Security Compliance: Achieving NSA Security Compliance

Contents

Introduction
Background Information
Scope of Article
Project Scenario
Network Topology
      Layer 3 Network Topology Abstracted
OSPF with MD5 Authentication
      Further Reading
      Planning and Testing
      Risk Assessment
      Deployment
      Recommendations
NTP with Authentication
      Further Reading
      Planning and Testing
      Cisco IOS Scripts
      Catalyst Operating System
      Windows NT
AAA with Cisco Secure ACS for Network Management
      Further Reading
      Planning and Testing
      Installing and Configuring Cisco Secure ACS
      ACS—Defining Groups
      ACS—Defining Users
      Cisco IOS Software-Based TACACS
      Catalyst OS-Based TACACS
Anti-Spoofing and Other Recommendations
Acknowledgments
Reference



Introduction

This article describes technical best practices to help achieve compliance with U.S. National Security Agency (NSA) security requirements for equipment used in military installations.

Background Information

The securing of networking devices such as switches and routers has been directed by several trusted, well-known authorities including the National Security Agency (NSA). These steps include the authentication of network managers as they log in to each device, as well as the tracking and recording of each of their actions with accurate, consistent time stamps. This task includes the process of confirming that device passwords and network managers' login information are encrypted and secured as the data passes through the campus. Additionally, authorities on network security encourage encrypting and authenticating any traffic that is critical for internal network management. One must be confident that routing protocols, timing sources, and other information are not being hijacked for malicious purposes.

In short, the individual routers, switches, and management tools become hardened into one integrated system with a firm boundary. While the ideal is well established, the process involves many small tasks performed on isolated systems. The ideal execution includes a small staff working in a network operations center during a scheduled maintenance window. The risks of poor execution include getting locked out of the production network, locking out valuable and necessary routing data, or denying essential network traffic. The worst possible situation includes system outages and/or a campus-wide effort of unlocking every networking closet and manually resetting each network device locally.

Scope of Article

This article has a three-fold purpose:

  • Accurately document the planning steps required to mitigate against the risks described above.
  • Document successful procedures for implementing network security on a large, "always up" production network.
  • Provide technical insight into the configuration of network management stations, network security tools, and network devices. As these components are integrated into one distributed system, the process of cross-platform documentation becomes more critical.

This article is not restricted to specific software and hardware versions.

This article is intended to help network engineers formulate a plan, a deployment process, and a testing process for implementing authenticated Network Time Protocol (NTP) and authenticated Open Shortest Path First (OSPF), Secure Shell (SSH), and Terminal Access Controller Access Control System (TACACS+) for login Authentication, Authorization, and Accounting (AAA). These technologies were deployed in a production military network. The intent is to address shortcomings that were in published guides referenced during deployment and to provide greater depth and insight into the process.

This article presumes that a security policy is already in place. Cisco Systems does not recommend deploying security technologies without an associated policy. This article addresses the needs of large enterprise customers. Readers interested in security best practices for networks of various sizes should read the SAFE articles published at www.cisco.com/go/safe.

The guidelines in this article are strictly limited to the deployment of a few specific technologies that are an integral part of a broad security posture. However, these steps cannot absolutely guarantee a secure environment.

Project Scenario

This project brought the 59th Signal Battalion at Fort Richardson, Alaska into compliance with all pertinent NSA requirements. This compliance was achieved with no service interruption on a network that spans three locations, approximately 75 devices, and one large military installation.

The project team selected from the NSA Recommendation Guide those tasks that could be most effectively executed during one network maintenance period. Those tasks were as follows:

  1. OSPF with MD5 authentication
  2. NTP with both transition to Zulu (Greenwich Mean Time) and authentication
  3. AAA with Cisco Secure Access Control Server (ACS) for network management
  4. Antispoofing and other recommendations (including SSH and limiting access to both Simple Network Management Protocol [SNMP] and network management)

The order of tasks was discussed at some length. Other engineers may take a different approach, but the project team chose to work in the order shown above. We executed OSPF first because it required coordination with another network operations support group. The Army Gateway Router is managed and supported by a command located in Hawaii. This router hosts one remote location and ties the OSPF to an Army-wide Border Gateway Protocol (BGP) network. For these reasons, courtesy dictated coordinating a specific start time.

As for the remaining tasks, order was critical to success. Cisco Secure ACS functions and logs are most understandable if the times reported by network devices are consistent. SSH should not be deployed until the AAA has been firmly established, tested, and proven stable. Limiting access to management ports with access lists would then introduce new barriers to network management. Such barriers are necessary for a more secure environment. Therefore, the team opted to tighten security one step at a time as if flowing through a funnel. Each step was more restrictive than the previous step.

Network Topology

