Snort — SOC Level 1 -Network Security and Traffic Analysis — TryHackMe Walkthrough

Learn how to use Snort to detect real-time threats, analyse recorded traffic files and identify anomalies.

IritT

49 min readFeb 9, 2025

Room URL: https://tryhackme.com/r/room/snort

Task 1 Introduction

This room expects you to be familiar with basic Linux command-line functionalities like general system navigation and Network fundamentals (ports, protocols and traffic data). The room aims to encourage you to start working with Snort to analyse live and captured traffic.

Before joining this room, we suggest completing the ‘Network Fundamentals’ module. If you have general knowledge of network basics and Linux fundamentals, you will be ready to begin! If you feel you need assistance in the Linux command line, you can always refer to our “Linux Fundamentals” rooms (here 1 2 3);

SNORT is an open-source, rule-based Network Intrusion Detection and Prevention System (NIDS/NIPS). It was developed and still maintained by Martin Roesch, open-source contributors, and the Cisco Talos team.

The official description: “Snort is the foremost Open Source Intrusion Prevention System (IPS) in the world. Snort IPS uses a series of rules that help define malicious network activity and uses those rules to find packets that match against them and generate alerts for users.”

Answer the questions below

Read the task above.

Task 2 Interactive Material and VM

Interactive material and exercise setup

Deploy the machine attached to this task; it will be visible in the split-screen view once it is ready. If you don’t see a virtual machine load, click the Show Split View button.

Once the machine had fully started, you will see a folder named “Task-Exercises” on the Desktop. Each exercise has an individual folder and files; use them accordingly to the questions.

Everything you need is located under the “Task-Exercises” folder.

There are two sub-folders available;

Config-Sample — Sample configuration and rule files. These files are provided to show what the configuration files look like. Installed Snort instance doesn’t use them, so feel free to practice and modify them. Snort’s original base files are located under /etc/snort folder.
Exercise-Files — There are separate folders for each task. Each folder contains pcap, log and rule files ready to play with.

Traffic Generator

The machine is offline, but there is a script (traffic-generator.sh) for you to generate traffic to your snort interface. You will use this script to trigger traffic to the snort interface. Once you run the script, it will ask you to choose the exercise type and then automatically open another terminal to show you the output of the selected action.

Note that each traffic is designed for a specific exercise. Make sure you start the snort instance and wait until to end of the script execution. Don’t stop the traffic flood unless you choose the wrong exercise.

Run the “traffic generator.sh” file by executing it as sudo.

executing the traffic generator script

user@ubuntu$ sudo ./traffic-generator.sh

General desktop overview. Traffic generator script in action.

Once you choose an action, the menu disappears and opens a terminal instance to show you the output of the action.

Answer the questions below

2. Navigate to the Task-Exercises folder and run the command “./.easy.sh” and write the output

Open a terminal on the VM and execute the following commands to locate the “Task-Exercises” folder:

cd ~/Desktop/Task-Exercises

Check the Contents of the Folder:
Verify that the script ./.easy.sh exists by listing the contents of the directory:

ls -la

Run the Script:

./.easy.sh

Answer: Too Easy!

Task 3 Introduction to IDS/IPS

Before diving into Snort and analysing traffic, let’s have a brief overview of what an Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) is. It is possible to configure your network infrastructure and use both of them, but before starting to use any of them, let’s learn the differences.

Intrusion Detection System (IDS)

IDS is a passive monitoring solution for detecting possible malicious activities/patterns, abnormal incidents, and policy violations. It is responsible for generating alerts for each suspicious event.

There are two main types of IDS systems;

Network Intrusion Detection System (NIDS) — NIDS monitors the traffic flow from various areas of the network. The aim is to investigate the traffic on the entire subnet. If a signature is identified, an alert is created.
Host-based Intrusion Detection System (HIDS) — HIDS monitors the traffic flow from a single endpoint device. The aim is to investigate the traffic on a particular device. If a signature is identified, an alert is created.

Intrusion Prevention System (IPS)

IPS is an active protecting solution for preventing possible malicious activities/patterns, abnormal incidents, and policy violations. It is responsible for stopping/preventing/terminating the suspicious event as soon as the detection is performed.

There are four main types of IPS systems;

Network Intrusion Prevention System (NIPS) — NIPS monitors the traffic flow from various areas of the network. The aim is to protect the traffic on the entire subnet. If a signature is identified, the connection is terminated.
Behaviour-based Intrusion Prevention System (Network Behaviour Analysis — NBA) — Behaviour-based systems monitor the traffic flow from various areas of the network. The aim is to protect the traffic on the entire subnet. If a signature is identified, the connection is terminated.

Network Behaviour Analysis System works similar to NIPS. The difference between NIPS and Behaviour-based is; behaviour based systems require a training period (also known as “baselining”) to learn the normal traffic and differentiate the malicious traffic and threats. This model provides more efficient results against new threats.

The system is trained to know the “normal” to detect “abnormal”. The training period is crucial to avoid any false positives. In case of any security breach during the training period, the results will be highly problematic. Another critical point is to ensure that the system is well trained to recognise benign activities.

Wireless Intrusion Prevention System (WIPS) — WIPS monitors the traffic flow from of wireless network. The aim is to protect the wireless traffic and stop possible attacks launched from there. If a signature is identified, the connection is terminated.
Host-based Intrusion Prevention System (HIPS) — HIPS actively protects the traffic flow from a single endpoint device. The aim is to investigate the traffic on a particular device. If a signature is identified, the connection is terminated.

HIPS working mechanism is similar to HIDS. The difference between them is that while HIDS creates alerts for threats, HIPS stops the threats by terminating the connection.

Detection/Prevention Techniques

Summary

Phew! That was a long ride and lots of information. Let’s summarise the overall functions of the IDS and IPS in a nutshell.

IDS can identify threats but require user assistance to stop them.
IPS can identify and block the threats with less user assistance at the detection time.

Now let’s talk about Snort. Here is the rest of the official description of the snort;

“Snort can be deployed inline to stop these packets, as well. Snort has three primary uses: As a packet sniffer like tcpdump, as a packet logger — which is useful for network traffic debugging, or it can be used as a full-blown network intrusion prevention system. Snort can be downloaded and configured for personal and business use alike.”

SNORT is an open-source, rule-based Network Intrusion Detection and Prevention System (NIDS/NIPS). It was developed and still maintained by Martin Roesch, open-source contributors, and the Cisco Talos team.

Capabilities of Snort;

Live traffic analysis
Attack and probe detection
Packet logging
Protocol analysis
Real-time alerting
Modules & plugins
Pre-processors
Cross-platform support! (Linux & Windows)

Snort has three main use models;

Sniffer Mode — Read IP packets and prompt them in the console application.
Packet Logger Mode — Log all IP packets (inbound and outbound) that visit the network.
NIDS (Network Intrusion Detection System) and NIPS (Network Intrusion Prevention System) Modes — Log/drop the packets that are deemed as malicious according to the user-defined rules.

Answer the questions below

3.1 Which snort mode can help you stop the threats on a local machine?

Answer: HIPS

3.2 Which snort mode can help you detect threats on a local network?

NIDS (Network Intrusion Detection System) Mode: This mode passively monitors network traffic across your entire network. If it detects suspicious behavior, it alerts you so you can investigate. For instance, if someone tries to scan your network for weaknesses, Snort will notice and let you know, but it won’t stop the activity itself. It’s like having a security camera that records suspicious activity without intervening.

Answer: NIDS

