Hardening Router Technologies

Now that you have performed the fundamental device-hardening measures, the next step is to harden router-specific technologies. The four primary tasks to undertake in hardening your router technologies are as follows :

• Implementing redundancy

• Hardening routing protocols

• Implementing traffic management

• Implementing IPsec

Implementing Redundancy

One of the most important things you can do to provide infrastructure security is to provide redundancy of critical devices. This ensures that if one device fails, the redundant device can transparently fill the void left behind.

Cisco uses Hot Standby Routing Protocol (HSRP) to provide device redundancy between two or more routers. HSRP functions by using a virtual IP address and MAC address that are shared between the routers, although only one router can be using the virtual addresses at any given time. If the router that owns the virtual addresses fails for any reason, the backup router will assume the role of responding on the virtual addresses. For end clients , the entire process is transparent because they are assigned the virtual IP address for their default gateway. In most cases, any service interruption lasts less than ten seconds.

HSRP configuration has two primary steps. First, you must configure HSRP on the primary router. Second, you must configure HSRP on the secondary router. To prevent HSRP spoofing or hijacking, you should also implement authentication. Once you implement authentication, the router will only participate in using HSRP with other routers that provide the correct authentication string (the string uses an MD5 hash for security).

To configure the primary router, enter the following commands at the interface configuration mode for the interface on which you want to enable HSRP:

 local-rtr(config-if)#interface Ethernet0 local-rtr(config-if)#ip address 192.168.1.1 255.255.255.0 local-rtr(config-if)#standby priority 200 preempt local-rtr(config-if)#standby preempt local-rtr(config-if)#standby ip 192.168.1.3 local-rtr(config-if)#standby authentication <authstring> 

To configure the backup router, enter the following commands at the interface configuration mode for the interface on which you want to enable HSRP:

 remote-rtr(config-if)#interface Ethernet0 remote-rtr(config-if)#ip address 192.168.1.2 255.255.255.0 remote-rtr(config-if)#standby priority 101 remote-rtr(config-if)#standby ip 192.168.1.3 

In this example, all clients use 192.168.1.3 as their default gateway. If, for some reason, the primary router fails, the secondary router will take over. As soon as the primary router is brought back online, it will preempt the secondary router and reassume the virtual addresses.

Hardening Routing Protocols

All the hardening steps you have taken on your routers lead to this section, because running routing protocols is why you implement routers in the first place. You have four primary routing mechanisms available to you:

• Direct connections Although direct connections are often overlooked as routing functions, they are included in the routing table. They represent the subnets that the router has an interface connected to.

• Static routing Static routing is simply the manual entry of all routes on a device. Static routing generally takes precedence over other routing methods and is the most secure method of routing because the router will only route if it is explicitly configured to do so. Static routing should be employed on all insecure network segments, such as DMZ segments.

• Dynamic routing Dynamic routing makes use of routing protocols to exchange routing information between routers. Dynamic routing is the most flexible routing choice because the routers can dynamically update and change according to network changes. The rest of this section will focus on how to secure dynamic routing protocols.

• Default routing Default routing is a form of static routing that is used to route a packet to another router when no explicit route to the destination network is known.

Generally speaking, there is not a whole lot we can do about securing the way the routing protocols function. For example, most (if not all) routing protocols were written so that the data is not encrypted, and there isn t much you or I can do about that. Similarly, most (if not all) routing protocols use multicast or broadcast traffic to locate other routers, and, again, there isn t much you or I can do about that.

The problem with all this, of course, is that we do not want our routers to be able to be poisoned with invalid routes or to have routes hijacked and data sent to remote locations. This we can do something about ”through the use of authentication, as you saw in Chapter 3. This section will exclusively focus on IOS-based devices and will look at how to implement authentication, as well as any routing protocol “specific security functions that are available.

Router Information Protocol (RIP)

Three steps are involved in configuring RIP authentication. The first step is to configure the key chain that will be used by RIP. You can do this by running the following commands from the global configuration mode of execution:

 rtr-1721(config)#key chain ripchain rtr-1721(config-keychain)#key 1 rtr-1721(config-keychain-key)#key-string ripkeystring 

This example configures a key chain named ripchain, with a key string of ripkeystring. The next step is to configure RIP by running the following commands from the global configuration mode of execution:

 rtr-1721(config)#router rip rtr-1721(config-router)#version 2 rtr-1721(config-router)#network 192.168.2.0 

One Step Futher

All hash-based authentication mechanisms are only as strong as the length of the key used to generate the hash. Consequently, I recommend that you use long key values (22 characters or longer), containing upper- and lowercase, numeric, and special characters .

 

The last step is to configure RIP authentication from the interface configuration mode of execution for all the interfaces on which you want to enable RIP authentication:

 rtr-1721(config-if)#ip rip authentication key-chain ripchain rtr-1721(config-if)#ip rip authentication mode md5 

Open Shortest Path First (OSPF)

OSPF uses a similar authentication mechanism, although the commands are a little different. The following commands will configure OSPF:

 rtr-1721(config)#router ospf 10 rtr-1721(config-router)#log-adjacency-changes rtr-1721(config-router)#area 10 authentication message-digest rtr-1721(config-router)#network 192.168.1.06 0.0.0.255 area 10 rtr-1721(config-router)#network 192.168.254.0 0.0.0.3 area 10 

