Router Hardening

Having the device that provides all your network's security on the edge of the perimeter is like having an army's general placed ahead of his troops. The piece that is vital to your success or failure is in the most vulnerable position. When it comes to perimeter protection, we can use defense in depth to help, but in some environments, we might not have much support for our "general." This is why router hardening is so important to your network's security. In effect, it's like placing your general in a tank. Its focus is on protecting the protection device. This protection involves disabling all unneeded services and servers, blocking all unnecessary traffic types, locking down any methods we use to configure our security device, posting warning banners, and closely monitoring the device and the traffic that passes through it.

Operating System

Protecting a router isn't that much different from protecting a computer. (Hardening procedures applicable to hosts are described in Chapter 9, "Host Hardening.") One major concern that is often overlooked involves patches for the operating system. The operating system for Cisco routers is called the IOS. Keeping tabs on IOS updates and security flaws is imperative in defending your router from attack. Cisco's website posts security issues as they are discovered, and it is a good practice to check such sites regularly. For a list of Cisco security advisories, go to http://www.cisco.com/en/US/products/products_security_advisories_listing.html.

It is also wise to subscribe to an email/list such as @RISK: The Consensus Security Alert, which automatically sends multiplatform security advisory information to you as it becomes available. To subscribe, go to http://www.sans.org/newsletters.

Cisco also has a security mailing list at [e-mail].

Registration information is available at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html.

Locking Down Administration Points

One of the most important parts of securing a perimeter security device is locking down the ways it can be configured. Otherwise, it is like locking a door and leaving the key in the lock. Over the next few sections, we will discuss popular administration methods and some ways to secure them from outside attack.

Telnet

Telnet is probably the most popular way to remotely configure a router. Following are the two greatest concerns of Telnet:

• Properly securing the Telnet server from outside access to prevent remote nefarious users from reconfiguring your router.

• Realizing that all information, including logins and passwords, are sent in clear text. This means that a sniffer could assist in gaining access to your router configuration.

The Telnet server on board every Cisco router can be protected through username and password authentication. However, protection by authentication might be insufficient for securing of something as vital as a perimeter security device. For this reason, it is advisable to apply access lists that limit where Telnet sessions can originate. Following is an example of an ACL that allows an administrative station at IP address 192.168.1.1 to have Telnet access:

 access-list 11 permit 192.168.1.1 

This access list is applied to the virtual terminal lines (VTY) using the access-class command, which works similarly to the access-group command that applies ACLs to router interfaces. (For more information on ACLs or the access-group command, see Chapter 2.) This access list would be applied as follows:

1. To get into line configuration mode, enter normal configuration mode and type router(config)#line 1 3, where 1 through 3 is the range of VTY lines to which you want to apply the access list in question.

2. Enter the access-class command router(config-line)#access-class 11 in. One administrator's trick is to apply an ACL to the first several VTY lines (for example, 1 through 3) that allow access for the IP addresses of all administrators. Then, apply an ACL to the last VTY line, including only the IP address of the senior administrator's station. This way, the administrator can always get Telnet access, regardless of whoever else is connected. Not only do these access lists verify that you'll always have a free VTY session, but they also protect you from malicious outside users (and inside users for that matter).

3. Make sure that Telnet is the only input type your router will accept by using router(config-line)#transport input telnet. This command disables all other protocols from being used to access the VTY lines. (This is important to prevent access from alternate protocols such as rlogin.)

4. If you want to ensure that Telnet access is completely disabled at the router level, you can add the login keyword to the VTY line configuration of your router and then add the no password command. This disables Telnet usage because a password is required for access.

5. Though this causes a great headache for many an administrator, it is wise to enable timeouts for sessions with the exec-timeout command. Simply add it followed by the time, in minutes, you want an inactive session to remain open before you are disconnected.

The fact that Telnet transfers information in clear text can only be corrected by using an alternative configuration method such as Secure Shell (SSH), which utilizes encryption, or by adding IPSec support to run your Telnet sessions through encrypted ESP tunnels.

Telnet Trick

Sometimes you might want to separate VTY sessions on a Cisco router, such as when using lock and key access lists or other instances when you need to set different criteria for various VTY Telnet sessions. You might want to have certain settings for VTY lines 13 and others for 45. How do you then log in to line 4 or 5? Using the default Telnet port (23) connects you to the first available VTY. If that doesn't happen to be line 4 or 5, the alternatively defined criteria will not apply. access-class statements will not correct this problem. If your connection fails to one VTY line, you are simply denied access, not rolled on to the next line to see if its ACL will allow you.

