CISCO SECURE IDS AND ATTACK PREVENTION | Hacking Exposed Cisco Networks: Cisco Security Secrets & Solutions

The Cisco IDS is designed to protect both the network perimeter and the internal IT infrastructure in an efficient manner. With the increased sophistication of attacks, achieving efficient network intrusion detection and blocking is critical. By combining complex methodologies, Cisco claims to ensure business continuity and minimize the effect of malicious attacks. Cisco takes a multilayered approach to intrusion detection and prevention to ensure the following elements are present:

Accurate attack detection
Intelligent attack investigation
Ease of security management
Flexible deployment options for all network design models and topologies

To achieve these elements, Cisco implements a line of IDS products that can be integrated into current network routers and switches, deployed as separate IDS appliances, or run as software applications on management workstations.

Cisco IDS consists of two major components : the IDS sensor and management console. While the sensor sniffs or analyzes bypassing traffic, the management console provides interfaces for alarms monitoring and distributed sensors configuration. The sensors come in two varietiesthose that do passive traffic monitoring (standalone appliances and blades) and those that analyze traffic passing through the device (software IOS IDS and PIX). Passively sniffing devices do not impose any network performance penalties. To the contrary, inline processing of bypassing traffic can overload participating routers or PIX firewalls. If the throughput of the passive monitoring device is below your network bandwidth, some attacks can slip in undetected. If the throughput of the inline monitoring device is below your network bandwidth, the router or PIX can freeze. Keep these factors in mind when you are selecting an IDS solution for your network.

Hardware Standalone IDS Sensors

A standalone rack-mountable (1U) Cisco IDS 4215/4235/4250/4250-XL sensor provides a pervasive protection against unauthorized, suspicious, or downright malicious activity traversing the network. These purpose-built, high-performance network security appliances can analyze traffic in real time up to 1000 Mbps (Cisco 4250 XL), notifying management console(s) with detailed alerts. Cisco IDS sensors support both knowledge (anomaly detection)-based and signature-based attack detection. Cisco's signature database is constantly updated to keep up with current security threats. Visit http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_data_sheet09186a008014c532.html to get up-to-date information.

The Cisco IDS 4215 sensor monitors up to 80 Mbps bandwidth and is appropriate for multiple WAN links monitoring. Up to five sniffing interfaces of the IDS 4215 sensor can watch five subnets simultaneously . The same applies to all higher-end sensor models, apart from Cisco IDS 4250-XL. Cisco IDS 4235 can handle 250 Mbps of traffic and is suitable for switched environments monitoring in addition to protecting multiple WAN links, OC-3 included. Cisco IDS 4250 supports a 500 Mbps speed and can be deployed at the core layer of campus networks. It is also upgradeable to scale to full line-rate gigabit performance if needed; however, Cisco IDS 4250-XL is recommended for deployment on fully loaded gigabit links.

OS-wise, Cisco IDS 4200 series are Solaris-based. The sensor's IDS functionality is implemented as an aggregation of daemons, including at least the following:

fileXferd A daemon that receives configuration files from the management console
loggerd A log file creation daemon
managed A daemon capable of sending a shun command to another Cisco device such as a PIX firewall for automated attack blocking
packetd The actual packet-capturing and analysis interface
postofficed A communication-handling daemon

These daemons, and their configuration, library, log, and temporary files as well as configuration utilities, are located in the /usr/nr directory that has the following structure:

 /usr/nr/bin              /usr/nr/etc      /usr/nr/bin/eventd       /usr/nr/etc/.lt      /usr/nr/bin/eventd/skel  /usr/nr/etc/backups      /usr/nr/bin/sap          /usr/nr/etc/licenses      /usr/nr/bin/sap/skel     /usr/nr/etc/nrConfigure      /usr/nr/bin/sap/sql      /usr/nr/etc/oem      /usr/nr/bin/sap/sql/skel /usr/nr/etc/oem/templates                               /usr/nr/etc/wgc                               /usr/nr/etc/wgc/templates      /usr/nr/lib              /usr/nr/var      /usr/nr/skel             /usr/nr/var/dump      /usr/nr/tmp              /usr/nr/var/iplog      /usr/nr/tmp/queues       /usr/nr/var/new                               /usr/nr/var/tmp