In this case, I have configured OSPF with an area of 10, assigned two networks for routing, and defined area 10 to use authentication. The second line configures the router to generate a syslog message anytime a neighbor router goes up or down to provide a means of alerting as to a potential routing problem. Finally, you need to configure the OSPF authentication key from the interface configuration mode of execution for all the interfaces on which you want to run OSPF:

 rtr-1721(config-if)#ip ospf message-digest-key 1 md5 ospfkey 

Enhanced Interior Gateway Router Protocol (EIGRP)

EIGRP is a proprietary Cisco routing protocol that can be used instead of RIP or OSPF. As with RIP, there are three steps to configuring EIGRP authentication. The first step is to create a key chain by running the following commands from the global configuration mode of execution:

 rtr-1721(config)#key chain eigrp-key-chain rtr-1721(config-keychain)#key 1 rtr-1721(config-keychain-key)#key-string eigrpkey 

The next step is to configure the EIGRP routing process by running the following commands from the global configuration mode of execution:

 rtr-1721(config)#router eigrp 100 rtr-1721(config-router)#network 192.168.2.0 255.255.255.0 rtr-1721(config-router)#network 192.168.254.4 255.255.255.252 

The final step is to configure authentication from the interface configuration mode for all the interfaces on which you want to use EIGRP:

 rtr-1721(config-if)#ip authentication mode eigrp 100 md5 rtr-1721(config-if)#ip authentication key-chain eigrp 100  eigrp-key-chain 

Border Gateway Protocol (BGP)

BGP is an exterior gateway protocol that is typically implemented on Internet-connected gateways. BGP is a fairly complex routing protocol. Although the details of its implementation are beyond the scope of this book, you can take a couple fundamental hardening steps: using authentication to protect against route injection attacks and simple TCP resets and protecting against potential denial of service attacks due to route flapping.

BGP, like the other routing protocols, uses an MD5 hash for authentication. One important aspect to clarify is that configuring authentication is required on both neighbor routers. In most cases, this is no big deal because the same administrator is responsible for both devices. With BGP, however, the neighbor router is commonly managed by the service provider; therefore, you need to ensure that the service provider configures their router accordingly . You can configure BGP authentication by running the following commands at the BGP router configuration mode of execution:

 local-rtr(config-router)#neighbor 192.168.254.1 remote-as 12345 local-rtr(config-router)#neighbor 192.168.254.1 password <password> 

In this case, I configured neighbor router entries for the router at 192.168.254.1, adding the appropriate password. The ISP would configure their router in a similar fashion.

BGP Route Flap Dampening Route flapping occurs when BGP networks are converging and can cause network instability and high CPU utilization. A route flap occurs when a route is constantly changing from an up to a down state, or from a down to an up state. Every time the router makes this transition, it sends a route update message to propagate around the network (in this case, the Internet). Although your ISP will typically implement BGP route flap dampening, you can also do it by running the following command at the BGP router configuration mode of execution:

 local-rtr(config-router)#bgp dampening 

You can implement additional BGP dampening options with the command to provide more granular control over things such as timing. One method is to define the half-life, reuse, suppress-limit, and max-suppress-time. There is no good answer as to what these values should be; rather, you should start with the default values (15 minutes, 750, 2000, and four times the half-life parameter, respectively) and then monitor your network to see whether route flapping is a problem.

The other method is to employ route-maps. This is a much more granular, but complex, method, allowing you to define different time values for different subnet sizes. See the Secure BGP IOS template located at http://www.cymru.com/Documents/secure-bgp-template.html for more information about how to configure the route-map entries.

One Step Futher

The BGP section of this chapter focuses exclusively on BGP authentication and flap dampening. This is due to the fact that both configurations are relatively straightforward, whereas route distribution and other BGP functionality require a much more exhaustive discussion than is practical for a single chapter. For more information about how to configure route distribution and a more concise filtering list for Internet-connected routers, see the Secure BGP IOS template located at http://www.cymru.com/Documents/secure-bgp-template.html.

 

Implementing Passive Interfaces

In addition to configuring authentication for your routing protocols, you can configure certain interfaces to not participate in routing by running the command passive-interface in the router configuration mode and assigning the interface on which to disable the routing protocol. For example, if you wanted to configure interface FastEthernet 0 as a passive interface, you would run the following commands:

 rtr-1721(config)#router ospf 10 rtr-1721(config-router)#passive-interface FastEthernet 0 

Filtering Routing Updates

You can also configure the router to filter what network information will be shared between devices. The distribute-list command can be used to apply access control lists that will perform the filtering.

There are two methods of filtering. The first method is to suppress the networks that will be advertised by running the distribute-list out command. The second method is to filter the networks that will be learned with the distribute-list in command.

You can use the distribute-list in command to protect against invalid routes being inserted into the routing table. To do this, you must first configure an access list containing the list of valid networks; for example, if you only wanted to permit networks 192.168.1.0/24 and 192.168.254.0/30, you would run the following commands from the global configuration mode of execution:

 local-rtr(config)#access-list 34 remark ACL for Routing Filter local-rtr(config)#access-list 34 permit 192.168.1.0 0.0.0.255 local-rtr(config)#access-list 34 permit 192.168.254.0 0.0.0.3 

