Snort 2.9.1 on CentOS 6.0

This tutorial demonstrates a Snort 2.9.1 installation on CentOS 6.0 32-bit using Emerging Threats community rules. These rules will be automatically configured and updated by Oinkmaster.

It is important to note that Snort will be installed from RPMs, and not from source. There are also many tutorials on the web that cover a Snort installation from source in addition to MySQL, Apache2, and Barnyard to support the BASE front-end. This can be a very daunting and discouraging task to first-time Snort users. This tutorial, however, is not another one of those.

I try to reduce the overall complexity of learning Snort by showing a very simple setup to help those first-time Snort users get "their feet wet".

Bridging interfaces

In this setup Snort will be placed inline between a cable modem and home router.

To use Snort inline, two separate interfaces (eth0 and eth1) will need to be bridged as a single interface (br0). Using a bridge interface will allow Snort to transparently inspect all traffic passing in and out of the network.

Configure /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
BRIDGE=br0
NM_CONTROLLED=no
USERCTL=no
ONBOOT=yes
BOOTPROTO=none

Configure /etc/sysconfig/network-scripts/ifcfg-eth1:

DEVICE=eth1
BRIDGE=br0
NM_CONTROLLED=no
USERCTL=no
ONBOOT=yes
BOOTPROTO=none

Now create /etc/sysconfig/network-scripts/ifcfg-br0:

DEVICE=br0
TYPE=Bridge
NM_CONTROLLED=no
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
DELAY=0

Restart the networking service:

# service networking restart

Installing Snort

Download the snort-2.9.1-1.F13.i386.rpm RPM from the Vincent Cojot unofficial Snort repository:

# wget http://vscojot.free.fr/dist/snort/snort-2.9.1/RHEL6/i386/snort-2.9.1-14.el6.i686.rpm

• Although considered "third party" RPMs, installation is a much smoother process with them.
• See http://blog.snort.org/2011/01/rpms-for-rhel5-are-available-from.html for more information.

Download and install the following dependencies needed by Snort 2.9.1 from the Vincent Cojot repository:

• libdnet
• libpcap library version 1.1.1
• Data Acquisiion Library

# wget http://vscojot.free.fr/dist/snort/snort-2.9.1/RHEL6/i386/libdnet-1.12-7.el6.i686.rpm
# wget http://vscojot.free.fr/dist/snort/snort-2.9.1/RHEL6/i386/libpcap1-1.1.1-10.el6.i686.rpm
# wget http://vscojot.free.fr/dist/snort/snort-2.9.1/RHEL6/i386/daq-0.6.1-10.el6.i686.rpm
# rpm -Uvh libdnet-1.12-7.el6.i686.rpm libpcap1-1.1.1-10.el6.i686.rpm daq-0.6.1-10.el6.i686.rpm

After all dependency packages have been installed, install the Snort RPM:

# rpm -Uvh snort-2.9.1-14.el6.i686.rpm

• This will automatically create the Snort user and group, startup scripts, and setup the correct directories and paths.

Edit /etc/snort/snort.conf:

• Configure the HOME_NET variable with your public IP address. If using Snort behind a router, configure HOME_NET with your internal network address, e.g. 192.168.1.0/24.
• Define the RULE_PATH. The SO_RULE_PATH and PREPROC_RULE_PATH can be safely commented out as they are not used by the Emerging Threat rulesets.
• Configure the unified2 output, change the filename from merged.log to snort.log and remove the additional options.

# Setup the network addresses you are protecting
#ipvar HOME_NET any
ipvar HOME_NET 1.2.3.4/32

# Path to your rules files (this can be a relative path)
# Note for Windows users:  You are advised to make this an absolute path,
# such as:  c:\snort\rules
#var RULE_PATH ../rules
#var SO_RULE_PATH ../so_rules
#var PREPROC_RULE_PATH ../preproc_rules
var RULE_PATH /etc/snort/rules

# output unified2: filename merged.log, limit 128, nostamp, mpls_event_types, vlan_event_types
output unified2: filename snort.log, limit 128

Verify that Snort will start with the following command:

# snort -c /etc/snort/snort.conf -i br0

• -c denotes the configuration file.
• -i denotes the interface to listen on.

