Some common ones:
ERROR telnet.rules:YYY => Port value missing in rule!
ERROR telnet.rules:YYY => Bad port number: "(msg:"blah"
ERROR telnet.rules:YYY => Couldn't resolve hostname blah
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:
Get rid of the quotes around the IP address and try again.
Your firewall rules will also block traffic to the Snort processes.
Note: This does not apply if Snort is installed on the firewall box.
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.
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.
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.
Most of them are likely destination unreachable and port unreachables that were detected by snort when a communications session attempt fails.
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.
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:
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:
There is also a good ICMP paper on http://www.sys-security.com/
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.
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.
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.
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.
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.
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:
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.
SYNFIN scans got their name because there are both the SYN and FIN flags set.
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.
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.
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.
>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.
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 :-).
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:
Use the ! operator. E.g.:
var EXTERNAL_NET !$HOME_NETNote 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]
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.
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.
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.
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
You want to pass the ``disable_evasion_alerts'' argument to stream4 in snort.conf.
Yes. Private SIDs start at 1000000.
The Snort parser has an 8K limit on variables and rules after expansion. In practice, this is not a major limitation. :-)
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.