Chapter 10. Auditing Cisco Routers and Switches
Solutions in this chapter:
▪ How a Router Can Play a Role in Your Security Infrastructure
▪ Router Technology: A TCP/IP Perspective
▪ Understanding the Auditing Issues with Routers
▪ Sample Router Architectures in Corporate WANs
▪ Router Audit Tool (RAT), Nipper
▪ Security Access Controls Performed by a Router
▪ Security of the Router Itself and Auditing for Router Integrity
▪ Identifying Security Vulnerabilities
▪ Audit Steps over Routers
▪ Sample Commands
▪ Cisco Router Checklists
Summary
Introduction
In this chapter we will focus on Cisco routers because Cisco has the largest market share of internet-based routers. The addition of statefull packet filtering and statefull inspection, and a wide range of supported protocols, dependent on licensing; make Cisco the ideal subject for discussions of router auditing.
Next, the command line nature of the Cisco IOS makes it possible to script configuration checks, and it is far simpler to take the knowledge gained on a Cisco router at the command line and transpose this to use on a Web-based or otherwise graphically-based configuration utility that many other products deploy. One of the major benefits of the Cisco range is that Cisco routers have a consistent command set across their entire product range. Although it is unlikely the full range of routing options, serial interfaces and other things that you may find on a 12000 series will be available on a 1600 series router, by and large the majority of commands are nearly identical.
Many of the same techniques used for routers may also apply when reviewing and auditing switches. In this section we will also point to a number of resources that will aid in the development of both your router and switch audit checklists.
Functions of a Router, Its Architectures, and Components
Routers, switches, and transmission equipment form the backbone of the Internet, yet most auditors do not understand how they work and how they fit into the bigger picture of security and functionality.
A router is designed to transmit packets between different networks. In addition, a router can also act as a control point, filtering unwanted protocols, networks, and other security concerns. Routers also act as a gateway between local and wide area networks. Routers are often used as relays for network attacks. Privileged access to the router may be used to reconfigure it or cause a Denial of Service (DoS) attack. Controlling interactive logons to the router helps prevent these and other conditions from occurring.
Modes of Operation
The auditor should be familiar with the variety of privilege modes on the router. By quickly looking at the current router prompt, it is possible to determine the current privlege level. Listed below are the prime modes of operation for a Cisco device:
▪ Nonprivileged mode: router>
▪ Privileged mode: router#
▪ Global configuration mode: router(config)#
▪ Interface configuration mode: router(config-if )#
▪ ACL configuration mode: router(config-ext-nacl)#
▪ Boot loader mode: router(boot)
▪ Remote connectivity config mode: router(config-line)#
The difference between these operational modes is linked to what the router will allow. For instance, in non-privileged mode it may be possible to view selected settings but it is not possible to change any. Cisco Routers allow the configuration of numerous settings based on a privilege level. There are more than the standard non-privileged and privileged operational levels that are commonly deployed and the auditor should become familiar with these.
It is unlikely that everyone who accesses a router will require the same level of access. Through the careful use of privilege levels, a site can limit the commands users can run on routers. Privilege levels can be difficult, but practice will quickly give any auditor full knowledge of how to understand the level of privilege settled router. Visit www.cisco.com/univercd for documentation on configuring privilege levels.
Configuration Files and States
The auditor needs to understand a number of configuration files and states.
When the router boots, or initially starts up, it will load the startup-config. This is the initial configuration controlling the system by default. The configuration that is loaded at boot time may not be the same as the policy and configuration that is actually running and used by the router. Consequently, it is essential to never trust the default policy and configuration alone. To check this it is necessary to view both the running-config and the startup-config.
The running-config may or may not be the same as the startup-config. The running-config is, however, the actual configuration being used by the router, as all changes made to the configuration while the router is running are made to the running-config. This can be useful as the changes will not be written to the startup-config by default. As a result, if administrators creates bad policies and locks themselves out of the router, a simple reboot will take them back to the previous configuration.
To view the configuration that is loaded at boot time, the following command would be issued:
<Site_Router># show startup-config
Notice that the router is in privileged mode. <Site_Router> is the host name of the router that has been set. To then view the actual configuration of the router the auditor would issue the command:
<Site_Router># show running-config
It is important to check whether the startup and running configurations are the same. There are a variety of methods to do this, and it may be simple enough on small configurations to do this manually. On more complex configurations running a command such as diff may be useful to point out the differences in the configurations.
Remember: Work with the network team. The auditor's role is not to take over a system nor to run it. The best results come from working in concert. Let the network administrator log onto the router. and you will never have to ask for the administrator's password. This both builds trust and means that the auditor will not be blamed for unforeseen changes to the router configuration.
How a Router Can Play a Role in Your Security Infrastructure
The router can do more than simply move packets. Many routers, including Cisco routers, support a combination of static packet filtering and statefull filtering. Further, routers can add a layer of encryption, support the creation of Virtual Private Networks (VPNs), ensure that compliance with protocol standards is met, and log traffic for both network analysis and security (for example for incident handling or forensics).
Static filtering is most useful when working with absolutes. It is best used in filtering blanket traffic restrictions. Such a consideration would be the creation of Bogon lists designed to restrict access from known bad or non-existent networks. This would include blocking access to internal networks from the Internet. Some other things that could be considered would be blocking all access to a secured management network or a universal restriction blocking all private IP address, SNMP ports, Telnet and inbound ICMP/PING (Internet Control Message Protocol).
Stateful inspection is best for conditional traffic filtering. Conditional traffic filters are those based on complex rules (such as allow HTTP traffic from this address at these times). After a static filter has been applied to block the universals, staple filters could be applied to everything else. The deployment and architecture of routers on your network should be based on the controls used around the perimeter. Never consider the routers in isolation. Browsers both support and increase the security of firewalls and other devices on your network.
Router Technology: A TCP/IP Perspective
An often difficult and intricate skill is the configuration of a router, and the writing of its ACL (access control list). Understanding how to appropriately configure routing protocols, such as Border Gateway Protocol (BGP), Enhanced Interior Gateway Protocol (EIGRP) and Open Shortest Path First (OSPF) in the case of internal routers, can be reasonably complicated to set up properly. Once the initial configuration has been completed, the router should require only minimal maintenance, and a baseline image can be taken.
The most difficult aspect associated with auditing a router is the maintenance of ACLs that have been configured. The order, function and testing of ACLs needs to be conducted on a regular basis to ensure that these have not been removed and that they are functioning correctly. These decide what is and is not allowed entry into the network. These rules have a syntax of their own, and it is essential that an auditor working with network equipment gains an understanding of the syntax employed. The position and order of these rules is vital to the security of the network behind the router and of the router itself. It is rarely adequate to test the system by reviewing the rules alone. A process to send packets through the device is generally warranted to ensure that the ACL is applied and is taking effect.
Understanding the Auditing Issues with Routers
Cisco has developed several security features including packet-filtering access lists, the Cisco IOS Firewall Feature Set, TCP Intercept, AAA, ACLs and encryption. Other features, such as packet logging and quality of service features, can be used to increase network security against various attacks. Also consider when auditing routers that access control lists are generally first match. By this we mean that the packet is matched to the first access control list entry found to match the contents of the packet, and this is the entry that is applied. Cisco also allows the use of many default names for packets. As such, it is possible to create an access list using Telnet instead of Port 23 TCP.
In the creation of an access list, it is important to note that port ranges may be used instead of a single value. Further, wildcard addressing on the Cisco router can be extremely complex. Keywords may be considered instead wildcards to replace values such as 255.255.255.255 and 0.0.0.0 with any or host respectively. By default as soon as any access control list is applied to an interface, an implicit deny rule comes into existence.
Authentication, authorization, and accounting (AAA) is the set of processes and tools used by Cisco to add advanced user access controls to its systems. See www.ciscopress.com/articles/article.asp?p=170744 for details.
Password Management
The main protection against unauthorized access to a router is a password. Terminal Access Controller Access Control System Plus (TACACS+) or Remote Authentication Dial-In User Service (RADIUS) authentication servers are the most effective method of password management, and use the Cisco AAA method. It is rare for a router not to have a local password privileged access.
The command that is used to set the password for privileged administrative access to the system is enable secret. The enable secret password should always be set. The enable password command uses a weak encryption algorithm and should not be used. Always ensure that enable secret is set on the router. Failure to set the enabled secret password may result in the console password being able to get privileged access even from a remote virtual type terminal (VTY) session.
Service Password Encryption
Use the service password-encryption commands to direct the IOS software to encrypt all passwords. (Challenge Handshake Authentication Protocol (CHAP) secrets, and similar data is saved in the configuration file and may be accessed by a casual attacker otherwise). This is used to protect access to passwords that may be read from configuration backups another such sources.
The default algorithm used by service password-encryption is a simple Vigenere cipher, which may be reversed. For this reason, great care should be taken to protect any Cisco configuration file. This warning applies to passwords configured using the enable password command and not those set with the enable secret command. The enable secret command uses an MD5 hash.
Note
Although MD4 is stronger than a Vigenere cipher, there are better methods available. The use of AAA and external authentication systems will add additional layers of security.
Console Ports
The console port of a Cisco IOS device has an astonishing level of privilege. During this initial boot phase, once you have sent the BREAK sequence, you can enter password recovery mode.
For this reason any modem or network connection accessing the console port needs be secured adequately.
Interactive Access
Cisco IOS software supports connections via Telnet; remote login (rlogin), Secure Shell (SSH), non-IP-based network protocols (for example LAT, MOP, X.29, and V.120), and local asynchronous connections and modem dial-ups. It is essential to ensure that appropriate controls are applied on both VTY lines and TTY lines, or the system security may be compromised.
It is good practice to block interactive logons on any line by configuring the login and no password commands. This is the default configuration for VTYs, but not for TTYs. Whenever the router is connected to a nun trusted network management should be conducted over an encrypted link. Cisco supports both SSH and the use of IP Security (IPsec) to encapsulate Telnet and other protocols. The simple solution, however, is to simply implement SSH.
Note
SSH may not be available on all IOS feature sets. Encryption adds additional burdens to the router's processor and also adds complexity. See the Cisco configuration guidelines at www.cisco.com for details.
TTYs
Local asynchronous terminals are generally used to access serial and console lines on network equipment and hosts (that is, as a terminal server) or connected to external modems. By default, a remote user can establish a connection to a TTY line over the network (also known as reverse Telnet).
To disable the reverse Telnet function, use the command transport input none to all asynchronous or modem lines that need to be disabled. Don't use the same modems for both dial-in and dial-out, and never permit reverse Telnet connections into dial-in lines.
Controlling VTYs and Ensuring VTY Availability
VTYs may be configured to accept connections with selected protocols using the transport input command (for example VTYs configured to receive only Telnet sessions (TCP 23) can be configured with transport input Telnet, while a VTY permitting both Telnet and SSH sessions would have transport input telnet ssh). Use the ip access-class command to restrict the IP addresses from which the VTY is able to accept connections.
Note
The access-class command provides the capability to log access to the router through the addition of the work log at the end of the permit lines in the ACL. See the Cisco IOS Security Configuration Guide for further details (www.cisco.com/en/US/docs/ios/12_4/secure/configuration/guide/h_login.html for IOS version 12.4).
A Cisco IOS device has a limited number of VTY lines. Reducing exposure to DoS attacks against the VTY lines by configuring a more restrictive ip access-class command on the last VTY than on the other VTY lines is considered good practice. The final VTY (for example VTY 4) should be restricted to accept connections only from a single, specific administrative workstation or IP address.
Also configure VTY timeouts using the exec-timeout command to prevent an idle session from indefinitely consuming a VTY. Enable TCP keepalives on all incoming connections (with the command service tcp-keepalives-In) to help defend the system against both malicious attacks and orphaned sessions.
VTY protection may also be implemented by disabling all non-IP-based remote access protocols, and using IPsec encryption for all remote interactive connections to the router.
Note
IPsec requires the Cisco IOS encryption feature set.
Warning Banners
As with all systems it is good practice to use a logon banner. This is configured on Cisco routers using the IOS banner logon command.
A sample warning banner is shown in Figure 10.1.
 |