3.3 Which snort mode can help you detect the threats on a local machine?

HIDS (Host-based Intrusion Detection System): Focuses on detecting threats on one computer. It keeps track of all the data going in and out of that computer and warns you if something looks dangerous. However, it doesn’t block the threat — it only alerts you. It’s like having a smoke detector in your house: it tells you there’s smoke but doesn’t put out the fire.

Answer: HIDS

3.4 Which snort mode can help you stop the threats on a local network?

NBA (Network Behavior Analysis) is a security method used to monitor the behavior of network traffic to identify unusual or suspicious activities. Instead of relying on pre-defined rules or patterns (like a rule-based system), NBA focuses on learning what “normal” network activity looks like and detects anything that deviates from that.

NBA (Network Behavior Analysis), it’s important to note that baselining (training the system to recognize normal traffic) is a key component of NBA systems, but Snort primarily functions as a rule-based system.

Answer: NBA

3.5 Which snort mode works similar to NIPS mode?

NIPS (Network Intrusion Prevention System) Mode: Just like it can protect a single machine, NIPS can also protect an entire network. It actively blocks malicious traffic across your network before it reaches any device. For example, if someone launches an attack on one of your servers, NIPS will stop it at the network level before it causes harm. It’s like having a fence around your entire property that stops intruders.

Answer: NIPS

3.6 According to the official description of the snort, what kind of NIPS is it?

“full-blown” means something is fully developed or operates at its complete capacity. When Snort is referred to as a full-blown NIPS, it means Snort is capable of operating at its maximum potential as a comprehensive Intrusion Prevention System.

Answer: full-blown

3.7 NBA training period is also known as …

Baselining: During the training period, the system learns what “normal” network activity looks like. Later, it compares new activity to this baseline to identify unusual (and potentially malicious) behavior. If the baseline isn’t set correctly, the system might either miss real threats or falsely identify harmless activities as dangerous. Think of it as teaching a dog to recognize friends versus strangers — it needs proper training to avoid mistakes.

Answer: Baselining

Task 4 First Interaction with Snort

The First Interaction with Snort

First, let’s verify snort is installed. The following command will show you the instance version.

version check

user@ubuntu$ snort -V

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

Before getting your hands dirty, we should ensure our configuration file is valid.

Here “-T” is used for testing configuration, and “-c” is identifying the configuration file (snort.conf).
Note that it is possible to use an additional configuration file by pointing it with “-c”.

configuration check

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -T

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
... [Output truncated]
        --== Initialization Complete ==--   ,,_     -*> Snort! <*-
  o"  )~   Version 2.9.7.0 GRE (Build XXXX) 
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/contact#team
           Copyright (C) 2014 Cisco and/or its affiliates. All rights reserved.
           Copyright (C) 1998-2013 Sourcefire, Inc., et al.
           Using libpcap version 1.9.1 (with TPACKET_V3)
           Using PCRE version: 8.39 2016-06-14
           Using ZLIB version: 1.2.11           Rules Engine: SF_SNORT_DETECTION_ENGINE  Version 2.4  
           Preprocessor Object: SF_GTP  Version 1.1  
           Preprocessor Object: SF_SIP  Version 1.1  
           Preprocessor Object: SF_SSH  Version 1.1  
           Preprocessor Object: SF_SMTP  Version 1.1  
           Preprocessor Object: SF_POP  Version 1.0  
           Preprocessor Object: SF_DCERPC2  Version 1.0  
           Preprocessor Object: SF_IMAP  Version 1.0  
           Preprocessor Object: SF_DNP3  Version 1.1  
           Preprocessor Object: SF_SSLPP  Version 1.1  
           Preprocessor Object: SF_MODBUS  Version 1.1  
           Preprocessor Object: SF_SDF  Version 1.1  
           Preprocessor Object: SF_REPUTATION  Version 1.1  
           Preprocessor Object: SF_DNS  Version 1.1  
           Preprocessor Object: SF_FTPTELNET  Version 1.2  
... [Output truncated]
Snort successfully validated the configuration!
Snort exiting

Once we use a configuration file, snort got much more power! The configuration file is an all-in-one management file of the snort. Rules, plugins, detection mechanisms, default actions and output settings are identified here. It is possible to have multiple configuration files for different purposes and cases but can only use one at runtime.

Note that every time you start the Snort, it will automatically show the default banner and initial information about your setup. You can prevent this by using the “-q” parameter.

That was an easy one; let’s continue exploring snort modes!

Answer the questions below

4.1 Run the Snort instance and check the build number. (Question Hint -V helps you have information on your current build)

snort -V

Version: 2.9.7.0 GRE

Build: 149

The build number is a technical identifier for the exact version of Snort you are running.

Answer: 149

4.2 Test the current instance with “/etc/snort/snort.conf” file and check how many rules are loaded with the current build. (Question Hint -c identifies the configuration file. -T activates self-test mode)

sudo snort -c /etc/snort/snort.conf -T

Scroll Down

Snort successfully read and processed 4151 rules, but only 3477 of them are active detection rules.

The difference (4151–3477 = 674) includes rules that are duplicates, disabled, or invalid.

Answer: 4151

4.3 Test the current instance with “/etc/snort/snortv2.conf” file and check how many rules are loaded with the current build. (Question Hint Remember, you can have multiple configuration files for different purposes/cases)

sudo snort -c /etc/snort/snortv2.conf -T

Scroll Down

Snort rules read: 1

Detection rules: 1

Answer: 1

Task 5 Operation Mode 1: Sniffer Mode

Let’s run Snort in Sniffer Mode

Like tcpdump, Snort has various flags capable of viewing various data about the packet it is ingesting.

Sniffer mode parameters are explained in the table below;

Let’s start using each parameter and see the difference between them. Snort needs active traffic on your interface, so we need to generate traffic to see Snort in action.

To do this, use the traffic-generator script (find this in the Task-Exercise folder)

Sniffing with parameter “-i”

Start the Snort instance in verbose mode (-v) and use the interface (-i) “eth0”; sudo snort -v -i eth0

In case you have only one interface, Snort uses it by default. The above example demonstrates to sniff on the interface named “eth0”. Once you simulate the parameter -v, you will notice it will automatically use the “eth0” interface and prompt it.

Sniffing with parameter “-v”

Start the Snort instance in verbose mode (-v); sudo snort -v

Now run the traffic-generator script as sudo and start ICMP/HTTP traffic. Once the traffic is generated, snort will start showing the packets in verbosity mode as follows;

sniffing with -v

user@ubuntu$ sudo snort -v
                             
Running in packet dump mode

        --== Initializing Snort ==--
...
Commencing packet processing (pid=64)
12/01-20:10:13.846653 192.168.175.129:34316 -> 192.168.175.2:53
UDP TTL:64 TOS:0x0 ID:23826 IpLen:20 DgmLen:64 DF
Len: 36
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+12/01-20:10:13.846794 192.168.175.129:38655 -> 192.168.175.2:53
UDP TTL:64 TOS:0x0 ID:23827 IpLen:20 DgmLen:64 DF
Len: 36
===============================================================================
Snort exiting

As you can see in the given output, verbosity mode provides tcpdump like output information. Once we interrupt the sniffing with CTRL+C, it stops and summarises the sniffed packets.

Sniffing with parameter “-d”

Start the Snort instance in dumping packet data mode (-d); sudo snort -d

Now run the traffic-generator script as sudo and start ICMP/HTTP traffic. Once the traffic is generated, snort will start showing the packets in verbosity mode as follows;

sniffing with -d

user@ubuntu$ sudo snort -d
                             
Running in packet dump mode

        --== Initializing Snort ==--
...
Commencing packet processing (pid=67)12/01-20:45:42.068675 192.168.175.129:37820 -> 192.168.175.2:53
UDP TTL:64 TOS:0x0 ID:53099 IpLen:20 DgmLen:56 DF
Len: 28
99 A5 01 00 00 01 00 00 00 00 00 00 06 67 6F 6F  .............goo
67 6C 65 03 63 6F 6D 00 00 1C 00 01              gle.com.....=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+WARNING: No preprocessors configured for policy 0.
12/01-20:45:42.070742 192.168.175.2:53 -> 192.168.175.129:44947
UDP TTL:128 TOS:0x0 ID:63307 IpLen:20 DgmLen:72
Len: 44
FE 64 81 80 00 01 00 01 00 00 00 00 06 67 6F 6F  .d...........goo
67 6C 65 03 63 6F 6D 00 00 01 00 01 C0 0C 00 01  gle.com.........
00 01 00 00 00 05 00 04 D8 3A CE CE              .........:..=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

As you can see in the given output, packet data payload mode covers the verbose mode and provides more data.

Sniffing with parameter “-de”

Start the Snort instance in dump (-d) and link-layer header grabbing (-e) mode; snort -d -e

Now run the traffic-generator script as sudo and start ICMP/HTTP traffic. Once the traffic is generated, snort will start showing the packets in verbosity mode as follows;

sniffing with -de

user@ubuntu$ sudo snort -de
                             
Running in packet dump mode

        --== Initializing Snort ==--
...
Commencing packet processing (pid=70)
12/01-20:55:26.958773 00:0C:29:A5:B7:A2 -> 00:50:56:E1:9B:9D type:0x800 len:0x46
192.168.175.129:47395 -> 192.168.175.2:53 UDP TTL:64 TOS:0x0 ID:64294 IpLen:20 DgmLen:56 DF
Len: 28
6D 9C 01 00 00 01 00 00 00 00 00 00 06 67 6F 6F  m............goo
67 6C 65 03 63 6F 6D 00 00 01 00 01              gle.com.....=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+WARNING: No preprocessors configured for policy 0.
12/01-20:55:26.965226 00:50:56:E1:9B:9D -> 00:0C:29:A5:B7:A2 type:0x800 len:0x56
192.168.175.2:53 -> 192.168.175.129:47395 UDP TTL:128 TOS:0x0 ID:63346 IpLen:20 DgmLen:72
Len: 44
6D 9C 81 80 00 01 00 01 00 00 00 00 06 67 6F 6F  m............goo
67 6C 65 03 63 6F 6D 00 00 01 00 01 C0 0C 00 01  gle.com.........
00 01 00 00 00 05 00 04 D8 3A D6 8E              .........:..

Sniffing with parameter “-X”

Start the Snort instance in full packet dump mode (-X); sudo snort -X

Now run the traffic-generator script as sudo and start ICMP/HTTP traffic. Once the traffic is generated, snort will start showing the packets in verbosity mode as follows;

sniffing with -X

user@ubuntu$ sudo snort -X
                             
Running in packet dump mode

        --== Initializing Snort ==--
...
Commencing packet processing (pid=76)
WARNING: No preprocessors configured for policy 0.
12/01-21:07:56.806121 192.168.175.1:58626 -> 239.255.255.250:1900
UDP TTL:1 TOS:0x0 ID:48861 IpLen:20 DgmLen:196
Len: 168
0x0000: 01 00 5E 7F FF FA 00 50 56 C0 00 08 08 00 45 00  ..^....PV.....E.
0x0010: 00 C4 BE DD 00 00 01 11 9A A7 C0 A8 AF 01 EF FF  ................
0x0020: FF FA E5 02 07 6C 00 B0 85 AE 4D 2D 53 45 41 52  .....l....M-SEAR
0x0030: 43 48 20 2A 20 48 54 54 50 2F 31 2E 31 0D 0A 48  CH * HTTP/1.1..H
0x0040: 4F 53 54 3A 20 32 33 39 2E 32 35 35 2E 32 35 35  OST: 239.255.255
0x0050: 2E 32 35 30 3A 31 39 30 30 0D 0A 4D 41 4E 3A 20  .250:1900..MAN: 
0x0060: 22 73 73 64 70 3A 64 69 73 63 6F 76 65 72 22 0D  "ssdp:discover".
0x0070: 0A 4D 58 3A 20 31 0D 0A 53 54 3A 20 75 72 6E 3A  .MX: 1..ST: urn:
0x0080: 64 69 61 6C 2D 6D 75 6C 74 69 73 63 72 65 65 6E  dial-multiscreen
0x0090: 2D 6F 72 67 3A 73 65 72 76 69 63 65 3A 64 69 61  -org:service:dia
0x00A0: 6C 3A 31 0D 0A 55 53 45 52 2D 41 47 45 4E 54 3A  l:1..USER-AGENT:
0x00B0: 20 43 68 72 6F 6D 69 75 6D 2F 39 35 2E 30 2E 34   Chromium/95.0.4
0x00C0: 36 33 38 2E 36 39 20 57 69 6E 64 6F 77 73 0D 0A  638.69 Windows..
0x00D0: 0D 0A                                            ..=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+WARNING: No preprocessors configured for policy 0.
12/01-21:07:57.624205 216.58.214.142 -> 192.168.175.129
ICMP TTL:128 TOS:0x0 ID:63394 IpLen:20 DgmLen:84
Type:0  Code:0  ID:15  Seq:1  ECHO REPLY
0x0000: 00 0C 29 A5 B7 A2 00 50 56 E1 9B 9D 08 00 45 00  ..)....PV.....E.
0x0010: 00 54 F7 A2 00 00 80 01 24 13 D8 3A D6 8E C0 A8  .T......$..:....
0x0020: AF 81 00 00 BE B6 00 0F 00 01 2D E4 A7 61 00 00  ..........-..a..
0x0030: 00 00 A4 20 09 00 00 00 00 00 10 11 12 13 14 15  ... ............
0x0040: 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25  .......... !"#$%
0x0050: 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35  &'()*+,-./012345
0x0060: 36 37                                            67=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Note that you can use the parameters both in combined and separated form as follows;

snort -v
snort -vd
snort -de
snort -v -d -e
snort -X

Make sure you understand and practice each parameter with different types of traffic and discover your favourite combination.

Answer the questions below

5. You can practice the parameter combinations by using the traffic-generator script.

Answer: No answer needed

Task 6 Operation Mode 2: Packet Logger Mode

Let’s run Snort in Logger Mode

You can use Snort as a sniffer and log the sniffed packets via logger mode. You only need to use the packet logger mode parameters, and Snort does the rest to accomplish this.

Packet logger parameters are explained in the table below;

Let’s start using each parameter and see the difference between them. Snort needs active traffic on your interface, so we need to generate traffic to see Snort in action.

Logfile Ownership

Before generating logs and investigating them, we must remember the Linux file ownership and permissions. No need to deep dive into user types and permissions. The fundamental file ownership rule; whoever creates a file becomes the owner of the corresponding file.

Snort needs superuser (root) rights to sniff the traffic, so once you run the snort with the “sudo” command, the “root” account will own the generated log files. Therefore you will need “root” rights to investigate the log files. There are two different approaches to investigate the generated log files;

Elevation of privileges — You can elevate your privileges to examine the files. You can use the “sudo” command to execute your command as a superuser with the following command sudo command. You can also elevate the session privileges and switch to the superuser account to examine the generated log files with the following command: sudo su
Changing the ownership of files/directories — You can also change the ownership of the file/folder to read it as your user: sudo chown username file or sudo chown username -R directory The "-R" parameter helps recursively process the files and directories.

Logging with parameter “-l”

First, start the Snort instance in packet logger mode; sudo snort -dev -l .

Now start ICMP/HTTP traffic with the traffic-generator script.

Once the traffic is generated, Snort will start showing the packets and log them in the target directory. You can configure the default output directory in snort.config file. However, you can use the “-l” parameter to set a target directory. Identifying the default log directory is useful for continuous monitoring operations, and the “-l” parameter is much more useful for testing purposes.

The -l . part of the command creates the logs in the current directory. You will need to use this option to have the logs for each exercise in their folder.

logging with -l

user@ubuntu$ sudo snort -dev -l .
                             
Running in packet logging mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Log directory = /var/log/snort
pcap DAQ configured to passive.
Acquiring network traffic from "ens33".
Decoding Ethernet        --== Initialization Complete ==--
...
Commencing packet processing (pid=2679)
WARNING: No preprocessors configured for policy 0.
WARNING: No preprocessors configured for policy 0.

Now, let’s check the generated log file. Note that the log file names will be different in your case.

checking the log file

user@ubuntu$ ls .
                             
snort.log.1638459842

As you can see, it is a single all-in-one log file. It is a binary/tcpdump format log. This is what it looks like in the folder view.

Logging with parameter “-K ASCII”

Start the Snort instance in packet logger mode; sudo snort -dev -K ASCII

Now run the traffic-generator script as sudo and start ICMP/HTTP traffic. Once the traffic is generated, Snort will start showing the packets in verbosity mode as follows;

logging with -K ASCII

user@ubuntu$ sudo snort -dev -K ASCII -l .
                             
Running in packet logging mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Log directory = /var/log/snort
pcap DAQ configured to passive.
Acquiring network traffic from "ens33".
Decoding Ethernet        --== Initialization Complete ==--
...
Commencing packet processing (pid=2679)
WARNING: No preprocessors configured for policy 0.
WARNING: No preprocessors configured for policy 0.

Now, let’s check the generated log file.

Checking the log file

user@ubuntu$ ls .
                             
142.250.187.110  192.168.175.129  snort.log.1638459842

This is what it looks like in the folder view.

The logs created with “-K ASCII” parameter is entirely different. There are two folders with IP address names. Let’s look into them.

checking the log file

user@ubuntu$ ls ./192.168.175.129/
                             
ICMP_ECHO  UDP:36648-53  UDP:40757-53  UDP:47404-53  UDP:50624-123

Once we look closer at the created folders, we can see that the logs are in ASCII and categorised format, so it is possible to read them without using a Snort instance.

This is what it looks like in the folder view.

In a nutshell, ASCII mode provides multiple files in human-readable format, so it is possible to read the logs easily by using a text editor. By contrast with ASCII format, binary format is not human-readable and requires analysis using Snort or an application like tcpdump.

Let’s compare the ASCII format with the binary format by opening both of them in a text editor. The difference between the binary log file and the ASCII log file is shown below. (Left side: binary format. Right side: ASCII format).

Reading generated logs with parameter “-r”

Start the Snort instance in packet reader mode; sudo snort -r

reading log files with -r

user@ubuntu$ sudo snort -r snort.log.1638459842
                             
Running in packet dump mode

        --== Initializing Snort ==--
Initializing Output Plugins!
pcap DAQ configured to read-file.
Acquiring network traffic from "snort.log.1638459842".        --== Initialization Complete ==--
...
Commencing packet processing (pid=3012)
WARNING: No preprocessors configured for policy 0.
12/02-07:44:03.123225 192.168.175.129 -> 142.250.187.110
ICMP TTL:64 TOS:0x0 ID:41900 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:1   Seq:49  ECHO
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
WARNING: No preprocessors configured for policy 0.
12/02-07:44:26.169620 192.168.175.129 -> 142.250.187.110
ICMP TTL:64 TOS:0x0 ID:44765 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:1   Seq:72  ECHO
===============================================================================
Packet I/O Totals:
   Received:           51
   Analyzed:           51 (100.000%)
    Dropped:            0 (  0.000%)
   Filtered:            0 (  0.000%)
Outstanding:            0 (  0.000%)
   Injected:            0
===============================================================================
Breakdown by protocol (includes rebuilt packets):
...
      Total:           51
===============================================================================
Snort exiting

Note that Snort can read and handle the binary like output (tcpdump and Wireshark also can handle this log format). However, if you create logs with “-K ASCII” parameter, Snort will not read them. As you can see in the above output, Snort read and displayed the log file just like in the sniffer mode.

Opening log file with tcpdump.

Opening the log file with tcpdump

user@ubuntu$ sudo tcpdump -r snort.log.1638459842 -ntc 10
                             
reading from file snort.log.1638459842, link-type EN10MB (Ethernet)
IP 192.168.175.129 > 142.250.187.110: ICMP echo request, id 1, seq 49, length 64
IP 142.250.187.110 > 192.168.175.129: ICMP echo reply, id 1, seq 49, length 64
IP 192.168.175.129 > 142.250.187.110: ICMP echo request, id 1, seq 50, length 64
IP 142.250.187.110 > 192.168.175.129: ICMP echo reply, id 1, seq 50, length 64
IP 192.168.175.129 > 142.250.187.110: ICMP echo request, id 1, seq 51, length 64
IP 142.250.187.110 > 192.168.175.129: ICMP echo reply, id 1, seq 51, length 64
IP 192.168.175.129 > 142.250.187.110: ICMP echo request, id 1, seq 52, length 64
IP 142.250.187.110 > 192.168.175.129: ICMP echo reply, id 1, seq 52, length 64
IP 192.168.175.1.63096 > 239.255.255.250.1900: UDP, length 173
IP 192.168.175.129 > 142.250.187.110: ICMP echo request, id 1, seq 53, length 64

Opening log file with Wireshark.

“-r” parameter also allows users to filter the binary log files. You can filter the processed log to see specific packets with the “-r” parameter and Berkeley Packet Filters (BPF).

sudo snort -r logname.log -X
sudo snort -r logname.log icmp
sudo snort -r logname.log tcp
sudo snort -r logname.log 'udp and port 53'

The output will be the same as the above, but only packets with the chosen protocol will be shown. Additionally, you can specify the number of processes with the parameter “-n”. The following command will process only the first 10 packets:

snort -dvr logname.log -n 10

Please use the following resources to understand how the BPF works and its use.

Now, use the attached VM and navigate to the Task-Exercises/Exercise-Files/TASK-6 folder to answer the questions!

Answer the questions below

6.1 Investigate the traffic with the default configuration file with ASCII mode.

sudo snort -dev -K ASCII -l .

Execute the traffic generator script and choose “TASK-6 Exercise”. Wait until the traffic ends, then stop the Snort instance. Now analyse the output summary and answer the question.

sudo ./traffic-generator.sh

Go back to the first terminal window and press Ctrl+C to stop the prosess

Now, you should have the logs in the current directory.

ls

Navigate to folder “145.254.160.237”. What is the source port used to connect port 53? (Question Hint You can re-generate the traffic if the expected log is not generated. “sudo ls” can help you! Check the “Logfile Ownership” part in this task to avoid the “permission denied” error)

cd 145.254.160.237

Changes permissions:

sudo chmod 777 145.254.160.237
cd 145.254.160.237
ls

The question specifically asks for the source port used to connect to port 53.

Look at the file UDP:3009–53.

This naming format indicates 3009 is the source port.

53 is the destination port (commonly used for DNS traffic).

Answer: 3009

6.2 Use snort.log.1640048004

Read the snort.log file with Snort; what is the IP ID of the 10th packet?

snort -r snort.log.1640048004 -n 10 (Question Hint -n helps to analyse the “n” number of packets. You can view the IP with sniffing mode parameters -v, -d, -e or -X.)

Find snort.log.1640048004

find / -name "snort.log.1640048004" 2>/dev/null

Navigate to the Directory where the file is located:

cd /home/ubuntu/Desktop/Task-Exercises/Exercise-Files/TASK-6/

read the 10th packet:

sudo snort -r snort.log.1640048004 -n 10

Scroll down

Find the IP ID Look for the 10th packet in the output and locate the ID: field. The value after ID: is the IP ID.

Answer: 49313

6.3 Read the “snort.log.1640048004” file with Snort; what is the referer of the 4th packet? (Question Hint “-X” helps you to display the full packet details)

sudo snort -r snort.log.1640048004 -n 4 -X

Scroll down

Answer: http://www.ethereal.com/development.html

6.4 Read the “snort.log.1640048004” file with Snort; what is the Ack number of the 8th packet?

Process the first 8 packets:

sudo snort -r snort.log.1640048004 -n 8 -v

Scroll down

Answer: 0x38AFFFF3

6.5 Read the “snort.log.1640048004” file with Snort; what is the number of the “TCP port 80” packets? (Question Hint PF filters will help you to filter the log file. ‘tcp and port 80’)

Filter and count only the TCP packets that use port 80:

sudo snort -r snort.log.1640048004 'tcp and port 80'

Scroll down

Answer: 41

Task 7 Operation Mode 3: IDS/IPS

Snort in IDS/IPS Mode

Capabilities of Snort are not limited to sniffing and logging the traffic. IDS/IPS mode helps you manage the traffic according to user-defined rules.

Note that (N)IDS/IPS mode depends on the rules and configuration. TASK-10 summarises the essential paths, files and variables. Also, TASK-3 covers configuration testing. Here, we need to understand the operating logic first, and then we will be going into rules in TASK-9.

Let’s run Snort in IDS/IPS Mode

NIDS mode parameters are explained in the table below;

Let’s start using each parameter and see the difference between them. Snort needs active traffic on your interface, so we need to generate traffic to see Snort in action. To do this, use the traffic-generator script and sniff the traffic.

Once you start running IDS/IPS mode, you need to use rules. As we mentioned earlier, we will use a pre-defined ICMP rule as an example. The defined rule will only generate alerts in any direction of ICMP packet activity.

alert icmp any any <> any any (msg: "ICMP Packet Found"; sid: 100001; rev:1;)

This rule is located in “/etc/snort/rules/local.rules”.

Remember, in this module, we will focus only on the operating modes. The rules are covered in TASK9&10. Snort will create an “alert” file if the traffic flow triggers an alert. One last note; once you start running IPS/IDS mode, the sniffing and logging mode will be semi-passive. However, you can activate the functions using the parameters discussed in previous tasks. (-i, -v, -d, -e, -X, -l, -K ASCII) If you don’t remember the purpose of these commands, please revisit TASK4.

IDS/IPS mode with parameter “-c and -T”

Start the Snort instance and test the configuration file. sudo snort -c /etc/snort/snort.conf -T This command will check your configuration file and prompt it if there is any misconfiguratioın in your current setting. You should be familiar with this command if you covered TASK3. If you don't remember the output of this command, please revisit TASK4.

IDS/IPS mode with parameter “-N”

Start the Snort instance and disable logging by running the following command: sudo snort -c /etc/snort/snort.conf -N

Now run the traffic-generator script as sudo and start ICMP/HTTP traffic. This command will disable logging mode. The rest of the other functions will still be available (if activated).

The command-line output will provide the information requested with the parameters. So, if you activate verbosity (-v) or full packet dump (-X) you will still have the output in the console, but there will be no logs in the log folder.

IDS/IPS mode with parameter “-D”

Start the Snort instance in background mode with the following command: sudo snort -c /etc/snort/snort.conf -D

Now run the traffic-generator script as sudo and start ICMP/HTTP traffic. Once the traffic is generated, snort will start processing the packets and accomplish the given task with additional parameters.

running in background mode

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -D

Spawning daemon child...
My daemon child 2898 lives...
Daemon parent exiting (0)

The command-line output will provide the information requested with the parameters. So, if you activate verbosity (-v) or full packet dump (-X) with packet logger mode (-l) you will still have the logs in the logs folder, but there will be no output in the console.

Once you start the background mode and want to check the corresponding process, you can easily use the “ps” command as shown below;

running in background mode

user@ubuntu$ ps -ef | grep snort

root        2898    1706  0 05:53 ?        00:00:00 snort -c /etc/snort/snort.conf -D

If you want to stop the daemon, you can easily use the “kill” command to stop the process.

running in background mode

user@ubuntu$ sudo kill -9 2898

Note that daemon mode is mainly used to automate the Snort. This parameter is mainly used in scripts to start the Snort service in the background. It is not recommended to use this mode unless you have a working knowledge of Snort and stable configuration.

IDS/IPS mode with parameter “-A”

Remember that there are several alert modes available in snort;

console: Provides fast style alerts on the console screen.
cmg: Provides basic header details with payload in hex and text format.
full: Full alert mode, providing all possible information about the alert.
fast: Fast mode, shows the alert message, timestamp, source and destination ıp along with port numbers.
none: Disabling alerting.

In this section, only the “console” and “cmg” parameters provide alert information in the console. It is impossible to identify the difference between the rest of the alert modes via terminal. Differences can be identified by looking at generated logs.

At the end of this section, we will compare the “full”, “fast” and “none” modes. Remember that these parameters don’t provide console output, so we will continue to identify the differences through log formats.

IDS/IPS mode with parameter “-A console”

Console mode provides fast style alerts on the console screen. Start the Snort instance in console alert mode (-A console ) with the following command sudo snort -c /etc/snort/snort.conf -A console

Now run the traffic-generator script as sudo and start ICMP/HTTP traffic. Once the traffic is generated, snort will start generating alerts according to provided ruleset defined in the configuration file.

