This blog post explains how to install, configure, and use Snort. Snort is an intrusion prevention & detection system that acts upon a collection of rules whenever it “sniffs” a packet on your network.

Requirements

For this tutorial, I am using two Virtual Machines (VMs):

  • Kali Linux VM (w/Snort): 192.168.56.5
  • Debian Linux VM: 192.168.56.4

Installation

apt-get install snort

Configuration

First, make a copy of your important files in the event you mess something up.

cp /etc/snort/snort.conf bak.snort.conf
cp /etc/snort/rules/local.rules bak.local.rules

Specifying our ruleset & logging preferences
Find and open your main .conf file using a text-editor (I’m using vim).

vim /etc/snort/snort.conf

My preference is to disable (comment-out) any original configuration settings I intend to change. I then add my changes beneath them (at least whenever I’m modifying a monolithic configuration file like this). For example, comment-out the lines that include HOME_NET and dynamicdetection directory /usr/local/lib/snort_dynamicrules.

# ipvar HOME_NET any
<...snipped...>
# dynamicdetection directory /usr/local/lib/snort_dynamicrules

Then, identify what your HOME_NET will be or rather, the network you want monitored.

# ipvar HOME_NET any
ipvar HOME_NET [192.168.56.0/24]

Ensure the two lines below are enabled (remove any prefacing # symbols if they are disabled). The first line explicitly tells Snort to use our local.rules file when analyzing packets. The second line tells Snort how to communicate with our Syslog daemon. To our Syslog daemon, LOG_AUTH describes our logging facility, or source of events to log, while LOG_ALERT identifies the Severity Level of our logged events. Request For Comments (RFC) document 5424 specifies ALERT as the second, most-high Severity Level for Syslog events.

include $RULE_PATH/local.rules
output alert_syslog: LOG_AUTH LOG_ALERT

Finally, as another option (this is not required to get Snort working), add an entry similiar to the one below. Here, we’re telling Snort to also use its log_tcpdump module which will capture and log packets matching our specified ruleset in a tcpdump format.

# output log_tcpdump: tcpdump.log
output log_tcpdump: /var/log/snort/tcpdump.log

Adding our first rule
Snort rules use the following syntax:

<action> <proto> <src> <src port> <dir> <dst> <dst port> <rule options>

In this tutorial, we’re going to tell Snort to alert us whenever it sniffs icmp packets coming from any network & any port that’s destined for our $HOME_NET (on any port). We also want Snort to log the message “ICMP traffic!” when this condition is met. Lastly, we’re going to identify our rule as sid:3000001. If we want to update it later we can either re-write it, or add a revision number.

vim /etc/snort/rules/local.rule
alert icmp any any -> $HOME_NET any (msg:"ICMP traffic!"; sid:3000001;)

Testing

Before we do any kind of real testing, we need to make sure our logging mechanisms are working.

service --status-all | grep 'rsyslog'
[ + ]  rsyslog # good, our syslog daemon is working

Now, we’ll start Snort, tail one of our log files, and then ping our Kali Linux VM to validate our ruleset.

To make things a little easier to manage, I recommend opening two terminal sessions on your Kali VM: one for Snort, another to watch your log.

Starting Snort
To start Snort, specify the interface attached to your HOME_NET and the location of your configuration file.

snort -i eth0 -c /etc/snort/snort.conf

Tailing our log
In another terminal window on your Kali Linux VM, use tail and grep to watch Snort in action.

tail -f /var/log/auth.log | grep snort

Testing our ruleset

ping 192.168.56.5 # starting a ping on our Debian Linux VM

If everything was properly configured, you should see log entries similar to the one below. If you don’t see anything like this, I recommend checking the log file you’re tailing, your Syslog daemon, your network configuration, and/or your Snort configuration.

<...snipped...>
Dec 20 07:49:12 kali snort: [1:3000001:0] ICMP traffic! {ICMP} 192.168.56.4 -> 192.168.56.5
<...snipped...>

You should also be able to read the tcpdump log Snort created if you enabled this module. For me, my log was identified as tcpdump.log.1545225915. This will be helpful later when we need to dig into what originally triggered Snort.

tcpdump -r /var/log/snort/tcpdump.log.1545225915
reading from file snort/tcpdump.log.1545225915, link-type EN10MB (Ethernet)
08:25:16.469579 IP 192.168.56.4 > kali: ICMP echo request, id 8498, seq 32, length 64
08:25:16.469611 IP kali > 192.168.56.4: ICMP echo reply, id 8498, seq 32, length 64
08:25:17.471011 IP 192.168.56.4 > kali: ICMP echo request, id 8498, seq 33, length 64
08:25:17.471038 IP kali > 192.168.56.4: ICMP echo reply, id 8498, seq 33, length 64
08:25:18.475506 IP 192.168.56.4 > kali: ICMP echo request, id 8498, seq 34, length 64

tl;dr (too long; didn’t read)

Again, the following general steps are required to successfully get Snort up and running:

  • Get Snort installed
  • Edit your main .conf file so it includes your ruleset & logging preferences
  • Add your rule
  • Verify your logging mechanisms are working
  • Tail your log
  • Test your rule
  • Start Snort with minimal parameters
  • Verify your rule was triggered (review your log)
  • Modify/add new rules as desired

References