Chapter 22

Chapter 22. Cisco Routers and Switches

IN THIS CHAPTER

·         The Problems with Infrastructure Equipment

·         Keeping Up with IOS Revisions

·         Securing and Configuring Cisco Routers

·         Network Management Considerations

·         Preventing Spoofing and Other Packet Games

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 focussing on the steps necessary to configure, deploy, and help keep your infrastructure equipment safe from hostile attackers . I have chosen to focus on Cisco products simply because they are by far the most predominant in use. However, users of products from Extreme, Juniper, 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.

The Problems with Infrastructure Equipment

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.

Cisco routers and switches have their own OS, otherwise known as Cisco 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 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 perma nently locking him out of your systems and network.

Note

The authors of the book @Large wrote about a cracker who had stolen thousands of passwords by compromising Internet backbones 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 OSs 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.

Note

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.

Keeping Up with IOS Revisions

Keeping "current" with IOS 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 to 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 focussed on stability, and are usually fairly "bug free."

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 here: 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.

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 .

Securing and Configuring Cisco Routers

Cisco routers are easier to protect, at a host-level, than many UNIX 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 such as BIND, IMAP, POP, or sendmail—services that have proven to be points of entry on UNIX-based 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.

Securing Login Points

Unfortunately, the majority of Cisco 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. Although Cisco IOS version 12.1 brought SSH version 1 to most router platforms, Cisco has yet to work out some of the bugs in their SSH implementation.

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 .

Until Cisco decides to get serious about using SSH (and hopefully they will adopt SSH version 2 sometime soon), we are stuck using Telnet. 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.

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 time-out 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, and 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.

Keeping Administrators Accountable

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 RADIUS or TACACS, administrators can tie their Cisco infrastructure to a centralized username repository such as 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.

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 .

Disabling Unnecessary Services

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 then sorry by using this command:

Router1(config)#no ip http server

Cisco devices have a Cisco-proprietary protocol called CDP, or Cisco Discovery Protocol. 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 this:

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

Note

It never hurts to double-check your work. Consider periodically running nmap against your routers to check for running services. It's a good habit to form, and it might save your butt some day.

Network Management Considerations

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 in to 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, 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.

Centralizing Logging

Security gurus will 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 alterna tives. 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.

Password Storage Considerations

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.

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 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

Time Synchronization

The network time protocol (NTP) was designed to synchronize the clocks of systems and net work 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

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 .

SNMP Considerations

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 Access Control Lists (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.

Preventing Spoofing and Other Packet Games

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. So important is the following material that, had the majority of network administrators implemented these suggestions, the massive distributed denial of service (DDoS) attacks that occurred in February 2000 might not have been possible.

Although certain types of DDoS starvation attacks will continue to be virtually impossible to stop, some preventative measure 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 net- citizens from your misfortune. If your infrastructure is designed and protected properly, should 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.

Egress Filtering

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 then 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.

The ICSA released a tool called NetLitmus that can be used for testing egress filtering. You can read more about it at http://www.icsa.net/html/communities/ddos/alliance/checker/index.shtml .

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

Chris Brenton wrote a brief but good paper on egress filtering for SANS. It's worth a quick read, and you can find it at http://www.sans.org/y2k/egress.htm .

Curious readers might also want to check out RFC 2267, "Network Ingress Filtering." The RFC discusses another method of helping defeat denial of service tools. RFC 2267 can found in a number of places, one them being http://archives.neohapsis.com/archives/rfcs/rfc2267.txt .

Stopping Silly Packet Games

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 solely 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 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.

Summary

Securing infrastructure equipment is critical for two reasons:

1.        If an attacker gains access to your infrastructure equipment, she can do an incredible amount of damage.

2.        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. Finally, as in dealing with any vendor, make sure that someone in your organization is monitoring Cisco security advisories. Timeliness counts with routers and switches, too.