Suricata 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 Suricata sensor in virtual machines.

Hands-on proof of concept

Build it. Detect it. Explain it.

Start with a two-machine beginner route, prove that one known packet becomes a Suricata alert, investigate the structured evidence, then tune and retest the detection. Add passive monitoring or prevention only after the core works.

⏱ 4–7 hours core ◆ Guided beginner ✓ Evidence required

Start building

Self-hosted · Several hours

Suricata Full Lab

Installation required

How this differs from the demonstrations

This is an outcome-based exercise rather than a screenshot transcript. Your interfaces, addresses, software versions, rules, and EVE fields may differ. Record those differences and prove every checkpoint in your own lab.

Use an isolated, authorised environment

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

Before you begin

You need: an x86-64 computer with virtualisation enabled, administrator access, approximately 12 GB of available RAM, 90 GB of free disk space, and temporary internet access for authorised downloads.

How to use this lab

Complete one session at a time. Stop when a milestone fails and fix that boundary before changing a rule, adding another interface, or enabling inline mode.

Recommended first

Beginner Core Lab

Use one Ubuntu Suricata sensor/target and one Linux traffic generator. Prove the host-based IDS path through all three activities before adding another system.

Expected time: 4–7 hours across three sessions.

Optional extension

Complete PoC

After the core checkpoint passes, add a separate target, passive mirror, authorised PCAP, SIEM integration, inline path, or pfSense gateway.

Expected time: one or more additional sessions.

1. Session 1Build and snapshot90–150 minutes
2. Session 2Detect and verify60–90 minutes
3. Session 3Investigate and tune60–120 minutes

Objective

You are validating a small Suricata deployment for a SOC demonstration. A lab server is receiving unexpected ICMP echo requests. Build the sensor, prove the test traffic reaches the correct interface, confirm a local rule produces an EVE alert, rule out unrelated traffic, and tune the detection without hiding useful evidence.

The Beginner Core Lab consists of:

• one Ubuntu system running Suricata and receiving the test traffic;
• one Linux system generating authorised traffic; and
• one isolated virtual network connecting them.

Beginner terminology used in this lab

Term	Meaning in this lab
HOME_NET	The protected address or subnet Suricata treats as local.
Capture interface	The network interface from which Suricata reads packets.
SID	The unique identifier of a detection rule.
Revision	The version of a rule; increase it after changing behaviour.
EVE	Suricata's structured JSON event output, normally eve.json.
Positive test	Traffic deliberately expected to match the rule.
Negative control	Similar or unrelated traffic expected not to match it.
flow_id	A Suricata value that links records belonging to one flow.
community_id	A common flow identifier that can support correlation across tools.
Capture/drop counters	Evidence showing how many packets were received and whether packets were missed.

Choose a topology

Use the host-based network IDS profile for the Beginner Core Lab. Treat passive monitoring, inline prevention, and pfSense as extensions after alerting works.

Profile	Minimum systems	Traffic path	Use
Host-based network IDS	Suricata sensor/target + generator	Test traffic terminates on the sensor	Beginner Core Lab
Passive sensor	Generator + target + Suricata sensor	TAP, SPAN, or virtual mirror copies traffic	Realistic IDS/NSM extension
Inline IPS	Client + server + inline sensor	Traffic crosses NFQUEUE or another enforced path	Optional prevention extension
pfSense gateway	pfSense + internal client + generator	Traffic crosses the gateway interface	Optional package workflow

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

Client Original traffic→ Server

TAP / SPAN copy

Passive sensorAlert + record

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

Client → Inline sensorInspect AllowDrop → Server

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

Application → Linux firewallSelect traffic → NFQUEUE 0Wait for verdict ↔ Snort / SuricataAllow or drop

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

Client network → Sensor NIC AEnter ↔Inspect + enforce Sensor NIC BExit → Server network

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.

01

Activity 1: Build the environment

Download checklist

Record the filename, version, architecture, source URL, checksum, licence, and download date for every required item.

Required for the Beginner Core Lab

