Principles and Practise of Cisco Router Security: Part I

by Lev Lafayette


Introduction

The foundation of network security is router security. As the gateway for the network, it is also the first line of defense. If the router is compromised, all else follows. Despite this sparse information is available for this critically important device with most texts concentrating on network security. Whilst an important topic itself, and which there are some excellent resources available, network security per se is not the purpose of this article. It is about router security in general and, given an approximate 80% market share, Cisco routers in particular.

Four main themes are discussed in this article. The first discusses router security within a general IT security plan, IOS software and standard access. The second theme discusses password security and authentication. The third theme discusses services, applications and protocol security. The final theme is concerned with NTP, logging and incident response. The article assumes a basic degree of knowledge of Cisco IOS, include Access Control Lists (ACLs).


Part One: Router Security Within A General IT Plan

Whilst must attention is often given by organisations on firewalls, VPNs, intrusion detection etc, routers are often left with simple configurations with the rather strange justification that they do not hold mission-critical data. However routers can be disabled, bringing down the entire network or blocking communication to and from the outside world. There can be internal attacks, often bypassing intrusion detect systems, and can be used as a base to launch external attacks (the difficult of tracing a hacker through several routers can be imagined). A compromised router can also be reconfigured, providing a "backdoor" to the network. With default configurations hackers can gather an extraordinary amount of detail concerning a network, including subnets, neighbouring equipment and redundant paths. Network traffic can be monitored, recorded and rerouted, a frightening prospect if online financial orders and transactions are redirected to 419-Nigeria Inc.

Basic probabilistic risk analysis should be conducted on all routers in an enterprise according to the standard formula of R=v(1..n)*t(1..n)*c(1..n) where R= total risk cost, t=threat, v=vulnerability, and c=cost. Essentially the likelihood of possible threats are multiplied by the vulnerability to each threat and multiplied by the likely cost of each threat. The aggregate amount is the total threat to the organisation. Risk analysis should be applied firstly to routers that are a gateway to the Internet, those that are part of a firewall, those that connect to secure networks and those that perform packet filtering. Engaging in probabilitic risk analysis for a router should occur independently of other network or server systems.

Physical access issues are, as always, the first priority in any security analysis. Access to mission critical routers should obviously be as secure as possible. Apart from locked heavy self-closing doors, this includes insuring that walls continue above and below raised flooring and ceilings and that air ducts are too small for access. Keep configuration backups in a separate secure place. Ensure adequate fire prevention (smoke alarms, extinguishers), water protection (e.g., link sprinkler activation to circuit breakers) and heat and humidty protection in the area. Ensure all equipment has UPS and the area is free from airbone dust. If all this seems excessive, recheck the Risk Analysis statement. Can your organisation afford to be lax on router security?

Of particular importance is the console port. As the main access port on Cisco routers, it is the only one enabled by default and is required for password recovery. For these reasons, a modem should never be attached to the console port. Given sufficient time on some routers it would be possible to perform password recovery remotely. Instead use the Auxiliary port to provide out-of-band access. This allows remote access to a router even if the network is disabled without compromising the fundamental security of the router.

Technical administrators often overlook the importance of warning banners on the Message of the Day (MOTD) statement. Whilst it is true that a warning is not going to stop a dedicated hacker, the apocryphal story of the router administrator who included the word "Welcome" in their MOTD banner and thus gave carte blanche to hackers is worth recalling. Obviously a MOTD does not provide technical protection. But it does provide legal protection. MOTD banners should provide enough warnings for legal prosecution to intruders (e.g., "Authorised Users Only"), protect administrators from liability, warn users about monitoring and system use policies (e.g., "Authorised Work Related Activities Only"). An MOTD should include that use of the system implies consent to these conditions. Do not include information such as the location of the router, the name of the administrator, contact information etc, all of which could be useful to an attacker. Similar banners can and should also be set for privi
leged and telnet login and AAA Authentication.

Following physical security and MOTD banners, the next important step is to ensure security in the Internetworking Operating System (IOS). Every IOS has security problems, even if Cisco would prefer that such issues were not made public [1]. The most well known security flaw in 2005 allowed unauthenticated, remote attackers on the same IP subnet to execute arbitrary code or cause a denial of service. This particular vulnerability affected all 12.* releases of the Cisco IOS requiring upgrades. As patches have been released, it is imperative that a router administrator ensure that their IOS is protected. In general, only GD (General Deployment) releases should be deployed, unless there is specific and particular reasons to run a different release. 


Part Two: Passwords and Authentication