The second step is to configure the distribute list for the routing protocol. You can configure distribute lists for RIP, OSPF, and EIGRP. For example, if I wanted to configure the distribute list for the EIGRP network I previously configured, I would run the following commands from the global configuration mode of execution:

 local-rtr(config)#router eigrp 100 local-rtr(config-router)#distribute-list 34 in 

This will prevent the router from learning about any networks other than the 192.168.1.0/24 and 192.168.254.0/30 networks, even if a neighbor router advertises those networks. This is an excellent method of ensuring that your routers will only learn about actual subnets that you have defined and created on your network.

If you wanted to prevent a router from advertising a network, you would follow the same general process. The first step is to create an ACL, except that instead of defining the networks to permit, you define the networks to deny and then permit everything else, as shown here:

 rtr-1721(config)#access-list 37 remark ACL to Deny Routing rtr-1721(config)#access-list 37 deny 192.168.1.0 rtr-1721(config)#access-list 37 permit any 

The last step is to simply configure the distribute list, this time using the out operator:

 rtr-1721(config-router)#distribute-list 37 out 

This configuration could be used, for example, to prevent the subnet containing HR resources from being advertised in your environment.

Using Black-Hole Routes and Null Routing

Although distribute lists and access control lists provide a much more granular method of controlling the traffic that can pass in and out of a router, they can impose a performance degradation on the device because it has to inspect all packets. Although most routers will not have a problem with this, in large networks and, in particular, on backbone devices, this can be an issue.

As an alternative to configuring distribute lists and ACLs, you can implement what is known as null routing, or using black-hole routes. Null routing functions by configuring the router to route all packets for a given network to the null interface, effectively preventing any traffic from going to that network. Null routing uses static route entries to define the black-holed networks. You can configure null routing by running the following commands at the global configuration mode of execution:

 rtr-1721(config)#interface null0 rtr-1721(config-if)#no ip unreachables rtr-1721(config-if)#exit rtr-1721(config)#ip route 10.0.0.0 255.0.0.0 null0 rtr-1721(config)#ip route 192.168.1.0 255.255.255.0 null0 

You want to ensure that you disable IP unreachables on the null interface because the router could potentially flood the upstream neighbor with unreachables due to the fact that packets destined to the network will never reach there. You can then add static route entries for each network you want to black hole (in this case, network 10.0.0.0/8 and network 192.168.1.0/24).

Implementing Traffic Management

In addition to routing of traffic, our routers can be used to perform traffic management, defining what traffic will be permitted, and how much of any given traffic type will be allowed. We have already looked at how to filter traffic to the router (for example, filtering SNMP or VTY access), and in this section we are going to look at how to filter traffic through the router. We will examine the following traffic management mechanisms:

• Unicast Reverse-Path Forwarding (RPF) verification

• Access Control Lists (ACLs)

• Context Based Access Control (CBAC)

• Flood management

Unicast Reverse-Path Forwarding (RPF) Verification

Unicast RPF is a feature that allows you to configure your router to perform a reverse-path verification on all packets it receives. The packets are compared against the router s routing table to see if a valid router to the source network exists. If it does, the router will forward the packets. If it does not, the router assumes the source has been spoofed and drops the packets.

Unicast RPF is typically implemented on border routers to ensure that internal hosts are not spoofing addresses to the Internet (for example, a host that may be infected with a Trojan to execute a DDoS). The only real caveat to unicast RPF is that Cisco Express Forwarding must be enabled on the router in order to perform the look backward function. In addition, you cannot use unicast RPF if your router uses asymmetric routes because the packets will be incorrectly dropped on the receive leg of the asymmetric route.

You can configure unicast RPF by running the following commands from the global configuration mode of execution:

 rtr-1721(config)#ip cef rtr-1721(config)#interface Serial 0 rtr-1721(config-if)#ip verify unicast reverse-path 

In this example, I have applied the unicast RPF to the serial 0 interface. You will need to do this for all interfaces on which you want to perform unicast RPF. As long as a route exists for the traffic, it will be permitted. If it doesn t exist, the traffic will be denied . For example, if this was your Internet gateway and you wanted to use unicast RPF, you could add a default route by running the command ip route 0.0.0.0 0.0.0.0 Serial 0 . This would allow all traffic from the Internet into the serial 0 interface connected to the ISP while dropping all traffic that may have a source IP address of the internal network because the internal network is directly connected to a different interface.

Note  

If your device uses a Versatile Interface Processor (VIP), you need to run the command ip cef distributed .

A new feature for IOS versions 12.1(2)T and later is the inclusion of access lists in the commands. This allows you to configure an ACL to permit traffic in the event that the source address check fails. You can apply the ACL to the command by running the following at the interface configuration mode:

 rtr-1721(config-if)#ip verify unicast reverse-path 101 

In this case, I have configured unicast RPF to check ACL 101 before rejecting a packet that fails the initial source check.

Using Access Control Lists to Filter Traffic

ACLs represent the most functional method of controlling traffic because they offer a high degree of configuration granularity. Although ACL syntax, formats, and concepts are beyond the scope of this book (if you are not familiar with them, I strongly suggest that you review them before you undertake this section of the book), we will look at how to apply ACLs in various scenarios to protect your network from attack. We will look at how to use ACLs for both inbound (ingress) and outbound (egress) filtering on your network, including the following scenarios:

• Implementing spoof protection

• Implementing TCP SYN attack filtering

• Implementing Land attack filtering

• Implementing Smurf attack filtering

• Implementing ICMP message type filtering

• Implementing Bogon filtering

  Note  

  A potential source of confusion will be the repeated use of the terms internal and external network. This does not necessarily refer to your internal subnet in your protected enterprise LAN/WAN. Instead, it refers to internal and external from the perspective of the router. For example, on a perimeter router that connects to your ISP, the internal network is the subnet between the router and the firewall, not the protected networks behind the firewall.

One Step Futher

In all these ACL scenarios, you should consider using Turbo ACLs. Turbo ACLs compile all suitable ACLs into fast lookup tables, reducing the performance impact of ACL processing on the router. In general, any ACL with more than five entries is a candidate for turbo ACLs. You can configure turbo ACLs by running the following command at the global configuration mode of execution:

 Router#(config) access-list compiled 

 

Implementing Spoof Protection Spoof protection with ACLs allows you to prevent inbound traffic that claims to be from the inside or to prevent outbound traffic that claims to be from the outside. If you are using unicast RPF, you should not implement spoof protection with ACLs because unicast RPF is a lesser load on the router than processing ACLs.

The first type of spoof protection to implement is inbound spoof protection. With inbound spoof protection, you want to configure an ACL that denies any traffic with a source IP address of your internal network. In addition, you should deny the RFC1918 private address ranges and multicast traffic if you do not need to permit them. You can configure a basic inbound spoof-protection ACL by running the following commands at the global configuration mode of execution:

 rtr-1721(config)#access-list 111 deny ip 7.7.7.0 0.0.0.255 any log rtr-1721(config)#access-list 111 deny ip 127.0.0.0 0.255.255.255 any log rtr-1721(config)#access-list 111 deny ip 10.0.0.0 0.255.255.255 any log rtr-1721(config)#access-list 111 deny ip 0.0.0.0 0.255.255.255 any log rtr-1721(config)#access-list 111 deny ip 172.16.0.0 0.15.255.255 any log rtr-1721(config)#access-list 111 deny ip 192.168.0.0 0.0.255.255 any log rtr-1721(config)#access-list 111 deny ip 192.0.2.0 0.0.0.255 any log rtr-1721(config)#access-list 111 deny ip 169.254.0.0 0.0.255.255 any log rtr-1721(config)#access-list 111 deny ip 224.0.0.0 15.255.255.255 any log rtr-1721(config)#access-list 111 deny ip host 255.255.255.255 any log rtr-1721(config)#access-list 111 permit ip any 7.7.7.0 0.0.0.255 rtr-1721(config)#interface s0 rtr-1721(config-if)#description External Connection to Internet rtr-1721(config-if)#ip access-group 111 in 

This ACL will prevent the specified IP addresses from being able to send packets inbound with the final line or the ACL permitting all other IP traffic to the internal network of 7.7.7.0/24. The ACL is then applied to the external interface on the router.

Implementing outbound spoof protection is considerably simpler than implementing inbound spoof protection. Simply create an ACL that permits traffic from the internal network and denies everything else, as shown here:

 rtr-1721(config)#access-list 115 permit ip 7.7.7.0 0.0.0.255 any rtr-1721(config)#access-list 115 deny ip any any log 

The next step is to apply the ACL to the internal interface on the router:

 rtr-1721(config-if)#ip access-group 115 in 

Implementing TCP SYN Attack Filtering TCP SYN attacks function by partially establishing a volume of connections on a router that causes connection queues to fill up, thus preventing subsequent connection methods. There are two approaches to providing TCP SYN attack filtering.

The first method is to implement a filter that allows connections that are sourced from the internal network out and their subsequent responses back in while preventing all traffic from the external network from establishing a connection at all. Be advised that this will prevent all external hosts from being able to connect to internal resources, so use care when implementing this method. You can configure the ACL by running the following commands at the global and interface configuration modes of execution:

 rtr-1721(config)#access-list 117 permit tcp any 7.7.7.0 0.0.0.255  established rtr-1721(config)#access-list 117 deny ip any any log rtr-1721(config-if)#ip access-group 117 in 

This allows any external host to respond on an established connection to hosts on the 7.7.7.0/24 subnet. The ACL should be applied to the external interface of the router.

A more effective method of protecting against TCP SYN attacks, though at the cost of more performance degradation, is to implement the TCP intercept feature on your router. This feature will intercept the inbound SYN requests and respond with an ACK and SYN on behalf of the destination. If it receives an ACK, the session is established between the source and destination. If it does not receive an ACK, the session is dropped, thus protecting the server from the SYN attack. You can configure TCP intercept to use ACLs to define the traffic that it should be intercepting by running the following commands at the global configuration mode of execution:

 local-rtr(config)#ip tcp intercept mode intercept local-rtr(config)#ip tcp intercept list 121 local-rtr(config)#access-list 121 permit tcp any 7.7.7.0 0.0.0.255 local-rtr(config)#access-list 121 deny ip any any log local-rtr(config)#interface s0 local-rtr(config-if)#desc External Interface local-rtr(config-if)#ip access-group 121 in 

