Carrying Out Statistical Analysis

Problem

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

Solution

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: http://www.computersecurityonline.com/spade/.

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

make

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.

Discussion

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

Option	Action
Logfile	Specifies the logging file for Spade; if - is specified, stdout is used.
Statefile	Specifies the state file and stores the probability table between runs. If this file exists, Spade starts from scratch again to build the tables.
Cpfreq	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.
Dest	This specifies the destination of the messages from Spade. It can be alert, log, or both.
Adjdest	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., 192.168.0.0/24), a specific IP address (e.g., 192.168.0.8), 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

Option	Action
Type	Indicates the detector type. You can choose from closed-dport, dead-dest, odd_dport, or odd-typecode.
To	Sets the direction of traffic: home is traffic with destinations in the earlier specified homenet, nothome is everything else, and any is both directions.
From	Is the same as To, except for the source rather than the destination.
Proto	Specifies which protocol the detector is for; can be tcp, udp, or icmp.
Tcpflags	Specifies flags that are set for TCP packets. Possible values are synonly, synack, setup, established, teardown, or "weird".
Icmptype	Specifies the type of ICMP packet to look for; can be "err", "noterr", or "all".
Thresh	Is the initial threshold for packets to be reported based upon their anomaly score.
Minobs	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.
Wait	Is the number of seconds that a message is held in the waiting queue before timing out.
Xdips	Exclude reports from this detector about certain destination IP addresses.
Xdports	Exclude reports from this detector about certain destination ports.
Xsips	Exclude reports from this detector about certain source addresses.
Xsports	Exclude reports from this detector about certain source ports.
Id	Is a label for the detector; must start with a letter, and can contain only alphanumeric characters,- and _.
Revwaitrpt	Causes the conditions for the detection to be reversed, if response waiting is enabled for this detector.
Scalefreq	Is how often in minutes the existing observations are decayed in favor of newer observations.
Scalefactor	Is the relative weight that should be given to old data at each scalefreq reweighing.
Scalehalflife	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.
Scalecutoff	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.

closed-dport

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

Option	Action
to,id	As normal
Protocol	tcp or udp only
Tcpflags	synonly, synack, established, teardown, and weird available
Wait	How long to wait for the response packet
Revwaitrpt	Wait for response

 

dead-dest

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

Option	Action
to,id	As normal
Tcpflags	synonly, synack, established, teardown, and weird available
Icmptype	As normal

 

odd-dport

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

Option	Action
from, id	As normal
Protocol	tcp or udp only
Wait	How long to wait for a response packet if you specify revwaitrpt
Revwaitrpt	Wait for a response before alerting

 

odd-port-dest

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

Option	Action
from, id	As normal.
Protocol	tcp and udp only.
Maxentropy	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.

 

odd-typecode

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

Option	Action
To, id	As normal
Icmptype	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

Introduction

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