Analyzing Snort Alerts

Introduction

Snort is a powerful, open-source Intrusion Detection System (IDS) that monitors network traffic in real-time and compares it against a set of predefined rules. When suspicious activity matches a rule, Snort generates an alert. Understanding how to read and interpret these alerts is a fundamental skill for any cybersecurity professional.

Generating an alert is only the beginning of the defensive workflow. Analysts still need to decide whether the event is meaningful, what happened on the network, and whether follow-up action is required. That is why alert interpretation matters just as much as rule creation. A strong detection stack is useless if humans cannot read and triage its output accurately.

In this lab, you will learn how to interact with Snort alerts. You will start Snort with a custom configuration, generate network traffic to trigger specific detection rules, and then analyze the resulting log files. Snort can output logs in various formats; we will focus on the fast log (which provides a quick, one-line summary of the event) and the full log (which includes detailed packet header information).

Trigger Multiple Rules

In this step, you will start the Snort Intrusion Detection System and generate network traffic to trigger the custom rules that have been pre-configured for you.

Creating known-good test traffic is a standard detection engineering habit. If you know exactly which packets should trigger which rules, you have a clear baseline for validating that the monitoring pipeline is working end to end.

The environment has been set up with two simple Snort rules: one that detects ICMP (Ping) traffic and another that detects HTTP (web) traffic on port 80. We have also created a custom configuration file at /etc/snort/custom.conf that tells Snort to save alerts in two different formats: a "fast" log and a "full" log.

First, start Snort in daemon (background) mode using the custom configuration file. The -D flag tells Snort to run in the background, -c specifies the configuration file, -l specifies the log directory, and -i eth0 tells Snort to listen on the default network interface.

sudo snort -c /etc/snort/custom.conf -l /var/log/snort -i eth0 -D

You should see a message indicating that Snort has successfully initialized and daemonized.

Next, generate some network traffic to trigger the rules. We will send three ICMP ping packets to a public DNS server (8.8.8.8) to trigger the ICMP rule.

ping -c 3 8.8.8.8

Now, generate some HTTP traffic by using the curl command to fetch a web page. This will trigger the HTTP rule. We use > /dev/null to hide the HTML output from cluttering your terminal.

curl -s http://example.com > /dev/null

Finally, wait a moment for Snort to process the packets and write them to the log files. You can verify that the log files have been created by listing the contents of the Snort log directory.

sleep 2
ls -l /var/log/snort

You should see fast_alert.log and full_alert.log in the output, indicating that Snort successfully detected the traffic and generated the alerts.

total 8
-rw-r--r-- 1 root root  345 Sep 15 10:00 fast_alert.log
-rw-r--r-- 1 root root 1250 Sep 15 10:00 full_alert.log

Analyze the Fast Log

In this step, you will examine the fast_alert.log file. The "fast" alert format is designed to be easily readable and concise. It records the most critical information about an alert on a single line, making it ideal for quick reviews or for parsing with automated scripts.

This is the format many analysts interact with first because triage usually starts broad. You want to know what fired, when it fired, and which endpoints were involved before deciding whether deeper packet details are necessary.

Use the cat command to display the contents of the fast log file.

cat /var/log/snort/fast_alert.log

Your output will look similar to the following:

09/15-10:00:01.123456  [**] [1:1000001:1] ICMP Ping Detected [**] {ICMP} 192.168.1.10 -> 8.8.8.8
09/15-10:00:01.123456  [**] [1:1000001:1] ICMP Ping Detected [**] {ICMP} 8.8.8.8 -> 192.168.1.10
09/15-10:00:05.654321  [**] [1:1000002:1] HTTP Traffic Detected [**] {TCP} 192.168.1.10:45678 -> 93.184.216.34:80

Let's break down the components of a fast alert line:

• Timestamp: 09/15-10:00:01.123456 shows the exact date and time the packet was captured.
• Generator, SID, and Revision: [1:1000001:1] represents the Generator ID (1 means it's a standard Snort rule), the Snort ID (SID) which uniquely identifies the rule (1000001), and the Revision number of the rule (1).
• Message: ICMP Ping Detected is the human-readable message defined in the rule.
• Protocol: {ICMP} or {TCP} indicates the network protocol used.
• Source and Destination: 192.168.1.10:45678 -> 93.184.216.34:80 shows the source IP and port, an arrow indicating the direction of traffic, and the destination IP and port.

By reading this log, a security analyst can quickly determine who is attacking (Source IP), what their target is (Destination IP and Port), and what type of attack is suspected (Message).

Inspect Full Packet Dumps

While the fast log is great for a quick overview, it lacks the deep technical details needed for a thorough investigation. In this step, you will examine the full_alert.log file.

The full log supports a different question: not just "what alert fired?" but "what did the triggering packet actually look like?" This deeper context helps analysts validate alerts, understand protocol behavior, and investigate potential false positives or evasions.

The "full" alert format includes the complete packet header information. This allows analysts to inspect details like the Time to Live (TTL), Type of Service (TOS), packet length, and TCP flags, which can be crucial for understanding the nature of an attack or identifying false positives.

Because the full log contains multiple lines per alert, it can be quite long. Use the head command to view the first 30 lines of the file, which will show you the details of the first few alerts.

head -n 30 /var/log/snort/full_alert.log

Your output will look similar to this:

[**] [1:1000001:1] ICMP Ping Detected [**]
09/15-10:00:01.123456 192.168.1.10 -> 8.8.8.8
ICMP TTL:64 TOS:0x0 ID:12345 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:15  Seq:1  ECHO
...
[**] [1:1000002:1] HTTP Traffic Detected [**]
09/15-10:00:05.654321 192.168.1.10:45678 -> 93.184.216.34:80
TCP TTL:64 TOS:0x0 ID:54321 IpLen:20 DgmLen:60 DF
******S* Seq: 0x1A2B3C4D  Ack: 0x0  Win: 0xFAF0  TcpLen: 40

Notice the additional details provided in the full log:

• IP Header Info: TTL:64 (Time to Live), TOS:0x0 (Type of Service), ID:12345 (IP Identification), and DgmLen:84 (Datagram Length).
• ICMP Specifics: Type:8 Code:0 indicates an ICMP Echo Request (a standard ping).
• TCP Specifics: ******S* represents the TCP flags set in the packet (in this case, the SYN flag is set, indicating the start of a connection). It also shows Sequence numbers (Seq), Acknowledgment numbers (Ack), and Window size (Win).

By analyzing these full packet dumps, you can gain a much deeper understanding of the network traffic that triggered the IDS alert.

Summary

In this lab, you successfully configured and ran the Snort Intrusion Detection System to monitor network traffic. You learned how to trigger custom detection rules by generating specific types of network traffic, such as ICMP pings and HTTP requests. Furthermore, you explored the differences between Snort's fast and full alert logs, gaining hands-on experience in reading and interpreting the critical information they contain, from basic source and destination IPs to detailed packet header flags. These skills are essential for effectively monitoring network security and responding to potential threats.