The remainder of this chapter focuses on Cisco router IDS capabilities and the configuration of IDS using the Cisco IOS Firewall feature set. The Cisco IOS IDS implementation is suited best for midlevel to higher-level platforms because of the overhead associated with examining packets to detect threats and attacks on perimeter routers. It also can provide a level of protection for remote access and dialup connections. There are four basic reasons for deploying the Cisco IOS Firewall IDS:
To extend security to your perimeter routers across an enterprise network, especially at branch and regional offices
To provide a cost-effective IDS solution for small- to medium-size businesses
To detect external attacks directed at the router itself where a network-based sensor, connected behind the router, cannot detect these attacks
To implement a one-box perimeter solution
The router IDS is not a full-blown IDS solution: Because it is an inline solution, it might affect the performance of the router. Therefore, you need to be careful about enabling it on a router. Also, the router supports a limited number of signatures and, therefore, should be coupled with a network-based IDS solution, such as the 4200 sensors, in medium- to large-size networks.
Whereas the Cisco network-based sensors, such as the 4200, support more than 1000 signatures, the Cisco IOS Firewall IDS feature supports only 100. Because of the limited number of signatures, the Cisco IOS IDS software typically is used at the perimeter of the network and in combination with other IDS solutions, such as dedicated hardware sensors.
For example, if you refer back to Figure 16-1, you can see that the hardware sensor sitting behind the perimeter router never sees the traffic that the perimeter router filters. With the Cisco IOS IDS software, the perimeter router at least can report a small number of attacks that are directed at the perimeter router or that the perimeter router filters; in either case, the hardware sensor behind the perimeter router would never see this traffic anyway. Even though the number of signatures is limited, the Cisco IOS IDS software looks for common attacks and threats. Table 16-2 lists the signatures supported by the Cisco IOS Firewall IDS feature set.
Bad options exist in the IP header, or the IP header is incomplete or malformed.
Option 7 in the IP header is marked (record the route of the packet).
Option 4 in the IP header is marked (timestamp information requested).
Option 2 (security) in the IP header is marked. This is obsolete.
Option 3 in the IP header is marked (loose source-routing information).
Option 8 (SATNET stream identifier) in the IP header is marked. This is obsolete.
Strict source routing is requested for the packet.
The "more fragments" flag is set to 1, or an offset is indicated in the Offset field.
A packet has an IP protocol of 134 or higher. These protocols either are undefined or are reserved and should not be used. (The IP protocol number used to be 101.)
This indicates a Land.c attack, in which the source and destination addresses are the same.
127.0.0.1 is detected in the source IP address field.
A broadcast address (255.255.255.255.) is detected in the source IP address field.
A multicast address is detected in the source IP address field.
RFC 1918 addresses are detected.
The reassembled packet is larger than the specified length or is greater than 65,535 bytes.
Any fragment (except the last) is less than 400 bytes.
The ICMP type field is set to 0 (echo reply).
The ICMP type field is set to 1 (host unreachable).
The ICMP type field is set to 4 (source quench).
The ICMP type field is set to 5 (redirect).
The ICMP type field is set to 8 (echo request).
The ICMP type field is set to 11 (time exceeded).
The ICMP type field is set to 12 (parameter problem in the packet).
The ICMP type field is set to 13 (timestamp request).
The ICMP type field is set to 14 (timestamp reply).
The ICMP type field is set to 15 (information request).
The ICMP type field is set to 16 (information reply).
The ICMP type field is set to 17 (subnet mask request).
The ICMP type field is set to 18 (subnet mask reply).
An ICMP packet has the More Fragments flag set to 1, or an offset is indicated in the header.
The length in the IP header is set to something larger than 1024 bytes.
An ICMP packet has the last fragment bit set, and the following is true: ("IP offset" * 8) + "IP data length" > 65,535). This is called the Ping of Death.
A TCP segment does not have the SYN, FIN, ACK, or RST flags set (reconnaissance sweep).
A fragmented TCP FIN packet was sent to a port less than 1024, called an orphaned FIN.
A TCP segment with no bits set is present in the flags field.
A TCP segment has both the SYN and FIN bits set.
A TCP segment has the FIN bit set but no ACK bit set.
A fragmented TCP segment has the SYN and FIN bits set.
Multiple TCP connections have been initiated but have not completed. This looks at only ports 21, 23, 25, and 80.
This looks for the mail attack against RFC-compliant SMTP servers, such as sendmail.
E-mail messages have the pipe symbol (|) in the To field.
E-mail messages have the pipe symbol (|) in the From field.
E-mail messages have the expn or vrfy commands.
E-mail messages have the wiz or debug commands.
E-mail messages have :decode@ in the e-mail header.
An e-mail message has more than 250 (default) Rcpt To lines.
A bug in Majordomo allows remote users to execute commands on the server.
The FTP site command was executed on an FTP connection.
The FTP syst command was executed on an FTP connection.
The FTP cwd ~root command was executed on an FTP connection.
In an FTP connection, a port command was executed with a different address than the requesting source.
A port number less than 1024 or greater than 65,535 was specified on an FTP connection.
Someone tried to execute a command, using a directory traversal bug, on an IIS web server (IIS DOT DOT EXECUTE attack).
Someone tried to access the win-c-sample program through a web server.
An overflow attempt against the CGI-bin count program was detected.
The UDP segment length is less than the length in the IP header.
UDP packets have a source port of 7, 19, or 135 and a destination of 135 (Snork attack).
UDP traffic was sent to port 7 or 19 (Chargen attack).
Someone tried to access the /etc/passwd file through TFTP.
A malformed syslog message was sent to UDP port 514. This is called an Cisco IOS UDP bomb.
Someone tried to run the newdsn.exe program through an HTTP server.
An attacker tried to send commands through the CGI-bin program HylaFAX Faxsurvey.
An attacker tried to execute commands through a CGI-bin script.
An attacker tried to access scripts on a ColdFusion server.
An attacker tried to execute commands through the rguest.exe or wguest.exe CGI-bin scripts associated with the Webcom.se Guestbook.
A CGI-bin script attempted to execute the xterm-display command to circumvent a UNIX WWW server.
A .htr buffer overrun attack was detected against a Windows IIS server.
An HTTP buffer overflow attempt was made using a large username/password combination.
An attacker tried to access the msacds.dll WWW Windows file to execute commands or view secured files.
An attacker tried to access the cmd.exe program on a Windows WWW server.
An attacker tried to access a FrontPage CGI script with a filename ending in 0,0.
An attacker tried to exploit the Unicode ../ directory movement in WWW IIS.
An attacker sent shell metacharacters to be executed with the privilege level in the CGI script in Endymion MailMan.
An attacker attempted to execute code that exploits a vulnerability in phpGroupWare.
An attacker sent a special HTTP/GET request to upload files to the web server (called the eWave ServletEXEC 3.0C File Upload attack).
An abnormally large HTTP GET request was sent to a web server.
Someone attempted to access HINFO DNS records on a DNS server.
A DNS zone transfer with a source port of 53 (legitimate) was detected.
A DNS zone transfer with a different source port than 53 was detected.
Someone requested all the records for a DNS server.
Someone requested the version of a DNS server.
A DNS inverse query with more than 255 characters was detected, attempting a buffer overflow.
A DNS NXT buffer overflow against a DNS server was detected.
A DNS SIG buffer overflow against a DNS server was detected.
A DNS query of type TXT was made with the string Authors.Bind.
A DNS query type 251 was detected for a zone transfer.
Someone tried to register new RPC services on a host.
Someone tried to unregister RPC services on a host.
An RPC dump request was made to a host.
A proxied RPC request was sent to the portmapper process on a host.
A request was sent to the portmapper process for the YP server daemon.
A request was sent to the portmapper process for the YP bind daemon.
A request was sent to the portmapper process for the YP password daemon.
A request was sent to the portmapper process for the YP update daemon.
A request was sent to the portmapper process for the YP transfer daemon.
A request was sent to the portmapper process for the mount daemon.
A request was sent to the portmapper process for the rexd daemon.
A call was sent to the portmapper process for the rexd daemon. This typically indicates an access attack.
A large statd request was sent, probably indicating a buffer overflow attack method.
Someone entered the string passwd during an FTP session, probably indicating that someone was trying to download the system's password file.
More than 40 signatures were added in 12.2(15)T; therefore, if you have an older Cisco IOS version, the number of signatures that the Cisco IOS Firewall feature set supports is actually less than 60. Read the Cisco IOS release notes to determine what signatures are enabled for the Cisco IOS version that you currently are running on your router.
By default, IDS is not enabled on a router that has the Cisco IOS Firewall feature set installed. Instead, you must create audit rules, which specify the signatures that the Cisco IOS should use when looking for suspicious traffic, threats, or attacks. Cisco divides the signatures into two basic categories on the Cisco IOS, based on their severity: informational and attack. You can enable one or both groups. Also, you can selectively enable or disable specific signatures, or specify that a signature be enabled or disabled for a specific host or hosts.
After you have created your audit rule, you need to activate it on the router's interface(s) in an in or out direction. After you do this, IDS is enabled. If you applied the audit rule inbound, all packets are audited entering the interface. Unlike most other features, IDS is performed before any inbound ACL is processed; this enables you to detect external threats coming into your network. If you apply an audit policy outbound on an interface, as long as traffic is permitted into the router and routed to the outbound interface, the audit policy is used. In this case, IDS examines packets before the outbound ACL, if any, is processed on the interface.
When comparing a packet or packets against the router's signatures, the Cisco IOS does it in this order:
TCP or UDP signatures (depending on the connection type)
Application layer signatures
One important thing to point out about the matching process is that, as soon as the Cisco IOS finds a match on one signature, it immediately stops looking for any other matches within the same type. However, it continues to look for matches in other modules. For example, if the Cisco IOS finds an IP signature match, it does not look for any other IP signature matches, but it continues on to ICMP. This is different from the Cisco 4200 hardware sensors, which look for all possible signature matches in all categories.
When a router with the firewall IDS enabled detects an attack, it can take one of three actions:
Generate an alarm, which, by default, is displayed on the console. This alarm also can be sent to a syslog server or to Cisco Secure IDS Director, a centralized management platform.
For TCP connections, reset them.
Drop the packet.
Cisco highly recommends that you use the reset and drop actions together.
Even though all 100 signatures are enabled by default, you selectively can disable them if the router is triggering a high number of false positives. You can even disable a signature selectively based on the device that triggered the alarm.
I previously discussed some general issues with IDS solutions. This section discusses some issues that are specific to the Cisco IOS and the IDS and its configuration. Obviously, the performance of IDS on a Cisco router depends on many things, including these:
The processor on the router.
The amount of memory on the router. For compound signatures, the CBAC allocates memory to maintain not only the state information for the connection, but also internal caching of packets.
The amount of traffic traveling through the router.
Whether the router is performing encryption.
Enabling or disabling specific signatures does not impact the performance of IDS on the router. Likewise, interface ACLs do not impact IDS performance. However, if you are using an ACL to determine what packets trigger signatures, there will be a significant impact in the performance of the router.