I searched for a way to change this behavior, but to no avail. Then as I was perusing a firewall mailing list archive one day, I found a workaround. A gentleman sent in the advice that you can use the rotary # command to allow VTY Telnet access via an alternate port. This port is the number listed after the rotary command, added onto 3,000, 5,000, and 7,000. The result is that if you configure the option rotary 13 on your last VTY line with alternate criteria, you can initiate a Telnet connection to ports 3013, 5013, or 7013. You will also access the alternate criteria instead of what is configured for the other VTY lines. This can be great in situations where you have to execute an autocommand, such as with lock and key ACLs. Personally, I don't like having all those ports available, so I lock down the line with an ACL such as access-list 117 permit tcp host my IP any eq 3013 and apply it with an access-class 117 on the VTY line in question. Not only does this verify that no one else will gain access, but it ensures that I can only access port 3013. (Of course, this port is based on the rotary number used.) Use this tip at your own riskit is not the way the command was intended to be used, but it works!

SSH

SSH is a secure alternative to Telnet. Instead of passing login information in clear text, SSH uses encryption to protect login names and passwords while authenticating. Since version 12.1 of IOS (only those versions that support encryption), SSH version 1 only is supported in most of the Cisco router platforms. If you remotely manage your routers, you are in a high-risk environment, and you have concerns about the security of your authentication information, consider using SSH as your Telnet replacement. To configure SSH server capabilities on your router, do the following:

1. Enter the commands hostname host and ip domain name domain, where host specifies the unique hostname of the device and domain is the domain that the device resides in.

   The host and domain name information must be entered before attempting to configure SSH. This information is required to enable key generation.

2. Our next goal is to create our RSA key with the statement crypto key generate rsa. This statement actually generates an RSA key and activates SSH. You can view generated RSA keys using the command show crypto key mypubkey rsa. You can verify that SSH is active by entering sh ip ssh.

   Tip

   Enter the crypto key generate rsa command at the global configuration command prompt. It is not part of your configuration file; therefore, it cannot be entered by editing and reloading the current configuration file.

   
   

3. We can set SSH options with the following commands:

    ip ssh time-out 50 ip ssh authentication-retries 4 

   
   

   If these options are not entered, the defaults for each are assumed.

4. Use the login local command to enable local authentication or use Authentication, Authorization, and Accounting (AAA) commands if authenticating through Remote Authentication Dial-In User Service (RADIUS) or Terminal Access Controller Access Control System (TACACS) servers.

5. Of course, we also have to include the command username name password pass, where name is the username for authentication and pass is the password of choice.

6. The transport input ssh command can be entered for the VTY lines in question. It disables Telnet remote configuration, allowing SSH to be the only connection method. (Multiple items can be listed for more than one input type.)

7. The exec-timeout x command can be applied to verify that inactive sessions will be disconnected after x minutes of no activity.

The Cisco router (IOS version 12.1[3]t and up) also includes an SSH client implementation so that other SSH-capable devices can be contacted from the router's console prompt. The command to start such a session is ssh l user 10.0.0.1, where user is the user ID you will use to connect, and 10.0.0.1 represents the SSH server device to which you are connecting. Additionally, the p option allows the use of an alternate port number, and the c option allows the preferred encryption strength to be specifiedeither Data Encryption Standard (DES), 3DES, or AES with 128-, 192-, or 256-bit key strength (for SSHv2 only).

The Console Port