In this case, I have configured TCP intercept to use ACL 121, which has been subsequently applied to the external interface to define what traffic is permitted inbound.

Implementing Land Attack Filtering A Land attack is when a device receives a packet that has the same source and destination IP address and the same source and destination port number. These types of attacks can cause a denial of service or inflict performance degradation on the router and therefore should be filtered by using ACLs. Land attack defense simply involves applying an ACL that denies all traffic with the same source and destination IP address of the interface it is being applied to. For example, if the serial 0 interface has an IP address of 7.7.7.1, you would build and apply the ACL by running the following commands at the global configuration mode of execution:

 rtr-1721(config)#access-list 141 deny ip host 7.7.7.1 host 7.7.7.1 log rtr-1721(config)#access-list 141 permit ip any any rtr-1721(config)#interface serial0 rtr-1721(config-if)#ip access-group 141 in 

Implementing Smurf Attack Filtering A Smurf attack entails sending ICMP echoes at a subnet s broadcast address while using a spoofed source address for that subnet, causing the entire subnet to send an ECHO-REPLY to the spoofed IP address. You can filter Smurf attacks either by not forwarding broadcasts ( no ip directed-broadcast ) or by denying all traffic from external hosts to the internal broadcast addresses. For example, if your internal network is 7.7.7.0/24, you could run the following commands at the global configuration mode of execution:

 rtr-1721(config)#access-list 151 deny ip any host 7.7.7.255 log rtr-1721(config)#access-list 151 deny ip any host 7.7.7.0 log rtr-1721(config)#access-list 151 permit ip any any rtr-1721(config)#interface serial 0 rtr-1721(config-if)#ip access-group 151 in 

Implementing ICMP Message Type Filtering As mentioned previously in this chapter, ICMP can be used by an attacker to gain information about the network they are trying to attack. To mitigate this, you should implement ICMP message filtering at your router. You will filter ICMP differently depending on whether you are controlling inbound or outbound traffic.

For inbound traffic, you should deny the Echo, Redirect, and Mask-Request message types. You can permit all other message types. You can do this by building an ACL, as follows, and applying it to the external router interface as an inbound ACL:

 rtr-1721(config)#access-list 161 deny icmp any any echo log rtr-1721(config)#access-list 161 deny icmp any any redirect log rtr-1721(config)#access-list 161 deny icmp any any mask-request log rtr-1721(config)#access-list 161 permit icmp any 7.7.7.0 0.0.0.255 

This will deny the three message types we want to prevent while permitting any other ICMP traffic from external hosts to the internal network.

You should also filter the ICMP messages that are permitted from the internal network to external destinations. As a general rule, you should permit the Echo, Parameter-Problem, Packet-Too-Big, and Source-Quench message types while denying all other outbound ICMP traffic. You can do this by building an ACL, as follows, and applying it to the internal router interface as an inbound ACL:

 rtr-1721(config)#access-list 164 permit icmp any any echo rtr-1721(config)#access-list 164 permit icmp any any parameter-problem rtr-1721(config)#access-list 164 permit icmp any any packet-too-big rtr-1721(config)#access-list 164 permit icmp any any source-quench rtr-1721(config)#access-list 164 deny icmp any any 

In addition to filtering ICMP message types, you will also filter inbound traceroute packets because they can map a network as easily as an ICMP echo can. You can prevent inbound traceroute by adding the following line to an ACL that is assigned to an external interface as in inbound ACL (for example, the previous ICMP ACL 161):

 rtr-1721(config)#access-list 161 deny udp any any range 33434  33434 log 

You can permit outbound traceroute by simply adding a permit rule similar to the preceding deny:

 rtr-1721(config)#access-list 164 permit udp any any range 33434  33434 log 

Implementing Bogon Filtering I think the question I have received from the editors the most on this book is, What the heck is a bogon <g>? Bogons are network address spaces that have not been assigned to anyone yet. The term is a bit of slang that means bogus network, in the sense that because the IP address space has not been assigned to anyone, if someone claims they own that address space, it is a bogus claim.

Bogon filtering is predominantly applied for use with BGP routing to prevent your router from accepting routing entries to these bogus network. Bogon filtering can also be used as a component of null routing or spoof protection.

An obvious implementation issue with bogon filtering is the fact that periodically these addresses are going to be properly assigned to organizations, at which point they are not bogus anymore. This means that bogon filtering is not a one-time thing. You need to regularly and routinely update your bogon lists. To help stay on top of bogons, I recommend that you bookmark and check http://www.cymru.com/Bogons/ for the latest bogon list and compare it to your list. Now, you might be thinking at this point, OK, this seems like an awful lot of effort, and I m not going to mislead you ”it is a lot of effort. However, when you consider that some studies have identified that over 60 percent of the naughty traffic roaming around the Internet comes from these bogons, blocking them at your router is a good step toward protecting your internal users.