Unfortunately, we cannot discuss the functionality and configuration of these daemons in this chapter since it is intended to give you a taste of the vast range of Cisco security safeguards, rather than the specifics. If you have a deep interest in Cisco IDS appliances architecture and configuration, we suggest you consult http://www.cisco.com/en/US/products/sw/secursw/ps2113/prod_architecture09186a00800eead6.html or specific literature on the subject, such as Cisco Secure Intrusion Detection Systems Student Guide (CSIDS), provided by the Cisco Academy; Cisco Security Professional's Guide to Secure Intrusion Detection Systems (Syngress, 2003); or Cisco Secure Intrusion Detection System (Cisco Press, 2002).

When a Cisco 4200 IDS sensor detects an attack, the following can be performed:

No action
Shun
Log
Shun + log
TCP connection reset
TCP connection reset + shun
TCP connection reset + log
TCP connection reset + shun + log

Shun (shunning) refers to the complete blocking of any traffic from the offending host or subnet. Log (logging) refers to both attack event alarms and whole suspicious IP session logs. All types of logs can be sent to either the Cisco IDS management console or a traditional UNIX syslog. As you can see, because of the possible connection reset and shun functions, a Cisco IDS 4200 sensor is more than just an IDS sensor in a traditional meaning of the term . It is an intrusion prevention system (IPS)a prevention appliance.

Modular IDS Sensors

The Cisco IDS module is available for 2600, 3600, and 3700 series routers (NM-CIDS-K9, one module per router only) as well as for Catalyst 6500 series switches (IDSM-2, WS-SVC-IDS2-BUN-K9 if purchased as part of a Catalyst system, WS-SVC-IDS2BUNK9 if purchased separately as a spare). To support NM-CIDS-K9, minimum Cisco IOS software release 12.2(15)ZJ is needed, while CatOS 7.6(1) is the minimum requirement for the IDSM-2 support. These blades are a part of the integrated Cisco IDS family sensor portfolio and the Cisco Intrusion Protection System. Cisco IDS sensors work in concert with the other IDS components installed throughout the corporate network, including Cisco IDS management consoles, CiscoWorks VPN/Security Management Solution, and Cisco IDS Device Manager, to protect your data and information infrastructure efficiently .

It is very important to assess what kind of bandwidth throughput your IDS blade can support. If your network throughput is higher than what the IDS module can handle, a significant percentage of the traffic will pass by without intrusion detection analysis performed on it. The NM-CIDS-K9 blade supports up to 10 Mbps in the Cisco 2600XM, and up to 45 Mbps in the Cisco 3700 Series, while the Cisco Catalyst IDS module (IDSM-2) supports 600 Mbps throughput. Thus, Cisco 2600 and 3700 IDS blades are suitable for protecting multiple WAN links, while IDSM-2 can be positioned anywhere on the network, even at the core layer. Multiple IDSMs can be placed into the Catalyst 6500 chassis to scale for bandwidth above 600 Mbps.

Since the storage of detected events is performed locally on the module, it is vital to know how much storage space on the blade is available and how much of it is free. It is also necessary to monitor the amount of RAM and CPU cycles consumed on the module. Following are the main characteristics of NM-CIDS-K9 and IDSM-2 blades to be used as a reference.

For the NM-CIDS-K9:

Operating system: Cisco IDS 4.1 Sensor Software
Supported platforms: Cisco 2600XM, Cisco 2691, Cisco 3660, Cisco 3725, Cisco 3745
CPU: 500 MHz Intel Mobile Pentium III
Default SDRAM: 256MB
Maximum SDRAM: 512MB
Internal disk storage: 20GB IDE
Flash memory: 16MB internal plus optional external compact Flash memory

For the IDSM-2 (note that Cisco IDSM-2 is classified as a "strong encryption" product and its export is restricted):

