After deciding to implement an IDS like Snort, determining your budget, choosing a product and understanding how NIDSes (network intrusion-detection systems) work in relation to network architectures (especially
There are legitimate political, budgetary and research reasons to want to see all the "attacks" against your connection, but given the care and feeding any IDS like Snort requires, do yourself a favor and keep your IDS sensors on the inside of the firewall. We all know the Internet has a lot of evil traffic, so there's usually no need to waste the resources to prove it.
With the low capital cost of Snort (free) and the hardware to run it on (cheap) the real cost is your time and labor for implementation, configuration and ongoing monitoring. Ideally you want to have an IDS network sensor on your DMZ with all your public servers, on the LAN just inside the firewall and on your extranet if you have one, in that order. After that it depends on your environment. Consider your choke points, possible avenues of attack and your risk. Brainstorm for any possibly useful locations, prioritize them and then work down the list as resources allow. Any well-planned and well-tuned intrusion detection system will be an excellent addition to your defense-in-depth strategy. A poorly planned and noisy IDS will just be a nuisance.
SNORT INTRUSION DETECTION AND PREVENTION TECHNICAL GUIDE
Why Snort makes IDS worth the time and effort
How to identify and monitor network ports
How to handle network design with switches and segments
Where to place IDS network sensors
Finding an OS for Snort IDS sensors.
How to determine network interface cards for IDS sensors
Modifying and writing custom Snort IDS rules
How to configure Snort variables
Where to find Snort IDS rules
How to automatically update Snort rules
How to decipher the Oinkcode for Snort VRT rules
Using IDS rules to test Snort
|JP Vossen, CISSP, is a Senior Security Engineer for Counterpane Internet Security. He is involved with various open source projects including Snort, and has previously worked as an information security consultant and systems engineer.|
This was first published in May 2005