Recommended Minimum IOS Security Settings

This section deals with the basic minimum configurations that all enterprises should employ on their routers. Although some of the commands explained in this section are disabled by default, the administrator is urged to deny specifically those services and routes that are not needed. The following topics are covered:

• Denying RFC 1918 routes

• UDP and TCP servers

• Finger service

• IP unreachables

• ICMP Redirect messages

• Directed broadcasts

• Proxy Address Resolution Protocol (ARP)

• IP Unicast

• IP source routing

Denying RFC 1918 Routes

All border routers within a company that is concerned with security should have some specific routes denied. RFC 1918 defines the ranges of IP addresses available for use on the Internet, as well as those considered private. A private IP address should not be used on the Internet. The source or destination addresses of all packets on the Internet should not be within these private ranges. Common attack methods rely on private addresses to hide the true source of the attack. This section shows a typical method of blocking access from these forms of attack. With the exception of Network Address Translation (NAT), no one from the Internet or from within your own network should be sending packets from any of the addresses in the following list. The following is a sample ACL that will be applied to routing updates to prohibit the private address spaces as defined by RFC 1918:

access-list 191 deny ip host 0.0.0.0 any
!This prevents packets with a source address of 0.0.0.0
!from traversing the network
access-list 191 deny ip any host 0.0.0.0
access-list 191 deny ip 10.0.0.0 0.255.255.255 any
!10.0.0.0 through 10.255.255.255 is a non-routable address range
!and should not traverse the network from the Internet.
access-list 191 deny ip 127.0.0.0 0.255.255.255 any
!127.0.0.0 through 127.255.255.255 addresses are used for loopback testing
!and should never traverse the Internet.
access-list 191 deny ip 169.254.0.0 0.0.255.255 any
!169.254.0.0 is reserved by Microsoft as the address given to a host
!unsuccessfully attempting to use DHCP services.
access-list 191 deny ip 172.16.0.0 0.15.255.255 any
!172.16.0.0 through 172.31.255.255 are non-routable addresses.
access-list 191 deny ip 192.168.0.0 0.0.255.255 any
!192.168.0.0 through 192.168.255.255 are non-routable addresses
!and should never be traveling over the Internet.
access-list 191 deny ip 224.0.0.0 31.255.255.255 224.0.0.0 31.255.255.255
!224.0.0.0 through 255.255.255.255 as a source address is invalid
!because these are reserved for multicast broadcasts.
!Here, you are stopping these packets from traversing the network if the
!destination is a multicast and the source is a multicast.
!A correctly formed multicast packet will have a valid source address
!with a multicast destination address between 224.0.0.0 and 255.255.255.255.
access-list 191 deny ip any 255.255.255.0 0.0.0.255
!Packets should not be sent to the 255.255.255.0 network,
!because this is a reserved network.
access-list 191 permit ip any any
!You need to allow traffic that is not specifically blocked
!through the router.
deny any any
!The deny any any line is shown for clarity.
!This line is implied by all access lists.
!Any packets that are not specifically allowed are denied.

This access list should be applied to both the inbound and outbound interfaces of border routers. If you are running NAT services, some of these interfaces will not necessarily apply. For example, if you are using the 10.0.0.0 network inside your organization, you will need to allow this network to travel to the device providing NAT services. Additionally, on the inbound interface of all border routers, the internal network addresses should be specifically denied. The preceding list is a minimum list that is designed to prevent commonly spoofed IP addresses from being allowed to traverse your network. If other routes are known to be invalid, they should also be prohibited. Besides specifically preventing packets with a source address matching your internal network from entering through the Internet, administrators should consider ways in which they can prohibit unauthorized external network addresses from traversing to the outside of the network. This will help prevent someone from using the network to launch an attack on a third party.

As with all access lists, these might cause excessive CPU usage on routers. However, the additional CPU usage is usually justified by the added security provided by the access lists. If your router is unable to effectively function with the preceding access lists, chances are that the router is already overworked and should be upgraded.

User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) Servers

The User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) servers are generally those with port numbers below 10. These typically include echo ports and discard ports. Echo ports replay the packet (echo) out of the port received. Discard throws away the packet. Because either throwing away or echoing packets consumes CPU cycles, they are commonly used in denial of service (DoS) attacks. When too many packets requesting echoes overload a router, for example, the router must delay other processes. This delay can cause problems, such as an inability to process routing updates. Therefore, both of these should be disabled unless there is a specific reason to run them. This is especially important on the router directly connected to the Internet. These can be disabled as follows:

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

Finger Service

The finger service can be used to resolve usernames on remote systems. Specifically, finger was designed to show active users on a system. Although the prevalence of finger has been reduced in the last few years, several administrators still allow finger requests to traverse their networks. Because of the many known ways that finger can be abused, no router should ever run finger unless there is a very specific reason to do so. An administrator can (and should) stop finger services with the following command:

no service finger

IP Unreachables

By default, when a router receives a nonbroadcast packet with an unrecognized protocol whose destination address belongs to that router, it will send an Internet Control Message Protocol (ICMP) Protocol Unreachable message back toward the source. A router will also send back an ICMP Host Unreachable message if it receives a packet whose destination address is not known. This is illustrated in Figure 2-8.

