Snort is brand new. Its author, Martin Roesch, released the first public version a few weeks ago. I have been running it on my home network for about a fortnight. I want to write about it because I think it is going to matter, and because there is almost nothing on the web about it yet.
What it does
Snort is a network intrusion detection system. It sits on a network interface, captures every packet that comes past, runs each one against a set of rules, and writes an alert when a packet matches a rule.
The rules look like this:
alert tcp any any -> any 80 (msg:"PHF probe"; content:"/cgi-bin/phf"; nocase;)In English: any TCP packet, from any address, on any port, going to anywhere on port 80, that contains the string /cgi-bin/phf (case-insensitive), is worth alerting on.
The rule language is small enough that you can read all of it in an afternoon. It is regular enough that writing your own rules is straightforward. There is already a small community of people sharing rules they have written, on the Snort mailing list.
How it relates to firewalls
A firewall makes a decision about every packet: allow or deny. It is in the path of the traffic. If it makes a wrong decision, the wrong thing happens.
An intrusion detection system, in the Snort sense, makes no decisions about traffic. It only watches. If it sees something interesting, it logs an alert.
The two are complements. The firewall is your front door — it stops as much as it can identify confidently as bad. The IDS is the camera in the hallway — it tells you what is actually getting in, and what people are trying to get in to do, including things the firewall is not configured to block.
Some people on Bugtraq are already calling for Snort to also do the blocking — to combine detection and prevention into a single tool. That is an interesting argument. The case for is obvious: if you can detect, you can deny. The case against is that detection is a probabilistic exercise, and a false positive in a tool that only logs is an annoyance, while a false positive in a tool that blocks legitimate traffic is an outage. I think the right answer for now is to keep them separate, but I expect the next decade is going to see them slowly fuse together.
How it compares to commercial IDS
There are commercial IDS products. ISS RealSecure is the famous one. They cost serious money. They are also closed-source, which means you cannot read the rules they fire on. You cannot tell, when one of them produces an alert, whether the alert reflects an actual attack pattern or a marketing decision somebody made about which patterns make the product look impressive.
Snort is the opposite of all that. The source is small. The rules are plain text. Anyone who runs it can read every rule, understand exactly what triggers it, and write more.
What I have actually seen
A fortnight is not a lot. In that time, on a small home network, Snort has alerted on:
- A handful of probes for the
/cgi-bin/phfURL, which my DTK setup had also caught. Useful confirmation that the two tools agree on what they are looking at. - Several variants of port scan, including a slow-scan attempt that dribbled SYN packets at me over an hour. The slow scan is the kind of thing an old-fashioned
netstatis unlikely to flag as anomalous, but Snort spotted the pattern. - A truly remarkable amount of misdirected traffic — reply packets to connections that were never made, ICMP messages from networks I have never touched. Most of it is probably garbage. Some of it is the reflected scan traffic of someone using me as a passive measurement target.
None of this is critical. All of it is data I would not otherwise have had.
Where this is going
My strong guess is that the next year is going to bring an explosion of rules — community-contributed and, eventually, organised into something like a public ruleset. The interesting question is whether Snort, which is currently a single-process detection tool, will scale up to monitor large enterprise networks where the packet rate is far beyond what a Pentium 75 can handle. The author is clearly thinking about that. I am going to keep watching.
In the meantime, if you have ten minutes and a Linux box on a network, I would recommend at least installing it. Even the default ruleset, against an unimportant home network, is enough to be educational.
More on this later, including some rules of my own once I have written rules I am willing to defend.