Skip to content

Snort Hands-on Labs

Choose the route that fits your available time and computing resources. Use the Interactive Lab for a short guided investigation, or the Full Lab to build and operate a Snort sensor in virtual machines.

Hands-on proof of concept

Build it. Detect it. Explain it.

Start with one Snort sensor and one traffic generator, prove the packet path, make a predictable local rule fire, then remove a demonstrated overmatch. Add HTTP inspection, passive sensing, and inline prevention after the core works.

⏱ 4–7 hours core ◆ Guided beginner ✓ Evidence required
Start building
Self-hosted · Several hours

Snort Full Lab

Installation required

How this differs from the demonstrations

This is not a screenshot transcript. It gives you commands, checkpoints, and success criteria while leaving room to diagnose your environment. Your interface names, versions, DAQ modules, and alert details may differ.

Use an isolated, authorised environment

Generate traffic only against systems you own or are authorised to test. Keep the Beginner Core Lab passive. Inline prevention is an optional extension requiring console access, a snapshot, and a tested rollback.

Before you begin

You need: an x86-64 computer with virtualisation enabled, administrator access, approximately 16 GB of available RAM, 100 GB of free disk space, and temporary internet access or a verified offline installation bundle.

How to use this lab

Complete one session at a time. Stop when a checkpoint fails; prove the packet path before changing rule logic, loggers, or DAQ configuration.

Recommended

Beginner Core Lab

Use one Ubuntu Snort sensor and one Linux generator. Complete the ICMP rule, PCAP reproduction, tuning, and handoff before adding another topology.

Expected time: 4–7 hours across three sessions.

Optional extension

Complete PoC

Add the HTTP challenge, community rules, PulledPork, a mirrored passive sensor, pfSense, or inline IPS only after the core checkpoints pass.

Expected time: one or more additional sessions.

  1. Session 1Build and verify2–3 hours
  2. Session 2Detect and reproduce1–2 hours
  3. Session 3Tune and explain1–2 hours

Objective

You are validating a small Snort 3 deployment for a SOC demonstration. Build the two-machine core, prove that traffic reaches the selected interface, detect a controlled ICMP exchange, reproduce the result from a PCAP, tune a real overmatch, and produce a record another analyst can follow.

The Beginner Core Lab consists of:

  • one x86-64 Ubuntu Snort sensor with one lab interface;
  • one disposable Linux traffic generator;
  • one isolated virtual network with synchronised clocks and snapshots; and
  • one local ICMP rule with a predictable SID and controlled test traffic.

Understand sensor placement

Before choosing commands, decide which relationship the sensor has with the traffic. Is it watching traffic involving itself, receiving a copy, or sitting in the real path? That choice determines what the sensor can see, whether it can block, and what happens if it fails.

Recommended first

Host-based network IDS

The engine watches traffic entering or leaving the same computer on which it runs. This is the simplest placement for a first rule-writing lab.

Interfaces: one lab NIC Can block directly: no Failure impact: host monitoring is lost

Observe a copy

Passive IDS

A TAP, SPAN port, or virtual mirror sends the sensor a copy while the original traffic continues to its destination.

Interfaces: management + capture Can block directly: no Failure impact: monitoring is lost

Higher disruption risk

Inline IPS

Real traffic must cross the sensor or be queued to it. The engine can allow or drop packets before they continue.

Interfaces: depends on inline method Can block directly: yes Failure impact: connectivity can fail

Choose the smallest useful placement

  • First Snort or Suricata lab: use host-based network IDS.
  • Need to observe traffic between other systems: use passive IDS and prove the copy reaches the capture interface.
  • Need to stop traffic: use inline IPS only after testing console access, bypass, rollback, and recovery.

Passive IDS: observe a copy

The client-to-server packet does not pass through the sensor. If the sensor stops, normal traffic normally continues, but monitoring is lost.

Inline IPS: inspect the real traffic path

The sensor can block, but a failure or unsuitable rule can interrupt connectivity. Keep console access and a tested bypass or rollback.

Network security monitoring adds investigation context

A passive sensor can collect connections, protocols, DNS, HTTP, TLS, file, and packet metadata even when no signature fires. This broader evidence is commonly called network security monitoring, or NSM.

How passive traffic reaches the sensor
Method What it does What to verify
Network TAP A physical device on a link makes a copy of passing traffic. The sensor receives both directions without entering the forwarding path.
SPAN or mirror port A switch or virtual switch copies selected ports or VLANs to the sensor. Unicast traffic between two other systems reaches the capture NIC; overloaded mirrors can omit packets.

