Disabling Interface Services
Now that you have disabled all global services that are insecure or that are not necessary, you are ready to proceed to disabling unnecessary or undesirable services on your router's interfaces. This section covers the basics about disabling insecure services on your router's interfaces.
CAUTION
Subinterfaces, loopback interfaces, and null interfaces are considered physical interfaces on the router, so a lot of the things I discuss here also should be done on these interfaces. It is better to be safe than really sorry.
CDP on Insecure Interfaces
As I mentioned at the beginning of this chapter, CDP typically is used as a troubleshooting tool. However, a hacker can use this information in a reconnaissance attack to learn more information about your router. Therefore, if you do not globally disable CDP, you at least should disable CDP on insecure interfaces. Insecure interfaces are basically any interface that is not connected to your internal network:
An insecure interface is connected to a public network, such as the Internet
It is connected to a different private network (some other company).
It is connected to a private WAN to a remote office.
To disable CDP on an interface, use the following configuration:
Router(config)# interface type [slot_#/]port_# Router(config-if)# no cdp enable
After you have disabled CDP on your router's interface(s), you can verify it by using the show cdp interface command. You should not see the disabled interfaces in the output of this command.
Proxy ARP
IP devices use the Address Resolution Protocol (ARP) to resolve Layer 3 addresses to Layer 2 (MAC) addresses. This allows devices to communicate with each other at Layer 2, like Ethernet. Typically, ARP is used to help devices communicate with each other on the same segment, subnet, or broadcast domain (virtual LAN, or VLAN).
Cisco routers can function as a proxy, giving a requesting device a MAC address of the router. This typically happens when the device is confused about the destination. The device thinks that the destination is on the same segment, but, in reality, the device is in a different subnet. Figure 4-2 illustrates how proxy ARP works, as defined in RFC 1027.
Figure 4-2. Proxy ARP Example
In this example, the network administrator is breaking up a Class C segment (192.168.1.0/24) into two physically separate segments: 192.168.1.0/25 and 192.168.1.128/25. You will notice that the router has been configured correctly for both of these subnets. However, you now have an addressing issue for User A and User B. Both of these devices assume that they are on the same physical segment because of their subnet mask: /24. As an example, if User A wants to get to 192.168.1.129, it assumes that this address is on the same segment and performs an ARP for 192.168.1.129. Obviously, the destination is not on the same segment, so User B cannot respond with a reply. Two solutions exist for this problem:
Readdress the clients with the correct addressing information (good solution).
Have the router use proxy ARP (not a very good solution).
Of course, readdressing the network might not be a simple task, so the administrator in this example decided to have the router use proxy ARP. With proxy ARP, the router responds on behalf of User B; however, instead of sending User B's MAC address to User A, it sends its own address: 0000.0C00.DDDD. User A then encapsulates its IP packet with a source of 192.168.1.1 and a destination of 192.168.1.129 in a frame with a destination MAC address of the router. When the router receives the frame, it processes it because it matches its NIC's MAC address; then it examines its routing table and routes the packet correctly. Basically, proxy ARP is a poor man's version of routing: It allows devices to talk to each other across subnet boundaries.
Given the example in Figure 4-2, however, there are problems with using proxy ARP. Assume that you have gone through and readdressed the network correctly, as shown in Figure 4-3. The administrator has set up filtering to allow traffic between the two 192.168.1.0/24 subnets, but to deny other types of traffic. An ingenious hacker has found out that the interface on the router that he is connected to supports proxy ARP. The hacker wants to execute a DoS attack against User B. The hacker takes advantage of proxy ARP by configuring an address from 192.168.1.0/25 (192.168.1.77) and pings User B. With proxy ARP enabled, the router responds with its own MAC address. The hacker then executes his DoS attack by flooding User B. The router's filtering rules allow this traffic and forward it to User B. Assuming that these were ICMP messages, User B attempts to respond by sending them to 192.168.1.77. The router receives the responses, looks at its routing table, and determines that the packets need to go to the segment where User A is. The router does one of two things at this point: either sends the responses back to the hacker (not likely because the routing information points to a different interface), or uses ARP to get the MAC address of 192.168.1.77 on User A's segment, does not get a response, and responds to each ICMP message to User B with a host unreachable message.
Figure 4-3. Proxy ARP Hacking Example
By default, Cisco routers perform proxy ARP on all their interfaces with IP addresses configured on them. I can understand why Cisco initially did this 10 years ago in the infancy of networking with TCP/IP, but this makes no sense today. Therefore, I highly recommend that you disable proxy ARP on your router's interfaces. Use the following command to do this:
Router(config)# interface type [slot_#/]port_# Router(config-if)# no ip proxy-arp
NOTE
There is one instance where you do not want to disable proxy ARP: when your router is terminating IPSec remote access VPN connections. In this instance, the router will have to respond to a local ARP from a local device when the local device wants to access the remote access client across the VPN connection. In this instance, leave proxy ARP enabled on the router's internal interface(s).
Remember to repeat the no ip proxy-arp command on each interface. To verify your configuration, use the show ip interface command. In Example 4-14, proxy ARP has been disabled on the router's fastethernet0 interface.
Example 4-14. Verifying That Proxy ARP Is Disabled
Router# show ip interface FastEthernet0 is up, line protocol is up Internet address is 192.168.1.254/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is disabled <--output omitted-->
Directed Broadcasts
A directed broadcast is a broadcast specific to a network. Each network or subnet has three types of addresses: a network number, host addresses, and a broadcast address, called a directed broadcast. Unlike local broadcasts, directed broadcasts are routable. Some old DoS attacks used this by flooding a specific network or subnet with directed broadcasts, typically in a spoofing attack in which the hacker replaced his own IP address with one of the devices in the subnet in the source address field of the packet header. The Smurf attack does this through the use of ICMP packets.
No application really uses the directed broadcast function, so it is highly recommended that you prevent the router from forwarding directed broadcasts by configuring the following on its interfaces:
Router(config)# interface type [slot_#/]port_# Router(config-if)# no ip directed-broadcast
Remember to repeat the no ip directed-broadcast command on each interface. To verify your configuration, use the show ip interface command. In Example 4-15, directed broadcasts have been disabled on the router's fastethernet0 interface.
Example 4-15. Verifying that Forwarding of Directed Broadcasts Is Disabled
Router# show ip interface FastEthernet0 is up, line protocol is up Internet address is 192.168.1.254/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled <--output omitted-->
ICMP Messages
A hacker can use three types of ICMP messages to create either a DoS attack or a reconnaissance attack:
ICMP unreachables
ICMP redirects
ICMP mask replies
The following three sections discuss how these ICMP messages are used, how a hacker can exploit them, and how you can disable them on your routers' interfaces.
ICMP Unreachables
By default, if a Cisco router receives a nonbroadcast packet to itself with an unknown protocol, or if the router receives a packet that the router cannot forward to its destination because the host or network is not reachable, the router automatically generates an ICMP unreachable message. A hacker can use this information in two ways:
This information tells the hacker what is not reachable in the network.
The hacker can use a DoS attack to cause the router to respond to the ICMP unreachable messages. An intelligent hacker changes the source address in the packet to a destination that it wants to attack. This is a form of the Smurf attack.
To prevent the router from responding with ICMP unreachable messages, use this configuration on each of your router's interfaces:
Router(config)# interface type [slot_#/]port_# Router(config-if)# no ip unreachable
Remember to repeat the no ip unreachable command on each interface. To verify your configuration, use the show ip interface command. In Example 4-16, ICMP unreachables have been disabled on the router's fastethernet0 interface.
Example 4-16. Verifying that ICMP Unreachables Is Disabled
Router# show ip interface fastethernet0 FastEthernet0 is up, line protocol is up Internet address is 192.168.1.254/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are never sent ICMP unreachables are never sent ICMP mask replies are never sent <--output omitted-->
ICMP Redirects
ICMP redirects are used to help devices intelligently find a destination. The example shown in Figure 4-4 illustrates how ICMP redirects work. In this example, User A is using Router A as a default gateway. All of User A's traffic leaving the subnet is forwarded to Router A. User A then sends some traffic to User B. When Router A receives the traffic, it realizes that Router B, on the same segment, actually has a better path. Router A thus sends an ICMP redirect message to User A, basically telling User A that Router B should be used for this particular destination. Basically, Router A is sharing routing information with User A. User A then uses Router B to reach User B.
Figure 4-4. ICMP Redirect Hacking Example
However, hackers can take advantage of this process by corrupting a device's routing table, creating a DoS attack. For example, assume that the hacker in Figure 4-4 sends ICMP redirect messages to User A concerning User B's network. In the hacker's packet, the hacker gives an imaginary router address?say, Router D?to User A. When User A tries to send traffic to User B, it forwards its traffic to Router D, the imaginary router, thus preventing the traffic from reaching User B. A more intelligent hacker would have User A forward traffic to Router C, where the hacker is connected. Of course, for Router C to forward that traffic to the hacker's PC, the hacker first would have to corrupt Router C's routing table in a routing attack.
Headaches with ICMP RedirectsAbout 7 years ago, I was working with a customer that was the victim of an ICMP redirect hacking attack. It actually took me a handful of days to figure out what the problem was. A few of the file servers were being sent redirect messages that pointed to invalid next-hop addresses. It was weird because sometimes things worked, and sometimes they did not. This is because of how ICMP redirects were incorporated into the file servers: Every 30 minutes, the file servers verified the reachability of the routers that they knew about. So when the attack took place, the file servers lost connectivity to certain locations; then, 30 minutes later, everything worked. The attacker repeated this process every so often, but not often enough for me to catch the problem right away. It took long hours of looking at packets with a protocol analyzer to pinpoint the culprit. |
Cisco routers can prevent the router from generating ICMP redirect messages. To prevent the router from generating ICMP redirect messages, use this configuration on each of your router's interfaces:
Router(config)# interface type [slot_#/]port_# Router(config-if)# no ip redirect
Remember to repeat the no ip redirect command on each interface. To verify your configuration, use the show ip interface command. In Example 4-17, ICMP redirects have been disabled on the router's fastethernet0 interface.
Example 4-17. Verifying that ICMP Redirects Are Disabled
Router# show ip interface FastEthernet0 is up, line protocol is up Internet address is 192.168.1.254/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are never sent ICMP unreachables are never sent ICMP mask replies are never sent <--output omitted-->
ICMP Mask Replies
ICMP supports a mask request message that allows devices on a segment to learn about what the subnet mask is for the segment if this has not been configured on them. Any device, including a router, can generate an ICMP mask reply message. Hackers can use this for two purposes:
First, it tells the hacker what the range of addresses are on the subnet.
Second, it tells the hacker the directed broadcast for the subnet, which allows the hacker to use a DoS directed broadcast attack using a modified form of Smurf.
In some cases, the hacker can learn the identity of the device, such as what operating system it is running, with ICMP mask reply messages. For example, Sun systems respond to a mask reply that is fragmented across two ICMP packets. If a hacker gets a reply to this request, he has just found a Sun device and can start using his Sun hacking tools to exploit holes in the SunOS/Solaris operating system of this device.
ICMP mask requests and replies were meant for a local segment and should not be forwarded to other segments. Firewalls should filter them, and routers should ignore these requests; in today's world, every device on the segment either is hard-coded with a subnet mask or learns it through DHCP. To prevent the router from sending ICMP mask reply messages, use this configuration on each of your router's interfaces:
Router(config)# interface type [slot_#/]port_# Router(config-if)# no ip mask-reply
Remember to repeat the no ip mask-reply command on each interface. To verify your configuration, use the show ip interface command. In Example 4-18, ICMP mask replies have been disabled on the router's fastethernet0 interface.
Example 4-18. Verifying that ICMP Mask Reply Messages Are Disabled
Router# show ip interface FastEthernet0 is up, line protocol is up Internet address is 192.168.1.254/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are never sent ICMP unreachables are never sent ICMP mask replies are never sent <--output omitted-->
Maintenance Operation Protocol
The Maintenance Operation Protocol (MOP), popular in older Digital Equipment Corporation (DEC) equipment, is used for maintenance services such as these:
Uploading or downloading of system software
Remote testing
Problem troubleshooting
Cisco routers can use this to load a Cisco IOS image from a MOP server, assuming that MOP is enabled. This process is a carryover from more than a decade ago, but many routers still have MOP enabled, by default, on their interfaces. To prevent a DoS MOP attack from occurring, disable MOP on your interfaces:
Router(config)# interface type [slot_#/]port_# Router(config-if)# no mop enable
Remember to repeat the no mop enable command on each interface.
VTYs
Even though VTYs are not interfaces, this is an appropriate place to discuss them. By default, VTYs allow all types of remote access, such as Telnet, SSH, and others. For your VTYs, you will want to restrict access to your VTYs to only Telnet (not recommended) and SSH (recommended). To restrict the router's VTYs to only Telnet access, use this configuration:
Router(config)# line vty 0 4 Router(config-line)# transport input telnet Router(config-line)# transport output telnet
To restrict the router's VTYs to only SSH access (I recommend this approach over the previous one), use this configuration:
Router(config)# line vty 0 4 Router(config-line)# transport input ssh Router(config-line)# transport output ssh
The transport command restricts VTY access into and out of the router. By specifying one particular access method, such as SSH, you are preventing anyone else from using another method. Therefore, if you want to let remote administrators use only SSH (but not Telnet), use the previous configuration. Use the show line vty command to verify your configuration, as shown in Example 4-19.
Example 4-19. Verifying the Configuration of the Router's VTYs
Bullmastiff# show line vty 0 Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 6 VTY - - - - - 2 0 0/0 - Line 6, Location: "", Type: "" Length: 24 lines, Width: 80 columns Baud rate (TX/RX) is 9600/9600 <--output omitted--> DNS resolution in show commands is enabled Full user help is disabled Allowed input transports are ssh. Allowed output transports are ssh. Preferred transport is telnet. No output characters are padded No special data dispatching characters Bullmastiff# Bullmastiff# telnet 192.168.1.254 Trying 192.168.1.254 ... % Connection refused by remote host Bullmastiff# ssh -l richard 192.168.1.254 Password: cisco Bullmastiff#
Notice in Example 4-19 that only SSH connections are allowed. I then tested this by trying to Telnet to the router itself, which was refused. I then used SSH to access the router and was successful.
You will want to put one more security measure in place, to ensure that a DoS attack against your VTYs does not tie them up and prevent remote access by a valid administrator. The following two commands help somewhat with this process:
Router(config)# service tcp-keepalives-in Router(config)# service tcp-keepalives-out
With these two commands, the router monitors network TCP connections to and from the router by generating keepalives for connections such as Telnet and SSH. The advantage that these commands provide is that if a Telnet connection is abnormally aborted, for instance, the keepalive function detects this and removes the bad connection, allowing other devices to use the VTY line. This feature is disabled by default, and I recommend that you enable it.
Unused Interfaces
As a last precaution, disabling unused interfaces creates a more secure environment than when leaving them up and opening them to hacking attempts. You should use the shutdown command on all interfaces that you are not currently using, like this:
Router(config)# interface type [slot_#/]port_# Router(config-if)# shutdown
Remember to repeat the shutdown command on each interface that you are not using. To verify your configuration, use the show ip interface brief command. In Example 4-20, ethernet0 has been disabled manually.
Example 4-20. Verifying that Unused Interfaces Are Disabled
Router# show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 unassigned YES NVRAM administratively down down FastEthernet0 192.168.1.254 YES NVRAM up up
