next up previous
Next: 5 Getting Fancy Up: The Snort FAQ Previous: 3 Configuring Snort

Subsections

4 Rules and Alerts

4.1 Errors loading rules files

Some common ones:

What's going on?

``telnet.rules'' is the file where the syntax error occurred, and ``YYY'' is the line number it occurred on. There are a couple of possibilities:

  1. 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.

  2. 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 at http://www.snort.org/docs/writing_rules/chap2.html#tth_sEc2.1.2

4.2 Snort says ``Rule IP addr (``1.1.1.1'') didn't x-late, WTF?''

Get rid of the quotes around the IP address and try again.

4.3 Snort is behind a firewall (ipf/pf/ipchains/ipfilter) and awfully quiet...

Your firewall rules will also block traffic to the Snort processes.

Note: This does not apply if Snort is installed on the firewall box.

4.4 Does snort see packets filtered by IPTables/IPChains/IPF/PF?

Snort operates using libpcap. In general it sees everything the network adapter driver sees before the network stack munges it. Linux IPTables, Linux IPChains, BSD PF and IPF and other packet filters do not prevent snort from seeing a packet that is present on the network wire. Even if an inbound packet is denied by the packet filter Snort will still see and analyze the packet if it is listening to that interface. Snort/pcap sees whatever comes out of or goes into the network adapter.

Note however that Snort is affected to the extent that the stream of data on the network wire is affected. Thus Snort will not see outbound packets which were denied while being sent since they will never reach the network adapter.

Under OpenBSD you can snort just the PF rejects by using the /dev/pflogN interface.

4.5 I'm getting large amounts of $<$some alerts type$>$. What should I do? Where can I go to find out more about it?

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
Nessus Nessus 11073 http://cgi.nessus.org/plugins/dump.php3?id=11073

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.6 What about all these false alarms?

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.7 What are all these ICMP files in subdirectories under /var/log/snort?

Most of them are likely destination unreachable and port unreachables that were detected by snort when a communications session attempt fails.

4.8 Why does the program generate alerts on packets that have pass rules?

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, or the ``order'' config directive.

One other thing to keep in mind is that the alert might be generated from a preprocessor. If that is the case, then no pass rule will help you minimize the false positives. You will need to use a BPF filter.

4.9 What are all these ``ICMP destination unreachable'' alerts?

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:

As far as why... ``it all depends...''

ICMP Unreachable Error Messages are divided into two groups:

  1. ICMP Unreachable Error Messages issued by routers (all 16 of them)
  2. 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 arachnids 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:

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.10 Why do many Snort rules have the flags P (TCP PuSH) and A (TCP ACK) set?

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.11 What are these IDS codes in the alert names?

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.

4.12 Snort says BACKDOOR SIGNATURE... does my machine have a Trojan?

If you are dumping the data part of the packet, review it. These rules are known to have high false rates as most of them are just based on numeric port numbers.

4.13 What about ``CGI Null Byte attacks?''

It's a part of the http preprocessor. Basically, if the http decoding routine finds a %00 in an http request, it will alert with this message. Sometimes you may see false positives with sites that use cookies with urlencoded binary data, or if you're scanning port 443 and picking up SSLencrypted traffic . If you're logging alerted packets you can check the actual string that caused the alert. Also, the unicode alert is subject to the same false positives with cookies and SSL. Having the packet dumps is the only way to tell for sure if you have a real attack on your hands, but this is true for any content-based alert.

4.14 Why do certain alerts seem to have `unknown' IPs in ACID?

The Snort database plug-in only logs packet information into the database when an alert is triggered by a rule (signature). Therefore, since alerts generated by pre-preprocessors such as portscan and mini-fragment have no corresponding rules, no packet information is logged beyond an entry indicating their occurance. As a consequence, ACID cannot display any packet-level (e.g. IP address) information for these alerts.

For these particular alerts, certain statistics may show zero unique IP addresses, list the IP address as 'unknown', and will not list any packet information when decoding the alert.

4.15 Can priorities be assigned to alerts using ACID?

The quick answer to this question is no. ACID is at the mercy of the underlying database, since Snort doesn't assign priorities, ACID does not have priorities. Nevertheless, there are several work-arounds:

4.16 What about `SMB Name Wildcard' alerts?

Whitehats IDS177 http://dev.whitehats.com/cgi/test/new.pl/Show?_id=netbios-name-query specifies traffic coming from outside of your local network. Allowing netbios traffic over public networks is usually very insecure.

If the rule you are using also refers to ingres traffic only, then it would explain why you don't see a lot of false positives. For anyone reading that does see a lot of false postiives - if you change your rule to reflect the source address as being !$HOME (or whatever variable you use to represent your internal network), then you should see most of the false positives go away.

The value of this chack is that a default administrative share C$ ADMIN$ or some such has been accessed. This shouldn't happen in normal use - when people want to share files they should be implicitely defining the shares and ACL.

4.17 What the heck is a SYNFIN scan?

SYNFIN scans got their name because there are both the SYN and FIN flags set.

4.18 I am getting too many ``IIS Unicode attack detected'' and/or ``CGI Null Byte attack detected'' false positives. How can I turn this detection off?

These messages are produced by the http_decode preprocessor. If you wish to turn these checks off, add -unicode or -cginull to your http_decode preprocessor line respectively.

preprocessor http_decode: 80 8080 -unicode -cginull

