Securing the device management

Secure Management

First let's nail down a definition of what our management traffic is before we attempt to make it secure.

Management traffic is any traffic that allows a user to control a device.

We'll keep this in mind throughout this post. Saying any traffic that terminates on a device is too broad, as that includes control section traffic.

The reason we want to keep this secure should be fairly obvious, we don't want any malicious users to gain control of our devices, because once they have control of our devices, they've got control of our network.

When we first receive an IOS device, we connect to it using the console port directly plugged into our computer. Management this way is inherently secure, as someone has to have physical access to our device in order to control it. However whilst this works well for initial setup, ongoing support of a device via the console can be very inconvenient, as they are often housed in different buildings, locations or even countries. We need a way of obtaining a secure connection to a device, without being physically near it.

Best Practices

• Strong password policy
• User authentication and AAA – being able to verify exactly which users are logging on, rather than just having a device password
• Role-based access – 1^st line support engineers may require access to issue show commands, but may never need access to configure a device.
• Encrypted management protocols – SSH, HTTPS, management VPNs
• Logging
• NTP
• Secure system files – make it difficult to delete startup configuration files

Using AAA

There are many ways to implement AAA on Cisco devices, many of which use centralised servers, which we will refer to as authentication servers. Some of these options are AAA servers, RADIUS servers, TACACS servers, or ACS servers. All of these essentially refer to a server which holds a database of usernames and passwords to verify who is connecting to a device. You can also implement device only authentication, where the device itself holds a database of usernames and passwords to authenticate users.

AAA method lists

We can create a list of AAA methods to be used, and make that list specific for authentication, authorisation and accounting. The default list will be applied to the entire device. If we use a custom list it must be specifically reference in the configuration of a line or interface.

R1(config)#aaa authentication login default local

This command would set the default method to login to the device to the local database.

R1(config)#aaa authentication login CONSOLE krb5

However this command would set the login method to krb5, and then we could reference this new list on the console like so:

R1(config)#line console 0

R1(config-line)#login authentication CONSOLE

 

Role-based access and custom privilege levels

We've spoken before about the need for role-based access and only granting the minimum required access required. To put this into place we create a privilege level for each user that we define. The privilege levers run between 1 and 15, with 1 being user access only, and 15 being full administrator access. With these access levels we can assign commands which normally reside at level 15 to a lower security level so that lower privilege level administrators can access what they require for their role.

Encrypted Management Protocols

As has been spoken about before, SSH and HTTPS should really be the only methods used to manage a device remotely, unless you are configuring a VPN to access the device. Within SSH, version 2 should always be used if possible.

R1(config)#ip ssh version 2

Logging

Logging is extremely important as it provides us a way to see what is happening with the device and the network without watching it in real time. It gives us the opportunity to see if hardware fails or a failover occurs between clustered devices, and much more information.

Cisco devices can output logs to a variety of places:

• Console
• vty lines
• buffer
• SNMP server
• syslog server

Syslog servers and SNMP servers are both popular options and often used in conjunction with each other.

Secure passwords

Now that we've gone over the best practices, we can see some practical examples.

R1(config)#username insecure password cisco

R1(config)#username secure secret sf$%sd129&d

Here are two different ways of assigning a password to a user. They might not seem obvious right now, but if we run a command to see what users are enabled on a device we can see the difference:

R1#show run | inc username

username insecure password 0 cisco

username secure secret 5 $1$YBo/$1.JF.FtDmz8YZ44kPzXdM.

The difference is obvious here, the when we issue the secret command instead of the password command the secret is hashed with the MD5 algorithm to create what is seen above. Even if someone was able to view the configuration of the device, they wouldn't be able to retrieve the users password.

We can also define passwords on the console and vty ports:

R1(config)#line con 0

R1(config-line)#password 89skjh&^@lhasd

R1(config-line)#login

R1(config-line)#exit

R1(config)#line vty 0 4

R1(config-line)#password o872394uhjkhdsf7^

R1(config-line)#login

If we now issue a show run command and view the configuration for the console and vty ports, we can still see the passwords in clear text. There is no secret option available for configuring these passwords so we need another command to ensure that they are no longer visible.

R1(config-line)#do show run | beg con 0

line con 0

exec-timeout 0 0

privilege level 15

password 89skjh&^@lhasd

logging synchronous

login

stopbits 1

--------------------------------

line vty 0 4

password o872394uhjkhdsf7^

login

!

What we can do is the service password-encryption command, which will encrypt all the passwords on the device.

R1(config)#service password-encryption

R1(config)#do show run | beg con 0

line con 0

exec-timeout 0 0

privilege level 15

password 7 005C4A150F51034031014046080A01

logging synchronous

login

stopbits 1

-------------------------------------

line vty 0 4

password 7 011C5E5309585F5B34444402110104145C32