| Figure 10.1 Logon Banner Example |
Common Management Services
The most common IP Based management protocols used on routers (other than Telnet and SSH) are SNMP and HTTP. The Cisco discovery protocol (CDP) is also commonly used, but its use is limited to local networks. This does not mean it is secure, just that the access needs to be local.
SNMP
Simple Network Management Protocol (SNMP) version 1 should not be used for the following reasons.
▪ It uses cleartext authentication strings (community strings).
▪ SNMP sends the strings repeatedly.
▪ SNMP is an easily spoofable, datagram-based transaction protocol.
If SNMP is necessary within your organization, use SNMP version 2c or SNMP 3 (if at all possible) and always configure digest authentication with the authentication and md5 keywords of the snmp-server party configuration command. It is good practice to implement different MD5 secret values for each router.
HTTP
If Hypertext Transfer Protocol (HTTP) is used for management of the router (not recommended), always restrict access to appropriate IP addresses using the ip https access-class command.
Also configure authentication using the ip http authentication command. As with interactive logons, HTTP authentication may be configured to use a TACACS+ or RADIUS server. Never use the enable password as an HTTP password.
Note
The Cisco Security and Device Manager (SDM) is accessed via Hypertext Transfer Protocol over Secure Socket Layer (HTTPS). The addition of Secure Socket Layer (SSL) is an effective means to implementing additional security on a Cisco IOS router if management over HTTP is required.
Logging
Cisco routers are configurable to be able to record information about a variety of events that could have security significance. Logs are an important tool in characterizing and responding to security incidents.
The main types of logging used by Cisco routers are:
▪ AAA logging collects information about user dial-in connections, logons, logouts, HTTP accesses, privilege level changes, and commands executed. AAA log entries are sent to authentication servers using the TACACS+ and/or RADIUS protocols. AAA logging is configured using the AAA configuration commands (for example aaa accounting).
▪ SNMP trap logging sends notifications to SNMP management stations.
▪ system console logging (command logging console).
▪ syslog servers, such as UNIX (command logging ip-address, logging trap).
▪ VTYs and TTYs sessions (command logging monitor, terminal monitor).
▪ local logging buffer in RAM (command logging buffered).
The most important security events recorded by system logging are interface status changes, changes to the system configuration, access list matches, and events detected by the optional firewall or intrusion detection features.
System logging events are tagged with an urgency levels. Levels range from debugging information (syslog level 7) to major system emergencies (syslog level 0). The syslog command allows the router to send its logs to a central syslog server. This allows for segregation of duties, as logs can be removed from the control of the router administrator, and also provides an alternate location to store logs. If the router is compromised, one of the first things an attacker will do is delete the logs. A separate syslog server adds an additional layer in creating defense in depth.
Note
It is possible to send syslog messages to up to sixteen syslog servers. This can be used to allow more than one person to monitor the logs and, thus, provide additional security.
Sample Router Architectures in Corporate WANs
When auditing systems, thinking outside the box is essential. One of the best ways of coming to understand the interactions between routers and systems is to recreate the network. Virtual hosts and network simulators that were designed for training purposes and configuration can also serve the auditor, although this is rarely done in the field as very few auditors even though these tools exist.
One of the best packages for this is the Boson Network Designer (www.boson.com/AboutNetSim.html). This software allows for the creation and simulation of network protocols and interactions as shown in Figure 10.2.
 |
