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:
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.
There are a few related articles at Cisco.com, including the following:
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
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.
Although the commands were known and tests were performed, there were still several outstanding questions:
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.
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 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.
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:
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:
Scripts were written before deployment and tested on sample equipment in an isolated laboratory network.
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
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.
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
Net stop w32time
Debug and view synchronization
W32tm -once -v
Net start w32time
Query SNTP settings
Net time /querysntp
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:
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:
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.
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:
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:
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:
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:
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:
For the group with unlimited authority, NetAdmin, select the third radio button:
This is illustrated below.
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:
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.
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
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
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:
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.
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.
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.