Carrying Out Statistical Analysis


You want Snort to alert you to behavior on your network that isn't normal.


Use the Spade preprocessor Splug-in.

Download a copy of Spade. Its original creators are no longer around, but as it has been released under the GNU Public License, it is still available and is now being maintained again. Download a copy here:

In the top level of your Snort distribution, uncompress and unpack the Spade distribution by typing the following:

tar xzvf Spade-040223.1.tgz

Change into the Spade distribution directory and make the distribution by typing the following:

cd Spade-040223.1


Compile Snort as normal according to Recipe 1.n.

To get started quickly, copy the lines included in the spade.conf file into your file snort.conf to enable the preprocessor.


Plenty of tools allow you to do statistical analysis of alerts you've already collected. Spade creates an overview of the "normal" behavior of the network based upon observed history. The fewer times a packet of a certain type is seen, the higher its anomaly score. This will very quickly balance out to show the normal behavior of your network (you can also configure Spade to show you what the normal behavior of your network is, which is very useful for capacity planning) and will flash up any "odd" packets. Spade is bright enough not only to spot unusual source and destination ports and IP addresses but also oddly "shaped" packets with odd configurations of flags.

Once you have carried out the installation instructions, you will need to edit your snort.conf file. An example of all the requisite lines for enabling Spade is included in the spade.conf file in the distribution directory.

The following should be added to snort.conf:

preprocessor spade: {=}

You can add any of the options listed in Table 3-5.

Table 3-5. Configuration options for the Spade preprocessor




Specifies the logging file for Spade; if - is specified, stdout is used.


Specifies the state file and stores the probability table between runs. If this file exists, Spade starts from scratch again to build the tables.


Specifies how often the state file is updated with the current state. The file will be updated every n times the state changes. The default is 50,000 changes before the file is written.


This specifies the destination of the messages from Spade. It can be alert, log, or both.


This specifies the location to which messages regarding the updates of the probabilities should be sent. If this isn't specified, the messages go to the source specified in Dest.

You then need to give Spade a bit of an idea about the location of the Snort sensor within the network. You do this by inserting the following line:

preprocessor spade-homenet: [,,...]

You'll need to specify your network using CIDR notation (e.g.,, a specific IP address (e.g.,, or any (which means everything). The any setting is the default if no other line is specified. The spade-homenet setting is unrelated to any Snort options about the home network.

You'll now need to set up some detectors. Detectors are the bits that do the work, somewhat like rules, and allow you to create more targeted statistical analysis of your traffic. The format of a detector line is as follows:

preprocessor spade-detect: {=}

You can use any combination of the options listed in Table 3-6.

Table 3-6. Configuration options for Spade detectors




Indicates the detector type. You can choose from closed-dport, dead-dest, odd_dport, or odd-typecode.


Sets the direction of traffic: home is traffic with destinations in the earlier specified homenet, nothome is everything else, and any is both directions.


Is the same as To, except for the source rather than the destination.


Specifies which protocol the detector is for; can be tcp, udp, or icmp.


Specifies flags that are set for TCP packets. Possible values are synonly, synack, setup, established, teardown, or "weird".


Specifies the type of ICMP packet to look for; can be "err", "noterr", or "all".


Is the initial threshold for packets to be reported based upon their anomaly score.


Are minimum observations: how many packets need to be observed before alerts are sent. This covers the startup of the system, when all packets look like anomalies.


Is the number of seconds that a message is held in the waiting queue before timing out.


Exclude reports from this detector about certain destination IP addresses.


Exclude reports from this detector about certain destination ports.


Exclude reports from this detector about certain source addresses.


Exclude reports from this detector about certain source ports.


Is a label for the detector; must start with a letter, and can contain only alphanumeric characters,- and _.


Causes the conditions for the detection to be reversed, if response waiting is enabled for this detector.


Is how often in minutes the existing observations are decayed in favor of newer observations.


Is the relative weight that should be given to old data at each scalefreq reweighing.


Helps to attain a certain half life for the weight of an item of traffic. It can be created through scalefreq and scalefactor, but is easier to specify as an exact time in seconds.