As of March 18, 2004, the following is the list of bogons (in Cisco ACL format so that you can see how they would be applied in your configuration). This is an aggregated list of the bogons, which simply means that any bogon entries that could be combined into a single entry have been:

0.0.0.0 1.255.255.255	2.0.0.0 0.255.255.255	5.0.0.0 0.255.255.255
7.0.0.0 0.255.255.255	10.0.0.0 0.255.255.255	23.0.0.0 0.255.255.255
27.0.0.0 0.255.255.255	31.0.0.0 0.255.255.255	36.0.0.0 1.255.255.255
39.0.0.0 0.255.255.255	41.0.0.0 0.255.255.255	42.0.0.0 0.255.255.255
49.0.0.0 0.255.255.255	50.0.0.0 0.255.255.255	58.0.0.0 1.255.255.255
71.0.0.0 0.255.255.255	72.0.0.0 7.255.255.255	85.0.0.0 0.255.255.255
86.0.0.0 1.255.255.255	88.0.0.0 7.255.255.255	96.0.0.0 31.255.255.255
169.254.0.0 0.0.255.255	172.16.0.0 0.15.255.255	173.0.0.0 0.255.255.255
174.0.0.0 1.255.255.255	176.0.0.0 7.255.255.255	184.0.0.0 3.255.255.255
189.0.0.0 0.255.255.255	190.0.0.0 0.255.255.255	192.0.2.0 0.0.0.255
192.168.0.0 0.0.255.255	197.0.0.0 0.255.255.255	198.18.0.0 0.1.255.255
223.0.0.0 0.255.255.255	224.0.0.0 31.255.255.255

Implementing Context Based Access Control

Context Based Access Control (CBAC) is the heart of the Cisco IOS Firewall. CBAC is essentially ACLs on steroids, providing the additional functionality of being able to perform stateful, dynamic packet inspection as well as being able to look deeper in the data.

The one caution that I want to address up front is using routers instead of firewalls for security. Although CBAC does provide better security than simple ACLs, at the end of the day, a router is a router, and it is designed primarily to route, not to function as a firewall. Consequently, I strongly recommend implementing an actual firewall instead of CBAC. Those circumstances, however, where you cannot implement a firewall (for example, the money layer of the OSI model) are a good environment for CBAC because it will provide you more security than simply applying an ACL (and because it is stateful, it is also much simpler to manage the traffic flow).

Five steps are involved in configuring CBAC:

1. Configure audit trails and alerts.

2. Configure global settings.

3. Define Port-to-Application Mapping (PAM).

4. Define the inspection rules.

5. Apply the inspection rules and ACLs to interfaces.

Configure Audit Trails and Alerts

The first step is to configure the router to write the CBAC audit trail and alert events to our previously configured syslog server. You can do this by running the following command from the global configuration mode of execution:

 local-rtr(config)#ip inspect audit-trail local-rtr(config)#no ip inspect alert-off 

Configure Global Settings The next step is to configure the CBAC global timeouts and thresholds. This step is optional because they all have default values. In general, all these settings influence the timeout and threshold values for the session state information.

In most cases, the default values are adequate. You could, however, change them (for example, if your system was being flooded with a SYN attack to reduce the SYN wait time).

Define Port-to-Application Mapping (PAM) PAM allows you to specify a nonstandard port that an application is running on. For example, if you have a web server running on port 8000, you could use PAM to map port 8000 to HTTP for inspection purposes. In this example, the following command would configure the PAM:

 local-rtr(config)#ip port-map http port 8000 

Unless you are running applications on nonstandard ports, you should not need to make any PAM changes. For more information about the ports that are supported for PAM, see http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7c5.html.

Define the Inspection Rules The fourth step is to configure the application inspection rules. These allow you to configure CBAC to inspect the traffic specified to verify that it is not harmful . Application inspection is a mixed bag, however. First, CBAC will only inspect the traffic you configure it to. If you don t configure it to inspect HTTP traffic, it won t do so. Second, CBAC only inspects a subset of all the traffic out there. Although CBAC can inspect most of the common Internet protocols, such as HTTP, SMTP, and FTP, there are many protocols it is not capable of inspecting. Generally speaking, any traffic that you want to be permitted based on state must be inspected. For example, if you wanted to grant your internal users access to the Internet using HTTP, SMTP, FTP, as well as generic TCP and UDP, you would configure the following at the global configuration mode of execution:

 local-rtr(config)#ip inspect name CBAC01 http local-rtr(config)#ip inspect name CBAC01 ftp local-rtr(config)#ip inspect name CBAC01 tcp local-rtr(config)#ip inspect name CBAC01 udp local-rtr(config)#ip inspect name CBAC01 smtp 

In addition, if you wanted to generate an alert or audit trail in syslog, you could add the following option to the command: alert on or audit-trail on .

Apply the Inspection Rules and ACLs to Interfaces The final step is to apply the inspection rules and any ACLs to the interface. Remember that CBAC only inspects the traffic you have defined, so if your ACL permits the traffic for the interface and CBAC is not configured to inspect the traffic, it will be allowed in without being inspected.