| Figure 10.2 Boson Network Designer |
The auditor can use simulators to validate the assertions of the network administrator. The creation of a logical map mirroring the network map allows the auditor to load the router and switch configurations obtained during the audit. In doing this, the auditor can compare the results of testing from the real system against the simulated system. In the event that the configuration file supplied for the audit does not truly match the running configuration, there will be differences between the results obtained in testing the live network and those obtained testing the simulated network.
Further, the auditor is able to recreate the environment and test it in a manner that would not be permissible on a live network. For instance, denial-of-service attacks and other packet testing that would not be allowed on a live network may be done on a simulated network.
In cases where there is a sufficient budget it is possible to create a test lab. This option is far more expensive than the simulated environment.
Network simulators can run in host mode (see Figure 10.3). Depending on how complex you wish to make the environment, you may limit the host to a simple virtual environment or integrate a number of complex virtual machines. It is rarely necessary to simulate all aspects of the environment. Generally, only a simple and basic representation of the hosts will be needed. Generally, what is required is the ability to monitor network traffic that is then sent and to ensure that the configuration will adequately support the security goals. As an example, it is essential to ensure that access control lists are not only correctly constructed but also applied to the individual interfaces.
 |
| Figure 10.3 Boson Network Simulator in Host Mode |
One of the main strengths of these types of tools is the ability to load existing network configurations. Although these are generally limited to an individual type of device (in this case Cisco), the capability to visualize the configuration of a complex switch can be invaluable to the auditor (see Figure 10.4).
 |
| Figure 10.4 Boson Network Simulator in Virtual Switch Mode |
In particular, the ability to see what routing protocols are active, what protocols are filtered and create a network map that actually reflects the configuration and settings supplied makes reviewing a system far simpler. After all, configurations can become very large and the human mind is better at looking at visual representations than it is at scrolling through reams of documents. It is more likely that you will find an interface that is incorrectly configured through a visual representation than manually reviewing documents containing configuration details.
There are a number of tools that do provide some of these capabilities, and these will be discussed later in the document.
For the moment, however, your main concern is with validating the information you have received. In the homogeneous network consisting of all Cisco devices, a single simulator will allow us to create a reconstruction of all the devices on the network.
Using this type of configuration you can do things such as connecting from one router to another and verifying that access is either allowed or restricted based on the controls reported to be in use (see Figure 10.5 and Figure 10.6).
 |