Don't let the fact that the console port of your router is local lull you into a false sense of security. Even in facilities with high physical security, individuals may still be able to gain local access to your router. For this reason, all the same authentication precautions mentioned for the VTY lines using Telnet or SSH should be applied to the console port. Either add a local password with the password command, set it for local user login using the login local command, or set it for remote authentication using the login tacacs command. Finally, because the console port has a local transport, the exec-timeout statement is more important than ever. If you are configuring your router via the console port and don't properly exit before disconnecting your console cable and walking away, your session will remain active if no exec-timeout is set! When the next person plugs in to the port weeks, months, or years later (assuming there haven't been any reboots), the router will still be in whatever mode it was left in, most likely enable mode if you were in the configuration process! With exec-timeout set, reauthentication will be forced after x minutes.

TFTP and FTP

TFTP is a dangerous protocol. It has the file transfer power of FTP, but with zero security. No login or authentication is neededjust point and transfer. You can imagine that if TFTP were running on any systems on your network, you wouldn't want anyone to have outside access to it. TFTP can be run as a server on some versions of Cisco routers, although it should be disabled by default. (For more information on disabling the TFTP server on Cisco devices, see the "Disabling Servers" section later in this chapter.) TFTP can also be run as a client on all Cisco routers, enabling transfer of configuration files, IOS upgrades, and so on.

Many experienced administrators use TFTP as their administration method of choice instead of Telnet or other command-line type utilities. This brings up the greatest TFTP security concern, which is not the router, but the TFTP server where configuration files are held. A place must exist for administrators to upload and download the configuration files they edit, and these locations are a major point of concern. Many administrators use their personal station or an administration station for this purpose and only run the TFTP server while in the process of updating configurations. This is the preferred method.

Having a TFTP server running all the time with former or current configuration files and IOS updates on it is an outside attacker's dream. Those configuration files can be used as a map of your entire security structure. For this reason alone, it is imperative to block TFTP traffic coming in from the Internet. An access list to block traffic destined for a TFTP server using standard UDP port 69 would look something like this:

 router(config)#access-list 110 deny udp any any eq 69 

Of course, this wouldn't be necessary in an environment that only allows necessary traffic.

Since IOS version 12, FTP has also become available to transfer IOS and configuration information. Thankfully, FTP servers have the authentication controls that a TFTP server lacks. However, if you have administrative FTP servers running on your network, it is still advisable that you verify whether inbound FTP traffic is being blocked. Also, keep in mind that all FTP information travels in the clear, so it has the same "eavesdropping" issues that Telnet suffers from. If your router's IOS version supports encryption, it would be possible to protect your FTP sessions from eavesdropping with IPSec.

Configuration Management Tricks with TFTP and Scripts

Anyone who has configured a Cisco router via Telnet or another command-line interface has wondered, "Isn't there a better way?" Because the ordering of rules is so important to their effectiveness, reconfiguration of a long ACL via the command line is a chore of Herculean proportions. In addition, the retyping of key information for VPNs or other features that require encryption demands the utmost in accuracy. This is why many long-time Cisco administrators transfer config files to their station and use an editor to make router changes. Use the command copy run tftp and supply the details about where the TFTP server can be located. This will copy the running configuration from the Cisco device in question to your TFTP server. Then you can edit the document with an editor that handles formatting, such as WordPad in a Windows environment. (Other text editors might not be able to process the formatting, and the file will appear jumbled.) With Find and Replace, a changed IP address can be propagated throughout a complicated configuration with ease. Cut and Paste can allow the swift addition of ACL lines wherever you want them. When the process is complete, copy the saved file back to the router with the copy tftp run or copy tftp star command. If the update needs to be done without a reboot, you will need to copy to run. However, when you copy to the running configuration, commands are appended rather than overwritten, which can be messy. A better way, in environments that can afford a few minutes down time, is to copy the config to star (or the startup configuration) and then do a reload to reboot. Upon reload, the changed configuration will be loaded as typed. Watch for typing errors; with this method, you lose the error checking of the IOS until it's too late!

In environments where a reboot cannot be afforded, administrators can make scripts from copied configurations that can be pasted into the command-line interface. This way, the same speed can be afforded with Find and Replace, but without any service interruption.

Simple Network Management Protocol

Simple Network Management Protocol (SNMP) is a popular way to manage network devices (including routers), especially in large, cumbersome, complex, or geographically dispersed networks. Many different management products and systems use it. However, allowing Internet access to SNMP, despite the fact that it provides an easy way for a distant administrator to help manage the network, still opens a potential security hole that outside malicious users can exploit. If an attacker can figure out your SNMP security scheme, or if the scheme isn't properly secured, the attacker could be the person managing your network. Because we strive to avoid this, it is highly advisable that you simply block all SNMP traffic at the entrance to the network. SNMP devices may use several ports, but most typically operate on UDP ports 161 and 162. An access list to explicitly block such traffic would look like this:

 router(config)#access-list 113 deny udp any any eq 161 router(config)#access-list 113 deny udp any any eq 162 

Other SNMP-related ports that may need to be blocked in some environments are TCP ports 161, 162, 199, 391, 705, and 1993, and UDP ports 199, 391, and 1993. Of course, you would only use this access list if it were part of an existing access list that permits traffic by default. In other configurations, SNMP traffic would be most likely be blocked by an implicit deny.

The most effective way to mitigate SNMP-related risks is to disable SNMP in environments where it is not required. You can accomplish this by applying the following command in the configuration mode:

 router(config)#no snmp-server 

Note

In February 2002, vulnerabilities were discovered that left many vendors' SNMP implementations open to exploit (http://www.cert.org/advisories/CA-2002-03.html). It is imperative that your product is patched to the level required to fix these vulnerabilities, or that a workaround is implemented to prevent external access to the SNMP ports of your hosts and devices.

In Chapter 19, "Maintaining a Security Perimeter," we describe the benefits of using SNMP for monitoring the network devices on the internal network. If you want to take advantage of SNMP capabilities built in to Cisco routers, here are some suggestions on best practices for securing SNMP. If your environment allows it, implement at least SNMP version 3, which supports encryption and cryptographic authentication and is significantly more secure than its predecessors. (SNMP versions 1 and 2c, which are also supported by Cisco IOS, are limited to using community strings for authentication, and they transmit data in clear text.) If you cannot use version 3, consider implementing IPSec encryption to protect the clear-text SNMP traffic if it absolutely must travel across the Internet. When you need to resort to using plain community strings, by all means, carefully pick community string names. Don't use the universal choices of "public" and "private." The Cisco command for setting up a complex community name for SNMP version 1 reads as follows for read-only (RO) access:

 router(config)#snmp-server community complex name RO 

Substituting RO with RW (read-write) allows read-write access to the said community. It is in your best security interest to disallow read-write access from the outside network if possible. An IP access list number can be included to restrict access to certain stations by adding the number of a standard ACL to the end of the snmp-server community command, as follows:

 snmp-server community complex name RW ACL # 

The standard ACL represented by the listed number includes the IP address range of stations that are allowed to access the agent.

Note

This is an SNMPv1 command. Do not use this command in an SNMPv3 environment; otherwise, the router will think you are using SNMPv1 and disable the advantages associated with SNMPv3. For information about configuring SNMPv3 on Cisco devices, take a look at http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/_120t3/snmp3.htm.

Authentication and Passwords

When discussing the security of a managed device, it's imperative to mention authentication and passwording. In the Cisco router, each service has its own configuration options for the authentication method of choice (as mentioned in their individual sections). However, these options basically boil down to two types: remote and local authentication. Remote authentication is the preferred method, and it relies on an external RADIUS or TACACS+ server. Both RADIUS and TACACS+ are remote server methods of verifying a user's name and password credentials. To set this up for TACACS+, use the following commands.

To enable AAA from config mode, use the command

 aaa new-model 

Until this is typed in, no other aaa commands will be available. Then follow with this command:

 aaa authentication login default group tacacs+ local 

Here, default is the name of the AAA list (you can substitute a unique name here). Also, group tacacs+ tells the router to authenticate with any servers defined in the tacacs+ group, and local indicates to use the local login as a backup if the remote server should fail.

Tip

Always have a backup for your AAA authentication command, especially when you're first configuring remote authentication! It is a good practice to leave an open session to the router while configuring and testing AAA commands. Also, do not save the configuration until it has been tested. This way, you can always recover by rebooting. Otherwise, you may find yourself completely locked out of your router!

Then go to the line you want to configure remote authentication for (con, aux, vty, and so on) and type the following:

 login authentication default 

This will force the line in question to use the authentication methods defined in the AAA authentication list default.

Finally, to specify your TACACS+ server, use these commands:

 tacacs-server host 10.0.0.1 tacacs-server key THISISMYKEY 

Here, 10.0.0.1 is the IP address of your TACACS+ server and THISISMYKEY is the unique key name you are using for authentication with your TACACS+ servers. This will be the default key used for any TACACS+ server. For unique server keys, append the key keyword to the tacacs-server host command, followed by the unique key value.

The advantage of remote authentication is not having all of your "eggs in one basket." If you use local authentication, your login and password information is accessible directly in the router. Moving this information to a remote location adds to its security. Also, when you are administering a lot of devices and dozens of users, setting up all your users on new devices is as easy as configuring them for RADIUS or TACACS. Also, because all the user and password information is securely held on a remote server, the security complications of having to transport and type in local users is eliminated. One negative point of remote authentication is that if your remote authentication source is down and you have no other authentication options available, you could be kept from logging in. However, remote authentication options can allow for many types of backups for just such circumstances, including the ability to use local or no authentication.

When a business decision is made not to implement a remote authentication server, the next best option is local authentication. As mentioned previously, this is accomplished by adding the login local command to the line you want to control access to. To configure a username and password, use the username command mentioned previously in the section on SSH. It is important to use best practices to select a username and password for configuration purposes. If you do remote configuration by Telnet or SSH, a good username and password might be all that stands between your network and an attacker.

For extra protection, passwords can be set to appear as an encrypted string when listing configuration information on the router. This is accomplished with the command service password encryption. This command is simply a means to help sanitize configurations, preventing accidental exposure of passwords to "shoulder surfers." However, the encryption method employed is weak and will not protect the passwords from serious cryptographic analysis. Don't let this encryption give you a false sense of security and start leaving configuration files lying about!

Disabling Servers

Several servers can be run on most Cisco routers, and as with a PC, any running server is a point of vulnerability. Therefore, all unneeded servers should be disabled. Depending on the IOS version, these servers might be disabled by default; however, it never hurts to double-check. We already discussed the Telnet server and ways to defend it. Following are a few of the more common server programs and the commands to disable them:

• The Bootp server is a forerunner of DHCP that can be configured to hand out necessary IP information to configured clients. Bootp can be disabled with the command no ip bootp server.

• The TFTP server on supported routers is disabled with no tftp-server device-name. Here, device-name is the device that is configured to receive files.

• The HTTP server offers alternative means to manage the router via a web browser. This can be a major security concern because web traffic is much more likely to be allowed into an environment than Telnet traffic is. You can disable HTTP by using the command no ip http server.

• If the HTTP server must be used for management, authentication can be enabled (much like the login local feature of Telnet) with the command ip http authentication local.

• For additional security, ACLs can be applied to allow only specified addresses access to the HTTP server with the command ip http access-class ACL #, where ACL # refers to the standard access list that defines stations that can gain access.

• You can change the HTTP server's port address with the command ip http port port#, where port# is the port used for HTTP access, numbered 065535. Picking an unusual port number helps promote "security through obscurity," making your Cisco router's web server harder to find.

Disable Unneeded Services

One key to securing any type of device is removing any services that are not needed. These services might not serve as a direct threat, but when you're maximizing security, any window that isn't needed should be boarded up. In this section, we will take a look at some services that are not used in some environments and that can be known troublemakers.

Small Services

Small services (ports below 20 TCP and UDP) and the Time service (TCP and UDP port 37) are seldom used and are more of a liability than a value to you. The small services can be disabled with the following commands:

 router(config)#no service tcp-small-servers router(config)#no service udp-small-servers 

By typing these commands at the config prompt and saving the configuration, you will disallow small services on the router. (These services are disabled by default on IOS version 12.0 and later.) Access to these services should be blocked at your perimeter. In an environment where inbound access is allowed until explicitly denied, access to these services running on internal systems can be blocked using an ACL as follows:

 router(config)#access-list 101 deny tcp any any lt 20 router(config)#access-list 101 deny udp any any lt 20 

The Time service should also be blocked. Any time-related services should be handled by NTP (see "Configure NTP and NTP Authentication," later in this chapter). The rule of thumb in security is to block any service ports you know you don't need. It doesn't matter whether this is regarding an unpopular service, such as Time, or one as popular as FTP. If your security policy states that a service isn't used on your network, block it. In an environment where you only block traffic that you don't want, the Time service can be filtered with two extended access lists:

 router(config)#access-list 101 deny tcp any any eq 37 router(config)#access-list 101 deny udp any any eq 37 

The following line is used to apply the access lists to the interface:

 router (config-if)#ip access-group 101 in 

This is applied with the rest of the deny statements on the external router interface to the Internet.

Cisco Discovery Protocol

Another popular protocol specific to Cisco routers is the Cisco Discovery Protocol (CDP), which enables Cisco routers to discover specific details about each other. CDP can be a major security concern because detailed configuration information is propagated throughout the network. If you don't have a specific need for CDP, disable it. The command to do so by interface is router(config-if)#no cdp enable. To completely disable CDP, use router(config)#no cdp run.

Finger

Finger is a service that allows users to query a network device to discover information about other users by their email address or about currently logged-on users. Depending on the variation of Finger server, you might find out only if the user is currently logged on, or you might find more personal information, including the last time the user retrieved his mail, his telephone number, full name, address, and so on. Cisco routers specifically can give information about users who are logged in currently to the router via services such as Telnet. Most ISPs now disable Finger services for privacy reasons; we want to give out as little information as possible to prevent possible attacks. It is in your users' best interest to block the Finger service at the furthest contact point from your private network, most likely your border router. To disable the Finger server built in to the Cisco router, use the following command:

 router(config)#no service finger 

An access list to specifically block the Finger service would look like this:

 access-list 122 deny tcp any any eq 79 

It is unlikely that this access list would be used, however, because most environments only allow traffic they want.

PAD Service

The PAD service is used for Packet Assembler/Disassembler commands, which are used for connections between servers accessing the services and devices using PAD. If your Cisco configuration does not require this service, use the command no service pad.

Proxy-ARP

Cisco routers have the ability to respond to ARP requests on behalf of hosts that are shielded behind them. This proxy-ARP feature can allow hosts on routed subnets to communicate as if they are on one large, flat network. However, in a properly configured routed environment, this feature is not needed. Also, spoofing and denial of service attacks can be facilitated with proxy-ARP enabled. Therefore, it is a commonly accepted best practice to disable proxy-ARP. This is accomplished on all router interfaces by typing no ip proxy-arp.

Configure NTP and NTP Authentication

Network Time Protocol (NTP) is used to synchronize time sources on a network. You should disable access to NTP services through any interface that does not require them. Cisco includes a simple command to disable NTP on any router interface:

 router(config-if)# ntp disable 

NTP is disabled on all interfaces of Cisco routers by default. However, NTP is important from a security perspective, because it can be useful for synchronizing time sources when comparing log files from various devices and for tracking time-sensitive update information. To prevent update information from unwanted sources, authentication can be enabled that requires all updates to be "signed" with an MD5 hash. If you are using a local NTP source, verify that it is properly "hardened" and that you have these authentication mechanisms enabled. Also, if you use a remote NTP time source, be sure it is a known public source and audit that it is answering NTP requests from your hosts on a regular basis.

Note

For an updated list of publicly available time servers, check out http://ntp.isc.org/bin/view/Servers/WebHome.

Often, public time servers ask that you use a DNS name to reach them instead of an IP address, because they want the flexibility to change the IP address of the server they are using for this service. However, many routers and switches can only support an IP address. For this reason, it is a good practice to set up a local NTP server to query the public source by DNS name and then configure routers and switches to synchronize with it. Here's the command to configure a Cisco router to query an NTP time server:

 ntp server 10.0.0.1 key key# 

In this example, 10.0.0.1 would be the address of the time server. If authentication is used, the key option is specified, followed by the number of the key being used. Multiple commands can be listed for redundancy, in case one time server is down. To choose a preferred time server, add the prefer keyword to the end of the corresponding NTP server statement. You can also append the version keyword, followed by the version of NTP you are using (13) and the source keyword followed by the name of the interface you want to be the source of the NTP request.

If you want to use authentication for NTP on a Cisco router, use the following command:

 ntp authenticate 

This command enables the ability to use authentication with NTP. Then, type in this next command:

 ntp authentication-key 1 md5 thisismytestkey 

Here, 1 is the key number, md5 is the hash algorithm being used, and thisismytestkey is the value used to generate the MD5 hash.

Finally, use the following command to let the router know that the previously defined key (identified as 1) is a trusted key and should be used for future NTP transactions.

 ntp trusted-key 1 

As a final means to protect your Cisco router's NTP services, you can apply an access list to it of all its peers (servers it is allowed to communicate with):

 ntp access-group serve-only 1 

Here, 1 is the standard access list defining allowed NTP communications partners and serve-only specifically states that this ACL will only allow server access to the router's NTP service. You can also specify peer, query-only, and serve for other combinations of allowed NTP access.

Cisco TCP Keepalives Services

The Cisco TCP Keepalives services ensure that connections are properly cleared when they are idle and improperly terminated. These services guarantee that connections cannot be used by nefarious users for diabolical purposes. To enable these services, add the statements service tcp-keepalives-in and service tcp-keepalives-out to your global router configuration.

Unicast Reverse Path Forwarding

Unicast Reverse Path Forwarding (RFP) verifies that packets come from a logically sound source based on routing information stored in the Cisco router. In turn, this feature helps prevent spoofed packets from being accepted on the router. To enable Unicast RFP, use the command ip verify unicast reverse-path. This feature requires Cisco Express Forwarding (CEF) to be enabled, which uses additional resources on the router.

Internet Control Message Protocol Blocking

Internet Control Message Protocol (ICMP) is a workhorse protocol in an IP-based environment. It is responsible for generating many of the error messages and informative messages that keep the Internet working. However, many popular attacks and reconnaissance techniques are based on this protocol. In this section, we will look at some ways to protect your router from these types of attacks.

Unreachables

We will now look at the filtering of host unreachables (ICMP type 3). A router sends the "host unreachable" message when it can't find the listed host because it is down or doesn't exist. This doesn't seem like such a bad thing, but if a malicious mapper compares the unreachables and other responses from an IP address range, she can determine which of the IP addresses represent valid, running hosts. This is yet another method for the devious to map out your network before an attack. A trace of communication (using a product such as Tcpdump) between a sender and a nonexistent recipient would look like this:

 sender.com.31054 > receiver.com.23: S 3435678932:3435678932(0) win 8760 <ms 1460> (DF) router > sender.com: icmp: host receiver.com unreachable 

The trace shows an initiating Telnet packet from sender.com to a nonexistent host, receiver.com. Because the nonexistent receiver can't respond for itself (obviously!), the router (called "router" in our example) replies to sender.com with the ICMP host unreachable message.

Because of these mapping concerns, host unreachables are another traffic type that is popular to block. Cisco has the following integrated command to disable them:

 router(config-if)#no ip unreachables 

After applying this in global configuration mode, all host unreachable messages will be disabled. To test this, Telnet to an IP address that doesn't exist on your inside network while running a network trace program to see what packets are returned to you. Be sure that Telnet traffic will pass through to your inside network by altering any access lists that would deny such traffic. After the command has been applied, you shouldn't receive host unreachables. You might wonder, "If it's not returning host unreachables, what would the traffic look like?"

The answer is simply that there would be no reply. The sender would give up on its own because it didn't receive a response in the allotted amount of retries.

Disabling such informative ICMP messages from your network or from being propagated by your router has consequences. The "packet-too-big" unreachable message (a subtype of the standard ICMP unreachable) is often necessary for proper network functionality. If you can't let outside parties know that they need to fragment their information or adjust their maximum transmission unit (MTU) size to communicate with you, you might not successfully communicate.

Note

For information on excluding the packet-too-big ICMP unreachable messages (type 3 code 4) from your ICMP filtering, as well as suggestions for filtering the various ICMP types from your network, look at the "Filtering TCP and UDP Ports and ICMP Types" section of Chapter 2.

Blocking IP unreachables and other ICMP traffic types that facilitate smooth communications assumes either that you don't have any publicly accessible servers or that you do and aren't being a good Internet neighbor. If you have public servers, you might want to be a good Internet neighbor and allow certain ICMP interactions with them on your screened subnet. Apply all the ICMP filters to the router interface of the private network, protecting it, and allow chosen ICMP traffic to the screened subnet. This allows enhanced communications with outside parties who aren't familiar with your environment. Some allowed ICMP types might include outbound echo replies, time-exceeded messages, packet-too-big, administratively prohibited, and unreachables. Inbound, you might want to allow echo requests (perhaps just to a few particular servers' IP addresses). Your security policy and your ISP will decide the types you allow.

