Snort is an open source package that provides a range of network monitoring functions, from basic packet sniffing up to rules-based IPS/IDS-style functionality. It was originally developed for Unix-style machines, though it has also been ported to run on the Windows family.
Anyone who’s used open-source software over the years – particularly on Unix/Linux – will be used to software packages whose installers don’t do everything for you, and which is configured by hand-crafting text files rather than via some pretty GUI. In a Unix/Linux world the key things that Snort relies on are generally preinstalled with the OS – low-level packet sniffer drivers, for instance, and an on-board firewall package that Snort can talk to in order to enforce IDS rules in what the makers term "in-line mode."
On Windows you’ll have to do some work by hand (notably the installation of WinPcap, an open source packet-level monitoring service), and although most of the functionality is there and it’ll be able to monitor traffic and generate alerts, it won’t be able to actually force packets to be dropped since it can’t interface to the Windows firewall. To be honest you might as well just run up a Linux box and be done with it – with modern distributions that’s dead easy anyway.
In the documentation directory is a collection of useful text files and a couple of PDFs describing how to get everything running and test that it’s working. Again, the Unix heritage shows – Windows does get a mention, and a specific "How to get going" file, but the docs fit the Unix world more comprehensively.
On to the product, then. In its basic "sniffer" mode, it simply shows you what’s happening on the console screen. You can switch it to “packet logger” mode simply by giving it the name of a directory to write its results to; log files are saved in "tcpdump" format – a binary form that can be loaded into packet analysis tools (we use Ethereal, as it’s free and excellent) – and if you’re feeling adventurous and you can do a bit of Unix socket programming (not too hard – it was second-year-coursework level when I was at uni). Snort can also punt information at a Unix domain socket.
The sniffer and packet logger modes are both passive – they watch what’s going on, but don’t do anything. You can, however, run Snort in-line in the network as an IDS system, providing it with rules and letting it analyse traffic and warn you that something is up via alerts or logs. In a relatively slow network (eg if you have an ADSL link running at half a meg) you can let Snort decode into a human-readable ASCII form the packets you’ve asked it to log for you or alert you to. If you want to be sure it’ll keep up with a fast LAN, though, you can tell it to log in a binary format (i.e. without spending CPU time decoding everything) and then point a binary dump decoder at the resulting file.
The behaviour of Snort in IDS mode is defined by rules that you set – and as with the rest of the configuration process, you set these up by bashing rules in text form into the config file. There’s a bit of a learning curve, but the rule format isn’t all that bad once you’ve got the hang of it.
Step one is to define "ruletypes." These basically say things like: "For activity that my rules call 'suspicious', log to this file” or “For major problems, log to this file and trigger this alert.” It’s basically a shorthand that you can refer to later when telling the system how to behave when a given rule triggers. Once you’ve dealt with your ruletypes you can then define the individual rules, of which there are eight types: the five you get in all installations are "alert", "log", "pass" (which actually means "take no action" but which you could use for turning off rules without deleting them completely), "activate" (turn on a rule that wasn’t previously enabled) and "dynamic" (sit and wait until an “activate” rule turns me on).
The final three rules are for killing connections, and are only usable on Unix/Linux systems with the IPTables packet firewall installed: "drop" (log the packet but don’t pass it), "reject" (log the packet and actively send a tear-down to the source), and "sdrop" (silent drop - like "drop", but without logging).
In basic form the comparisons you can enable in the rules resemble the kind of stuff you’d find in a traditional firewall – matching IP addresses/ranges and port numbers of sources and destinations. You can, however, do far more: as well as matching on the content of the packets themselves, you can also do sneaky things like "If this DoS-spotting rule triggers, capture the next 250 packets from that source to that destination so I can look at them later." As you’d expect you can throttle the verbosity of alerts by setting it to (say) restrict a particular alert to one in each 30 second period – there’s nothing worse than an IDS that keeps stuffing you up with alerts that you have to fight your way through in order to fix the problem.
In addition to the primary rulesets, there are a couple of concepts thrown in that allow further customisation of Snort’s behaviour. One is a set of pre-processor modules, of which you get a load thrown in with the distribution. These extend the system from a packet filter (albeit one on serious steroids) into one that can do application-specific monitoring – so there’s an SMTP pre-processor that lets you enforce rules specific to SMTP email, an SSH one that understands many of the security exploits specific to the secure shell protocol, and so on. The second, related concept is a "dynamic module:" you can develop your own modules according to the API, drop it in the appropriate directory, and tell Snort to call that module when it needs to – so if there isn’t a pre-processor entity that fits something you want to do, you can consider making your own.
If you want an IDS package that’s pretty, graphical and idiot-proof, Snort isn’t for you. But if you want something that’s surprisingly powerful and costs nothing, and you don’t mind spending a few hours figuring out how to write rules and chant the right incantations on a Linux command line, go and download Snort now.
Don’t expect to get a full-blown system up and running in half an hour – zero price doesn’t mean zero TCO. But do think seriously about using it, because you’ll probably be surprised how quickly you get used to hacking the text-based config files and designing rules.