Skip to content
All posts
Network IDS

How to Set Up Suricata IDS with Automated Response

8 min read

Suricata is one of the best open source network intrusion detection systems available. It inspects packets, matches against thousands of signatures, and generates alerts for everything from malware C2 callbacks to SQL injection attempts. But Suricata has a gap: it detects threats but does not block them by default. Someone, or something, needs to read those alerts and take action.

Inner Warden fills that gap. It reads Suricata's EVE JSON output, promotes alerts to incidents, enriches them with threat intelligence, runs them through AI confidence scoring, and executes firewall blocks. The complete alert-to-block pipeline, automated.

What Suricata detects

Suricata uses the ET Open ruleset (and optionally ET Pro) to match packet patterns against known attack signatures. It catches threats that log-based tools cannot see:

  • Malware C2 traffic - connections to known command-and-control servers.
  • Exploit attempts - buffer overflows, shellcode, known CVE exploits in network traffic.
  • Protocol anomalies - malformed HTTP, DNS tunneling, TLS certificate mismatches.
  • Network scans - Nmap SYN scans, service fingerprinting, OS detection probes.
  • Data exfiltration - unusual outbound traffic patterns that suggest data theft.

The gap: detection without response

In IDS mode, Suricata writes alerts to its EVE JSON log. That is it. The alerts sit in a file until someone reads them. On a busy server, Suricata can generate thousands of alerts per day. Without automated triage, the signal drowns in noise.

You could run Suricata in IPS mode (inline), but that requires specific network configuration (bridge mode or NFQueue) and drops packets directly. For many VPS and cloud setups, IDS mode with an external response layer is more practical and safer.

How Inner Warden closes the loop

Inner Warden's sensor includes a suricata_eve collector that tails Suricata's EVE JSON log in real time. High-severity alerts are promoted to incidents and fed into the full pipeline.

suricataET SCAN Nmap SYN scan from 198.51.100.12
promoteAlert promoted to incident | severity: high
enrichAbuseIPDB: 94% | GeoIP: DigitalOcean, US
decideAI confidence 0.93 | recommend block-ip-ufw
blockFirewall deny rule + Telegram alert + AbuseIPDB report

Install and configure Suricata

On Ubuntu/Debian, install Suricata from the official PPA:

Install Suricata
sudo apt install suricata suricata-update

Update the rulesets:

Update rules
sudo suricata-update

Ensure EVE JSON output is enabled in /etc/suricata/suricata.yaml. This is enabled by default on most installations. The log file is typically at /var/log/suricata/eve.json.

Connect Inner Warden

Install Inner Warden and enable the Suricata integration:

Install Inner Warden
curl -fsSL https://innerwarden.com/install | sudo bash
Enable Suricata integration
innerwarden integrate suricata

Inner Warden automatically discovers the EVE JSON log and starts tailing it. You can verify the integration is active:

Verify
innerwarden status

Alert severity filtering

Not every Suricata alert warrants a firewall block. Inner Warden filters by severity: only high and critical alerts are promoted to incidents by default. Low-severity alerts (like informational protocol detections) are logged but not acted on.

The AI adds another filter layer. Even a high-severity alert might get a low confidence score if the source IP has no AbuseIPDB reports and the traffic pattern is ambiguous. The combination of severity filtering + AI confidence scoring reduces false positives significantly.

What to do next