Intrusion Detection Lab Guide: Snort and Pattern Detection

Setup

For this lab we need to VMs you can find them in your weekly folder Week-9:

  • Victim to do all the work (collecting traffic and generate rules) o
    • Username:victim, password: victimvm
  • Admin to test some rules and to generate traffic
    • Username:csf_vm1, password: kalivm1.

Part1: Understanding Snort

Section 1: Understanding Snort and Its Purpose

1. What is Snort?

Definition: Snort is an open-source Network Intrusion Detection System (NIDS) designed to monitor network traffic in real time, identify suspicious patterns, and generate alerts for potentially malicious activities.

  • Applications: Snort can be used for multiple purposes, such as:
    • Real-time traffic monitoring and packet analysis.
    • Alerting on potentially harmful activity based on defined rules.
    • Acting as an Intrusion Prevention System (IPS) when configured with active blocking.

3. How Snort Works

Basic Components:

  • Packet Decoder (Sniffer): Reads raw network traffic and passes it to the preprocessor.

  • Preprocessor: Normalises packets (e.g., fragments reassembled) and prepares them for inspection.

  • Detection Engine: Applies Snort rules to identify suspicious patterns.

  • Logging and Alerting (output): Logs detected events and generates alerts based on configured rules.

    bg

Example Workflow: A packet enters the network, passes through Snort’s decoder, is inspected by various preprocessors, matched against Snort rules, and if a rule matches, it’s logged and an alert is generated.


4. Key Snort Terminology

  • IDS (Intrusion Detection System): A system designed to detect malicious activity on a network.
  • Rule: A specific instruction for detecting network patterns, like recognising a certain type of packet or a sequence of packets.
  • Alert: A notification generated by Snort when it detects activity matching a rule.
  • Packet: A unit of data routed between an origin and a destination in a network.
  • TCP/UDP/ICMP: Common network protocols Snort can inspect.
  • Preprocessor: A module in Snort that processes packets to make detection more effective (e.g., normalising fragmented packets).

5. Snort Operating Modes

Overview of Modes:

  • Sniffer Mode: Captures and displays network traffic in real time, like a basic packet sniffer.
  • Packet Logger Mode: Records network traffic to a log file, enabling later analysis.
  • Intrusion Detection Mode: Monitors network traffic in real time and checks for suspicious activity based on defined rules.

Activity:

  • For each mode, explain when it might be used in real-world scenarios?

    Click to view possible answers
    • Sniffer Mode: Quick traffic inspection or debugging network issues.

    • Packet Logger Mode: Collecting data for forensic analysis.

    • Intrusion Detection Mode: Monitoring a network for active threats.





Section-2: Working with Snort (on the Victim Machine, please)

I highly recomand to do your lab on an UBUNTU machine and not Kali this time.

Snort is already installed on your lab vm, but if you're using your own machine please using this to install it:

sudo apt install snort
  1. Verify Installation:

    snort --version
    
  2. File and Directory Structure:

    • Explain key configuration files:
      • snort.conf or snort.lua (if you're using Kali): The main configuration file where Snort’s operational settings are defined.
        sudo nano /etc/snort/snort.conf
        
      • rules/: Directory containing various rule files Snort uses to detect specific traffic patterns.
    • Task: Navigate to Snort’s Rules directory (usually /etc/snort/rules) and view the contents.
      • Navigate:
        cd /etc/snort/rules
        
      • List:
        ls
        

A directory containing the Snort rules files. Files within typically follow a naming convention, like:

  • local.rules: Custom rules written by the user.
  • community.rules: Community-contributed rules.
  • Protocol-specific rules: like dns.rules, http.rules, icmp.rules, etc., for detecting protocol-specific patterns.
  • preproc_rules: Contains configuration files for Snort’s preprocessors, which help in normalising or decoding traffic before rule inspection. Examples include frag3.conf (for fragment reassembly) and sfportscan.conf (for port scanning).
  1. Validating the Snort Configuration File

    Before we start using Snort, let's make sure that our configuration file is valid. Testing the configuration file ensures that there are no syntax errors or misconfigurations that could prevent Snort from running correctly.

    To test the configuration file, use the -T option. This flag tells Snort to run in test mode, where it checks the configuration file without actually starting the IDS/IPS process. The -c option specifies the configuration file path (in our case, snort.conf).

    Run the following command:

sudo snort -T -c /etc/snort/snort.conf
  • T: Enables test mode, which validates the configuration.
  • c: Specifies the path to the configuration file. This allows you to use a different configuration file if needed by pointing to it with -c.

If the configuration file is correct, you’ll see a message indicating that Snort has successfully validated the configuration. If there are any errors, Snort will display them so you can troubleshoot.

Every time you start Snort, it will automatically display the default banner and initial setup information. You can suppress this display by using the -q parameter.

Useful Snort Parameters

ParameterDescription
-V / --versionDisplays version information about your Snort instance.
-cSpecifies the configuration file to be used.
-TRuns Snort in self-test mode to check your setup without starting the IDS/IPS process.
-qQuiet mode; prevents Snort from displaying the default banner and initial setup information.

Section-3: Running Snort in Sniffer Mode

Like tcpdump or Wireshark (from Network Protocals Module), Snort can be used in Sniffer mode with various flags to display different types of packet data. The table below explains the Sniffer mode parameters:

ParameterDescription
-vVerbose mode. Displays the TCP/IP output in the console.
-dDisplays the packet data (payload).
-eDisplays the link-layer (TCP/IP/UDP/ICMP) headers.
-XDisplays the full packet details in HEX.
-iSpecifies a network interface to listen/sniff on. If multiple interfaces exist, choose one.

Let's start using each parameter and observe the differences between them.

Sniffing with Parameter -i

To run the following command, you’ll need to identify the network adapter you want to sniff packets from, such as Wi-Fi or Ethernet. To find it, run ifconfig as shown below. Look for the adapter name associated with your IP address (e.g., enp0s3 in this example), though the name may vary based on your setup.

bg

Start Snort in verbose mode (-v) on the interface Please add interface:

sudo snort -v -i enp0s3

Note: If you have only one interface, Snort will use it by default. In this example, we're explicitly setting it to eth0.

Sniffing with Parameter -v

Start Snort in verbose mode:

sudo snort -v

Generate traffic: Next, try to generate ICMP traffic by pinging this machine from a different one. You should be able to see alerts corresponding to ICMP traffic in the Snort console. Alternatively, if you're using your own machine, try opening a webpage to generate HTTP traffic, and observe how different types of traffic are detected and logged. Snort will start displaying packets in verbose mode as follows:

As you can see, verbosity mode provides tcpdump-like output. To stop sniffing, press CTRL+C, and Snort will summarise the sniffed packets. to exit press CTRL+X

Sniffing with Parameter -d

Start Snort in packet data display mode:

sudo snort -d

Now, create traffic again using ping (or if you're using your own machine, open a webpage, etc.). Snort will show packets in a more detailed view, including packet payload data.

In -d mode, Snort includes payload data on top of what’s shown in verbose mode.

Sniffing with Parameter -de

Start Snort with both packet data (-d) and link-layer headers (-e):

sudo snort -d -e

After generating traffic with the using ping or HTTP, Snort will display both payload data and link-layer headers.

Sniffing with Parameter -X

Start Snort in full packet dump mode, displaying data in HEX:

sudo snort -X

Once the traffic is generated, Snort will display packets in HEX format, showing full details of each packet.


Section 4: Running Snort in Logger Mode

Snort can be used in Logger mode to log sniffed packets. By using packet logger mode parameters, Snort will automatically capture and log network traffic.

Packet Logger Parameters

ParameterDescription
-lLogger mode. Specifies the target directory for log and alert output. Default is /var/log/snort.
-K ASCIILogs packets in ASCII format.
-rReads dumped logs in Snort.
-nSpecifies the number of packets to process or read before stopping.

Let’s explore each parameter to see the differences. Note: Snort requires active traffic on the network interface, so generate traffic using the ping or web activities if you are using your own machine script.

Log File Ownership

Before generating logs, remember that Snort requires superuser (root/su) privileges to sniff traffic. When run with sudo, the "root" account owns the generated log files, so you may need elevated privileges to investigate them. There are two main ways to access these logs:

  1. Elevate privileges: Use sudo to examine files, or switch to superuser mode with sudo su.
  2. Change file ownership: Change file ownership with sudo chown username file or sudo chown username -R directory for recursive access.

Logging with -l

Run Snort in logger mode with:

sudo snort -dev -l  "your path"

if you're using the victim machine, you can save it in the home dir:

sudo snort -dev -l  /home/victim/

This logs packets in the current directory. You can configure the default output directory in snort.conf or use -l to specify a directory. This is useful for organising logs in different folders for testing.

Reading Generated Logs with -r

To read binary logs, use:

sudo snort -r logname

so if you kept the file in the home dir, your cmd would be :

sudo snort -r /home/victim/snort.log.17131939362

The number at the end of the file is random based on time so might not be the same.

Snort can read and display logs in a format similar to Sniffer mode. This parameter supports filters and formats like tcpdump or Wireshark.

Example Filters:

  • Display HEX output: sudo snort -r logname.log -X
  • Filter ICMP packets: sudo snort -r logname.log icmp
  • Filter for UDP packets on port 53: sudo snort -r logname.log 'udp and port 53'

Additionally, you can use the -n parameter to limit packet processing. For example, process only the first 10 packets with:

sudo snort -dvr logname.log -n 10

Section 5: Intrusion Detection Mode (Snort Rule Configuration and Testing)

Step 1: Understanding Snort Rules

A Snort rule is composed of:

  • Action: What Snort does if the rule matches (e.g., alert).

  • Protocol: The protocol to match (e.g., icmp, tcp).

  • Source/Destination: The IPs and ports involved.

  • Message: The message to display in the alert log.

    bg

  • Each Snort rule must define an action, protocol, source and destination IP, source and destination port, and an optional rule component. By default, Snort operates in passive (IDS) mode; to enable IPS mode, you need to activate "inline mode."

  • Creating efficient Snort rules requires familiarity with rule options and details, so practicing with various use cases is recommended. Here, we’ll cover the basics of Snort rule structure and explore two primary actions:

    • "alert" for IDS mode and
    • "reject" for IPS mode.
  • While rule options are technically optional, they are essential for detecting complex attacks, as rules cannot function without a header.

CategoryParameterDescription
ActionalertGenerates an alert and logs the packet.
logLogs the packet.
dropBlocks and logs the packet.
rejectBlocks the packet, logs it, and terminates the session.
ProtocolIP, TCP, UDP, ICMPSpecifies the protocol to filter for the rule. Snort supports only these four protocols natively. For example, to detect FTP traffic, use the TCP protocol on port 21.

Task: Go throught table below and try to provide interpretation and type of filtering (Few should be enough)

Filtering TypeSnort RuleDescription
IP Filteringalert icmp 192.168.1.56 any <> any any (msg: "ICMP Packet From "; sid: 100001; rev:1;)Creates an alert for each ICMP packet originating from the 192.168.1.56 IP address.
??alert icmp 192.168.1.0/24 any <> any any (msg: "ICMP Packet Found"; sid: 100001; rev:1;)Please provide interpretation.
??alert icmp [192.168.1.0/24, 10.1.1.0/24] any <> any any (msg: "ICMP Packet Found"; sid: 100001; rev:1;)Please provide interpretation.
??alert icmp !192.168.1.0/24 any <> any any (msg: "ICMP Packet Found"; sid: 100001; rev:1;)Please provide interpretation..
??alert tcp any any <> any 21 (msg: "FTP Port 21 Command Activity Detected"; sid: 100001; rev:1;)Please provide interpretation.
??alert tcp any any <> any !21 (msg: "Traffic Activity Without FTP Port 21 Command Channel"; sid: 100001; rev:1;)Please provide interpretation.
??alert tcp any any <> any 1:1024 (msg: "TCP 1-1024 System Port Activity"; sid: 100001; rev:1;)Please provide interpretation.
??alert tcp any any <> any :1024 (msg: "TCP 0-1024 System Port Activity"; sid: 100001; rev:1;)Please provide interpretation.
??alert tcp any any <> any 1025: (msg: "TCP Non-System Port Activity"; sid: 100001; rev:1;)Please provide interpretation.
??alert tcp any any <> any [21,23] (msg: "FTP and Telnet Port 21-23 Activity Detected"; sid: 100001; rev:1;)Please provide interpretation.
Click to view interpretations
Filtering TypeSnort RuleDescription
Filter an IP rangealert icmp 192.168.1.0/24 any <> any any (msg: "ICMP Packet Found"; sid: 100001; rev:1;)Creates an alert for each ICMP packet originating from the 192.168.1.0/24 subnet.
Filter multiple IP rangesalert icmp [192.168.1.0/24, 10.1.1.0/24] any <> any any (msg: "ICMP Packet Found"; sid: 100001; rev:1;)Creates an alert for each ICMP packet originating from the 192.168.1.0/24 and 10.1.1.0/24 subnets.
Exclude IP addresses/rangesalert icmp !192.168.1.0/24 any <> any any (msg: "ICMP Packet Found"; sid: 100001; rev:1;)Creates an alert for each ICMP packet not originating from the 192.168.1.0/24 subnet.
Port Filteringalert tcp any any <> any 21 (msg: "FTP Port 21 Command Activity Detected"; sid: 100001; rev:1;)Creates an alert for each TCP packet sent to port 21.
Exclude a specific portalert tcp any any <> any !21 (msg: "Traffic Activity Without FTP Port 21 Command Channel"; sid: 100001; rev:1;)Creates an alert for each TCP packet not sent to port 21.
Filter a port range (Type 1)alert tcp any any <> any 1:1024 (msg: "TCP 1-1024 System Port Activity"; sid: 100001; rev:1;)Creates an alert for each TCP packet sent to ports between 1-1024.
Filter a port range (Type 2)alert tcp any any <> any :1024 (msg: "TCP 0-1024 System Port Activity"; sid: 100001; rev:1;)Creates an alert for each TCP packet sent to ports less than or equal to 1024.
Filter a port range (Type 3)alert tcp any any <> any 1025: (msg: "TCP Non-System Port Activity"; sid: 100001; rev:1;)Creates an alert for each TCP packet sent to source port higher than or equal to 1025.
Filter specific portsalert tcp any any <> any [21,23] (msg: "FTP and Telnet Port 21-23 Activity Detected"; sid: 100001; rev:1;)Creates an alert for each TCP packet sent to ports 21 and 23.

Step 2: Rules options

bg

OptionDescription
msgA quick identifier that appears in the console or log when the rule triggers. Provides a brief summary.
sidSnort rule ID. Should be unique and >= 1,000,000 for user-created rules. Avoid overlap with reserved IDs.
referenceAdditional information, such as CVE IDs, useful for incident investigation.
revRevision number for tracking rule updates. Helps analysts understand rule improvements over time. Version Control

Example Rule:

alert icmp any any <> any any (msg: "ICMP Packet Found"; sid: 100001; reference:cve,CVE-XXXX; rev:1;)

Step 2: Payload options

OptionDescription
contentMatches specific payload data (ASCII or HEX). Multiple content options can be used in a rule, though more matches increase processing time.
nocaseDisables case sensitivity in content matching, useful for broader searches.
fast_patternPrioritises content search, speeding up the match operation. Recommended when using multiple content options.
alert tcp any any <> any 80  (msg: "GET Request Found"; content:"GET"; fast_pattern; content:"www";  sid:100001; rev:1;)

Step 4: Non-Payload Detection Rule Options (FYI)

OptionDescription
idFilters based on the IP ID field.
flagsFilters TCP flags, such as F (FIN), S (SYN), R (RST), P (PSH), A (ACK), U (URG).
dsizeFilters packet payload size. Specify a range (e.g., dsize:100<>300) or use greater/less than (dsize:>100).
sameipTriggers if source and destination IPs are the same.

Example Rules:

  • ID Filtering: alert tcp any any <> any any (msg: "ID TEST"; id:123456; sid: 100001; rev:1;)
  • TCP Flag Filtering: alert tcp any any <> any any (msg: "FLAG TEST"; flags:S; sid: 100001; rev:1;)
  • Payload Size Filtering: alert ip any any <> any any (msg: "SEQ TEST"; dsize:100<>300; sid: 100001; rev:1;)
  • Same IP Filtering: alert ip any any <> any any (msg: "SAME-IP TEST"; sameip; sid: 100001; rev:1;)

Step 5: Setting Up the Rule

ICMP rule

1.. Navigate to the Rules Directory
Open a terminal on the victim machine (victim) and navigate to the Snort rules directory:

cd /etc/snort/rules
  1. Edit the Local Rules File
    Open the local.rules file using a text editor:

    sudo nano local.rules
    
  2. Add the ICMP Ping Rule
    Add the following rule to detect ICMP echo requests (ping):

    alert icmp any any <> any any (msg:"FCS_Check_19133: ICMP Ping Detected"; sid:1000001; rev:1;)
    
    • msg: Message to display in the alert.
    • sid: A unique identifier for the rule.
    • rev:1: version 1.
  3. Save and Exit
    Save the file (Ctrl+O, then Enter) and exit the editor (Ctrl+X).

  4. Verify the Configuration
    Test Snort to ensure there are no syntax errors:

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

    You should get a long message saying that Snort successfully validated the configration

Testing the Rule

  1. Start the Snort Console: Open a terminal on the victim machine (victim) and start Snort in console mode, using the network interface you identified earlier with ifconfig or ip a:

    sudo snort -A console -q -c /etc/snort/snort.conf -i enp0s3
    
  • -A console: Displays alerts in the terminal.
  • -q Suppresses extra output for a cleaner console.
  • -c /etc/snort/snort.conf: Specifies the configuration file.
  • -i enp0s3: Replace enp0s3 with the name of your network interface.

Snort will now wait for traffic and display alerts in the terminal.

  1. Send a Ping Request From another machine (the Admin machine), send a ping to the victim machine. Open a terminal on the admin machine and run the following command:

    ping <YOUR_IP_ADDRESS>
    

Replace <YOUR_IP_ADDRESS> with the IP address of the victim machine (where you defined the rule).

Now you should be able to see alerts with messages

Adding the SSH Detection Rule

Before testing, ensure the following rule is added to the local.rules file on the victim machine. This rule will trigger an alert whenever an SSH connection attempt is detected:

  1. Navigate to the Rules Directory
    Open a terminal and navigate to the Snort rules directory:

    cd /etc/snort/rules
    
  2. Edit the Local Rules File
    Open the local.rules file for editing:

    sudo nano local.rules
    
  3. Add the SSH Detection Rule
    Add the following rule to detect SSH connection attempts:

    alert tcp any any <> any 22 (msg:"FCS_19133_SSH Connection Attempt Detected"; sid:1000002; rev:1; flags:S; priority:3; content:"SSH"; nocase;)
    
    • msg: Message displayed in the alert.
    • sid: A unique identifier for the rule.
    • flags:S: Matches TCP SYN packets (indicating a connection attempt).
    • content:"SSH": Looks for the SSH protocol string in the packet.
    • nocase: Makes the match case-insensitive.
  4. Save and Exit
    Save the file (Ctrl+O, then Enter) and exit the editor (Ctrl+X).

  5. Verify the Configuration
    Test Snort to ensure there are no syntax errors:

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

Testing the Rule

  1. Start the Snort Console
    Open a terminal on the victim machine (victim) and start Snort in console mode, using the network interface you identified earlier with ifconfig or ip a:

    sudo snort -A console -q -c /etc/snort/snort.conf -i enp0s3
    
    • -A console: Displays alerts in the terminal.
    • -q: Suppresses extra output for a cleaner console.
    • -c /etc/snort/snort.conf: Specifies the configuration file.
    • -i enp0s3: Replace enp0s3 with the name of your network interface.

    Snort will now wait for traffic and display alerts in the terminal.

  2. Send an SSH Connection Attempt
    From another machine (the admin machine), attempt to establish an SSH connection to the victim machine. Open a terminal on the admin machine and run the following command:

    ssh <USERNAME>@<VICTIM_IP_ADDRESS>
    
    • Replace <USERNAME> with the SSH username on the victim machine (e.g., victim).
    • Replace <VICTIM_IP_ADDRESS> with the IP address of the victim machine.

    You may get a prompt asking for a password or to accept the host key. Simply attempt the connection—there is no need to log in.

    Now you should see alerts in the Snort console with messages indicating the detection of SSH traffic.

Task: Detecting Nmap Scanning Activity

In this task, we will create a Snort rule to detect and alert on Nmap scanning activity. This is a common reconnaissance technique used by attackers, and detecting it is crucial in a security context.


Adding the Nmap Detection Rule

  1. Navigate to the Rules Directory
    Open a terminal and navigate to the Snort rules directory on the victim machine:

    cd /etc/snort/rules
    
  2. Edit the Local Rules File
    Open the local.rules file for editing:

    sudo nano local.rules
    
  3. Add the Nmap Detection Rule
    Add the following rule to detect Nmap scans:

    alert tcp any any <> any any (msg:"Nmap Scan Detected"; sid:1000003; rev:1; flags:S; threshold:type limit, track by_src, count 10, seconds 1; priority:2;)
    
    • msg: Message displayed in the alert.
    • sid: A unique identifier for the rule.
    • flags:S: Matches TCP SYN packets (common in Nmap scans).
    • threshold: Limits alerts to trigger if more than 10 SYN packets are sent by the same source within 1 second.
    • priority: Sets the alert priority.
  4. Save and Exit
    Save the file (Ctrl+O, then Enter) and exit the editor (Ctrl+X).

  5. Verify the Configuration
    Test Snort to ensure there are no syntax errors:

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

Testing the Rule

  1. Start the Snort Console
    On the victim machine, start Snort in console mode:

    sudo snort -A console -q -c /etc/snort/snort.conf -i enp0s3
    

    Replace enp0s3 with the name of your network interface.

    Snort will now monitor traffic and display alerts in the terminal.

  2. Run an Nmap Scan
    From the admin machine, perform an Nmap scan targeting the victim machine. Open a terminal on the admin machine and run the following command:

    nmap -sS <VICTIM_IP_ADDRESS>
    
    • Replace <VICTIM_IP_ADDRESS> with the IP address of the victim machine.
    • -sS: Performs a TCP SYN scan.

    You can also try different scan types, such as -sT for a full TCP connect scan or -sU for a UDP scan.

  3. Check for Alerts
    Switch back to the Snort console on the victim machine. You should see alerts like:

    [**] [1:1000003:1] Nmap Scan Detected [**]
    

More:

  • Extra info about Snort
  • You can you create/form your Snort Rules online using this