Figure 1 provides a conceptual overview of the Fort Richardson network. Five systems provide routing and VLAN termination, which are described in the diagram as Core A, Core B, Distribution R, Distribution D, and Army Gateway Router.

Layer 3 Network Topology Abstracted


  • The distribution layers are not completely meshed because of the paths and availability of fiber-optic cabling.
  • All end-user buildings are either connected to both cores or connected to a distribution layer switch. Per-VLAN spanning Tree (PVST) is used extensively to distribute the load between the two cores and to prevent a perfectly healthy strand of fiber from being left unused.
  • All routing devices are Cisco Catalyst 6509 switches, with the exception of the two routers located at Far Point. The two routers at Far Point are Cisco 2600 routers running Hot Standby Router Protocol (HSRP). One of the links to Anchorage, Alaska is a T1 via satellite. The second link is a 56 Kbps satellite link also going to Anchorage.
  • The links between Cisco Catalyst 6509s are Gigabit Ethernet (GigE) links or multiple GigE links, and they are routed.
  • The seven devices shown are all in OSPF Area 1.

OSPF with MD5 Authentication

OSPF routing information is shared between routing devices. This routing information could be hijacked or compromised in a number of other ways that would be devastating to a network. A network that does not route accurately is perceived as a failed network. OSPF authentication mitigates the risks in these vulnerabilities.

OSPF authentication comes in many flavors. The first decision a network engineer must make is whether to authenticate all OSPF conversation within a single area. Success depends on the access to all routers in the OSPF area, and authentication is an "all-or-nothing" option for the entire area. It is possible to do OSPF with authentication across a virtual OSPF link. A virtual link is a link that originates in one OSPF area, transits a second OSPF area, and terminates on a router that is a member of the original OSPF area. In this scenario, the project team had either direct access to all routing devices or support from the teams that did have that access. Additionally, there were no virtual links in the OSPF area.

The next decision involves the types of authentication required. The following three different types of authentication are supported by OSPF:

  • Null Authentication, also called Type 0, does not include any authentication information in the packet header. This is the default.
  • Plaintext Authentication, also called Type 1, uses simple cleartext passwords. For those supporting the U.S. Federal Government, OSPF Type 1 is not related to Type 1 Encryption.
  • MD5 Authentication, also called Type 2, uses MD5 cryptographic keys.

Authentication does not need be set, but if it is set, all peer routers must have the same keys. The example here demonstrates only configurations and MD5 authentication.

Further Reading

There are a few related articles at Cisco.com, including the following:

Sample Configuration for Authentication in OSPF

RFC 2328

Planning and Testing

It is recommended to document a stable OSPF foundation before introducing OSPF authentication. In this project scenario, OSPF had been operating reliably for a long time in this production environment. Additionally, no other OSPF changes were planned during the same network maintenance window. Given the risk involved, the team decided to change only this variable and allow the OSPF network to regain its stability.

After researching the topic and identifying the critical commands, a test in a nonproduction network was performed. This test involved two routers as described in Sample Configuration for Authentication in OSPF. The configurations are symmetrical between the two routers. There are two critical commands.

int s0/0
ip address 10.0.0.1 255.255.255.0
! defines the MD5 keys for the area 
ip ospf message-digest-key 1 md5 da_key
router ospf 0
! enable MD5 authentication for an area
area 1 authentication message-digest
network 10.0.0.0
exit

Risk Assessment

There will be a momentary disruption in OSPF routing throughout the area. All OSPF routes will be dropped and then re-learned. The network will shortly stabilize and all routing will return to normal operation.

In contrast, an actual failure will disrupt the OSPF databases and routing tables. The Telnet session may be dropped. HTTP links will stall or fail. The network may appear to be down because inter-VLAN traffic will not route between routers and data will not route to the Internet. However, access to routers (Cisco IOS 6509s) can easily be achieved by telnetting from a router that shares a common network.

Deployment

Although the commands were known and tests were performed, there were still several outstanding questions:

  • What links on which systems require the ip ospf message-digest-key command? How can we gain confidence that all interfaces have been accurately and completely identified?
  • Is it better to work from the core out or from the edge in?
  • Does the ip ospf message-digest-key command belong only on the interface that passed OSPF traffic, or on all interfaces involved with networks defined in the OSPF area?

Our team did not identify these questions during the mock-up, and therefore these questions remained unanswered as we approached the production network.

In an effort to avoid a missed OSPF link, two individuals used different techniques to draft Layer 3 maps of the network. The first person systematically documented the results of the following two commands:

show cdp neighbor
show ip ospf neighbor

These steps, taken together, accurately identified the Layer 3 links between all OSPF devices. This information was distilled into a map that showed both IP addresses and physical interfaces. The ip ospf message-digest-key is applied to the physical interface, information not shown in OSPF neighbor command.

