Section 13-3. Monitoring IDS Activity

13-3. Monitoring IDS Activity

When you configure embedded IDS sensors in your network, it is important to monitor their activity frequently. If the sensors are configured only to generate alarms, you need to see the alarms so that you can take the appropriate action. If the sensors are configured to drop or reset connections in response to an alarm, you should review the logs to learn what took place.

As well, the whole IDS process requires some tuning so that you reduce the number of false positive alarms. Watching the alarm logs helps you determine which ones are false and should be removed from the signature audit.

The following sections step through the two types of alarm collection as they are deployed and monitored.

Verifying Syslog Operation

As soon as logging is enabled on a router or firewall IDS sensor platform, you should try to ping the Syslog server address. If the ping is successful, use the show logging command to verify that messages are being sent to the Syslog server.

For example, the router in the following output has sent 496 messages to the Syslog server at 192.168.199.100:

 Router# show logging Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes,   0 overruns)     Console logging: level debugging, 566 messages logged     Monitor logging: level debugging, 0 messages logged     Buffer logging: level debugging, 511 messages logged     Logging Exception size (4096 bytes)     Count and timestamp logging messages: disabled     Trap logging: level informational, 572 message lines logged         Logging to 192.168.199.100, 496 message lines logged 

If you are using a firewall IDS sensor, you should get results similar to the following:

 Firewall# show logging Syslog logging: enabled     Facility: 20     Timestamp logging: enabled     Standby logging: disabled     Console logging: disabled     Monitor logging: disabled     Buffer logging: level debugging, 836546 messages logged     Trap logging: level informational, 2634 messages logged         Logging to outside 192.168.199.100         Logging to outside 192.168.199.200     History logging: disabled     Device ID: hostname "Firewall" 

On the Syslog server, you should now be able to see logging messages being collected from the IDS sensor. When an IDS alarm is sent, the Syslog message from a router looks something like this:

 Mar  1 00:04:54.399: %IDS-4-ICMP_FRAGMENT_SIG: Sig:2150:Fragmented ICMP Traffic -   from 128.163.55.142 to 172.16.1.1 

Router IDS alarms always have %IDS-4- at the start of the message text, and PIX alarms always begin with %PIX-4-4000nn IDS:, where nn is a two-digit number that corresponds to the Syslog message for the IDS signature. The IDS signature number always appears in the message text, too. In the preceding Syslog message example, signature ID 2150 triggers the alarm.

If you don't see any IDS messages within a short time, you might have to manually cause one to be generated. Go to a host that is outside the IDS sensor. This can be a PC or UNIX host or another router, switch, firewall, and so on. Generate a ping that targets the IDS sensor outside interface. Make sure that the ping packet size is greater than the maximum transmission unit (MTU); 10000 bytes should work fine.

On a PC command shell, the ping results should look like this:

 C:\> ping -l 10000 172.16.1.1 Pinging 172.16.1.1with 10000 bytes of data: Reply from 172.16.1.1: bytes=10000 time=1564ms TTL=247 Reply from 172.16.1.1: bytes=10000 time=1717ms TTL=247 Reply from 172.16.1.1: bytes=10000 time=1554ms TTL=247 Reply from 172.16.1.1: bytes=10000 time=1636ms TTL=247 Ping statistics for 172.16.1.1:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 1554ms, Maximum = 1717ms, Average = 1617ms C:\> 

From a Cisco router, the ping results should look like this:

 Router# ping Protocol [ip]: Target IP address: 172.16.1.1 Repeat count [5]: Datagram size [100]: 10000 Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 10000-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1492/1499/1504 ms Router# 

The goal of the manual ping is to send a large packet to the IDS sensor itself. The packet is fragmented before it reaches the sensor, because it is larger than the usual 1500-byte MTU. Then, the IDS sensor triggers signature ID 2150 when the fragmented ICMP request arrives. You should now see the alarm in your Syslog messages, verifying end-to-end IDS to Syslog server operation:

 Mar  3 14:27:52.804: %IDS-4-ICMP_FRAGMENT_SIG: Sig:2150:Fragmented ICMP Traffic -   from 169.54.55.142 to 172.16.1.1 

On a firewall sensor, the alarm would look something like this:

 400023: IDS:2150 ICMP fragment from 169.54.55.142 to 172.16.1.1 on interface   outside 400025: IDS:2154 ICMP ping of death from 169.54.55.142 to 172.16.1.1 on interface   outside 

Verifying Post Office Operation

Suppose a router is configured as an IDS sensor. It uses Post Office to communicate with a CiscoWorks VMS server, where alarms are collected and analyzed. From the VMS Security Monitor application, you can add the router sensor to the Post Office system. Figure 13-5 shows an example of the information entered to accomplish this.

Figure 13-5. Adding a Router IDS Sensor to CiscoWorks VMS

TIP

You can also add an IDS sensor, even if it doesn't support Post Office communication. For example, VMS collects IDS alarms from Cisco firewall IDS sensors using only Syslog. To do that, add the device as before, but uncheck the Uses Postoffice box. This implies that Syslog is being used.

After the IDS sensor is added, VMS tries to bring up a Post Office connection to it. You can verify the connection status by bringing up the Security Monitor application and selecting the Monitor tab and Connections. In Figure 13-6, the router IDS sensor has not yet been configured for Post Office, so the connection status is Not Connected. Figure 13-7 shows the same information after the router configuration has been completed. Notice that the connection status has changed.

Figure 13-6. Post Office Connection to a Router Sensor Is Down

Figure 13-7. Verifying an Established Post Office Connection

As soon as all the IDS sensors have been added into CiscoWorks VMS, you can see an alarm summary in the Security Monitor application, under the Monitor tab and Events. Figure 13-8 shows an example in which VMS has been populated with two types of IDS sensorsPIX Firewalls (using Syslog) and IOS routers (using Post Office). VMS has collected a total of 1253 and 1333 messages from the firewall and router sensors, respectively.

Figure 13-8. Using VMS to See a Summary of IDS Sensor Activity

In the summary window display, you can double-click an alarm type (PIX or PostOffice) to see a breakdown of all the active signatures. The signatures are shown with the sensor name that generated them, as well as more information about the type of alarm.

Figure 13-9 shows how the example has been expanded to list all the signatures that have generated alarms. Notice that a few signatures don't have signature ID numbers. For example, Route Up and Route Down! are generated as the Post Office mechanism begins communicating with the sensors. The PostOffice Init message was sent by the router IDS sensor when its Post Office connection first came up.

Figure 13-9. Viewing Active Signatures from All IDS Sensors

Finally, suppose the Security Monitor shows a list of active signature alarms, as shown in Figure 13-9. How can you find more detailed information about the signature, other than the name? In Security Monitor, you can right-click a specific signature name and select view NSDB. This brings up a Network Security Database (NSDB) window that contains complete information about the signature. Figure 13-10 shows an example, where the user has right-clicked the Excessive Rcpt Tos (SPAM) signature name in the Security Monitor window. From the NSDB window, you can see that it is signature 3106, the Mail Spam attack.

Figure 13-10. Getting More Information About a Signature

Verifying IDS Activity on a Router Sensor

You can display audit statistics on the IDS sensor itself to verify signature activity. Router IDS sensors also show information about the Post Office activity.

On a Cisco router IDS sensor, you can use the show ip audit all command to verify the IDS configuration, as in the following example. On a router IOS IPS platform, you would use the show ip ips all command:

 Router# show ip audit all Event notification through syslog is enabled Event notification through Net Director is enabled Default action(s) for info signatures is alarm Default action(s) for attack signatures is alarm Default threshold of recipients for spam signature is 250 Signature 2004 disable Signature 3106 list 9 PostOffice:HostID:4 OrgID:100 Msg dropped:0           :Curr Event Buf Size:100  Configured:100 Host ID:1, Organization ID:100, SYN pkts sent:94, ACK pkts sent:6, Heartbeat pkts sent:1346, Heartbeat ACK pkts sent:1341, Duplicate ACK pkts received:0, Retransmission:3, Queued pkts:0   ID:1 Dest:192.168.199.200:45000 Loc:192.168.199.1:45000 T:5 S:ESTAB * Audit Rule Configuration  Audit name MyIDS     info actions alarm     attack actions alarm drop reset Interface Configuration  Interface Ethernet0   Inbound IDS audit rule is MyIDS     info actions alarm     attack actions alarm drop reset   Outgoing IDS audit rule is MyIDS     info actions alarm     attack actions alarm drop reset Router# 