Most of these traffic types are security concerns because of an outsider's ability to map your network. This isn't as great of a concern on a publicly accessible segment. Echo replies and requests are of the most concern (due to exploits and covert channel concerns), but with properly patched, configured, and hardened servers, they shouldn't be a problem either. The proper logging of said traffic types is advised to verify that the traffic in question is not of a malicious nature. For more information on the logging and examination of malicious traffic, check out Chapter 8, "Network Intrusion Detection," and Chapter 20, "Network Log Analysis."

Directed Broadcasts

One command that is useful when securing Cisco routers against popular ICMP-based attacks is router(config-if)#no ip directed-broadcast.

This command disallows traffic to broadcast addresses, preventing amplification of Smurf-like attacks, where one echo request can generate hundreds of responses. For this reason, it is best to execute this command on all router interfaces on your network. As of IOS version 12.0, directed broadcasts are disabled by default. Although this command is popularly mentioned as a means to deter Smurf attacks that use the ICMP protocol, it is also effective against broadcast attacks using UDP, TCP, and IP.

Smurf Attacks

Smurfing is a type of denial of service attack that makes use of the broadcast behavior of IP networks. It is called smurfing because one of the first programs to implement the attack was named Smurf. The attack works by sending a series of spoofed ICMP echo packets to the broadcast address of a network. The attacker hopes that all the hosts on the network will send ICMP echo replies to the spoofed address. If the network segment is large, the attacker might be able to evoke hundreds of echo reply packets generated for every echo packet he sends. This allows the attacker to magnify the bandwidth of the attack, making it possible for a dial-up attacker connected at 56Kbps to bring down sites connected using a T1 line (1.544Mbps).