Item	Purpose	Authoritative source
Hypervisor	Isolated networking, console, and snapshots	Selected vendor's official documentation
Ubuntu Server ISO	Operating system for both lab systems	Ubuntu releases
Suricata packages	Detection engine and update tooling	Matching Ubuntu repository and installation journey
ET Open or selected rules	Detection content	Source recorded through suricata-update
jq, tcpdump, and ethtool	EVE, capture, and interface validation	Matching Ubuntu repository

Create the two virtual machines

VM	Suggested allocation	Example address
Suricata sensor/target	4 vCPU, 8 GB RAM, 60 GB disk	10.0.0.27
Linux generator	2 vCPU, 4 GB RAM, 30 GB disk	10.0.0.29

1. Create an isolated network and provide temporary NAT only for authorised downloads.
2. Install both systems, configure addresses and time, then take a base-os snapshot.
3. Follow Install Suricata, record suricata --build-info, and install the selected ruleset.
4. Configure HOME_NET and the actual capture interface.
5. Prove packets arrive, validate the configuration, and verify the service is active (running).
6. Record capture/drop counters and take a suricata-installed snapshot.

Need help verifying the sensor?

Identify the interface and address:

ip -br address

On the sensor, watch for the generator's ICMP traffic. Replace the placeholders with values from your lab:

sudo tcpdump -ni <capture-interface> icmp and host <generator-ip>

Validate the configuration and check service health:

sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl status suricata --no-pager

Continue only when: tcpdump sees the authorised test packet, validation succeeds, and the service remains active.

Optional PoC machines and downloads

Add these only after the Beginner Core Lab works:

Optional item	Purpose
Separate Linux target	Traffic between two other systems for a passive mirror test
Benign PCAP fixture	Repeatable offline analysis with a recorded checksum
pfSense VM	Gateway and package extension
SIEM destination	EVE ingestion and cross-source correlation

Keep management on a separate path for inline testing. An ordinary endpoint interface will not see unrelated unicast traffic; prove the TAP, SPAN, or virtual mirror before troubleshooting Suricata.

Milestone 1Sensor readyBoth machines have synchronised clocks and recorded addresses; the sensor sees the generator's traffic, validates successfully, remains active, and has a recoverable snapshot.

Expected result The sensor has a known interface and address, receives the intended traffic, loads a valid configuration, and can be restored to the working baseline.

02

Activity 2: Detect and verify

Follow the checkpoints in order. Keep this page open and return after each linked journey.

1. The local rule is loadedAdd SID 1000001 from Local rules & EVE, validate the configuration, and restart Suricata.
2. The positive test alertsSend an authorised ICMP echo request from the generator and retain the matching fast.log and EVE alert.
3. The negative control stays quietGenerate traffic outside the rule's type or direction and explain why it does not match SID 1000001.
4. The detection survives restartRestart Suricata, repeat the positive test, and confirm the new alert.
5. Packet handling is understoodRecord capture/drop counters and investigate unexplained packet loss before continuing.

Need help running and finding the tests?

From the generator, send a small positive test:

ping -c 3 <sensor-ip>

On the sensor, confirm the SID appears in EVE:

sudo jq -c 'select(.event_type == "alert" and .alert.signature_id == 1000001)' \
  /var/log/suricata/eve.json | tail -n 3

For the negative control, use traffic that the ICMP echo-request rule does not describe, such as an authorised SSH connection attempt or HTTP request. Search the same narrow time window and confirm no record with SID 1000001 was created for that traffic.

Continue only when: the positive test alerts, the negative control does not, and another positive alert appears after restarting Suricata.

Trace one event through:

1Test packet→2Capture counter→3SID 1000001→4EVE alert→5Analyst finding

Record the timestamp, action, SID, revision, endpoints, interface, flow_id, community_id when present, and related protocol events.

Milestone 2Detection provedSID 1000001 passes positive, negative, and post-restart tests, and the matching structured evidence can be explained.

Expected result A known test packet becomes a matching EVE alert, unrelated traffic is excluded, and the detection still works after a service restart.

03

Activity 3: Investigate, tune, and present