Applying the inspection rule is relatively straightforward. In our example of an Internet gateway, simply create an access list that denies all IP traffic. Next, change to the external interface and apply the access list and the CBAC inspect list:

 local-rtr(config)#access-list 101 remark ACL to Protect Ext. Int. local-rtr(config)#access-list 101 deny ip any any log local-rtr(config)#interface Ethernet 0 local-rtr(config-if)#ip access-group 101 in local-rtr(config-if)#ip inspect CBAC01 out 

This allows all traffic permitted by the inspect list to exit the interface, and it permits the corresponding responses back because CBAC is stateful. It does this by dynamically modifying the ACL to permit the given traffic. You can see this by running the following command:

 local-rtr#sh ip access-lists Extended IP access list 101  permit udp host 192.168.1.100 eq 389 host 192.168.2.10  eq 1201 (1 match)   permit tcp host 192.168.1.100 eq 445 host 192.168.2.10  eq 1197 (6 matches)   permit tcp host 192.168.1.100 eq 445 host 192.168.2.10  eq 1175 (14 matches)  deny ip any any log (218 matches) 

Flood Management

Another important role for a router is to control the flow of traffic through the router to protect against flood attacks (for example, DoS or DDoS attacks). One method of flood management that we have already discussed is the use of Cisco Express Forwarding (CEF), which uses a more efficient forwarding/switching path. Another feature to enable on your router interfaces is NetFlow. Not only does NetFlow provide a more efficient traffic-flow mechanism, but the data it collects can be used for security monitoring, network management, capacity planning, and application traffic-flow analysis. You can enable NetFlow on an interface by running the following command at the interface configuration mode of execution:

 rtr-1721(config-if)#ip route-cache flow 

Another traffic-flooding feature is to enable the nagle service by running the following command at the global configuration mode of execution:

 rtr-1721(config)#service nagle 

The Nagle algorithm is used to address small packet problems, such as with Telnet. Telnet sends each character as a single packet. Nagle establishes the initial session using a single packet and then collects the remaining Telnet packets and waits to submit them until it receives an ACK. At that point, it sends the collected packets as a second, larger packet, continuing to accumulate the data into larger chunks of data. It then paces the data out to the network, reducing the amount of CPU interrupts in the case of Telnet because each character is a single CPU interrupt.

Implement Committed Access Rate (CAR) The committed access rate (CAR) has been traditionally viewed as simply a Quality of Service (QoS) tool that allows you to define what amount of bandwidth an application or protocol is guaranteed on the network. It has the pleasant side effect, however, of being able to be used as a rate-limiting tool to protect your network from attacks that rely on a certain protocol, such as ICMP, to function.

CAR functions by allowing you to define what portion of bandwidth should be reserved for critical traffic, forcing all other traffic to be dropped if it exceeds a certain amount of bandwidth. Although CAR is a very helpful feature for mitigating DoS attacks, it is not perfect. For example, if the attack is using a protocol that you have reserved for critical traffic (for example, HTTP traffic), CAR isn t going to help much because there is no method of differentiating between legitimate and illegitimate traffic. If, however, the attack is being waged using ICMP traffic, for example, CAR could insulate your HTTP traffic, ensuring that the router always provides a minimum amount of bandwidth to HTTP requests, as you defined.

You can define the CAR through the use of the rate-limit command. You can apply a rate limit to input and output traffic on the interface. The rate limit rule is broken into three distinct components :

• The first section defines whether the rule applies to input or output traffic. It can also be used in conjunction with an ACL to define the types of traffic to be managed by the rule.

• The second section defines what the token bucket parameters are. The token buckets represent the bit rate (in bps), the burst size (in bytes), and the burst excess size (in bytes). For more information about the token bucket parameters, see http://www.cisco.com/warp/public/732/Tech/car/index.html.

• The third section defines what should be done with the traffic that exceeds the CAR (for example, dropping it or continuing to transmit it).

For example, let s assume on your 10MB Internet connection that you want to define the following CAR rules for outbound traffic:

• HTTP traffic is reserved for 30 percent of the traffic.

• SMTP traffic is reserved for 10 percent of the traffic.

• ICMP echo and echo-reply (ping) is limited to less than 1 percent of the traffic.

You want to ensure that HTTP and SMTP always have the reserved amount of bandwidth available to them, and if more bandwidth is available, they can use it. For ICMP, however, you want to drop it anytime it exceeds the 1-percent reservation. To do this, you would run the following commands from the global configuration mode of execution:

 rtr-1721(config)#access-list 170 remark ACL for HTTP CAR rtr-1721(config)#access-list 170 permit tcp any any eq 80 rtr-1721(config)#access-list 171 remark ACL for SMTP CAR rtr-1721(config)#access-list 171 permit tcp any any eq 25 rtr-1721(config)#access-list 172 remark ACL for ICMP (ping) CAR rtr-1721(config)#access-list 172 permit icmp any any echo rtr-1721(config)#access-list 172 permit icmp any any echo-reply rtr-1721(config)#interface Ethernet 0 rtr-1721(config-if)#rate-limit output access-group 170 3000000  25000 50000 conform-action transmit exceed-action continue rtr-1721(config-if)#rate-limit output access-group 171 1000000  25000 50000 conform-action transmit exceed-action continue rtr-1721(config-if)#rate-limit output access-group 172 16000  8000 8000 conform-action transmit exceed-action drop 

