A Comparison of Snort Books
October 28th, 2003 by Jeffrey L. Taylor in
Title: Intrusion Detection with Snort: Advanced IDS Techniques with Snort, Apache, MySQL, PHP, and ACIDAuthor: Rafeed Ur RehmanPublisher: Prentice HallISBN: 0131407333
Title: Intrusion Detection with SnortAuthor: Jack KoziolPublisher: SAMsISBN: 157870281x
One indication that an idea's time has come is when two publications on the topic arrive at the same time. Based on the two titles reviewed here, it's apparent that Snort is going mainstream. These two books plus Snort 2.0 Intrusion Detection and Snort: The Complete Guide to Intrusion Detection all have been released this year.
Rafeed Ur Rehman' Intrusion Detection with Snort: Advanced IDS Techniques with Snort, Apache, MySQL, PHP, and ACID is part of Bruce Peren's Open Source Series. It reads like a more user-friendly version of the documentation that comes with Snort or that is accessible through the Snort Web site. The level and language of the book and documentation are similar, although the books assumes less and has more material than a cursory search of the Web reveals. The book also offers the convenience of having the information all in one place, along with a table of contents and an index. Spending $39.99 on this book is a better use of my resources than spending an afternoon running down similar content on the Web, printing it, stuffing it into a binder and then figuring out how all the pieces fit together. Of course, if your major source of income is a paper route, your mileage will vary. On a scale of Snort knowledge from zero to 100, this book covers from 10 to 50.
Jack Koziol's Intrusion Detection with Snort covers 30 to 75 on the same scale. This book does not have as much installation hand-holding as does Rehman's. If you have installed several packages from source tarballs, this lack isn't an obstacle. If installing an RPM or .deb package from the command line is stretching your comfort zone, however, the Rehman book is better for you. That said, either book will get you up and running.
Koziol's book is much better at explaining the types of attacks Snort is looking for. For example, Koziol writes (NIDS stands for Network Intrusion Detection System, a hardware/software entity that watches all traffic on a network, not only to one computer):
Hackers have discovered numerous methods for hiding malicious traffic in ways an NIDS cannot detect.
One such method takes advantage of the process that occurs when a network connection exceeds the maximum allowable size for a packet. When this situation occurs, the data is split up and sent in multiple packets. This process is called fragmentation. When the host receives these fragmented packets, it must reassemble them to correctly interpret the data. Different operating systems reassemble the packets in different orders: Some start with the first packet and work forward, whereas others do the reverse. Reassembly order is insignificant if the fragments are consistent and do not overlap as expected. If the reassembly overlaps, the results differ from each other, depending on the reassembly order. Choosing the correct reassembly order to detect a fragmentation attack can be problematic for NIDSs.
This type of detail I can use.
One of the differences between these two books lies at the heart of a controversy surrounding IDSs. Out of the box, Snort does nothing to increase your security. Someone has to be looking at the alerts, they have to understand what they are seeing (false alarms are an unavoidable part of a properly functioning IDS), someone has to decide how to respond to attacks and compromises (preferably ahead of time), and Snort needs to be tuned, maintained and updated. As both books make clear, out-of-the-box Snort definitely leans towards accepting false alarms (false positives) as part of the cost of minimizing missed attacks (false negatives).
There always is a certain amount of trading off false negatives for reduced false positives in using Snort. For example, it is difficult to write signatures that do not trip on legitimate traffic. This is partly because attackers often try to hide within legitimate traffic or break up the tell-tale part of the attack with meaningless noise. This noise can be the fragmentation attacks described above, inserting comments between or in the middle of HTML or the TTL trick described below.
Another part of the problem is an area where I firmly come down on both sides of the fence (yes, it's uncomfortable). When using Snort, all the supplied rules can be enabled, allowing me to see all the garbage that washes up against my firewall. (Is an alert about an Microsoft IIS exploit a false positive if I don't run Windows?) But when all the rules are enabled, the real attacks can get lost in all the noise; the peaks of the Code Red, Nimda and MS SQL worm outbreaks saturated my logs. Alternatively, I carefully can disable rules for attacks on operating systems and servers I am not running. The Rehman book leans toward the "let me see it all and I'll sort it out" approach. The greater depth of the Koziol book is necessary to fully understand the supplied rules and to write your own rules to minimize the false positives without letting real threats go undetected.
There are two reasons to run Snort, for information (FYI) and for action (FYA). The solution is to run two instances of Snort logging to separate syslog facilities. One shows nearly everything, while the other shows only the threats to which my system may be vulnerable. Snort is configurable enough at run time to allow this; that is, the configuration file and syslog facility can be set at run-time and are not hard coded at compile time.
Configuring two Snorts is the easy part. The startup scripts for double Snorting are a hassle, because they often take care to not start a dæmon if it already is running. The startproc and killproc programs should not be used for the second instance.
The other major factor in deciding which Snort book you should get is whether you need to support Windows. Koziol covers installing Snort on Windows, and Rehman doesn't. Both authors recommend against using Windows for Snort itself because of security concerns. On the other hand, both authors like IDS Policy Manager, which runs only on Windows. IDS Policy Manager is used for managing Snort attack signature rule sets. It does not need to run on the same computer as Snort. All the pieces--Snort, MySQL, PHP and ACID--run on Windows, Linux and most Unixes. The farther the Windows machine is from the hostile environment being monitored, the more acceptable using Windows is. At the level where the IDS analyst sits, any OS with a graphical Web browser is fine.
Koziol targets the industrial-strength audience. He highly recommends a three-tiered setup: sensors (first tier) connected to the hostile environment to be monitored feeding a database server (second tier) through a separate monitoring network. The IDS analyst (third tier) connects through the monitoring network to the database server. The separate monitoring network requires an attacker to compromise the sensor before they can attack the database or the analyst workstation. Koziol does mention a single-tier setup and when to use it, basically, only in SOHO environments. The rest of the book describes three or two-tier setups, and the single-tier case is left as an exercise for the reader.
Rehman mentions the multi-tier case and gives some examples, but he basically covers the single-tier case and leaves the multi-tier case as an exercise for the reader.
Both books are well written; the language is clear, easy to read and transparent. Neither book is a good vacation read, though. After the first chapter or two, it is best to be within reach of your computer. I read the Rehman book first, and it was fine for getting all the pieces installed. I had put off installing ACID (an IDS analysis tool), because wading through the separate bits of documentation didn't seem worth the probable benefits. With this book, installation was a breeze, and I wish I had not waited so long to get ACID. ACID makes it easy to look at the Snort alerts in ways you simply don't get from watching the logs. For example, a slow scan, such as Nmap's paranoid mode, stretches a portscan out over several days. It is difficult to catch this in the syslogs, but it's easy to see with ACID.
If you need to get serious about IDS, however, you need to read Koziol. And plan to return to it to tune your system. He not only describes Snort's parameters, he gives recommended values and when you might want to adjust them further. He also explains why you might change them from the default. It is relatively obvious that ttl is setting a time to live threshold, but why would you want to change it? Koziol gives the reason: packets with low ttl values can be inserted in the middle of an attack to break up the telltale signature. The ttl expires between the sensor and the target, and the meaningless noise drops out. As a result, the target sees a different stream of packets than Snort does. Setting the ttl value to be equal or less than the number of hops between Snort and the target system lets both see the same data stream.
So which do I recommend? If you have Rehman's book, don't wait for Koziol's to arrive--install everything. Snort out of the box generally is better than nothing. When or if you decide to get serious, get a copy of Koziol's book. If you are in a Windows-only shop, skip Rehman altogether. Rehman's book is open-source licensed, so you could print it off the Web if someone else is paying for the paper and ink. Either book can get you started. Or read one of the other books, and let us know how it compares.
Special Magazine Offer -- Free Gift with Subscription
Receive a free digital copy of Linux Journal's System Administration Special Edition as well as instant online access to current and past issues. CLICK HERE for offer
Linux Journal: delivering readers the advice and inspiration they need to get the most out of their Linux systems since 1994.
Subscribe now!
The Latest
Newsletter
Tech Tip Videos
- Nov-19-09
- Nov-04-09
Recently Popular
From the Magazine
December 2009, #188
If last month's Infrastrucuture issue was too "big" for you then try on this month's Embedded issue. Find out how to use Player for programming mobile robots, build a humidity controller for your root cellar, find out how to reduce the boot time of your embedded system, and if you're new to embedded systems find out the basics that go into one. You can also read about the Beagle Board, the Mesh Potato and a spate of other interestingly named items. And along with our regular columns don't miss our new monthly column: Economy Size Geek.
Delicious
Digg
StumbleUpon
Reddit
Facebook








