| PREVIOUS | HEAD |
Snort uses a simple, lightweight rules description language that is flexible and quite powerful. There are a number of simple guidelines to remember when developing Snort rules.
Most Snort rules are written in a single line. This was required in versions prior to 1.8. In current versions of Snort, rules may span multiple lines by adding a backslash to the end of the line.
Snort rules are divided into two logical sections, the rule header and the rule options. The rule header contains the rule's action, protocol, source and destination IP addresses and netmasks, and the source and destination ports information. The rule option section contains alert messages and information on which parts of the packet should be inspected to determine if the rule action should be taken.
Figure 2.1 illustrates a sample Snort rule.
msg: "mountd access";)
The text up to the first parenthesis is the rule header and the section enclosed in parenthesis is the rule options. The words before the colons in the rule options section are called option keywords. Note that the rule options section is not specifically required by any rule, they are just used for the sake of making tighter definitions of packets to collect or alert on (or drop, for that matter). All of the elements in that make up a rule must be true for the indicated rule action to be taken. When taken together, the elements can be considered to form a logical AND statement. At the same time, the various rules in a Snort rules library file can be considered to form a large logical OR statement.
The include keyword allows other rule files to be included within the rules file indicated on the Snort command line. It works much like an "#include" from the C programming language, reading the contents of the named file and putting them in place in the file in the place where the include appears.
Format
Variables may be defined in Snort. These are simple substitution variables set with the var keyword as in Figure 2.2.
alert tcp any any -> $MY_NET any (flags: S; msg: "SYN packet";)
See Figure 2.3 for an example of these rules modifiers in action.
log tcp any any -> $(MY_NET:?MY_NET is undefined!) 23
The rule header contains the information that defines the "who, where, and what" of a packet, as well as what to do in the event that a packet with all the attributes indicated in the rule should show up. The first item in a rule is the rule action. The rule action tells Snort what to do when it finds a packet that matches the rule criteria. There are 5 available default actions in Snort, alert, log, pass, activate, and dynamic.
This example will create a type that will log to just tcpdump:
{
type log output
log_tcpdump: suspicious.log
}
{
type alert output
alert_syslog: LOG_AUTH LOG_ALERT
output database: log, mysql, user=snort dbname=snort host=localhost
}
The next field in a rule is the protocol. There are four Protocols that Snort currently analyzes for suspicious behavior - tcp, udp, icmp, and ip. In the future there may be more, such as ARP, IGRP, GRE, OSPF, RIP, IPX, etc.
The next portion of the rule header deals with the IP address and port information for a given rule. The keyword "any" may be used to define any address. Snort does not have a mechanism to provide host name lookup for the IP address fields in the rules file. The addresses are formed by a straight numeric IP address and a CIDR[,] block. The CIDR block indicates the netmask that should be applied to the rule's address and any incoming packets that are tested against the rule. A CIDR block mask of /24 indicates a Class C network, /16 a Class B network, and /32 indicates a specific machine address. For example, the address/CIDR combination 192.168.1.0/24 would signify the block of addresses from 192.168.1.1 to 192.168.1.255. Any rule that used this designation for, say, the destination address would match on any address in that range. The CIDR designations give us a nice short-hand way to designate large address spaces with just a few characters.
In Figure 2.1, the source IP address was set to match for any computer talking, and the destination address was set to match on the 192.168.1.0 Class C network.
There is an operator that can be applied to IP addresses, the negation operator. This operator tells Snort to match any IP address except the one indicated by the listed IP address. The negation operator is indicated with a "!". For example, an easy modification to the initial example is to make it alert on any traffic that originates outside of the local net with the negation operator as shown in Figure 2.4.
(content: "|00 01 86 a5|"; msg: "external mountd access";)
This rule's IP addresses indicate "any tcp packet with a source IP address not originating from the internal network and a destination address on the internal network".
You may also specify lists of IP addresses. An IP list is specified by enclosing a comma separated list of IP addresses and CIDR blocks within square brackets. For the time being, the IP list may not include spaces between the addresses. See Figure 2.5 for an example of an IP list in action.
[192.168.1.0/24,10.1.1.0/24] 111 (content: "|00 01 86 a5|";
msg: "external mountd access";)
Port numbers may be specified in a number of ways, including "any" ports, static port definitions, ranges, and by negation. "Any" ports are a wildcard value, meaning literally any port. Static ports are indicated by a single port number, such as 111 for portmapper, 23 for telnet, or 80 for http, etc. Port ranges are indicated with the range operator ":". The range operator may be applied in a number of ways to take on different meanings, such as in Figure 2.6.
Port negation is indicated by using the negation operator "!". The negation operator may be applied against any of the other rule types (except any, which would translate to none, how Zen...). For example, if for some twisted reason you wanted to log everything except the X Windows ports, you could do something like the rule in Figure 2.7.
The Direction Operator
The direction operator "->" indicates the orientation, or "direction", of the traffic that the rule applies to. The IP address and port numbers on the left side of the direction operator is considered to be the traffic coming from the source host, and the address and port information on the right side of the operator is the destination host. There is also a bidirectional operator, which is indicated with a "<>" symbol. This tells Snort to consider the address/port pairs in either the source or destination orientation. This is handy for recording/analyzing both sides of a conversation, such as telnet or POP3 sessions. An example of the bidirectional operator being used to record both sides of a telnet session is shown in Figure 2.8.
Activate/dynamic rule pairs give Snort a powerful capability. You can now have one rule activate another when it's action is performed for a set number of packets. This is very useful if you want to set Snort up to perform follow on recording when a specific rule "goes off". Activate rules act just like alert rules, except they have a *required* option field: "activates". Dynamic rules act just like log rules, but they have a different option field: "activated_by". Dynamic rules have a second required field as well, "count". When the "activate" rule goes off, it turns on the dynamic rule it is linked to (indicated by the activates/activated_by option numbers) for "count" number of packets (50 in this case).
Put 'em together and they look like Figure 2.9.
content: "|E8C0FFFFFF|bin|; activates: 1;
msg: "IMAP buffer overflow!";)
dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by: 1; count: 50;)
These rules tell Snort to alert when it detects an IMAP buffer overflow and collect the next 50 packets headed for port 143 coming from outside $HOME_NET headed to $HOME_NET. If the buffer overflow happened and was successful, there's a very good possibility that useful data will be contained within the next 50 (or whatever) packets going to that same service port on the network, so there's value in collecting those packets for later analysis.
Rule options form the heart of Snort's intrusion detection engine, combining ease of use with power and flexibility. All Snort rule options are separated from each other using the semicolon ";" character. Rule option keywords are separated from their arguments with a colon ":" character.
The msg rule option tells the logging and alerting engine the message to print along with a packet dump or to an alert. It is a simple text string that utilizes the "" as an escape character to indicate a discrete character that might otherwise confuse Snort's rules parser (such as the semi-colon ";" character).
The logto option tells Snort to log all packets that trigger this rule to a special output log file. This is especially handy for combining data from things like NMAP activity, HTTP CGI scans, etc. It should be noted that this option does not work when Snort is in binary logging mode.
This rule option is used to set a specific time-to-live value to test against. The test it performs is only successful on an exact match. This option keyword was intended for use in the detection of traceroute attempts.
The "tos" keyword allows you to check the IP header TOS field for a specific value. The test it performs is only successful on an exact match.
This option keyword is used to test for an exact match in the IP header fragment ID field. Some hacking tools (and other programs) set this field specifically for various purposes, for example the value 31337 is very popular with some hackers. This can be turned against them by putting a simple rule in place to test for this and some other "hacker numbers".
If IP options are present in a packet, this option will search for a specific option in use, such as source routing. Valid arguments to this option are:
This rule inspects the fragment and reserved bits in the IP header. There are three bits that can be checked, the Reserved Bit (RB), More Fragments (MF) bit, and the Don't Fragment (DF) bit. These bits can be checked in a variety of combinations. Use the following values to indicate specific bits: * R - Reserved Bit * D - DF bit * M - MF bit
You can also use modifiers to indicate logical match criteria for the specified bits: * + - ALL flag, match on specified bits plus any others * * - ANY flag, match if any of the specified bits are set * ! - NOT flag, match if the specified bits are not set
msg: "Reserved IP bit set!";)
The dsize option is used to test the packet payload size. It may be set to any value, plus use the greater than/less than signs to indicate ranges and limits. For example, if you know that a certain service has a buffer of a certain size, you can set this option to watch for attempted buffer overflows. It has the added advantage of being a much faster way to test for a buffer overflow than a payload content check.
The content keyword is one of the more important features of Snort. It allows the user to set rules that search for specific content in the packet payload and trigger response based on that data. Whenever a content option pattern match is performed, the Boyer-Moore pattern match function is called and the (rather computationally expensive) test is performed against the packet contents. If data exactly matching the argument data string is contained anywhere within the packet's payload, the test is successful and the remainder of the rule option tests are performed. Be aware that this test is case sensitive.
The option data for the content keyword is somewhat complex; it can contain mixed text and binary data. The binary data is generally enclosed within the pipe ("|") character and represented as bytecode. Bytecode represents binary data as hexadecimal numbers and is a good shorthand method for describing complex binary data. Figure 2.11 contains an example of mixed text and binary data in a Snort rule.
Note that multiple content rules can be specified in one rule. This allows rules to be tailored for less false positives.
Also note that the following characters must be escaped inside a content rule:
msg: "IMAP buffer overflow!";)
dsize: >100; msg: "Long Non-Get FTP command!";)
The offset rule option is used as a modifier to rules using the content option keyword. This keyword modifies the starting search position for the pattern match function from the beginning of the packet payload. It is very useful for things like CGI scan detection rules where the content search string is never found in the first four bytes of the payload. Care should be taken against setting the offset value too "tightly" and potentially missing an attack! This rule option keyword cannot be used without also specifying a content rule option. See Figure 2.13 for an example of a combined content, offset, and depth search rule.
Depth is another content rule option modifier. This sets the maximum search depth for the content pattern match function to search from the beginning of its search region. It is useful for limiting the pattern match function from performing inefficient searches once the possible search region for a given set of content has been exceeded. (Which is to say, if you're searching for "cgi-bin/phf" in a web-bound packet, you probably don't need to waste time searching the payload beyond the first 20 bytes!) See Figure 2.13 for an example of a combined content, offset, and depth search rule.
offset: 3; depth: 22; msg: "CGI-PHF access";)
The nocase option is used to deactivate case sensitivity in a "content" rule. It is specified alone within a rule and any ASCII characters that are compared to the packet payload are treated as though they are either upper of lower case.
nocase; msg: "FTP root user access attempt";)
This rule tests the TCP flags for a match. There are actually 9 flags variables available in Snort:
This rule option refers to the TCP sequence number. Essentially, it detects if the packet has a static sequence number set, and is therefore pretty much unused. It was included for the sake of completeness.
The ack rule option keyword refers to the TCP header's acknowledge field. This rule has one practical purpose so far: detecting NMAP[,,,,] TCP pings. A NMAP TCP ping sets this field to zero and sends a packet with the TCP ACK flag set to determine if a network host is active. The rule to detect this activity is shown in Figure 2.16.
This rule tests the value of the ICMP type field. It is set using the numeric value of this field. For a list of the available values, look in the decode.h file included with Snort or in any ICMP reference. It should be noted that the values can be set out of range to detect invalid ICMP type values that are sometimes used in denial of service and flooding attacks.
The icode rule option keyword is pretty much identical to the itype rule, just set a numeric value in here and Snort will detect any traffic using that ICMP code value. Out of range values can also be set to detect suspicious traffic.
The session keyword is brand new as of version 1.3.1.1 and is used to extract the user data from TCP sessions. It is extremely useful for seeing what users are typing in telnet, rlogin, ftp, or even web sessions. There are two available argument keywords for the session rule option, printable or all. The printable keyword only prints out data that the user would normally see or be able to type. The all keyword substitutes non-printable characters with their hexadecimal equivalents. This function can slow Snort down considerably, so it shouldn't be used in heavy load situations, and is probably best suited for post-processing binary (tcpdump format) log files. See Figure 2.17 for a good example of a telnet session logging rule.
The icmp_id option examines an ICMP ECHO packet's ICMP ID number for a specific value. This is useful because some [84]covert channel programs use static ICMP fields when they communicate. This particular plugin was developed to enable the stacheldraht detection rules written by [85]Max Vision, but it is certainly useful for detection of a number of potential attacks.
The icmp_id option examines an ICMP ECHO packet's ICMP sequence field for a specific value. This is useful because some [86]covert channel programs use static ICMP fields when they communicate. This particular plugin was developed to enable the stacheldraht detection rules written by [87]Max Vision, but it is certainly useful for detection of a number of potential attacks. (And yes, I know the info for this field is almost identical to the icmp_id description, it's practically the same damn thing!)
This option looks at RPC requests and automatically decodes the application, procedure, and program version, indicating success when all three variables are matched. The format of the option call is "application, procedure, version". Wildcards are valid for both the procedure and version numbers and are indicated with a "*".
msg:"RPC getport (TCP)";)
alert udp any any -> 192.168.1.0/24 111 (rpc: 100000,*,3;
msg:"RPC getport (UDP)";)
alert udp any any -> 192.168.1.0/24 111 (rpc: 100083,*,*;
msg:"RPC ttdb";)
alert udp any any -> 192.168.1.0/24 111 (rpc: 100232,10,*;
msg:"RPC sadmin";)
The resp keyword implements flexible response (FlexResp) to traffic that matches a Snort rule. The FlexResp code allows Snort to actively close offending connections. The following arguments are valid for this module:
rst_snd - send TCP-RST packets to the sending socket
rst_rcv - send TCP-RST packets to the receiving socket
rst_all - send TCP_RST packets in both directions
icmp_net - send a ICMP_NET_UNREACH to the sender
icmp_host - send a ICMP_HOST_UNREACH to the sender
icmp_port - send a ICMP_PORT_UNREACH to the sender
icmp_all - send all above ICMP packets to the sender
These options can be combined to send multiple responses to the target host. Multiple arguments are separated by a comma.
resp: rst_all; msg: "Root shell backdoor attempt";)
alert udp any any -> 192.168.1.0/24 31 (resp: icmp_port,icmp_host;
msg: "Hacker's Paradise access attempt";)
The content-list keyword allows multiple content strings to be specified in the place of a single content option. The patterns to be searched for must each be on a single line of content-list file as shown in Figure 2.20, but they are treated otherwise identically to content strings specified as an argument to a standard content directive. This option is the basis for the react keyword.
Using the ! operator, the alert will be triggered on events not matching this rule. See Section 2.3.9 for more explanation.
porn
adults
hard core
www.pornsite.com
# ...
The react keyword based on flexible response (Flex Resp) implements flexible reaction to traffic that matches a Snort rule. The basic reaction is blocking interesting sites users want to access: New York Times, slashdot, or something really important - napster and porn sites. The Flex Resp code allows Snort to actively close offending connections and/or send a visible notice to the browser (warn modifier available soon). The notice may include your own comment. The following arguments (basic modifiers) are valid for this option:
msg: "Not for children!"; react: block, msg;)
alert tcp any any <> 192.168.1.0/24 any (content-list: "adults";
msg: "Adults list access attempt"; react: block;)
The reference keyword allows rules to include references to external attack identification systems. The plugin currently supports several specific systems as well as unique urls. This plugin is to be used by output plugins to provide a link to additional information about the alert produced.
| System | URL Prefix |
| Bugtraq | http://www.securityfocus.com/bid/ |
| CVE | http://cve.mitre.org/cgi-bin/cvename.cgi?name= |
| Arachnids | http://www.whitehats.com/info/IDS |
| McAffee | http://vil.nai.com/vil/dispVirus.asp?virus_k= |
| url | http:// |
AP; content: "|fff4 fffd 06|"; reference: arachNIDS,IDS411;)
alert TCP any any -> any 21 (msg: "IDS287/ftp-wuftp260-venglin-linux";
flags: AP; content: "|31c031db 31c9b046 cd80 31c031db|";
reference: arachNIDS,IDS287; reference: bugtraq,1387;
reference: cve,CAN-2000-1574; )
The sid keyword is used to identify unique Snort rules. This information allows output plugins to identify rules easily. See Figure 2.23for a usage example. Sid ranges are assigned as follows:
(msg:"WEB-IIS File permission canonicalization";
uricontent:"/scripts/..%c1%9c../";
flags: A+; nocase; sid:983; rev:1;)
The rev keyword is used to identify rule revisions. Revisions, along with snort rule ids, allow signatures and descriptions to be refined and replaced with updated information. For a usage example, see Figure 2.23.
The classtype keyword categorizes alerts to be attack classes. By using the and prioritized. The user can specify what priority each type of rule classification has. Rules that have a classification will have a default priority set.
| Class Name | Description | Default Priority |
| not-suspicious | Not Suspicious Traffic | 0 |
| unknown | Unknown Traffic | 1 |
| bad-unknown | Potentially Bad Traffic | 2 |
| attempted-recon | Attempted Information Leak | 3 |
| successful-recon-limited | Information Leak | 4 |
| successful-recon-largescale | Large Scale Information Leak | 5 |
| attempted-dos | Attempted Denial of Service | 6 |
| successful-dos | Denial of Service | 7 |
| attempted-user | Attempted User Privilege Gain | 8 |
| unsuccessful-user | Unsuccessful User Privilege Gain | 7 |
| successful-user | Successful User Privilege Gain | 9 |
| attempted-admin | Attempted Administrator Privilege Gain | 10 |
| successful-admin | Successful Administrator Privilege Gain | 11 |
dsize: > 128; classtype:attempted-admin; priority:10 );
alert TCP any any -> any 25 (msg:"SMTP expn root"; flags:A+;
content:"expn root"; nocase; classtype:attempted-recon;)
The priority tag assigns a severity level to rules. A classtype rule assigns a default priority that may be overridden with a priority rule. For an example in conjunction with a classification rule refer to Figure 2.24. For use by itself, see Figure 2.25
content: "/cgi-bin/bash"; priority:10;)
The uricontent rule allows searches to be matched against only the URI portion of a request. This allows rules to search only the request portion of an attack without false alerts from server data files. For a description of the parameters to this function, see the content rule options in Section 2.3.9.
The tag keyword allow rules to log more than just the single packet that triggered the rule. Once a rule is triggered, additional traffic involving the source host is ``tagged''. Tagged traffic is logged to allow analysis of response codes and post-attack traffic. See Figure 2.26 for usage examples.
content: "|e8 c0ff ffff|/bin/sh"; tag: host, 300, packets, src;
msg: "IMAP Buffer overflow, tagging!";)
alert tcp !$HOME_NET any -> $HOME_NET 23 (flags: S;
tag: session, 10, seconds; msg: "incoming telnet session";)
The ip_proto keyword allows checks against the IP protocol header. For a list of protocols that may be specified by name, see /etc/protocols. Note the use of the ip protocol specification in the rule.
ip_proto: igmp; )
The sameip keyword allows rules to check if the source ip is equal to the destination ip.
Used in conjunction with the Stream4 preprocessor, the stateless keyword allows rules to match regardless of the state of the connection the packet is associated with.
The regex option allows content options to specify wildcard options. The wildcards behave more like shell globbing than Perl-type regular expressions. A '*' in the content string, along with the regex modifier is interpreted to mean "any character, any number of times." Additionally, the '?' character means "any single character".
At the time of writing (Snort 1.8.1), it could not be used in conjunction with the nocase option. This is a bug and is marked to be fixed.
(flags: A+;
content: "|c08f e4ff ffff|/bin/*sh"; regex;
msg: "buffer overflow!"; sid: 2341239; rev: 1;)
Preprocessors were introduced in version 1.5 of Snort. They allow the functionality of Snort to be extended by allowing users and programmers to drop modular "plugins" into Snort fairly easily. Preprocessor code is run before the detection engine is called, but after the packet has been decoded. The packet can be modified or analyzed in an "out of band" manner through this mechanism.
Preprocessors are loaded and configured using the preprocessor keyword. The format of the preprocessor directive in the Snort rules file is:
This documentation is for historical purposes. As of Snort 1.8, the use of minfrag is deprecated in favor of Stream4.
The minfrag preprocessor examines fragmented packets for a specified size threshold. When packets are fragmented, it is generally caused by routers between the source and destination. Generally speaking, there is no piece of commercial network equipment that fragments packets in sizes smaller than 512 bytes, so we can use this fact to enable traffic to be monitored for tiny fragments that are generally indicative of someone trying to hide their traffic behind fragmentation.
HTTP Decode is used to process HTTP URI strings and convert their data to non-obfuscated ASCII strings. This is done to defeat evasive web URL scanners and hostile attackers that could otherwise elude the content analysis strings used to examine HTTP traffic for suspicious activity. The preprocessor module takes HTTP port numbers (separated by spaces) to be normalized as its arguments (typically 80 and 8080).
Alerts on unicode traffic and null bytes in CGI's can be disabled via the -unicode and -cginull options.
The Snort Portscan Preprocessor is developed by Patrick Mullen and more information is available at his web page[,].
The arguments to this module are:
Another module from Patrick Mullen that modifies the portscan detection system's operation. If you have servers which tend to trip off the portscan detector (such as NTP, NFS, and DNS servers), you can tell portscan to ignore TCP SYN and UDP portscans from certain hosts. The arguments to this module are a list of IPs/CIDR blocks to be ignored.
The defrag module (from Dragos Ruiu) allows Snort to perform full blown IP defragmentation, making it more difficult for hackers to simply circumvent the detection capabilities of the system. It is very simple in its usage, merely requiring the addition of a preprocessor directive to the configuration file with no arguments. This module generall supercedes the functionality of the minfrag module (i.e. you don't need to use minfrag if you're using defrag).
Frag2, introduced in Snort 1.8, is a new IP defragmentation preprocessor. Frag2 is designed to replace the defrag preprocessor. This defragmenter is designed to memory efficient and use the same memory management routines that are in use in other parts of Snort.
Frag2 has configurable memory usage and fragment timeout options. Given no arguments, frag2 uses the default memory limit of 4194304 bytes (4 MB) and a timeout period of 60 seconds.
This module is documented here only for historical reasons. New versions of snort should use Stream4.
The stream plugin provides TCP stream reassembly functionality to Snort. TCP streams on the configured ports with small segments will be reassembled into a stream of data that Snort can properly evaluate for suspicious activity. This plugin takes a number of arguments:
The stream4 module provides TCP stream reassembly and stateful analysis capabilities to Snort. Robust stream reassembly capabilities allow Snort to ignore ''stateless'' attacks such as stick and snot produce. Stream4 also gives large scale users the ability to track more than 256 simultaneous TCP streams. Stream4 should be able to scale to handle 64,000 simultaneous TCP connections.
Stream4 contains two configurable modules, the stream4 preprocessor and the associated stream4 reassemble plugin. Their associated options listed below.
[memcap <bytes>], [detect_scans], [detect state_problems]
Just setting the stream4 and stream4_reassemble directives without arguments in the snort.conf file will set them up in their default configurations shown in Table 2.3 and Table 2.4.
Stream4 introduces a new command line switch: "-z". The -z switch can take one of two arguments: "est" and "all". The "all" argument is the default if you don't specify anything and tells Snort to alert normally. If the -z switch is specified with the "est" argument, Snort will only alert (for TCP traffic) on streams that have been established via a three way handshake or streams where cooperative bidirectional activity has been observed (i.e. where some traffic went one way and something other than a RST or FIN was seen going back to the originator). With "-z est" turned on, Snort completely ignores TCP-based stick/snot "attacks".
This is done as a mechanism to let people have control over a subsystem in Snort that can eat a lot of CPU cycles if you're not careful. For example, in many networks today, packets with bad IP checksums never make it past the router or switch, and so IP checksum verification is a waste of time for Snort on these networks. Allowing people to turn that subsystem off (or tune it) lets them get better performance without having to make code tweaks.
Stream4 also adds another command line switch, "-k". The -k switch allows you to modify the checksum tests that Snort performs in the decoder stage. This mechanism allows users to control the CPU usage of a potential bottleneck in Snort. In many modern networks, packets with bad IP checksums never make it past the router or switch. This means that IP checksum verification is a waste of time for Snort on these networks. Allowing people to disable specific subsystems allows better performance without having to modify Snort's source code.
The -k checksum option takes the following command line arguments:
| Option | Default |
| Session Timeout | 30 seconds |
| Session Memory Cap | 8388608 bytes |
| Stateful Inspection | ACTIVE |
| Stream Stats | INACTIVE |
| State Problem Alerts | INACTIVE |
| Portscan Alerts | INACTIVE |
| Option | Default |
| Reassemble Client | ACTIVE |
| Reassemble Server | INACTIVE |
| Reassemble Ports | 21 23 25 53 80 143 110 111 513 |
| Reassembly Alerts | ACTIVE |
In the interest of timeliness and sanity, I'd suggest checking out the README.Spade in the Snort distribution as well as checking out the Silicon Defense website[7,,].
This module allows Snort to be able to perform statistical anomaly detection on your network, and it's essentially an entire new detection engine for Snort. If you're interested in this kind of capability, you should definitely read the documentation in the Snort distribution as well as that on the Silicon Defense website.
Output modules are new as of version 1.6. They allow Snort to be much more flexible in the formatting and presentation of output to its users. The output modules are run when the alert or logging subsystems of Snort are called, after the preprocessors and detection engine. The format of the directives in the rules file is very similar to that of the preprocessors.
Multiple output plugins may be specified in the Snort configuration file. When multiple plugins of the same type (log, alert) are specified, they are "stacked" and called in sequence when an event occurs. As with the standard logging and alerting systems, output plugins send their data to /var/log/snort by default or to a user directed directory (using the "-l" command line switch).
Output modules are loaded at runtime by specifying the output keyword in the rules file:
This module sends alerts to the syslog facility (much like the -s command line switch). This module also allows the user to specify the logging facility and priority within the Snort rules file, giving users greater flexibility in logging alerts.
Options
Facilities
Priorities
This will print Snort alerts in a quick one line format to a specified output file. It is a faster alerting method than full alerts because it doesn't need to print all of the packet headers to the output file
Print Snort alert messages with full packet headers. This alerting facility is generall pretty slow because it requires that the program do a whole lot of data parsing to format the data to be printed. The alerts will be written in the default logging directory (/var/log/snort) or in the logging directory specified at the command line.
This plugin sends WinPopup alert messages to the NETBIOS named machines indicated within the file specified as an argument to this output plugin. It should be noted that use of this plugin is not encouraged as it executes an external executable binary (smbclient) at the same privilege level as Snort, commonly root. The format of the workstation file is a list of the NETBIOS names of the hosts that wish to receive alerts, one per line in the file.
Sets up a UNIX domain socket and sends alert reports to it. External programs/processes can listen in on this socket and receive Snort alert and packet data in real time. This is currently an experimental interface.
The log_tcpdump module logs packets to a tcpdump-formatted file. This is useful for performing post process analysis on collected traffic with the vast number of tools that are avialable for examining tcpdump formatted files. This module only takes a single argument, the name of the output file.
The XML plug-in enables snort to log in SNML - simple network markup language aka (snort markup language) to a file or over a network. The DTD is available in the contrib directory of the snort distribution and at: http://www.cert.org/DTD/snml-1.0.dtd. You can use this plug-in with on one or more snort sensors to log to a central database and create highly configurable intrusion detection infrastructures within your network. The plugin will also enable you to automatically report alerts to the CERT Coordination Center, your response team, or your managed IDS provider.
This plugin was developed by Jed Pickel and Roman Danyliw at the CERT Coordination Center as part of the AIRCERT project. Be aware that the SNML DTD is in its early phases of development and is likely to be modified as it undergoes public scrutiny. See http://www.cert.org/DTD/snml-1.0.dtdfor the most up to date information and documentation about this plugin.
This string can be created by:
timestamp, signature, source ip, destination ip, source port, destination port, tcp flags, protocol
host=air.cert.org file=alert.snort cert=mycert.crt
key=mykey.pem ca=ca.crt server=srv_list.lst
This module from Jed Pickel sends Snort data to a variety of SQL databases. More information on installing and configuring this module can be found on the [91]Incident.org web page. The arguments to this plugin are the name of the database to be logged to and a parameter list. Parameters are specified with the format parameter = argument. See Figure 2.45 for example usage.
There are four database types available in the current version of the plugin. These are MySQL, PostgreSQL, Oracle, and unixODBC-compliant databases. Set the type to match the database you are using.
The CSV output plugin allows alert data to be written in a format easily importable to a database. The plugin requires 2 arguments, a full pathname to a file and the output formatting option.
The list of formatting options is below. If the formatting option is default, the output is in the order the formatting option is listed.
output CSV: /var/log/alert.csv timestamp, msg
The unified output plugin is designed to be the fastest possible method of logging Snort events. It logs events into an alert file and a packet log file. The alert file contains the high-level details of an event (ips, protocol, port, message id). The log file contains the detailed packet information ( a packet dump with the associated event id ).
Both portions of the files are written in a binary format described in spo_unified.h. Barnyard, when available, will incorporate the current output plugins into a new architecture so that logging. The Unified-output format will soon become the standard method of logging Snort data for sensors that have high amounts of activity. Snort will focus only only on collecting data in realtime while Barnyard will allow complex logging methods that would otherwise diminish sensor effectiveness.
Note the date format `'monthday@hourminute-`' is prepended to the file name to separate Snort starts.
output log_unified: <file name>
output log_unified: snort.log
The SNMP trap output module allows Snort to direct alerts to a network management station (NMS). The MIB format is listed in the MIBS directory of the Snort distribution. SNMP allows Snort to integrate with many third party tools in a standard manner.
Glenn Mansfield Keeni contributed this plugin and established an SNMP enterprise id for Snort (10234). This plugin is contains code licensed under a BSD license and its copyright notice is listed in Appendix A.
[SnmpOptions] , <snmptrapdAddress>, <community>
There are some general concepts to keep in mind when developing Snort rules to maximize efficiency and speed. I will add to this section as my muse wills. :)
Content Rules are Case Sensitive (unless you use the "nocase" option)
Don't forget that content rules are case sensitive and that many programs typically use uppercase letters to indicate commands. FTP is a good example of this. Consider the following two rules:
msg: "FTP root login";)
alert tcp any any -> 192.168.1.0/24 21 (content: "USER root";
msg: "FTP root login";)
Speeding Up Rules That Have Content Options
The order that rules are tested by the detection engine is completely independent of the order that they are written in a rule. The last rule test that is done (when necessary) is always the content rule option. Take advantage of this fact by using other faster rule options that can detect whether or not the content needs to be checked at all. For instance, most of the time when data is sent from client to server after a TCP session is established, the PSH and ACK TCP flags are set on the packet containing the data. This fact can be taken advantage of by rules that need to test payload content coming from the client to the sever with a simple TCP flag test that is far less computationally expensive than the pattern match algorithm. Knowing this, a simple way to speed up rules that use content options is to also perform a flag test, as in Figure 2.49. The basic idea is that if the PSH and ACK flags aren't set, there's no need to test the packet payload for the given rule. If the flags are set, the additional computing power required to perform the test is negligible.
flags: PA; msg: "CGI-PHF probe";)
| NEXT | HEAD |