We were recently asked to assess a risk adverse environment in which there was (I don’t know the collective noun) a “chunk” of Cisco kit, comprising both switches and ASA firewalls. We needed to make sure it was being accessed in a secure manner.
The client had decided for this small isolated environment that implementing a centralised authentication system was inappropriate and costly, and to be fair, I can see that it was a fair decision.
Local authentication, given the scale and scope of the solution was the appropriate option and, in keeping with good security practices the client had disabled Telnet and only permitted SSH access, of the appropriate flavour. Furthermore, access to the management interface was only possible from specific IP addresses. Lovely.
However something sparked our attention: the administrative users would SSH in as level 15. Forgive me for expanding on this: level 15 is privileged EXEC mode, i.e. the superuser. And going straight in as a superuser is bad, kids.
Ordinarily for systems such as this, we would suggest logging in as a low privilege user (in Cisco terms that would be “level 0″, or user EXEC mode), and then to elevate privileges via the use of secondary authentication.
However we debated the use of a shared enable (level 15 access) password, which in theory could potentially erode security and the ability to audit commands being executed on the devices.
The solution we proposed to the client ended up being the use of the user definable privilege levels (1-14) which can be set up to permit users access to administrator defined commands and configuration options.
So, for instance, in this environment we recommended that, for the 3 users that had access to the Cisco devices, the accounts would be configured as follows with policies that would be put in place to the following effect:
- Each of them would, by default be granted level 0 privilege when SSH-ing in
- Each of them would have individual credentials assigned to custom privilege levels (1,2,3) which would enable commonly used administrative commands consummate with their duties
- In extremis the level 15 privilege mode password would be made available for use, and would then be changed
In essence a kind of clumsy sudoers approach to accessing the devices.
For example user Bob would be configured with level 0 access upon SSH-ing in. And then assign to Bob his level 1 password.
Then we would define the usual commands he would be likely to need to administer the device:
device(config)#privilege interface level 1 ip address device(config)#privilege configure level 1 interface device(config)#privilege exec level 1 show running-config device(config)#enable secret level 1 BobL!kesSecu)ty
In order to elevate to the level 1 privileged account, Bob then simply has to use the following command:
enable 1
The interesting side-effect of this is that if Bob were to show the running configuration, he would only see the configuration of the commands that he has that privilege level to alter.
Which is nice.