Republished with permission of WatchGuard Technologies . Originally published January 4, 2002.
Basic IP Router Security
by Fred Avolio , Avolio Consulting, Inc .
This month, we’re looking at routing. This article considers security aspects of internetwork routing, and gives an overview of basic IP router security practices. I don’t intend for this to be a complete list, nor specific to a particular vendor’s routers. Rather, I present some general areas of concern — a roadmap for tightening the security of your routers. While this discussion applies to all routers, it is most critical for Internet-facing or other “border” routers.
What’s the buzz?
Routers — no surprise here — route. Internet Protocol (IP) routers facilitate communication among IP networks. We depend on lots of routers to facilitate communication from our enterprise desktops to anywhere else on the Internet. Routers try to do this as quickly and as seamlessly as possible. “Fast and transparent” is what users want. But that’s a concern for security practitioners, because usability is always inversely proportional to security.
Before Trojan horse and virus attacks became so devilishly easy to launch, attacks against the basic protocols in the Internet were accomplished through routers and their undying and exact support of those protocols, built-in weaknesses and all. (If you need an example, refer to Take-down in the Resources listed at the end of this article. Take-down is a hyped version of an historical attack that made the people on both sides famous for a while, was recounted in two books and a movie, and still surrounds the participants in litigation.)
Securing routers becomes even more important when we understand that, just as with many security devices, danger lies in default settings (your WatchGuard firewall excepted). Cisco, a leading router vendor, points out on their Web site, “This is particularly important because some of the default settings in Cisco IOS software are there for historical reasons; they made sense when they were chosen, but would probably be different if new defaults were chosen today. Other defaults make sense for most systems, but may create security exposures if they’re used in devices that form part of a network perimeter defense. Still other defaults are actually required by standards, but aren’t always desirable from a security point of view.” Of course, this state of enforcing outdated standards is not unique to Cisco products.
Obviously, critical connections to important networks should be protected. But how?
Start with controlling physical access to the routers. Then, since routers can all be configured and managed remotely, tightly control network access to them. Most routers support usernames and passwords, stored locally and also on TACACS+ and RADIUS servers. You know all of the insecurities associated with recycled passwords (passwords that are common across multiple systems or devices), so resist the temptation to recycle them. Do store passwords encrypted wherever they are stored (on the router or a server). Consider the implementation of single use password schemes such as CRYPTOCard or S/KEY if your router supports them. Use an encrypted connection for remote administration to limit your exposure to a packet sniffer copying the router’s password. IPsec or SSH are supported by some routers, and should be used whenever someone is remotely managing the router. And choose and use difficult to guess passwords . (Though as I think of it, this is practically impossible, but at least you can move away from usernames like “guest” and “anonymous” and passwords like “user.”)
Some routers come pre-configured with a well-known username and password, and allow in-the-clear administration via Telnet. Assume your routers do, and make sure you disable or fix these. And use different authentication secrets for each router. Paraphrasing Dr. Brian K. Reid, formerly of Digital Equipment Corporation, administrator convenience is the opposite of security, because it often becomes intruder convenience.
As mentioned above, routers support many things that today we consider insecure and ill advised — but they must, to support standards. That’s fine for the manufacturers. But for you — well, no IP police will call on you if you make the smart move of disallowing insecure “features” that you don’t use, or should never use.
What are examples of capabilities you should disable? One is “ IP source routing ,” which manufacturers must support to comply with standards. Another is “IP directed broadcasts.” Attackers use these features more than you do (since you probably don’t use them at all). Check your routers’ documentation to learn how to turn these functions off.
Border routers should also be configured to know what networks should be on which interfaces. Doing so disables many IP spoofing attacks. Strictly speaking, routers are supposed to be more flexible than this. Not border routers; not if you care about security. What possible good could it do to leave the public side of your router open to accepting packets from IP addresses reserved for private use? Why allow your router to pass outbound traffic “from” addresses that are not on your internal networks?
Just as with any server or system on your network, turn off any unneeded services on the router. Can it be configured via HTTP, but you never use that feature? Turn it off. A Tech Note from Cisco states, “The authentication protocol used for HTTP is equivalent to sending a cleartext password across the network, and, unfortunately, there is no effective provision in HTTP for challenge-based or one-time passwords.” And don’t tell me, “But it’s convenient!” Scary lists of other conveniences you should disable are mentioned in “Improving Security on Cisco Routers” (a Cisco Tech Note ), and the NSA’s Router Security Configuration Guide, listed under Resources.
Security folks assign SNMP (the Simple Network Management Protocol) an alternate meaning: “Security’s Not My Problem.” SNMP is used for remotely managing routers (or any other network device supporting SNMP). Routers run SNMP agents, allowing management (that is, changes to the router) from another system, such as someone’s desktop workstation. SNMPv1 and v2 are insecure. SNMPv3 supports key hashed message authentication codes (HMAC) and encryption. If you must use SNMP (yes, it is convenient, isn’t it?), and if you use common sense, you don’t need me to tell you, “Use only SNMPv3.” Somewhat less dangerous than SNMP is using its remote monitoring extension, RMON . (Think of RMON as an enhanced remote logging mechanism, such as what your Firebox does.) Still, you’ll typically only want to support this in a trusted environment (and that really means “nowhere”) or when the traffic is encrypted.
Other steps to take
Securing routers includes the same steps you find in a discussion about securing any kind of server or device. First, you have to stay up-to-date on security alerts and patches. You already get WatchGuard’s LiveSecurity broadcasts; now get on your vendors’ security mailing list as well. Other good sources of information are:
Employ strict configuration control over your routers. You’ll want to ensure that configurations are correct, easy to deploy, and easy to pull out so you can fall back to a previous working configuration. Attackers are bad enough, but mess-ups (that’s the polite term) are even more frequent.
Every security-related device must periodically be verified for correctness and integrity. Network vulnerability assessment tools ( vulnerability scanners ) are excellent for checking the things we’ve mentioned, and for looking for known problems with router configuration. ISS, Satan, CyberCop Scanner, and nmap can all be used to scan and test routers on your network.
Configuring your firewall is not enough to guarantee security. Harden your routers, too, and consider the task merely a starting point on your journey to true defense in depth. ##
“Improving Security on Cisco Routers ,” Cisco Tech Note
” Router Security Configuration Guide ,” National Security Agency Report Number C4-054R-00, Updated: November 21, 2001 (Version: 1.0j)
Two sides of one story:
Was this article useful to you? Is there a security topic you want our experts to tackle? Let us know at firstname.lastname@example.org .
For more helpful articles, log into the LiveSecurity Archive .
Copyright© 2002, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.