| msg: foo           | ---------------------          |          |  OTN    \|/   ---------v----------| content: bar       || msg: bar           | ---------------------          |          |  OTN    \|/   ---------v----------| content: baz       || msg: baz           | ---------------------This is an efficient way to do things because we only need to check thedata in the RTN once with this method.  There is actually anotherdimension to this array: the function pointer list.  Each node in the"array" has a linked list of function pointers attached to it.  Thefunctions in this list are the tests that need to be done to determinewhether the data in the current packet matches the current rule node'sinformation.  Having this function pointer list gives us greatefficiency and flexibility: we don't need to perform tests for thingsthe current rule doesn't contain (e.g. "any" ports/IPs, packet contenton non-content rules, etc).  It also allows us to analyze the packetwith any function without having to make major modifications to thewhole program (which was the case in versions prior to version 1.5).There are a couple of implications of this architecture.  For the sakeof this discussion on rules ordering, the one we're interested in isthat rule order is tricky to figure out.  For instancealert tcp any any -> $HOME 80 (content: "foo"; msg: "foo";)alert tcp any any -> $HOME 1:1024 (flags: S; msg: "example";)alert tcp any any -> $HOME 80 (flags: S; msg: "Port 80 SYN!";)alert tcp any any -> $HOME 80 (content: "baz"; msg: "baz";)gets built like this:  RTN                            RTN --------------------           --------------------|  SIP: any          |         |  SIP: any          ||  SP: any           |-------->|  SP: any           ||  DIP: $HOME        |         |  DIP: $HOME        ||  DP: 80            |         |  DP: 1-1024        | --------------------           --------------------          |                              |          |                              |  OTN    \|/                            \|/ ---------v----------           ---------v----------  | content: foo       |         | flags: S           || msg: foo           |         | msg: example       | --------------------           --------------------          |          |  OTN    \|/   ---------v----------| flags: S           || msg: Port 80 SYN!  | --------------------          |          |  OTN    \|/   ---------v----------| content: baz       || msg: baz           | --------------------Note that all three of the port 80 rules will be checked before the"1:1024" rule due to the order in which the applicable RTN has beencreated.  This is because the rules parser builds the first chain headerfor port 80 traffic and sticks it on the rules list, then on the nextrule it sees that a new chain header is required, so it gets built andput in place.  In this case you would intuitively expect to get the"example" message and never see the "Port 80 SYN!", but the opposite istrue.3.14 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: How do I configure stream4?A: Stream4 is an entirely new preprocessor that preforms two functions:   1) Stateful inspection of TCP sessions   2) TCP stream reassembly   I implemented stream4 out of the desire to have more robust stream   reassembly capabilities and the desire to defeat the latest "stateless   attacks" that have been coming out against Snort (c.f. stick and snot).    Stream4 is written with the intent to let Snort be able to handle   performing stream reassembly for "enterprise class" users, people who   need to track and reassemble more than 256 streams simultaneously.  I've   optimized the code fairly extensively to be robust, stable, and fast.    The testing and calculations I've performed lead me to be fairly   confident that stream4 can provide full stream reassembly for several   thousand simultaneous connections and stateful inspection for upwards of   64,000 simultaneous sessions.      Stream4 is a large and complex piece of code (almost 2000 lines) and   there are a lot of options associated with its runtime configuration, so   I'll go over them here.      preprocessor stream4: [noinspect], [keepstats], [timeout <seconds>],   [memcap <btream4_reassemble defaults:    Reassemble client: ACTIVE   Reassemble server: INACTIVE   Reassemble ports: 21 23 25 53 80 143 110 111 513   Reassembly alerts: ACTIVE      There is a new command line switch that is used in concert with the   stream4 code, "-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".   3.15 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: Where does one obtain new/modifed rules? How do you merge them in?A: New rules can be downloaded via CVS (See next question) or alternatively   may be found at www.snort.org. There is a mailing list dedicated to snort    rules, called snort-sigs hosted at sourceforge.   To merge in new rules check out the snortpp program in the snort/contrib   directory.3.16 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: How do you get the latest snort via cvs?A: The Snort project's SourceForge CVS repository can be checked out   through anonymous (pserver) CVS with the following instruction set.   The module you wish to check out must be specified as the modulename.r   When prompted for a password for anonymous, simply press the Enter key.cvs -d:pserver:anonymous@cvs.snort.sourceforge.net:/cvsroot/snort logincvs -z3 -d:pserver:anonymous@cvs.snort.sourceforge.net:/cvsroot/snort co snort    Updates from within the module's directory do not need the -d parameter.***************************************Section 4: RULES AND ALERTS***************************************4.1 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: When I start snort I get errors from my rules files:      Some common ones:       ERROR somefile.rules:yy => Port value missing in rule!       ERROR somefile.rules:yy => Bad port number: "(msg:"blah"       ERROR somefile.rules:yy => Couldn't resolve hostname blah   What's going on?A: somefile.rules is the file where the syntax error occurred, and yy is the    line number it occurred on.  There are a couple of possibilities:   a)  The rule is missing a port value, has an invalid port number, or a       bad hostname - in which case the ruleset author/maintainer should be        notified.   b)  More often, the rule is just fine, but a variable in it was not        declared.  Open the rules file, look at the rule on the line number        provided, and confirm that the variables it uses have been declared.       You can read more about variables from        http://www.snort.org/writing_snort_rules.htm#variables 4.2 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: Snort says "Rule IP addr ("1.1.1.1") didn't x-late, WTF?"A: Chuckle... Get rid of the quotes around the IP address and try again. :-)4.3 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: Snort is behind a firewall (ipf/pf/ipchains/ipfilter) and awfully quiet...A: Your firewall rules will also block traffic to the snort processes.4.4 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: I'm getting large amounts of <some alerts type>. What should I do?  Where   can I go to find out more about it?A: Some rules are more prone to producing false positives than others.        This often varies between networks.  You first need to determine if it   is indeed a false positive.  Some rules are referenced with ID numbers.   The following are some common identification systems, and where to go   to find more information about a particular alert.System      Example        URL---------------------------------------------------------------IDS         IDS182         http://www.whitehats.com/IDS/182CVE         CVE-2000-0138  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0138Bugtraq     BugtraqID 1    http://www.securityfocus.com/vdb/bottom.html?vid=1McAfee      Mcafee 10225   http://vil.nai.com/vil/dispVirus.asp?virus_k=10225   It may be necessary to examine the packet payload to determine if the   alert is a false positive.  The packet payload is logged using the -d   option.  If you determine the alerts are false positives, you may want   to write pass rules for machines that are producing a large number of them.   If the rule is producing an unmanageable amount of false positives from   a number of different machines, you could pass on the rule for all traffic.   This should be used as a last resort.4.5 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: What about all these false alarms?A: Most think that a pile of false positives is infinitely preferable. Then   people can turn off what they don't want. The reverse, having a small rule   set, can lure people into complacency thinking that Snort is doing "its   thing" and there is nothing to worry about. 4.6 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: What are all these ICMP files in subdirectories under /var/log/snort?A: Most of them are likely destination unreachable and port unreachables that   were detected by snort when a communications session attempt fails.4.7 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: Why does the program generate alerts on packets that have pass rules? A: The default order that the rules are applied in is alerts first, then pass   rules, then log rules.  This ordering ensures that you don't write 50 great   alert rules and then disable them all accidently with an errant pass rule.    If you really want to change this order so that the pass rules are applied   first, use the "-o" command line switch.  4.8 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: What are all these "ICMP destination unreachable" alerts?A: ICMP is the acronym for Internet Control Message Protocol   They are failed connections ICMP unreach packet carries first 64   bits(8bytes) or more of the original datagrami and the original IP header.   The ICMP Destination Unreachable (message type 3) is sent back to the   originator when an IP packet could not be delivered to the destination   address.  The ICMP Code indicates why the packet could not be delivered.    The original codes are:         0       net unreachable         1       host unreachable         2       protocol unreachable         3       port unreachable         4       fragmentation needed and DF bit set         5       source route failed   As far as why... "it all depends..."   ICMP Unreachable Error Messages are divided into two groups:   - ICMP Unreachable Error Messages issued by routers (all 16 of them)   - ICMP Unreachable Error Messages issued by a Host (only 2)   What are the only 2 issued by a host?   ICMP Port Unreachable - the destination port on the targeted host is                           closed (a.k.a. not in a listening state).   ICMP Protocol Unreachable - the protocol we were trying to use is not                           being used on the targeted host.   Both ICMP Type field and Code field indicates why the packets could   not be delivered.  Some snort ICMP alerts" are informational like the ICMP   alerts found in icmp-info.rules.  At this time there are no references   or even classtypes associated with these rules.   Other rules are more likely to be associated with untoward activity.  For   example, in icmp.rules you will find:      alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP ISS Pinger";      content:"|495353504e475251|";itype:8;depth:32; reference:arachnids,158;      classtype:attempted-recon; sid:465; rev:1;)   which has a reference where the importance might be determined by checking   out the aracnids reference.  The classtype may indicate more or   less the relative importance of the event.   When a destination UDP port is closed on the targeted host, a.k.a. not   in a listening state, the targeted host will issue an ICMP Port Unreachable   error message back to the offending packets source IP address, given in   the query.  Some programs use these messages, like traceroute with *nix   based machines. Windows based machines (tracert) will default to   ICMP Echo requests...   For further information about this see         IP      ftp://ftp.isi.edu/in-notes/rfc791.txt         ICMP    ftp://ftp.isi.edu/in-notes/rfc792.txt         TCP     ftp://ftp.isi.edu/in-notes/rfc793.txt         UDP     ftp://ftp.isi.edu/in-notes/rfc768.txt   and   http://www.iana.org/assignments/icmp-parameters   Actually, putting this URL somewhere handy is a good idea:   http://www.iana.org/   There is also a good ICMP paper on http://www.sys-security.com/4.9 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: Why do many snort rules have the flags P (TCP PuSH) and A (TCP ACK) set?A:  One of the reasons it alerts on a PA flags is to minimize the false    positive. You will only get an alert upon successful connections. If you    want to see all the attempts, you either have to modify the signatures, add    you own signatures or use your firewall logs to see if an attempt to    specific a port occurred.4.10 --faq-- --snort-- --faq-- --snort-- --faq-- --snort-- --faq--Q: What are these IDS codes in the alert names?A: IDS means "Intrusion Detection Signature" and identifies a   known attack attempt. You can learn more about a specific IDS id   at the arachNIDS search engine on http://www.whitehats.com/.   The "references" keyword in rules can also be a good pointer    for further research.