The second person used CiscoWorks software. With a mouse-over on links between routing devices, CiscoWorks displayed the physical port on both ends. We recognized that CiscoWorks uses Cisco Discovery Protocol (CDP) to define these links. But our objective was to have two people verify information: one from a well-established map, the other from the command line.

This information was reconciled and scripts were drafted for all seven routers:

Script for 99.129 Distribution D

oursecret
enable
en-pass
conf t
int gi4/9
ip ospf message-digest-key 1 md5 da_key
int gi 1/2
ip ospf message-digest-key 1 md5 da_key
router ospf 1
area 1 authentication message-digest
exit

Script for 99.142 Distribution R

oursecret
enable
en-pass
conf t
int gi3/3
ip ospf message-digest-key 1 md5 da_key
int gi1/2
ip ospf message-digest-key 1 md5 da_key
int gi1/1
ip ospf message-digest-key 1 md5 da_key
router ospf 1
area 1 authentication message-digest
exit

Script for Far Point Routers

   **** Far Point 242.2
conf t
int s0/0
ip ospf message-digest-key 1 md5 da_key
router ospf 1
area 1 authentication message-digest
exit
**** Far Point 242.1
conf t
int s0/0
ip ospf message-digest-key 1 md5 da_key
router ospf 1
area 1 authentication message-digest
exit

Script for Core B

oursecret
enable
en-pass
conf t
int port-chan 1
ip ospf message-digest-key 1 md5 da_key
int gi3/5
ip ospf message-digest-key 1 md5 da_key
int gi 4/9
ip ospf message-digest-key 1 md5 da_key
int vlan4
ip ospf message-digest-key 1 md5 da_key
router ospf 1
area 1 authentication message-digest
exit

Script for Core A

oursecret
enable
en-pass
conf t
int port-chan 1
ip ospf message-digest-key 1 md5 da_key
int gi3/8
ip ospf message-digest-key 1 md5 da_key
int vlan4
ip ospf message-digest-key 1 md5 da_key
router ospf 1
area 1 authentication message-digest
exit

The team concluded that it is better to work from the edge toward the core. As the commands are executed, the OSPF links are broken until both sides have symmetrical commands. It is logical to work at the most extreme end of the network and retreat across still-working links. Working from the core outward is possible, but it is cumbersome and therefore not advisable. It may be easier to scrap any work done backward and start afresh.

The remaining question was the location of the ip ospf message-digest-key command. A certain amount of logic would guide a clever engineer to apply this command only to interfaces that are shared between the routers. A truly clever engineer might ask why the MD5 key would have to be applied to each interface if its significance is areawide. Why would one not apply it only to the OSPF process command? Why is it applied only to the OSPF links? Should it be applied to all interfaces that define OSPF significant networks?

The team was unable to locate an explanation of this issue, so we went with our best guess when deploying the production network. We discovered that the ip ospf message-digest-keycommand needs to be entered only on the links between OSPF routers. It does not need to be entered on interfaces that terminate VLANs or otherwise source the networks defined for OSPF to advertise.

We did not write the configuration to nonvolatile RAM (NVRAM) until OSPF converged and completed all necessary updates. While monitoring the network on CiscoWorks, significant regions of the network displayed "failed" or red for a minute or two before stabilizing. This behavior can be anticipated. If OSPF does not stabilize as a result of an error, reloading all devices provides an efficient recovery. We waited a full 10 minutes while we performed informal testing with pings and browsed to websites before executing a copy run start command on all seven devices.

Recommendations


  • Confirm and document that OSPF is running well
  • Document and verify all OSPF links
  • Draft detailed scripts that apply OSPF/MD5 commands to all identified interfaces
  • Work from the edge of the network in toward the core
  • Do not save configuration (copy run start) until OSPF has stabilized and all systems are functional

NTP with Authentication

NTP allows individual network devices to synchronize time. Network management tools will then report chronological events in order. Network security monitoring events can be correlated with network faults. Login activity and network configurations can be correlated with both network faults and with security monitoring. Logs posted from devices appear synchronized and ordered.

In this manner, NTP is a necessary step in tying individual network devices into one integrated system. NTP is part of the suite of tools used to assist in managing a network as a single distributed system. Tools such as routing protocols, trunking protocols, and SNMP are all part of this process.

NTP uses User Diagram Protocol (UDP) to communicate between devices. The device that provides the clock source is called a master. Clients send requests to the master. The master responds. This communication occurs using UDP port 123 as both the source and destination. NTP describes time in terms of Greenwich Mean Time (GMT, also known as "Zulu") and provides a means of communicating the time. NTP functions much like asking a neighbor on the train for the time. For example, the client requests an update on time, and the master then provides that time. Unlike time-division multiplexing (TDM), the clock is not communicated as a heartbeat or a pulse. It is rather simply the time stated in Zulu. In common language, the conversation would sound like this: "What time is it?" "It is 13:14:28.234." Note that this concept is somewhat different than the concepts surrounding time and clock on a T1 or other TDM interface.

