I recently fired up a Snort Anomaly Detection instance provided by the SnortAD project and wanted to share my experience for those who might be interested in trying it on your network. SnortAD is the third generation anomaly detection preprocessor for Snort and is a little different than its predecessors but don’t take my word for it, check out their site.

First you need to create a log file based on your network, the log file will contain a profile of your network traffics characteristics. Although a log file has been provided with the SnortAD virtual machine (VM) that contains null entries it will not do you much good aside from alerting on everything. In order to characterize your network, you will need to create a log file with enough data to be statistically relevant. For the impatient, you can create a day or two worth of data and duplicate the data. Duplicating the data will have adverse effects though. Think about a university in which a majority of classes occur on Monday and Wednesday. If you only create a profile for Monday and duplicate it for the rest of the week, you can quickly understand how your results might be skewed.

To get going, use the snort.conf included on SnortAD VM and begin creating a log file but remember to backup or remove the original log file in the event you need it for reference. Also, always backup your configuration files before making changes for good measure.

Configure the snort.conf file to log. Something like the following should work fine:

preprocessor AnomalyDetection: LogPath /var/log/snort log time 60

Next, run Snort to generate log data. As mentioned, you should create enough data to make it statistically relevant. The evaluator script expects three weeks. As an alternate, you might be able to use tcpreplay to replay existing PCAP if you have enough data.

$ sudo /usr/local/bin/snort -c /etc/snort.conf -i eth0

You should start seeing messages to stdout that look like the following:

Loged transfer between 06-01-13 15:33:52 - 06-01-13 15:34:52
Loged transfer between 06-01-13 15:34:52 - 06-01-13 15:35:52

Now you should have a log with a number of entries saved in /var/log/snort. The profile generation script is next run. In this example we specify a week rather than opt for the three week default but again, YMMV and you made need to adjust these values. Also, make sure you check the help of the profile generator as there are other algorithms, five to be specific: Moving average (default), Naive method, Autoregressive time series model, Holt-Winters model, and HW model with Brutlag’s confidence band.

/usr/local/src/profilegenerator/ad_profilegenerator.r -m AVG --avg 'WEEKLY,1' -l Log_Data.txt -p profile.txt -e evaluator.txt -P pattern.txt

The previous command creates the profile.txt file which is a CSV file, i.e. you could respectively name it profile.csv. The CSV file will be used by your updated snort.conf file. In order to enable anomaly detection, we need to download or create a few Snort configuration files:

$ ls -l /etc/snort
total 4200
-rw-r--r--. 1 root root    3621 Jan  5 15:35 classification.config
-rw-r--r--. 1 root root   29596 Jan  5 15:35 gen-msg.map
-rw-r--r--. 1 root root    7897 Jan  5 15:35 preprocessor.rules
-rw-r--r--. 1 root root 1484013 Jan  5 15:35 profile.csv
-rw-r--r--. 1 root root     746 Jan  5 15:35 reference.config
-rw-r--r--. 1 root root 2696705 Jan  5 15:35 sid-msg.map
-rw-r--r--. 1 root root     255 Jan  5 15:35 snort.conf
-rw-r--r--. 1 root root    2556 Jan  5 15:35 threshold.conf
-rw-r--r--. 1 root root   53841 Jan  5 15:35 unicode.map

I found it simplest to pull down the latest Snort signature as they have the additional required files that are not included in the provide SnortAD build. You can pull down the needed preprocessor.rules from one of the authors bitbucket. The snort.conf was populated with the following contents:

include classification.config
include reference.config
include preprocessor.rules
preprocessor AnomalyDetection: ProfilePath /etc/snort/profile.csv LogPath /var/log/snort alert log time 60

If you have everything in the /etc/snort directory, you should be able to run Snort and see alerts when anomalies are detected:

$ sudo /usr/local/bin/snort -c /etc/snort/snort.conf -i eth0

Here are some sample alerts from some early testing. It will probably take some tuning to begin seeing useful alerts:

[**] [1000100:1000101:1] AD_UNUSUALLY_HIGH_TCP_TRAFFIC [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000107:1] AD_HIGH_LAN_TCP_TRAFFIC [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000108:1] AD_UNUSUALLY_LOW_UDP_TRAFFIC [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000114:1] AD_LOW_LAN_UDP_TRAFFIC [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000134:1] AD_LOW_ARP_REQUEST_NUMBER [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000138:1] AD_LOW_NOT_TCP_IP_TRAFFIC [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

[**] [1000100:1000140:1] AD_LOW_OVERALL_PACKET_NUMBER [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
01/06-20:59:04.308505 10.0.0.116 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:30537   Seq:1  ECHO

If you have any questions, leave a comment and/or check out the authors Readme.txt for some additional usage insight.