Although this behavior might seem reasonable, it also opens the router to vulnerability from ICMP DoS attacks. If a router spends all of its time responding to ICMP messages, something else is not being processed. Additionally, disabling ICMP unreachables might help out the innocent victim of a DoS attack.

A DoS attack can occur in many ways. Here is just one scenario: When sending an ICMP echo request, the perpetrator changes the originating IP address on the packet to a legitimate IP address of the victim. The perpetrator sends numerous ICMP requests to the network broadcast address of the bystander. The bystander, who is unaware of what is occurring, responds to these ICMP requests. The response is sent to the IP address within the original request. If the source address is valid, some router will start receiving these responses. Take a moment to look at Figure 2-9.

In this case, the ICMP requests were sent to the broadcast network address on the bystander's network. Each host on the network received the request and responded. This means that the bystander amplified the power of the effectiveness of the requests by the number of hosts responding. Very quickly, the bystander's available bandwidth will be used by ICMP messages. The victim's bandwidth will also be used by these ICMP messages. In effect, both the victim and the bystander lose all effective communication capabilities. It becomes very hard to tell exactly who the intended victim is in this case. If the perpetrator sends out requests to more than one bystander at a time, the effect can be devastating to the victim.

It is recommended that all external interfaces be configured not to respond in this manner. Preventing a router from sending out ICMP Host and Protocol Unreachable messages is easily accomplished with the following interface command:

no ip unreachable

ICMP Redirect Messages

Under certain circumstances, routes might not be optimal. Although most of these cases can be prevented by proper configuration, it is usually prudent for the administrator to ensure that routers do not send packets out the same interface over which they have been received. When a packet is sent back out the interface on which it was received, an ICMP Redirect message is also sent. This is illustrated in Figure 2-10.

The ICMP Redirect message tells the sender of the original packet to remove the route and substitute a specified device that has a more direct route. This feature is enabled by default, but it becomes disabled when the Hot Standby Router Protocol (HSRP) is in use on the particular interface.

Because you should be concerned about any ICMP messages leaving your network, you should manually disable this feature. Instead of using your bandwidth to inform other, usually unknown routers where a network exists, you should reserve your bandwidth for your own purposes. This is especially important on external interfaces where large amounts of these ICMP messages might be a form of DoS attack. Figure 2-10 gives an example of how ICMP Redirect works. To manually disable this behavior, use the following interface command:

no ip redirects

Directed Broadcasts

It is possible within the IP protocols to send a directed broadcast, which is when a packet that is received contains a request to translate the broadcast packet to another interface on the device, usually the LAN interface. If this is left enabled, the LAN might experience excessive broadcasts from a DoS attack. The default on IOS 12.0 and later is to have directed broadcasts disabled. However, the administrator should still specifically disable it with the following command:

no ip directed-broadcast

Proxy Address Resolution Protocol (ARP)

Proxy Address Resolution Protocol (ARP) is a system where one device answers an ARP request destined for another device if that MAC address is known. When a proxy ARP device sees an ARP request for a device on a different known Layer 3 network, the proxy ARP device will reply to the ARP and forward the request to the remote LAN segment. This is usually done so that ARP requests will not have to travel over a relatively slow link. The problem with using proxy ARP is that it can expose the network to potential security problems. One way of exploiting the security hole caused by proxy ARP is to launch a DoS attack that uses bandwidth and router resources responding to repeated ARP requests. Figure 2-11 illustrates this attack.

Proxy ARP can be disabled with the global command:

no ip proxy-arp

IP Verify

The ip verify unicast reverse-path command is useful in preventing address-spoofing attacks on systems running Cisco Express Forwarding (CEF) and IOS version 12.0 and higher. While running CEF with this interface level command, all packets are evaluated for the source address. If the source IP address does not have a CEF route in the table corresponding to the interface on which the packet was received, that packet is dropped. The result of this configuration is that attacks depending on address spoofing and received on an interface other than the expected interface are automatically dropped. Because most IP spoofing packets do not come over the expected interface (or subinterface), another layer of protection is added.

CEF must be turned on for the router. However, there is no requirement that CEF must be turned on for the specific interface or subinterface where the filtering is used. The following will start packet filtering on an interface:

ip verify unicast reverse-path

IP Source Routing

The Cisco IOS is designed to examine the options within the header of every IP packet. According to RFC 791, these options can include Loose Source Route, Record Route, or Time Stamp. When the IOS receives a packet with one of these options enabled, it responds appropriately. If the packet contains an invalid option, the router sends an ICMP parameter problem message to the source and discards the packet. If the packet contains the source route option, it is interpreted to mean that the packet is requesting a specific route through the network. Although the default is to use source routing, ISPs usually do not want the customer deciding how to route through the network. Also, IP source routing has a number of known security problems. The main security problem is that a remote entity controls where data travels, meaning that it is possible for data to travel through a hacker's network before going on to its ultimate destination. The hacker is able to record all data intended for another network. Figure 2-12 shows an example.

IP source routing can be disabled with the following command:

no ip source-route