| Figure 10.5 Boson Network Simulator Remote Control |
 |
| Figure 10.6 Boson Network Simulator in Virtual Router Mode |
The additional benefit is that an interactive network map provides far more information than a basic Visio diagram ever could. It is simple in a Visio diagram, for instance, to add or subtract equipment that does not exist. When you have a simulated network environment created through the actual existing configurations, it becomes difficult to hide connections or networks.
Being able to see how both the routers and switches interact provides you with far more information than individually testing either one of these alone.
In the event that you wish to test more than just simple connections, tools such as the NMS Network Simulator provide a complete interactive environment (see Figure 10.7). These types of simulators are far more comprehensive than Boson and related tools, but they are far more expensive.
 |
| Figure 10.7 NMS Network Simulator |
Router Audit Tool (RAT) and Nipper
Another way of auditing row configurations is the use of automated tools such as the Router Audit Tool (RAT) and Nipper. Tools such as these allow the auditor to run preset tests against stored configurations and see how these apply against a number of standards.
The primary ability of such tools is that they allow for scripting. The creation of a script that can periodically pull live configurations allows the comparison of the router configuration to a baseline and provides the capability to script alerts in the event that a non-authorized change has occurred. In addition, a script is also useful to take periodic samples of devices and test their security and configuration status.
RAT
The Router Audit Tool (RAT) was designed to help audit the configurations of Cisco routers quickly and efficiently. RAT tests Cisco router configurations against a baseline. After performing the baseline test, RAT not only provides a list of the potential security vulnerabilities discovered, but also a list of commands to be applied to the router in order to correct the potential security problems discovered. RAT is available from the Centre for Internet Security (CIS) website www.cisecurity.org/bench_cisco.html.
Aside from providing an industry-accepted benchmark for the Cisco IOS, RAT helps solve the following issues:
▪ Difficulty maintaining consistency
▪ Difficulty detecting changes
▪ Need to quickly fix incorrect settings
▪ Need for reporting and customization
▪ Need to check non-IOS devices
Although RAT does provide many useful functions, it is not actively updated, and therefore requires the user to check from time to time for the latest version releases and patches. Also, as powerful as it is, there are a number of issues that it does not address such as:
▪ Management issues
▪ Poor operations practices
▪ Vendor code
▪ Protocols weaknesses
▪ Host-based problems (viruses, code red….)
▪ Bandwidth-based new DoS vulnerabilities
▪ Local configuration choices
▪ Need for competence and vigilance
▪ Non-Cisco devices not yet supported
How RAT Works
RAT was written in Perl. It consists of four other Perl programs: ncat, ncat_report, ncat_config, and snarf.
▪ snarf is used to download the router settings.
▪ ncat reads the rulebase and configuration files and provides output in a text file.
▪ ncat_report creates the html pages from the text files.
▪ ncat_config is used to perform localization of the rulebase.
The rules and baseline document are licensed by the Centre for Internet Security. RAT performs an audit by comparing text strings in the configuration file from the router with regular expressions in the rules. Each rule has either a required or forbidden regular expression element. Based on this element RAT determines if a rule is passed or failed. Due to the use of regular expressions, the RAT rulebase is extremely flexible. There are currently Level 1 and Level 2 audits that can be performed. The Level 1 audit is based on the National Security Agency (NSA) guidelines. The Level 2 audit includes additional tests from several sources, including Cisco. The majority of the rules are for the protection of the router. However, several rules provide limited protection to the networks they serve. Additional rules can be added to the rulebase with relative ease. This allows RAT to work with any configuration.
How to Install RAT
Installing RAT is fairly simple. First, download the installer from www.cisecurity.org/bench_cisco.html. For Windows users, select the win32 native installer.
1 Ensure that any previous versions of RAT are no longer installed; if necessary, use the Windows Add/Remove Programs control panel to uninstall a previous version of RAT.
2 Run the installer, either by double-clicking on it or by selecting it through the Windows Add/Remove Program control panel. You may be asked to restart your computer at this point.
3 At the CIS RAT logo splash image (see Figure 10.8), click Next.
 |
| Figure 10.8 CIS RAT Logo |
4 In the Welcome page shown in Figure 10.9, click Next.
 |
| Figure 10.9 CIS RAT Welcome |
5 After reading the Licensing Agreement shown in Figure 10.10, select I accept the terms… and click Next.
 |
| Figure 10.10 CIS License Agreement |
6 Read the background information presented on the next page of the wizard shown in Figure 10.11 and then click Next.
 |
| Figure 10.11 CIS RAT Release Notes |
7 Select a directory where RAT should be installed as shown in Figure 10.12. For best results, do not select a directory with spaces or special characters in its name. If the default is acceptable on your system, then use it. Then click Next.
 |
| Figure 10.12 CIS RAT Destination Folder |
8 Choose an installation type as shown in Figure 10.13. Most users require only the Basic setup. Then click Next.
 |
| Figure 10.13 CIS RAT Setup Type |
9 Verify that the installation settings are correct and then click Install (see Figure 10.14).
 |
| Figure 10.14 CIS RAT Ready to Install |
11 Click Finish (see Figure 10.15).
 |