Redirects

Another popularly implemented Cisco ICMP type command is router(config-if)#no ip redirects.

This command is often used in conjunction with antispoofing access lists and is applied to any router interface from which malicious traffic can enter your network. It is a means by which a nefarious user could manipulate the path of return traffic, and it should be disabled.

Spoofing and Source Routing

As introduced in Chapter 2, source routing and spoofing can be an effective and hazardous combination. This is why it is so important to apply ingress filters and disable source routing. As mentioned previously, the command to disable source routing on Cisco routers is router(config)#no ip source-route.

For a review of ingress filtering and source routing, refer to Chapter 2.

Router Logging

Logging is an important feature of any firewall, especially one with a secured subnet. A router doesn't have much space onboard for logs, however. In addition, logging takes up extra resources on a possibly already taxed component of your network. Other logging solutions could involve installing an IDS or some other type of sniffer on your network to monitor and log the type of traffic roaming about on your network segments. (A sniffer is a device that captures detailed packet information.) If you do a lot of logging on your router (with the log option appended to your access lists), you can set up or use an existing Syslog server on your network and redirect the log files to it. This way, you don't run into the space limitations of a router's onboard memory, and if you have more than one router, you can have all the routers' logs sent to one centralized location.

POSTED: No TrespassingThe Importance of Banners

