Why You Should Know How to Do It Yourself

The Snort rules are updated frequently and it is tempting to rely on them entirely. To a large extent, this is a good idea. But it is a mistake to rely on these externally defined rules to the exclusion of understanding the construction and purpose of the Snort rules language.

Why? First, there is the basic issue of trust. How do you know that the person or persons constructing those rules are reliable, capable, and trustworthy? I'm not for a moment suggesting they are not, but you are trusting your network to them. If your network is like mine, you have your personal data, your personal and business financial data, work in progress for clients , and the odd manuscript or two on it. Now ask yourself again if you trust rulesets from someone you have never met who has intentions unknown to you.

To borrow an adage from Cold War arms control negotiations, "Trust but verify." You should review the rulesets you use so that, at a minimum, you understand what the rules are doing so that you know something about what an alert actually means when you get one. Also, you should be comfortable "tuning" the rules to your own needs. You might want to send certain alerts to syslogd with a fixed prefix you can use to trigger a Perl script that sends you a page message, for example.

Second, the sad but simple truth is that using an intrusion-detection system you don't understand is little better than having no such system. In some ways it is worse , because you now have a false sense of security. You assume that the absence of alerts means no attempts are being made and your system is secure. This is the reason we presented Tripwire first. To borrow from the Cold War again (and this is an apt metaphor, because it is fair to say that crackers and defenders are engaged in an arms race of attack versus defense tools), you need "defense in depth."

Snort is an extremely effective part of your network defense, but it can be much more effective when used as part of a system of defense. I recommend a minimum five-part defense:

1. Snort on the outside, set to alert only on extremes.

2. A properly cond firewall; at minimum a transparent outbound masquerade with no back channels. Ideally explicit rules set for outbound traffic as well as inbound.

3. Snort set to alert on practically everything on the inside network.

4. Tripwire on all hosts to monitor for changes on host file systems.

5. Proper ownership/permissions/setuid settings on all files, checked periodically on all hosts.

That seems like a simple list, but the devil is in the details. I recommend reading Practical Unix and Internet Security , by Garfinkle and Spafford, particularly Part 5, to learn some of the intricacies involved.