Re: A Comparison of Snort Books
On October 30th, 2003 Anonymous says:
NOTE: The link to purchase the book that corresponds Intrusion Detection with Snort by Jack Koziol is INCORRECT. It is for some other book that has not yet been released.
Here is the correct link to Koziol's Intrusion Detection with Snort:
http://tinyurl.com/t1ce
Comments on Snort vs. these books
On October 30th, 2003 Anonymous says:
Regarding running two installations of Snort: FYI and Alerts
Personally I think that snort should be modified or configured so that one instance tees off these two purposes. The difference is not in the capture and analysis (which are relatively resource intensive, but in the disposition of the results. Since the selection and dispatch of this data is cheap it makes sense to consolidate the expensive part.
Also I have a different approach to using Snort. Rather than searching for attack signatures (which, like virus signatures, can only detect *known* threats), I prefer to search for policy violations.
Attack signatures fall into two general categories: those that can be blocked by the firewall (packet filtering) and those that are or can be rendered innocuous patch to their recipient process. In other words, if I know Apache 1.3.27 is vulnerable to a particular attack I can run something else or I can block all web access. The "something else" might be an application layer inbound proxy which is not vulnerable to such an attack. In either case getting IDS reports about the *attempts* to exploit this vulnerability is futile. I'd love to see detections that suggest *success* of these attacks
(indications that a vulnerability was not fixed as intended or that a system reverted to a vulnerable state --- the classic case of a restored system backup with an incomplete suite of patches).
Policy violation detection is more useful. However, it cannot be canned.
If I set up a system --- perhaps a web server, I can established a well-defined policy of allowed traffic to and from that system: inbound ports 80 (and possibly 443) from anywhere, and responses thereto; a specific set of NTP peers (perhaps all internal), a specific set of ssh (and rsync over ssh) peers (the content staging servers and administrative workstations), logging and mail to a specific set of peers, MySQL or Postgres traffic to specific servers. That's it. ANY OTHER TRAFFIC *from* that box is a violation. (We ignore other traffic *to* is if that garners no response).
So, in a typical attack scenario the cracker exploits a vulnerability in one service then uses the system to fetch a rootkit. Of course a more subtle
script may use the same channel for the fetch. After the attacker has compromised the system it is typically (ab)used in some way. If they use it for portscanning or as a relay point for further attacks it should show up in the policy monitoring IDS. So the one sort of attack that can't be detected this way is one where the cracker takes control of the system and covertly leaches data back through one of the permitted channels (i.e. converts one of the existing channels into a covert channel.
(Unfortunately HTTP has become a catchall so almost any sort of traffic might be tunneled thorugh it legitimately; and HTTPS is opaque; so monitoring traffic through these is "non-trivial").
Post new comment