Although no rules have been loaded yet, Snort should display a similar message if everything is configured correctly so far:

        --== Initialization Complete ==--

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.9.1 IPv6 GRE (Build 71) 
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
           Copyright (C) 1998-2011 Sourcefire, Inc., et al.
           Using libpcap version 1.1.1
           Using PCRE version: 7.8 2008-09-05
           Using ZLIB version: 1.2.3

           Rules Engine: SF_SNORT_DETECTION_ENGINE  Version 1.15  
           Preprocessor Object: SF_SIP (IPV6)  Version 1.1  
           Preprocessor Object: SF_FTPTELNET (IPV6)  Version 1.2  
           Preprocessor Object: SF_DCERPC2 (IPV6)  Version 1.0  
           Preprocessor Object: SF_DNS (IPV6)  Version 1.1  
           Preprocessor Object: SF_SDF (IPV6)  Version 1.1  
           Preprocessor Object: SF_SMTP (IPV6)  Version 1.1  
           Preprocessor Object: SF_REPUTATION (IPV6)  Version 1.1  
           Preprocessor Object: SF_IMAP (IPV6)  Version 1.0  
           Preprocessor Object: SF_SSH (IPV6)  Version 1.1  
           Preprocessor Object: SF_POP (IPV6)  Version 1.0  
           Preprocessor Object: SF_SSLPP (IPV6)  Version 1.1  
Commencing packet processing (pid=10957)

Oinkmaster and Emerging Threats rules

Emerging Threats is a fantastic community-driven project that provides free Snort rules for both personal and commercial use. They update their rulesets on a daily basis and even provide a commercial subscription with support, known as Emerging Threats Pro. See also ruleset comparison.

Oinkmaster is a simple perl script with accompanying .conf file that allows for that automatic configuration and management of Snort rules.

In a real-production network, not all Snort rules will be used, and certain rules may be disabled. When manually downloading and updating the newest rules, rules that have been disabled may be re-enabled again during the manual update process. Oinkmaster simplifies management of rules by allowing an administrator to keep track of which rules are disabled or enabled by default during an update as well as any other additional files to ignore.

Download the Oinkmaster tar archive from http://oinkmaster.sourceforge.net/download.shtml and extract:

# gunzip oinkmaster-2.0.tar.gz
# tar xvf oinkmaster-2.0.tar

The following files will be extracted to the current working directory:

oinkmaster-2.0
oinkmaster-2.0/README.templates
oinkmaster-2.0/oinkmaster.pl
oinkmaster-2.0/FAQ
oinkmaster-2.0/UPGRADING
oinkmaster-2.0/README
oinkmaster-2.0/README.win32
oinkmaster-2.0/README.gui
oinkmaster-2.0/LICENSE
oinkmaster-2.0/INSTALL
oinkmaster-2.0/ChangeLog
oinkmaster-2.0/oinkmaster.1
oinkmaster-2.0/template-examples.conf
oinkmaster-2.0/oinkmaster.conf
oinkmaster-2.0/contrib
oinkmaster-2.0/contrib/create-sidmap.pl
oinkmaster-2.0/contrib/addsid.pl
oinkmaster-2.0/contrib/makesidex.pl
oinkmaster-2.0/contrib/addmsg.pl
oinkmaster-2.0/contrib/README.contrib
oinkmaster-2.0/contrib/oinkgui.pl

Change into the oinkmaster-2.0/ directory and edit the oinkmaster.conf file.

Edit oinkmaster-2.0/oinkmaster.conf:

• Add the url to the Emerging Threat rules Snort 2.9.0 rules. (2.9.0 rules are compatible with 2.9.1)
• Set the tmpdir to /tmp.

# Example for Community rules
# url = http://www.snort.org/pub-bin/downloads.cgi/Download/comm_rules/Community-Rules.tar.gz

# Example for rules from the Bleeding Snort project
# url = http://www.bleedingsnort.com/bleeding.rules.tar.gz

# Emerging Threats
url = http://rules.emergingthreats.net/open/snort-2.9.0/emerging.rules.tar.gz

# Example for UNIX.
# tmpdir = /home/oinkmaster/tmp/
tmpdir = /tmp

Create a directory to backup old rules when Oinkmaster updates rules:

# mkdir /tmp/rules.old

Run the Oinkmaster perl script for the first time:

# oinkmaster.pl -o /etc/snort/rules/ -b /tmp/rules.old -C oinkmaster.conf

• -o outputs the downloaded rules to the specified directory
• -b defines where to backup old rules
• -C defines which configuration file to use.
• NOTE: oinkmaster.pl uses the wget utility, install it if it is not present on the system.

Output from above command:

# ./oinkmaster.pl -o /etc/snort/rules/ -b /tmp/rules.old -C oinkmaster.conf
Loading /root/oinkmaster-2.0/oinkmaster.conf
Downloading file from http://rules.emergingthreats.net/open/snort-2.9.0/emerging.rules.tar.gz... done.
Archive successfully downloaded, unpacking... done.
Setting up rules structures... done.
Processing downloaded rules... disabled 0, enabled 0, modified 0, total=15999
Setting up rules structures... done.
Comparing new files to the old ones... done.
Updating local rules files... done.

[***] Results from Oinkmaster started 20110915 20:06:35 [***]

[*] Rules modifications: [*]
    None.

[*] Non-rule line modifications: [*]
    None.

[+] Added files (consider updating your snort.conf to include them if needed): [+]

    -> BSD-License.txt
    -> classification.config
    -> compromised-ips.txt
    -> emerging.conf
    -> emerging-activex.rules
    -> emerging-attack_response.rules
    -> emerging-botcc.rules
    -> emerging-chat.rules
    -> emerging-ciarmy.rules
    -> emerging-compromised.rules
    -> emerging-current_events.rules
    -> emerging-deleted.rules
    -> emerging-dns.rules
    -> emerging-dos.rules
    -> emerging-drop.rules
    -> emerging-dshield.rules
    -> emerging-exploit.rules
    -> emerging-ftp.rules
    -> emerging-games.rules
    -> emerging-icmp.rules
    -> emerging-icmp_info.rules
    -> emerging-imap.rules
    -> emerging-inappropriate.rules
    -> emerging-malware.rules
    -> emerging-misc.rules
    -> emerging-mobile_malware.rules
    -> emerging-netbios.rules
    -> emerging-p2p.rules
    -> emerging-policy.rules
    -> emerging-pop3.rules
    -> emerging-rbn-malvertisers.rules
    -> emerging-rbn.rules
    -> emerging-rpc.rules
    -> emerging-scada.rules
    -> emerging-scan.rules
    -> emerging-shellcode.rules
    -> emerging-smtp.rules
    -> emerging-snmp.rules
    -> emerging-sql.rules
    -> emerging-telnet.rules
    -> emerging-tftp.rules
    -> emerging-tor.rules
    -> emerging-trojan.rules
    -> emerging-user_agents.rules
    -> emerging-virus.rules
    -> emerging-voip.rules
    -> emerging-web_client.rules
    -> emerging-web_server.rules
    -> emerging-web_specific_apps.rules
    -> emerging-worm.rules
    -> gen-msg.map
    -> gpl-2.0.txt
    -> rbn-ips.txt
    -> rbn-malvertisers-ips.txt
    -> reference.config
    -> sid-msg.map
    -> snort-2.9.0-open.txt
    -> unicode.map

Edit /etc/snort/snort.conf:

• Now add the emerging.conf configuration file as an include.

###################################################
# Step #7: Customize your rule set
# For more information, see Snort Manual, Writing Snort Rules
#
# NOTE: All categories are enabled in this conf file
###################################################

# Emerging Threats rules
include $RULE_PATH/emerging.conf

By default /etc/snort/rules/emerging.conf has all rule groups commented out, and they must be enabled manually.

Edit /etc/snort/rules/emerging.conf to enable specific Emerging Threats rules:

• Ensure classification.config and reference.config are uncommented!
• Note do not enable all rules, you should enable rules relevant to your environment.
• As an example I enabled the rules shown below.

include $RULE_PATH/classification.config
include $RULE_PATH/reference.config

include $RULE_PATH/emerging-policy.rules
include $RULE_PATH/emerging-games.rules
include $RULE_PATH/emerging-virus.rules
include $RULE_PATH/emerging-attack_response.rules
include $RULE_PATH/emerging-icmp.rules
include $RULE_PATH/emerging-scan.rules
include $RULE_PATH/emerging-chat.rulesles
include $RULE_PATH/emerging-shellcode.rules
include $RULE_PATH/emerging-current_events.rules
include $RULE_PATH/emerging-malware.rules
include $RULE_PATH/emerging-worm.rules
include $RULE_PATH/emerging-misc.rules
include $RULE_PATH/emerging-exploit.rules
include $RULE_PATH/emerging-p2p.rules
include $RULE_PATH/emerging-mobile_malware.rules

include $RULE_PATH/emerging-botcc.rules
include $RULE_PATH/emerging-compromised.ruless
include $RULE_PATH/emerging-drop.rulesK.rules
include $RULE_PATH/emerging-dshield.rules
include $RULE_PATH/emerging-rbn.rules
include $RULE_PATH/emerging-rbn-malvertisers.rules

Take time to go through each file to determine whether or not to use the rulesets provided by Emerging Threats. Again, not all will be relevant to your environment.

Because we edited /etc/snort/rules/emerging.conf, we need to ensure that it is not accidentally "updated" or overwritten by Oinkmaster. Remember, Oinkmaster outputs to and updates the /etc/snort/rules directory.

Edit oinkmaster-2.0/oinkmaster.conf again:

#######################################################################
# Files to totally skip (i.e. never update or check for changes)      #
#                                                                     #
# Syntax: skipfile filename                                           #
# or:     skipfile filename1, filename2, filename3, ...               #
#######################################################################

# Do not modify or update emerging.conf
skipfile emerging.conf

NOTE: You can optionally ignore the rulesets that are commented out as well, i.e. skipfile emerging-tor.rules,emerging-sql etc.

Now anytime you need to update your Snort rules, simply run the ./oinkmaster.pl -o /etc/snort/rules/ -b /tmp/rules.old -C oinkmaster.conf command. It is recommended to put this command in a daily cron job, as Emerging Threats updates their rules on a daily basis.

Running Snort

Finally, run Snort in the foreground with the following command:

# snort -c /etc/snort/snort.conf -A fast -b -i br0

• -A specifies the alert mode.
• -b will log packets that were alerted on in tcpdump format.
• -i specifies what interface to listen on.

Alerts will be logged to /var/log/snort/alert, if using the fast alert mode, alerts will appear as a single line.

Example output of /var/log/snort/alert using Snort alert-mode fast:

09/15-20:55:08.642022  [**] [1:2012141:2] ET POLICY Protocol 41 IPv6 encapsulation potential 6in4 IPv6 tunnel active [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {IPV6-ICMP} fe80:0000:0000:0000:0000:5efe:c0a8:0bf1 -> fe80:0000:0000:0000:0000:5efe:181c:c109
09/15-21:01:55.234549  [**] [1:2003089:4] ET GAMES STEAM Connection (v2) [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 1.2.3.4:49158 -> 68.142.72.250:27031
09/15-21:02:22.628590  [**] [1:2012170:2] ET GAMES Blizzard Web Downloader Install Detected [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 1.2.3.4:49196 -> 12.129.206.133:1119

I recommend running Snort for at least a day or two, you are guaranteed to see several alerts especially if your sensor is facing an external public network.

Tuning alerts

After running Snort for a period of time, even for a day or two as previously mentioned, you can quickly get a baseline of the alerts on your network. Some of these alerts can occur quite frequently and may unnecessarily flood your log file. Ideally you want to reduce the amount of "noise" in the alert log file. Tuning your alerts either by disabling the rule signature entirely, or suppressing them using the threshold.conf file is one of the many best practices in maintaining and optimizing Snort.

Disabling an alert

For example, on my development sensor I saw several of the following alerts:

09/16-17:39:08.567824  [**] [1:2012170:2] ET GAMES Blizzard Web Downloader Install Detected [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 1.2.3.4:54741 -> 173.223.52.219:80
09/16-17:39:08.677677  [**] [1:2012170:2] ET GAMES Blizzard Web Downloader Install Detected [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 1.2.3.4:54741 -> 173.223.52.219:80
09/16-17:39:13.197098  [**] [1:2012170:2] ET GAMES Blizzard Web Downloader Install Detected [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 1.2.3.4:54742 -> 12.129.242.21:80

As seen above, Snort detected a Blizzard Web Downloader which was triggered from a desktop running World of Warcraft within my network. If this were a corporate network, company policy would likely dictate that employees should not be playing games during work. However, because this development Snort sensor is on my home network, this alert is completely harmless and therefore can simply be disabled.

The signature or rule ID that triggered the above alert is 2012170. The 2 denotes that this is the second revision of the rule.

Using grep to search for 2012170 within the /etc/snort/rules directory, the file that contains the rule can be found:

# cd /etc/snort/rules
# grep -n 2012170 *

emerging-games.rules:326:alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET GAMES Blizzard Web Downloader Install Detected"; flow: established,to_server; content: "User-Agent|3a| Blizzard Web Client"; nocase; classtype:policy-violation; sid:2012170; rev:2;)
sid-msg.map:11036:2012170 || ET GAMES Blizzard Web Downloader Install Detected

The command found the rule in emerging-games.rules on line 326. To disable the rule, simply comment it out with #, like so:

#emerging-games.rules:326:alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET GAMES Blizzard Web Downloader Install Detected"; flow: established,to_server; content: "User-Agent|3a| Blizzard Web Client"; nocase; classtype:policy-violation; sid:2012170; rev:2;)

Restart Snort and the rule ID will no longer trigger an alert to the /var/log/snort/alert log file.

IMPORTANT: The oinkmaster.conf still needs to be configured to ensure that the above rule we disabled stays disabled during an update.

Edit your oinkmaster.conf:

• Use a disablesid statement to disable the rule.

########################################################################
# SIDs to comment out, i.e. disable, after each update by placing a    #
# '#' in front of the rule (if it's a multi-line rule, it will be put  #
# in front of all lines).                                              #
#                                                                      #
# Syntax:  disablesid SID                                              #
# or:      disablesid SID1, SID2, SID3, ...                            #
########################################################################

disablesid 2012170 # ET GAMES Blizzard Web Downloader Install Detected

The configuration file allows for comments to be appended to the disablesid parameter. For reference, putting the description of the rule, or why the rule is being disabled is strongly recommended.

Now, during an Oinkmaster update the above signature will stay disabled.

Suppressing an alert

There may be scenarios, where you do not want to disable a rule entirely, but rather configure it so that it does not alert on specific factors, such as source or destination IP addresses.

Take for instance the following alerts that were lightly flooding my alert file:

09/16-12:20:43.317651  [**] [1:1390:6] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable Code was Detected] [Priority: 1] {TCP} 74.125.239.6:80 -> 1.2.3.4:54066
09/16-12:20:43.329227  [**] [1:1390:6] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable Code was Detected] [Priority: 1] {TCP} 74.125.239.9:80 -> 1.2.3.4:54229
09/16-12:20:43.365007  [**] [1:1390:6] GPL SHELLCODE x86 inc ebx NOOP [**] [Classification: Executable Code was Detected] [Priority: 1] {TCP} 74.125.224.170:80 -> 1.2.3.4:54222

Resolving the above IP addresses shows that they actually belong to Google:

# for i in 74.125.239.6 74.125.239.9 74.125.224.170; do whois -h asn.shadowserver.org origin $i; done
[Querying asn.shadowserver.org]
[asn.shadowserver.org]
15169 | 74.125.239.0/24 | GOOGLE | US | GOOGLE.COM | GOOGLE INC
[Querying asn.shadowserver.org]
[asn.shadowserver.org]
15169 | 74.125.239.0/24 | GOOGLE | US | GOOGLE.COM | GOOGLE INC
[Querying asn.shadowserver.org]
[asn.shadowserver.org]
15169 | 74.125.224.0/24 | GOOGLE | US | GOOGLE.COM | GOOGLE INC

After further investigation it is safe to assume that the alerts were false positives. Optionally the triggering rule can be disabled, as shown in the previous example above, however, doing so would allow any IP address meeting the requirements to alert signature ID 1390 to pass through the network undetected. The correct way to tune the alert is to ignore only if it originates from Google, which can be done using the /etc/snort/threshold.conf file.

Configure /etc/snort/threshold.conf to ignore alerts from signature ID 1390 if it originates from Google's networks:

# Suppression:
#
# Suppression commands are standalone commands that reference generators and
# sids and IP addresses via a CIDR block (or IP list). This allows a rule to be
# completely suppressed, or suppressed when the causitive traffic is going to
# or comming from a specific IP or group of IP addresses.
#
# Suppress this event completely:
#
# suppress gen_id 1, sig_id 1852
#
# Suppress this event from this IP:
#
# suppress gen_id 1, sig_id 1852, track by_src, ip 10.1.1.54
#
# Suppress this event to this CIDR block:
#
# suppress gen_id 1, sig_id 1852, track by_dst, ip 10.1.1.0/24
#

# Suppress [1:1390:6] GPL SHELLCODE x86 inc ebx NOOP [**] if originating from Google's networks.
suppress gen_id 1, sig_id 1390, track by_src, ip 74.125.0.0/16

The Snort developers were kind enough to provide different examples in thethreshold.conf file.

Lastly, restart Snort and the the signature ID will only alert on non-Google networks.

Nothing needs to be changed on the Oinkmaster side, as no rule was explicitly being disabled or enabled. Suppression is handled by threshold.conf which is outside of the /etc/snort/rules directory that Oinkmaster "tracks".

Resources

Snort Official Documention: http://www.snort.org/docs
Emerging Threats Rule Documentation Wiki: http://doc.emergingthreats.net/