Tuesday, September 4, 2012

Cisco Switch Security - Section 1 - Management Interface

1. Management port and Interface

The management interface permits an administrator to configure the switch, check different operational parameters and alter the way frames are treated or forwarded.

There are multiple types of management interfaces:

  • Direct or local interactive session, for example through a serial console
  • Remote or network interactive session, for example through a SSH connection
  • Management protocol, for example SNMP

1.1 Authentication

This is the act by which someone connecting will assume a specific identity, using a personal piece of information. This can be a password, a token code or one time password, a fingerprint etc. The important part is that that piece of information is sufficient to ascertain the requested identity, i.e. that no one else could have provided it.

In order to establish traceability and accounting, it is important that each administrator be given his/her own username and password.

1.1.1 Local and enable authentication

I won't talk about the old "line" passwords.

Cisco allows one to create a database of usernames using the command username. Its syntax is
username user secret password 
Where user is the given username, priv the privilege level (0 to 15, more on this below) and password the clear text password. By using the keyword secret, the password will be stored as a salted MD5 hash, which is stronger than the default password 7 based on a Vigenere Cipher.

Cisco users know the famous enable command: it grants level 15 access to the system if no other level is provided. When user tries to increase his/her privilege level, a special password is requested, that needs to be set with
enable secret password
Again, the secret keyword forces the storage to be salted and hashed using MD5.

1.1.2 Centralized authentication

Opposed to the local authentication, on which all the accounts need to exist on all the devices, there is a central authentication: the accounts exist in one location and a device has to check the credentials against that repository. In turn, the repository may send back additional information along the ACCEPT or REJECT response, such as the privilege level or a list of permitted commands.

I have seen two major centralized authentication deployed with Cisco devices: radius and tacacs. While other methods, such as LDAP or KERBEROS, are possible, I haven't seen them widely used. Remote Authentication Dial-In User Service (Radius)

For a description of radius, look here. By no standard is RADIUS a recent protocol. It was originally developed in 1991 to allow the central authentication of dial-in users. Over the years, its use cases have grown to include not only dial-in, but also console authentication, OS login authentication and so forth.

On Cisco devices, two types of radius server exist: private (limited to a group) or global (accessible to all groups). The difference is that if a radius server is used by more than a single group, a global definition will force all the parameters (ports, key, timeouts) to be the same. A private server exists only within the scope of a group, and has its own parameters: if the same server is defined in another group, different parameters can be specified.

The authentication process with Cisco is as follow:

  • A server exists within a group (there is also a default global group called radius)
  • A group is used in an authentication method
  • An authentication method is used to perform the authentication process attached to a management interface

Configuration steps:

Activate the aaa code
aaa new-model 

Define a group and its private servers:
aaa group server radius my-group-name 
server server1 key key1
server server2 key key2

Define an authentication method using the group and local if none of the servers is reachable:
aaa authentication login my-auth-name group my-group-name local

Bind the authentication to the remote management interface
line vty 0 15 
login authentication my-auth-name
It is important to understand the notion of "backup authentication". In the aaa authentication statement, I specified local after the group name. This means that the local authentication database will be used only and only if the servers in the group fail to reply. If a server replies with a rejection, the authentication process stops there and returns an authentication failure, and denies the login.

The backup authentication allows an administrator to gain access to the device even if the radius servers are down or unreachable. However, this opens the potential for misuse. Let's assume Alice is a disgruntled employees and is about to be fired. Her account was just disabled in radius. Decided to leave in a blaze of glory, she runs a DoS against the radius servers and use the local credentials to access the switch... Terminal Access Controller Access-Control System (TACACS)

For more information on tacacs/tacacs+, read the wikipedia page.

Tacacs/Tacacs+ has some advantages over radius: encryption of the whole communication instead of just the password field, authorization of individual commands. However, if radius is an open protocol, Tacacs is proprietary.
The authentication process is the same as for radius.

Configuration steps:

Activate the aaa code

aaa new-model

Define the server group

aaa group server tacacs+ my-group-nameserver server1server server2

Define an authentication method using the group and local if none of the server is reachable:

aaa authentication login my-auth-name group my-group-name local 

1.1.3 Putting the authentication together

aaa new-modelusername myuser secret MySecretPassword 
aaa group server radius my-group   
server key ThisIsMyRadiusKey
aaa authentication  login my-auth-login group my-group local
line vty 0 15 
login authentication my-group

1.2 Authorization

After a user has proven who he/she is to the system, he has to get his/her authorization to perform tasks. For instance, is the user allowed to "show" certain parameters? The configuration? Is he/she allowed to alter the system configuration? 

The authorization process for Cisco devices has two different options.

  • Privilege level based: the user will be assigned to a privilege level, which has a number of commands allowed. All users at the same privilege level have the right to execute the same commands.
  • Command based: when a user enters a command, the device will check with the authorization server whether this is permitted. If the answer is "yes", the command is allowed, otherwise the command fails. 
The latter depends on the authorization server and will not be described in this text. 

1.2.1 Local database

To authorize a user against the local database, two components are needed: a user entry defining the privilege level, and the aaa statement to instruct the device to enforce the privilege level. I will describe the process of defining what command is available to a privilege level later.  Of course, this presumes the user has been authenticated prior to be authorized!

To assign a privilege level to a user, the command is username.
username user privilege priv 
To instruct the device to apply the privilege level.

aaa authorization exec <my list> local

To apply the authorization to the user sessions.

line vty 0 15authorization exec <my list>

1.2.2 Radius authorization

Radius authorization works in almost the same way: the Radius server returns an A/V pair the device interprets as the privilege level. 

Configuring the A/V pair depends on your Radius server. The information that needs to be returned is

shell:priv-lvl=<priv level>
In order to configure the radius authorization, either a group of radius servers or all the radius servers can be selected through the definition of a list-name.

aaa authorization exec <my list> group <my radius group>
- OR -
aaa authorization exec <my list> group radius
As for the authentication, a second method can be added as a failover if the first method fails. 

1.2.3 Tacacs+

This is the same as for the radius authorization: an A/V pair is defined on the server and returned. Instead of creating a group of radius servers, one would create a group of tacacs+ servers.

1.2.4 Allowing commands based on the privilege level

Now that each user is assigned a privilege level, we can restrict the commands used. 

An important point to remember: a privilege level allows access to all the commands listed for that privilege, but also for all the commands allowed for the privileges below! For instance, if "ping" is allowed at privilege level 3,  all users at level 3 and up can use it. 

Privilege levels start at 0, which allows only 5 commands (disable,enable,help,exit,logout), and up to 15, which is the equivalent of "root" in the Unix world, and accessible through the enable command without parameter.

Of course, all the privilege levels don't have to be used. But the planning needs to be adequate, otherwise you may have to shift levels and change a fair amount of configuration.

 As a privilege level inherits all the commands from below, the command definition can have "holes", and for instance, you may configure privilege levels 1, 7, 9, and13. Levels 2 thru 6 will have the same commands as level 1, 8 as level 7, 10 thru 12 as level 9 and 14 as level 13. This allows for future definitions if needed.

In IOS, commands come in two flavors: exec and configuration. The exec mode is basically the shell in which you type all non configuration commands, including reloading the device, pinging other devices, saving the configuration and displaying information. The configuration mode, as its name indicates, is to alter the configuration of the device. 

Example: to allow privilege level 7 to save the configuration and to configure SNMP parameters

privilege exec level 7 write memory 
privilege exec level 7 configure 
privilege exec level 7 configure terminal 
privilege configure level 7 snmp-server

1.3 Accounting

Accounting allows one to review "what" was done by "whom". This is often overlooked but is an extremely important feature to have, both from a compliance perspective and from the company's ability to quickly find the origin of an issue. 

There are two options for command accounting: logging and aaa accounting. The logging part will be addressed in a later chapter.  

The aaa accounting is only possible with radius and tacacs+. No local aaa accounting is possible. To activate aaa accounting, as for authentication and authorization, a group must exist. A quick note: there is no named-list available for system accounting, all the accounting needs to be done as default.

aaa accounting exec default start-stop group <my group> 
aaa accounting command <my level> default start-stop group <my group>
The first command logs all accesses to the exec shell, recording the time started and stopped. The second logs all commands executed at level <my level>.

1.4 Consoles

A Cisco device has multiple types of console: local serial and remote (network) consoles. A console is a way to interact with the management plane of the device, i.e. to execute commands to get some information about the device's status or to modify its configuration.

1.4.1 Serial consoles

These are physical console ports on the device. Usually, they are RJ45 (ethernet-like) ports, but nowadays, they also come as USB miniports. In order to connect to it, one needs to have a physical access to the equipment. 

As physical ports, they don't support any fancy features such as encryption or access-list, but they provide access to the rommon during the boot sequence. 

There could be one or two console ports, denoted "con" and "aux". The latter can be configured as a console port to connect a modem and gain a remote access should the device lose access to the network. 

1.4.2 Network consoles

These are virtual consoles - denoted by vty - that emulates a serial port over a network connection. They are accessible from anywhere as long as a TCP connection is possible to the device. Specifying the protocol

Network consoles support different protocols: telnet, rlogin, ssh. These define what service will be bound to the vty. For instance

line vty 0 4 
transport input telnet 
line vty 5 15 
transport input ssh 

defines that telnet sessions will be allocated a vty from 0 to 4 and the ssh ones will get a number between 5 and 15.

Administering a network device is a sensitive task: whoever gets access to yours can deeply affect your operations by creating issues, monitoring traffic or redirecting packets. As such, it is important that all remote management connections are encrypted.  

SSH was designed as a VPN technology. The best known feature is the replacement for telnet. As telnet sends the password plaintext, it is susceptible to being intercepted by an attacker. All modern devices support configuring SSH for remote administration, and Cisco is no exception.

ip ssh version 2
This will force SSH version 2 to be used. Version 1 is afflicted by a series of issues that can be used to compromise a device.
ip domain-name <your domain-name>
Next, we have to define the domain-name for the system. This is not extremely important to have something resolvable or meaningful.
crypto key generate rsa
Next we generate the encryption keys using the default settings. There are options to specify whether the keys are exportable, the modulus size (or key length) and so forth.
line vty 0 15
transport input ssh
Last but not least, we apply this to all vtys. Starting now, the device is only accessible through ssh. A word of caution: SSH requires some authentication, it is important to have that configured and working prior to enabling SSH. Limiting the sources

Now that we can authenticate, authorize and trace, and that all the sessions are encrypted, let's look further: how can we restrict the access to the management console to certain sources.

An important point in any secure design is "segregation": segregation of networks and machines based on roles - network operators or engineers, system administrators, non technical personnel and so forth. The requirements for each are different, and it makes sense to have them in different subnets. 

Using an access-list, it is possible to restrict the access to any Cisco device to a group of subnets. The following example uses a standard access-list and supposes that:

  • The local subnet for the network operators is
  • The remote access subnet for the network operators is

  The commands are

access-list 10 permit
access-list 10 permit

line vty 0 15
access-class 10 in

1.5 More control over the login process

There are now a few things left we can do. 

1.5.1 Limiting the number of failed attempts in SSH

First, we will put some obstacles in an attacker's path. Let's assume the attacker wants to brute force some credentials and has access to a machine with access to the device. A common attack is to create a session and start trying combinations of username/password.

An important step is to make sure this takes as long as possible by severing the connection after a few failed attempts. That way, the attacker will spend a fair amount of time re-establishing the session to the device, which will give some more time for the security team to notice the events and react.

ip ssh authentication-retries 2
This gives two attempts, if the first one fails, the second must succeed or the session will be interrupted. 

1.5.2 In case of (repeated) failures ...

Also, we may want to enforce a delay in the login process if too many authentication failures are encountered in a brief period of time. Cisco offers a mechanism for this in the login enhancements.

login block-for 30 attempts 5 within 60
The previous command instructs the router to suspend the login process for 30 seconds if 5 failed attempts are detected within 60 seconds or less. This is a powerful way of delaying an attack, but at the same time, it offers a side-effect of enabling an attacker to DoS a network device and prevent legitimate access.

In order to mitigate that, an access-list can be applied to provide a list of IPs that have access, even during the quiet-period (the period during which the login process is suspended).

access-list 11 permit host
login quiet-mode access-class 11
Again, this has another side effect: if the compromised machine is, there will be no enforcement of the quiet-mode for the attacker. The emphasis is on making sure the host(s) allowed are perfectly secure. 

The team may want to log failed attempts, but maybe not EVERY failed attempt. For instance, we may not need to know whenever a colleague (or self) fat fingers his/her password.

login on-failure log every 3
This logs the failure only after 3 unsuccessful attempts. 

1.5.3 But if successful ...

We may want, however, to keep track of all successful logins. Even though we have the accounting in place, we may want to have a specific message for each successful created session. 

login on-success log
That last command will generate a log entry for each successful login to the device. 

1.5.4 More delays during login!

Yes, there is a way to add some delay between the login attempts. Again, using the login enhancements, a delay between two login attempts can be enforced.

login delay 3

After this, there will be three seconds between two login attempts. With all the previous configuration in place, an attacker would spend around 72 seconds - not including the session re-establishment - for every 5 attempts. This will considerably slow down his effort and give that time to be detected.