login

!

Note that this also encrypts the users whose passwords were specified with the password commands, but does not encrypt the users whose passwords were already hashed with the secret command:

R1#show run | inc username

username insecure password 7 104D000A0618

username secure secret 5 $1$YBo/$1.JF.FtDmz8YZ44kPzXdM.

Using AAA and method lists

First we need to enable aaa if it's not already in place on the device

R1(config)#aaa new-model

We can use a tacacs server to authenticate users, but first we must define the tacacs server itself:

R1(config)#tacacs-server host 1.1.1.1

R1(config)#tacacs-server key tacacspassword

Now we can use a default aaa method list to authenticate users:

R1(config)#aaa authentication login default local enable

This specifies that when a user is logging in they must authorise against the local user database, and if that fails then to use the enable secret which has been specified. Because this is a default list, this will apply to all logins, whether they are from console, aux ports or vty ports, unless those particular ports have a different authentication method specified.

R1(config)#aaa authentication login MY_LIST group tacacs+ local enable

This is a custom list which will first use the tacacs server to authenticate, if that is not responding then it will use the local database and then the enable password.

Now we can create authorisation lists which we can use to specify the privilege levels of the users who login:

R1(config)#aaa authorization commands 1 priv1 group tacacs+ local

R1(config)#aaa authorization commands 15 priv15 group tacacs+ local

Here we have defined two authorisation lists, one for users to login at the user level (level 1) and the other for administrators (level 15). These lists wont be used until they are specified at a line level.

R1(config)#aaa accounting commands 1 ACCT1 start-stop group tacacs+

R1(config)#aaa accounting commands 15 ACCT15 start-stop group tacacs+

It's alwas a good idea to have an admin account with privilege 15 present on the device, in the case that the remote server is unreachable, so long as the local database is specified as a backup

R1(config)#username admin privilege 15 secret 298hef8&&sdfh\

In the example below, we now apply our newly created aaa method lists to the vty ports, to be applied when users login remotely. First we set the authentication to come from MY_LIST, specified above. Then we set the authorisation commands for the list of users in prvi1 and priv15, and the accounting methods for the same users.

R1(config)#line vty 0 4

R1(config-line)#login authentication MY_LIST

R1(config-line)#authorization commands 1 priv1

R1(config-line)#authorization commands 15 priv15

R1(config-line)#accounting commands 1 ACCT1

R1(config-line)#accounting commands 15 ACCT15

Debugging Authentication

Now that we've got our aaa parameters, we can use the debug aaa command to see it in action.

First we need to put an IP address on our device so we can connect to it.

R1(config)#int loopback 0

R1(config-if)#ip address 10.0.0.1 255.255.255.0

We also need to set the logging to the buffer so we can see what happens:

R1(config)#logging buffered 7

R1#debug aaa authentication

R1#telnet 10.0.0.1

Trying 10.0.0.1 ... Open

User Access Verification

Username: insecure

*Nov 22 19:39:20.238: AAA/BIND(0000000E): Bind i/f

*Nov 22 19:39:20.242: AAA/AUTHEN/LOGIN (0000000E): Pick method list 'MY_LIST' ure

Password:

R1>who

Line User Host(s) Idle Location

0 con 0 10.0.0.1 00:00:00

* 2 vty 0 insecure idle 00:00:00 10.0.0.1

Here we can see that Bob is connected to line vty 0, and from the debug output we see that MY_LIST is to be used to authenticate.

What we can now to test the correct parameters are being used is to remove all the users from the local database and set the enable secret. What should happen when we try to connect as a local user is the authentication method should fall back to the enable password.

Remove users with the 'no username username' command

R1(config)#enable secret lasdjf*7SKJ

Now with no users defined, let's see what happens when we try to connect:

R1#telnet 10.0.0.1

Trying 10.0.0.1 ... Open

User Access Verification

Username:

*Nov 22 19:46:59.990: AAA/BIND(00000012): Bind i/f

*Nov 22 19:46:59.994: AAA/AUTHEN/LOGIN (00000012): Pick method list 'MY_LIST'

Username: myusername

Password: enable secret password set above

*Nov 22 19:47:04.846: AAA/AUTHEN/ENABLE(00000012): Processing request action LOGIN

*Nov 22 19:47:04.846: AAA/AUTHEN/ENABLE(00000012): Done status GET_PASSWORD

R1>

*Nov 22 19:47:11.154: AAA/AUTHEN/ENABLE(00000012): Processing request action LOGIN

*Nov 22 19:47:11.202: AAA/AUTHEN/ENABLE(00000012): Done status PASS

So even with no users specified on the device, we can still login with the enable password. Note that if we added none to MY_LIST, then we could still login without any password at all.

Next post we'll do learn how to do some troubleshooting.