There are many ways to access a Cisco router. Each way can provide different levels of authorization, from viewing router information to completely reconfiguring the router or some level in between. The default levels are 1 (user mode) and 15 (enable or privileged mode). The primary methods of access are through the console port, the auxiliary port, or network access through virtual TTYs (VTYs). Less common methods include HTTP, TFTP, and SNMP. Each access method requires its own configuration through well-known commands and is established through saving the running-config. It is recommended that on of the five VTY passwords is kept different from the other four to ensure administrator access at all times. 

Default Cisco router authentication does not require a login name. Problems arise when when more than one administrator has privileged access as there is no accountability. Therefore usernames and passwords should be set, along with local authentication on VTY, console and AUX ports. If VTY and AUX ports are not used then they should be disabled;

Router#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#line aux 0
Router(config-line)#login local
Router(config-line)#no password
Router(config-line)#transport input none
Router(config-line)#no exec
Router(config-line)#exec-timeout 0 1
Router(config-line)#^Z

Note that some of the commands here are somewhat counter-intuitive. Using the command 'no login' on a line will allow anyone to log in without a password. The 'no password' command removes the password but tells the router not to allow anyone to log in.

An alternative to local usernames is use of network access servers. The basic system in this regard is the Terminal Access Controller Access System (TACACS). Instead of each router being configured with usernames and passwords, it is configured to ask a TACACS server for information about who is allowed to log in to the router which is administratively a lot easier. However TACACS and X-TACACS have been declared at "end-of-maintenance" by Cisco, so it is recommended that if a network access server is used TACACS+ (Cisco's recommended service), RADIUS or Kerberos is utilised instead [2]. Note that Kerberos provide authentication not authorisation. If TACACS is used, a local password of last resort should be set in case the router cannot contact the TACACS server ('enable last-resort password'). TACACS doesn't differentiate between user-level authentication request and a privileged-level request. This requires Extended TACACS, RADIUS or TACACS+. When TACACS+ or RADIUS are used, configura
tion files must be kept secure, since TACACS+ and RADIUS keys are not obscured by the service password-encryption command.

TFTP provides no authentication. Whilst TFTP is normally used only when a router needs upgrading some routers download their configuration from a TFTP server. If attackers are able to compromise the TFTP server and modify the configuration files that reside on that server. When routers use TFTP servers for their configuration files, then the security of the router depends directly on the security of the TFTP server. Also, some new routers can be used as TFTP servers; if this is allowed (and if at all possible, it shouldn't) it should only be for the duration of file transfers then immediately turned off. Routers as TFTP servers is an enormous security risk.

Remote administration is a blessing and a danger. The two basic methods are dial-up in the AUX port and VTY or HTTP access with the latter only available when the network is up. Common dangers to remote access include sniffing, brute-force attacks, spoofing of source IP address, hijacking sessions, and compromise of trusted hosts (e.g., a TACACS or RADIUS server). Spoofing, sniffing and session hijacks can be prevented through using "out-of-band" access (i.e., dial-up/AUX), employing antispoofing filters and using strongly encrypted protocols such as SSHv2. Telnet should certainly not be used when SSH is available and should be disabled as it passes information in clear text. In addition to disallowing Telnet, it is also worthwhile limiting VTY access to a few secure IPs if possible through ACLs with an exec-timeout of several minutes at the most. 

If the router IOS does not support SSH services then it is still not a good idea to use Telnet; have a dial-in to a SSH server elsewhere (secure, trusted location) then use that to connect to the router. Use 'service tcp-keepalives-in' at global configuration to ensure that there are no orphaned connections (e.g., when a client crashes whilst connected, the server may still assume a connection exists). When using dial-up access to a router, ensure that both the AUX port and the modem are password protected and configure callback security ('service exec-callback') to a predefined number (this does result in the loss of some flexibility). This will require the local modem to be configured to accept incoming calls. Reverse telnet should be disabled on all physical ports ('transport input none' on config-line). 

Cisco has added HTTP web browser access to router management and monitoring. This is usually however a bad idea, as invariably information, including passwords, are sent through in plain-text. Further, the HTTP protocol provides no means to ensure token-based or single-use passwords. In general it is recommended that HTTP access be disabled ('no ip http server' at global configuration), but if it must be used, it should be limited by IP, with a limited privilege level and conducted through a VPN with IPSec.

Passwords themselves should always be set with the service 'password-encryption' from global configuration (weak encryption, Vigenere) as they are stored in clear-text in the configuration file. Privileged level (level 15) passwords should be set with the enable secret command (stronger encryption MD5) and should be significantly different than the password encryption and user level password. Passwords should of course in all cases be strong (foreign language phrases with numerical and special key components etc). Different routers should have different passwords and backup configurations should be kept on secure servers; note the use of the multiple. Serveral services, such as connect, telnet, rlogin, show ip access-lists etc should be reconfigured to privileged level.


Part II in the next issue