General Network Equipment Audit Steps

Begin the audit by asking the network engineers for a copy of the configuration and the version of the device you intend to audit. For routers and switches, frequently, nearly all the information you will want is located in this file, and it prevents you from having to log onto the device repeatedly.

If you get a configuration file, sometimes it can be fairly long, and you may find it helpful to use command line tools such as grep and sort to move through the file and retrieve information for you. Windows version of these tools are readily available online from http://www.gnuwin32.sourceforge.net. You also could install Cygwin (http://www.cygwin.com) or other toolkits that provide similar functionality. It's possible to create scripts based on these binaries to quickly audit several configuration files at the same time.

Note 

Many of the illustrations that follow are from the Cisco IOS. Your networking equipment may be different, but the concepts generally are the same. Your network engineers should know when there are differences and show you adequate supporting documentation so that you feel confident that your network is secure and operating as it should.

1 Review controls around developing and maintaining configurations.

This is a catch-all that addresses configuration management, the overarching concept of maintaining the secure configuration of the firewall. Failure to maintain a secure configuration subjects the firewall to lapses in technology or processes that affect the security of your network. Changes on the firewall should be reviewed immediately to ensure that the change did not unintentionally degrade the performance or otherwise hurt the security of the assets the firewall is protecting.

How

Discuss change-management practices with network administrators. Ensure that changes are planned, scheduled, documented (including the purpose of the change), and approved prior to implementation. Ensure that the company's configuration change-management policies and processes are followed. See Chapter 3 for more information.

Note that this step lightly covers routine patch cycles, which is specifically covered again in step 2. Discuss the following as applicable with the administrator to ensure that proper configuration management controls are in place:

• Security mailing lists are monitored.

• The latest patches are applied in a routine patch cycle under the guidance of written and agreed-on policies and procedures.

• A configuration guideline exists for the equipment in the environment and is strictly followed. Exceptions are carefully documented and maintained.

• Regular vulnerability scanning from both internal and external perspectives is conducted to discover new risks quickly and to test planned changes to the environment.

• Regular internal reviews of the configuration are conducted to compare the existing infrastructure with the configuration guide.

• Regular status reports are issued to upper management documenting the overall security posture of the network.

Having a strong configuration standard is critical to a secure network. Network equipment, including routers, switches, and firewalls, has many configuration options that affect security and are rarely secure out of the box. Taking the time to understand these options and how to configure them to your environment is fundamental to maintaining a sound and secure network.

2 Ensure appropriate controls are in place for any vulnerabilities associated with the current software version. These controls might include software updates, configuration changes, or other compensating controls.

This step goes beyond configuration changes and targets specifically software updates and any associated vulnerabilities. This step is where you as an auditor will research critical vulnerabilities associated with the software and ensure appropriate controls are in place, such as a software update, a configuration change, or other compensating control. Note that it isn't necessary to install each and every update, but you generally should keep your network equipment current. As vulnerabilities become known to the security community, they are documented in various online databases such as the National Vulnerability Database (NVD) located at http://www.nvd.nist.gov. These lists should be checked, and if the version of code being used is found to have some known vulnerabilities, the device should be patched or have other mitigating controls put in place to protect the network device and your network.

How

Discuss the software version information with the network administrator and the status of any pending patches or upgrades. Check the software and version against the National Vulnerability Database. Note and discuss any potential issues with the network administrator.

3 Verify that all unnecessary services are disabled.

Running unnecessary services can leave you susceptible to performance and security related risks. This is true of any host or device and adds to the attack surface available to potential attackers.

How

Discuss unnecessary services with the network administrator, and review the configuration of the device. If the device depends on another platform (e.g., some firewalls), then ensure the underlying platform also has all unnecessary services disabled.

Discuss any exceptions with the administrator, and determine what additional risk exposure might exist and whether exceptions are necessary. For any other services enabled, discuss with the administrator to verify that there is a legitimate business need for the service. Services should be enabled only when needed.

Table 5-3 presents an example for Cisco routers and switches. Note the presence or absence of these services, and be aware some of the ones included in the table may not be applicable. However, they should be disabled if they exist. For more documentation on these services, please consult the references section.

Table 5-3: Unnecessary Services

Service Name	Comments	Config File Entry
TCP Small Servers	RFC specified services for TCP (chargen, daytime, etc)	no service tcp-small-servers
UDP Small Servers	RFC specified services for UDP (chargen, daytime, etc)	no service udp-small-servers
Finger	Gives away information about the device and users; should be disabled or at least blocked from external networks	no service finger or no ip finger
HTTP Server	Used to manage the router via HTTP; disable if not in use; restrict access via ACLs if in use; typically not used at TI	no http server no ip http secure-server
Proxy ARP	Use only when absolutely necessary to support legacy architectures; not really a big deal unless the interface is an end-user subnet	no ip proxy-arp (on each interface)
DNS	Disable entirely or enable with specific server(s)	no ip domain-lookup (to disable) ip name-server addresses (for specific servers)
DHCP	Assumes you have other DHCP servers on your network	no ip dhcp-server
bootp	Bootstrap Protocol	no ip bootp server
identd	Identifies the user of a particular TCP connection	no ip identd
CDP	Cisco Discovery Protocol: Information sent through CDP is cleartext and unauthenticated	no cdp run (disables globally) no cdp enable <interface> (disables per interface)

4 Ensure good SNMP management practices are followed.

Simple Network Management Protocol (SNMP) represents an often-overlooked way to obtain full administrative access to a network device. This step may not be applicable to your equipment if the equipment doesn't support SNMP management or it is disabled.

How

Discuss SNMP management practices with your network administrator. In an ideal world, you would use SNMP Version 3 because the packets are authenticated and the password is encrypted on the wire. However, it's much more common to find SNMP Version 2 in most corporate environment. If SNMP Version 2 is used, then the community string should be difficult to guess. SNMP Versions 1 and 2 send the community string in cleartext, and packets are unauthenticated. These issues are resolved in SNMP Version 3.

SNMP community strings should follow standard password policies for strength and change frequency. Management with SNMP should be restricted with an access list, and no management should be allowed from an untrusted network.

5 Review and evaluate procedures for creating user accounts and ensuring that accounts are created only when there's a legitimate business need. Also review and evaluate processes for ensuring that accounts are removed or disabled in a timely fashion in the event of termination or job change.

This is a large step with a wide scope, covering controls around account usage and management. Inappropriately managed or used accounts could provide easy access to the network device, bypassing other additional security controls to prevent malicious attacks. This step should cover policies and procedures that are essential to ensure that only authorized administrators can log in to a network device and that once logged in they have the proper privilege level. Login procedures should adhere to strong authentication, authorization, and accounting (AAA).

How

Discuss with the administrator and verify with the administrator's help that appropriate policies and procedures exist to add and remove account access to the device. The accounts should be controlled such that only those authorized to have access can log onto the device. Unused accounts, if applicable, should be removed from the configuration of the network device or completely disabled in accordance with your organization's account management policies.

Also review the process for removing accounts when access is no longer needed. The process could include a periodic review and validation of active accounts by system administrators and/or other knowledgeable managers. Obtain a sample of accounts, and verify that they are owned by active employees and that those employees' job positions have not changed since the account's creation.

In general, accounts should never be shared among administrators. This can present risk in that you lose accountability for actions taken on the system. Strong account policies always should be enforced by the network device. Additionally, discuss login procedures with the administrator to ensure that all users are managed appropriately using roles and that actions are logged appropriately. In general, individual IDs should be created for every person requiring access to the network device, or the network device should use a central authentication server for these accounts, sometimes called an AAA server. RADIUS and TACACS are examples of AAA servers.

Some network infrastructures may use TACACS for AAA on routers and switches. This system allows anyone with an RAS-enabled NT account to log onto the router in nonprivileged mode. An additional password, enable secret, is then required for privileged access. An example configuration file entry if TACACS servers are used might be

 tacacs-server host <IP Address> 

Individual IDs might look something like this in the configuration file:

 username <name> password 7 <encrypted password> 

These IDs should be created with a privilege level of 1, forcing enable secret to be required for additional access.

6 Ensure appropriate password controls are used.

Weak and unencrypted passwords allow attackers to easily guess or read passwords in plaintext. Strong password controls are essential to protecting network equipment.

How

Discuss password controls with the network administrator, and consult existing policies and procedures. Ensure complex passwords are used, stored with MD5 hashes where possible, and changed with appropriate periodicity (e.g., every 90 days). Passwords for privileged modes of operation never should be the same as any other password on the device.

Look for the command service password encryption on Cisco and other devices running IOS because this will encrypt most passwords displayed in the configuration. You may run across two types of encryption, type 5 and type 7. Type 5 is used for the enable secret only and is a strong encryption method using MD5 hash. Type 7 is a reversible algorithm. Type 7 encryption is decoded easily.

Note 

Some passwords may not be able to be encrypted in the configuration file. These values often include SNMP community strings and RADIUS keys. It is imperative that these plaintext values are not the same as any other passwords on the system. Discuss this with the administrator.

Additionally, service password-encryption, if available on your router or switch, serves to provide a measure of security against shoulder-surfing attacks, where someone casually looks over your shoulder and sees the configuration file on your screen by storing and displaying your passwords in a scrambled format. Also for IOS devices, review the configuration file to ensure that the enable secret password is set and that it is not the same as any other password set on the system. Look in the configuration file for the line

enable secret 5 xxxxxxxxxxxxxxx.

Finally, ensure that appropriate controls exist such that the same password isn't shared on a large number of devices throughout your network. Passwords shared on the WAN should not be used on the LAN.