This router is sending IDS alarms to both Syslog and Post Office collectors. The router is identified as host ID 4 in the Post Office organization ID 100, and the Post Office collector is host ID 1 at 192.168.199.200. The Post Office connection is working, as noted by the "ESTAB" status.

To see statistics of actual signature activity, you can use the show ip audit statistics command. The IOS IPS counterpart is show ip ips statistics. If a signature has been triggered, it is listed with its ID and the number of packets it inspected. An example of the output from this command follows:

 Router# show ip audit statistics Signature audit statistics [process switch:fast switch]   signature 2001 packets audited: [189:189]   signature 2004 packets audited: [628:628]   signature 2150 packets audited: [35:35]   signature 3106 packets audited: [0:1] Interfaces configured for audit 1 Session creations since subsystem startup or last reset 15 Current session counts (estab/half-open/terminating) [0:0:0] Maxever session counts (estab/half-open/terminating) [2:3:1] Last session created 00:00:40 Last statistic reset never Host ID:1, Organization ID:100, SYN pkts sent:94, ACK pkts sent:6, Heartbeat pkts sent:1372, Heartbeat ACK pkts sent:1366, Duplicate ACK pkts received:0, Retransmission:3, Queued pkts:0 Router# 

In the output lines listing specific signatures, each one ends with two numbers enclosed in square brackets. These represent the number of packets that were audited through the "process-switching" path in the router, versus the total number of packets audited through the "fast-switching" path. Most audit signatures can be handled by inspecting only the packet headers, which can be done in the fast-switching path. Others, such as signature 3106 (Mail Spam), require an inspection on into the packet payload. This must be done by the router CPU as process switching, requiring more router resources.

Verifying IDS Activity on a Firewall Sensor

Firewall IDS sensors also keep running statistics about audit activity. You can use the following command to see a count of the number of times each signature has been triggered:

 Firewall# show ip audit count 

The resulting output shows every signature in the firewall's database, regardless of whether it has seen activity. As well, the resulting output shows a count of packets triggering the signature on each audited interface. For example, the firewall in the following output example has IDS auditing enabled on its outside interface. The outside column represents activity on that interface, and the Global column is the total activity across all interfaces.

 Firewall# show ip audit count Signature                               outside Global 1000 I Bad IP Options List              0       0 1001 I Record Packet Route              0       0 1002 I Timestamp                        0       0 1003 I Provide s,c,h,tcc                0       0 1004 I Loose Source Route               0       0 1005 I SATNET ID                        0       0 1006 I Strict Source Route              0       0 1100 A IP Fragment Attack               0       0 1102 A Impossible IP Packet             0       0 1103 A IP Teardrop                      0       0 2001 I ICMP Unreachable                 939044  939044 2002 I ICMP Source Quench               0       0 2003 I ICMP Redirect                    0       0 2005 I ICMP Time Exceed                 593     593 2006 I ICMP Parameter Problem           0       0 2007 I ICMP Time Request                0       0 2008 I ICMP Time Reply                  0       0 2009 I ICMP Info Request                0       0 2010 I ICMP Info Reply                  0       0 2011 I ICMP Address Mask Request        0       0 2012 I ICMP Address Mask Reply          0       0 2150 A Fragmented ICMP                  0       0 2151 A Large ICMP                       640     640 2154 A Ping of Death                    0       0 3040 A TCP No Flags                     0       0 3041 A TCP SYN & FIN Flags Only         0       0 3042 A TCP FIN Flag Only                0       0 3153 A FTP Improper Address             0       0 3154 A FTP Improper Port                0       0 4050 A Bomb                             0       0 4051 A Snork                            0       0 4052 A Chargen                          0       0 6050 I DNS Host Info                    0       0 6051 I DNS Zone Xfer                    0       0 6052 I DNS Zone Xfer High Port          0       0 6053 I DNS All Records                  0       0 6100 I RPC Port Registration            0       0 6101 I RPC Port Unregistration          0       0 6102 I RPC Dump                         0       0 6103 A Proxied RPC                      0       0 6150 I ypserv Portmap Request           0       0 6151 I ypbind Portmap Request           0       0 6152 I yppasswdd Portmap Request        0       0 6153 I ypupdated Portmap Request        0       0 6154 I ypxfrd Portmap Request           0       0 6155 I mountd Portmap Request           0       0 6175 I rexd Portmap Request             0       0 6180 I rexd Attempt                     0       0 6190 A statd Buffer Overflow            0       0 Firewall#