When configuring a router, it is possible to configure a banner that will be displayed at the logon prompt when a user first accesses the router. The command to create such a login banner is router(config)#banner login,_scary approved message,.

The commas in this command represent some (any) delimiter, and "scary approved message" represents a login message that your business has chosen to most effectively ward off evildoers. Posting a warning doesn't guarantee that if a bad person elects to trespass on your virtual property you will be able to capture and convict him, but it can help improve the chances and help demonstrate the interloper's intent. More than one electronic trespasser has escaped conviction with the claim "I didn't know I wasn't supposed to be there." It is a good idea to get counsel familiar with your area's legal specifics to help choose the wording for your banner to maximize its effectiveness. Don't include information about your site or its equipment because this can all be used against you.

Remember that a banner can work against you as well. Using a banner that reads "Top-Secret Government SiteDO NOT ENTER!" is just asking for trouble. Something along these lines might be preferable: "ALL ACTIVITY ON THIS DEVICE IS MONITORED AND WILL BE USED AS EVIDENCE IN THE EVENT OF PROSECUTION." Gives you a funny feeling, doesn't it? Again, the banner might have to be tweaked for your environment and local laws, but it does three things:

• It keeps your site completely anonymous.

• It lets trespassers know (without threats) that they are being watched.

• It states up front that the owner of this device will prosecute people who shouldn't be there.

The end result is that it makes the visitor think twice, and if bad things happen, it is a strong indicator of an attacker's intent.

To configure a Cisco router to perform logging, make sure it is currently enabled with the command router(config)#logging on.

To send logging information to a local Syslog server, use the command router (config)#logging ip address, where ip address represents the IP address for the Syslog server in question.

After logging is successfully configured, the router sends its logging information to the Syslog server based on the "trap" level you configured. This is set using the command router(config)# logging trap information level, where information level is the informational level of the messages that will be sent to the Syslog server. (This command sends all messages of the listed level and lower.) The default level of the trap command is informational, which includes all message types except debugging information (which is generated by the Cisco debug commands). To log this information as well, change the trap level to debugging.

Tip

Keep in mind that the debug commands can generate quite a lot of information and can fill up log servers quickly.

After logging is properly configured, messages like this one should magically appear on your Syslog server:

[View full width]
 138: 1d06h: %SEC-6-IPACCESSLOGP: list 112 permitted tcp 10.0.0.3(4766) -> 192.168.219.25 (80), 5 packets 

The message is an example of a standard Cisco log entry as generated by an access list, including the log keyword (access-list 112 to be exact). The ACL was a permit rule, so this is reported as matching the permit and is allowed to pass. Most of the rest of the entry is pretty intuitiveaddress, port source, and destinationexcept the cryptic Cisco labeling mechanisms. For more information on log files, take a look at Chapter 20.