Is the point below which an item of traffic will be removed from the active dataset.

Each detector type makes use of the other options in slightly different ways; some options are inappropriate for use with a specific detector type.


This detector type looks at TCP and UDP traffic for attempts to connect to closed ports. This is common behavior for port scanners, which attempt to connect to all ports to determine what is open. There is an option to wait for the rejection of the packet before issuing an alert to see whether the port was open, which removes alerts caused through the use of passive FTP. This will create one of three types of alert. Without the response wait option enabled, it gives Rare dest port used. If response waiting is enabled and a RST or ICMP unreachable response is sent, it gives Closed dest port used. Finally, if response waiting is enabled and the port is open, it gives Rare but open dest port used. The normal options are in Table 3-7.

Table 3-7. Configuration options for the closed-dport detector




As normal


tcp or udp only


synonly, synack, established, teardown, and weird available


How long to wait for the response packet


Wait for response



This detector type scans for traffic that is being sent to IP addresses that are not in use. This will detect the typical behavior of network scanners and worms that are unaware of the internal layout of your network. The alert given is Non-live dest used. The normal options are listed in Table 3-8.

Table 3-8. Configuration options for the dead-dest detector




As normal


synonly, synack, established, teardown, and weird available


As normal



This detector type looks for use of ports that differ from the normal usage patterns. This is often a symptom of a compromised host running something new. This can be applied to local or remote sources, and is reported with an alert of Source used odd dest port. The normal options are listed in Table 3-9.

Table 3-9. Configuration options for the odd-dport detector



from, id

As normal


tcp or udp only


How long to wait for a response packet if you specify revwaitrpt


Wait for a response before alerting



This detector looks for anomalous behavior in the way of connections being made to normal ports on unusual machines. For example, if email usually goes to a specific host and this changes suddenly, it may be that the host has been compromised in some way. The alert given is Source used odd dest for port. The normal options are listed in Table 3-10.

Table 3-10. Configuration options for the odd-port-dest detector



from, id

As normal.


tcp and udp only.


This is a measure of the variation that should be expected for the destination IP of a given port. 0 indicates that there should be only one port expected, and increasingly higher numbers indicate an increasingly higher variation.



This detector reports odd ICMP packets on the network. The alert given is Odd ICMP type/code found. The normal options are listed in Table 3-11.

Table 3-11. Configuration options for the odd-typecode detector



To, id

As normal


As normal; defaults to any

The Spade documentation goes into a great deal of depth, both as to the exact options and the mathematics beyond the plug-in. The example cases that are given, spade.conf and spade.more.conf, are well written and clear as to the way that you should make use of Spade.

See Also

Spade User Manual


The ability to customize Snort through the use of rules is one of the program's greatest advantages. This chapter will show you how to build rules that aid Snort in seeking out things specific to your needs. The chapter includes some examples of specific uses of the rules language. The trick to writing effective rules lies in a few tips:

  1. Look for something that's repeated every time the condition occurs. Like GET / or POST / in a web connection.
  2. Try not to make your trigger so general that it fires on every connection.

    alert tcp any any -> any 80 (msg:"port 80 connection!!!"; 
    flow: stateless; rev:1;)
  3. You can use multiple conditions in a single rule for more accurate detection. For example, the following rule looks for a successful compromise of a wu-ftpd server (one of the most common Unix FTP servers that has been known to be plagued by exploits). The rule looks for the client sending the command uname, along with some reference to a /bin directory.

    alert tcp $HOME_NET any -> any 21 (msg:"FTP compromise - success 
    w00t"; content:"uname"; content:"/bin"; flow:from_client, 
    established; rev:1;)

Now let's look at some specific examples of the rules engine and its power in helping defend your network.

Preprocessing An Introduction

Installing Snort from Source on Unix

Logging to a File Quickly

How to Build Rules

Detecting Stateless Attacks and Stream Reassembly

Managing Snort Sensors

Generating Statistical Output from Snort Logs

Monitoring Network Performance


Snort Cookbook
Snort Cookbook
ISBN: 0596007914
EAN: 2147483647
Year: 2006
Pages: 167 © 2008-2020.
If you may any questions please contact us: