Snort Tutorial and Practical Examples

Introduction to Snort

Snort is widely used by Blue Teams protecting networks of all sizes and is considered a robust part of network security infrastructure. Cisco purchased the snort project in 2013 and incorporated it in its Sourcefire line of products. The core snort software remains open source with a GPL2+ license.

Common Use Cases for Snort

Snort can be used in a variety of scenarios to protect networks from cyber threats. Some practical use cases for Snort include:

Detecting and blocking network attacks

Snort can be used to detect and block network-based attacks, such as denial of service (DoS) attacks, SQL injection or network service attacks such as the well known ETERNALBLUE exploit. Snort will analyze network traffic in real-time, alerting and potentially taking action to prevent the attack from succeeding.

Monitoring network traffic for suspicious activity

Snort can be used to monitor network traffic for any suspicious activity, such as an unusually high amount of traffic; think multiple Microsoft Remote Desktop (RDP) logins or High number of HTTP POST requests. This can help identify potential security threats allowing the network administrator assess a potential incident.

Detecting and blocking malware

Snort can be configured to use a set of rules that are designed to detect known implants or malware signatures. Common examples would be Cobal Strike (installer / C2 traffic) and the Metasploit based Meterpreter. When malware is detected, Snort can alert the network administrator or trigger actions to mitigate damage from the malware.

These are the most common use cases for a snort deployment. It should be kept in mind that due to the ability to create custom rules, the possibilities for what Snort can monitor and alert on is endless.

Installing Snort 2.9 on Ubuntu

In order to get started with Snort easily, we recommend starting with Snort 2.9 which is available in the Ubuntu 22.04 repositories. Installation is a simple matter of the standard apt-get install.

:-$ sudo apt install snort

Using this method ensures you have a production ready version that is easy to maintain and update when required through the standard update processes.

:-$ snort --version

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.9.15.1 GRE (Build 15125) 
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/contact#team
           Copyright (C) 2014-2019 Cisco and/or its affiliates. All rights reserved.
           Copyright (C) 1998-2013 Sourcefire, Inc., et al.
           Using libpcap version 1.10.1 (with TPACKET_V3)
           Using PCRE version: 8.39 2016-06-14
           Using ZLIB version: 1.2.11

Snort 3 with Docker

Using the Cisco Talos docker container is the fastest way to get Snort 3 up and running. Primarily suited for initial testing, the docker container has a full snort installation and can be used to quickly process a network capture (pcap) within a few minutes.

Snort 3 comes with a number of new capabilities and features. Jump in with the following docker commands.

:-$ sudo docker pull ciscotalos/snort3
:-$ sudo docker run --name snort3 -h snort3 -u snorty -w /home/snorty -d -it ciscotalos/snort3 bash
:-$ sudo docker exec -it snort3 bash

Installing Snort 3 on Ubuntu

As snort 3 does not come as packaged binaries it is necessary to install from source to deploy on Ubuntu.

The full installation guide is available from the snort.org website. Specifically for Ubuntu deployments you will need the following required packages.

:-$ sudo apt install build-essential libpcap-dev libpcre3-dev libnet1-dev zlib1g-dev luajit hwloc libdnet-dev \
libdumbnet-dev bison flex liblzma-dev openssl libssl-dev pkg-config libhwloc-dev cmake cpputest libsqlite3-dev uuid-dev \
libcmocka-dev libnetfilter-queue-dev libmnl-dev autotools-dev libluajit-5.1-dev libunwind-dev libfl-dev

Getting the Rules

The rules can be downloaded from snort.org and are available as the Community Rule set, as well as the official Cisco rules. The official rules require a free registration (30 day delay) or a paid subscription for immediate access to newly released rules.

While the community rules are an excellent resource the official rules are essential for getting good coverage and registration or a subscription should be done.

In addition there are excellent rules available from Emerging Threats (Proofpoint) with the option of Free or a Paid for offering.

Oinkcodes - Automate Rule Downloads

The Oinkcode is an API key associated with a registered account. Using the oinkcode you are able to access the rule updates programatically using a tool such as Pulled Pork.

Working Snort 3 Installation

Whichever version or method you are using running the following confirms that snort is installed and ready to go:

snorty@snort3:~$ snort --version

   ,,_     -*> Snort++ <*-
  o"  )~   Version 3.0.0 (Build 267)
   ''''    By Martin Roesch & The Snort Team
           http://snort.org/contact#team
           Copyright (C) 2014-2019 Cisco and/or its affiliates. All rights reserved.
           Copyright (C) 1998-2013 Sourcefire, Inc., et al.
           Using DAQ version 3.0.0
           Using LuaJIT version 2.1.0-beta3
           Using OpenSSL 1.1.1d  10 Sep 2019
           Using libpcap version 1.8.1
           Using PCRE version 8.39 2016-06-14
           Using ZLIB version 1.2.11
           Using Hyperscan version 5.1.0 2019-01-31
           Using LZMA version 5.2.4

snorty@snort3:~$ 

Practical Examples

These examples show a number of practical uses for snort as a command line tool and demonstrates how the system works in a hands on capacity.

1. Capture on Local Interface with Snort

In this mode, Snort reads packets from the network interface and compares them to the set of rules specified in the configuration file.

:~$ snort -c /etc/snort/snort.conf -i eth0

2. Analyse Packets from a PCAP File

You can use Snort to read packets from a PCAP file.

:~$ snort -r file.pcap -c /etc/snort/snort.conf

3. Test Snort Configuration File

This command tests your Snort configuration and rules for errors.

:~$ snort -T -c /etc/snort/snort.conf

4. Log Traffic to a pcap File

Output options are configured in the snort.conf file. Logging to pcap can be configured in the file or we can use the command line option below to write the pcap.

Read packets from the configured network interface and write to a pcap file.

:~$ snort -b -L packets.pcap

5. A simple test rule to ensure Snort is working as expected

To test everything is working and to understand how the alerting / logging works lets create a simple rule that we can trigger at any time.

Edit the file /etc/snort/rules/local.rules and put the following line at the end.

alert icmp any any -> any any (msg:"ICMP connection attempt"; sid:1000010; rev:1;)

This rule will detect any use of the icmp protocol (second entry in rule). That matches the source / dest (any -> any variable), and will then use the msg: as the alert text.

The following example is a bit different to previous. It says to print the alerts to the console (-A console) and uses the (-q) parameter to be quiet. Stopping the debugging and startup information from appearing and providing clean output. We can specify the local.rules file as the config or the snort.conf (as it should be including the local.rules file).

:~$ snort -q -A console -c /etc/snort/local.rules

If you ping the host or network that is listening you should see the alerts printed to the console.

05/25-10:50:00.887913  [**] [1:1000002:1] ICMP connection attempt [**] [Priority: 0] {ICMP} 10.1.1.33 -> 10.1.1.44
05/25-10:50:00.888003  [**] [1:1000002:1] ICMP connection attempt [**] [Priority: 0] {ICMP} 10.1.1.44 -> 10.1.1.33

6. Reject and Drop Rules

Using our previous test rule for icmp we are able to demonstrate the drop and reject options for rules. To demostrate we will simply replace the alert with reject. The sid will also be incremented otherwise there will be an error when starting with two rules with the same sid.

reject icmp any any -> $HOME_NET any (msg:"ICMP connection attempt"; sid:1000011; rev:1;)

Restarting snort and running the same ping -c 2 10.1.1.44 we will receieve the following output:

:~$ ping -c 2 10.1.1.44
PING 10.1.1.44 (10.1.1.44) 56(84) bytes of data.
64 bytes from 10.1.1.44: icmp_seq=1 ttl=64 time=1.25 ms
From 10.1.1.44 icmp_seq=1 Destination Port Unreachable

The first packet gets a response, however the subsequent packet is rejected with an icmp port unreachable.

The rule options are available here -> http://manual.snort.org/node29.html

Using the reject option causes snort to send a TCP reset or an ICMP port unreachable packet, that will break the session. Using drop and sdrop will only work if Snort is running inline as it does as advertised and simply will drop the packets in this mode.

7. Filtering on the Command Line with BPF

Similar to tcpdump we can provide BPF filters on the command line to limit the traffic we are inspecting and capturing. The following example limits captured traffic to a single host, that can be the source or destination.

:~$ snort -q -A console -c /etc/snort/snort.conf host 10.1.1.33

8. Enable app-detect.rules and Know the Network

After copying the official rules into the /etc/snort/rules/, quite a lot of rules are actually disabled. This is due to the fact that the default configuration is trying to balance alert noise vs coverage. It is up to the administrator to enable many of the rules.

An interesting set of rules to look at when getting started is the app-detect.rules these detect many types of application on the network - many of those that have remote control features often used by attackers but also legitimitaly.

:~$ sudo grep app-detect /etc/snort/snort.conf 
#include $RULE_PATH/app-detect.rules

Firstly the configuration file has the rule file disabled. Furthermore the app-detect.rules rules are disabled by default.

# alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"APP-DETECT VNC server response"; flow:established; content:"RFB 0"; depth:5; content:".0"; depth:2; offset:7; metadata:ruleset community; classtype:misc-activity; sid:560; rev:9;)

This is an interesting rule, VNC is an application that allows GUI access to a console. While VNC can be used by administrators it is also used by attackers. An example is the payloads for VNC found within Metasploit.

So this is an example of the app-detect.rules that we want to enable by removing the '#' from the start of the line.

9. Enable malware rules

Another set of rules that are disabled by default in the Ubuntu package are the malware-rules. We want to enable these as they will provide coverage of attacker favorites such as Cobalt Strike beacons or installers.

:~$ sudo grep malware /etc/snort/snort.conf 
#include $RULE_PATH/malware-backdoor.rules
#include $RULE_PATH/malware-cnc.rules
#include $RULE_PATH/malware-other.rules
#include $RULE_PATH/malware-tools.rules

Remove the comment from the start of these lines to enable the use of the malware rules.

These rules contain detections for interesting tools such as Cobalt Strike and Meterpreter. If these are triggering on the internal network you will certainly want to know about it.

Conclusion

Snort has been around for 25 years and is still a powerful and effective tool for those who defend networks from threats. The above tutorial and examples are not intended to cover everything but to give you a practical starting point from which to build up your Snort skillset and build some key knowledge for when planning a deployment.

Even if you do not plan on throwing it on a network immediately, being able to quickly spin up a docker container or an install can be very helpful. Run it over some pcaps from the network or an incident and you may just find some bread crumbs to follow.

In recent years the trend has moved from Network Intrusion Detection (nids) to Endpoint Detection and Response (edr). This makes sense with increasingly encrypted network traffic. However, snort and other network tools still give visibility to a great deal of interestings on the wire and not everything runs an EDR client.