Restore or clone the suricata-installed snapshot if necessary. Confirm the service is active and repeat the known positive test before changing the rule.

Investigation scenario

You are the analyst reviewing unexpected ICMP echo requests to the lab server. Use the retained event to determine:

• which system initiated the traffic;
• which protected system received it;
• when and on which interface it was observed;
• which rule and revision produced the alert;
• whether related flow or protocol records support the finding; and
• what the evidence does not establish about intent or wider impact.

Recommended beginner extension: tune one variable

Narrow the local rule to the authorised generator address or another property you can test safely. Increment the revision, validate the configuration, and repeat the positive and negative tests. Compare alert counts before and after the change and explain what visibility the narrower rule removes.

Need help tuning without losing the baseline?

1. Copy the working rule and retained EVE evidence into your lab notes.
2. Change only one condition, such as the source address.
3. Increase rev by one and validate before restarting.
4. Repeat the original positive test from the authorised generator.
5. Run a negative control that falls outside the new condition.
6. Restore the earlier rule if either result differs from your expectation.

Record the rule before and after the change, both test windows, and the reason the narrower behaviour is appropriate for this lab.

More ways to extend the working core

Choose only one after the recommended tuning checkpoint passes:

• add a narrowly scoped HTTP marker on a local lab server;
• correlate the alert with DNS, HTTP, TLS, flow, or packet evidence;
• replay an authorised PCAP and compare two rulesets;
• integrate EVE with a lab SIEM;
• prove a passive TAP, SPAN, or virtual-mirror path; or
• complete the inline journey with one scoped block and tested rollback.

Change one variable at a time and repeat positive and negative tests after each change.

Present and validate

Prepare a short analyst readout covering:

1. topology and capture assumptions;
2. engine, configuration, and ruleset versions;
3. the question the detection answers;
4. positive, negative, and restart evidence;
5. the tuning change and remaining blind spots;
6. packet-loss or performance observations; and
7. whether changing alert to drop would be safe.

Ask another person to reproduce one test using only the retained notes. Record any missing instruction they identify.

Milestone 3Finding reproducedThe rule is tuned and retested, limitations are stated, and another analyst can reproduce the finding from the retained notes.

Expected result Your conclusion stays within the evidence, the tuned rule preserves the intended detection, and the work can be repeated by another analyst.

Troubleshooting worksheet

Symptom	Evidence to collect first	Likely boundary
No packets	tcpdump, interface counters, mirror configuration	Traffic delivery
Packets but no alert	HOME_NET, direction, loaded SID, timestamps	Rule evaluation
Service exits	systemctl status, journal, suricata.log	Configuration or runtime
Alert differs after update	Engine/config/ruleset checksums and SID revision	Content drift
Inline traffic stops	Firewall counters, queue listener, EVE action	NFQUEUE/verdict path
PCAP result differs	PCAP, engine, config, and rule checksums	Reproducibility

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.

Complete the challenge by recording evidence that your selected route works:

• Required downloads with versions, filenames, checksums, sources, and licence constraints.
• Core VM specifications, addresses, time synchronisation, capture interface, and snapshots.
• Build information, successful configuration validation, and active service state.
• Packet capture and counter evidence showing that the intended traffic reached Suricata.
• The local rule with SID, revision, and loaded-rules evidence.
• Positive, negative, and post-restart test results with narrow time windows.
• The matching EVE record and a short evidence-based analyst conclusion.
• The tuning rationale, before/after rule, and repeated test results.
• Peer-reproduction notes, remaining blind spots, and any differences from the demonstrated environment.

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

Clean up

Remove temporary NFQUEUE or firewall rules, return test signatures to alert, stop local fixtures, remove temporary DNS or account changes, restore offload settings, dispose of sensitive captures according to policy, and revert disposable VMs when appropriate. Retain your rules, EVE evidence, test notes, and conclusion as the lab record.

Completion criteriaThe packet-to-alert path, investigation, tuning, restart behaviour, peer validation, and cleanup are supported by reproducible evidence.

PreviousEvaluate pfSense NextReturn to the Suricata overview