Security Management

If a network is to be secure, the routers themselves must be secured. Passwords are one way to control access to the routers. You can configure passwords on the routers, or you can use authentication servers such as TACACS+ or RADIUS. In addition to password protection, you should limit interactive access to the routers to necessary protocols and users. Enable only the protocols that are required for the proper functionality and manageability of the router and restrict access to the routers to those IP subnets that you know are secure. Even with access controlled, it is possible for mischievous network users to attempt to prevent the routers from functioning. Take steps to reduce the chance of these denial-of-service attacks on the routers. The next few sections discuss router configuration parameters needed to provide secure and properly functioning routers.

Password Types and Encryption

You should control all access by some authentication mechanism. If you cannot use TACACS+ or RADIUS, you should protect privileged EXEC mode router access with the enable secret password type. Do not use the older enable password, because it has a weak encryption algorithm. The enable secret password command provides better security by storing the enable secret password using a nonreversible cryptographic function. The added layer of security encryption provided proves useful in environments where the configuration file, and therefore the password, crosses the network or is stored on a TFTP server. Encrypt all passwords, including username passwords, authentication key passwords, the privileged command password, console and virtual terminal line access passwords, and BGP neighbor passwords using service password-encryption to prevent an onlooker from seeing passwords when you display the router configuration.

Controlling Interactive Access

You should control interactive access to the router. You can limit access to specified network numbers by using the following command:

  access-class   access-list_1-199_or_1300-2699  {  in   out  } 

The access-list argument specifies the source network number allowed to connect to the line (with the keyword in ), or the network number to which a connection is permitted (with the keyword out ).

Ensure that there are no access holes by permitting only the remote access protocol desired, such as the following:

  transport input telnet ssh  

List the protocols that are permitted. Everything else is denied .

You should password protect all modems connected to the router, in addition to the login required on the console and auxiliary ports.

If the modems are to be used for dial-in purposes only, so administrators can access the router from home, disable the capability to use reverse Telnet to connect to the modem from the network and dial out to another location. Reverse Telnet provides the capability to specify a port number along with the IP address to connect to a device off of an asynchronous port on the router. Disable reverse Telnet on any port connected to an asynchronous terminal or modem that should not be used to dial out by issuing the transport input none command on the modem-connected line.

Example 9-36 illustrates a router configuration with all the access control methods discussed so far.

Example 9-36 Controlling Interactive Access on a Router

  access-list 1 permit 172.16.0.0 0.0.255.255   line con 0   transport input none   line aux 0   transport input none   line vty 0 4   access-class 1 in   transport input telnet ssh  

Telnet and Secure Shell access are the only remote protocols permitted, and those who can use the protocols to connect to the router are limited to source IP addresses in the range 172.16.0.0/16.

Minimizing Risks of Denial-of-Service Attacks

Denial-of-service (DoS) attacks deny access to some resource. Someone can perform a DoS attack in many ways. You can take some actions, however, to minimize the risks of an attack aimed at the router.

A limited number of vty ports are available on a router. Once they are all in use, no more remote sessions are permitted to the router, opening up the potential for a DoS attack. An intruder can block all vty ports, denying access to the administrator. Configure a very restrictive access-class command on the last vty port. Permit only a specific management station. This way, at least one port will be accessible. Configure exec-timeout also, to prevent idle sessions from consuming the vty indefinitely. The service tcp- keepalives -in command configures TCP keepalive messages on incoming connections to guard against malicious attacks and "orphaned" sessions caused by remote system crashes.

A specific DoS attack uses directed broadcasts. ICMP packets are sent to a directed broadcast address with a falsified source address, and all machines on the LAN reply, sending a large stream of traffic to the falsified source address. The real node addressed with the source IP address gets flooded with data. The command no ip directed-broadcast configured on all LAN interfaces thwarts this attack. no ip directed-broadcast is the default on IOS 12.0 and later.

IP packets with the source-route option specify routers that the packet must traverse between the source and destination. Return packets also must traverse the specified routers. A spoofed source address in a source-routed packet can cause a node to bypass routing tables and send data to a spoofed address. There is rarely ever a valid use for source-routed packets. Configure the routers to drop packets with the source-route option using the global command no ip source-route.

Very fast floods of packets may cause the router to spend so much time responding to interrupts from interfaces that it cannot do anything else. The command scheduler interval milliseconds tells the router to stop handling interrupts and attend to other business at regular intervals. Newer platforms may use scheduler allocate interrupt-time process-time instead.

The interrupt-time argument is the maximum number of microseconds the router spends on fast switching within any one network-interrupt context. The process-time argument is the minimum number of microseconds the router spends at the process level when network interrupts are disabled.

The routers run small servers used for diagnostic purposes. In reality, these are rarely used. The TCP services are Echo, Chargen, Discard, and Daytime. The UDP services are Echo, Chargen, and Discard. An attacker can flood traffic to these services, impacting the capability of the router to route. The following commands disable these services:

  no service tcp-small-servers   no service udp-small-servers  

The services are disabled by default in Cisco IOS Software Release 12.0 and later.

Some other services that should be disabled are Finger and the Async Line BOOTP Server, if they are not being used. Use the following commands to disable these services:

  no service finger   no ip bootp server  

The Finger service allows Finger protocol requests to the router. A Finger protocol request is equivalent to issuing a remote show users command, which displays information about active lines on the router.

The router offers BOOTP services to hosts connected to asynchronous lines. The command no ip bootp server disables these BOOTP services.

The configuration in Example 9-37 illustrates minimizing the DoS risks using the previously discussed commands.

Example 9-37 Minimizing DoS Attacks

  enable secret jj15Qp   service tcp-keepalives-in   scheduler interval 500   no server tcp-small-servers   no server udp-small-servers   no service finger   no ip bootp server   no ip source-route   int e 0   no ip directed-broadcast   access-list 10 permit 172.16.1.2   line vty 4   access-class 10 in   transport input telnet  

Configure a remote authentication and authorization server, such as TACACS+, to secure the router further.

TACACS+

Terminal Access Controller Access Control System Plus (TACACS+) provides centralized validation of users attempting to gain access to routers or network access servers. A TACACS+ application resides on a server, runs as a daemon, and stores information about access privileges in a database. When a user logs in to a router configured with TACACS+, the TACACS+ client on the router and the TACACS+ daemon communicate to send the user login and password prompts and to exchange authentication and authorization information. The router also sends accounting information to the TACACS+ daemon. All communication between the router and the TACACS+ daemon is encrypted, although the communication between the user and the router may not be.

TACACS+ provides authentication, authorization, and accounting information:

• TACACS+ authentication requires the user to enter a login ID and password. The authentication service also can send messages to logged-in users, such as a request to change their password.

• TACACS+ authorization fine-tunes what the logged-in user can do. Authorization may automatically perform commands upon login, provide access control, or limit session duration. Authorization also can limit which commands a user is permitted to perform while logged in to the router.

• TACACS+ accounting collects information used for billing, auditing, and reporting and sends it to the TACACS+ server. The accounting records include information about user identities, start and stop times, executed commands, number of packets, and number of bytes. The information is useful in a security audit and for billing purposes. When TACACS+ is used to control user access to a network access server, which then enables the user to use services on the network, billing information may be desirable.

TACACS+ Authentication Configuration

The router uses AAA to enable TACACS+. The command aaa new-model enables AAA.

The command that defines a list of authentication methods is as follows :

  aaa authentication login  {  default   list_name}   group   auth_type  [  auth_type ...  ] 

The authentication methods are tacacs+, radius, kerberos, local, line password, enable password, and none.

After the authentication list has been defined, it is applied to lines. The keyword default automatically applies the list to all lines. When you are first configuring authentication, it is a good idea to specify a list name and manually apply the list to lines. By doing so, you can test your configuration in a controlled manner, without locking yourself out of the router.

To apply the list to lines, use the following commands:

  line   type number   login authentication   list_name  

You also need to specify the location of the TACACS+ server. Use the tacacs-server host ip_address command to specify the IP address of the server.

Example 9-38 demonstrates a router configuration for TACACS+ authentication.

Example 9-38 Configuring a Router for TACACS+ Authentication

  aaa new-model   aaa authentication login tac tacacs+  enable   tacacs-server host 172.16.1.2   line vty 0 1   login authentication tac   !line vty 2 4   ! login authentication tac   !line con 0   ! login authentication tac   !line aux 0   ! login authentication tac  

The authentication list tac first attempts to authenticate using the TACACS+ server, 172.16.1.2. If the server is unreachable, the second method, enable password authentication, is used. The second method allows access to the router in the event that the TACACS+ server becomes unreachable. The list is traversed only if a method is unavailable, not if the method returns a failure. If the TACACS+ server is down, for instance, enable password is used. If TACACS+ server is up, but the user ID entered is not correct, a failed message is returned and no more methods are attempted.

Notice that the authentication list in Example 9-38 is applied only to line vty 0 and 1. This is for testing purposes. If TACACS+ is misconfigured, the router can still be accessed via the other vty lines and the console port. Make sure the configuration is correct and working as you expect before applying the list to all lines. When the configuration is correct, apply the authentication to all lines.

You can define a TACACS+ shared encryption key using tacacs-server key key.

You must define the same key in the TACACS+ configuration file on the server.

You can use TACACS+ when entering the enable mode on the router as well. Use the command aaa authentication enable default group auth_type [ auth_type ].

The configuration commands in Example 9-39 are added to router Seattle to specify enable-level authentication and a TACACS+ shared key.

Example 9-39 Specifying Enable-Level Authentication and a TACACS+ Shared Key on Router Seattle

  aaa new-model   aaa authentication login tac tacacs+  enable    aaa authentication enable default group  tacacs+ enable    tacacs-server host 172.16.1.2    tacacs-server key mykey    line vty 0 4   login authentication tac  

Example 9-40 shows the TACACS+ server configuration file that corresponds with the router configuration in Example 9-39.

Example 9-40 TACACS+ Server Configuration File for Seattle Configuration in Example 9-39

 Key = "mykey" User = agnes {                     login = cleartext "agnes password" } user = admin {                     login = cleartext "encrypted" } user = $enab15$ {                     login = cleartext "secret" } 

Two regular users are configured, agnes and admin. The user $enab15$ is used for the enable-level authentication, at privilege level 15, which is the default. A side effect of the enable authentication is that a user named $enab15$ is created. Someone can log in to the router with this user ID, if he knows the password.

With the configuration in Example 9-39, access to the router requires a username and a password. The normal router login IDs are used only if the TACACS+ server is unreachable. The username is included in certain log messages as a result.

The following log message shows the username, the user's IP address, and the date and time of a configuration change:

 Jun 20 16:42:32 UTC: %SYS-5-CONFIG_I: Configured from console by agnes on   vty0 (10.1.2.25) 

The preceding represents a very basic configuration. You can do much more with TACACS+, including defining groups and specifying privileges based on group membership using DES-encrypted passwords or using a UNIX password file.

NOTE

Refer to the TACACS+ User Guide for full implementation specifications. Passwd(5) is the supported password file type for the UNIX password file.

TACACS+ Authorization Configuration

You can configure TACACS+ to authorize what users are permitted to do on the router. Access lists can be applied, commands can be limited, or PPP and SLIP access can be permitted. A profile is set up on the TACACS+ server for each user. The profile specifies what the user is authorized to do. When the user logs in to the router, all his actions must be authorized by the contents of the user profile.

The following commands define the authorization methods list and apply the list to lines on the router:

  aaa authorization  {  network   exec   commands   level   reverse-access  } {  default   list-   name  } [  method1  [  method2...  ]]  line   type number   authorization  {  arap   exec   commands   level   reverse-access  } {  default   list-name  } 

The user profile must be configured on the TACACS+ server. The same warning that applied to authentication applies here. Make sure to test the authorization configuration well, and configure a user who has unrestricted access before using the default list, which gets applied to all lines and interfaces, or before applying a named list to all lines. Authorization is applied to the router as soon as the command is entered, and it affects even the existing connections. Also, the TACACS+ configuration file defaults to no authorization allowed. If TACACS+ authorization is configured on the router and applied to all lines, but nothing is specifically permitted in the configuration file, you may find yourself unable to perform any commands.

The server configuration file in Example 9-41 limits the commands available to Agnes but provides no restrictions on user Admin.

Example 9-41 TACACS+ Server Configuration File Providing Restrictions Based on the User

 Key = "mykey" User = agnes {            login = cleartext "agnes password"  cmd = show {   permit .*  } } user = admin {  default service = permit  login = cleartext "encrypted" } user = $enab15$ {            login = cleartext "secret" } 

Agnes is permitted to perform any show commands. Nothing else is permitted.

Example 9-42 shows the router commands required to make use of the TACACS+ configuration in Example 9-41.

Example 9-42 Router Authorization Configuration Associated with the TACACS+ Server Authorization in Example 9-41

  aaa authorization commands 1 restrict group tacacs+   aaa authorization commands 15 restrict group tacacs+   line vty 0 1   authorization commands 1 restrict   authorization commands 15 restrict   ! line vty 2 4   !           authorization commands 1 restrict   !           authorization commands 15 restrict  

Remember not to apply the authorization list to all vty ports until after you have fully tested it.

Like TACACS+ authentication, you can do much more with authorization. I have illustrated a very simple use of the TACACS+ authorization feature. Access lists can be applied. Autocommands can be enforced. Telnet restrictions can be applied.

TACACS+ accounting shows information about what the user connected to the router is doing.

TACACS+ Accounting Configuration

TACACS+ accounting is used to record information about user connections, including the length of their connections, commands they entered, and the destination and length of outbound connections. This information can prove useful for billing or for a security audit. You enable accounting by using AAA accounting commands on the router and by specifying the accounting filename in the TACACS+ configuration file on the server.

The following commands define the type of accounting associated with the named list:

  aaa accounting  {  system   network   exec   connection   commands   level  } {  default   list-   name  } {  start-stop   wait-start   stop-only   none  } [  method1  [  method2...  ]]  line   type number   accounting  {  arap   exec   connection   commands   level  } {  default   list-name  } 

Information about system-level events, such as the system rebooting or accounting configured, is enabled with system accounting. Information about PPP, SLIP, or ARAP sessions, including packet and byte counts, is provided with network accounting. EXEC accounting provides information about the EXEC terminal sessions on the router. The information includes username data, as well as start and stop times of the session. Connections accounting provides information about connections made from the router. The connection could be telnet, LAT, tn3270, PAD, or rlogin. The data includes destination address, protocol, start and stop times, username, and packets and bytes transferred. Command accounting provides information about commands entered. The commands are normally either level 1 or level 15 commands. Level 1 commands are those that you can enter at any login level. Level 15 commands are available only at the enable level. The actual command entered is recorded. Even configuration commands are recorded.

To apply the list to lines, use the line subcommand accounting [ type ] list-name.

To configure accounting on the TACACS+ server, add the command accounting file = filename, as demonstrated in Example 9-43.

Example 9-43 Configuring Accounting on the TACACS+ Server

 Key = "mykey"  Accounting file = tacacs.acct  User = agnes {            login = cleartext "agnes password"            cmd = show {                       permit .*            } } user = admin {            default service = permit            login = cleartext "encrypted" } user = $enab15$ {            login = cleartext "secret" } 

Example 9-44 shows the router commands that enable command and EXEC accounting.

Example 9-44 Enabling Command and EXEC Accounting

  aaa accounting commands 1 default stop-only group tacacs+   aaa accounting commands 15 default stop-only group tacacs+   aaa accounting exec default start-stop group tacacs+  

The line vty subcommands are not needed in this configuration because the default list is used. The default list is automatically applied to all lines and interfaces.

Example 9-45 shows the content of an accounting log.

Example 9-45 The Accounting Log Shows Commands and an EXEC Record

 ObiWan:/tacacs#  more tacacs.acct   Tue Jun 20 10:33:06 2000        172.16.1.7      agnes   tty2  10.1.2.25  stop    task_id=2       start_time=961520711    timezone=UTC service=shell  priv-lvl=15     cmd=debug aaa accounting <cr>   Tue Jun 20 10:33:57 2000        172.16.1.7      agnes   tty3  10.1.2.25  stop    task_id=4       start_time=961520761    timezone=UTC    service=shell  priv-lvl=15     cmd=write terminal <cr>   Tue Jun 20 10:34:08 2000        172.16.1.7      agnes   tty3  10.1.2.25  stop    task_id=5       start_time=961520773    timezone=UTC    service=shell  priv-lvl=15     cmd=configure terminal <cr>   Tue Jun 20 10:34:22 2000        172.16.1.7      agnes   tty3  10.1.2.25  stop    task_id=6       start_time=961520786    timezone=UTC    service=shell  priv-lvl=15     cmd=interface Serial 1 <cr>   Tue Jun 20 10:34:24 2000        172.16.1.7      agnes   tty3  10.1.2.25  stop    task_id=7       start_time=961520789    timezone=UTC    service=shell  priv-lvl=15     cmd=shutdown <cr>  Tue Jun 20 10:34:42 2000        172.16.1.7      agnes   tty3  10.1.2.25 stop    task_id=3       start_time=961520734    timezone=UTC    service=shell   disc-cause=1    disc-cause-ext=1020     elapsed_time=73 nas-rx-speed=0   nas-tx-speed=0 

The accounting log shows commands entered and an EXEC session record. From the log, you can see that Agnes shut down serial interface 1 at 10:34:24 on Tuesday, June 20. She terminated her EXEC session at 10:34:42 on the same day. Her session lasted for 73 seconds.