Most routers and switches use an internal battery-powered clock in the same way that a PC does. In order for a PC, router, or switch to use NTP, it must be instructed to do so. With Cisco IOS Software-based devices, this time-keeping chip is called the calendar chip. The calendar chip does not inherently ask for help in setting the time.

The relationships between clients and masters are defined statically on devices. On clients, one must define the device to which it is supposed to make the request. On the master, one can restrict the polling using an access control list (ACL). Additionally, the communication can be transmitted with authentication between the end points.

A coordinated clock is important primarily to provide chronological, sequential, and coordinated logs. If clock sources are hijacked, events posted to logs can be out of sequence and not coordinated. The risks include:

  • The date of clock events could be modified so that they would not appear on daily/weekly reports
  • The date could be modified back far enough so that events would be instantly purged at the logging server
  • The dates on multiple devices could be modified so that causal events would not appear correlated in time

The net result of such tampering would corrupt the logs, therefore crippling the forensic analysis of events.

GMT is also referred to as Universal Coordinated Time (UTC), the term that is extensively used within this article. Local time is often called Lima.

Further Reading

Network Time Protocol: Best Practices White Paper

Example NTP Configuration for High Availability Catalyst 6000 Switch

Planning and Testing

Although authoritative clocks do exist on military installations, they are not necessarily available for NTP. Several Cisco devices can interpret an authoritative clock through a serial port and an atomic clock radio or Global Positioning System (GPS). However, these technologies were not readily available to the project team. Further discussion revealed that it was critical to obtain a coordinated time more so than an absolute time. Therefore, the goal was to sequence events across a statewide network regardless of source: system logs, CiscoWorks, and Cisco Secure ACS. Knowing the value of the time and the required precision helps to guide the design process.

The team decided to request clock from a known and trusted authority from U.S. Army devices located and managed by a related command (organization). But we wanted to have two local clock sources for all devices located in our operations area.

We identified the following questions to answer during our design and planning process:

  • Can we define master clocks that in turn poll from remote clocking authorities?
  • What devices should be the master clocks?
  • What model do we want to use? Client/server, symmetric active/passive, broadcast? (Refer to Network Time Protocol: Best Practices White Paper for definitions.)
  • How secure should the NTP deployment be?
  • What time zone should be used?

A master can be a client and a master simultaneously. This creates a hierarchical topology for NTP. We decided to have the two core Cisco Catalyst 6509s be the local NTP master. First, these devices are "closest" to the remote clock authority. There would be less time delay between the NTP transmission and the NTP reception. Second, these devices are located in a highly secure environment with substantial redundancies: power, supervisors, generators, battery systems, and so forth. Third, no network device is more than two hops from these switches. Approximately half of the devices are directly connected.

We opted for the client/server model for several reasons. First, client/server was the best fit with our business requirements. Second, the topology was well understood and well documented.

The team decided to deploy NTP with authentication because it was more secure and provided little additional risk. Authentication does not impact the stability of NTP, nor does it make the configurations or the process any more complicated. Furthermore, NTP with authentication mitigates against vulnerabilities in NTP.

NTP was not deployed with ACLs that would limit the scope of devices accessing NTP. This will be a subsequent task during a future network maintenance window. The primary objective was to stabilize and coordinate time with little risk. Given the constraints of executing NSA security guidelines as effectively and efficiently as possible during a single maintenance window, it was decided that the team should not make more than one change in a technology.

We were confident that a change in one variable was less risky than multiple simultaneous changes. And if there were problems, then diagnosing, debugging, or recovering from one change would be easier and more effective than recovering from complex changes. Changing multiple variables can impact troubleshooting significantly. Therefore, the team's philosophy was to change one variable and establish a new baseline before making a second change.

As for discussing and determining what time zone to use, the team settled on Zulu (also called Universal Coordinated Time). Readers should make careful and educated decisions on the proper time zone to use. Using Zulu can lend complexity to understanding logs and requesting reports. It is possible for a system administrator to request a report at 3 p.m. on a Monday for data at 12:30 on a Tuesday. Reading logs will often require a systems administrator to normalize or translate the time shown in the log to current time. This process can be cumbersome.

Alternatively, if a network spans more than one time zone, confusion will exist anyway. When a network spans more than one time zone with network administrators in multiple time zones, the selection of a time zone for network logs is arbitrary. Zulu is a well-accepted arbiter in these cases.

