The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The Cisco IOS Intrusion Prevention System (IPS) uses the following methods to protect a network from internal and external attacks and threats:
•IPS signatures are dynamically updated and posted to Cisco.com on a regular basis so that customers can access signatures that help protect their network from the latest known network attacks.
•A Parallel Signature Scanning Engine is used to scan for multiple patterns within a signature microengine (SME) at any given time. IPS signatures are no longer scanned on a serial basis.
•Cisco IOS IPS supports both named and numbered extended access control lists (ACLs).
Note Cisco IOS IPS restructures and replaces the existing Cisco IOS Intrusion Detection System (IDS).
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Configuring Cisco IOS IPS" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
•Prerequisites for Configuring Cisco IOS IPS
•Restrictions for Configuring Cisco IOS IPS
•Information About Cisco IOS IPS
•How to Configure Cisco IOS IPS on a Device
•Feature Information for Configuring Cisco IOS IPS
It is recommended that a new Cisco IOS image be loaded on your router before installing Cisco IOS IPS.
Compatibility with VMS IDS MC 2.3 and Cisco Router SDM
VMS IDS MC provides a web-based interface for configuring, managing, and monitoring multiple IDS sensors. SDM is a web-based device-management tool that allows users to import and edit SDFs from Cisco.com to the router. VMS IDS MC is for network-wide management while SDM is for single-device management. It is strongly recommended that customers download the SDF to an IDS MC 2.3 network management device or an SDM.
Customers can choose to download the SDF to a device other than VMS IDS MC or SDM (such as a router) through command-line interface (CLI); however, this approach is not recommended because it requires that the customer know which signatures come from which signature engines.
Signature Support Deprecation
Effective Cisco IOS Release 12.3(8)T, the following signatures are no longer supported by Cisco IOS IPS:
•1100 IP Fragment Attack (Attack, Atomic)
Triggers when any IP datagram is received with the "more fragments" flag set to 1 or if there is an offset indicated in the offset field. (To scan for application layer signatures across fragments, you can enable virtual fragment reassembly.)
•1105 Broadcast Source Address (Compound/Attack)
Triggers when an IP packet with a source address of 255.255.255.255 is detected. This signature may be an indicator of an IP spoof attack or an attempt to subvert a firewall, proxy, or gateway.
•1106 Multicast IP Source Address (Compound/Attack)
Triggers when an IP packet with a source address of 224.x.x.x is detected. This signature may be an indicator of an IP spoof attack or an attempt to subvert a firewall, proxy, or gateway.
•8000 FTP Retrieve Password File (Attack, Atomic) SubSig ID: 2101
Triggers on string "passwd" issued during an FTP session. May indicate that someone is attempting to retrieve the password file from a machine to try and gain unauthorized access to system resources.
Memory Impact on Low-End to Midrange Routers
Intrusion detection configuration on certain routers may not support the complete list of signatures because of lack of sufficient memory. Thus, the network administrator may have to select a smaller subset of signatures or choose to use the standard 100 (built-in) signatures with which the routers are shipped.
Action Configuration through CLI No Longer Supported
Cisco IOS IPS actions (such as resetting the TCP connection) can no longer be configured through CLI. If you are using the attack-drop.sdf signature file, the signatures are preset with actions to mitigate the attack by dropping the packet and resetting the connection, if applicable. If you are using VMS or SDM to deploy signatures to the router, you must first tune the signatures to use the desired actions.
Any CLI that is issued to configure IPS actions is silently ignored.
Restrictions for Transparent Cisco IOS IPS
•Mixed-media bridging configurations are not supported. Only Ethernet media is supported.
•Layer 2 signatures are not supported.
•Multicast traffic is not processed.
•If more than two interfaces are assigned to a bridge group, any routers that are acting as first-hop gateways to hosts that are in the bridged network (the bridge group) must allow ICMP time-to-live (TTL) exceeded messages to pass.
•Spanning Tree Bridge Protocol Data Units (BPDU) and packets that are to be routed out of the bridge, if IRB is configured, are not inspected.
•Transparent Cisco IOS IPS Overview
•Signature Microengines: Overview and Lists of Supported Engines
•Supported Cisco IOS IPS Signatures in the attack-drop.sdf File
The Cisco IOS IPS acts as an in-line intrusion detection sensor, watching packets and sessions as they flow through the router and scanning each packet to match any of the Cisco IOS IPS signatures. When Cisco IOS IPS detects suspicious activity, it responds before network security can be compromised and logs the event through Cisco IOS syslog messages or Security Device Event Exchange (SDEE). The network administrator can configure Cisco IOS IPS to choose the appropriate response to various threats. When packets in a session match a signature, Cisco IOS IPS can take any of the following actions, as appropriate:
•Send an alarm to a syslog server or a centralized management interface
•Drop the packet
•Reset the connection
•Deny traffic from the source IP address of the attacker for a specified amount of time
•Deny traffic on the connection for which the signature was seen for a specified amount of time
Cisco developed its Cisco IOS software-based intrusion-prevention capabilities and Cisco IOS Firewall with flexibility in mind, so that individual signatures can be disabled in case of false positives. Generally, it is preferable to enable both the firewall and Cisco IOS IPS to support network security policies. However, each of these features may be enabled independently and on different router interfaces.
SDEE is an application-level communication protocol that is used to exchange IPS messages between IPS clients and IPS servers.
SDEE is always running, but it does not receive and process events from IPS unless SDEE notification is enabled. If SDEE notification is not enabled and a client sends a request, SDEE responds with a fault response message, indicating that notification is not enabled.
When SDEE notification is enabled (through the ip ips notify sdee command), 200 events can automatically be stored in the buffer. When SDEE notification is disabled, all stored events are lost. A new buffer is allocated when the notifications are reenabled.
When specifying the size of an events buffer, note the following functionality:
•It is circular. When the end of the buffer is reached, the buffer starts overwriting the earliest stored events. (If overwritten events have not yet been reported, a buffer overflow notice is received.)
•If a new, smaller buffer is requested, all events that are stored in the previous buffer is lost.
•If a new, larger buffer is requested, all existing events is saved.
If customers want to protect their network through a typical Cisco IOS IPS device, they must manually readdress each of the statically defined devices on the trusted network. A transparent Cisco IOS IPS device allows customers to "drop" a Layer 3 IPS device in front of the devices that need to be protected. Thus, the tedious and costly overhead that is required to renumber devices on the trusted network is eliminated.
A transparent Cisco IOS IPS device acts as a Layer 3 IPS between bridged interfaces. (The current implementation of the transparent IPS does not support Layer 2 IPS functionality; thus, IPS can act only as a Layer 3 device.)
If configured for bridging, a Cisco IOS device can bridge any number of interfaces. The device can complete basic bridging tasks such as learning MAC addresses on ports to restrict collision domains and running Spanning Tree Protocol (STP) to prevent looping in the topology.
Within bridging, a user can configure Integrated Routed Bridging (IRB), which allows a device to bridge on some interfaces while a Layer 3 Bridged Virtual Interface (BVI) is presented for routing. The bridge can determine whether the packet is to be bridged or routed on the basis of the destination of the Layer 2 or Layer 3 IP address in the packet. Configured with an IP address, the BVI can manage the device even if there is no interface configured for routing.
A transparent IPS device supports a BVI for routing, so a packet that comes in on a bridged interface can be bridged or routed out of the BVI. This functionality allows a transparent IPS device and a nontransparent IPS device to be configured on the same router. The transparent IPS device operates on the bridged packets while the "normal" IPS device operates on the routed packets. For example, if you have six interfaces on your router and two of them are in a bridge group, you can simultaneously configure and run normal IPS inspection on the remaining four interfaces.
Users can also configure transparent IPS and a transparent firewall on the same device. For more information on the transparent firewall, see the document "Transparent Cisco IOS Firewall."
Cisco IOS IPS allows customers to choose between any of the following options when loading IPS signatures onto a device:
•Loading the default, built-in signatures.
•Download the signature definition file (SDF) on the router by using the Cisco Router and Security Device Manager (SDM) to have the latest available detection of security threats. Go to the following link to download the SDF:
http://www.cisco.com/cgi-bin/tablebuild.pl/ios-sigup
Note SDM automatically recommends which SDF that should be used the first time IPS in enabled on the router.
After the SDF is downloaded on to their router, the SDM can immediately begin scanning for new signatures.
An SDF has definitions for each signature it contains. After signatures are loaded and complied onto a router running Cisco IOS IPS, IPS can begin detecting the new signatures immediately. If the default, built-in signatures that are shipped with the routers are not used, then one of three different types of SDFs can be selected for download, which are pre-configured for routers with memory requirements:
•attack-drop.sdf file (which is a static file that has 83 signatures) is used for routers with less than 128MB memory.
•128MB.sdf (which has about 300 signatures) is used for routers with 128 MB or more memory.
•256MB.sdf (which has about 500 signatures) is used for routers with 256 MB or more memory.
The attack-drop.sdf, 128MB.sdf, and 256MB.sdf are available in flash on all Cisco access routers that are shipped with Cisco IOS Release 12.4 or later. One of these files can then be loaded directly from flash into the Cisco IOS IPS system. If flash is erased, the SDF file may also be erased. If a Cisco IOS image is copied to flash and there is a prompt to erase the contents of flash before copying the new image, you might risk erasing the SDF file. If the SDF file is erased, the router refers to the built-in signatures within the Cisco IOS image.
The SDF file can also be downloaded onto your router from Cisco.com through SDM. SDF files can be loaded through IDS MC 2.3, which can be launched from CSM 3.0.
Note SDF files can be used only with 12.4(9)Tx or earlier IOS Images and mainline images.
To help detect the latest vulnerabilities, Cisco provides signature updates on Cisco.com on a regular basis. Users can use VMS or SDM to download these signature updates, tune the signature parameters as necessary, and deploy the new SDF to a Cisco IOS IPS router.
Cisco IOS IPS uses SMEs to load the SDF and scan signatures. Signatures contained within the SDF are handled by a variety of SMEs. The SDF typically contains signature definitions for multiple engines. The SME typically corresponds to the protocol in which the signature occurs and looks for malicious activity in that protocol.
A packet is processed by several SMEs. Each SME scans for various conditions that can lead to a signature pattern match. When an SME scans the packets, it extracts certain values, searching for patterns within the packet through the regular expression engine. See the "Lists of Supported Signature Engines" section for a list of supported signature engines.
Note If the SDF contains a signature that requires an engine that is not supported, the engine is ignored and an error message is displayed. If a signature within a supported engine contains a parameter that is not supported, the parameter is ignored and an error message is displayed.
|
Cisco IOS Release |
|
---|---|---|
ATOMIC.L3.IP |
12.3(8)T |
— |
ATOMIC.ICMP |
12.3(8)T |
— |
ATOMIC.IPOPTIONS |
12.3(8)T |
— |
ATOMIC.TCP |
12.3(8)T |
— |
ATOMIC.UDP |
12.3(8)T |
— |
SERVICE.DNS |
12.3(8)T |
— |
SERVICE.HTTP |
12.3(8)T |
ServicePorts (applicable only in Cisco IOS Release 12.3(8)T) |
SERVICE.FTP |
12.3(8)T |
ServicePorts |
SERVICE.SMTP |
12.3(8)T |
ServicePorts |
SERVICE.RPC |
12.3(8)T |
ServicePorts, Unique, and isSweep |
STRING.ICMP |
12.3(14)T |
— |
STRING.TCP |
12.3(14)T |
— |
STRING.UDP |
12.3(14)T |
— |
1 The following parameters, which are defined in all signature engines, are currently not supported: AlarmThrottle=Summarize (all other values are supported), MaxInspectLength, MaxTTL, Protocol, ResetAfterIdle, StorageKey, and SummaryKey. |
Table 2 lists support for the 100 signatures that are available in Cisco IOS IDS prior to Cisco IOS Release 12.3(8)T. As of Cisco IOS Release 12.3(8)T, these 100 signatures are a part of the Cisco IOS IPS built-in SDF. By default, signatures are loaded from this built-in SDF. Table 2 lists support for these 100 signatures under Cisco IOS IPS.
Note Because Cisco IOS IPS counts signatures on the basis of signature-id and subsignature-id, the 100 signatures under Cisco IOS IDS are counted as 132 signatures under Cisco IOS IPS.
|
|
|
---|---|---|
1000-1006 |
7 |
ATOMIC.IPOPTIONS |
1101, 1102 |
2 |
ATOMIC.L3.IP |
1004, 1007 |
2 |
ATOMIC.L3.IP |
2000-2012, 2150 |
14 |
ATOMIC.ICMP |
2151, 2154 |
2 |
ATOMIC.L3.IP |
3038-3043 |
6 |
ATOMIC.TCP |
3100-3107 |
8 |
SERVICE.SMTP |
3153, 3154 |
2 |
SERVICE.FTP |
4050-4052, 4600 |
4 |
ATOMIC.UDP |
6100-6103 |
4 |
SERVICE.RPC |
6150-6155 |
6 |
SERVICE.RPC |
6175, 6180, 6190 |
3 |
SERVICE.RPC |
6050-6057 |
8 |
SERVICE.DNS |
6062-6063 |
2 |
SERVICE.DNS |
3215, 3229, 3223 |
3 |
SERVICE.HTTP |
5034-5035 |
2 |
SERVICE.HTTP |
5041, 5043-5045 |
4 |
SERVICE.HTTP |
5050, 5055, 5071 |
3 |
SERVICE.HTTP |
5081, 5090, 5123 |
3 |
SERVICE.HTTP |
5114, 5116-5118 |
4 |
SERVICE.HTTP |
1100 |
1 |
Not applicable. Signature is replaced by 12xx series. |
1105-1106 |
2 |
Cisco IOS IPS deprecates these signatures, which do not appear in the SDF. |
1201-1208 |
10 |
OTHER1 (fragment attack signatures) |
3050 |
2 |
OTHER1 (SYN attack signatures) |
3150-3152 |
3 |
STRING.TCP |
4100 |
1 |
STRING.UDP |
8000 |
1 |
Cisco IOS IPS deprecates these signatures, which do not appear in the SDF. |
1 The OTHER engine contains existing, hard-coded signatures. Although the standard SDF contains an entry for these signatures, the engine is not dynamically updated. If the SDF that is loaded onto the engine does not contain the signature, the signature is treated as though it has been disabled. |
Customers can choose to use Cisco IOS IPS in one of the following ways:
•Download new signatures that are posted on Cisco.com. These signatures can be obtained at the Cisco Intrusion Prevention Alert Center web page. (You must have a valid Cisco.com account to access this web page.)
•Download the attack-drop.sdf file, which contains the signatures that are identified in Table 3.
|
|
|
|
|
---|---|---|---|---|
1006:0 |
IP options-Strict Source Route |
A, D |
ATOMIC.IPOPTIONS |
Triggers on receipt of an IP datagram in which the IP option list for the datagram includes option 2 (Strict Source Routing). |
1102:0 |
Impossible IP Packet |
A, D |
ATOMIC.L3.IP |
Triggers when an IP packet arrives with source equal to destination address. This signature catches the Land Attack. |
1104:0 |
IP Localhost Source Spoof |
A, D |
ATOMIC.L3.IP |
Triggers when an IP packet with the address of 127.0.0.1, a local host IP address that should never be seen on the network, is detected. This signature can detect the Blaster attack. |
1108:0 |
IP Packet with Proto 11 |
A, D |
ATOMIC.L3.IP |
Alarms upon detecting IP traffic with the protocol set to 11. There have been known "backdoors" running on IP protocol 11. |
2154:0 |
Ping Of Death Attack |
A, D |
ATOMIC.L3.IP |
Triggers when an IP datagram is received with the protocol field in the IP header set to 1 (Internet Control Message Protocol [ICMP]), the Last Fragment bit is set. The IP offset (which represents the starting position of this fragment in the original packet and which is in 8-byte units) plus the rest of the packet is greater than the maximum size for an IP packet. |
3038:0 |
Fragmented NULL TCP Packet |
A, D |
ATOMIC.TCP |
Triggers when a single, fragmented TCP packet with none of the SYN, FIN, ACK, or RST flags set has been sent to a specific host. A reconnaissance sweep of your network may be in progress. |
3039:0 |
Fragmented Orphaned FIN packet |
A, D |
ATOMIC.TCP |
Triggers when a single, fragmented, orphan TCP FIN packet is sent to a privileged port (having a port number less than 1024) on a specific host. A reconnaissance sweep of your network may be in progress. |
3040:0 |
NULL TCP Packet |
A, D |
ATOMIC.TCP |
Triggers when a single TCP packet with none of the SYN, FIN, ACK, or RST flags set has been sent to a specific host. A reconnaissance sweep of your network may be in progress. |
3041:0 |
SYN/FIN Packet |
A, D |
ATOMIC.TCP |
Triggers when a single TCP packet with the SYN and FIN flags set is sent to a specific host. A reconnaissance sweep of your network may be in progress. The use of this type of packet indicates an attempt to conceal the sweep. |
3043:0 |
Fragmented SYN/FIN Packet |
A, D |
ATOMIC.TCP |
Triggers when a single, fragmented TCP packet with the SYN and FIN flags set is sent to a specific host. A reconnaissance sweep of your network may be in progress. The use of this type of packet indicates an attempt to conceal the sweep. |
3129:0 |
Mimail Virus C Variant File Attachment |
A, D, R |
SERVICE. SMTP |
Fires when an e-mail attachment matching the C Variant of the Mimail virus is detected. The virus sends itself to recipients as the e-mail attachment "photos.zip" that contains the file "photos.jpg.exe" and has "our private photos" in the e-mail subject line. If launched, the virus harvests e-mail addresses and possible mail servers from the infected system. |
3140:3 |
Bagle Virus Activity2 |
A, D, R |
SERVICE.HTTP |
Fires when HTTP propagation using .jpeg associated with the .Q variant is detected. |
3140:4 |
Bagle Virus Activity3 |
A, D, R |
SERVICE.HTTP |
Fires when HTTP propagation using .php associated with the .Q variant is detected. |
3300:0 |
NetBIOS OOB Data |
A, D |
ATOMIC.TCP |
Triggers when an attempt to send Out Of Band data to port 139 is detected. |
5045:0 |
WWW xterm display attack |
A, D, R |
SERVICE.HTTP |
Triggers when any cgi-bin script attempts to execute the command xterm -display. An attempt to illegally log into your system may be in progress. |
5047:0 |
WWW Server Side Include POST attack |
A, D, R |
SERVICE.HTTP |
Triggers when an attempt is made to embed a server side include (SSI) in an http POST command. An attempt to illegally access system resources may be in progress. |
5055:0 |
HTTP Basic Authentication Overflow |
A, D |
SERVICE.HTTP |
A buffer overflow can occur on vulnerable web servers if a very large username and password combination is used with basic authentication. |
5071:0 |
WWW msacds.dll Attack |
A, D, R |
SERVICE.HTTP |
An attempt has been made to execute commands or view secured files, with privileged access. Administrators are highly recommended to check the affected systems to ensure that they have not been illicitly modified. |
5081:0 |
WWW WinNT cmd.exe Access |
A, D, R |
SERVICE.HTTP |
Triggers when the use of the Windows NT cmd.exe is detected in a URL. This signature can detect the NIMDA attack. |
5114: 0 5114:1 5114:2 |
WWW IIS Unicode Attack |
A, D, R |
SERVICE.HTTP |
Triggers when an attempt to exploit the Unicode ../ directory traversal vulnerability is detected. Looks for the commonly exploited combinations that are included in publicly available exploit scripts. SubSig 2 is know to detect the NIMDA attack. |
5126:0 |
WWW IIS .ida Indexing Service Overflow |
A, D, R |
SERVICE.HTTP |
Alarms if web traffic is detected with the ISAPI extension .ida? and a data size of greater 200 characters. |
5159:0 |
phpMyAdmin Cmd Exec |
A, D, R |
SERVICE.HTTP |
Triggers when access to sql.php with the arguments goto and btnDrop=No is detected. |
5184:0 |
Apache Authentication Module ByPass |
A, D, R |
SERVICE.HTTP |
Fires upon detecting a select statement on the Authorization line of an HTTP header. |
5188:0 |
HTTP Tunneling4 SubSig 0: GotomyPC |
A, D, R |
SERVICE.HTTP |
Triggers when a computer connects to gotomyPC site. |
5188:1 |
HTTP Tunneling SubSig 1: FireThru |
A, D, R |
SERVICE.HTTP |
Triggers when an attempt to use /cgi-bin/proxy is detected. The /cgi-bin/proxy is used to tunnel connections to other ports using web ports. |
5188:2 |
HTTP Tunneling SubSig 2: HTTP Port |
A, D, R |
SERVICE.HTTP |
Triggers when a connection is made to exectech-va.com. The site runs a server, which connects to the requested resource and passes the information back to the client on web ports. |
5188:3 |
HTTP Tunneling SubSig 3: httptunnel |
A, D, R |
SERVICE.HTTP |
Triggers when /index/html? is detected on POST request. |
5245:0 |
HTTP 1.1 Chunked Encoding Transfer |
A, D, R |
SERVICE.HTTP |
Fires when HTTP 1.1 chunked encoding transfer activity is detected. This signature is known to detect the Scalper Worm. |
5326:0 |
Root.exe access |
A, D, R |
SERVICE.HTTP |
Alarms upon detecting an HTTP request for root.exe. This signature is known to detect the NIMDA attack. |
5329:0 |
Apache/mod_ssl Worm Probe |
A, D, R |
SERVICE.HTTP |
Fires when a probe by the Apache/mod_ssl worm is detected. If the worm detects a vulnerable web server, a buffer overflow attack is sent to HTTPS port (TCP 443) of the web server. The worm then attempts to propagate itself to the newly infected web server and begins scanning for new hosts to attack. |
5364:0 |
IIS WebDAV Overflow |
A, D, R |
SERVICE.HTTP |
Fires when a long HTTP request (65000+ characters) is detected with an HTTP header option "Translate:". An attack to exploit a weakness in the WebDAV component of the IIS web server may be in progress. |
5390:0 |
Swen Worm HTTP Counter Update Attempt |
A, D, R |
SERVICE.HTTP |
Triggers when an attempt to access the URL "/bin/counter.gif/link=bacillus" is detected. A system may be infected by the Swen worm trying the update a counter on a web page located on the server "ww2.fce.vutbr.cz." |
5400:0 |
Beagle.B (Bagle.B) Web Beacon |
A, D, R |
SERVICE.HTTP |
Fires when a request is made for the script 1.php or 2.php residing on the hosts "www.47df.de" or "www.strato.de," followed by the argument indicating the trojan's listening port number, p=8866. |
6055:0 6055:1 6055:2 |
DNS Inverse Query Buffer Overflow |
A, D R for subsig 1, 2 |
SERVICE.DNS |
Triggers when an IQUERY request arrives with a data section that is greater than 255 characters. |
6056:0 6056:1 6056:2 |
DNS NXT Buffer Overflow |
A, D R for subsig 1, 2 |
SERVICE.DNS |
Triggers when a Domain Name System (DNS) server response arrives with a long NXT resource where the length of the resource data is greater than 2069 bytes or the length of the TCP stream containing the NXT resource is greater than 3000 bytes. |
6057:0 6057:1 6057:2 |
DNS SIG Buffer Overflow |
A, D R for subsig 1, 2 |
SERVICE.DNS |
Triggers when a DNS server response arrives with a long SIG resource where the length of the resource data is greater than 2069 bytes or the length of the TCP stream that contains the SIG resource is greater than 3000 bytes. |
6058:0 6058:1 |
DNS SRV DoS |
A, D R for subsig 1 |
SERVICE.DNS |
Alarms when a DNS query type SRV and DNS query class IN is detected with more than ten pointer jumps in the SRV resource record. |
6059:0 6059:1 6059:2 |
DNS TSIG Overflow |
A, D R for subsig 2 |
SERVICE.DNS |
Alarms when a DNS query type TSIG is detected and the domain name is greater than 255 characters. This signature is known to detect the Lion work. |
6060:0 6060:1 6060:2 6060:3 |
DNS Complian Overflow |
A, D R for subsig 2, 3 |
SERVICE.DNS |
Alarms when a Name Server (NS) record is detected with a domain name greater than 255 characters and the IP address is 0.0.0.0, 255.255.255.255 or a multicast address of the form 224.x.x.x. |
6100:0 6100:1 |
RPC Port Registration |
A, D R for subsig 1 |
SERVICE.RPC |
Triggers when attempts are made to register new RPC services on a target host. Port registration is the method used by new services to report their presence to the portmapper and to gain access to a port. Their presence is then advertised by the portmapper. |
6101:0 6101:1 |
RPC Port Unregistration |
A, D R for subsig 1 |
SERVICE.RPC |
Triggers when attempts are made to unregister existing Remote Procedure Call (RPC) services on a target host. Port unregistration is the method used by services to report their absence to the portmapper and to remove themselves from the active port map. |
6104:0 6104:1 |
RPC Set Spoof |
A, D R for subsig 1 |
SERVICE.RPC |
Triggers when an RPC set request with a source address of 127.x.x.x is detected. |
6105:0 6105:1 |
RPC Unset Spoof |
A, D R for subsig 1 |
SERVICE.RPC |
Triggers when an RPC unset request with a source address of 127.x.x.x is detected. |
6188:0 |
statd dot dot |
A, D |
SERVICE.RPC |
Alarms upon detecting a dot dot slash (../) sequence sent to the statd RPC service. |
6189:0 6189:1 |
statd automount attack |
A, D R for subsig 1 |
SERVICE.RPC |
Alarms upon detecting a statd bounce attack on the automount process. This attack targets a vulnerability in the automount process that could be exploited only through localhost. |
6190:0 6190:1 |
statd Buffer Overflow |
A, D R for subsig 1 |
SERVICE.RPC |
Triggers when a large statd request is sent. This attack could be an attempt to overflow a buffer and gain access to system resources. |
6191:0 6191:1 |
RPC.tooltalk buffer overflow |
A, D R for subsig 1 |
SERVICE.RPC |
Fires when an attempt is made to overflow an internal buffer in the tooltalk rpc program. |
6192:0 6192:1 |
RPC mountd Buffer Overflow |
A, D R for subsig 1 |
SERVICE.RPC |
Triggers on an attempt to overflow a buffer in the RPC mountd application. This attack may result in unauthorized access to system resources. |
6193:0 6193:1 |
RPC CMSD Buffer Overflow |
A, D R for subsig 1 |
SERVICE.RPC |
Fires when an attempt is made to overflow an internal buffer in the Calendar Manager Service Daemon, rpc.cmsd. |
6194:0 6194:1 |
sadmind RPC Buffer Overflow |
A, D R for subsig 1 |
SERVICE.RPC |
Fires when a call to RPC program number 100232 procedure 1 with a UDP packet length greater than 1024 bytes is detected. |
6195:0 6195:1 |
RPC amd Buffer Overflow |
A, D R for subsig 1 |
SERVICE.RPC |
Detects the exploitation of the RPC AMD Buffer Overflow vulnerability. The trigger for this signature is an RPC call to the berkeley automounter daemons rpc program (300019) procedure 7 that has a UDP length greater than 1024 bytes or a TCP stream length greater than 1024 bytes. The TCP stream length is defined by the contents of the two bytes preceding the RPC header in a TCP packet. |
6196:0 6196:1 |
snmpXdmid Buffer Overflow |
A, D R for subsig 1 |
SERVICE.RPC |
Fires when an abnormally long call to the RPC program 100249 (snmpXdmid) and procedure 257 is detected. |
6197:0 6197:1 |
rpc yppaswdd overflow |
A, D R for subsig 0 |
SERVICE.RPC |
Fires when an overflow attempt is detected. This alarm looks for an abnormally large argument in the attempt to access yppaswdd. |
6276:0 6276:1 |
TooltalkDB overflow |
A, D R for subsig 1 |
SERVICE.RPC |
Alarms upon detecting an RPC connection to rpc program number 100083 using procedure 103 with a buffer greater than 1024. |
9200:0 |
Back Door Response (TCP 12345) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 12345, which is a known trojan port for NetBus as others. |
9201:0 |
Back Door Response (TCP 31337) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 31337, which is a known trojan port for BackFire. |
9202:0 |
Back Door Response (TCP 1524) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 1524, which is a common back door placed on machines by worms and hackers. |
9203:0 |
Back Door Response (TCP 2773) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 2773, which is a known trojan port for SubSeven. |
9204:0 |
Back Door Response (TCP 2774) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 2774, which is a known trojan port for SubSeven. |
9205:0 |
Back Door Response (TCP 20034) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 20034, which is a known trojan port for Netbus Pro. |
9206:0 |
Back Door Response (TCP 27374) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 27374, which is a known trojan port for SubSeven. |
9207:0 |
Back Door Response (TCP 1234) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 1234, which is a known trojan port for SubSeven. |
9208:0 |
Back Door Response (TCP 1999) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 1999, which is a known trojan port for SubSeven. |
9209:0 |
Back Door Response (TCP 6711) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 6711, which is a known trojan port for SubSeven. |
9210:0 |
Back Door Response (TCP 6712) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 6712, which is a known trojan port for SubSeven. |
9211:0 |
Back Door Response (TCP 6713) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 6713, which is a known trojan port for SubSeven. |
9212:0 |
Back Door Response (TCP 6776) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 6776, which is a known trojan port for SubSeven. |
9213:0 |
Back Door Response (TCP 16959) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 16959, which is a known trojan port for SubSeven. |
9214:0 |
Back Door Response (TCP 27573) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 27573, which is a known trojan port for SubSeven. |
9215:0 |
Back Door Response (TCP 23432) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 23432, which is a known trojan port for asylum. |
9216:0 |
Back Door Response (TCP 5400) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 5400, which is a known trojan port for back-construction. |
9217:0 |
Back Door Response (TCP 5401) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 5401, which is a known trojan port for back-construction. |
9218:0 |
Back Door Response (TCP 2115) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 2115, which is a known trojan port for bugs. |
9223:0 |
Back Door Response (TCP 36794) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 36794, which is a known trojan port for NetBus as well Bugbear. |
9224:0 |
Back Door Response (TCP 10168) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 10168, which is a known trojan port for lovegate. |
9225:0 |
Back Door Response (TCP 20168) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 20168, which is a known trojan port for lovegate. |
9226:0 |
Back Door Response (TCP 1092) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 1092, which is a known trojan port for lovegate. |
9227:0 |
Back Door Response (TCP 2018) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 2018, which is a known trojan port for fizzer. |
9228:0 |
Back Door Response (TCP 2019) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 2019, which is a known trojan port for fizzer. |
9229:0 |
Back Door Response (TCP 2020) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 2020, which is a known trojan port for fizzer. |
9230:0 |
Back Door Response (TCP 2021) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 2021, which is a known trojan port for fizzer. |
9231:0 |
Back Door Response (TCP 6777) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 6777, which is a known trojan port for Beagle (Bagle). |
9232:0 |
Back Door Response (TCP 5190) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 5190, which is a known trojan port for the Anig worm. |
9233:0 |
Back Door Response (TCP 3127) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 3127, which is a known trojan port for the MyDoom.A / Novarg.A virus. |
9236:0 |
Back Door Response (TCP 3128) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 3128, which is a known trojan port for the MyDoom.B / Novarg.B virus. |
9237:0 |
Back Door Response (TCP 8866) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 8866, which is a known trojan port for the Beagle.B (Bagle.B) virus. |
9238:0 |
Back Door Response (TCP 2766) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 2766, which is a known trojan port for the DeadHat worm. |
9239:0 |
Back Door Response (TCP 2745) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 2745, which is a known trojan port for the Bagle.H-J virus. |
9240:0 |
Back Door Response (TCP 2556) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 2556, which is a known trojan port for the Bagle (.M.N.O.P) virus. |
9241:0 |
Back Door Response (TCP 4751) |
A, D |
ATOMIC.TCP |
Fires upon detecting a TCP SYN/ACK packet from port 4751, which is a known trojan port for the Bagle.U virus. |
1 A = alarm, D = drop, R = reset 2 This signature requires port to application mapping (PAM) configuration through the command ip port-map http port 81. 3 This signature requires PAM configuration through the command ip port-map http port 81. 4 This signature requires PAM configuration through the command ip port-map http port 8200. |
If you want to configure transparent Cisco IOS IPS, you must configure a bridge group before loading IPS onto a device. To configure a bridge group, see the section "Configuring a Bridge Group for Transparent Cisco IOS IPS." If you do not want to configure transparent IPS, skip this task and immediately begin installing IPS onto your device as shown in the tasks below.
Before configuring Cisco IOS IPS on a router, you should determine which one of the following deployment scenarios best addresses your situation and configure the associated task, as appropriate:
•You are loading signatures onto a router through VMS IDS MC or SDM:
To use VMS IDS MC, see the documents on the VMS index.
To use SDM, see the chapter Intrusion Prevention System in the Cisco Router and Security Device Manager 2.5 User Guide.
•You are installing a new router with the latest version of Cisco IOS IPS.
To perform this task, see the section "Installing Cisco IOS IPS on a New Router."
•Your network is transitioning to Cisco IOS IPS in Cisco IOS Release 12.3(8)T or later.
To perform this task, see the section "Upgrading to the Latest Cisco IOS IPS Signature Definition File (SDF)."
•You are merging the default (built-in) Cisco IOS IPS signatures with the latest version of the Cisco IOS IPS signature detection file, "attack-drop.sdf."
To perform this task, see the section "Merging Built-In Signatures with the attack-drop.sdf File"
After you have configured Cisco IOS IPS on your router, see the following optional sections:
•Monitoring Cisco IOS IPS Signatures through Syslog Messages or SDEE
•Troubleshooting Cisco IOS IPS
Note You should configure a bridge group only if you want to configure transparent IPS.
•If a BVI is not configured, you must disable IP routing (through the no ip routing command) for the bridging operation to take effect.
•If configured, a BVI must be configured with an IP address in the same subnet.
•You must configure a BVI if more than two interfaces are placed in a bridge group.
•Bridging between VLAN trunks works only for dot1q encapsulation; Inter-Switch Link (ISL) encapsulation does not work.
1. enable
2. configure terminal
3. bridge bridge-group protocol {dec | ibm | ieee | vlan-bridge}
4. interface type number
5. bridge-group bridge-group
6. exit
7. bridge irb
8. bridge bridge-group route protocol
9. interface type number
10. ip address ip-address mask
11. no shutdown
The following example shows how to configure interfaces "ethernet0" and "ethernet1" in a bridge group. These interfaces are associated with the BVI interface "BVI1," which can be reached from any host on either of the interfaces through the IP address 10.1.1.1.
Router(config)# bridge 1 protocol ieee
Router(config)# interface ethernet0
Router(config-if)# bridge-group 1
Router(config-if)# interface ethernet1
Router(config-if)# bridge-group 1
Router(config-if)# exit
! Configure the BVI.
Router(config)# bridge irb
Router(config)# bridge 1 route ip
Router(config)# interface BVI1
Router(config-if)# ip address 10.1.1.1 255.255.255.0
Router(config-if)# no shutdown
To display the status of each bridge group, use the show bridge-group command or to display entries in the bridge table, use the show bridge command.
After you have configured the bridge group, you must configure Cisco IOS IPS as shown in one of the following Cisco IOS IPS tasks, as appropriate to your network needs.
Perform this task to install the latest Cisco IOS IPS signatures on a router for the first time.
Perform this task to install the default, built-in signatures or the SDF called "attack-drop.sdf"—but not both. If you want to merge the two signature files, you must load the default, built-in signatures as described in this task. Then, you can merge the default signatures with the attack-drop.sdf file as described in the task "Merging Built-In Signatures with the attack-drop.sdf File."
Note Installing the signatures provided in flash is the recommended method in Cisco IOS Release 12.3(8)T for IPS attack mitigation.
1. enable
2. configure terminal
3. ip ips sdf location url
4. ip ips name ips-name [list acl]
5. ip ips signature signature-id [:sub-signature-id] {delete | disable | list acl-list}
6. ip ips deny-action ips-interface
7. interface type name
8. ip ips ips-name {in | out}
9. exit
10. show ip ips configuration
Perform this task to replace the existing signatures on your router with the latest IPS signature file, attack-drop.sdf.
Note The latest IPS image reads and converts all commands that begin with the words "ip audit" to "ip ips." For example, the ip audit name command becomes the ip ips name command.
Although IPS accepts the audit keyword, it generates the ips keyword when you show the configuration. Also, if you issue the help character (?), the CLI displays the ips keyword instead of the audit keyword, and the Tab key used for command completion does not recognize the audit keyword.
1. enable
2. configure terminal
3. ip ips name ips-name
4. ip ips sdf location url
5. no ip ips location in builtin
6. ip ips fail closed
7. ip ips deny-action ips-interface
8. interface type name
9. ip ips ips-name {in | out} [list acl]
10. exit
11. show ip ips configuration
12. show ip ips signatures [detailed]
You may want to merge the built-in signatures with the attack-drop.sdf file if the built-in signatures are not providing your network with adequate protection from security threats. Perform this task to add the SDF and to change default parameters for a specific signature within the SDF or signature engine.
Before you can merge the attack-drop.sdf file with the built-in signatures, you should already have the built-in signatures loaded onto the router as described in the "Installing Cisco IOS IPS on a New Router" section.
1. enable
2. configure terminal
3. no ip ips location in builtin
4. ip ips fail closed
5. exit
6. copy [/erase] url ips-sdf
7. copy ips-sdf url
8. configure terminal
9. ip ips signature signature-id[:sub-signature-id] {delete | disable | list acl-list}
10. ip ips sdf location url
11. ip ips deny-action ips-interface
12. interface type name
13. ip ips ips-name {in | out}
14. exit
15. exit
16. show ip ips signatures [detailed]
To use SDEE, the HTTP server must be enabled (through the ip http server command). If the HTTP server is not enabled, the router cannot respond to the SDEE clients because it cannot not "see" the requests.
1. enable
2. configure terminal
3. ip ips notify sdee
4. ip sdee events events
5. ip sdee subscriptions subscriptions
6. exit
7. show ip sdee {[alerts] [all] [errors] [events] [configuration] [status] [subscriptions]}
To print out new SDEE alerts on the router console, issue the debug ip sdee command.
To clear the event buffer or SDEE subscriptions from the router (which helps with error recovery), issue the clear ip sdee command.
•Interpreting Cisco IOS IPS System Messages
•Conditions of an SME Build Failure
Sometimes an SME that is being built fails. The SME can fail because it is attempting to load a corrupted SDF file or it exceeds memory limitations of the router. If a failure occurs, Cisco IOS IPS is designed to handle it. Possible failures are as follows:
•By default, IPS is designed to "fail open," which means that if an SME does not build, all packets that are destined for that particular engine passes traffic without scanning.
•If IPS cannot load the attack-drop.sdf file onto a router, the router reverts to the previously loaded available signatures. (In most cases, the previously loaded signatures are the Cisco IOS built-in signatures.)
•If an engine build fails when you are merging the attack-drop.sdf file with the built-in signatures, IPS reverts, by default, to the previously available engine (or engines).
The default behavior for engine failure allows for packets to be passed unscanned. To prevent traffic from being passed unscanned, issue the ip ips fail closed command, which forces the router to drop all packets if an SME build fails.
Note If a signature or a signature parameter is not supported, Cisco IOS prints a syslog message, indicating that the signature or parameter is not supported.
•Loading the Default Signatures: Example
•Loading the attack-drop.sdf: Example
•Merging the attack-drop.sdf File with the Default, Built-in Signatures: Example
The following example shows the Cisco IOS IPS commands required to load the default, built-in signatures. Note that a configuration option for specifying an SDF location is not necessary; built-in signatures reside statically in Cisco IOS.
!
ip ips po max-events 100
ip ips name MYIPS
!
interface GigabitEthernet0/1
ip address 10.1.1.16 255.255.255.0
ip ips MYIPS in
duplex full
speed 100
media-type rj45
no negotiation auto
!
The following example shows the basic configuration necessary to load the attack-drop.sdf file onto a router running Cisco IOS IPS. Note that the configuration is almost the same as loading the default signatures onto a router, except for the ip ips sdf location command, which specifies the attack-drop.sdf file.
!
ip ips sdf location disk2:attack-drop.sdf
ip ips name MYIPS
!
interface GigabitEthernet0/1
ip address 10.1.1.16 255.255.255.0
ip ips MYIPS in
duplex full
speed 100
media-type rj45
no negotiation auto
!
The following example shows how to configure the router to load and merge the attack-drop.sdf file with the default signatures. After you have merged the two files, it is recommended that you copy the newly merged signatures to a separate file. The router can then be reloaded (through the reload command) or reinitalized to recognize the newly merged file (as shown the following example).
!
ip ips name MYIPS
!
interface GigabitEthernet0/1
ip address 10.1.1.16 255.255.255.0
ip ips MYIPS in
duplex full
speed 100
media-type rj45
no negotiation auto
!
!
! Merge the flash-based SDF (attack-drop.sdf) with the built-in signatures.
Router# copy disk2:attack-drop.sdf ips-sdf
! Save the newly merged signatures to a separate file.
Router# copy ips-sdf disk2:my-signatures.sdf
!
! Configure the router to use the new file, my-signatures.sdf
Router# configure terminal
Router(config)# ip ips sdf location disk2:my-signatures.sdf
! Reinitialize the IPS by removing the IPS rule set and reapplying the rule set.
Router(config-if)# interface gig 0/1
Router(config-if)# no ip ips MYIPS in
!
*Apr 8 14:05:38.243:%IPS-2-DISABLED:IPS removed from all interfaces - IPS disabled
!
Router(config-if)# ip ips MYIPS in
!
Router(config-if)# exit
|
|
---|---|
IPS and firewall commands |
|
Fragment attack support through VFR |
|
Transparent Cisco IOS Firewall documentation |
Table 5 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note Table 5 lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
|
|
|
---|---|---|
Cisco IOS Intrusion Prevention System (IPS) |
12.3(8)T |
The Cisco IOS Intrusion Prevention System (IPS) uses the following methods to protect a network from internal and external attacks and threats: •IPS signatures are dynamically updated and posted to Cisco.com on a regular basis so that customers can access signatures that help protect their network from the latest known network attacks. •A Parallel Signature Scanning Engine is used to scan for multiple patterns within a signature microengine (SME) at any given time. IPS signatures are no longer scanned on a serial basis. •Cisco IOS IPS supports both named and numbered extended access control lists (ACLs). The following sections provide information about this feature: •Information About Cisco IOS IPS •How to Configure Cisco IOS IPS on a Device The following commands were introduced by this feature: clear ip sdee, copy ips-sdf, debug ip ips, debug ip sdee, ip ips fail closed, ip ips sdf location, ip sdee events, ip sdee subscriptions, no ip ips sdf builtin, show ip sdee |
Cisco IOS Intrusion Prevention System (IPS) |
12.3(14)T |
•Supports access to more recent virus and attack signatures with the addition of three more SMEs—STRING.TCP, STRING.ICMP, and STRING.UDP. •Intelligent and local shunning is supported, which allows Cisco IOS IPS to shun offending traffic on the same router that Cisco IOS IPS is configured. •The ip ips deny-action ips-interface command was added, which allows users to choose between two available ACL filter settings for detecting offending packets. Support for the Post Office Protocol was deprecated and the following commands were removed from the Cisco IOS software: ip ips po local, ip ips po max-events, ip ips po protected, and ip ips po remote. |
Transparent Cisco IOS IPS |
12.4(2)T |
Support was added for Layer 2 transparent bridging for Cisco IOS IPS. Transparent Cisco IOS IPS eases certain network and management deployment by allowing users to "drop" a device running Cisco IOS IPS in front of their existing network without changing the statically defined IP addresses of their network-connected devices. Thus, users can allow selected devices from a subnet to traverse the IPS while access to other devices on the same subnet is denied. The following sections provide information about this feature: •Transparent Cisco IOS IPS Overview •Configuring a Bridge Group for Transparent Cisco IOS IPS No commands were introduced or modified for this feature. |