Turn on Suricata IDS#

You will end up with Suricata watching one interface, alerting on what it sees, and the alerts on a page in the web UI. This is detection: the engine watches a copy of the traffic and cannot drop anything. Putting it in the packet path is a different job — Put the engine in the packet path.

VyOS packages Suricata natively and drives it from service suricata, so this is configuration in the tree like everything else: it diffs, it commits, it rolls back, and it survives an image upgrade.

Before you start#

The operator role and a licence.
The LAN prefix. The engine needs to know which addresses are "ours".
Somewhere for the load to go. Suricata inspects packets on a general-purpose CPU; on a small box that is real work. There are no throughput figures in this project — nothing has been measured — so try it on the interface you care about and watch the load.

Step 1 — Install the feature module#

Services → Apps, find Suricata IDS, install it.

Suricata is a feature module, not a container: kind: "builtin" in the catalogue marks a native VyOS feature whose Wheelhouse page is gated by installation. Installing one is instant and stages nothing — there is no image, no volume and no commit, because the flag is a UI-surface preference in the agent's own state, not router behaviour.

Two consequences worth knowing:

Configuration outranks the flag. If service suricata is configured on the router — by the CLI, by another operator, by anything — the IDS page shows regardless of whether the module is "installed". Wheelhouse never hides configuration that exists.
Uninstalling with live configuration hands you the delete operations for the Commit Bar to review, and the page stays until they land.

Step 2 — Enable it#

Security → IDS. The enable panel asks two questions and shows exactly what it will stage.

Interface to watch. The LAN side attributes flows to real client addresses; the WAN side sees pre-NAT traffic. Watching the LAN is usually what you want, because an alert that names 192.0.2.37 is actionable and an alert that names your public address is not.

Home network. This becomes $HOME_NET, the prefix the rules treat as ours. The panel seeds it from the chosen interface's address and refuses to stage without one — a home network that is not this router's is worse than none.

what it stages

set service suricata interface eth0
set service suricata address-group home-net address 192.0.2.0/24
set service suricata address-group external-net group !home-net
set service suricata port-group http-ports port 80
set service suricata port-group shellcode-ports port !80
set service suricata port-group oracle-ports port 1521
set service suricata port-group ssh-ports port 22

The four port groups are the variables the standard rule sets expect to exist. !home-net and !80 are negations — external is everything that is not home, and shellcode ports are everything that is not 80.

Step 3 — Commit and watch it start#

The page shows three things separately, which is the point of it:

The page shows	Meaning
The configuration	What `service suricata` declares
The engine state	Whether a Suricata process is actually running
The alerts	Parsed from the engine's own `fast.log`

Configuration without a running engine means the service did not start, and the Logs page will say why.

Check it worked#

The engine is running. The IDS page says so. From a shell:

bash

systemctl status suricata

It sees traffic. The simplest honest test is to generate something a rule set matches. Suricata ships with a test rule; on the router, the alert file is where the page reads from:

bash

sudo tail -f /var/log/suricata/fast.log

The page shows the alerts. Each row is parsed from a fast.log line: timestamp, the signature identifier, the message, its classification and priority, the protocol, and the source and destination.

What to do with an alert#

An IDS alert is an observation, not a verdict. Before acting:

Read the signature. The message and its classification say what the rule thought it saw.
Check the direction. An alert about traffic leaving a client is a different problem from one about traffic arriving.
Find the host. The source address plus the Sessions page tells you what that host is doing now, and the DHCP lease table tells you which machine it is.
Then decide. Blocking is a firewall rule you write — A default-drop ruleset — or, if you want the engine itself to drop, inline IPS.

Undoing it#

delete service suricata

Or Disable on the IDS page, which stages the same. Uninstalling the feature module from the Apps page while configuration exists hands you those delete operations rather than doing it silently.