Additionally, Zulu is not subject to semi-annual leaps across time as we see in daylight saving time (or "summer-time" as defined by Cisco IOS Software). The impact of semi-annual time changes is seen in logs. During the "spring forward" time change, equipment jumps ahead one hour, leaving one hour without any log entries. During the "fall back" process, equipment logs events to the same hour twice.

The project team concluded that when supporting an enterprise-class network where events may have to be coordinated beyond a single time zone, the use of local time would only add confusion. Zulu may be more complex for systems administrators but it is less confusing in the long run. And for just a few dollars, a Zulu clock can be purchased and mounted on the wall.

The last remaining planning step was to accurately identify all devices that would be impacted by NTP. This list included all switches, routers, Cisco Secure ACS, CiscoWorks, and other network management tools. The team compiled a list organized by operating system. The operating systems discussed in this article include:

  • Cisco IOS Software
  • Catalyst Operating System
  • Windows NT

Scripts were written before deployment and tested on sample equipment in an isolated laboratory network.

Cisco IOS Scripts

There were two Cisco IOS scripts written: one each for the two core Cisco IOS Software-based Catalyst 6509 switches. These switches act as both NTP masters, providing clock to the LAN and NTP clients, polling clock from a remote NTP master.

Script for Core Catalyst 6509 Switches

oursecret
enable
en-pass
conf t
! set system as NTP server
NTP Master 3
! force calendar chip to update from NTP
NTP update-calendar
! set system to Zulu without semi-annual changes
No Clock timezone 
No clock summer-time
! Require authentication with NTP
NTP authenticate
! Define the MD5 keys for the authentication process
NTP authentication-key 11 md5 1618033988
! identify the key used with clients
NTP trusted-key 11
! These are the remote time authorities
Ntp server 10.11.12.245
NTP server 10.11.12.247 prefer
! use Zulu for posting logs and not system uptime
Service timestamps log datetime
end

These scripts set the internal clocks to use NTP and to display time in Zulu. Logs will also be posted in Zulu.

For all other Cisco IOS Software-based switches and routers, the following script was used:

NTP Clients—Cisco IOS Software-Based Switches and Routers

oursecret
enable
en-pass
conf t
! Require authentication with NTP
NTP authenticate
NTP authentication-key 11 md5 1618033988
! Define the MD5 keys for the authentication process
NTP server 10.0.1.1  version 3 key 11 prefer
! Define NTP server and Key used to poll NTP
NTP server 10.0.1.2 version 3 key 11
! force calendar chip to update from NTP
NTP update-calendar
! set system to Zulu without semi-annual changes
No Clock timezone 
No clock summer-time
! use Zulu for posting logs and not system uptime
Service timestamps log datetime
end
wr
sho clock
sho ntp assoc

Show clock may take a few moments to display the time correctly.

Catalyst Operating System

The following script responds to questions that are presented by the operating system as one executes the commands.

Script for Catalyst Switches with Catalyst Operating System

oursecret
enable
en-pass
Clear ntp server  all
! the "y" responds to the switch confirming the clear
y
! Define the MD5 keys for the authentication process
Set ntp key 11 trusted md5 1618033988
Set ntp client enable
! Require authentication with NTP
Set ntp authentication enable
! Define NTP server and Key used to poll NTP
Set ntp  server 10.0.2.2 key 11
Set ntp  server 10.0.2.3 key 11
! remove summertime issues
Set summertime disable
! set the switch to Zulu
Clear timezone
y
sho ntp
sho time

Again, show time took a few moments to synchronize and display the updated time.

Windows NT

Synchronizing the time between Windows NT and the networking device is critical for many network management applications, including CiscoWorks. It is best to have the network management, syslog servers, and other tools in the same time zone all synchronized to the same clock as the network equipment. This is critical to prevent errors in reporting and data analysis.

The process is executed from the Windows NT command line (also called the DOS window). The following script was used:

Windows NTP Commands (Entered in Command Window)

Clear NTP servers (if necessary)

net time /setsntp

Define the NTP server

net time /setsntp: 10.0.2.2

Windows time service uses Simple Network Time Protocol (SNTP), which is derived from NTP and is defined in RFC 1769. Network-based time synchronization has come to Microsoft Windows to accommodate Kerberos user authentication. As a result, several features desired in management and communication of a synchronized time for use in network management are not available under the current Microsoft operating system. Desired features include NTP and NTP with authentication.

There are techniques for debugging SNTP in Windows. The primary SNTP application is w32time. A different application, called W32tm, can be used to diagnose and troubleshoot time synchronization. However, W32tm and w32time cannot run at the same time. To debug time synchronization, an operator must first turn off w32time, then use the W32tm commands, and finally re-engage w32time. The commands are as follows:

Debugging Windows SNTP