running in console alert mode

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -A console
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
...
Commencing packet processing (pid=3743)
12/12-02:08:27.577495  [**] [1:366:7] ICMP PING *NIX [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:08:27.577495  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:08:27.577495  [**] [1:384:5] ICMP PING [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:08:27.609719  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
^C*** Caught Int-Signal
12/12-02:08:29.595898  [**] [1:366:7] ICMP PING *NIX [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:08:29.595898  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:08:29.595898  [**] [1:384:5] ICMP PING [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.175.129 -> 142.250.187.110
===============================================================================
Run time for packet processing was 26.25844 seconds
Snort processed 88 packets.

IDS/IPS mode with parameter “-A cmg”

Cmg mode provides basic header details with payload in hex and text format. Start the Snort instance in cmg alert mode (-A cmg ) with the following command sudo snort -c /etc/snort/snort.conf -A cmg

running in cmg alert mode

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -A cmg
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
...
Commencing packet processing (pid=3743)
12/12-02:23:56.944351  [**] [1:366:7] ICMP PING *NIX [**] [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-02:23:56.944351 00:0C:29:A5:B7:A2 -> 00:50:56:E1:9B:9D type:0x800 len:0x62
192.168.175.129 -> 142.250.187.110 ICMP TTL:64 TOS:0x0 ID:10393 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:4   Seq:1  ECHO
BC CD B5 61 00 00 00 00 CE 68 0E 00 00 00 00 00  ...a.....h......
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F  ................
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F   !"#$%&'()*+,-./
30 31 32 33 34 35 36 37                          01234567=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Let’s compare the console and cmg outputs before moving on to other alarm types. As you can see in the given outputs above, console mode provides basic header and rule information. Cmg mode provides full packet details along with rule information.

IDS/IPS mode with parameter “-A fast”

Fast mode provides alert messages, timestamps, and source and destination IP addresses. Remember, there is no console output in this mode. Start the Snort instance in fast alert mode (-A fast ) with the following command sudo snort -c /etc/snort/snort.conf -A fast

running in fast alert mode

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -A fast
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
...
Commencing packet processing (pid=3743)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Let’s check the alarm file;

As you can see in the given picture above, fast style alerts contain summary information on the action like direction and alert header.

IDS/IPS mode with parameter “-A full”

Full alert mode provides all possible information about the alert. Remember, there is no console output in this mode. Start the Snort instance in full alert mode (-A full ) with the following command sudo snort -c /etc/snort/snort.conf -A full

running in full alert mode

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -A full
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
...
Commencing packet processing (pid=3744)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Let’s check the alarm file;

As you can see in the given picture above, full style alerts contain all possible information on the action.

IDS/IPS mode with parameter “-A none”

Disable alerting. This mode doesn’t create the alert file. However, it still logs the traffic and creates a log file in binary dump format. Remember, there is no console output in this mode. Start the Snort instance in none alert mode (-A none) with the following command sudo snort -c /etc/snort/snort.conf -A none

running in none alert mode

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -A none
Running in IDS mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
...
Commencing packet processing (pid=3745)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

As you can see in the picture below, there is no alert file. Snort only generated the log file.

IDS/IPS mode: “Using rule file without configuration file”

It is possible to run the Snort only with rules without a configuration file. Running the Snort in this mode will help you test the user-created rules. However, this mode will provide less performance.

running without configuration file

user@ubuntu$ sudo snort -c /etc/snort/rules/local.rules -A console
Running in IDS mode

12/12-12:13:29.167955  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:29.200543  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:30.169785  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:30.201470  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:31.172101  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
^C*** Caught Int-Signal

IPS mode and dropping packets

Snort IPS mode activated with -Q — daq afpacket parameters. You can also activate this mode by editing snort.conf file. However, you don’t need to edit snort.conf file in the scope of this room. Review the bonus task or snort manual for further information on daq and advanced configuration settings: -Q --daq afpacket

Activate the Data Acquisition (DAQ) modules and use the afpacket module to use snort as an IPS: -i eth0:eth1

Identifying interfaces note that Snort IPS require at least two interfaces to work. Now run the traffic-generator script as sudo and start ICMP/HTTP traffic.

running IPS mode

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -q -Q --daq afpacket -i eth0:eth1 -A console
Running in IPS mode

12/18-07:40:01.527100  [Drop] [**] [1:1000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.131 -> 192.168.175.2
12/18-07:40:01.552811  [Drop] [**] [1:1000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 172.217.169.142 -> 192.168.1.18
12/18-07:40:01.566232  [Drop] [**] [1:1000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.131 -> 192.168.175.2
12/18-07:40:02.517903  [Drop] [**] [1:1000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.1.18 -> 172.217.169.142
12/18-07:40:02.550844  [Drop] [**] [1:1000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 172.217.169.142 -> 192.168.1.18
^C*** Caught Int-Signal

As you can see in the picture above, Snort blocked the packets this time. We used the same rule with a different action (drop/reject). Remember, for the scope of this task; our point is the operating mode, not the rule.

Answer the questions below

7.1 Investigate the traffic with the default configuration file.

sudo snort -c /etc/snort/snort.conf -A full -l .

In a new terminal window, Execute the traffic generator script and choose “TASK-7 Exercise.”raffic stops, then stop the Snort instance. Now analyse the output summary and answer the question.

sudo ./traffic-generator.sh

What is the number of the detected HTTP GET methods? (Question Hint Timing is important, you should start the sniffing before the attack and terminate right after the attack. You can read the provided output statistics summary on the console)

Go back to the first terminal Window press Ctrl+C

Scroll to find HTTP GET methods

Answer: 2

7.2 You can practice the rest of the parameters by using the traffic-generator script.

Answer: No answer needed

Task 8 Operation Mode 4: PCAP Investigation

Let’s investigate PCAPs with Snort

Capabilities of Snort are not limited to sniffing, logging and detecting/preventing the threats. PCAP read/investigate mode helps you work with pcap files. Once you have a pcap file and process it with Snort, you will receive default traffic statistics with alerts depending on your ruleset.

Reading a pcap without using any additional parameters we discussed before will only overview the packets and provide statistics about the file. In most cases, this is not very handy. We are investigating the pcap with Snort to benefit from the rules and speed up our investigation process by using the known patterns of threats.

Note that we are pretty close to starting to create rules. Therefore, you need to grasp the working mechanism of the Snort, learn the discussed parameters and begin combining the parameters for different purposes.

PCAP mode parameters are explained in the table below;

Investigating single PCAP with parameter “-r”

For test purposes, you can still test the default reading option with pcap by using the following command snort -r icmp-test.pcap

Let’s investigate the pcap with our configuration file and see what will happen. sudo snort -c /etc/snort/snort.conf -q -r icmp-test.pcap -A console -n 10

If you don’t remember the purpose of the parameters in the given command, please revisit previous tasks and come back again!

investigating single pcap file

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -q -r icmp-test.pcap -A console -n 10

12/12-12:13:29.167955  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:29.200543  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:30.169785  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:30.201470  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:31.172101  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:31.204104  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:32.174106  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:32.208683  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:33.176920  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:33.208359  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129

Our ICMP rule got a hit! As you can see in the given output, snort identified the traffic and prompted the alerts according to our ruleset.

Investigating multiple PCAPs with parameter “ — pcap-list”

Let’s investigate multiple pcaps with our configuration file and see what will happen. sudo snort -c /etc/snort/snort.conf -q --pcap-list="icmp-test.pcap http2.pcap" -A console -n 10

investigating multiple pcap files

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -q --pcap-list="icmp-test.pcap http2.pcap" -A console

12/12-12:13:29.167955  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:29.200543  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:30.169785  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:30.201470  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:31.172101  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
...
12/12-12:13:31.204104  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:32.174106  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:32.208683  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:33.176920  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:33.208359  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129

Our ICMP rule got a hit! As you can see in the given output, snort identified the traffic and prompted the alerts according to our ruleset.

Here is one point to notice: we’ve processed two pcaps, and there are lots of alerts, so it is impossible to match the alerts with provided pcaps without snort’s help. We need to separate the pcap process to identify the source of the alerts.

Investigating multiple PCAPs with parameter “ — pcap-show”

Let’s investigate multiple pcaps, distinguish each one, and see what will happen. sudo snort -c /etc/snort/snort.conf -q --pcap-list="icmp-test.pcap http2.pcap" -A console --pcap-show

investigating multiple pcap files wth pcap info

user@ubuntu$ sudo snort -c /etc/snort/snort.conf -q --pcap-list="icmp-test.pcap http2.pcap" -A console --pcap-show

Reading network traffic from "icmp-test.pcap" with snaplen = 1514
12/12-12:13:29.167955  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:29.200543  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:30.169785  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
...Reading network traffic from "http2.pcap" with snaplen = 1514
12/12-12:13:35.213176  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
12/12-12:13:36.182950  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 192.168.175.129 -> 142.250.187.110
12/12-12:13:38.223470  [**] [1:10000001:0] ICMP Packet found [**] [Priority: 0] {ICMP} 142.250.187.110 -> 192.168.175.129
...

Our ICMP rule got a hit! As you can see in the given output, snort identified the traffic, distinguished each pcap file and prompted the alerts according to our ruleset.

Now, use the attached VM and navigate to the Task-Exercises/Exercise-Files/TASK-8 folder to answer the questions!

Answer the questions below

8.1 Investigate the mx-1.pcap file with the default configuration file.

sudo snort -c /etc/snort/snort.conf -A full -l . -r mx-1.pcap

What is the number of the generated alerts?

cd /home/ubuntu/Desktop/Task-Exercises/Exercise-Files/TASK-8/
ls
sudo snort -c /etc/snort/snort.conf -A full -l . -r mx-1.pcap

Scrool to find generated alerts

Answer: 170

8.2 Keep reading the output. How many TCP Segments are Queued?

Answer: 18

8.3 Keep reading the output.How many “HTTP response headers” were extracted?

Answer: 3

8.4 Investigate the mx-1.pcap file with the second configuration file.

sudo snort -c /etc/snort/snortv2.conf -A full -l . -r mx-1.pcap

What is the number of the generated alerts?

Scrool to find generated alerts

Answer: 68

8.5 Investigate the mx-2.pcap file with the default configuration file.

sudo snort -c /etc/snort/snort.conf -A full -l . -r mx-2.pcap

What is the number of the generated alerts? (Question Hint Check for the TCP Port Filter)

If the above steps fail, explicitly specify a different log directory:

sudo snort -c /etc/snort/snort.conf -A full -l /tmp -r mx-2.pcap

Scroll to find generated alerts:

Answer: 340

8.6 Keep reading the output. What is the number of the detected TCP packets?

Answer: 82

8.7 Investigate the mx-2.pcap and mx-3.pcap files with the default configuration file.

sudo snort -c /etc/snort/snort.conf -A full -l . --pcap-list="mx-2.pcap mx-3.pcap"

What is the number of the generated alerts?

Scroll to find generated alerts:

Answer: 1020

Task 9 Snort Rule Structure

Let’s Learn Snort Rules!

Understanding the Snort rule format is essential for any blue and purple teamer. The primary structure of the snort rule is shown below;

Each rule should have a type of action, protocol, source and destination IP, source and destination port and an option. Remember, Snort is in passive mode by default. So most of the time, you will use Snort as an IDS. You will need to start “inline mode” to turn on IPS mode. But before you start playing with inline mode, you should be familiar with Snort features and rules.

The Snort rule structure is easy to understand but difficult to produce. You should be familiar with rule options and related details to create efficient rules. It is recommended to practice Snort rules and option details for different use cases.

We will cover the basic rule structure in this room and help you take a step into snort rules. You can always advance your rule creation skills with different rule options by practising different use cases and studying rule option details in depth. We will focus on two actions; “alert” for IDS mode and “reject” for IPS mode.

Rules cannot be processed without a header. Rule options are “optional” parts. However, it is almost impossible to detect sophisticated attacks without using the rule options.

IP and Port Numbers

These parameters identify the source and destination IP addresses and associated port numbers filtered for the rule.

Direction

The direction operator indicates the traffic flow to be filtered by Snort. The left side of the rule shows the source, and the right side shows the destination.

-> Source to destination flow.
<> Bidirectional flow

Note that there is no “<-” operator in Snort.

There are three main rule options in Snort;

General Rule Options — Fundamental rule options for Snort.
Payload Rule Options — Rule options that help to investigate the payload data. These options are helpful to detect specific payload patterns.
Non-Payload Rule Options — Rule options that focus on non-payload data. These options will help create specific patterns and identify network issues.

General Rule Options

Payload Detection Rule Options

Non-Payload Detection Rule Options

There are rule options that focus on non-payload data. These options will help create specific patterns and identify network issues.

Remember, once you create a rule, it is a local rule and should be in your “local.rules” file. This file is located under “/etc/snort/rules/local.rules”. A quick reminder on how to edit your local rules is shown below.

modifying the local rules

user@ubuntu$ sudo gedit /etc/snort/rules/local.rules

That is your “local.rules” file.

Note that there are some default rules activated with snort instance. These rules are deactivated to manage your rules and improve your exercise experience. For further information, please refer to the TASK-10 or Snort manual.

By this point, we covered the primary structure of the Snort rules. Understanding and practicing the fundamentals is suggested before creating advanced rules and using additional options.

Wow! We have covered the fundamentals of the Snort rules! Now, use the attached VM and navigate to the Task-Exercises/Exercise-Files/TASK-9 folder to answer the questions! Note that you can use the following command to create the logs in the current directory: -l .

Answer the questions below

9.1 Use “task9.pcap”.

Write a rule to filter IP ID “35369” and run it against the given pcap file. What is the request name of the detected packet? snort -c local.rules -A full -l . -r task9.pcap (Question Hint Try to filter different protocols like TCP/UDP/ICMP. id:35369;)

Navigate to the directory

cd /home/ubuntu/Desktop/Task-Exercises/Exercise-Files/TASK-9/

Use a text editor to open the local.rules file:

sudo nano /etc/snort/rules/local.rules

Add the rule to the file:

alert ip any any <> any any (msg: "IP ID 35369 Detected"; id:35369; sid:100001; rev:1;)

Save and Exit

Run Snort with your rule and the provided task9.pcap file

Snort to analyze the network packets in the file task9.pcap and apply the detection rules defined in local.rules (or other rules specified in snort.conf).

snort -c /etc/snort/snort.conf -A full -l . -r task9.pcap

Once Snort finishes processing, check the alert file in the current directory

cat alert

Look for ID 35369

The packet is an ICMP Timestamp Request (Type 13, Code 0), commonly used to synchronize clocks between devices.

Answer: Timestamp Request

ICMP (Internet Control Message Protocol) is a protocol used for diagnostic and control purposes within a network. It helps determine if a device is reachable and can provide error messages or other control data. Common ICMP messages include “ping” (echo requests) and “timestamp requests.”

An ICMP Timestamp Request is a specific type of ICMP message (Type 13). It is used to query the current time from another device on the network. The request includes:

Originate Timestamp: The time when the packet was sent from the source.
Sequence Number: Used to match requests with replies.
The destination device responds with a Timestamp Reply (Type 14), which includes:
The Originate Timestamp,
A Receive Timestamp (time when the request was received),
A Transmit Timestamp (time when the reply is sent).

The Purpose of the Timestamp Request:

It helps measure round-trip time (RTT) between two devices.
In older systems, it was also used for clock synchronization.
Security Implications:
While timestamp requests might seem harmless, they can be exploited by attackers:
They can be used for network reconnaissance, where attackers probe systems to see if they’re online and to map the network.
It may reveal details about a system’s internal clock or timing, which can assist in time-based attacks, such as replay attacks.

9.2 Create a rule to filter packets with Syn flag and run it against the given pcap file. What is the number of detected packets?

Open the local.rules file:

sudo nano /etc/snort/rules/local.rules

Add the rule to the file:

Comment out the old rule by adding # at the beginning of the rule line

Write the rule inside the file

alert tcp any any <> any any (msg: "SYN Packet Detected"; flags:S; sid:100002; rev:1;)

Save and Exit

Run Snort with the configuration

snort -c /etc/snort/snort.conf -A full -l . -r task9.pcap

Once Snort finishes processing, check the alert file in the current directory

cat alert

Snort detected a TCP packet with the SYN flag

To make sure only one packet was detected, to count all alerts with the message “SYN Packet Detected”

grep "SYN Packet Detected" alert | wc -l

The command output was 1, confirming that only one SYN packet was detected.

Answer: 1

9.3 Clear the previous log and alarm files and deactivate/comment out the old rule.

Write a rule to filter packets with Push-Ack flags and run it against the given pcap file. What is the number of detected packets?

Deleting the previous log and alert files to ensure no old results remain

rm alert
rm -r log/

Open the local.rules file:

sudo nano /etc/snort/rules/local.rules

Add the rule to the file

Comment out the old rule by adding # at the beginning of the rule line

Write the rule inside the file Add a new rule to detect packets with Push (P) and Acknowledgment (A) flags set

alert tcp any any <> any any (msg: "Push-Ack Packet Detected"; flags:PA; sid:100003; rev:1;)

Save and Exit

Run Snort with the configuration

snort -c /etc/snort/snort.conf -A full -l . -r task9.pcap

Once Snort finishes processing, check the alert file in the current directory

cat alert

Count all Push-Ack packets

grep "Push-Ack Packet Detected" alert | wc -l

Answer: 216

9.4 Clear the previous log and alarm files and deactivate/comment out the old rule.

Create a rule to filter packets with the same source and destination IP and run it against the given pcap file. What is the number of packets that show the same source and destination address? (Question Hint Review the logs and count the number of the alerts. Don’t consider the unassigned IP addresses, IP requests and broadcast/multicast messages.)

Deleting the previous log and alert files to ensure no old results remain

rm alert
rm -r log/

Open the local.rules file:

sudo nano /etc/snort/rules/local.rules

Add the rule to the file

Comment out the old rule by adding # at the beginning of the rule line

Write the rule inside the file Add a new rule to detect packets with Push (P) and Acknowledgment (A) flags set

alert ip any any <> any any (msg: "Same Source-Destination IP Detected"; sameip; sid:100004; rev:1;)

Save and Exit

Run Snort with the configuration

snort -c /etc/snort/snort.conf -A full -l . -r task9.pcap

Once Snort finishes processing, check the alert file in the current directory

cat alert

Filtering and Reviewing Packets with Same Source and Destination IP

grep -A 5 "Same Source-Destination IP Detected" alert > detailed_alerts.txt
cat detailed_alerts.txt

Valid Packets (Same Source and Destination IP)

12/18-21:57:47.100000 192.168.0.1:0 -> 192.168.0.1:0
12/18-21:57:47.200000 192.168.0.21:0 -> 192.168.0.21:0
12/18-21:57:47.300000 192.168.0.44:4444 -> 192.168.0.44:4444
12/18-21:57:47.400000 192.168.0.21:0 -> 192.168.0.21:0
12/18-21:57:47.500000 192.168.0.21:0 -> 192.168.0.21:0
12/18-21:57:47.600000 192.168.0.11:4444 -> 192.168.0.11:4444
12/18-21:57:47.700000 192.168.0.11:0 -> 192.168.0.11:0

There are 7 valid packets with the same source and destination IPs.

Answer: 7

9.5 Case Example — An analyst modified an existing rule successfully. Which rule option must the analyst change after the implementation?

rev (Revision) is a rule option used to indicate the version of a rule.
Whenever a rule is updated or modified, the revision number (rev) should be incremented to keep track of changes.
This helps other analysts understand the rule’s history, updates, and improvements.

Answer: erv

Task 10 Snort2 Operation Logic: Points to Remember

Points to Remember

Main Components of Snort

Packet Decoder — Packet collector component of Snort. It collects and prepares the packets for pre-processing.
Pre-processors — A component that arranges and modifies the packets for the detection engine.
Detection Engine — The primary component that process, dissect and analyse the packets by applying the rules.
Logging and Alerting — Log and alert generation component.
Outputs and Plugins — Output integration modules (i.e. alerts to syslog/mysql) and additional plugin (rule management detection plugins) support is done with this component.

There are three types of rules available for snort

Community Rules — Free ruleset under the GPLv2. Publicly accessible, no need for registration.
Registered Rules — Free ruleset (requires registration). This ruleset contains subscriber rules with 30 days delay.
Subscriber Rules (Paid) — Paid ruleset (requires subscription). This ruleset is the main ruleset and is updated twice a week (Tuesdays and Thursdays).

You can download and read more on the rules here.

Note: Once you install Snort2, it automatically creates the required directories and files. However, if you want to use the community or the paid rules, you need to indicate each rule in the snort.conf file.

Since it is a long, all-in-one configuration file, editing it without causing misconfiguration is troublesome for some users. That is why Snort has several rule updating modules and integration tools. To sum up, never replace your configured Snort configuration files; you must edit your configuration files manually or update your rules with additional tools and modules to not face any fail/crash or lack of feature.

snort.conf: Main configuration file.
local.rules: User-generated rules file.

Let’s start with overviewing the main configuration file (snort.conf) sudo gedit /etc/snort/snort.conf

Navigate to the “Step #1: Set the network variables.” section.

This section manages the scope of the detection and rule paths.

Navigate to the “Step #2: Configure the decoder.” section.

In this section, you manage the IPS mode of snort. The single-node installation model IPS model works best with “afpacket” mode. You can enable this mode and run Snort in IPS.

Data Acquisition Modules (DAQ) are specific libraries used for packet I/O, bringing flexibility to process packets. It is possible to select DAQ type and mode for different purposes.

There are six DAQ modules available in Snort;

Pcap: Default mode, known as Sniffer mode.
Afpacket: Inline mode, known as IPS mode.
Ipq: Inline mode on Linux by using Netfilter. It replaces the snort_inline patch.
Nfq: Inline mode on Linux.
Ipfw: Inline on OpenBSD and FreeBSD by using divert sockets, with the pf and ipfw firewalls.
Dump: Testing mode of inline and normalisation.

The most popular modes are the default (pcap) and inline/IPS (Afpacket).

Navigate to the “Step #6: Configure output plugins” section.

This section manages the outputs of the IDS/IPS actions, such as logging and alerting format details. The default action prompts everything in the console application, so configuring this part will help you use the Snort more efficiently.

Navigate to the “Step #7: Customise your ruleset” section.

Note that “#” is commenting operator. You should uncomment a line to activate it.

Answer the questions below

Read the task above.

Task 11 Conclusion

In this room, we covered Snort, what it is, how it operates, and how to create and use the rules to investigate threats.

Understanding and practising the fundamentals is crucial before creating advanced rules and using additional options.
Do not create complex rules at once; try to add options step by step to notice possible syntax errors or any other problem easily.
Do not reinvent the wheel; use it or modify/enhance it if there is a smooth rule.
Take a backup of the configuration files before making any change.
Never delete a rule that works properly. Comment it if you don’t need it.
Test newly created rules before migrating them to production.

Now, we invite you to complete the snort challenge room: Snort Challenge — Live Attacks

A great way to quickly recall snort rules and commands is to download and refer to the TryHackMe snort cheatsheet.