Implementing IPsec

As we have discussed in Chapters 3 and 5, using IPsec is the only real effective method of securing traffic that is otherwise insecure (SNMP, syslog, TFTP, and so on). You can configure IPsec on your routers in two scenarios:

• Establishing IPsec between two routers (or a router and other remote device such as a firewall or VPN concentrator) to encrypt all traffic traversing the network between the two devices

• Using IPsec for secure remote management of the device (for example, to tunnel Syslog, SNMP, or Telnet traffic in IPsec)

Configuring IPsec to a remote management station is covered in Chapters 3 and 10 of this book, so I am not going to repeat the process here. Instead, I will focus on how to configure IPsec on two routers to allow them to communicate securely with each other. The configuration differences between that and the remote administration scenario are relatively minor. If you can establish IPsec between two routers, you should not have any problems making the necessary changes for remote administration.

There are three steps to configuring IPsec on your router:

1. Configure common IKE authentication.

2. Configure the IKE security policy.

3. Configure the IPsec protection parameters.

Configure Common IKE Authentication

The first step is to configure the pre-shared keys that will be used by both routers. For example, let s assume that you have two routers connected via a serial line and you want all traffic traversing that serial line to be encrypted. One router is named local-rtr, and the other router is named remote-rtr. You would want to run the following command on local-rtr:

 local-rtr(config)#crypto isakmp key 12345abcde address 192.168.254.1 

You would run the corresponding command on the remote router:

 remote-rtr(config)#crypto isakmp key 12345abcde address 192.168.254.2 

Configure the IKE Security Policy

The next phase is to configure a common IKE security policy on both the routers. It is critical that you run the exact same commands on both routers because IPsec is a temperamental feature, and any difference between the two policies can cause the IPsec tunnel to fail. You want to run the following commands from the global configuration mode on both routers (only one router example is shown):

 !-- You can assign any policy number remote-rtr(config)#crypto isakmp policy 1 !-- 3DES is the most secure encryption, though you could use DES remote-rtr(config-isakmp)#encryption 3des !-- SHA is a more secure HASH method than MD5 remote-rtr(config-isakmp)#hash sha remote-rtr(config-isakmp)#authentication pre-share !-- Diffie-Hellman group 2 is more secure than group 1 remote-rtr(config-isakmp)#group 2 remote-rtr(config-isakmp)#lifetime 86400 

Configure the IPsec Protection Parameters

The final step is to configure the IPsec tunnel characteristics. You will build the characteristics in three steps:

1. Configure the ACLs to define what traffic should be encrypted.

2. Configure the appropriate transform set.

3. Create the necessary crypto map.

Configure the ACLs to Define What Traffic Should Be Encrypted In this case, you want all traffic to be encrypted by IPsec, so you will create an ACL on both routers that causes this to occur:

 remote-rtr(config)#access-list 175 remark ACL for IPsec remote-rtr(config)#access-list 175 permit ip any any 

Configure the Appropriate Transform Set Next, you want to configure the transform set with the appropriate encryption and authentication mechanism, and you want to set the tunnel mode on both routers:

 remote-rtr(config)#crypto ipsec transform-set set1 esp-3des  esp-sha-hmac remote-rtr(cfg-crypto-trans)#mode tunnel 

Create the Necessary Crypto Map The final step is to create the crypto map that brings all the ISAKMP and IPsec information together to build the IPsec tunnel. Like the

IKE security policy, both routers need to have exact matches of each other, with the exception of the peer value, which is configured with the neighbor router IP address:

 remote-rtr(config)#crypto map pipe-1 1 ipsec-isakmp % NOTE: This new crypto map will remain disabled until a peer     and a valid access list have been configured. remote-rtr(config-crypto-map)#match address 175 !-- Ensure that you specify the remote peer IP address, in this case !-- the IP address of the local router remote-rtr(config-crypto-map)#set peer 192.168.254.2 remote-rtr(config-crypto-map)#set transform-set set1 remote-rtr(config-crypto-map)#set security-assoc lifetime kilo 80000 remote-rtr(config-crypto-map)#set security-assoc lifetime sec 26400 

Finally, you need to turn IPsec on for the appropriate interface. The best way to do this is to configure the remote side first, because as soon as you configure one side, you will not be able to communicate with the other router until IPsec is functioning.

By configuring the remote side first, when you lose connectivity (and you will), the connection will automatically fix itself when you finish the configuration on the local router. Turn on IPsec on the serial interface of the remote router:

 remote-rtr(config-if)#crypto map pipe-1 

The link will not pass traffic until you turn on IPsec on the serial interface of the local router:

 local-rtr(config-if)#crypto map pipe-1 

At this point, all traffic passing across the serial interface should be encrypted by IPsec, as shown by the following command:

 local-rtr#sh crypto isakmp sa  dst   src    state conn-id  slot 192.168.254.1 192.168.254.2 QM_IDLE 1 0