| Figure 10.15 CIS RAT Installed and Ready to Use |
Read the documents rat.html and ncat_config.html in the doc subfolder to view relevant options and files. For more information on running RAT on Windows, see the file etcREADME.WIN32.txt. For information on running RAT specifically for Cisco PIX, see the file etcREADME.PIX.txt.
Note that the file etcOLD-INSTALL.WIN32.txt contains instructions for another, older, more complex method of installing RAT on Windows. This involves installing ActiveState Perl, and downloading and installing Perl (CPAN) modules. This is not recommended for most users.
How to Run RAT
Prior to running RAT, determine whether router configurations are going to be obtained directly from the router, or if they have already been downloaded and saved into a file. In the case of the latter, the path to that file should be specified when invoking RAT on the command line. Alternately, with the use of the –snarf switch, RAT will log onto the routers specified (you have to provide logon info and the router's IP address), pull down the configurations, audit them against a set of rules, and produce several output files.
There are several options (switches) that can be used to control the behavior of RAT. These switches are supplied later in the chapter. In the example shown in Figure 10.16, the configurations of the router are contained in a text file called syd_1760rt_06082007.txt.
 |
| Figure 10.16 Running RAT |
In this example it is assumed that the path to the directory where the RAT executables and supporting files has already been established. In the default installation, those files and folders are located at C:CISRAT. Also, there are several ways of saving the router configuration file to a file. However, HTTP, TFTP or Telnet methods are not recommended, as they produce output in clear text, and therefore pose a risk to confidentiality. Pressing the ENTER key after entering the command shown in Figure 10.16 resulted in the display shown in Figure 10.17:
 |
| Figure 10.17 CIS RAT Having Been Run |
Several files have been created after running RAT against the configuration file. If you list those files using the dir command, you get the listing shown in Figure 10.18.
 |
| Figure 10.18 CIS RAT Creates Several Output Files |
The details of the output files that are created by RAT are included in Table 10.1.
The generated index.html file is shown in Figure 10.19.
 |
| Figure 10.19 CIS RAT Report Page |
Clicking the Description of Rules link brings up the rules.html file shown in Figure 10.20.
 |
| Figure 10.20 CIS RAT Rules Display |
After you go back to index.html and then click the Combined Report (all rules on all devices) link, the all.html file will appear (see Figure 10.21).
 |
| Figure 10.21 CIS RAT Audit Summary Results |
The all.html file shows the pass/fail marks for every rule listed in the rules.html file. Failed marks are highlighted in red. Clicking on any of the links in the report brings up the details for the particular rule in the rules.html file.
Going back to index.html and clicking on the All Individual Reports:syd_1760rt_06082007.txt link brings up the syd_1760rt_06082007.txt.html file (see Figure 10.22).
 |
| Figure 10.22 CIS RAT Audit Report for the Individual Report |
Command SYNTAX
rat [OPTIONS] config [config ...]
RAT Configuration Options
The following options apply to all RAT functions.
-h, –help The –help displays correct program usage and options.
-V, –version The –version option displays the current program version.
Options for Downloading Device Configurations
The following options apply to downloading configurations. These are, for the most part, specific to Cisco IOS.
-e, –enablepw The –enablepw flag allows the specification of an enable password. If the password is not specified, then the user will be prompted (without echo) for the password.
-b, –noclobber The –noclobber flag indicates that device configurations should not be pulled if they already exist.
-n, –nonenable The –noenable flag indicates that snarf should not try to enable before pulling configs.
-a, –snarf The –snarf flag indicates that device configurations should be downloaded.
-u, –user The –user flag allows the specification of an a username to be used when logging on to routers. The default is the current logon name.
-w, –userpw The –userpw flag allows the specification of a user-level password on the command line. If the password is not specified, then the user will be prompted (without echo) for the password.
-x, –passcode The –passcode flag allows the specification of a Terminal Access Controller Access-Control System (TACACS) passcode on the command line. If the passcode is not specified, then the user will be prompted (without echo) for the passcode. =back
Options Affecting Rule Selection and Reporting
The following options affect which rules are checked and how the results are reported.
-i, –include The –include allows the user to specify a limited set of rules to check on the command line. It specifies a regular expression to limit the objects (rules, data types, and classes) that are checked. The name of the object must match the regexp specified or the rule is skipped. You might try something like:
–include=finger
or
–include=‘finger|syslog’
or
–include=access, logging, aaa
See the config files for definition of objects. all is synonym for *. You can give a normal comma separated list of objects that you want to check because a comma is treated as a synonym for the regular expression or |).
-p, –onlypass The –onlypass flag indicates flag indicates that only passing rules should be reported. It may not be combined with –onlyfail.
-f, –onlyfail The –onlyfail flag indicates flag indicates that only failing rules should be reported. It may not be combined with –onlypass.
–mail-to The –mail-to option indicates a recipient for audit failure e-mail notification. The value of this option should be an e-mail address (for example [email protected]). This option may appear several times to add several different recipients. (global config option: ConfigMailTo: if used as a global config, then the value should be a comma-separated list of e-mail addresses.)
–mail-on This option sets the percentage score threshold necessary to cause e-mail to be sent. The value should be an integer; the default is 100 (global config option: ConfigMailOn).
–mail-from Set the address that the e-mail will appear to have come from, if a message is sent. The default is rat@localhost, which may be rejected by some mailers. (global config option: ConfigMailFrom)
–mail-server This options tells RAT to use a remote SMTP mail server at the given host name. If this option does not appear, then if RAT needs to send a message, RAT will attempt to use a local sendmail. (global config option: ConfigMailServer)
–mail-results If this option appears, then when RAT sends an e-mail message, it will also send the relevant HTML reports as an attachments. (global config option: ConfigMailServer)
Options for Selecting RAT Configuration files
The following options are used to select RAT configuration files that define the type of rules to be checked, the specific rules to be checked, and the location of the configuration files.
-t, –configtype=configtype The –configtype option allows the user to specify which of the available configuration types are used. The list of available config types is determined by the directories present in $prefix/etc/configs/*. The default is the first of these directories lexically.
–prefix=prefix The –prefix option allows the user to specify the prefix that is used for locating config files. The default is the prefix specified during installation.
-r, –rulesfiles=file[, file…] The –rulesfiles option allows the user to specify the list of rules files that are parsed. By default, the $prefix/etc/configs/$config_type/ common.conf is processed followed by $prefix/etc/configs/$config_type/cis-level-1.conf, $prefix/etc/configs/$config_type/cis-level-2.conf and $prefix/etc/configs/$config_type/local.conf, if it exists.
This option allows the user to supply an explicit list of rules files to parse. If the first filename is default, then the common.conf, cis-level-1.conf and cis-level-2.conf files are processed first, followed by any other config files given.
Nipper
Nipper (Network Infrastructure Parser) was previously known as CiscoParse. It is an open source network device security auditing tool. It is used to check security configurations and, hence, the risks associated with a router or firewall device. It takes as input the network device's configuration file, processes it, and generates a nice, friendly report.
Nipper is platform independent and supports a range of network devices from different manufacturers; the report output can be in a variety of formats. The currently supported formats are HTML, XML, Latex, and ASCII text, with a good chance that more will be added in the future.
The report produced includes; detailed security-related issues with recommendations, a configuration report, and various appendices. This is possible because Nipper has the capability to check the network filtering, password strength, routing protocols, software versions, management services, and a host of other settings. A number of these checks are fully customizable, so that the audit of the device can meet a specific requirement. Each security issue that Nipper identifies is uniquely described in the report. The report (Annex B for a sample) will describe what was found, why it is a security risk and what the alternatives are for mitigating the risk. The security report also provides a conclusion which gives an overview of the findings.
Nipper can audit various types of devices from different manufacturers. The current version of Nipper supports the following different types of devices:
▪ Bay Networks Accelar
▪ CheckPoint VPN-1/Firewall-1
▪ Cisco Catalysts (IOS, CatOS and NMP)
▪ Cisco Content Services Switch (CSS)
▪ Cisco Routers (IOS)
▪ Cisco Security Appliances (PIX, ASA and FWSM)
▪ Juniper NetScreens Firewall
▪ Nokia IP Firewalls
▪ Notel Passports
▪ SonicWALL SonicOS Firewalls
An advantage of RAT over Nipper is that RAT has more built-in customization. However, compared to RAT, Nipper is more actively maintained and has the capability to test more devices (routers and firewalls from different manufacturers).
Getting Started
The following steps detail the process used to deploy Nipper.
1 First, download Nipper to your system. All Nipper downloads are provided by Source Forge.
Official Nipper downloads are provided for the following platforms:
Microsoft Windows
▪ 32-bit Binary Package
▪ Platform Independent Source Code
Linux and UNIX Systems
▪ Platform Independent Source Code
Apple Mac OS-X
▪ Platform Independent Source Code
Using Nipper
The following is a brief summary of the process of running Nipper
1 First, get a copy of the router configuration file. It is strongly advised that HTTP, Telnet, and TFTP not be used to obtain the configuration file from your device, as no encryption is used during such transfer.
The steps on how to download the config file of a Cisco Router (IOS) are as follows:
a Connect to the Cisco Router using SSH or a console connection.
b Logon.
c Type the following command: enable
d Enter the enable password.
e Execute the following enable command and capture the output: show run
f Save the captured output to a file and remove any visible page lines (for example <--- More --->).
2 Save the config file (usually in a text file) on the extracted zip file of Nipper. (Let's assume that you save Nipper file in the C: drive of our system.)
3 You are now ready to run Nipper. Click Start, then Run, and then type cmd.
4 Type c:, and from c: type cd space and then the location of the Nipper.exe binary (for example cd C:
ipper-0.11.3 as shown in Figure 10.23).
 |
| Figure 10.23 Running Nipper |
For example, to run Nipper on the config file of a Cisco Router (IOS) with the filename ABC_Company_Router.txt using the HTML output format with the filename ABC_Report, you would enter the command shown in Figure 10.24:
nipper ––ios-router ––input=ABC_Company_Router.txt –– output=ABC_Report.html
 |
| Figure 10.24 Running Nipper from the Command Line |
Nipper looks for certain lines within a devices configuration file to determine whether or not it is processing the right type of configuration for the device type specified. This means that if you are processing a Juniper NetScreen device, but have told Nipper that it is a Cisco PIX, Nipper will stop. Nipper has an option to disable the configuration file checks in order to bypass this feature if there is a problem with the file, but you still need to check it. This is the –force option.
If you are unsure whether the device type specified is correct, (in the example you specified ios-router), you can add –force on the command line options such as:
nipper ––ios-router ––input=ABC_Company_Router.txt –– output=ABC_Report.html –force
Annexes A and B present the router config file and the Nipper html report.
After pressing the Enter key, you can expect the output (with the filename that you specified) in the folder where our Nipper file is saved. However, if the command you typed contains errors, such as spaces or single dash instead of double, an error message would be displayed.
A guide on how to run Nipper on other devices is available from http://nipper.titania.co.uk. The following devices can be configured using the listed options at the command line:
Bay Networks Accelar:
nipper ––passport ––input=accelar.config ––output=report.html
CheckPoint VPN-1 / Firewall-1:
nipper ––fw1 ––input=/home/firewall/conf ––output=report.html
Cisco Catalyst (NMP):
nipper ––nmp ––input=nmp.config ––output=report.html
Cisco CSS:
nipper ––css ––input=css.config ––output=report.html
Cisco Adaptive Security Appliance (ASA):
nipper ––asa ––input=asa.config ––output=report.html
Cisco Firewall Service Module (FWSM):
nipper ––fwsm ––input=fwsm.config ––output=report.html
Customizing the Parameter Settings in Nipper
With the command line that you used to run Nipper, you are auditing the configuration of the device vis-à-vis the built-in parameters settings of Nipper that are contained in the file nipper.ini in the Nipper install folder. The configuration settings used by Nipper may be changed to suit the compliance requirements of any organization. To modify the parameters and settings of Nipper, you can either make the change at the command line or modify the settings contained in nipper.ini. (Just don't forget to save it.)
Using the Command Line
The following command options can be added to the command line that you used above to run Nipper.
–pass-length={length} The minimum password length.
–pass-uppers={yes | no} Yes if the password MUST contain uppercase characters.
–pass-lowers={yes | no} Yes if the password MUST contain lowercase characters.
–pass-either={yes | no} Yes if the password MUST contain lowercase or uppercase characters (including combinations).
–pass-numbers={yes | no} Yes if the password MUST contain numbers.
–pass-specials={yes | no} Yes if the password MUST contain special characters (that is, non-alphanumeric).
–no-passwords If you do not want to display the passwords in the report.
–john={ filename} Create an external file with the encrypted passwords using the John-the-Ripper format for external cracking.
–dictionary={dictionary file} If you want to use an external dictionary file against which the passwords would be compared, otherwise Nipper will compare it to a small internal dictionary of common passwords.
Modifying the nipper.ini File
Figure 10.25 presents the default configuration settings of Nipper. If youi want to modify some parameters, you can do that directly on the nipper.ini file. The following example contains a portion of the configuration settings:
# Password / key audit options
Minimum Password Length = 8
Passwords Must Include Uppercase = off
Passwords Must Include Lowercase = off
Passwords Must Include Lowercase or Uppercase = on
Passwords Must Include Numbers = on
Passwords Must Include Special Characters = off
 |
| Figure 10.25 Nipper Config File |
Configuring Nipper can be achieved by modifying the parameters in this file, such as those listed above. For example, the minimum password length can be changed to 10. After modifying the file, save it and run Nipper using the original command line that you used, which is presented again below.
nipper ––ios-router ––input=ABC_Company_Router.txt –– output=ABC_Report.html
The report produced by Nipper is configurable. The images in Figure 10.26 and Figure 10.27 show the default HTML report format for Nipper. Of particular benefit is the inclusion of information about how to fix the problems with detailed descriptions of the risks associated with each misconfiguration. Each of the recommendations also includes the command line or configuration change needed to fix the problem.
 |
| Figure 10.26 Nipper Output File/Report |
 |
| Figure 10.27 Nipper Output File/Report Recommendations Section |
Other Options
Nipper and RAT are not the only means of auditing your Cisco devices. The Cisco Output Interpreter and Cisco Security and Device Manager have audit functions. Many other commercial products also offer this capability.
Cisco Output Interpreter
The Cisco Output Interpreter is available to registered Cisco.com users with a Cisco service contract (CCO) and is on the authenticated section of Cisco's web site. The Cisco Output Interpreter allows the upload of configurations and will send a report of problems found in the configuration. The main issue with this service when auditing multiple systems is that scripting or automating is difficult.
See https://www.cisco.com/pcgi-bin/Support/OutputInterpreter/home.pl for further information.
Cisco Security and Device Manager
The Cisco Security and Device Manager (SDM) also provides a Security Audit feature. For more information on this product see www.cisco.com/univercd/cc/td/doc/product/software/sdm/sdmfaq.htm.
Security Access Controls Performed by a Router
Routers have a critical security role to play on any network. They provide anti-spoofing, logging and black hole blocking. Routers are extremely effective in configuring default drop rules based on IP ranges that should not be allowed into your site, and routers should be deployed for this. To do this, Cisco uses a number of IP filter types. There include:
standard IP access control lists These are defined by the list numeric range of 1-99 or 1300-1999. These test only the IP source. As such, they are faster than extended IP access lists, but check far less.
extended IP access control lists These are defined by numeric range 100-199 or 2000-2699. These test the source, destination, protocol, UDP or TCP port, and ICMP types in sequence. These may be used to make a complex filter set.
reflexive IP access control lists These use the state table to maintain more secure connection entries. They were created as a replacement for the established keyword. The use of reflexive filters is recommended in the event that the router is the sole line of perimeter defense (that is, there is no firewall). These should also be considered to add defense in depth to a site. Reflexive lists are CPU and memory intensive, and hence there is a direct performance cost leading to an associated higher system cost.
.named access control lists Named lists may be created using the number ranges specified or by using a descriptive name. They are a way of creating more lists than was possible using the numbered format and also to add a descriptive feature.
Context Based Access Control (CBAC) This product is known as the Cisco Firewall Feature Set. This affords protocol-aware control to the router, making it a de facto firewall. CBAC is very CPU and memory intensive.
The recommendation is to filter absolutes with standard or extended lists, while using a backend firewall to take care of the remaining traffic. This reduces the load on the firewall and also makes log review simpler.
Security of the Router Itself and Auditing for Router Integrity
It is important to take note of the following points when securing a router.
1 Where possible protect the physical security of the device by housing it in a separate room or closet. If such facilities are not available where required, a secure lockable cabinet should be substituted. This should be located out of sight of the general work area, and keys or other access tokens strictly controlled.
2 All cabling and other transmission media (for example fiber optic cable) should be secured or placed in locations not readily accessible.
3 Only those protocols which are specifically required should be permitted.
4 Cisco routers provide a set of services referred to as Authentication, Authorization and Accounting (AAA).
▪ Authentication All routers should employ username and password security for authentication. Note that the enable secret option must be used when setting router passwords. This will cause the password to be hashed using the MD5 algorithm. Normal passwords are encrypted using a weaker, reversible algorithm. Due to this vulnerability associated with Cisco user authentication, it should be employed in conjunction with a remote security database.
▪ Authorization Authorization specifies who can use the router and how they are to be authenticated. Optionally, access control lists can be used to tailor the network access granted to a user and levels of access. This should be considered if there is a chance that external parties may have access to machines containing restricted information.
▪ Accounting AAA accounting and billing commands can be used to monitor network activity. Accounting must be used in conjunction with an authentication server. While it is not practical to implement as a security monitor, Accounting can be used to record activity in the case that unauthorized access is suspected. It is also a useful tool to provide detailed baseline traffic measurements, which can be used as a comparison test for unauthorized activity.
5 All virtual terminals should be fully filtered, that is, no unauthorized traffic should be passed to or from the virtual terminal. In cases where physical access on demand is not practical (for example at remote locations), virtual terminals may be set to allow specific protocols and addresses. Under no circumstances should unencrypted Telnet be used with these devices.
6 While it is not possible to determine every purpose to which the network may be put, in general, the aim of filtering should be to permit only authorized traffic and deny all else. No protocol should be permitted on any interface unless its purpose has been documented and approved. In particular, if the finger service is not filtered by the router, the command no service finger should be added to the router's configuration.
7 Dynamic (Lock-and-Key) access should not be used, as it has the potential to create holes in a firewall or filter. Even after legitimate access has ceased, unauthorized traffic could hold the access list entry open. There are also performance and management issues associated with this type of filtering.
8 Cisco neighbor authentication or a similar function should be enabled for all routers. If supported by the router, the authentication should be encrypted (for example MD5 secret hashing with Cisco routers). While there is some overhead associated with the authentication process, careful minimization of routing updates can mitigate the problem.
9 Network traffic should be encrypted when it travels over unsecured networks.
10 Trivial File Transfer Protocol (TFTP) services should not normally be available to the network. If TFTP is used for storing configuration files or for other utility purposes, all filenames should be random and give no indication of the file's contents. Any TFTP servers must be disabled or disconnected when not in use.
11 Disable all unnecessary services.
12 Implement flood management processes on the router.
13 Create anti-spoofing access lists.
When a router is configured as a firewall or external filtering device, it should conform to the standards listed below.
1 A default deny strategy will be employed.
2 All permitted protocols need to be documented and approved as part of a risk assessment process.
3 Non-approved protocols will not be permitted.
4 Any protocol or application which uses cleartext passwords will be blocked unless the communications are encrypted.
5 Changes to the permitted protocols will be subjected to an approval process and normal change control before implementation.
6 All related equipment will be in a secure area with logged access controls.
7 Backups are to be taken of all systems and configuration files before connection and after all significant maintenance.
8 Equipment comprising the firewall shall only have administrative user IDs – passwords used for these IDs will be different from those used internally.
9 All devices shall use directly connected consoles or terminals with secure authentication mechanisms (for example Cisco user lists are not considered secure).
10 Testing is to be conducted to ensure correct operation after all significant modifications to the equipment.
Identifying Security Vulnerabilities
The Cisco general security page is:
The auditor must review any audit data of the router and validate that the system is running on a secure version of the firmware. Routers are commonly overlooked and frequently remain unpatched. Numerous excuses are usually made to explain why this occurs; however, patching a router is just as important as patching any other equipment on the network. In fact, in many ways patching network equipment, such as routers and switches, is more critical than applying patches to client machines.
Router Audit Steps
To audit a router, the following steps and questions will help you comprehend the security in place to protect the router itself and also the network.
The first stage is to view both the running and startup configurations. Validate each rule used on the individual interfaces and question why all the rules are being used. The system administrator should have these documented, and they should be detailed in change control. At the least, the administrator must be able to answer “If not, why not?”
To test if ACLs are implemented and functioning, send traffic through the router and use a network sniffer to capture the traffic on the other side of the device. Traffic that is filtered should not be seen on the sniffer. Generate a number of traffic patterns and test again to be sure.
If you are getting traffic on the sniffer that should be blocked, the rule order may be incorrect or the ACLs may not be applied correctly. At this point you should suggest rulebase fixes. As an internal auditor, you can suggest the actual implementation that may correct this. An external auditor will have to remain independent and only point out the sections of the best practice guides listed below. This is achieved by comparing the rules in the rulebase to the checklists and standards, and noting the differences and shortcomings.
Even if there are no errors or vulnerabilities, it is still important to ask if the most commonly matched rules occur towards the top of the ACL. If this is not the case, suggest that the network administrator optimize the rule order to improve performance and efficiency.
Not only should the rules meet the standards that are being tested against in the checklist you will create, but the rules must also match the organization's policy, procedures, and/or best practice. When checking this, ask:
▪ Are the filter rules authorized and correctly documented? Just being secure is not enough; they must also follow good change control processes to ensure that the rules remain effective. Otherwise, who is to say that the rules will remain the same tomorrow?
▪ Are the filter rules optimized? If they are not optimized, then the router may be costing money. This may be tested by comparing the packet match quantities in the router history. (Alternatively, use the command sh ip protocols). The command to display access lists including the number of displayed matches is show access-lists. By using this you can see if the rulebase order is set with the most frequently matched rules first.
▪ Carry out a technical verification of the filter rules. This requires firing packets through the routers and testing what is recorded on the other side.
▪ Recommend changes as and when necessary, but always explain the reason for each change and any benefits of the change. Most importantly, use external sources to support your claims.
Sample Commands
Table 10.2 is a summary of many of the security-related Cisco commands. The list in this table is by no means comprehensive.
Cisco Router Check Lists
Numerous good router checklists may be readily found on the Internet. The following list offers a number of alternatives to creating your own router checklists.
The Router Checklist Procedure Guide – Supplement to the Network Infrastructure Checklist is available from http://csrc.nist.gov/checklists/repository/1059.html, which is maintained by NIST and DISA. These, together with the NSA (www.nsa.gov/snac/downloads_all.cfm) checklists, make a comprehensive combination. The CIS standards (www.cisecurity.org/bench_cisco.html) are also effective and are aligned with the RAT tool.
If you want to check your network equipment against the ISO-27001 standard, the following site offers a good alternative Cisco router checklist.
If you truly need a secure router or you just want to learn why these settings are required, then you really need to get a copy of Hardening Cisco Routers by Thomas Akin. This was published by O'Reilly in February 2002.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.