Operating system: Red Hat Linux 6.2 (at the time of writing anyway)
Supported platforms: Cisco Catalyst 6500 (1U module)
CPU: Pentium P3 1.13 GHz on main board with 232 MHz IXP 32 bit StrongARM policy processor on the accelerator
RAM: 2GB
Internal disk storage: 100GB hard drive (20GB used), 4GB event storage

When IDSM-2 is deployed, traffic can be fed into the module in two ways:

Using Switched Port Analyzer (SPAN). This is simple to do. For example, Catalyst6500>set span 2/8 6/1 rx create will mirror the traffic from port 2/8 to the IDSM-2 sensing port 6/1, while Catalyst6500>set span 69 6/1 rx create copies traffic from VLAN 117 to the IDSM-2 sensing port 6/1 for analysis.
Using VLAN Access Lists (VACLs), as mentioned in the previous chapter. This requires that the switch supervisor engine has a Policy Feature Card (PFC) option and is more complex to configure. However, this method offers higher flexibility in selecting traffic for IDS inspection. If you use multiple IDSM-2 modules, VACLs can be employed to distribute traffic between them.

Tip	By default, IDSM-2 sniffing port 1 is a trunk port that will get traffic from all VLANs on the switch as long as capture ACLs are applied to these VLANs. Use `set trunk` and `clear trunk` commands to select VLANs you want to be monitored by the IDSM-2.

When IDSM-2 matches a signature, it can perform both event logging/alarm sending and attacker IP range shunning. Note, however, that there is no TCP connection reset option.

Cisco IOS IDS Software

