Snort is quickly becoming the Linux of the NIDS scene, and for good reason: It's a powerful, CLI-based tool that appeals to open-source and network-security geeks alike. Development started in 1999, when Marty Roesch first released his brainchild, and growth has continued at an impressive pace ever since. With the launch of Sourcefire, a commercial entity supporting the engine and developing a more robust back-end framework, it will be interesting to see how Snort evolves.
Snort started as a simple "packet grepper," looking for telltale signs of attacks (via signatures) in packet pay-loads. However, plug-ins are now available to allow for more advanced detection techniques, including IP defragmentation, TCP stream reassembly (still labeled beta, this caused Snort to crash when we had it flipped on) and HTTP preprocessors.
It's important to decide how to view the data that Snort spits out. The logging option you choose -- fast or full -- will determine how much data Snort will dump. Fast is nice if you're dumping to a remote syslog server where you have automated alert scripts set up. Full will give you an amazingly useful amount of information about the offending packets, for advanced security administrators.
Recording the actual packets is as easy as flipping a flag ("-b") in the Snort command line. Another extremely useful feature, but one that chews up CPU and disk resources, is the "Dump application layer data" ("-d"), which decodes the packets and presents them in hexadecimal and ASCII formats, often giving technical administrators insight into what is happening. Dragon, Cisco Secure IDS and Snort were best at grabbing packet data.
Text-based alerting is great for scripting, but what if you need to present large amounts of data or your 24x7 security admins are not all hardcore networking gurus? A number of GUI-based front ends can help. We choose to deploy SnortSnarf, written by the folks at Silicon Defense and included in the Snort distribution. SnortSnarf generates HTML pages with intuitive links to the data, including the actual packet data (if you have it turned on), as well as various "whois" and DNS lookups (see www.silicondefense.com/snortsnarf/).
Another powerful GUI being deployed is ACID, a visually impressive PHP-based application that uses a MySQL back-end database. Be prepared to do some work to get this up and running, however. You'll have to have all your ducks in a row -- Apache, PHP, MySQL, Snort -- and even then you'll be reaching for the readme files.
Snort performed well during our testing. It caught the majority of the attacks that we threw at it, and the full-packet logging made the generic "X86 NO-OP" alerts useful. By looking at the packet decodes we were able to quickly distinguish between attacks and benign traffic. For example, Macromedia Flash data can produce enough "NO-OPs" to trigger the generic signatures. Sifting through decodes let us efficiently examine the traffic, something we couldn't do using products like NetProwler or RealSecure.
Snort's signature coverage isn't as broad as that of Enterasys' Dragon, but it's certainly more complete than many rivals'. Several different signature distributions are available. Default signature sets are available with the standard Snort distribution, signatures are also available at the Whitehats site via the arachNIDS signature database. For each signature, Max Vision and other contributors provide details of the attack, sample packet traces and links to the CVE (Common Vulnerability and Exposures) database. We found these resources incredibly useful.
While Snort doesn't have any licensing fees, no IDS implementation is going to be free. Snort is a relatively raw tool, and it will take some time to deploy a complete system that alerts, logs and archives data per your organization's requirements. Also, finding competent Linux/Unix administrators is not always as easy as finding their Windows counterparts. Complicating matters, some organizations are still not receptive toward open-source software, however foolish the open-source taboo might be. In short, if your organization is not running Apache Web servers, Squid HTTP proxies, Linux file servers or other successful open-source applications, getting a Snort implementation off the ground will be challenging. However, just as Linux has evolved, Snort is bound to, as well.
Snort 1.7 (open source). Available: Now. www.snort.org
Internet Security Systems RealSecure 5.5
ISS is one of the market leaders on the IDS front and for good reason: It's been working on IDS technology for some time. RealSecure is one of the few products to contain both strong HIDS and NIDS components. Combined with a unified management console, OPSEC (Open Platform for Security) compliance, express update mechanisms and a healthy signature set, RealSecure is a great option for small to midsize organizations. Its ease of use makes it a no-brainer for Windows-based environments, and it is easy to deploy and maintain. On the enterprise front, however, RealSecure has some problems.
For starters, on Windows remote management of RealSecure (like any Windows-based sensor) is tricky. However, unlike products such as NetProwler, RealSecure can run on Sun Solaris. While most of the configuration changes are done through the console, we ran into a few problems with one of the MUs (Micro Updates). We had one sensor start complaining about a DLL after an update. Everything appeared to be working -- we were getting alerts -- but we were told that the signatures in the MU may or may not be active. The only solution, according to ISS, was to reinstall the sensor.
The link between the sensor and the console is also somewhat fragile and tended to break when stressed. Alert information is stored in the sensor's log file until the contents of this file are pushed up to the console. If this log file (on the sensor) becomes corrupted, the console and sensor will often no longer talk to each other. This happened several times during our testing. Cryptic error messages hinder quick fixing of such problems. Fortunately, some of these issues appear to be fixed in RealSecure 6.0, which we received at the end of our testing cycle.
RealSecure's console is a blessing and a curse. The automatically updated events give you an idea of what is going on with your network and let you see which sigs are probably "falsing." However, once the events time out, they are essentially gone. Yes, most events will be logged to the back-end database, but they are then accessible only via weak reporting tools. Reports are a pain to generate, are difficult to customize (you'll need Crystal Reports) and don't present the data in a very usable form. It would be nice if a security admin could dig into the database through an interactive tool of some sort.
Getting useful forensic data after a serious attack proved equally challenging. Some unsupported workarounds are detailed on the RealSecure Technical Center page on ISS' site (see www.iss.net/customer_care/resource_center/realsecure_tech_center/tips_tricks/index.php), such as setting up a "netmon" box to record the data and integrate with RealSecure, but it's a kludgy solution. We believe that robust packet-logging abilities should be built into any enterprise-class NIDS solution.
Logging to a separate database instead of the built-in Microsoft Access database is possible via ODBC. Logging to a SQL-based database lets you build your own tools to extract data. However, you'll want to investigate the data RealSecure is going to record--it might not be everything you require.
Unfortunately, the Log Packet option available for each signature does not record the packet in a way that can be retrieved and viewed with standard tools, such as tcpdump, or even with tools provided in RealSecure. What this option does allow is "session playback" for protocols that RealSecure knows about and for which it has proper decodes. Unfortunately, those are limited to well-defined protocols, such as telnet and FTP. This is more of a gee-whiz feature, with limited value, since you are not likely going to find many attacks taking place over these protocols.
Finally, RealSecure's alert manager is OK with a few alerts, painful with a larger number (hundreds) and virtually useless with many (thousands). Sorting data the way you can in CSPM is a pipe dream right now with RealSecure; brace yourself for a lot of clicking. In addition, make sure to sign up for the RealSecure mailing list, since new attacks (like the IIS 5 ISAPI printer vulnerability) aren't integrated into update files quickly, and you'll have to create new sigs by hand.
If you're looking for an easy-to-deploy IDS with decent signature coverage, RealSecure may be just the ticket. Just keep in mind you'll be sacrificing some depth in forensics, trending and viewing data, and RealSecure's ability to scale in the enterprise while remaining usable is questionable.
Version 6.0 of RealSecure addresses most of the issues that we found ourselves struggling with in version 5.5. We were able to evaluate 6.0 only in the lab and thus couldn't seriously bang on it. The database corruption issues should be addressed by the new SQL back-end database, however. Also corrected is the ephemeral nature of the alerts, which scrolled off the console; a new middle-tier component called Event Collector can log all alert data from multiple sensors to a robust database, against which reports can be run.
RealSecure 5.5. Available: Now. Internet Security Systems, (404) 236-2600; fax (404) 236-2626. www.iss.net
REPORTS
ANALYTICS
Follow 
