The Router as a Security Device

Because the router is traditionally the entranceway to a network, it plays an important part in network security. For this reason, routers have been designed with many built-in security features, such as packet filters, stateful firewall features, Network Address Translation (NAT), and Virtual Private Network (VPN) support. The question is whether a router is utilized as your only security device or as a piece of a larger defense-in-depth security structure. In a perfect (secure) world, the answer would always be as a part of a larger security structure, letting the router focus on its primary function, and allowing firewalls, intrusion detection systems (IDSs), and so on handle the burden of the security concerns. In this section, we look at scenarios that use a router as part of defense in depth and also as the primary security solution. We also explore the technologies that are often implemented when using a router as a lone security device, such as NAT, context-based access control (CBAC), ACLs, and so on. In addition, we look at the technologies that can be employed to make the router a complement to a greater security scheme.

The Router as a Part of Defense in Depth

In Chapter 12, "Fundamentals of Secure Perimeter Design," we go into detail on the logistics of placing a router as part of the defense-in-depth structure and the functions it should perform. In this section, we predominately focus on the technologies to make a router an effective part of defense in depth and ways to implement those technologies.

A router's role as part of defense in depth can vary depending on the related pieces of the overall security scheme. For example, it would be foolish to implement a router with stateful inspection capabilities in conjunction with a stateful firewall. Typically, the rule of thumb is to keep the router from doing any more than it has to, and let it focus on what it is good at.

Packet Filtering

As stated in Chapter 2, blocking access from ranges of addresses is something that routers do well. It makes sense to take advantage of this strong suit when using the router as a role player in conjunction with a stateful firewall, by utilizing the router for ingress and egress filtering.

It is logical to implement ingress filters at the furthermost point on your perimeter, which is most likely your border router. Having the router perform this function offloads some of the burden from the firewall, allowing it to focus on the things for which it is better suited, such as the stateful inspection of defined protocols. Egress filtering is also a good choice for a router that is working in conjunction with other perimeter firewalls; blocking or allowing entire network ranges is something that packet filters are well suited for. Due to the structuring of the TCP/IP packet and the means by which matches are made with the standard packet filter, blocking a range of network addresses is simple bit matching that is difficult to circumvent on a router and that can be accomplished efficiently. For this reason, any time whole ranges of network addresses need to be blocked or allowed, the router is an excellent candidate for a point of implementation.

For more information on the best ways to implement egress and ingress filters and to utilize the packet-filtering features of a router, refer to Chapter 2.

Network-Based Application Recognition (NBAR)

Recently, routers have begun to be utilized in another way as a part of defense in depth. Cisco's network-based application recognition (NBAR) is a feature that was originally designed to help with Quality of Service (QoS) issues, with full functionality available in IOS 12.1(2)e or later. With the onset of bandwidth-devouring streaming-multimedia applications and applications that require high QoS, such as Voice over IP (VoIP), a method had to be created to allocate bandwidth based on the applications being used. NBAR can be used to allocate at least a certain amount of bandwidth to an activity or traffic type or to limit bandwidth for a given traffic type.

You might be wondering why QoS commands are being mentioned in a book about security. In today's world, security is more than disallowing or allowing access to resources. It also includes the protection of service demands and available bandwidth. Because of the increased threat of denial of service (DoS) attacks, protecting the bandwidth we have to offer our business or clients has become a major point of concern. A business relying on e-commerce whose storefront is inaccessible due to inadequate bandwidth can face a serious financial hardship. A lack of bandwidth equates to a DoS whether it is due to an outside malicious DoS attack or mismanaged use of internal bandwidth. Using solutions such as NBAR can prevent this mismanagement, keeping a "governor" on high-bandwidth activities that don't serve as an important resource for your business. For example, if your site relies on e-commerce to exist and you share bandwidth between e-commerce applications and Internet access for employees, NBAR would prevent a DoS condition caused from all your employees simultaneously tuning in to the latest Victoria's Secret streaming fashion show.

NBAR can recognize traffic based on HTTP informationincluding MIME types, URLs, and hostnames. It can also search on static and dynamic port information. After the traffic is identified, it can be marked, and then a policy determining the amount of bandwidth allowed can be applied. This policy can be used in many creative ways to control QoS and protect application bandwidth.

For example, in a business environment, you might want to limit the bandwidth for multimedia applications to a fraction of your total Internet connection bandwidth so that they don't interfere with higher priority business applications. Using the following commands limits the bandwidth for all defined multimedia applications to 12 kilobits per second (Kbps) total:

Tip

Cisco Express Forwarding must be enabled for NBAR to function.

 router(config)#class-map match-any av router(config-cmap)#match protocol http mime "audio/*" router(config-cmap)#match protocol http mime "video/*" router(config)#class-map match-any images router(config-cmap)#match protocol http url "*.gif" router(config-cmap)#match protocol http url "*.jpg|*.jpeg" 

Here, av and images are the unique names for the class maps, and audio/* and video/* are the MIME types for which we want to control QoS. With the images class map, we specifically limit the bandwidth for defined picture types as well.

Then, both of these class maps can be combined into one all-inclusive class map:

 router(config)#class-map match-any mmedia router(config-cmap)#match class-map av router(config-cmap)#match class-map images 

Notice the use of the match-any keyword. The keyword match-all (not shown) requires that all the listed criteria be met, whereas match-any allows a match if any of the listed criteria is the same. Because we want to affect traffic that matches either of the listed class maps, we must use match-any.

Now we will create a policy defining how much bandwidth our mmedia class map will be allowed:

 router(config)#policy-map mybusiness router(config-pmap)#class mmedia router(config-pmap-c)#police 12000 conform transmit exceed drop 

Here, mybusiness is a unique policy name that represents all class maps for which we want to control QoS on an interface. Other class maps could be applied in this same policy map. We apply the class map mmedia, which we created previously, and then allow no more than 12Kbps of our total bandwidth to it with the police command.

Note

As you may have guessed by the syntax of the police command, any multimedia traffic exceeding the 12K bandwidth limitation is dropped. It is not queued in any way and will break multimedia communications.

Finally, we apply the policy to an interface using the following command:

 router(config-if)#service-policy output mybusiness 

Here, mybusiness is the policy name previously defined, and output is the correct direction on the interface to which we choose to apply it.

NBAR has also become a method to prevent outside attacks from causing a DoS condition. With the advent of the Code Red and Nimda and SQL Slammer worms, many sites that properly patched their servers still fell victim to the "noise" generated by other infected locations. They had no means to protect their bandwidth from the repeated assaults from outside infectors. By placing NBAR as a screening mechanism on border routers, you can effectively prevent just such a DoS condition.

The setup is similar to our previous example. We simply create another class map. This class map can be used to screen incoming malicious traffic that has a known uniquely identifiable structure, or footprint.

Note

Don't allow yourself to be lulled into a false sense of security. NBAR screening for malicious traffic is a dynamic process. As variants are discovered, the footprints used to screen content must be updated.

Our class map will include Cisco's suggested match information for Code Red, Nimda, and some current variants:

 router(config)#class-map match-any web-attacks router(config-cmap)#match protocol http url "*.ida*" router(config-cmap)#match protocol http url "*cmd.exe*" router(config-cmap)#match protocol http url "*root.exe*" router(config-cmap)#match protocol http url "*readme.eml*" 

This new class map can be added to an existing policy that is applied in the same direction on the same interfaces. If you don't have a like policy, you can create a new one:

[View full width]
 router(config)#Policy-map attacks router(config-pmap)#class web-attacks router(config-pmap-c)#police 10000 3000 3000 conform-action drop exceed-action drop  violate-action drop 

Notice that the policy map looks similar to the last example, with the exception of the police command. Because of the addition of the violate-action keyword, we need to add burst speeds after the first bandwidth listing. However, the three numbers specified are meaningless because all defined actions will drop the identified traffic. Cisco has documented this as a solution for bandwidth issues in these situations (http://www.cisco.com/warp/public/63/nbar_acl_codered.shtml).

To handle a worm like SQL Slammer with an unusual protocol and no particular URL-match criteria to filter on, we need to use other information to generate a "signature." First, a custom protocol needs to be created with the following command:

 ip nbar port-map custom udp 1434 

Then, the class map can be created to include this custom defined protocol and another unique piece of criteria, the packet length:

 Class-map match-all slammer Match protocol custom Match packet length min 404 max 404 

The packet length as part of the matching criteria is crucial, because it is what separates the Slammer traffic from possibly normal SQL traffic on UDP port 1434. Notice in this class map we specify to "match all" because we only want to drop UDP 1434 packets with the listed packet length. In the Nimda/Code Red example, payloads matching any of the criteria would have been dropped. Finally, this class map would be assigned to a policy map like the one in the Nimda/Code Red example and the traffic would be dropped using a like police statement.

Note

Realize that your border router will experience additional load from this NBAR screening process, and a seriously overburdened router can also create a DoS condition.

Tip

For more information on mitigating the effects of worms using Cisco technologies, refer to http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_white_paper09186a00801e120c.shtml. Also, additional settings can be added to your router to limit the effect of DoS attacks. For an article on protecting against various other DoS attacks on Cisco routers, see http://www.cisco.com/warp/public/707/newsflash.html.

No matter what security technology you take advantage of on your routerwhether it's simple access lists for filtering out undesired packets, or NBAR to drop malicious Internet wormsyou will find the router to be an excellent role player in your network's defense in depth. However, in some cases a router may need to supply the majority of the security features for the defense of a network segment.

The Router as a Lone Perimeter Security Solution

In some environments, the router can be used as an effective perimeter security solution on its own. It can be used as a sole means of defense for a remote or home office, for an internal segment of your network, or as a security solution for a low-risk facility where it wouldn't be cost effective to add an additional firewall or other security device. No matter what the deployment, a properly configured router can provide a good base for a perimeter defense. However, it is still important to apply defense-in-depth principles beyond the router. Relying on any single perimeter device as your only source of security leaves you only one step from being compromised. An outsider needs to find only a single flaw to have access to your entire network.

Router Placement

The placement of your router will help determine the technologies you should implement when securing your environment.

A border router that has to serve as an all-in-one security solution might have many duties to perform. Not only does it handle all the routing between your network and the outside world, but it must also block incoming attacks to provide security. Depending on the environment, this might be accomplished with ACLs or stateful CBAC support. (For more information on CBAC, look at the "Technology Choices" section later in this chapter.) Because it is at the border of your network, it may support NAT or Port Address Translation (PAT) to allow the use of a private addressing scheme internally. It may also be where VPN connections are decoded and information passed on to internal hosts. One important thing to remember when a border router is your sole security solution is its visibility. Because it is your gateway to the world, anyone on the Internet must be able to contact it for you to be able to communicate. In turn, that means it is vulnerable. Many border routers are configured to securely protect internal hosts, and yet are open to attack themselves. In the section on router hardening later in this chapter, we discuss means to defend the lone router from being exploited.

Routers can also be placed at internal subnetting points in your network. IP networks are subnetted for various reasons, including performance and security. A router must be placed at the points where the subnetted segments join together to facilitate communication. Depending on environmental circumstances, a router might be a good device for enforcing resource separation on the network. For example, when subnetting off a research and development lab, you might want to consider preventing inbound access from other internal subnets, while allowing outbound access from the lab to the rest of the network and Internet. Again, this can be accomplished with ACLs or CBAC, depending on the segment's security level. If the internal network is based entirely on a private addressing scheme, it is unlikely that NAT would be implemented on a router joining such subnets.

No matter the placement, several security technologies can be used to secure the network. In the following section, we will discuss these technologies.

Technology Choices

With the advancement of technology, routers are becoming more feature rich. Many options are available when implementing a router as a security solution, whether it is as part of an entire defense scheme or as a standalone device. All the technologies in the following list are discussed in depth in this section and can be used in either case, but they are often implemented as a lone solution:

• NAT/PAT

• CBAC

• Packet filtering and ACLs

NAT has long been a means to help solve the public IP address range shortage and help secure a network and its privacy. NAT allows the assignment of a public IP address on the "outside" of a device to a corresponding private IP address on the "inside." This way, the internal network addressing remains hidden from outside parties. As communication ensues, the NAT device is responsible for translating the traffic between the public outside and private inside addressing. Only the NAT device knows the internal addresses to which the outside public addresses relate. These translations can be statically assigned (to allow bidirectional communication) or dynamically assigned. When dynamic assignment is used, a pool of available public addresses needs to be created. This outside pool does not necessarily have to match one-to-one with the number of inside addresses, allowing many privately addressed stations to share a smaller group of public addresses. However, no more stations can make external connections at one time than there are available public addresses in the pool. When all available public addresses from this outside pool are in use, the next internal station attempting an outside connection will be unable to do so, unless a variation of NAT, called overloading or PAT, is also implemented.

Note

In the context of this section, we use the term NAT to define standard NAT using address-only translation. We use the term PAT to define NAT translation using port overloading.

The greatest conservation of addresses can be accomplished by using overloading or PAT (also called NAPT, or single address NAT). PAT maps multiple internal addresses to one external public address by tracking the communication sessions by the port number in use. As an example, an internal station at IP address 192.168.1.5 contacts an outside web server. It generates an ephemeral port of 1035 and sends the request to its gateway router, which happens to be a PAT device. The router translates the requesting station's address into the defined public IP address and assigns a new port number (1111 in this instance). This is accomplished by actually rewriting the packet's header information with the new IP address and port number information. It then enters this information as well as the station's original IP address information and the information of the server it is contacting into a table, like this:

   Source IP/port - Translated IP/port - Contacted IP/port 192.168.1.5.1035 - 200.200.200.2.1111 - 225.225.225.1.80 

Depending on the implementation, the PAT device may attempt to assign the same source port number on the outside that is being used by the station on the inside. However, if another connection is already using the port number, the PAT device might reassign a new port number in approximately the same port range, as in our previous example. Also, many implementations of PAT use a range of high port numbers (often 50,000 or more) that is assigned for the source port. When you're monitoring traffic, seeing ephemeral ports in this range is often a sign that a PAT device has translated the traffic.

When the traffic returns, the PAT device can refer to the NAT table and translate the response for IP 200.200.200.2 port 1111 back to IP address 192.168.1.5 port 1035. Subsequent connections from inside stations would be translated to other ports on the same 200.200.200.2 address. This way, thousands of sessions can successfully take place with only one public IP address, and each will be able to be differentiated from the other. PAT does not have to be limited to a single IP address. Some implementations of PAT will allow multiple IP addresses to be translated.

On a Cisco router, a NAT configuration can be implemented as follows:

1. Apply the command router(config-if)#ip nat outside on the external interface. This command sets this interface as the outside NAT interface.

2. Apply the command router(config-if)#ip nat inside to the internal router interface. For translation reasons, this command tells NAT that this is the inside interface.

3. Configure a pool of addresses for NAT to use with the following statement:

    ip nat pool natpool 200.200.200.2 200.200.200.10 netmask 255.255.255.240 

   
   

   This statement defines a public address pool named natpool with the IP addresses 200.200.200.2200.200.200.10.

4. Follow this with an access list to specify all internal addresses to be assigned public IP addresses from the NAT pool, as follows:

    access-list 1 permit ip 10.0.0.0 0.255.255.255 

   
   

   If you are using this device for a VPN as well, additional access lists will need to be created to allow the VPN traffic to bypass NAT. (For more information on VPN implementations on Cisco hardware, refer to Chapter 7, "Virtual Private Networks.")

5. Execute the following command in global configuration mode (this command is the bread and butter of the NAT implementation on a Cisco router):

    ip nat inside source list 1 pool natpool 

   
   

   It starts by assigning 1 to the access list as the addresses to be translated. Next, it defines the pool of public addresses to dynamically be assigned. This is a standard configuration for dynamic NAT, with a pool of addresses to be assigned.

   For PAT, the command would be changed as follows:

    ip nat inside source list 1 interface Ethernet0 overload 

   
   

   First, the definition of a pool of addresses is not needed because only one IP address will be used externally, although the definition of a pool would be allowable. The keyword overload is added to the end of the NAT statement, signifying that multiple outgoing connections can overload or share one external IP address. Notice that the following command doesn't use a pool name. Instead, the interface keyword assigns the external address followed by the listing of the external interface's name. This way, PAT and the router's external interface can share one public IP address. This statement would be entered in global configuration mode.

The entering of these commands can make almost any Cisco router into a NAT or PAT device. To view the NAT or PAT translation table at any point, use the command router#sh ip nat trans.

Although NAT can be considered a privacy method, it offers limited inherent security after a connection is established from the inside. After an inside IP address is added to the NAT table, the address it was contacting can be accessed from the outside until the mapping is dynamically cleared. Some NAT implementations have no reference to port information in their NAT table, which leaves the inside station open to activity from the contacted outside host (or from spoofed traffic) on protocols other than the one which it had contacted. For example, if your internal web server contacted an outside DNS server for DNS information, and the DNS server tried to initiate communication to your web server before the original NAT table entry expired, it would be allowed access to any services your web server offers. This makes a good case for the addition of ACLs or CBAC as a complement to properly secure NAT traffic. PAT offers more security because it also tracks the port numbers used for each connection and logs them in its translation table. As long as the source port that your internal station is using is a dynamically generated ephemeral port on which no services are hosted, your configuration should be rather safe. However, if an attacker has the ability to detect your IP address, most likely he also will be able to detect the source and destination ports you are using. This means that if the translation table still holds the address/port combination in question, properly crafted traffic could pass. This assumes that the inside station is still listening on the port it was contacting when the table entry was created.

Another security issue with NAT is the lack of inherent outbound filtering. Any inside hosts can get out, which leaves an opening for Trojan software. The lack of granularity in the translation tables allows a greater likelihood of the occurrence of session hijacking or the infiltration of the network through an existing address translation. However, when used in conjunction with other technologies, such as static packet filtering, dynamic packet filtering, and even stateful inspection methods, NAT and PAT can provide an excellent privacy and security combination.

CBAC is a full-featured method of stateful inspection for Cisco routers. CBAC is available in the Cisco Secure Firewall Feature Set. (Some functionality was introduced in IOS version 11.2p, but many useful features have been added up to version 12.05t.) CBAC supports most popular protocols and keeps full track of the state of connections, dynamically creating access lists to allow return traffic from outside sources. The implementation of CBAC involves creating inspect statements that monitor the defined protocols. Following is an example of an inspect statement:

 ip inspect name firewall http timeout 3600 

Here, firewall represents the name of the inspection set we will be applying to our interface. http is a keyword that defines the protocol we are inspecting with this command, and the timeout option (which is not required) tells how long the dynamically generated access lists should exist after creation. This same formatting is applied to additional inspect statements for other protocols that you want to allow to exit your internal network. The set named firewall must be applied outbound on the external router interface with a command such as ip inspect firewall out. This command must be applied in interface configuration mode.

Because CBAC uses stateful inspection, not only does it make sure that ACLs are dynamically generated to allow return traffic, but it also verifies that the traffic being inspected is indeed what it claims to be at the application level. This prevents the use of well-known ports to facilitate possibly malicious activities (for example, using port 80 for Telnetting to a host instead of HTTP) and helps prevent session hijacking. For more information on stateful inspection and stateful filtering, see Chapter 3, "Stateful Firewalls."

Despite the fact that CBAC adds an extra layer of intelligence to the inspection of inbound and outbound traffic, it is not a security panacea. It is still wise to use ingress and egress filters in conjunction with CBAC. Despite CBAC's ability to inspect traffic, it will not provide NBAR-type screening of malicious content. Although CBAC provides stateful inspection-level protection for communications channels, it is still only one segment of a total defense-in-depth deployment. In addition, CBAC uses more resources and is slower, comparatively, than the other technology choices. Despite the fact that CBAC might be the most secure method to protect traffic with a router, it might not be the best selection in all scenarios.

Another way to secure a router is through ACLs that use static and dynamic packet filtering. This is what the router does best, and it is a complement to any security configuration. An ACL can also be a facilitator. Often, when other default security solutions don't allow a type of access, a static packet filter is created as an easy means to allow traffic in or out. This is often the way that a secure configuration can suddenly jump to insecure. ACLs are a powerful tool that must be carefully configured to prevent security holes. For more information on packet filtering with a router, see Chapter 2. For full sample listings of ACLs, see Appendix A, "Cisco Access List Sample Configurations."

Regardless of which security technologies you choose for your router, it is important to remember that they all have their strengths and weaknesses, and no method is impenetrable. Also, each of these technologies can benefit from defense-in-depth methodology, even in the simplest of networks. Keep these points in mind when designing your network's security structure, and remember that even the most secure interior configuration can still leave the perimeter router at a point of vulnerability.