 |
|
|
Snort 1.8.1� Snort is a freeware Network Intrusion Detection System which was written for Unix/Linux systems and later ported to the Windows platform. For this report, we have tested the latest release for non-Windows platforms (version 1.8.1). Snort is described as a cross-platform, lightweight network intrusion detection tool that can be deployed to monitor small TCP/IP networks and detect a wide variety of suspicious network traffic as well as outright attacks. There is nothing lightweight about its flexibility and performance, however. It has a wealth of development effort behind it, in terms of both source code and attack signature production, and more often than not has the very latest attack signatures available for it before they are available for commercial IDS products. Snort is available under the GNU General Public License, and is free for use in any environment, making the deployment of Snort as a network security system more of a network management and coordination issue than one of affordability. Because of the freeware nature of the product, our approach to testing Snort is slightly different to that for commercial offerings. For example, Snort itself is basically a packet sniffer and rules-based logging engine, with advanced pattern-matching capabilities providing IDS functionality. It does not, however, feature any user-friendly GUI management interface or reporting capability. Configuration is achieved by editing text files, and output is a simple dump of suspicious packet contents and alerts to disk or database. Being open source, there are, of course, numerous freeware solutions available that can provide front-end and back-end functionality, but the permutations are too numerous for us to test effectively. Most commercial offerings are tested �out of the box� and that is how we have chosen to test Snort � utilising only the basic distribution and rule sets provided on www.snort.org. Architectural information and other technical details have also been sourced from the latest-available documents at www.snort.org, whilst technical support during testing and completion of the vendor questionnaire was provided by Silicon Defense (www.silicondefense.com, from where it is also possible to acquire the Windows port). Our thanks go to both Martin Roesch, the creator of Snort, and the support staff at Silicon Defense. Snort's architecture is focused on performance, simplicity, and flexibility. There are three primary subsystems that make up Snort: the packet decoder, the detection engine, and the logging and alerting subsystem. These subsystems ride on top of the libpcap promiscuous packet sniffing library, which provides a portable packet sniffing and filtering capability. Program configuration, rules parsing, and data structure generation takes place before the sniffer section is initialised, keeping the amount of per-packet processing to the minimum required to achieve the base program functionality. The decode engine is organised around the layers of the protocol stack present in the supported data-link and TCP/IP protocol definitions. Each subroutine in the decoder imposes order on the packet data by overlaying data structures on the raw network traffic. These decoding routines are called in order through the protocol stack, from the data link layer up through the� transport layer, finally ending at the application layer. Speed is emphasised in this section, and the majority of the functionality of the decoder consists of setting pointers into the packet data for later analysis by the detection engine. Essential functions such as packet reassembly, port scan detection and HTTP traffic normalisation are performed by plug-in modules known as preprocessors. These can perform a variety of functions on packets � such as modifying packet contents, raising an alert, logging packet contents, or signalling the detection engine not to process the packet at all � before passing them to the detection engine. The stream4 module, for example, provides TCP stream reassembly and stateful analysis capabilities. Stateful stream reassembly capabilities are claimed to allow Snort to ignore �stateless� attacks such as those produced by tools like Stick and Snot, though we found Snort to still generate large numbers of non-TCP alerts (and, as a result of the load, drop genuine attack packets) during Stick and Snot attacks. Stream4 also gives large scale users the ability to track more than 256 simultaneous TCP streams and is claimed to be able to scale to handle 64,000 simultaneous TCP connections. One important point to note is that all of the preprocessors must examine each packet in turn � there is no mechanism for a preprocessor to prematurely cut short packet processing and bypass the remaining ones. This means that if a large number of CPU-intensive preprocessors are loaded then it is likely to have an adverse effect on overall performance. Once the preprocessors are done with the packet (and none of them turned off the detection flag), the packet is passed on to the detection system. Snort maintains its detection rules in a two dimensional linked list of what are termed Chain Headers and Chain Options. These are lists of rules that have been condensed down to a list of common attributes (IP addresses, ports, etc.) in the Chain Headers, with the detection modifier options (TCP flags, ICMP code type, packet payload, etc.) contained in the Chain Options. For example, if forty CGI-BIN probe detection rules are specified in a given Snort detection library file, they generally all share common source and destination IP addresses and ports. To speed the detection processing, these commonalities are condensed into a single Chain Header and then individual detection signatures are kept in Chain Option structures. These rule chains are searched recursively for each packet in both directions. The detection engine checks only those chain options which have� been set by the rules parser at run-time. The first rule that matches a� decoded packet in the detection engine triggers the action specified in the rule definition and returns. A packet that does not match any Snort rule set is simply discarded. Note that Snort also includes the capability for users to write and distribute plug-in modules and bind them to keywords for the detection engine rules language. This allows anyone with an appropriate plug-in module to add significant detection functionality to Snort and customise the program for specific jobs. There is no single entry point into the logging engine. Instead there are multiple routines which serve packet logging and alerting purposes, and these are triggered from either the detection engine or the packet decoder depending on the type of rules and rule options, command line arguments, output plug-in settings, and so on. As with preprocessors, output processing is performed via plug-in modules known as output processors. These decouple output from the main Snort engine, and allow Snort to support a wide number of logging and alerting capabilities, including logging to binary tcpdump files, human-readable ASCII text files, SQL databases, syslog, Winpopup messages, and so on. These can be selected via entries in the configuration file or at run-time with command line switches. The latest Snort distribution can be downloaded from www.snort.org, and the distribution file contains full instructions on the install procedure. Whilst initially daunting for the Linux/Unix novice, installation of Snort is actually not that difficult, following the usual configure, make, make install process. You do, however, require libpcap too, though most are likely to find it already present on their systems. Those using Linux are well served by the RPM format, which removes the need for compilation and makes installation even more straightforward. Windows users can download the installer from the Silicon Defense Web site. Although there is a default rule set and configuration file included with the standard distribution, it is wise to download the latest rule set to be found at www.snort.org. Another good source for Snort rules (though not up to date at the time of writing) is www.whitehats.com. Documentation can be described as adequate at best, and is not always easy to find � often, in fact, the best documentation can be found as comments in source code and configuration files. This can be a huge deterrent to those not well versed in the arcane world of Unix. Once installed, it is not even necessary to edit the configuration file in order to run Snort, since all the necessary options can be specified on the command line, for which there is a full help screen available. Maximum flexibility is achieved by venturing into the configuration and rule files, however, armed with a text editor. Snort is actually capable of running in one of three modes: Sniffer � like tcpdump, Snort will simply read packets from the network and present them in a continuous (or filtered) stream on the console. Packet logger � similar in operation to sniffer mode, Snort can log all packets grabbed from the wire to disk for further analysis Intrusion detection � this is the most powerful and flexible mode allowing Snort to analyse network traffic for matches against a user defined rule set and perform actions based upon what it sees. In this mode, only certain packets are logged or alerted upon. The different modes are determined by the command line switches used to fire up Snort. The default is to log packets in a human-readable hierarchical directory structure based on source IP address in /var/log/snort, and to log alerts (also in ASCII format) to /var/log/snort/alert. Most of the configuration of Snort is done in the snort.conf file an ASCII file that contains a number of reasonably well-commented sections, including variable definitions, preprocessors, output modules, log and alert settings, and which rule sets to include. Many of the configuration options within snort.conf can be overridden via command-line switches, making it easy to test various configuration alternatives without having to edit snort.conf each time. The Snort configuration file provides the means to define parameters for all the available preprocessors. Sensible defaults are provided for each in the standard snort.conf file supplied with the snort.org distribution, but these can be amended to suit individual circumstances. Preprocessors available include port scan detector, fragmentation reassembly and stateful analysis, BackOrifice detector, and traffic normalisation for HTTP, RPC, and Telnet sessions (preventing the use of various types of encoding used in an attempt to evade IDS�). There is also an interesting module called SPADE (Statistical Packet Anomaly Detection Engine) which is a completely new detection engine for Snort that is designed to perform statistical anomaly detection on the network (i.e. raise alerts based on traffic that is deemed �out of the ordinary� for the network on which it is installed, rather than rely on pattern matching).
The signature-matching rules themselves are contained in a number of separate text files, each dedicated to a specific type of rule (such as Web, backdoor, DDOS, FTP, Telnet, DNS, and so on). Each Snort rule contained within those files consists of two logical parts: the rule header and options, as in Figure 1 The rule header determines the protocol, traffic direction, and source and destination IP addresses and ports that apply to the rule. The action field specifies what Snort should do when a rule is matched against packet contents: Pass � drop the packet. Snort performs no more processing on the packet, which provides the means to exclude certain types of traffic from Snort processing Log � writes the full packet to the logging location(s) selected in snort.conf (or on the command line) Alert � generates an event notification to one or more targets as specified in snort.conf, as well as logging the full packet contents as for the log directive. Activate/Dynamic � Activate/dynamic rule pairs enable one rule to trigger another linked rule for a specific number of packets. For example, an activate rule could be triggered by a buffer overflow attempt, and this could trigger a dynamic rule that will collect the next 100 packets of data heading for the same destination in order to provide extended forensic data of the entire session for later analysis. The second half of the Snort rule contains one or more option fields, providing tremendous flexibility and complexity. The most obvious option is the msg keyword, which prints a message in alert and packet logs describing the attack that was spotted. Numerous other keywords (all documented in the User Guide) provide the means to trigger on such things as packet contents, IP options, fragmentation bits, payload size, and TCP flags, amongst others. These can be combined in many ways to detect and classify packets that are of special interest, and all options must be true in order to generate a match and trigger the rule action. Other options are provided to enhance documentation and readability of alerts and packet logs, including unique signature ID, rule classification (i.e. Denial of Service, Information Leak, Privilege gain, and so on), attack severity/priority, and references to external attack identification systems such as Bugtraq, CVE or Arachnids. Some options have special functions, such as the session option, which captures the application-level data for a specific session (allowing the administrator to examine all the data typed by a user in a Telnet session, for example), and the tag option, which specifies that an additional number of packets should be captured following the one that triggered the alert. There is also the react option, which enables Snort to close connections dynamically and perhaps even send a message to a user�s browser warning them against visiting certain prohibited Web sites. The 35 options available in the current release are too numerous to detail here, but are all documented in the User Guide, and are being increased all the time. Unfortunately, the documentation does not always keep up with the rapid pace of development. As you can see, Snort rules are not particularly complex or difficult to read, though that does not always mean they are easy to write! Luckily, there is a huge user community investing time and effort in the development and maintenance of Snort and its rule set, meaning that you can usually find signatures for the latest attacks within days � or even hours � of those attacks becoming known by monitoring the right user groups or Web sites. As with most open source software, some effort is required on the part of the end user to makes sure everything is maintained correctly, and things like signature updates certainly don�t happen at the click of a button in a nice, neat GUI the way they might in a commercial IDS offering. Note also that in the base product, signature updates must be applied carefully � and manually � to each sensor deployed in your organisation. Clearly some degree of centralised management may well be available via another open source offerings, but the onus to source, install, configure and integrate this is on the end user. As with the configuration and management, Snort�s default output capabilities are somewhat basic. Not that it does not have sufficient output options, it�s just that the actual analysis and presentation of the oft-times voluminous amounts of data are left to the administrator to sort out using third party products. Recent developments in Snort have decoupled the output from the main Snort engine providing much more flexibility. As mentioned in the Architecture section, Snort output is essentially split into two � packet logs and alerts � and the output modules are run whenever the alert or logging subsystems of Snort are called, after the preprocessors and detection engine. Alerting can either be �fast� (one line per alert) or �full� (multiple lines of data including full packet headers) � or turned off altogether � and alerts can be written to numerous destinations such as ASCII log files, binary files, syslog, SQL databases, XML files, Unix sockets, SNMP traps or Windows pop-up messages. There is currently no built-in e-mail alerting capability, though this can be achieved using third party tools.� Figure 2 - Typical Snort alerts Each alert also generates a log of the same packet, whilst, conversely, a log rule will not automatically generate an alert. Packet logs � which record complete or abbreviated packet contents depending on the detail level chosen � can be written to the same range of output locations and, like alerts, can be disabled altogether if required. As with preprocessors, many output processor options set in snort.conf can be overridden via command line switches. Careful use of the log and alert rules and output processors can provide a wide range of options for the administrator to provide effective alerting and forensic data logging capabilities. Multiple output processors can be specified for each type of output (alert or log) if required, thus allowing alerts to be written to both database and syslog, whilst full packet logs are written to a binary dump file, for example. For those who want to customise the alerting and packet logging process, it is possible to define new rule types (in addition to log and alert) and associate one or more output plugins specifically to that type. For example, the administrator could create a new rule type called redalert which would cause an alert to be written to syslog and a packet log to be written to a MySQL database: ruletype redalert { Figure 3 - Creating custom rule types within Snort This rule type could then be used in place of the log or alert action directives in any Snort rule. The default settings in the standard Snort distribution force both alerts and packet logs to be written to text files in /var/log/snort. Whilst alerts are written to a single file, packet logs are written to individual ASCII files contained within an extended hierarchical directory structure based on source IP address and alert type. This can make analysis of large amounts of packet log data somewhat difficult, and is why most administrators would probably choose to log to a SQL database.
As you can imagine, writing large numbers of ASCII files into� a large number of subdirectories is likely to be very slow, and so Snort also provides a binary logging option.� Here, packet logs are written to a tcpdump binary file for speed, which can be subsequently run through a separate Snort engine off-line in order to recreate the ASCII-based packet log directory structure for further analysis. For those for whom handling the standard Snort output proves too cumbersome, various third party tools � such as ACID or Snortsnarf � are available to provide a more extensive and user-friendly means of analysis.� Some of these third party tools take considerable effort and knowledge to install, configure and maintain � a typical problem with open source software � and are beyond the scope of this report. Despite being pigeonholed as a �tool for small, lightly utilised networks�, we found that Snort�s performance is more than good enough to allow it to be deployed in large corporate networks. It demonstrated good attack recognition capabilities, and handled our �real world� packet mix tests with relative ease. It even returned very creditable results in the 64 byte packet tests when run on a suitably powerful and well-optimised hardware platform. There are a large number of signatures available, and it is not particularly difficult to develop your own. Alerting is reasonably accurate, although there can be problems with false positives, as with any commercial IDS products. However, at least with Snort you have the option to modify the signatures directly in order to tune them for your own environment. Default signature sets are available from various places on the Web, including www.snort.org and www.whitehats.com. However, this brings up one of the first dilemmas for the Snort �newbie�: which signature set to use? How much do they overlap? Can they be combined without causing problems? How can new signature sets be deployed to multiple remote sensors without destroying any custom rule development that has occurred on those sensors? In short, management of one or more Snort sensors is rarely going to be as straightforward as it is for a typical commercial IDS product, which will usually be far simpler to deploy and manage out of the box. Reporting and analysis, too, is a serious issue with the basic product. Snort does an excellent job of detecting and recording suspicious packets, but the subsequent means of transmitting the alerts to the administrator and analysing the data recorded is left entirely to the end user. True, there are various open source offerings available to provide the missing management and reporting capabilities, but considerable effort is required to source these, download them, install, configure and test them, and support is not always as readily available as it would be for commercial offerings. Optimising the underlying hardware and operating system platform to handle heavier network loads may also prove difficult for the inexperienced. This is typical, of course, of any freely available open source product. The tone of our verdict so far has been cautious, to say the least, and in some respects that is grossly unfair given that Snort is such a fine product � and make no mistake, it is a fine product. But we have to try and compare the entire Snort experience with that offered by competing commercial products, and just because there are no license fees to be paid, it would be a mistake to believe that there is no cost associated with deploying Snort. On its own Snort is a fairly raw tool, and requires quite a supporting cast in order to have everything managed, reporting and alerting the way you want. It is essentially a �roll your own� solution, which is likely to be beyond the capabilities of those organisations which do not have a reasonable level of in-house expertise in the black arts of Unix/Linux. But, for anyone who has that expertise � or who is happy to pay to acquire it from someone else� � the overall Snort experience is likely to be a positive one. The open nature of the product makes it quite possibly the most flexible IDS offering we have looked at so far, and once everything is up and running it requires very little in the way of ongoing management (other than the aforementioned rule-set updates) Configured correctly, it also turns in a performance every bit the equal of (and often superior to) commercial products costing many thousands of pounds. Company: Snort.org Commercial
technical support for the open source product is available from: Click here
to return to the Snort 1.8.1 questionnaire
|
 |
Send mail to webmaster
with questions or�
|
