faq

入侵检测系统.linux下与MySql连用的例子

| 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 the
data in the RTN once with this method.  There is actually another
dimension to this array: the function pointer list.  Each node in the
"array" has a linked list of function pointers attached to it.  The
functions in this list are the tests that need to be done to determine
whether the data in the current packet matches the current rule node's
information.  Having this function pointer list gives us great
efficiency and flexibility: we don't need to perform tests for things
the current rule doesn't contain (e.g. "any" ports/IPs, packet content
on non-content rules, etc).  It also allows us to analyze the packet
with any function without having to make major modifications to the
whole program (which was the case in versions prior to version 1.5).

There are a couple of implications of this architecture.  For the sake
of this discussion on rules ordering, the one we're interested in is
that rule order is tricky to figure out.  For instance

alert 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 been
created.  This is because the rules parser builds the first chain header
for port 80 traffic and sticks it on the rules list, then on the next
rule it sees that a new chain header is required, so it gets built and
put in place.  In this case you would intuitively expect to get the
"example" message and never see the "Port 80 SYN!", but the opposite is
true.


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:[e-mail]:/cvsroot/snort login

cvs -z3 -d:pserver:[e-mail]:/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/182
CVE         CVE-2000-0138  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0138
Bugtraq     BugtraqID 1    http://www.securityfocus.com/vdb/bottom.html?vid=1
McAfee      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.