8.3 Router Security Considerations

Routers are an often-overlooked part of a network security plan. Many companies that fall into the small-to medium-sized range with a single access router and limited routing expertise tend to hope that whatever configuration options are available on the router are good enough to secure it. I have often found that service providers that install the routers are not diligent about either mentioning the need for a secure router configuration or configuring it securely for customers when installing a new circuit.

The most common response that I receive when inquiring about the security of a router is, "What does it matter? The firewall will pick it up anyway." This is a flawed argument in at least two respects. The first is that a firewall will only inspect packets that flow through the firewall. Because the router is generally the network device prior to the firewall from the point of view of the Internet, it is possible to attack the router without ever involving the firewall. Of the two misconceptions, however, this is a minor one. The second major fallacy is that a firewall is a single device on the network. Any device that can increase the security of your network or assist in the implementation of your security policy should be employed as such. The secret of good network security is not complicated — defense in depth. Use as many resources as you can to protect your network against threats.

For many companies, the router is the firewall for their network as well. The common adage used to be, "Let the routers route, get another box for a firewall." This is something that I generally agree with, with some exceptions. Routers are best at routing and because you can "roll your own" firewall for very little cost in hardware or software, I find it difficult to justify not having at least two packet filtering devices on the network. The router does some simple packet filtering and the firewall does the more complex work. This, however, is not the best solution for all companies. Many companies, after performing a cost/benefit analysis for their network are looking for a way to provide the maximum protection with either minimal investment or with equipment they already have. In these circumstances, a router can act as a fairly robust firewall.

Advancements in processing and computing power have also rendered the old firewall/router adage somewhat obsolete. Today, it is difficult to tell the difference between the two. Routers are created with firewall feature sets that rival the most sophisticated firewalls and multi-homed firewalls can forward traffic at acceptable rates between subnets and speak all of the most common routing protocols. The functionality of the two devices is becoming one and the same, with the only difference being which vendor logo appears on the box.

For companies in this position, this section offers some advice on how to configure a router to operate as a firewall. Because these functions are also found in stand-alone firewalls, it will also be a good case study as to the implementation of the concepts discussed previously in this chapter. Finally, making a slight digression from the rest of this text, we will be speaking primarily about Cisco routers here. There are many fine and innovative router vendors out there and some that compete quite well with Cisco in specific markets; but for the market that we are discussing, where a router is likely to be used as a security device, Cisco dominates. When speaking of server operating systems, it is difficult to be specific without alienating a large portion of the market or including sections in your book for Microsoft Windows 2000, XP, various Linux flavors, and other UNIX-style operating systems — not to mention the numerous vendors that supply VPN products, authentication servers, and intrusion detection devices. Cisco routers however, primarily dominate access-routers and thus, playing to the demographics, we focus on that platform in this section.

Cisco or not, any commercial router that is likely to be found at the edge of a company network will allow you to do simple packet filtering. If the router is not your only firewall, you are going to be interested in filtering packets. Now that we have discussed what packet filtering is in the preceding text, we can now discuss what you would likely want to filter.

8.3.1 Packet Filtering Router and Firewall Together

Exhibit 5 illustrates a typical network set up with an access-router and a stand-alone firewall server. This section examines some of the more important implementation considerations that should take place in such a configuration. In this case, we know that the firewall is going to be doing the heavy lifting. Our goal with the router is to filter packets that we know are just plain wrong and let the firewall deal with packets that have the appearance of legitimacy. So what constitutes a packet that is "just plain wrong"?

Exhibit 5: Simple Network Diagram and Firewall Placement

With a little thought we can quickly come up with a list of things we do not think we should ever see on our network; these include:

We should never accept a packet from the Internet with a source of our own network number. This is called "spoofing."
We should never accept a packet from the Internet with a source address that is in the private address ranges of 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. This is most likely some form of attack, but may just be a misconfigured NAT device from a legitimate source. Regardless, the packet will never make it back to whomever sent it, so drop it at your router. These are also called "Martian addresses."
We should never accept packets with a multicast source address. Multicast addresses are found in the range of 224.0.0.0 to 239.255.255.255.
We should never accept packets with a source address from class E "experimental" addresses in the range of 240.0.0.0 to 255.255.255.254.
We should never accept packets that are sourced with an address assigned to the auto-DHCP range of 169.254.0.0/16.
We should never accept packets from the Internet with a source of all 0s or all 1s (0.0.0.0 and 255.255.255.255). These are illegal for use as source addresses and are most likely some form of attack.

Because these are all packets with addresses that should not be seen arriving from the Internet, we can safely discard them at our router and not burden the firewall with additional processing. While these rules are clear, there are others that fall into a grey area. Some of these and the considerations that surround them are as follows.

8.3.1.1 We should never accept packets from network numbers that are currently unassigned. These addresses are called "bogons."

While there is a great deal of discussion about IP addresses being used up, there are still quite a number of IP network ranges that are unassigned. Because nobody legitimately can be using these addresses, why would we be getting packets from them? Knowing that private addresses and clearly bogus addresses, as discussed above, are commonly dropped at the edge of a network, network-based attackers will commonly disguise their attacks by choosing addresses that look real, but are unassigned. Of course it makes sense not to accept these packets, but implementing this rule is another matter altogether. The assigned addresses are constantly changing. This prohibits router manufacturers from making a simple command that says, "filter bogons." Instead, the list needs to be manually created. Further-more, these lists change and, if your network manager does not keep up with the changes, legitimate traffic from the newly assigned network blocks will be dropped. Finally, there is nothing stopping a network-based attacker from simply changing the source IP address of an attack to someone else, in effect stealing a legitimate user's IP address.

The decision to filter "bogons" is one that is going to have to be based on your security policy. This filter does indeed provide more security than not having it; however, the cost of maintaining it must be weighed against the incremental increase in security.

8.3.1.2 Never accept packets from the outside that are destined to the router itself.

This rule simply states that packets from the Internet that are destined for one of the router interfaces should be discarded. Packets going through the router are unaffected; only packets with a destination of one of the routers IP address are filtered. Other than a bandwidth-based denial-of-service attack, any attack on the router itself is going to have to be sent to the router. It then stands to reason that denying traffic of this sort further increases the safeguards you have installed on your router. While effective, this configuration can also lead to problems in troubleshooting your network. Normally, there is no reason for someone on the Internet to be connecting to your router, unless it is the technical support of your service provider. If your ISP is managing your router, it is doubtful that this configuration will ever be included because your ISP cannot then connect to the router to make changes to it. If you get in a bind while managing your own router, then this configuration can make trouble-shooting from the outside more difficult.

If outside management is an issue, there are several ways to incorporate this into your network. The ideal solution is to never allow outside connections to your router and configure the router via a dial-up modem attached to a router auxiliary port. The high-tech solution to protecting the modem against war dialing ^[1] is to use a modem that supports user databases, hardware encryption, and authentication. The low-tech way is to keep the modem unplugged unless it is required and then someone local to the router plugs it in for use.

If the modem is not an option, then the router should be configured to accept only SSH connections. SSH, or Secure SHell, is an encrypted version of Telnet that encrypts all information sent, including usernames and passwords. This prevents someone from sniffing the log-in password but does not stop someone from guessing what that username and password are. SSH has occasionally been cracked on its own, meaning that if your router were running a vulnerable version of SSH, it could be compromised regardless of your other protection mechanisms.

Many protocols allow the configuration of a router but the commands and information are sent in cleartext and have weak authentication schemes. The least acceptable remote configuration protocols for routers are SNMPv2, ^[2] HTTP, or Telnet. HTTP servers on routers have been known to have security holes. A general rule of security is to run only essential services on computer equipment. In this case, HTTP is not essential and only increases the chance that someone will successfully attack your router.

As we can see, the strategy has been to simply filter packets that are clearly invalid. While the filtering capabilities of a router can be implemented in a much more complex manner, limiting our access-lists to this allows the router to perform at optimum efficiency while ensuring that our firewall only spends processing power on packets that are legitimately destined for our internal network. With this summary comes a brief editorial. It is a fact that access-lists do impede the performance of a router. That said, for your average T-1 connection, as long as they are constructed in a logical manner, your access-lists could be quite lengthy without impacting performance to the point where anyone notices.

^[1]War-dialing is the process of dialing a block of telephone numbers such as 1-802-555-0000 through 9999 and checking for computerized devices attached to the other end. Software to perform such scans is readily available from the Internet and easy to use. War-dialing is a popular method of circumventing corporate perimeter security by looking for a forgotten backdoor into the network via a modem.

^[2]SNMPv3 supports encryption. SNMP is a fine protocol with which to monitor routers, but allowing an SNMP agent to write to routers is not recommended.