Slashdot Mirror
Intrusion Detection with Snort
What Koziol implies throughout Intrusion Detection with Snort, but never states outright, is that Snort holds an inherent advantage over closed source IDSs, in that the IDS itself can be tailored and customized for each individual deployment to a level not possible for closed source competitors. If you have had the displeasure of working with a rigid, uncustomizable, IDS you already know where this is going ...
In order for an IDS to be effective, or in some high-bandwidth cases, even usable, detailed network and business context must be applied to the IDS. In a nutshell, IDSs are not as plug-and-play as firewalls or other security applications. For example, if you know you are not running any HTTP traffic on the segment where the IDS is sniffing, you may not want your IDS to waste cycles looking for attacks on Apache. On the other hand, you may feel that the mere presence of HTTP traffic may indicate something innately suspicious, so it is of value to watch for any HTTP traffic. It all depends on what you feel are legitimate threats to the network you are attempting to protect. Snort gives you the power to "watch" for specific attacks, protocol anomalies, or other chatter that has no legitimate business running on your network. Other closed source IDSs don't, or can't, have the same flexibility. Only Snort can implement something as detailed as "Send a page to the CISO's phone if this particular subnet attacks these Apache servers with the chunked encoding exploit."
With Snort, novices can easily write attack signatures (called rules) enable or disable specific protocol decoders, and detect advanced attacks such as exploits utilizing polymorphic shellcode. Without this level of flexibility, you are likely to be flooded with alerts that are not relevant, or, even worse, miss an actual attack that causes irreparable data loss.
Like many open source applications, Snort's biggest downfall has been documentation. Who wants to write boring user manuals when he can write code, right? Well, that's all fine and dandy for Snort developers, but folks that want to actually use all of the neat features can't, unless you tell them they are there, and how to use them. Intrusion Detection with Snort bridges this gap, and offers a clear, concise, guideline that helps plan, implement and maintain Snort-based IDS.
Another oft-cited problem with Snort that Intrusion Detection with Snort addresses is the lack of Snort features that are not directly related to intrusion detection. In essence, Snort's developers have concentrated on creating the world's best application for detecting unauthorized activity, and left everything else to other applications. If you want to organize and manage the alerts generated by Snort you have to use another application (ACID). If you desire alerts via email or pager you need another tool (swatch or syslog-ng). If you want to centrally manage attack signatures for multiple Snort installations, guess what? You need another tool (IDS Policy Manager or SnortCenter). Finding, installing, and getting all of these tools to work right can be frustrating, so Koziol walks us through these issues, and in the end we have an IDS rivaling the expensive commercial solutions.
On to the nitty-gritty of the book. Essentially, this book is organized into logical three sections, even though the author did not choose to make these demarcations in print. The first section introduces us to intrusion detection in general and features of Snort. The second section is a detailed installation guide, which walks through setting up and installing the various components of a distributed Snort setup. The final section focuses on post-installation and maintenance tasks, as well as advanced topics.
In the first section, the different breeds of IDS (Host and Network) are honestly presented, Koziol acknowledging in great detail some of the major shortcomings of IDS technology. The book then moves to describing Snort in great detail in an unbiased fashion. Other books on this subject written by Snort contributors are less forthcoming with Snort's disadvantages. The inner workings of Snort (such as packet decoders and libpcap) and the largely undocumented preprocessors are described in detail, giving tons real world examples. The examples are somewhat current, and describe exploits commonly found 6-18 months ago. Although the actual exploits found in the wild may change over time, the strategies for discovering them with Snort should remain relatively constant. The book then moves into the activities required in planning for a Snort-based IDS installation. Some of this is common sense for experienced security practitioners, such as establishing an incident response plan (the "Oh shit, I've been hacked, what do I do now!?!?"), but is relevant for novices. Other topics introduced in this section are:
Sensor placement: where to place an IDS from a network design perspective for maximum benefit.
Inserting a sensor into an in place network: covers using taps, span ports, and dedicated hubs.
Specific hardware and OS considerations: basically, why a flavor of Unix is best for Snort.
Creating a unidirectional sniffing cable: allows network traffic to flow in a single direction, minimizing risk to an IDS segment.
The second section is a detailed guide to building a distributed or 3-tiered Snort IDS. Getting the three components, the sensor (where Snort is actually installed), the server (database, alert management, and reporting server), and the analyst console (secure place to access other components and store config files and scripts) up and working on Linux takes up the bulk of this section. The analyst console chapter walks through the ever-popular Analysis Console for Intrusion Databases (ACID). Attention is paid to configuring a secured setup that encrypts traffic between the various sensors, servers, and consoles. Various packages and tools are described, as well as condensing all of the Snort tiers onto one physical box. Installing and configuring on Windows is covered as well, although this choice of setup is not as thoroughly explained as the others. The third and final section picks up where most books that deal with a specific application or software package too often leave off, namely, keeping the damn thing working. A chapter is dedicated to tuning Snort, and what thresholds can be configured to maximize benefit and performance. Getting real-time alerting via email working with ancillary tools, is covered in a dedicated chapter. Developing a targeted ruleset (a set of automagically generated signatures that will only detect attacks that have the potential to be successful) using a custom shell script is described.
A very important topic in Snort administration, writing custom rules (attack signatures) gets its own chapter. The syntax for creating rules is clearly described, followed by concrete examples. The book works through writing rules by reading through raw packet captures (last year's Slapper worm is a particularly good example). This is followed by upgrading and managing rules, which is highly useful if you have a number of Snort installations to manage. Finally, Intrusion Detection with Snort closes with a chapter on advanced topics. The advanced topics chapter primarily covers the latest fad 'Intrusion Prevention.' Snort can be made into an IPS device via packet scrubbing or shunting. For packet scrubbing, the Snort Inline patch is used and the box is placed in between a trusted and untrusted network, dropping packets that match specifically created rules. Shunting is accomplished with SnortSam, which basically sends a request to a border router or firewall to block an attacking IP address for a predetermined period of time.
Overall Jack Koziol's Intrusion Detection with Snort is a viable text for learning Intrusion Detection with the worlds premier open source IDS, even if it is light on diagrams and pictures, but it still comes highly recommended from this reviewer.
You can purchase Intrusion Detection with Snort from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Sure you can get tons of online articles about security, snort, and everything else under the sun. But for security, it's nice to have a book to get some more robust information than the 2 page onliners.
--------
Free your mind.
Personal computer security is laughable these days. Run snort, use snort, and tell others to run snort, and other free security software packages out there.
Hell buy a copy of this book and lend it to fellow admins, it can only help, let me repeat it can only help.
Not trying to be a troll, but remember not everyone is "Slashdot Savvy" and "in tune" with the hipster software. This is a tried and true program that is so uber documented they're writing books about it, you can't go wrong, seriously.
Ignore the "p2p is theft" trolls, they're just uninformed
I don't care how much a company touts that it's firewall toaster is ``plug and play'' and ``really easy to configure''. This is only part of the equation. You need qualified people working on the firewalls or IDS systems to make sence of what is happening and not to allow some bone-headed ass hat in Q & A to block a root name server since ``It was hacking us on port 53''
I don't necessarily want an IDS to run around correcting or cleaning things... it's usefulness is in the fact it's a watchdog. It's light and focused, with elegance in simplicity despite capability.
So long, michael. Don't let the door hit you...
while snort is useful and cool, one has to
seriously consider the security issues if running
snort. The code has been plagued with security
issues from day one. It is practically beta code.
I know if i ran snort on x86 linux, i would
consider that my weakest link out of all
my services. i know that one heap overflow exploit
is proably circling hands right now.
funny, your security tools are the most likely
avenue of getting hacked right now.
ironic
"In order for an IDS to be effective, or in some high-bandwidth cases, even usable, detailed network and business context must be applied to the IDS. In a nutshell, IDSs are not as plug-and-play as firewalls or other security applications."
This hits the nail right on the proverbial head. So many articles in the security industry focus on "IDS failures". If you don't know your network, servers, routers, and what they should be doing, you can't implement IDS effectively.
Very important topic, Im glad this point so often missed made it into this book. Should be a good read.
You can run them on YOUR systems, just not on the cable modem.
If they insist you can't, ask them to buy your computer, THEN they can tell you what you an't run on it....
Snort and the other intrusion detection systems perform to varying degrees at monitoring corporate resources resources and alerting personnel when something is amiss, according to the rulesets they've been given. The article assumes the rulesets are known in advance: your work is to take those rulesets and implement them in Snort or your favorite IDS.
The real world isn't so simple. IT personnel can only guess at all the possible security problems with the network equipment, hardware, server software, clients, external network connections, malicious hackers and information thiefs out there -- as well those rare dishonest insiders. A more effective security implementation includes plenty of logging, and subsequent log analysis.
Logs are easy to generate for all varieties of hardware and software. Collecting and centralizing log data lets you:
Having the history lets an organization more effectively implement the "detailed network and business context" within the real-time IDS solutions.
Of course, the real problem is the $2 million for the Oracle DB to manage all that log data. And querying all that history is a bear. And the DBAs, the software developers, etc. to manage that log history. I've heard that addamark's log management system (LMS) is a good alternative. Someone told me their product replaced a DB2 cluster at one organization after a two-hour DB2 query took three minutes on an Addamark cluster. The cost savings, storage capacity, and log compression were phenomenal too.
Are there other log centralizing solutions out there you've heard of? Addamark seems to work because it's not a full-fledged traditional DB, but optimized for this log management problem -- can a traditional DB keep pace?
I don't see why you couldn't. Then again, I don't see why you couldn't also run tcpdump/ethereal/packet sniffer of your choice. These are pretty much all passive systems, so unless your ISP is hacking into your box to see what processes are running on it, they'll never know.
:)
What I'd be more concerned about, and someone else touched upon here, is that your cable ISP is running a really ancient setup. Basically, you and everyone else on your node are on effectively a flat ethernet, and all traffic that goes to you also goes to them. It's up to the ethernet card to discard packets not intended for you, which is why your ISP doesn't want you sniffing your connection - you can basically see *everything* your neighbours are doing. Note that many internet protocols use plaintext passwords (email being the most obvious), so you could do some pretty serious damage if you were so inclined. Also you can get a good idea of what porn fetishes the guy next-door has, etc.
Modern cable ISPs implement (Docsis? someone help me out here) that basically isolates your traffic from everyone else, so that you can no longer sniff them. If this is the case, and your ISP has the 'no-sniff' rule in their TOS, it's probably just left over from the bad old days.
Regardless, at the end of the day, my ISP can blow me if they think I don't have the right to sniff traffic coming to my box. *You* sent it to me, and if you don't like it, then fix it. The technology isn't exactly new. And again, it's virtually impossible to get caught, so no big whoop either way.
A word of caution though, DON'T try using anything like ettercap (is used to sniff switched networks). It is by no means passive, and will give you away pretty easily. Consider yourself warned
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.