Be careful with IDS automated responses

Responses to intrusion alerts from an intrusion detection system can be passive, active or investigative.

The IDS can simply announce that there’s a problem, produce reports and let users handle the trouble. A more active response still includes human intervention, but the IDS can facilitate a range of actions such as collecting more detailed information about the intrusion or attack, changing the environment to make the attack less likely to succeed, or even (and this is not a good idea) to enable counterstrikes (hack-back) against the perceived attackers.

Automated responses are potentially powerful and therefore potentially dangerous. There’s always a danger that any automated system will be misused by people who assume that they don’t need to tune the parameters to fit their own requirements. These are the folks who install factory defaults on their IDS and firewalls without even reading the instruction manuals to verify that the defaults actually do something.

I remember that in the early days of the old NCSA’s Firewall Product Developers’ Consortium, we hammered away at the concept that default settings on security products should actually provide reasonable security if we were expected to certify the products as having value. At that time (the early 1990s), some firewall default installations resulted in a bandwidth-reduction device – the default settings for the firewall didn’t actually do very much except put an upper limit on the bandwidth of the communications channel where it was installed.

The second danger from automated responses is that they can sometimes be abused by attackers to create denial-of-service attacks. The classic example of how a well-intended security policy can easily be subverted is the automatic inactivation of accounts when there are more than a critical number of bad passwords supplied in a sequence (e.g., six bad passwords in a row). Some system managers configure their security parameters to lock the account in question automatically and require an administrator to reset the password or the account to allow access. Sounds good – online password crackers cannot possibly achieve their goals with only six (or whatever small number one wants) tries per account.

No, they may not be able to penetrate the system, but they sure can shut it down.

The attack need merely obtain (or guess at) a list of valid account names and then give each account a bad password enough times and the entire system can be locked up. And woe betide the system administrator who allows the automatic lockout to apply to the root user as well – then you can _really_ have headaches.

By the way, the same goal – slowing down automated online password cracking – can be achieved simply by introducing a modest delay (e.g., a few minutes) after the magic number of bad passwords. True, it is possible to inactivate lots of accounts by bombarding the system with fraudulent logons under such a regime, but it’s much harder to lock it up completely.

So back to IDS and automated responses: Some systems are available today that provide active response to attacks. They not only alert system administrators to attack, they actually deflect attacks before the firewalls can become overloaded. This is a good thing, but one should nonetheless monitor the activity carefully. An attacker could, for example, spoof the originating IP addresses in the flood of attack packets and thus cause the IDS to begin rejecting legitimate traffic from specific origins. This might be a minor consideration on an e-commerce site with public utilization, but it could be a disaster for a controlled trading network (an extranet) forming the basis for tightly coupled supply chain management or customer relationship management.

Again, to be sure I’m not being misunderstood (and to avoid angry messages from offended vendors): automated response tools are good – they should simply not be allowed to function unsupervised for extended periods. A human being should take action to understand what’s happening as soon as there’s an alarm from the IDS to prevent manipulation of the responses that could turn them into self-inflicted denial of service.

In the next short contribution on this subject, I’ll look at the human side of response to IDS alarms.