Cisco IOS IDS (o3 code trains) identifies more than 100 of the most common attacks and uses signatures to detect the misuse of the network traffic. Unlike Cisco 4200 sensors or Cisco XT 5600 Traffic Anomaly Detectors, no knowledge-based attack detection is implemented. Around 40 of the new signatures are based on analyzed data from the Security Posture Assessment Database, PIX signature database, and 15 of the most dangerous HTTP signatures in the Network Security Database ( http://www.network-intelligence.com/support/docs/CommonDocs/ExploitSignatures/all_sigs_index.html ).

Only 59 hard-coded intrusion-detection signatures were provided in Cisco IOS Firewall in images prior to Cisco IOS software release 12.2(11)YU. An additional 42 new hard-coded signatures are included in the current releases, in addition to all images after Cisco IOS software release 12.2T. These signatures were chosen from a wide cross section of IDS signatures and represent the most severe breaches of security, common network attacks, and enumerating attempts commonly launched against real-world networks.

In general, Cisco IDS signatures are categorized by severity and complexity:

Severity
- Information signatures (40) Detect enumeration attempts such as ping sweeps and portscans
- Attack signatures (61) Detect cracking attempts such as illicit SMTP or FTP commands sent or mail bombing
Complexity
- Atomic signatures (74) Detect simple attack patterns (that is, specific attack attempts against a selected host). Auditing these signatures has no trafficdependent RAM requirement.
- Compound signatures (27) Detect complex patterns (that is, attacks against multiple hosts , over extended time periods with multiple packets sent by attackers ). To audit these signatures, CBAC allocates memory for connection state maintenance, configuration database, and internal caching.

Different types of signatures supported by Cisco Secure IDS are marked by signature series numbers , as shown here:

1000 Series-IP signatures IP options, fragmentation issues, and malformed IP packets
2000 Series-ICMP signatures Various types of ICMP traffic and ICMP floods
3000 Series-TCP signatures TCP session records, various types of TCP portscans, TCP hijacking, SYN flood, mail, FTP, NetBIOS, legacy web attacks, and other forms of TCP- related malicious activity signatures
4000 Series-UDP signatures UDP traffic records, portscans, floods, and other forms of UDP-related attacks
5000 Series-web-related attack signatures Common Gateway Interface (CGI) scans
6000 Series-cross-protocol signatures Signatures of Domain Naming System (DNS), Remote Procedure Call (RPC), and various DDoS attacks as well as flagging authentication failures
8000 Series-string-match signatures Custom string matches and custom TCP applications signatures
10000 Series-ACL violation signatures Alert about defined IOS access lists violations

The default classification of alarms sent when a signature is matched is tied to the signature severity level. Low severities 1 and 2 alarms are generated for information purposes, for example when an unknown IP option is detected. Medium severity 3 alarms are triggered by ping sweeps and portscans. High severities 4 and 5 alarms are sent when full connect TCP portscans and clear-cut attacks (such as buffer overflow attempts) are discovered . Whether the alarm is at level 4 or 5 is determined by a possible attack outcome (for example, a grabbed banner versus a remote rootshell).

When bypassing packets match a known signature, the Cisco IOS IDS can be configured to take these actions:

Send an alarm message to a remote syslog server or a centralized management interface.
Drop the offending packet.
Reset the suspicious TCP connection. No shunning or complete IP session logging occurs, as can be done on Cisco IDS 4200 series sensors or (in case of shunning) IDSM-2 blades.

The configuration of send, drop, and reset is done via a series of ip audit commands.

Note

The link to the full list of signatures mentioned while discussing standalone Cisco IDS sensors applies to the IOS IDS signatures just as well ( http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_data_sheet09186a008014c532.html ; this appears to be broken at the moment, but hopefully will be back soon). Consult it when you need to know details about a particular signature.

Cisco PIX Firewalls as IDS Sensors

A PIX firewall is also an IDS device, similar to an IOS software IDS on a router. To underline this analogy, a similar set of ip audit commands is used on the PIX to configure various IDS-related options. The main difference between the PIX and IOS IDS routers is the number of signatures supported and that the PIX cannot send alarm messages to Cisco Secure IDS management consoles. Thus, when doing centralized remote logging with PIX, you are limited to the good old UNIX syslog. After all, the IDS functionality in PIX is provided primarily to improve this firewall's logging abilities and stop the attacks at the point of entry by dropping, resetting, and shunning the traffic recognized as malicious. PIX is naturally good at performing such actions and can work in tandem with a Cisco Secure IDS sensor to perform shunning. If that is the case, a sensor-triggered shun ip command takes precedence over the ACLs previously configured on the PIX.

Surprisingly, the list of IDS signatures on the PIX is not as extensive as the list on the IOS IDS router and is limited to the signatures contained in the Cisco Network Security Database (NSDB). To find out more about PIX IDS signatures supported, you can visit the Cisco web site and look up the Cisco PIX Firewall System Log Messages for the PIXOS version you use. You can view the messages by their number order as well their listing in accordance to their severity level. PIX syslog messages 400000 through 400051 are Cisco IDS signature messages; however, if you look at the whole list of PIX syslog messages, you'll discover more attack-related messages than just 51. Here's an example, which is likely to be an attack attempt alarm, even though it does not belong to the 400000400051 range:

Disable Signatures to Avoid Overflooding Logs

It is good to disable a few signatures to avoid overflooding your logs with information of little security relevance. We usually add the following to the router configuration file:

 ip audit signature 2000 disable      ip audit signature 2001 disable      ip audit signature 2005 disable

Signatures 2000, 2001, and 2005 stand for ICMP Echo Reply, ICMP Host Unreachable, and 2005 ICMP Time Exceeded for a Datagram. We do not consider these events to be security-critical unless you are bent on monitoring users pinging and tracerouting from your network.

 Message 403109  Error Message  %PIX-4-403109: Rec'd packet not an PPTP packet. (ip) dest_address=      dest_address, src_addr= source_address, data: string.  Explanation  The firewall received a spoofed PPTP packet. This may be a hostile      event.  Recommended Action  Contact the peer's administrator to check the PPTP      configuration settings.

Cisco Traffic Anomaly Detector XT 5600

Cisco Traffic Anomaly Detector XT 5600 provides multigigabit performance to defend the largest networks by rapidly discovering potential DDoS, DoS, and other attacks. As suggested by the device name , XT 5600 uses knowledge-based intrusion detection methodology to detect malicious activity. Cisco Traffic Anomaly Detector XT 5700 is different from XT 5600 in that it offers 1000BASE-SX multimode fiber optic ports with LC connectors instead of 100/1000Base-T Ethernet ports on XT 5600. These appliances are designed to work in tandem with a Cisco Guard XT 5650 to thwart DDoS attacks directed at the protected network. The attacks detected and blocked include the following spoofed and nonspoofed attacks:

TCP floods (SYNS, SYN-ACKS, ACKS, FINS, fragments )
UDP floods (random port floods, fragments)
ICMP floods (unreachable, echo, fragments)
DNS floods
Some client-side attacks
Inactive and total connections overload
HTTP Get requests floods
BGP attacks

The Cisco Traffic Anomaly Detector XT 5600 resides off the critical path to the protected network as a router- on-a-stick and mirrors all the traffic entering the network while passively sniffing it to identify possible traffic anomalies. Once an anomaly is detected, alerts are sent to the network operators and to the Cisco Guard XT 5650 that then diverts the malicious traffic off the intended target and removes offending packets.

Cisco Secure IDS Management Consoles

Apart from the PIX and Cisco Traffic Anomaly Detector XT 5600, all IDS appliances we have described so far can be configured, managed, and monitored from Cisco Secure IDS management consoles or directors. In addition, these consoles provide alert paging services and access to the network security database filled with information about signatures supported by sensors. Cisco provides two different software bundles with the IDS director functionality: UNIX Director and Windows NTbased Cisco Secure Policy Manager (CSPM) IDS Console. Both products offer similar functionality with the main differences between them being local logging, alarm sending, and alarm severity level recognition peculiarities .

An important feature of both UNIX Director and CSPM IDS Console is the ability to create and distribute new custom signatures to adapt to new attack threats before the manufacturer does. This can be done by applying the string to trigger the alarm, its unique signature ID number, the port involved, the direction of the traffic flow, the number of strings matched to consider this event a threat, and the action to be performed on match in the Matched Strings menu. The alarm severity level for the new alarm to be generated can also be set on the basis of the configuring expert's threat assessment and judgment.

Similar to the architecture of Cisco IDS 4200 series sensors, Cisco IDS UNIX Director functionality is implemented as a collection of daemons on a Solaris machine (albeit with the HP Open View additionally installed). In fact, many of the daemons used by 4200 sensors and the UNIX Director are the samefor example, fileXferd, loggerd, postofficed, and configd. The daemons also used by the UNIX Director include smid (a daemon that populates the alarm icons on the HP Open View user interface), sapd (data and file management daemon), sapx (provides Oracle or Remedy database population), and eventd (a daemon that sends various notifications based on the sensor alarms received). Note that these daemons, with an exception of sapx, can also be run on the IDS 4200 sensors, even though they are not crucial for these appliances' operation.

The architecture of the Windows CSPM IDS Console is, of course, somewhat different and includes the following:

nr.postofficed Similar to postofficed
Sensor CA Similar to fileXferd
nr.smid A security management interface daemon
EDI Event Database Interface; similar to eventd
EVS Event Viewing System; performs the function similar to the one performed by HP Open View
CIDS configuration GUI Similar to both the UNIX Director GUI and configd
cvtnrlog.exe A Windows command-line utility similar to the UNIX Director loggerd

While writing this Hacking Exposed book, we did wonder whether these multiple daemons run by both Cisco IDS sensors and management applications were ever thoroughly assessed on the subject of buffer overflow attacks resistance. Another potentially good target for exploitation is the IDSM-2 module. As you have probably noticed, ISDM-2 runs Red Hat and a rather old version of this Linux distribution with multiple known vulnerabilities and no current vendor support. While these devices and applications are not expected to be abundant on the Internet and be a good target for script kiddie mass scan sweeps, the impact of taking over IDS sensors (not to mention the multiple device management consoles) would be extremely severe. Such exploitation is a true goldmine for highly skilled industrial espionage or sabotage attackers as well as rogue employees within large enterprises that rely on Cisco Secure IDS for the complete IT infrastructure protection.