9.6 Reactive IDS

An IDS has traditionally been a passive device on the network, silently listening to traffic and providing output for analysis by the system administrator. These IDSs would support extensive alerting capabilities to alert administrators to significant threats as they occurred. Given the response time of computers compared to that of humans, however, by the time a human could realistically respond to an attack, the time for meaningful action had already passed. The best an administrator could do is examine the logs and affected systems to determine whether or not the attack was successful.

As time passed, system administrators began to realize the utility of a system that would respond to attacks for them. This is different from a firewall, in that a firewall generally has a static configuration. Packets are filtered based on address, protocols, and ports. If you wished to allow remote hosts to access the Web server, you needed to allow traffic with a destination port of 80 through the firewall. We know now, however, that there are a number of attacks that will attack the server using port 80. To protect against these attacks, we would have to filter port 80 and at the same time block all legitimate traffic to the server. Of course, there is the possibility that we could block traffic based on the source IP address if we discovered that someone was using a particular address to attack from, but this is simply reacting to a threat that we have not only discovered, but has already taken place.

It would very much be to our advantage if the IDS itself could defend against these attacks as the IDS discovered them. This would take us painfully slow humans out of the loop altogether. If someone was trying to attack our hypothetical Web server using a well-known directory traversal exploit, the IDS could send a TCP disconnect packet to the source of the attack on behalf of the affected Web server and then reconfigure the firewall so that traffic from that address is blocked. The attacker is stopped in his tracks by the IDS, and legitimate users can continue to use the network. It almost sounds too good to be true.

In some way it is too good to be true. The idea of the "reactive" IDS, while not new, has not seen wide deployment. The primary concern is that packets with spoofed IP sources can be used to perform a denial-of-service attack. If, for example, I wanted to prevent you from using a certain network resource, I could simply craft a packet that looks like an attack and make it look like it came from your computer. Voila! Your access to network resources has been limited by my actions. Imagine this scenario on a much larger scale with tens of thousands of packets and the potential for abuse is high.

Nevertheless, the reactive IDS is too good an idea to simply let die for such "minor" technical hurdles. Some of the proposed capabilities for a reactive IDS include, as mentioned above, the ability to actively reset TCP connections by sending spoofed packets of its own and to dynamically reconfigure the rules of a firewall in response to a threat in near-real-time. Other capabilities include disabling running processes on a host, locking out user accounts, and sending SNMP traps to devices.