An ordinary endpoint interface normally cannot see unicast traffic exchanged by two other hosts. Prove the TAP, SPAN, or virtual mirror before troubleshooting rules or log output.

How inline enforcement works
NFQUEUE: let the Linux firewall ask for a verdict

Only traffic selected by the firewall rule is queued. Verify that the firewall counter increases and its queue number matches the queue opened by the engine.

Paired-interface inline mode

Suricata commonly calls this AF_PACKET inline mode; Snort uses the applicable DAQ and paired-interface configuration for the installed release. Naming one interface is not enough: verify that traffic genuinely enters one side and exits the other.

Verify the chosen placement

Placement Minimum proof
Host-based network IDS The sensor sees traffic entering or leaving itself.
Passive IDS The capture interface sees unicast traffic between two other systems.
NFQUEUE inline Firewall counters increase and the engine opens the matching queue.
Paired-interface inline Ingress and egress counters show the test traffic crossing both sides.

Use these terminal names throughout the lab:

Terminal Machine Purpose
Snort console Sensor Validate and run Snort
Capture console Sensor Verify packets and save a PCAP
Generator terminal Generator Send the controlled traffic

01

Activity 1: Build the environment

Download checklist

Record the filename, version, architecture, source, checksum, licence or registration condition, and download date for every item.

Required for the Beginner Core Lab
Item Purpose Authoritative source
Hypervisor Isolated virtual networking and snapshots The selected vendor's official documentation
Ubuntu Server ISO Operating system for both core VMs Ubuntu releases
Snort source archive Detection engine Official Snort downloads
Compatible LibDAQ archive Packet-acquisition modules Official LibDAQ repository
Build dependencies Reproducible connected or offline build Matching Ubuntu repositories and the installation journey

Rules and vendor access

Community or licensed rules are not required for the core local-rule exercise. Some rule downloads require registration, an Oinkcode, or a subscription. Never place credentials in screenshots, shell history, source control, or shared notes.

Create the virtual machines

VM Suggested lab allocation Interface Example address
Snort sensor 4 vCPU, 8 GB RAM, 60 GB disk One core-lab NIC 10.0.0.22
Linux generator 2 vCPU, 4 GB RAM, 30 GB disk One core-lab NIC 10.0.0.29
  1. Enable hardware virtualisation and install a hypervisor with isolated networking and snapshot support.
  2. Create the isolated core-lab network. Provide NAT only while an authorised machine requires downloads or updates.
  3. Create the sensor and generator VMs, install Ubuntu, and configure their hostnames, addresses, DNS, and time synchronisation.
  4. Confirm the two machines can reach each other and do not overlap with a connected production network.
  5. Apply the selected OS baseline and take a base-os snapshot.
  6. Follow Install Snort 3, recording source and transfer checksums.
  7. Take a snort-installed snapshot after the configuration validates.

On the Snort console, record the technical baseline:

date --iso-8601=seconds
uname -a
/usr/local/bin/snort -V
/usr/local/bin/snort --daq-list
sudo /usr/local/bin/snort -c /usr/local/etc/snort/snort.lua -T
sha256sum /usr/local/etc/snort/snort.lua /usr/local/etc/rules/*.rules
ip -brief address
ip -s link show <SENSOR_INTERFACE>

On the Capture console, prove visibility before testing a rule:

sudo tcpdump -ni <SENSOR_INTERFACE> -c 6 icmp

While that command waits, run this from the Generator terminal:

ping -c 3 10.0.0.22

Keep one packet line and the sensor-interface counter change. If tcpdump shows nothing, stop here and fix the network or interface selection.

Milestone 1Packet path provenBoth VMs have recorded addresses and synchronised clocks, Snort validates, and the selected sensor interface sees the controlled ICMP exchange.
Optional sensor topologies and PoC components

The Beginner Core Lab uses the host-IDS profile. Add another profile only after the local packet path works.

Optional item Purpose
Community or licensed rules Wider detection content
PulledPork 3 Pinned ruleset retrieval and staging
Target server Separate destination for passive or inline testing
pfSense or another firewall Controlled routing and firewall integration
Dedicated capture and management NICs Mirrored passive or inline placement

For passive monitoring, verify that the TAP, SPAN port, or virtual-switch mirror delivers third-party unicast traffic. For inline testing, keep management on a separate path.

Expected result Both core VMs are recoverable and synchronised, Snort reports the intended engine and DAQ versions, its configuration validates, and the selected interface captures the authorised ICMP traffic.

02

Activity 2: Detect and reproduce

Follow the checkpoints in order. Do not troubleshoot a rule until the packet checkpoint passes.

  1. The VMs can communicateConfirm addresses, time synchronisation, and the isolated network.
  2. Snort validatesRun snort -T and resolve the first reported error before continuing.
  3. The interface sees packetsUse tcpdump to observe the generator's ICMP request.
  4. The local rule loadsConfirm SID 1000001 is included and the foreground sensor starts.
  5. The first alert is writtenMatch its SID, addresses, timestamp, and revision to the generated packet.

Follow Create and Test Local Rules to set HOME_NET, include local.rules, and enable alert_fast. Add this deliberately broad starter rule:

alert icmp any any -> 10.0.0.22 any (
    msg:"LOCAL LAB ICMP echo request";
    itype:8;
    sid:1000001;
    rev:1;
)

Adapt the destination if your plan differs. On the Snort console, validate and start the sensor:

sudo /usr/local/bin/snort -c /usr/local/etc/snort/snort.lua -T
sudo install -d -o root -g root -m 0755 /var/log/snort
sudo /usr/local/bin/snort \
  -c /usr/local/etc/snort/snort.lua \
  -i <SENSOR_INTERFACE> -A alert_fast -l /var/log/snort

From the Generator terminal, record the time and send exactly three requests:

date --iso-8601=seconds
ping -c 3 10.0.0.22

Confirm the original alert output contains SID 1000001, revision 1, the generator source, sensor destination, and matching time. Explain any alert-count difference rather than forcing a specific count.

Run a negative and restart test

On the Snort sensor, ping the generator:

date --iso-8601=seconds
ping -c 3 10.0.0.29

Snort can see the packets, but SID 1000001 should not fire because the destination is not 10.0.0.22. Record the command, time window, packet proof, and alert search. Restart foreground Snort with the same command, repeat the positive generator test, and confirm the rule still loads and fires.

Save and analyse the traffic

Use two terminals so the capture lifecycle is unambiguous.

  1. On the Capture console, start a six-packet capture:
sudo tcpdump -ni <SENSOR_INTERFACE> -c 6 -w snort-core-test.pcap \
  'icmp and host 10.0.0.29 and host 10.0.0.22'
  1. While it waits, repeat ping -c 3 10.0.0.22 from the Generator terminal.
  2. Wait for tcpdump to report six captured packets. If packet loss prevents completion, press Ctrl+C, remove the incomplete file, and repeat.
  3. On the Capture console, calculate the checksum:
sha256sum snort-core-test.pcap

Follow Analyse a PCAP with a separate output directory. Confirm the same SID appears and retain the PCAP checksum, Snort command, configuration and ruleset checksums, and result.

Milestone 2Detection reproducedThe controlled packet reaches Snort, SID 1000001 fires only for the intended destination, survives restart, and produces the same result from the saved PCAP.
Need help proving the alert path?

Check the boundaries in order:

  1. tcpdump sees the packet on the selected interface.
  2. snort -T validates the configuration and local rule.
  3. The live command uses the same interface and configuration.
  4. The packet fields agree with the rule header and itype option.
  5. alert_fast writes to the expected output and permissions allow it.

Change only one boundary at a time and keep the first failing proof.

Expected result The authorised positive test produces SID 1000001, the destination-based negative test avoids that SID, the result survives restart, and the saved PCAP reproduces the detection offline.

03

Activity 3: Tune and explain

Restore or clone the snort-installed snapshot if needed. Confirm the configuration validates and repeat the known positive test before changing the rule.

Demonstrate the overmatch

The revision 1 rule accepts echo requests from any source. On the isolated Generator terminal, add a temporary secondary address and ping the sensor:

sudo ip address add 10.0.0.30/24 dev <GENERATOR_INTERFACE>
date --iso-8601=seconds
ping -I 10.0.0.30 -c 3 10.0.0.22

Confirm revision 1 fires. This is the controlled overmatch you will remove.

Tune and retest

Constrain the source and increment the revision:

alert icmp 10.0.0.29 any -> 10.0.0.22 any (
    msg:"LOCAL LAB ICMP echo request";
    itype:8;
    sid:1000001;
    rev:2;
)

Validate and restart Snort. Run both tests:

  • ping -c 3 10.0.0.22 from 10.0.0.29 should produce revision 2.
  • ping -I 10.0.0.30 -c 3 10.0.0.22 should not produce revision 2.

Remove the temporary address after recording the result:

sudo ip address del 10.0.0.30/24 dev <GENERATOR_INTERFACE>

Explain what the new condition excludes, what benign traffic can still match, what the alert establishes, and why the exact source constraint may not suit a production network unchanged.

Investigate the evidence

Answer these questions:

  • Which packet fields satisfied the rule header and itype option?
  • Did the source, destination, and direction agree with the rule?
  • What evidence supports the result beyond the alert message?
  • What benign explanation could produce the same match?
  • Which endpoint, DNS, HTTP, TLS, or firewall evidence would add confidence?
  • What false-positive or performance effect could the rule have at scale?
  • Why would changing alert to drop require a separate safety decision?
Level 2 challenge: detect an HTTP response marker

This challenge is optional but keeps the application-inspection exercise available after the ICMP workflow succeeds.

On the sensor/server terminal, create two benign files and start a temporary server bound only to the lab address:

mkdir -p "$HOME/snort-http-lab"
cd "$HOME/snort-http-lab"
printf 'SNORT-LAB-MARKER-2026\n' > marker.txt
printf 'ordinary lab response\n' > comparison.txt
python3 -m http.server 8080 --bind 10.0.0.22

Add and validate this rule:

alert http 10.0.0.22 8080 -> 10.0.0.29 any (
    msg:"LOCAL LAB HTTP response marker";
    flow:to_client,established;
    http_server_body;
    content:"SNORT-LAB-MARKER-2026";
    sid:1000003;
    rev:1;
)

From the Generator terminal:

curl --fail http://10.0.0.22:8080/marker.txt
curl --fail http://10.0.0.22:8080/comparison.txt

The marker response should produce SID 1000003; the comparison response should not. If the rule does not parse, use the rule-writing documentation for the installed Snort release rather than replacing the HTTP buffer with an unrestricted raw-payload match.

Optional passive sensor and inline IPS paths

Use Inline IPS only after documenting console access, bypass, snapshot, rule rollback, interface restoration, and the traffic that a drop action could disrupt. For passive sensing, prove the virtual or physical mirror before troubleshooting Snort. These paths are not required for Beginner Core Lab completion.

Write the validation handoff

Give the report a clear title and include:

  • Environment: topology, addresses, interface, engine, DAQ, and checksums;
  • Hypothesis: the traffic revision 1 was intended to detect;
  • Evidence: packet references, positive alert, restart, and offline result;
  • Overmatch: why the secondary source also matched revision 1;
  • Change: the revision 2 constraint and rationale;
  • Validation: positive and negative revision 2 results;
  • Limitations: benign explanations and additional evidence required; and
  • Cleanup: restored configuration, connectivity, and retained evidence.

Ask another analyst to reproduce one positive and one negative result using only the report. Record any field, command, or version difference.

Milestone 3Rule tuned and explainedRevision 2 retains the intended detection, removes the demonstrated overmatch, and another analyst can reproduce both results from the handoff.

Expected result The revised rule is more specific without losing the intended detection, the conclusion remains limited to the packet evidence, and another analyst can reproduce the result.

Troubleshooting worksheet

Observation Most likely layer Next proof
No packets in tcpdump Network placement Check interface, virtual network, mirror, and counters
Packets visible, no rule match Variables or rule logic Compare packet fields with the rule header and options
Rule fails validation Syntax or compatibility Read the first parser error and inspect that SID
Alert appears on console, not in file Logger or permissions Check alert_fast, log path, and process identity
Alert fires on the tuned negative test Detection is still too broad Confirm revision 2 loaded and compare the source field
PCAP result differs Inputs are not pinned Compare PCAP, engine, configuration, and ruleset hashes
Inline counter rises but traffic passes Verdict path Confirm inline DAQ, queue, and loaded drop action

Full Lab evidence checklist

This checklist applies to the self-hosted Full Lab. If you completed the Interactive Lab, retain its downloaded evidence summary instead.

Do not aim to complete every optional topology. Record evidence that proves the selected core route works:

0 of 7 recorded Mark each item when you have saved the evidence.

Clean up

  1. Stop tcpdump, the temporary HTTP server if used, and foreground Snort.
  2. Remove the temporary secondary generator address if it remains configured.
  3. Remove test HTTP files and any test-only rule not being retained.
  4. If inline testing was attempted, remove only the recorded NFQUEUE rules or bridge changes and restore the original interface and offload state.
  5. Restore the known-good snort.lua and ruleset, then validate:
sudo /usr/local/bin/snort -c /usr/local/etc/snort/snort.lua -T
ip -s link show <SENSOR_INTERFACE>
  1. Confirm management access and expected isolated-network connectivity.
  2. Revert disposable VMs if appropriate. Retain the final report, PCAP, checksums, alerts, and evidence manifest outside any reverted snapshot.
PreviousEvaluate pfSense NextReturn to the Snort overview