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