7 Verify that secure management protocols are used where possible.

Telnet sends all its information in cleartext. This allows passwords and other information to be viewed with a sniffer. SNMP Versions 1 and 2 are similar. Secure alternatives are SSH, Encrypted Kerberized Telnet, IPSec, and SNMPv3. While it is imperative that secure protocols be used from an untrusted network, it is very important on the inside as well.

How

Discuss management procedures with the network administrator, and review the configuration of the network device. Ensure that policies and procedures exist to manage routers, switches, and firewalls as securely as possible. Secure Shell (SSH) Protocol or another secure management protocol or an out-of-band management system should be used.

8 Ensure that current backups exist for configuration files if applicable.

It is critical to keep copies of the all network device configurations in a readily accessible, secure location. These files will contain any comments that can help to give perspective to the configuration settings and filters. Changes to the filters can be done with much more ease and accuracy when you can refer back to the old configuration files. These backups also can be invaluable for diagnosing suspected attacks and recovering from them.

How

Discuss policies and procedures with the network administrator, and ask to see where the current configurations are kept. Verify with the administrator that the backup repository contains the latest configurations kept on the routers and switches. The configuration files should be stored in a secure location to which only the network team has access.

9 Verify that logging is enabled and sent to a centralized system.

Logs should be collected for AAA and regular syslogging. They should be sent to a secure host to prevent tampering with the information. Additionally, SNMP traps may be used to send a subset of the information available with syslog.

How

Discuss logging with the network administrator, and review the configuration file. Ensure that appropriate log levels are used. Log levels range from 0 to 7 on Cisco equipment. Log level 0 would only log emergencies where the system was unusable, and log level 7 is debug-level logging. Logging is identified by

 logging host <ip address> 

AAA logging is identified in Cisco configuration files by

 aaa accounting 

SNMP traps are identified by

 snmp-server host [log host] [version] [community string] [trap-type] snmp-server enable traps [trap-type] 

10 Evaluate use of Network Time Protocol (NTP).

Use of the NTP provides time synchronization for the timestamp on all logged events. The timestamps are invaluable in reporting and troubleshooting and enable acquisition of useful information about events in logfiles.

How

Discuss the use of NTP with the administrator, and review the configuration file. For ease of management, it is a good idea to standardize all clocks to a single time zone. The following indicates that NTP is enabled. Note that the key option is used with authentication.

 ntp server <ip address> key <key> 

11 Verify that a banner is configured to make all connecting users aware of the company's policy for use and monitoring.

A warning banner that clearly marks the router or switch as private property and disallowing unauthorized access is essential should a compromise ever result in legal action.

How

Verify with the administrator and a review of the device configuration that all connecting users are made aware of the company's policy for use and monitoring. Confirm that the motd or login banner does not disclose any information about the company or network device. This information should be reserved for the exec banner after a successful login.

For Cisco equipment, you would review the configuration file for either the banner motd or the banner login. These do basically the same thing with minor differences. The motd banner is displayed before the login banner, but both appear to the end user before the login prompt. The motd banner can be disabled on a per-line basis, whereas the login banner cannot.

12 Ensure that access controls are applied to the console port.

Logical access can be gained via the console port with poor physical access controls to the router or switch. Often the console port will be left with no password for convenience. Ensure that a password is used to provide an additional layer of defense beyond the physical controls. A password is imperative if the location is not physically secure.

How

Discuss access controls with the administrator, and verify that the console port is password-protected. Here is an example of a Cisco router or switch configuration:

 line con 0 login (to use a password only) login local (to use a locally defined username and password) login tacacs (to use the TACACS+ servers) password 7 xxxxxxxxxxxxxxxx 

If AAA authentication is used, make sure that the line starts with aaa authentication login default. Failure to include default could mean that login on the console port is allowed without any password. Typically, TACACS will be tried first with local as a backup.

13 Ensure that all network equipment is stored in a secure location.

Anyone with physical access to a network device might be able to gain full logical access using well-documented password-recovery procedures. Someone also could unplug cables or otherwise disrupt service. Additionally, access should be limited to prevent nonmalicious accidents (e.g., tripping over a cable) from disrupting service.

How

Visually observe the location of the network equipment, and discuss physical access to the equipment with the network administrator.

14 Ensure that a standard naming convention is used for all devices.

Standard naming conventions make troubleshooting and finding issues easier. Standard naming conventions also help to make managing the environment easier as the organization grows.

How

Discuss the naming conventions used with the network administrator.

15 Verify that standard, documented processes exist for building network devices.

Documented processes provide repeatability of secure designs and higher-quality workmanship, helping to prevent common mistakes that might lead to a service disruption or network compromise.

How

Discuss documented policies and procedures for building network equipment with the network administrator. If possible, verify using a recent build that the process was followed.