Gain real visibility into network traffic. This guide shows how to deploy Suricata on Debian in IDS mode, configure it correctly, validate that it is actually inspecting packets, and produce logs you can use for investigation, learning, and later SIEM integration.
Suricata is a network intrusion detection and network security monitoring engine. In IDS mode, it inspects traffic, applies signatures and protocol analysis, and writes alerts and structured logs. It does not block traffic by default in this mode.
This guide focuses on a practical Debian deployment in detection mode. The goal is to build a sensor that actually provides useful visibility instead of just installing a package and hoping it works.
A firewall tells you what is allowed or denied, but it does not tell you everything happening on the wire. Suricata can detect suspicious signatures, protocol anomalies, and other security-relevant behavior in real time.
It also generates structured event data through eve.json, which makes it useful for search,
dashboards, and correlation later on.
In practical terms, this is the step where your system moves from basic hardening into actual network detection.
This guide uses Suricata in IDS mode. That means Suricata observes, analyzes, and alerts, but does not block packets inline.
Inline blocking belongs to IPS mode, which requires different placement and more caution because a bad rule or bad inline design can break legitimate traffic.
Suricata only sees traffic that is visible to the interface it is monitoring.
On a normal host, that usually means:
• traffic to that host
• traffic from that host
It does not automatically see all traffic on your LAN just because it is on the same network.
To see broader network traffic, you need something like:
• a mirrored switch port (SPAN)
• a network tap
• or sensor placement where the traffic actually passes through the interface
This matters because many Suricata problems are really visibility problems, not rule problems.
• Debian system
• sudo access
• a network interface that can actually see the traffic you want to inspect
• a realistic understanding of your local network ranges
• optional: a dedicated sensor host for cleaner monitoring
• optional: centralized logging or SIEM tooling later on
sudo apt update
sudo apt install -y suricataWhat this does:
Installs the Suricata engine, default configuration, service unit, and logging layout.
Why this matters:
You need the engine and its configuration before you can build a usable IDS sensor.
What to expect:
Debian installs the package and places the main configuration at /etc/suricata/suricata.yaml.
sudo suricata --build-info
sudo systemctl status suricataWhat this does:
Shows Suricata build details and whether the service is already running, stopped, or failing.
Why this matters:
This confirms that the package installed cleanly and gives you a baseline before making configuration changes.
What to expect:
You should see version/build information and a readable service status.
ip addrWhat this does:
Lists network interfaces and addresses.
Why this matters:
Suricata has to inspect the correct interface. If you choose the wrong one, the sensor may run but provide little or no useful visibility.
What to expect:
Find the interface carrying the traffic you care about, such as eth0, enp1s0, or similar.
sudo nano /etc/suricata/suricata.yamlWhat this does:
Opens Suricata’s main configuration file.
Why this matters:
The most important baseline items for a live IDS setup are HOME_NET and the monitored interface configuration in af-packet.
Important:
Modify the existing sections in the file. Do not create duplicate top-level sections unless you know exactly why.
Example:
HOME_NET: "[192.168.1.0/24]"What this does:
Defines which addresses and local networks Suricata should treat as yours.
Why this matters:
Many rules and interpretations depend on knowing what is internal and what is external.
What to expect:
Use your real network range. Do not blindly copy the example if your environment is different.
Example:
af-packet:
- interface: enp1s0
cluster-id: 99
cluster-type: cluster_flow
defrag: yes
tpacket-v3: yesWhat this does:
Tells Suricata which live interface to inspect and enables a standard AF_PACKET live-capture IDS setup.
Why this matters:
Changing HOME_NET alone is not enough. Suricata also needs the correct live interface to capture traffic.
What to expect:
Replace enp1s0 with your actual interface name. Edit the existing af-packet section instead of creating a duplicate.
sudo suricata-updateWhat this does:
Downloads and installs Suricata detection rules.
Why this matters:
Suricata uses rules to trigger alerts. Without current rules, the sensor has far less detection value.
What to expect:
Suricata-Update typically writes the merged ruleset to /var/lib/suricata/rules/suricata.rules.
sudo suricata -T -c /etc/suricata/suricata.yamlWhat this does:
Validates the configuration file before the engine is restarted.
Why this matters:
A syntax or configuration error is much easier to catch here than after restarting a broken service.
What to expect:
You want a successful validation result. If it fails, fix the configuration before moving on.
sudo systemctl restart suricataWhat this does:
Reloads Suricata with the updated network definitions, interface settings, and rules.
Why this matters:
Configuration and rule changes do not take effect until the engine is restarted.
What to expect:
If the config is clean, the service should restart normally.
Use a dedicated sensor when possible
A dedicated sensor keeps detection cleaner, avoids unrelated workload interference, and makes troubleshooting easier.
Why this matters:
Visibility is more reliable when the sensor’s job is actually to be a sensor.
Keep rules updated regularly
sudo suricata-updateWhy this matters:
Rule freshness affects what your IDS can detect.
Do not guess at HOME_NET
Set it deliberately based on the networks you truly want treated as internal.
Why this matters:
Bad network definitions make alerts less meaningful and can distort detection context.
Optional: enable PCAP logging only with a storage plan
Example:
pcap-log:
enabled: yes
filename: log.pcap
limit: 100mb
max-files: 10
mode: normalWhat this does:
Enables packet-capture logging with rotation limits.
Why this matters:
PCAP can be extremely useful for deeper investigations, but uncontrolled packet capture can consume disk quickly.
What to expect:
Captured packets rotate according to the limits you set.
• setting HOME_NET correctly but forgetting to set the monitored interface
• creating a duplicate af-packet section instead of modifying the existing one
• choosing the wrong interface and then assuming Suricata is broken
• expecting full-network visibility without a tap, SPAN port, or proper placement
• updating rules and forgetting that they are not active until restart
• enabling PCAP logging without thinking about storage growth
• assuming more alerts always means better detection
sudo tail /var/log/suricata/suricata.logWhat this does:
Shows Suricata startup and runtime messages.
Why this matters:
This is where you confirm that the engine actually started cleanly after restart.
What to expect:
You want a clean startup, not repeated initialization or capture errors.
sudo tail -f /var/log/suricata/stats.logWhat this does:
Shows packet-processing statistics as Suricata runs.
Why this matters:
This confirms that packets are actually being inspected.
What to expect:
Counters should increase while relevant traffic is present.
sudo tail -f /var/log/suricata/fast.logWhat this does:
Shows human-readable alert output.
Why this matters:
It is one of the fastest ways to confirm that rule-based alerts are firing.
sudo tail -f /var/log/suricata/eve.jsonWhat this does:
Streams Suricata’s structured JSON event output.
Why this matters:
eve.json is the most useful Suricata output for later search, parsing, and SIEM ingestion.
What “working” looks like:
• Suricata starts cleanly
• packet counters increase in stats.log
• alerts appear in fast.log when appropriate
• structured events populate in eve.json
sudo tail -f /var/log/suricata/fast.log
curl http://testmynids.org/uid/index.htmlWhat this does:
Uses a known Suricata quickstart test method to trigger an alert and watch it in the alert log.
Why this matters:
A real test is better than assuming the engine works simply because the service started.
What to confirm:
• an alert appears in fast.log
• the same event appears in eve.json as an alert record
• packet counts continue moving in stats.log
Main places to watch:
• /var/log/suricata/suricata.log for engine problems
• /var/log/suricata/stats.log for packet-processing health
• /var/log/suricata/fast.log for quick alert visibility
• /var/log/suricata/eve.json for detailed event analysis
Useful live checks:
sudo tail -f /var/log/suricata/eve.json
sudo tail -f /var/log/suricata/stats.logWhat to watch for:
• repeated alerts from the same source
• anomalies lining up with suspicious traffic
• packet counts unexpectedly dropping because the wrong interface is being watched
• blind spots caused by interface placement or network design
Firewall: limits what can reach the host
SSH hardening and Fail2Ban: protect administrative access paths
Suricata: provides network detection and visibility
Central logging / SIEM: helps you correlate and investigate what Suricata sees
This is why Suricata matters so much: it turns network activity into something you can actually inspect, store, search, and learn from.
• keep the sensor on a dedicated host when practical
• feed eve.json into centralized logging later
• keep rules updated on a schedule
• enable PCAP logging only with clear storage limits
• tune HOME_NET and sensor placement based on what you actually want to detect
• Log centralization and analysis
• Splunk SIEM lab builds
• Traffic capture and packet review workflows
• IPS builds on Debian