Skip to main content

Standalone Suricata sensor

What this page is​

How to stand up a Suricata network sensor on separate hardware that watches live traffic from a switch port-mirror or TAP and ships alerts back to the AuroraSOC API. It covers the Linux container and native Windows shapes and why the sensor is passive by construction.

Why it exists this way​

The base Suricata stack under infra/suricata/ runs as a PCAP replay demo inside the main compose project. That exercises rules against captured traffic but does not cover the deployment an operator actually needs: a separate machine on a mirror or TAP watching live traffic. ADR 050 adds that shape without forking the base config or rules.

A mirror or TAP feed must never be treated as an enforcement path, so the sensor is IDS-only and never blocks. Inline blocking remains the job of the web-defense path.

How it works​

The bundle lives at infra/suricata/sensor/ and reuses the base assets rather than duplicating them.

  • Linux / Docker. A docker-compose.yml in the bundle mounts the shared ../entrypoint.sh, ../suricata.yaml.tpl, and ../rules/ so rule updates flow to the sensor without duplication. A two-NIC layout keeps the management path (API uplink) separate from the capture NIC.
  • Windows 11. A native install driven by PowerShell scripts under sensor/windows/ (install, interface listing, rule pull, Suricata run, and the bridge runner), because container capture is not available on Windows.
  • Shipping alerts. Both shapes reuse the suricata_eve_bridge.py shipper to forward EVE alerts to the AuroraSOC API. The sensor is passive and never blocks.

Configuration is per-host through .env (copied from .env.example); secrets and capture-specific values stay out of the tree.

What goes wrong​

  • No alerts reaching the API: confirm the capture NIC sees mirrored traffic (the management NIC alone will not) and that the EVE bridge has the correct API uplink URL and token.
  • Windows sees no traffic from a container: that is expected. Use the native install under sensor/windows/.
  • Rules look stale on the sensor: the Linux bundle mounts the shared ../rules/, so update rules at the base path, not inside the bundle.