Objectives
This lab is the first in a series aimed at guiding you through writing effective rules for IDS/IPS tools such as Snort and Suricata.
Details
You’ll be using the packet capture file located at /sec503/Exercises/Day3/01_exploit.pcap. The goal is to write a signature that correctly detects the exploit within the capture, which simulates a system compromise using a fictional CVE. Treat the capture as an example of traffic generated by a proof-of-concept exploit targeting a LamanServer service on a local network.
CVE-2026-0503
Description
This CVE relates to a buffer overflow in the Novak Enterprises LamanServer application. The vulnerability allows remote code execution and is triggered through traffic to TCP port 50503. Although a proof-of-concept exploit exists, there are no known instances of real-world exploitation.
The vulnerability occurs in the command parser, which only becomes accessible after the server receives a HELO command.
Exercise 1
Description: Write a rule that successfully detects the exploit in the file named 01_exploit.pcap by using one or more content options.
1) When developing rules for Snort (or similar IDS/IPS tools), it is best practice to use a custom copy of the configuration file. While it might seem easier to work with a minimal configuration specific to your testing environment, doing so may cause you to miss critical updates or necessary settings for a rule to function properly in a production environment.
First, we are going to validate the configuration file located in the etc directory:
2) Write a basic alert rule that includes only a rule header and leaves the rule options section empty. Test this rule using the 01_exploit.pcap file. Make sure the rule displays alerts in the console and saves any logs to the /sec503/Exercises/Day3/logs directory. The rule should trigger an alert for every packet in the capture file.
Let’s first open the local.rules file:
There’s already a rule in place from the previous lab. Using an editor, I am going to comment out this rule by adding a # at the beginning of the line It’s a good idea to keep the rule commented for reference.
To create a new rule header, I have to start by choosing the action the rule should perform. Possible actions include:
- alert: generate an alert
- pass: allow traffic through without further inspection
- log: log packets but don’t raise an alert
- sdrop: silently drop the packet (IPS only)
- drop: drop and log the packet (IPS only)
- reject: block the packet, log it, and send a TCP RST to reset the connection
- activate: enable a related dynamic rule if this rule matches
- dynamic: define a rule that can only be triggered by an activate rule
Next, the rule header must include the protocol, source IP, source port, direction, destination IP, and destination port. Supported protocols are:
- ip
- tcp
- udp
- icmp
Following the header, the rule must include the options section. This goes right after the destination port and must be enclosed in parentheses. In this case no options are needed, therefore I can use empty parentheses. I am going a very simple rule that generates an alert everytime a packet travelling over IP is encountered in the file:
Let’s now see the results generated by this alert:
3) Incorporating Metadata in Custom Snort Rules
When creating a custom Snort rule, it’s important to include metadata to ensure clarity, traceability, and effective alerting. For this rule, I assigned a signature ID (SID) of 1000000 and set the revision number to 1. I also defined a custom alert message to be displayed when the rule is triggered.
Metadata should reflect key contextual information. According to best practices:
The reference field links the rule to external documentation, such as CVEs or BugTraq entries. When supported, these references can be automatically converted into URLs for easier follow-up.
The rev field indicates the rule’s revision number. Each time a rule is updated, this number should be incremented. This helps avoid confusion caused by stale or outdated rules and streamlines troubleshooting.
The sid (signature ID) is a mandatory unique identifier for each rule. IDs under 1,000,000 are typically reserved, so custom rules should use higher values to prevent conflicts.
The msg field contains the message that will be displayed when the rule is triggered. This should clearly describe the nature of the alert.
4) Analyzing Packet Content for Reliable Signature Matching
As part of the analysis of 01_exploit.pcap, the objective is to identify specific content within the packets that could serve as a reliable signature for rule creation. The ideal content should be distinct enough that it won’t appear in regular network traffic, helping to minimize false positives.
Effective matching content is typically a string that is at least four bytes long—longer is better to improve match reliability. If shorter strings must be used, they should be supplemented by longer, more unique strings to ensure accurate detection.
Snort prioritizes locating the longest matching string, particularly one found at a known offset or near the beginning of the packet payload. Understanding how Snort evaluates packet data in this way is key to crafting precise and effective intrusion detection rules.
I am going to use tcpdump to look at the first 10 packets payload in this file:
I am going to use the payload in the 9th packet as a signature for my Alert. We have 3 strings that can be used as content for this signature: a series of Xs followed by PH/bin and 2/sh. Using this payload in the options’ content section, we write the below alert:
Let’s make sure that the alert wroks as intended:
