Intrusion Detection and Prevention

Problem

You want to use the built-in Intrusion Detection software on the router to deal with deliberate attacks on your network.

Solution

There are two versions to this feature. Prior to IOS Version 12.3(8)T, it was called IDS and implemented using the ip audit set of commands:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 21 deny 192.168.100.205
Router1(config)#access-list 21 permit any
Router1(config)#ip audit notify log
Router1(config)#ip audit info action alarm drop reset
Router1(config)#ip audit attack action alarm drop reset
Router1(config)#ip audit smtp spam 10
Router1(config)#ip audit signature 1107 disable
Router1(config)#ip audit signature 2004 disable
Router1(config)#ip audit name COOKBOOK info list 21 action alarm drop reset
Router1(config)#ip audit name COOKBOOK attack list 21 action alarm drop reset
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip audit COOKBOOK in
Router1(config-if)#exit
Router1(config)#end
Router1#

In IOS Version 12.3(8)T and later, Cisco significantly updated the feature and changed its name to IPS. It is now implemented by using the ip ips set of commands:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 21 deny 192.168.100.205
Router1(config)#access-list 21 permit any
Router1(config)#ip ips name EDITION2 list 21
Router1(config)#ip ips signature 4050 disable
Router1(config)#ip ips fail closed
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip ips EDITION2 in
Router1(config-if)#exit
Router1(config)#end
Router1#

 

Discussion

Cisco's Intrusion Detection System (IDS) was significantly enhanced from IOS Version 12.3 to 12.4, leading to a name change to Intrusion Prevention System (IPS). Both features are similar in that they work based on a set of pre-built "signatures," which describe different kinds of known deliberate intrusion attempts. As we indicated in the Introduction to this chapter, Cisco divides these signatures into several different categories. In terms of the signature implementation, Atomic signatures describe single-packet attacks, while Compound signatures cover several packets. And functionally, Cisco divides the signatures into Info signatures related to attempts to gather information about your network, while Attack signatures identify attempts to either gain access or to deny service to your network.

Both the IDS and IPS versions of this feature center around the ip audit set of commands. And both offer three possible actions in response to a detected threat:

 

Alarm

Sends a notification to your network management system. There are a few different options available for doing this. Alarms can be sent by Syslog. Alternatively, prior to IOS Version 12.3(14)T, you could send alarms using Post Office Protocol (POP). However, this option has since been deprecated and we do not recommend using it, even if you are still running an IOS version that supports it.

 

Drop

Instructs the router to simply drop any offending packets. This response is only appropriate for certain types of attacks, particularly those that use nonsession-based protocols such as UDP.

 

Reset

When you configure a reset a session in response to matching a particular signature, it forwards the packet on to the destination, but with the TCP RST flag set to force the end device to immediately drop the session.

It is important to note that you can (and probably should) apply all three of these options to most rules. This way you will always receive notification that the system has detected a problem, and the router will always attempt to deal with the problem in the most effective way: resetting the session if possible, and dropping the packet if there is no session to reset.

Intrusion detection

The first example shows how to enable IDS in an older router. You can apply the ip audit command either inbound or outbound to an interface. In general, it is best to apply it inbound to the first interface at the edge of the network, because this is where you expect to receive attacks from. Applying a rule outbound to an interface is useful, however, in situations when it is possible that the hacker is coordinating the attack via two or more points of entry.

First you need to define your IDS rules with the ip audit name command. The minimal version of this command just creates a named rule and assigns it to either info or attack type signatures:

Router1(config)#ip audit name COOKBOOK info 

You can then assign this rule to an interface as follows:

Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip audit COOKBOOK in

The example in the Solution section is somewhat more complicated, however. When we created the audit rule in the example, we did three important things:

Router1(config)#access-list 21 deny 192.168.100.205
Router1(config)#access-list 21 permit any
Router1(config)#ip audit name COOKBOOK info list 21 action alarm drop reset
Router1(config)#ip audit name COOKBOOK attack list 21 action alarm drop reset

First, this rule includes both info and attack type signatures. This is because we want to give this router the best possible protection that we can. Second, we have set the action for both types of signatures as a combination of all three possible actions, as we recommended earlier. Third, we have created an access-list that exempts one device from being included in any IDS tests. This option always uses a Standard ACL. Any addresses that are permitted by such an access-list are subjected to the audit rule. Packets with a source addresses that are denied by the access-list are excluded from any of the IDS tests.

We have specified that the notification method send alarms to the Syslog server using the ip audit notify command:

Router1(config)#ip audit notify log

Note that the Syslog server that will actually receive these messages is defined using the logging command. Please refer to Chapter 18 for more information about configuring Syslog.

Next we modified the default behavior for both info and attack signatures using the action keyword:

Router1(config)#ip audit info action alarm drop reset
Router1(config)#ip audit attack action alarm drop reset

In both cases, the default is to simply send an alarm when a packet or set of packets matches a signature. Recall that we also specified all three of these options on the ip audit name command, so they aren't technically required here as well. However, it is useful to redefine the default behavior in case you have several different rules that you want to apply to different interfaces.

The ip audit smtp spam command is actually not very useful, but we've set it anyway:

Router1(config)#ip audit smtp spam 10

The IDS feature includes a very primitive anti-spam feature. This particular command sets a parameter for this feature, defining the maximum allowed number of recipients for a single email message. The default value is 250. We have set a more reasonable maximum of 10. However, this is not a very meaningful way of categorizing spam in the first place. A more thorough spam filtering system is available with the CSC-SSM module on the ASA5500 series devices.

And, finally, we have disabled two of the rules, because they interfered with the functioning of the network:

Router1(config)#ip audit signature 1107 disable
Router1(config)#ip audit signature 2004 disable

Before we disabled the first of these rules we were getting the following messages:

Nov 12 00:06:16.193: %IDS-4-IP_RFC_1918_SIG: Sig:1107:IP RFC 1918 Address Seen -
 from 192.168.100.1 to 224.0.0.10

The observant reader will note that the multicast address listed here, 224.0.0.10, is the standard EIGRP multicast address. Because we are using an RFC 1918 address on this interface, this rule is rejecting EIGRP packets from the neighboring routers. Clearly this is not the desired behavior, so we disabled the rule specified in the log message.

This allowed EIGRP to work properly, but then we started to commonly see a different log message:

Nov 12 00:08:53.932: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.100.1 to 192.168.99.1

This message says that a device has been prevented from sending ICMP Echo Request packets across the interface. These are, of course, normal PING packets, which we require for network management reasons. This is why we have disabled this rule as well.

You should carefully examine your logs after implementing this feature, disabling any rules that are not relevant to your particular network. But you should carefully consider each message. For example, we also found this message in our router's IDS log:

Nov 12 00:14:19.310: %IDS-4-UDP_TFTP_PASSWD_SIG: Sig:4100:Tftp Passwd File - from 192.168.100.205 to 192.168.99.1

This indicates that somebody has attempted to use the TFTP protocol to download a Unix-style password file from the host at 192.168.99.1. This is not an acceptable thing to do, so we should pay a visit to the device with address 192.168.100.205 as soon as possible.

Intrusion prevention

The second example in the Solution section of this recipe shows how to configure the Intrusion Prevention feature in a router running IOS Version 12.3(8)T or higher. This new version of the feature works in a very similar way to the old one. First you must create a named rule:

Router1(config)#access-list 21 deny 192.168.100.205
Router1(config)#access-list 21 permit any
Router1(config)#ip ips name EDITION2 list 21

Here we have created a new rule called EDITION2 and applied the same access-list to it as we discussed earlier, so that any packets from the IP address 192.168.100.205 are excluded from consideration in any IPS rules.

You apply this rule to an interface in the same way also:

Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip ips EDITION2 in

When we applied this rule, we started seeing the following message in the log:

000147: Sep 12 21:01:11.906 EDT: %IPS-4-SIGNATURE: Sig:4050 Subsig:0 Sev:3 UDP Bomb [172.25.1.1:123 -> 10.1.1.3:123]
000148: Sep 12 21:01:12.178 EDT: %IPS-4-SIGNATURE: Sig:4050 Subsig:0 Sev:3 UDP Bomb [172.25.1.1:123 -> 172.25.1.101:123]

On closer investigation, it was determined that this message was a false alarm, so we have disabled the rule:

Router1(config)#ip ips signature 4050 disable

Up until here, the configuration of the IPS feature looks exactly the same as that for the older IDS feature. However, the ip ips signature command includes some other extremely useful options. For example, we may not have wanted to fully actually disable this rule, but rather exclude certain IP addresses from consideration just by this one rule:

Router1(config)#access-list 22 deny 172.25.1.1
Router1(config)#access-list 22 permit any
Router1(config)#ip ips signature 4050 list 22

We then continued to see this message, which shows that the rule is still working:

000265: Sep 12 21:41:35.630 EDT: %IPS-4-SIGNATURE: Sig:4050 Subsig:0 Sev:3 UDP Bomb [172.25.1.53:138 -> 172.25.1.255:138]

This is a much more flexible approach to the problem of false alarms.

Another great improvement in the new feature is the ability to specify what happens if the IPS engine is unable to process a packet. By default, the router will simply pass the packets normally. If you prefer, though, you can specify that the router should reject all packets if IPS stops working for any reason:

Router1(config)#ip ips fail closed

This is particularly relevant if the processing is done by a separate hardware module, such as the NM-CIDS modules, which are designed for use with 2600, 2800, 3600, 3700, and 3800 series routers. If this module suffers a failure of some kind, the default behavior is to simply pass all packets normally. In a high-security environment, however, you may prefer to disable all traffic when this happens. This is a tradeoff, of course, as losing all connectivity may be worse than losing the IPS feature.

You can see a useful summary of the current IPS configuration with the show ips configuration command:

Router1#show ip ips configuration
Configured SDF Locations: none
Builtin signatures are enabled and loaded
Last successful SDF load time: 20:54:51 EDT Sep 12 2006
IPS fail closed is enabled
Fastpath ips is enabled
Quick run mode is enabled
Event notification through syslog is enabled
Event notification through SDEE is disabled
Total Active Signatures: 132
Total Inactive Signatures: 0
Signature 4050:0 list 22
Signature 1107:0 disable
IPS Rule Configuration
 IPS name EDITION2
 acl list 21
Interface Configuration
 Interface FastEthernet0/0
 Inbound IPS rule is EDITION2
 acl list 21
 Outgoing IPS rule is not set
Router1#

Another useful command is show ip ips statistics, which shows information on the IPS feature:

Router1#show ip ips statistics
Signature statistics [process switch:fast switch]
 signature 4050:0 packets checked: [0:85]
Interfaces configured for ips 1
Session creations since subsystem startup or last reset 0
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [0:0:0]
Last session created never
Last statistic reset never

Router1#

This output shows, for example, that Signature number 4050, sub-rule 0 has checked 85 packets by using fast switching, and none using process switching. This indicates that this rule is not only being used, but is using the most efficient packet switching method.

See Also

Chapter 18