You can use accounting for security audits , when the need arises to see what people have been doing on the router. You also can use it for billing. Assuming that this information comes from a network access server (NAS), and the users are accessing network resources via the NAS, the data shows that Agnes was connected for 73 seconds. You could bill her for 73 seconds of network usage.

RADIUS

Remote Access Dial-In User Service (RADIUS) provides the same functionality as TACACS+, with a few differences. RADIUS is designed to be used as an authentication, authorization, and accounting server for dial-in access to a network. The RADIUS client resides on the router or NAS and communicates with a RADIUS server on the network. The main functional difference is that RADIUS does not allow users to control which commands can be executed on a router, as TACACS+ does. This makes TACACS+ a better choice for controlling access to a router if the network administrator wants to create tight control of commands available to various users.

RADIUS was developed by Livingston Enterprises. Its source code is publicly available, and there are no use restrictions. There are many server implementations , and the client is supported in many different vendor devices.

RADIUS is configured on the Cisco router in the same way that TACACS+ is enabled, via the AAA commands. A RADIUS server and a TACACS+ server may both be in the network, authenticating, authorizing, and providing accounting for the same router or NAS.

For example, a design goal may be to use the RADIUS server to authenticate users. If the RADIUS server is unavailable, the TACACS+ server authenticates. Example 9-46 shows the router configuration to enable RADIUS as the primary authentication server and TACACS+ in case of an unavailable RADIUS server.

Example 9-46 Enabling RADIUS and TACACS+ on a Router

  aaa new-model   aaa authentication login remoteauth radius tacacs+  enable   tacacs-server host 172.16.1.2   radius-server host 172.16.1.2   tacacs-server key mytackey   radius-server key myradkey   line vty 0 4   login authentication remoteauth  

You enable RADIUS in the same way that you enable TACACS+.

Secure Shell

Secure Shell (SSH) enables a user to make a secure, encrypted connection to a router. The connection's functionality is similar to an inbound Telnet session. Unlike Telnet, the connection is encrypted, providing a huge benefit over Telnet, which sends all data between the client and server (the router, in this case) in clear text, readable by any network analyzer collecting data along the traffic's path . Telnet's method means that if you are using Telnet to access the router, the passwords that you have purposely encrypted on the router are passed in clear text over the network. SSH encrypts the connection, so no data is exchanged in clear text between the client and router. RSA authentication for the SSH connection is not supported on routers, although it is supported in some clients . Authentication is performed by user ID and password only.

SSH is supported on 7200, 75000, and 12000 series routers only, and it is supported on DES and triple DES data encryption software images only. IOS supports SSH version 1 only.

To enable SSH on a router, you must perform the following steps:

Step 1. Configure a host name and domain name on your router.

Step 2. Generate an RSA key-pair.

Step 3. Enable local or AAA authentication.

Step 4. If you are using AAA authentication, disable it on the console port.

Step 5. Configure optional SSH parameters.

Host name and domain name are configured using the following commands:

  hostname   hostname   ip domain-name   domainname  

If these commands are not configured, errors report when you generate the RSA key-pair.

SSH is automatically enabled when the RSA key-pair is generated. It is disabled when the RSA key-pair is deleted.

The command crypto key generate rsa generates the RSA key-pair and enables SSH. SSH can use either local authentication, enabled using the username command, or AAA authentication. AAA must be disabled on the console port.

The SSH parameters modify the default connection behavior. You can modify the timeout value that applies to the SSH negotiation phase or you can specify the number of authentication retries. The timeout value must not exceed 120 seconds. The default is 120. The number of retries must not exceed 5; the default is 5. Use the following command to modify the parameters:

  ip ssh  {[  timeout   seconds  ]  [  authentication-retries   integer  ]} 

Example 9-47 demonstrates a basic SSH configuration.

Example 9-47 SSH Configuration

  hostname Seattle   ip domain-name thecompany.com   crypto key generate rsa   aaa authentication login tacauth tacacs+ local enable   aaa authentication login aaanone none   username agnes password 0 agnespassword   ip ssh time-out 60   ip ssh authentication-retries 2   tacacs-server host 172.16.1.2   tacacs-server key secret   line con 0   login authentication aaanone   transport input none   line aux 0   login authentication tacauth   line vty 0 4   login authentication tacauth  

Note that the AAA authentication list aaanone, which has no AAA authentication method defined, is applied to the console port. The other authentication list, tacauth, is applied to all vty ports and the auxiliary port.