|
|
The Cisco Network Supported Accounts (NSA) Network Analysis Toolkit (NATkit), a leading-edge enhancement to NSA support offerings, is based on the recognition that many network management operations are most efficiently handled with technology.
NATkit is a Web-based network problem avoidance and troubleshooting application that has built-in intelligence to help engineers prevent (or isolate and resolve) networking problems faster than ever before. NATkit performs as a proactive, real-time troubleshooting application that resides at the customer site.
NATkit delivers critical network information to NSA customers and to Cisco's NSA engineers, collecting network data through Simple Network Management Protocol (SNMP) requests, Telnet commands, and Syslog event messages to produce consolidated informative reports accessible through a web browser. Network data is available onsite to the customer and is updated through customer-controlled task scheduling. Network data is also encrypted and downloaded daily to Cisco for analysis by NSA engineers.
As a result, NATkit enables Cisco customers to maintain a high level of network management process integrity. The information NATkit provides allows our NSA experts to become more knowledgeable about the daily activities on customer networks. NATkit enables NSA engineers to provide proactive support capabilities, in order to maintain a high level of preventive and remedial support. In turn, it helps optimize the network reliability, performance, and uptime of the customer.
Why have both NATkit and RME on your network?
NATkit version 2.0 reduces the overlap of RME and NATkit by integrating them into a single package. All NATkit functionality is retained but the packages run on a single workstation and use a common user interface.
Although inventory collection is now done by RME, RME and NATkit share the information, and devices are no longer polled separately. NATkit does the collection of Syslog information while the RME collector is disabled. NATkit development and RME development are working to reduce the overlap even more in subsequent releases.
The following graphic shows how data gets from a customer network to the NATkit engineers at Cisco.
The following are the minimum recommended requirements for installing and operating NATkit 2.0:
NATkit supports all Cisco routers and switches and all versions of Cisco IOS software.
NATkit consists of the modules and features described in the following sections.
The Syslog module reads the Syslog files and stores Syslog messages for presentation in various formats. The NATkit system should not be the Syslog server; the Syslog files should be remotely mounted. Therefore NATkit can monitor multiple Syslog servers. Syslog also works with the Event Dispatcher module, this allows NATkit to get additional information based on messages from any of the the four parts (facility, severity, mnemonic, text). An example would be collecting an inventory and a configuration when a message with the mnemonic "RELOAD" is seen. When a change is detected NATkit will update the associated files and put a flag in the Daily Report, letting the NSA engineer know the changes happened.
The Configurations module triggers on changes in router configurations to create configuration differences. It also displays the current router configurations. The configuration differences are displayed in two modes: UNIX differences mode and the router command differences mode. Device configurations can be collected by SNMP in NATkit 2.0.
SNMP MIBs cover a whole array of variables on the Cisco devices. The SNMP Poller module presents the most useful MIBs and allows the user to select which MIBs are polled, what level constitutes a violation, and (via the Event Dispatcher) which commands to issue when a violation occurs. The user can also add extra MIBs if the ones presented are not enough. The main purpose of the SNMP Poller module is to trigger on user-defined exceptions relating to the SNMP MIBs variables.
There is a need in every network to measure the availability of the devices. The Availability module helps to facilitate calculating availability of Cisco devices on the network.
The Download module encrypts the data collected in the past 24 hours and sends it to the NSA database server at Cisco. At Cisco, the information is decrypted and looked over stringently by a network engineer for any anomalies. The information is also used to create reports, Year 2000 (Y2K) compliance, Syslog messages by quarter, network profiles, and so on. HTTP download is available in NATkit 2.0.
At the Cisco site (when the data is transferred) and at the customer site, the Access Control software groups all users in three categories:
Based on customer selected criteria the Syslog Monitor and the SNMP Poller will call the Event Dispatcher module. The Event Dispatcher module is configured by the user to perform a series of tasks, the goal of which is to record information that will be useful in troubleshooting the event. The Event Dispatcher can use Telnet to access the device, issue commands, and record the response(s). Also, user scripts can be executed and e-mail sent, alerting the appropriate person on the occurrence of the event. This feature enables the software to monitor changes and problems in the network 24 hours a day.
The Auto Discovery module is a configurable system that discovers new Cisco devices and allows the user to add them to RME and NATkit.
WAN switch networks without StrataView users are able to run scripts to monitor CPU utilization, load model, memory, and software logs.
The Network Analysis Monitor module is fully intregrated into NATkit 2.0.
Device Name Mapping (DNM) builds a table to map IP addresses to device name(s) for Syslog presentation. Syslog messages are grouped by device name.
The following standards are for Host Security:
The following standards are for Application Security:
The following standards are for Transport and Backend Security:
Possible future Security provisions are listed below.
The following are recommended practices from the NSA group:
The following information discusses software security issues a customer may have with NATkit 2.0:
NATkit requires that a Syslog server have NFS mounts if the machine on which it resides is not a Syslog server. If NFS mounts are deemed a security risk in the network, then the NATkit machine must be an additional Syslog server.
The NSA Tools Team is also looking into other means of sharing information with Syslog servers, with one possibility being sdist (secure distribution software). This exploration should not be looked upon as a commitment from the NSA Tools Team.
NATkit uses mail for the following reasons :
The version of Sendmail installed on machines provided by NSA is 8.9.3. We will update the Sendmail version if we find that the new version contains enhanced security features.
Some customers are concerned about Telnet and FTP daemons that could be running on the NATkit machine. We do not run any inetd daemons on the NATkit machine if the customer does not want us to. We provide access to the NATkit box via secure shell (ssh version 1). It should be noted that the customer has the responsibility to provide a point in its network where a NSA Tools Team member could log in to get to the NATkit machine via ssh for any natkit debugging/troubleshooting problems. The customer is also responsible for key management for the secure shell provided.
NATkit uses Telnet and SNMP to gather network information from Cisco devices like routers, LAN switches, and WAN switches. Much more information is available from the Cisco devices via Telnet than via SNMP. We use SNMP for the majority of the information collected, but Telnet is specifically used for the following:
As a result, we still must allow Telnet from a NATkit machine to Cisco routers and LAN switches because they do not support ssh as of yet.
NATkit currently does not support secure ID logins, but does support all other types of login including TACAS and different levels of login modes for routers and LAN switches.
NATkit supports access to Cisco devices via TACACS.
NATkit is a web-based network troubleshooting service. NATkit 2.0 uses Apache 1.3.0 (Apache 1.1.1 for NATkit 1.6x) as its web server. The web server will be upgraded to the latest Apache release.
NATkit does not support either SSL or SHTTP at this time. However, we are committed to providing at least SSL support with Apache.
Option 1 --- NSA provides the customer with a Sun Sparc workstation on which NATkit is loaded. The model of the workstation provided to the customer depends on the complexity of the network of the customer and its size. Because the machine is provided by Cisco but resides on the customer premise, we let the customer make it as secure as it sees fit. Nevertheless, the NSA Tools Team would like to have access to the machine for routine maintenance and software upgrades. We allow the customer to change and maintain the root password. We only ask that the customer provide us with the root password or some "pseudo" functionality when needed. The NATkit software does not execute as root on the machine. Instead it has its own UNIX ID, namely "natkuser."
Option 2 --- A customer can use its own server to host the NATkit application. However, this can cause severe restraints on what the NSA Tools Team can accomplish because of events that happen outside of its control.
We highly recommend the first option.
NATkit downloads data to Cisco from the customer site once every 24 hours. The data is currently downloaded using FTP, PFTP, or e-mail. In version 2.0 of NATkit, we have added support to download data by HTTP access. The data to be downloaded is encrypted and compressed prior to being transported. The customer can choose to use any of the three encryption schemes that NATkit supports:
The customer is completely in control of determining what information it wants transported back to Cisco. NATkit software provides the customer with the ability to transport only the information it chooses. NSA would prefer to receive all customer information as this helps make the NSA engineer proactive, and it allows quick response to events with adequate information immediately available.
NATkit currently downloads once every 24 hours. The time to download is chosen randomly between 1 a.m. and 4 a.m. local time. The customer can reset the time to download at its convenience.
As mentioned earlier, the customer has full control over whether to allow downloads or to prevent them totally. The customer also has control over partial downloads. NATkit downloads are broken down by the modules described on pages 2-5 through 2-7.
The customer determines which of these modules can download data at any given time.
NATkit uses a static key for all encryptions. Customers should make sure that the 128-bit key that NATkit uses to do 128-bit Triple DES is not a 64-bit key replicated twice.
NATkit has committed support for stronger key management protocols, like Diffie Hellman, in subsequent releases.
The following information discusses possible security issues a customer may have once its data is received by Cisco:
We are working on an access control method that restricts the viewable information to either the NSA engineers assigned to the account, any NSA engineer, or any Cisco engineer.
Whenever a Cisco product undergoes a change or revision, a Field Notice is announced and the customer must take appropriate action. The NSA engineer is also immediately alerted, whose job it is to facilitate this process. The NSA engineer is responsible for tracking down a Field Notice and determining to what extent it will affect a customer. NSA engineers are equipped with tools that enable them to immediately track the status of a customer following a field alert.
The backend has web-enabled GUI screens that allow engineers to view the daily reports, which will inform them if their customer has been affected by a Field Notice within the past 24 hours, and which (if any) devices were affected. A search feature is also available so an engineer can see what the affected devices were for a field alert during a specified time.
A Field Notice can be either hardware-or-software based. The current system, however, only addresses the Software Field Notice.
A Field Notice will tell a customer how its network will be affected. Customers will also receive reports that will include the following:
Quarterly and annual reports are aslo provided.
In order to guarantee that all the information is available at the backend for a criteria match during the Field Notice announcement, the NATkit Field Notice Module triggers a script that collects the audit information from the customer network at noon every 15 days. The collected data is then sent back to CCO, where it gets parsed upon arrival. All relevant information gets populated in the database, and is then scanned against the information provided in an announced Field Notice. If there is a match, the appropriate NSA engineer is notified for proactive action.
Both NATkit software and the third-party applications included with NATkit will not be effected by the date change on January 1, 2000. However, like any application, NATkit is dependent an operating system. In the case of NATkit that operating system is currently SUN Solaris, version 2.5.1 and 2.6.
Solaris versions prior to 4.0 do not address the year 2000 problem in their original form. However, patches are available from Sun that will extend the life of these systems well past January 1, 2000. Configured properly these systems will run until the year 2038.
The latest versions of these patches are added to all NATkit workstations configured by NATkit support. For customers configuring their own systems, NATkit support is available to help get the latest patches installed before the NATkit software is installed. Contact NATkit support at natkit-support@cisco.com for more information.
For more information on Solaris and Y2K please read the information found at the Sun Y2000 web site (http://www.sun.com/y2000/faq.html).
Posted: Wed Dec 15 14:29:45 PST 1999
Copyright 1989-1999©Cisco Systems Inc.