For readability of log files and for sanity between multiple devices, it is a best practice to force all routers to use the same time zone or, if your company crosses more than one time zone, to use Greenwich Mean Time (GMT) as your standard. To do this on a Cisco router, use the following command:

 enable clock timezone GMT 0 

Here, GMT is a label for the time zone you are configuring and 0 is the offset from GMT.

Automatic Securing and Auditing of Cisco Routers

Due to the complexities of securing a Cisco router, several automated methods have been established to help ease the burden on network professionals when auditing and hardening router configurations. The two we will discuss in this section are Cisco's Auto Secure and the Router Audit Tool (RAT).

Securing Your Router with Cisco's Auto Secure Feature

As of IOS version 12.3(1), administrators can take advantage of a new security tool for Cisco routers. Cisco's Auto Secure option allows the automated securing of Cisco routers using best practices. It adds ingress filters and disables commonly exploited services while enabling security enhancements, all with little input from the end user. The syntax of the command is as follows:

 auto secure 

This command is typed in enable mode (not config mode) and will offer prompts to the end user. First, it will ask if the router is connected to the Internet. If the answer is yes, it will ask questions to determine the interfaces facing the Internet and apply ingress filters to them blocking IANA reserved addresses and RFC 1918 addresses.

Next, it will go on to disable Finger, service PAD, UDP and TCP small servers, CDP protocol, Bootp server, HTTP server, source routing, and gratuitous ARP. It will enable password encryption, tcp-keepalives-in, and tcp-keepalives-out.

It then asks if SNMP is used to manage the router. If the end user answers yes, it deletes the default RO and RW community strings and suggests the use of SNMPv3. If the end user answers no, it disables SNMP.

Then the command prompts the user with a sample banner and asks him to input a banner of his own. It then checks the enable password and forces it to be configured if it doesn't exist or if it is of insufficient length.

The command then configures local AAA authentication and applies local authentication, exec-timeout, and transport options for all available con, vty, and aux lines. It disables IP redirects, IP proxy ARP, IP unreachables, IP directed broadcasts, and IP mask replies on all interfaces. It enables Cisco Express Forwarding and enables Unicast RFP on all interfaces connected to the Internet. To see an example of a configuration created by Auto Secure, check out Appendix A, "Cisco Access List Sample Configurations."

Cisco Auto Secure, though no substitute for a security professional, is a great step in the right direction for Cisco router security.

Auditing Your Router with the Router Audit Tool (RAT)

The Router Audit Tool (RAT) is a freeware command-line program available from The Center for Internet Security at www.cisecurity.com. As its name implies, RAT allows the automated auditing of your Cisco router configurations (and more recently PIX configurations) for common security issues. It runs from a computer's command prompt and is available for both Windows and UNIX platforms. After installing RAT, you will need to load a copy of the Cisco router configuration you want to audit on to the station where you installed RAT. This can be accomplished by loading a TFTP server on your RAT station and issuing the command copy running-config tftp from the Cisco router. You will be prompted for the communication information of your TFTP server. After transferring the file to the download directory of your TFTP server software, you will need to move the configuration file to the RAT/bin directory. Then, simply go to a command prompt and run the following command from the RAT/bin directory:

 RAT router-config 

Here, router-config is the name of the router configuration file you copied to your host. RAT will go through and check your configuration against a plethora of security best practices, much like Auto Secure. However, the end result is not an updated router configuration, but instead a report in HTML format that documents all the security tests your router configuration has failed and why they are issues. Next, the report includes a rating of your router's security and a script (that will need some minor editing for your particular IP address information) to correct the vulnerabilities it has found. This script, once adjusted for your environment, can simply be pasted into the command-line interface of the Cisco router from which it was downloaded. Though there may be a few minor false positives and some user input required, RAT offers many more security tests than Cisco Auto Secure and produces a friendly audit report that helps educate the user. The Router Audit Tool is a powerful program to add to your security arsenal.