Your own internal users normal surfing can trigger these alerts in the preprocessor. Netscape in particular has been known to trigger them.

Instead of disabling them,try a BPF filter to ignore your outbound http traffic such as:

snort -d -A fast -c snort.conf not (src net xxx.xxx and dst port 80)

This has worked very well for us over a period of 5-6 months and Snort is still very able to decode actual and dangerous cgi null and unicode attacks on our public web servers.

4.19 How do I test Snort alerts and logging?

Try a rule that will fire off all the time like:

alert tcp any any -> any any (msg:"TCP traffic";)

Also take a look at sneeze at http://snort.sourceforge.net/sneeze-1.0.tar Sneeze is a false positive generator that reads snort signatures and generates packets that will trigger the rules.

4.20 What is the difference between ``Alerting'' and ``Logging''?

There are two primary output facilities in Snort, logging and alerting. The alerting facility exists to let you know that something interesting has happened. The logging facility exists to log full packet information to the output format (pcap, ascii, database, etc).

The ``alert'' action in Snort is hard coded to do two things when an event is detected by Snort, write an event to the alert facility and log as much as possible/desired to the output facility. The ``log'' action merely logs the current packet to the logging facility without generating an alert. This is done so you can log interesting things (telnet sessions, whatever) without having to generate an alert on every packet.

The database plugin is something of an anomaly because it doesn't separate the two functionalities very much. The ``log'' option attaches the log facility and the ``alert'' option attaches it to the alert facility. What this means in practical terms is that if the db plugin is in alert mode, it will only receive output from alert rules, whereas if it's in ``log'' mode it will receive output from both log and alert rules.

4.21 Are rule keywords ORed or ANDed together?

>From Section 2.1 of the Snort Manual:

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.

4.22 Can Snort trigger a rule by MAC addresses?

Not exactly. Snort logs MAC addresses and other L2 info within the packets. The arpwatch pre-processor can watch for games with MAC address changes. But there is no facility for triggering Rules form the L2 information. The content search keywords and depth and offset begin from the L3 payload, though we haven't tried playing with really big offsets yet :-).

4.23 How can I deactivate a rule?

Rules can be called from an included file in snort.conf, which tells Snort to follow the path to the rules file specified, and load it at initialization. Rules can also be included in snort.conf directly. If you want to deactivate a single rule within any list of rules, you can use one of these techniques:

  1. Delete the rule and re-initialize Snort
  2. Place a # in front of the rule, commenting it out, and re-initialize Snort
  3. Write a pass rule with the same properties in local.rules (or wherever you prefer), and re-initialize Snort with the -o option.

4.24 How can I define an address to be anything except some hosts?

Use the ! operator. E.g.:

    var EXTERNAL_NET !$HOME_NET
Note that the negation operator does not work inside a list so the following will NOT work:
    var EXTERNAL_NET [!192.168.40.0/24,!10.14.0.0/16]
but this will work:
    var EXTERNAL_NET ![192.168.40.0/24,10.14.0.0/16]

4.25 After I add new rules or comment out rules how do I make Snort reload?

Usually a kill -HUP will work just fine. But if you are running inside of a chroot setup, this will not work as expected (see FAQ [*]). If you're running like inside of a chroot jail, your best bet would be to kill and restart the snort process instead.

4.26 Where do the distance and within keywords work from to modify content searches in rules?

The ``distance'' keyword gives you a relative offset from the end of the last match, so it basically acts as a wildcarding mechanism. You can also use the new ``within'' keyword to limit how deep into the packet from the end of the distance it'll search before it stops.

4.27 How can I specify a list of ports in a rule?

You can't yet. You can specify a range of ports between X and Y with the notation X:Y. See the users manual (http://www.snort.org/docs/writing_rules/chap2.html#tth_sEc2.2.4) for more info on port ranges.

4.28 How can I protect web servers running on ports other than 80?

It is possible... It's a kludge, but it can work. Since the newer rules use the $HTTP_PORTS variable, you simply reset it and re-run the rules for the other ports.

For example:

    var HTTP_PORTS 80
    include web.rules
    var HTTP_PORTS 8080
    include web.rules

4.29 How do I turn off ``spp:possible EVASIVE RST detection'' alerts?

You want to pass the ``disable_evasion_alerts'' argument to stream4 in snort.conf.

4.30 Is there a private SID number range so my rules don't conflict?

Yes. Private SIDs start at 1000000.

4.31 How long can address lists, variables, or rules be?

The Snort parser has an 8K limit on variables and rules after expansion. In practice, this is not a major limitation. :-)

4.32 What do the numbers (ie: [116:56:1]) in front of a Snort alert mean?

For this explanation, we'll use the following example:

[**] [116:56:1] (snort_decoder): T/TCP Detected [**]
The first number is the Generator ID, this tells the user what component of Snort generated this alert. For a list of GIDs, please read etc/generators in the Snort source. In this case, we know that this event came from the ``decode'' (116) component of Snort.

The second number is the Snort ID (sometimes referred to as Signature ID). For a list of preprocessor SIDs, please see etc/gen-msg.map. Rule-based SIDs are written directly into the rules with the ``sid'' option. In this case, ``56'' represents a T/TCP event.

The third number is the revision ID. This number is primarily used when writing signatures, as each rendition of the rule should increment this number with the ``rev'' option.


next up previous
Next: 5 Getting Fancy Up: The Snort FAQ Previous: 3 Configuring Snort
2005-03-21