Wouldn’t life be so much more pleasant if we didn’t have to expend so much energy protecting ourselves from the malevolence of others? Locking our doors at night, taking out insurance against someone running us off the road — it’s the same in the networking world. A huge and, it must be said, lucrative industry has grown up around the fact that people will, either for commercial gain or petty vendetta, try to break into a network and cause havoc, often for no better reason than they can.

Despite our best efforts with firewalls, the mere fact that we have to let traffic through them means that sometimes the bad guys will get in. Or be in already — it’s estimated that a good three-quarters of malicious attempts on your precious network will be from someone within your organisation. Hence there is an apparent need for intrusion detection and protection systems, the idea behind them being that the majority of hacking attempts follow some pattern that can be spotted as anomalous behaviour.

Network Intrusion Detection sensors (NIDS) sit on your network copying the packets that pass them, rather than sitting in the traffic path. Which is good in that they won’t affect your live traffic if they can’t keep up with the throughput. Of course if you buy one that isn’t up to the performance you need, and it has to drop packets, then you’re likely to miss problems.

The fact that it’s not inline does have one serious implication that you need to consciously take account of. If a hacker gets into your network and launches an DoS-type attack then your NIDS should spot it, alert you, and depending on how you’ve configured it, reset the connection or completely block out the attacking traffic before there’s time for any real damage to take place. However, many of the recent big-news attacks can be initiated by just one packet. The NIDS will take a copy of that packet, and may (or may not) see a potential problem. By the time it does something about it though, that packet has already hit your server. Clichés about horses and stable doors seem appropriate here.

This isn’t necessarily a fault with NIDS — it’s just the way they work. But try telling that to the CEO when the email system grinds to a halt.

To take account of this, there is a need for host-based IDS, software agents that sit on your critical servers and monitor and react to whatever is directed at your apps and OS, protecting them where a network-based IDS might not. They alert and block just as NIDS systems do, which means that in reality you need both host-based and network IDS. It might be going a bit far to say that one’s useless without the other, but as a minimum regard them as complementary. Maybe time to rethink your budget?

One other thing. Some IDS systems allow you not only to send TCP resets to kill potentially dangerous sessions, but also have the intelligence to dynamically create access lists on routers or firewalls to permanently block that traffic altogether. Sounds great, as long as you are completely sure that it’s a hacker you’re blocking out and not a potential customer. Even computers make mistakes (in this case known as false positives) so if you’re not absolutely 100 per cent sure that you’ve configured your IDS to only identify real hacks, it’s probably best not to take this rather drastic, although certainly appealing step. There’s little point in protecting all your e-commerce servers if your customers can’t get to them.