Snort as an IPS

Someone in the local Snort user group asked me,

"Dear James,

Was wondering if you know of anyone who has used snort for line-rate
deep inspection on networks up to about 400 mb data flow.
And if so on what hardware. "

I replied,

"I'll ask around.

I don't have direct experience with this, but I'll share my thoughts anyway.

I don't use it inline for a couple of reasons.

1) separation of policy audit from policy enforcement (conceptual thing)
2) complexity in a firewall is a bad thing imho (luddite thing) There's a history of vulnerabilities in anything that does protocol decodes, because they are tricky.
3) fail-open and default pass less desirable than default block on my stateful firewall

There are certainly reasonable claims to be made in favor.

I believe Sourcefire claims they comfortably handle gigabit rates for their branded Snort appliances. I'm sure you can't use a lot of any -> any rules, though. Some tuning required.

If I were to build such a box, I'd get a Xeon 5100 series, with a 1333 mhz bus, and intel I/OAT compatible cards/chipset to offload some of the tcp/ip overhead. I don't *think* the disk is critical so you could go with a SATA2 drive.

http://www.siliconmechanics.com/i5917/Xeon-Server.php

Sourcefire uses commodity hardware, and thinks they will be able to use Moore's Law to surpass ASIC-based custom hardware. The basic proposition is, can Tippingpoint do R&D and manufacturing better than Intel et. al. ? I talked to a smart booth weasel for Tippingpoint at an expo (the only IPS weasel who knew what he was talking about in a field of 4-5 vendors) who thought they could, with FPGAs.

Since you have to have a higher confidence level in the blocking rules than in alerting rules, you might want to run a separate IDS. You can have a larger ruleset without DoS'ing yourself on a device that simply observes. Any problems it has don't affect the net."

I don't know if I was clear but he can always ask. Some points for clarification: IPS doesn't just watch the bad packets go by. It blocks what it identifies. The problem is, that identification must be more certain than an i.d. that simply generates an alert. Another problem is that behavioral/heuristic analysis will unpredictably alter network performance. The Visible Ops/ITPI folks would scream. Apart from network neat-freaks (to whose ranks I aspire to join), there's a real issue with allowing stimulous of an attacker's choice to alter the behavior of your network defenses. And, inevitably, some fraction of what an IPS blocks is going to be legitimate traffic.

The point about the additional complexity of an IPS is that a dumb, robust stateful firewall is going to be reliable. An IPS does more, has more code, more functions, more flaws. This is mostly, but not entirely, theoretical. Snort has had issues. BlackIce has had issues. I imagine the others have, as well. Ethereal (now Wireshark) and tcpdump have had issues, and these tools do things that an IPS must do. Protocol decodes must either attract really stupid programmers, or be really hard to do. I'm guessing the latter.

The point about the default block is that usually an IPS passes whatever it doesn't recognize as bad. Marcus Ranum explains why "Enumerating Badness" is a broken model. You want your firewall to permit only specific things, and block everything else. So an IPS must not be your only line of defense.