Stop w32time

Net stop w32time

Debug and view synchronization

W32tm -once -v

Restart w32time

Net start w32time

Query SNTP settings

Net time /querysntp

AAA with Cisco Secure ACS for Network Management

Because so many network applications must be available on a 24-hour basis, it is critical to log activities on networking equipment. Figuratively speaking, each person who approaches the system must leave a thumbprint at the door and have their activities tracked—not strictly from an accountability perspective, or even a legal perspective, but from a more fundamental troubleshooting perspective.

As network systems become more complex, even a well-planned and well-executed action could have unanticipated secondary consequences. Fortunately, results from command accounting can correlate two seemingly unrelated events. These tools allow a network administration team to answer the following questions:

  • What happened on the network?
  • When did changes occur?
  • Who made those changes?

From any perspective, this level of professional accountability is required. The arguments for implementing full auditing are numerous, yet many organizations have been resistant. Employers may not wish to believe that an employee would violate a corporate trust, but it does happen. Therefore, system administrators must insist that all activity be logged, if only for forensic measures. And if an organization is aggressively seeking evidence of a violation, then audit logs will serve as valuable troubleshooting tools. The technologies that are involved in tracking the so-called "who, what, when, and where" are called Authentication, Authorization, and Accounting (AAA).

AAA comes in two flavors, either:

  • User authentication, activity accounting, and activity authorization to a device
  • User authentication, activity accounting, and activity authorization through a device

AAA to a box is called Character Mode and is seen most frequently on Telnet, SSH, and console activities. These activities are part of managing and monitoring a network.

AAA through a box is called Packet Mode and describes activities that pass through a system, such as dialing into an Internet service provider (ISP). These activities are most often employed by end users connecting to a business office, a personal Internet account, and so forth.

For the purposes of this article, only Character Mode AAA is discussed.

AAA involves a number of protocols for authenticating users, auditing activity, and verifying authority to execute activities. The articles below provide far more detail on these technologies. This article is specifically focused on AAA using TACACS on Cisco Secure ACS.

This article includes discussion of AAA with Cisco IOS Software and Catalyst OS but does not include Finesse, the Cisco PIX Firewall operating system.

Further Reading

User Guide for Cisco Secure ACS Windows Server 3.1

Cisco IOS Security Configuration Guide

Switch Access: Using Authentication, Authorization, and Accounting

Planning and Testing

After AAA is properly configured, network administrators may do only what is allowed on systems where they are permitted, and all activity will be logged. Therein lies the risk of deploying this system. An improper configuration can leave an administrator locked out of systems, or logged in but unable to execute a command (including exit). Recovery may require system reloads, password recovery techniques, and/or direct console access to the system.

The team discussed order and made a determination based on the risk. We worked first on devices that were physically close and on devices to which we could easily and rapidly gain physical access. Additionally, we opted to have one part of the team focus on the Cisco IOS Software-based system while the other group focused on the Catalyst OS-based switches. Despite our practice time in the lab, we were incomplete in our preparation. Fortunately, the results of our errors were easily corrected, but only because we studied, planned, and prepared as well as we did.

The project team implemented AAA with dual AAA servers to provide greater reliability.

There are three aspects to implementing AAA with Cisco Secure ACS for network management:

  • Install and configure Cisco Secure ACS on two systems
  • Configure AAA on Cisco IOS Software-based systems
  • Configure AAA on Catalyst OS-based switches

Installing and Configuring Cisco Secure ACS

It is important to study and follow the current, published guidelines for Cisco Secure ACS. In addition to the documents referenced above, the Cisco Documentation Site provides up-to-date guides.

A number of preparatory steps are required:

  • Inventory all network devices
  • Identify all members of the network administration team
  • Identify the limits of authority for each team member
  • Test users and authorizations on an isolated laboratory network

There are techniques for Cisco Secure ACS to accept all AAA requests from any device. Our team decided to manually enter each network device and manually configure its keys. A complete inventory provides a guide for completion. Unlike other tasks discussed in this article, an incomplete list will not result in a network failure or other performance problems. The result of an incomplete list will be absence of TACACS on a system.

We sorted the network support team members into two groups. The first group had unlimited access to all systems. The second group had the ability to log in to systems and to enter configuration mode, but was unable to modify any commands. They were limited to show and a few other commands that document system configuration and performance. This configuration required action on ACS and some testing.

Another objective was to create an ability to log in to systems in the event that the system was removed from the network. If all logins depend entirely on ACS, then when a device cannot see either ACS, it will not authenticate any users. To circumvent this issue, we determined that a network manager should be able to access a system with a username and password that is defined locally. We chose to limit this "back door" to the console port only. All Telnet and SSH sessions therefore require TACACS authentication. If TACACS is unavailable, direct physical access is required for system administration.

In our lab, ACS was initially installed and configured for use with an isolated lab. Both Catalyst OS and Cisco IOS Software-based devices were connected to the same segment. Testing started from there. There were three objectives in the TACACS/ACS setup:

  • Full AAA for all network administration on Cisco IOS/Catalyst OS devices
  • Two levels of authority
  • Local username/password "back door" for console port if TACACS becomes unavailable

ACS—Defining Groups

The team defined two groups. The "NetAdmin" group had the ability to configure devices without any limits on authority. The "NetSupport" group had the ability to log in to a device and enter the enable or privileged mode, although they could not execute any command that would change the function of the system. Users in NetSupport were permitted to use show, ping, and other similar commands. They were not permitted to enter configuration mode.

Limitations to authority can be configured in any of a number of ways. We chose to define "common services" to identify permitted commands. That profile was then assigned to the NetSupport group. Documentation on these processes with representative data is shown below.

For the authorization features to work, one must be able to define advanced TACACS features. These options must be turned on to bee seen. Prior to defining users and groups, we recommend going to Interface Configuration and then Advanced Options. On this screen, mark TACACS Advanced Services under Advanced Configuration Options. This is shown below:

Also check the Shell (exec) option if it is not already checked.

Before defining groups and users, define the Shared Components portion. This is where one restricts the authority of users. For our example, we wanted to allow some members of the staff to log in and enter the privileged (enable) mode but not change any settings. We learned that all commands, even commands without arguments, must have the Permit Unmatched Args box checked. Exit would not work without it. The configuration shown below works:

With group setup, confirm the following options:

  • Max Privilege level for any AAA Client should be set to 15
  • Shell (exec) gets a check mark
  • Privilege Level gets a check mark and a value of 15

Under Shell Command Authorization Set, there are two options. This is where one differentiates the NetSupport group, which will have Show_Me authority from the NetAdmin group, which will not have any restrictions on authority.

For the group with limited authority, NetSupport, select the second radio button:

  • Assign a Shell Command Authorization Set for any network device
  • Use the pull-down menu to choose Show_Me

For the group with unlimited authority, NetAdmin, select the third radio button:

  • Per group command authorization, then
  • Permit Unmatched Cisco IOS commands

This is illustrated below.

 

 

 


ACS—Defining Users

To simplify testing, it is recommended to establish one user in each group that will be used during the installation.

Advance TACACS+ setting must be selected. See sections above. If this option is not selected, the TACACS+ Enable Password will not be visible. On a number of systems, this enable password must be set in Cisco Secure ACS.

Additionally, be sure that Shell (exec) is selected. Most other setting should simply draw their settings from Group Settings. For example:

  • Shell Command Authorization set, use As Group

Only a few samples of the screens are shown.

 

The team configured ACS with its final IP addresses to avoid any risk or complication of having to change IP addresses after configuration and testing. Therefore, all switches introduced to the lab were defined in the same subnet.

Cisco IOS Software-Based TACACS

Testing and early deployment problems identified the risks of deploying TACACS (and frankly became the inspiration for this article). It is possible to lock oneself out of one's own systems. It is further possible to be logged in and executing commands and then to prevent oneself from executing any further commands, even exit.

The authors learned that different Cisco IOS Software versions and/or different classes of products respond to AAA commands differently. For example, our IOS-based TACACS testing was done on a new Catalyst 3550 switch. On this system, all AAA commands were accepted without impacting the current session. During deployment, the first Catalyst 3524-XL switch executed the authentication commands immediately. Then it executed the authorization commands. The network team then logged in to the system with an invalid username, a user that was not authenticated. Therefore, that group lost the ability to execute any further commands. The scripts were modified to accommodate the most conservative approach.

Additional lessons were learned regarding the core Catalyst 6509 switches. Although we had identified the devices in Cisco Secure ACS, we found that TACACS communicates the highest IP address defined for an interface to the TACACS server. This behavior is easily modified with the command:

ip tacacs source-interface xxx

Define the source interface such that its IP address matches the defined IP address for the device in ACS.

After a reliable script was tested and proven on several platforms, that script was used for all Cisco IOS Software-based systems. That script is as follows:

IOS-Based TACACS—Phase I

oursecret
enable
en-pass
conf t
!turn on AAA
aaa new-model
! tell people they are not welcome unless authorized
aaa authentication banner #
WARNING!!!
THIS IS A DEPARTMENT OF DEFENSE COMPUTER SYSTEM. Go away, etc., etc...
#
! define the aaa processes
aaa authentication login FRA group tacacs+
! note this authentication process allows for local username
aaa authentication login console-in group tacacs+ local
aaa authentication enable default group tacacs+ enable
! local username for use on console if all else fails
username FRA_joshua password 0 da_paswd
! define the tacacs servers
tacacs-server host 10.0.155.23 key 1123581321
tacacs-server host 10.0.155.22 key 1123581321
line con 0
! assigned authentication rules to interfaces/ports
login authentication console-in
line vty 0 4
login authentication FRA
line vty 5 15
login authentication FRA
end
exit
*** LOG OUT / LOG IN, Paste next section separately ****

At this point, authentication has been defined on the system. We recommend logging out of the system and then initiating a new Telnet session. Typically, we recommend keeping two Telnet sessions open as much as possible. We then applied the following script. Login activity and configuration commands will start logging to ACS immediately after success.

Cisco IOS Software-Based TACACS—Phase II

conf t
aaa authorization exec default group tacacs+ none
aaa authorization commands 0 default group tacacs+ none
aaa authorization commands 1 default group tacacs+ none
aaa authorization commands 15 default group tacacs+ none
aaa accounting exec default wait-start group tacacs+
aaa accounting commands 0 default wait-start group tacacs+
aaa accounting commands 1 default wait-start group tacacs+
aaa accounting commands 15 default wait-start group tacacs+
enable password en_pass
end
copy run star
exit

Catalyst OS-Based TACACS

Defining TACACS for systems running the Catalyst OS seemed to involve less risk and less variation than was encountered under Cisco IOS Software.

The process of testing the "back door" local authentication revealed an undocumented trick. There is no Catalyst OS equivalent to the Cisco IOS Software command username. Therefore, a network management team cannot manage the local username in the event of TACACS failure. The local username is a predefined static value of enable_15. The password used for enable_15 is the same as the enable password. After logging in, one must enter the enable mode and enter the enable password again.

The Catalyst OS script used is shown below:

oursecret
enable
en-pass
set tacacs server 10.0.155.21 primary
set tacacs server 10.0.155.22
set tacacs key 1123581321
!
set authentication login tacacs enable console primary
set authentication login tacacs enable telnet primary
set authentication login tacacs enable http primary
set authentication enable tacacs enable telnet primary
set accounting connect enable start-stop tacacs+
set accounting commands enable config stop-only tacacs+
set accounting suppress null-username enable
set authorization commands enable config tacacs+ if-authenticated console
set authorization commands enable config tacacs+ if-authenticated telnet

Anti-Spoofing and Other Recommendations

The final step for this network outage was to lock a few doors before we left. As mentioned earlier, the team wanted to improve security without creating diagnostic problems. Therefore, we opted to change only one variable per process to avoid compounding problem resolution. SSH will be implemented later but only after all current changes have proven stable and reliable.

Our steps to tighten the security of CDP and SNMP were limited. As an organization that relies on CiscoWorks for monitoring the enterprise network, we recognized that there was added risk in deploying SNMP restrictions at this moment. The use of CDP is strongly recommended for networks supported with CiscoWorks.

Furthermore, use of access lists to restrict access to the SNMP process has been inconsistently deployed in Catalyst switches. Although SNMP access lists are available on most platforms now, their use was introduced relatively recently. The earliest references we found for the command set snmp access-list were in Catalyst OS 7.5.

We strongly recommend implementing these features even though our team chose to delay because it would require operating system upgrades on some of the network equipment.

Our last actions during this short, scheduled outage were:

  • Turn off services that were not needed

These access lists were applied to interfaces as data flowed from the edges of the network toward the core, and as data flowed from the core toward the external networks.

Antispoofing and Other Recommendations

no service tcp-small-servers
no service udp-small-servers
no ip bootp server
no service finger
no ip http server
access-list 107  deny ip 0.0.0.0 0.255.255.255 any
access-list 107  deny ip 127.0.0.0 0.255.255.255 any
! see note below
access-list 107  deny ip 10.0.0.0 0.255.255.255 any
access-list 107  deny ip 169.254.0.0 0.0.255.255 any
access-list 107  deny ip 172.16.0.0 0.0.255.255 any
access-list 107 permit ip host 192.168.3.2 any
access-list 107  deny ip 192.168.0.0 0.0.255.255 any
access-list 107 deny icmp any any  redirect
access-list 107 deny icmp any any  mask-request
access-list 107 permit ip x.y.0.0 0.0.255.255 any

IP addresses were changed for publication in this article. All addresses used here were private IP address as outlined in RFC 1918. In a production network, one must permit valid address and limit access from private address—even as source addresses.

Acknowledgments

Christina Moore authored this article. The author wishes to thank U.S. Army Major Jerry L. Martin and Sergeant First Class James C. Parker for their help in documenting this collection of best-practice responses to NSA requirements.

Reference

NSA Security Configuration Guides

 

This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.

Back to Top