IN THIS CHAPTER
The Problems with Infrastructure Equipment
Administrators and security professionals alike often spend a significant amount of time configuring and securing the various firewalls, Web servers, and surrounding systems that make up their enterprise environments. Unfortunately, infrastructure devices such as routers and switches are frequently neglected in this effort. This neglect can often lead to sniffed sessions, route changes, and some overall Really Bad Things.
In this chapter, I will be focusing on the steps necessary to configure, deploy, and keep your infrastructure equipment safe from hostile attackers. I have chosen to focus on Cisco products simply because they are by far the most predominantly used. However, users of products from Extreme, Juniper, Nortel, or other routing and switching vendors might still find this chapter useful, as many of these techniques apply to non-Cisco equipment as well. Please note that this chapter assumes basic familiarity with Cisco routing equipment. Most of the examples in this chapter will be demonstrated on the “router” versions of IOS. Although the versions of IOS found on switches are similar, for simplicity’s sake we will only be showing examples from the router version of IOS.
NOTE
The authors of the book @Large write about a cracker who had stolen thousands of passwords by compromising Internet backbone routers and setting up customized sniffers. Although it is true that sniffing was easier back then (because many of the routers in the earlier days of the Internet were based on Unix operating systems such as IBM’s AIX), source code for Cisco’s IOS has been seen circulating through some underground channels. Although I know of no documented cases of Trojaned IOS code, it is certainly possible. People taking comfort in IOS being more “specialized” and subsequently more obscure, do so foolishly.
Although it is safe to assume that most hacking targets are end-node systems— such as Web, application, or database servers—many people foolishly ignore the security issues surrounding their infrastructure equipment. This can, unfortunately, be a colossal blunder. The truth of the matter is that not only can routers and switches be compromised, they can be used as stepping stones for further attack, as well as become incredibly useful information gathering devices for attackers.
Routers, switches, and hubs have their own OS. Cisco calls theirs IOS (Internetwork Operating System). Although Cisco’s track record with security is fairly good, it is by no means flawless. Cisco has had some security problems in the past, and as with any OS, if those problems are not patched or addressed, you leave yourself open to further troubles.
Of particular concern is the fact that routers and switches can be used to not only map target networks, but also to mask one’s identity, help create sniffing stations, and create some overall widespread chaos. For example, most Cisco switches have the capability to create a monitor port that can mirror or port span any other port on the switch. This effectively allows an administrator—or an intruder—to duplicate any traffic that the switch sees, and dump it down a specified switch port. So, although administrators might take comfort in their switched environment’s apparent immunity to the sniffer-based eavesdropping problems that HUBed environments face, all bets are off if the intruder has access to configuring the switch.
Other shenanigans can include static route entries and ICMP (Internet Control Message Protocol) redirect messages, conveniently disabled access control lists (ACLs), or even bizarre network address translation (NAT) rules. Rest assured that if an experienced intruder gets into your routing and switching architecture, you will have a very difficult time permanently locking him out of your systems and network.
Keeping “current” with OS changes is pivotal. Much as this point was driven home in the Microsoft, Novell, and Unix chapters of this book, the same holds true with Cisco IOS. However, Cisco actually does a better job with OS revisions, version control, and release strategies than most other software vendors. When Cisco says that a version of their software “is stable,” it might actually, in fact, be stable.
The first thing you should do while analyzing the state of your infrastructure equipment is investigate the various versions of IOS running on your systems. This can be accomplished by using the Show Version command. Should you discover that you are running older versions of IOS, consider the phrase “If it isn’t broken, don’t fix it” before moving towards massive upgrade efforts. More important than the age of the IOS version is where that version is in its release life cycle. Cisco has designated three stages that a particular IOS version resides in during its release cycle:
Early Deployment (ED)—. This is usually a version of IOS with new features that might still have some bugs in it.
Limited Deployment (LD)—. These IOS builds are usually considered “interim” builds. They are usually released with fixes to specific problems found in ED builds.
General Deployment (GD)—. General deployment builds are focused on stability, and are usually fairly “bug free.”
TIP
Cisco’s full release strategy is actually a fair bit more complex then what we’ve outlined previously—we are simply going over the basics here. A great document that details numbering, life cycles, and other versioning tidbits can be found on Cisco’s site at http://www.cisco.com/warp/public/cc/pd/iosw/iore/prodlit/537_pp.htm.
Although you might be tempted to use the “latest and greatest” version of IOS, I caution you to only use what you need, and to stick to GD builds whenever possible. GD builds tend to have the majority of the bugs worked out of them, and are usually quite solid. The only exception to this rule of thumb is in relation to security problems—if an IOS version contains a known security vulnerability, you really have no choice but to upgrade.
TIP
If you maintain Cisco equipment, it would be wise to subscribe to Cisco’s mailing list that announces the security field notices. You can find subscription information for the list at http://www.cisco.com/warp/public/707/sec_incident_response.shtml.
Hubs are the simplest of the three types of devices in this chapter by far. All hubs do is repeat all the packets they receive out of all the other ports. Two kinds of hubs are available: managed and unmanaged.
Unmanaged hubs are very simple. You plug them into the network, and that’s all you can do with them. The good news is that there is nothing a hacker can break into. The bad news is that it won’t provide you with any data when you have a problem.
Managed hubs will usually give you some traffic statistics and the ability to disable individual ports. Traffic statistics are good for looking for abnormal conditions. These devices enable you to remotely disable a port, which can be handy, especially if it is the weekend and you don’t have the keys to physically get to the hub.
The downside to a managed hub is that it will have either an SNMP, Telnet, and/or HTTP interface that enables you to perform remote management, which is another point of attack for crackers. If you are not using the remote management features, you should turn them off. How you do this depends on the vendor. If you are leaving them on, make sure to pick good passwords. We will discuss SNMP in more detail later in the chapter.
The difference between hubs and switches is simple. Switches only send traffic to those ports to which it needs to go. This stops users on a port from seeing all the traffic. This helps with network performance and security at the same time. Telling the difference between a switch and a router gets fuzzy because many “switch” products have routing-like functionality such as VLANs (Virtual Local Area Networks). Because this advanced functionality overlaps with routers, if you are using it, please read the router material below as well.
Virtually all switches are managed. The issue is the same as with hubs—turn off the management features if you are not using them. If you are using it, make sure to secure it as much as possible.
Routers are easier to protect at a host level than many Unix or Windows systems are, simply because they have fewer services that can be accessed remotely. Sure, they perform some complex routing calculations and play pivotal roles on the Internet, but they don’t have services running on them like BIND, IMAP, POP, or sendmail— services that have proven to be points of entry on Unix and Windows platforms again and again.
However, despite the fact that routers tend to be generally less accessible, a number of configuration tasks should be performed to limit a router’s accessibility even further.
Unfortunately, the majority of routers today are still managed over Telnet, which does not employ any type of encryption. Telnet passes all traffic in the clear, so it is quite easy to pick up login passwords if you have sniffers in place. Cisco IOS version 12.1 brought SSH version 1 to most of its router platforms. Unfortunately, Cisco is using the less secure SSH version 1 instead of version 2. Fortunately, we can do a number of things to help restrict access to Cisco routers, and help limit the chances of unauthorized users accessing our routers. On the other hand, Extreme Networks has a SSH2 Download for their ExtremeWare.
TIP
SSH is a secure replacement for Telnet (among other things). You can find out more about SSH at http://www.tigerlair.com/ssh/faq/ssh-faq.html.
You can log in to a Cisco router four ways:
Via the physical console port
Via the physical auxiliary port
Via other physical serial ports (only on models equipped with such ports, or lines)
Via telnetting into one of the unit’s IP addresses
Three of these methods require physical access, which makes our life a little easier. We will discuss the fourth method, logging in using Telnet, first.
Cisco routers have five virtual terminals, or vtys, that you can telnet to. There are two things you need to worry about with Telnet logins. First, you want to make sure that all the vtys have passwords enabled. You can do this by issuing the following commands from the configuration mode:
Router1(config)#line vty 0 4 Router1(config-line)#password fabi0!
This sets the vty password to fabi0!. Next, you will want to add a level of defense to help prevent attackers from telnetting into the router and remaining idle, which can tie up all five vtys. The following commands will not solve the problem entirely, but will definitely help:
Router1(config)#line vty 0 4 Router1(config-line)#exec-timeout 1 Router1(config-line)#exit Router1(config)#service tcp-keepalives-in
These commands set the vty timeout value to one minute, and force the use of TCP keep-alives to help combat orphaned sessions. In addition to these commands, you can use a standard access list to limit the number of workstations that can telnet into the router itself. For example, assuming your management segment (where you will be telnetting from) is 10.1.1.0, the following will limit inbound Telnet sessions to this range:
Router1(config)#access-list 1 permit 10.1.1.0 0.0.0.255 Router1(config)#access-list 1 deny any Router1(config)#line vty 0 4 Router1(config-line)#access-class 1 in
When it comes to physical access concerns, there are two things we want to watch out for: the console port and the auxiliary port. The auxiliary port is often used for “out of band” management via devices such as modems, so it is extremely important that this port be protected as well. You can protect both ports using passwords by issuing the following commands:
Router1(config)#line aux 0 Router1(config-line)#password fabi0! Router1(config)#line console 0 Router1(config-line)#password fabi0!
NOTE
There is one other method of helping combat the problems surrounding Telnet—don’t use it. Some administrators resort to recycling their terminal server and dial-up equipment, then attaching it to the Cisco router AUX or CONSOLE ports. They can then SSH or dial into the terminal server, and then hop onto the router from there. Also, directly connected dial-up access to routers is actually quite feasible because bandwidth is not an issue during text-based configurations. Just make sure that you require authentication.
Finally, in the interest of good auditing/accounting practices, it’s a good idea to remove the use of “shared” accounts. A shared account is one that is used by multiple people, with no method of clarifying true ownership. By default, Cisco devices have two levels of access: User mode and the privileged Enable mode. You can think of Enable mode as the equivalent of root in Unix, or Administrator in Windows NT.
By default, users are authenticated based solely on passwords—no usernames are required. This is true for both the regular Login mode, as well as Enable mode. Unfortunately, most organizations never move away from this model, and therefore have multiple people sharing the router passwords. By implementing AAA (Authentication, Authorization, and Accounting) services in conjunction with the RADIUS or TACACS authentication mechanisms, administrators can tie their Cisco infrastructure to a centralized username repository such as LDAP (Lightweight Directory Access Protocol), NDS (Novell Directory Services), AD (Active Directory), or any other centralized password store. By implementing such an authentication model, administrators will be forced to log in to routers using their username and password credentials, leading to the possibility of clean audit trails.
TIP
AAA configuration is beyond the scope of this chapter, but a good start to learning more on the subject (including sample configurations) can be found at http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt1/scathen.htm.
The next step in securing your Cisco equipment is to disable unnecessary services. Sound familiar? It should—this is the standard technique that should be employed across all OS platforms.
First, disable the small servers. These services are rarely used, and are not needed in most environments:
Router1(config)#no service udp-small-servers Router1(config)#no service tcp-small-servers
Next, disable the finger service:
Router1(config)#no ip finger
Although the finger service doesn’t pose any threat by itself, it can be used as a reconnaissance tool by hackers to scope out further information. After disabling finger, make sure that the HTTP (Web) server is not running. Although it is disabled by default, it’s better to be safe than sorry by using this command:
Router1(config)#no ip http server
Cisco devices have a Cisco-proprietary protocol called Cisco Discovery Protocol (CDP). Like finger, CDP is not a threat in and of itself, but can be used to gain information that an intruder shouldn’t have access to. You can disable CDP on a per-interface basis with these commands:
Router1(config)#int eth0/0 Router1(config-if)#no cdp enable
Or you can choose to disable it entirely by issuing the following:
Router1(config)#no cdp run
Finally, although I recommend using the Network Time Protocol (NTP) to synchronize time across your infrastructure (see the next section for NTP implementation issues), if you do not plan on deploying NTP, you should make sure it is disabled by issuing this:
Router1(config)#no ntp
Locking down terminal access and disabling unnecessary services are important steps in securing your infrastructure. However, the task does not end with a few configuration settings. There are a number of procedural and management aspects of infrastructure security that should be taken into consideration as well:
Do you keep backups of your router and switch configurations? If not, why not?
If so, where are those configuration files stored? Are they secure?
Are the passwords in those configuration files secure?
Do you track when people log into your routers, change configurations, or bring WAN links down?
Have you centralized your logging efforts for coordination purposes?
Can you monitor and manage your infrastructure securely?
Fortunately, down it’s not too hard to address most of these issues. With a little planning, a few service additions, and some configuration changes, even shaky situations can be drastically improved.
Security gurus will down explain that syslog is not the most secure protocol out there because it passes its information in the clear over UDP. Unfortunately, right now there are few alternatives. Assuming you have a syslog server set up, you can use the following commands to pipe your output to that server:
Router1(config)#logging trap notifications Router1(config)#logging facility local6 Router1(config)#logging 10.1.1.2
These commands will instruct the router to output all notifications (trap notification) to the logging host (10.1.1.2), using the facility local6.
NOTE
syslog uses facilities to help designate between log entry types: auth, auth-priv, cron, daemon, kern, lpr, mail, mark, syslog, user, uucp, and local0 through local7. You can think of these as simply categories of message types. Although you can configure your router or switch to report using any of these, most administrators pick one of the “local” settings for their infrastructure equipment. See the Unix man pages for syslogd and syslog.conf for more information.
Many people store their router configuration files and images on FTP or TFTP servers. Although keeping backup copies of both images and configuration files is a great practice, it is crucial that these files be protected. Make sure that the server they are hosted on is secure, and that the file permissions on those configuration files limit their accessibility. One good security measure is to only have the FTP or TFTP server up during the transfer and then shut them down immediately afterward.
NOTE
Frequently during penetration tests you will come across the systems that store the router configuration files. Although the routers themselves can be quite difficult to break into, after stumbling across unprotected configuration files you can usually decrypt the passwords and subsequently access the routers fairly easily. In these scenarios, the configuration files—not the routers themselves—become the weak link in the chain. You can read more about Cisco password storage at http://www.cisco.com/warp/public/701/64.html.
Next, consider implementing two precautionary measures on the password front. First, use Cisco’s “secret” password convention, as opposed to the normal “enable” password. The storage of the “enable secret” password uses an MD5 hash that is not reversible, but the regular “enable” password can be trivially decrypted. You can make the switch to using “enable secret” by using the following commands:
Router1(config)#no enable password Router1(config)#enable secret #fabi0!
This code removes the regular “enable” password, and replaces it with the “secret” password of #fabi0!. Another precautionary measure is to use the password encryption service available on most Cisco devices. This service applies to usernames and first-level login passwords only. Although the password encryption service still implements an incredibly weak encryption mechanism, it will at least allow you to avoid storing your user and login passwords in clear text. You can enable the password encryption service by using the following:
Router1(config)#service password-encryption
The network time protocol (NTP) was designed to synchronize the clocks of systems and network devices to some sort of time reference. NTP is an industry-standard Internet protocol, whose foundation was defined in RFC 1059. NTP is considered to be highly accurate, and quite transportable—there are implementations of it on Windows-based operating systems, Unix systems, and a myriad of routing and switching devices.
NOTE
Although something as seemingly trivial as time might not seem critical in the area of security, this couldn’t be farther from the truth. Time plays a critical role in basic auditing, accounting, and event correlation. I personally learned this the hard way when I was once asked by a client to track an internal user’s illegal activity on the Internet. The trail lead me to the proxy server logs, which were slightly out of sync with the log data I was given. I didn’t think this was a big deal until I realized that the proxy servers were servicing requests at the rate of 60-per-second! That minute’s worth of discrepancy sent me sifting through thousands of requests.
If you can successfully deploy NTP in your environment, you might be thanking yourself later. Assuming you have some NTP servers to poll from, the following commands will configure your router to synchronize with an NTP-enabled time source (in this case, an NTP server at 10.1.1.9):
Router1(config)#ntp server 10.1.1.9
TIP
The official NTP home page, which contains links to FAQs, RFCs, and code can be found at http://www.eecis.udel.edu/~ntp/.
You can also find a brief primer on NTP at http://www.nwc.com/1002/1002ws1.html.
Some organizations use SNMP heavily. Others do not, but leave the protocol enabled in hopes that some day their horrendously expensive network management “framework” product will do something useful. Regardless of what role SNMP plays in your environment, here are two bits of advice:
If you aren’t going to be using SNMP, disable it.
If you are going to use it, configure it properly.
Disabling snmp is pretty simple—simply find all your snmp statements and negate them with the no command, like this:
Router1(config)#no snmp-server community fabio RW Router1(config)#no snmp-server packetsize 2048 Router1(config)#no snmp-server engineID local 00000009020000107BCDE841
However, if you are using SNMP and cannot disable it, you can do a number of things to further secure its use. First, SNMP has essentially two modes: a READ-ONLY (RO) mode, and a READ-WRITE (RW) mode. If at all possible, use the READ-ONLY mode. By restricting the use of SNMP to READ-ONLY, even in the event that the community string is discovered, attackers will be limited to using SNMP for reconnaissance purposes. They will be unable to use it to modify configurations. If you must use the READ-WRITE mode of SNMP, make sure that your READ-WRITE and READ-ONLY community strings are different. Finally, you can use ACLs to restrict SNMP usage to only the workstations or management machines that need it. For example, if your network management segment is 10.1.1.0, the following ACLs will block SNMP from everything but that segment:
Router1(config)#ip access-list standard 1 Router1(config-std-nacl)#permit 10.1.1.0 0.0.0.255 Router1(config-std-nacl)#deny all Router1(config)#snmp-server community fabio RO 1
Remember, it is a good strategy to keep necessary services exposed to as few machines as possible.
NOTE
If you are not worried about the potential of SNMP being a security problem, please read the article at http://www.informationweek.com/story/IWK20020212S0007, which details SNMP vulnerabilities.
You might be tempted to skip this section. Don’t. If there is one thing you do with your infrastructure, I beg of you to implement these recommendations. The following material is so important that, had the majority of network administrators implemented these suggestions, the massive distributed-denial-of-service (DDoS) attacks that occurred in February 2000, and repeated on a smaller scale since then, might not have been possible.
Although certain types of DDoS starvation attacks will continue to be virtually impossible to stop, some preventative measures can be taken. Many of the denial-of-service attacks that occur on the Internet originate with forged, or spoofed, source addresses. This makes it incredibly hard for a victim to trace an attack back to its origin, much less stop it. The following precautionary measures will not only protect your network from some types of potentially hostile traffic, they will also help protect the Internet community as a whole from your network. Should any of your machines fall prey to malicious intruders, you can use your border routers to help shield your fellow netizens from your misfortune. If your infrastructure is designed and protected properly, in the event that any attackers beat your system administrators to the implementation of a patch, your routers might still be able to help stop hostile activity.
In short, implementing the following recommendations is not only a good idea for your own safety, but for the safety of the Internet community as a whole.
Frequently, network administrators keep a sharp eye on what enters their network, but never watch for what exits it. Filtering the traffic that leaves a network, or egress filtering, will help lower the risk of your environment being used as a DDoS platform, as well as make it less attractive to intruders.
The primary method used to stop outbound spoofing is the implementation of ACLs on the perimeter routers. It is generally considered a good practice to configure and apply these lists to the interface through which the packets come into a network, rather than the interface through which they leave. This not only makes the lists easier to read, but it also protects the router itself from spoofing attacks.
For this example, assume that the local network uses the address block of 172.16.1.0 (mask 255.255.255.0—a Class C). Also assume that the local area network is attached to the first Ethernet port, Ethernet 0/0.
With this configuration, you would want to make sure that all IP packets leaving the network have a source address falling in the 172.16.1.0 range. Anything not having a source address in that range is obviously spoofed. There are two steps to enforcing this policy. The first is the creation of the ACL itself:
Router1(config)#access-list 100 permit ip 172.16.1.0 0.0.0.255 any
The second is the implementation of the ACL on the proper interface, in this case, Ethernet 0/0:
Router1(config)#int eth0/0 Router1(config-if)#ip access-group 100 in
TIP
Chris Brenton has written a brief but good paper on egress filtering for the SANS Institute. It’s worth a quick read, and you can find it at http://www.sans.org/y2k/egress.htm.
Ingress (or inbound) filtering is very useful in defeating denial-of-service attacks against your network. RFC 2267 (http://archives.neohapsis.com/archives/rfcs/rfc2267.txt) describes it in detail.
You can manually configure ingress filters. The process is similar to egress filtering, except the filters here are on the external connections instead of the ethernet port. However, we are going to look at an easier way to implement it.
Cisco released the Unicast RPF (Reverse Path Forwarding) feature in IOS 12.0 (it was also in an earlier 11.1(CC) release) to try to mitigate problems caused by bad source addresses in packets. If this feature is enabled on a router interface, the router will verify that the source address is in the routing table for that interface. If it is not, the packet is dropped.
What’s nice about this feature is it’s much easier to implement than specific egress filtering, though it serves the same purpose. One major downside is that it assumes symmetrical routing. If you have asymmetrical routing in your network, this feature will cause a lot of connections to fail.
NOTE
Symmetrical routing is when packets going out and packets coming back in follow the same path across the network. Asymmetrical routing is when the packets going out take one path across the network, but the packets coming back in take a different one.
This feature depends on the Cisco Express Forwarding (CEF) feature, which is an easy to setup switching system built into Cisco router. CEF must be enabled on the router first:
Router1(config)#ip cef
Then you enable it on each interface:
Router1(config)#int ethernet 0/0 Router1(config-if)#ip verify unicast reverse-path
There are a number of tricks and miscellaneous packet nonsense that attackers might attempt when attacking your network. Although the likelihood of their success using only these techniques is rather limited, you still don’t want this type of traffic bouncing around on your network.
First you’ll want to disable IP source routing. IP source routing allows for the specification of a predefined path that a packet should take, and is often used in spoofing-based attacks. Packets being source routed rarely have a legitimate origin. It is therefore safe to disable this feature on at least your Internet-facing routers, with this command:
Router1(config)#no ip source-route
Another common attack uses directed broadcasts in an effort to flood a victim’s network with ICMP echo replies. This attack, otherwise known as smurfing, can be used to channel a number of networks to mistakenly respond to ICMP echo requests that were forged en masse. Unless you know of a specific application in your environment that might rely on directed broadcasts, you should disable this feature on every active interface of every active router:
Router1(config)#int ethernet 0/0 Router1(config-if)#no ip directed-broadcast
It is a good idea to disable proxy-arp on interfaces that don’t require it:
Router1(config)#int ethernet 0/0 Router1(config-if)#no ip proxy-arp
Finally, there are a number of ICMP services that you might want to disable. However, because a number of ICMP services are quite useful, and sometimes even required for proper functionality, our recommendation is to start by disabling ICMP redirects and move on from there, if necessary. The easiest way to disable ICMP redirects is with the following:
Router1(config)#int ethernet 0/0 Router1(config-if)#no ip redirects
However, if you want to gain more granular control over ICMP, you might want to look into using ACLs.
Securing infrastructure equipment is critical for two reasons:
If an attacker gains access to your infrastructure equipment, she can do an incredible amount of damage.
If security is executed properly, not only will you protect your own network, you will help protect the Internet as a whole.
The steps we’ve outlined are fairly simple to implement, but can still be very effective. You should try to test your configuration as much as possible. The NCAT (Network Config Audit Tool) and RAT (Router Audit Tool) can be found at http://ncat.sourceforge.net/. Finally, as in dealing with any vendor, make sure that someone in your organization is monitoring the security advisories of all the network equipment vendors you have in your shop. Timeliness counts with routers and switches, too.