IDS#

Security → IDS drives the intrusion detection engine VyOS ships. Suricata is configured from the configuration tree under service suricata, so enabling it, naming the interfaces it watches and defining the address and port groups its rules reference are all ordinary staged changes that diff, commit and roll back like anything else. The page reports three separate things and keeps them separate: what the configuration declares, whether a suricata process is actually running, and — when the agent runs on the router — the alerts the engine has written.

The Mode tile says IDS and, under it, detection only — nothing inline. That is not modesty. In this mode the engine watches copies of traffic; it raises alerts and it cannot drop a packet. The rules on the Firewall page remain the only thing between a flagged flow and its destination. Putting the engine in the packet path is a different arrangement, documented on inline IPS.

Getting to the page#

The IDS entry carries the suricata feature id in the navigation model, so it appears when the feature is switched on in Apps or when service suricata already exists in the configuration — a router that already runs the engine shows the page regardless of the switch (ui/src/components/nav.ts, agent/apps.go mergeFeatureState).

Where the page gets its data#

Everything on it comes from one call, GET /api/ids, re-read every 10 seconds (agent/ids.go handleIDS):

The CLI view is a second call, GET /api/config/commands?path=["service","suricata"], and shows # service suricata is not configured when the subtree is absent.

Before it is configured#

With no service suricata in the tree the page shows an empty state with the commands a minimal configuration consists of, and below it an Enable the IDS panel with two fields:

• Interface to watch, from the router's interfaces, with the hint that the LAN side attributes flows to real client addresses while the WAN side sees pre-NAT traffic.
• Home network, which becomes $HOME_NET — the prefix the rules treat as yours. It is seeded from the chosen interface's first non-link-local address. If no address can be read, the field is empty and the button stays disabled with the reason: a home network that is not this router's is worse than none.

Stage enable stages seven operations:

set service suricata interface eth0
set service suricata address-group home-net address 10.0.10.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

Those groups are not decoration: community rulesets are written against variables such as $HOME_NET, $EXTERNAL_NET, $HTTP_PORTS and $SSH_PORTS, and a ruleset loaded against groups that do not exist has nothing to reason about. The ! forms are negations — external-net is everything that is not home-net. The page's own empty-state example writes those negated values in quotes, which is what a shell needs; the staged commands above are as the Commit Bar renders them.

The engine starts on commit.

Once it is configured#

Four tiles across the top:

When the configuration declares the engine and no process is running, a warning band appears under the tiles: that is usually a failed start after a configuration change, and the Logs page filtered on suricata will say why.

Address groups and Port groups are listed as cards: each group's name with its members as badges, and any group references as a second kind of badge. An empty address group list is called out — rules that reference $HOME_NET will have nothing to reason about.

The Rules panel states the one thing that is not configuration: rulesets are fetched on the router with update suricata. Without them the engine runs and matches nothing.

Disable IDS in the header stages one operation, delete service suricata, which removes the whole subtree on commit.

The alerts table#

fast.log is Suricata's grep-friendly alert format, written alongside eve.json. The agent parses each line into a timestamp, a signature id, the message, the classification, the priority, the protocol and the two endpoints, and the table shows them with a filter box:

Two limits are stated on the page rather than hidden:

• The tail, not the file. At most the last 512 KB is read and at most 200 alerts are returned, because this is polled by a viewer and fast.log grows for as long as the engine has rules and traffic.
• Off-router, there are no alerts at all. An agent that is not running on the router cannot read /var/log/suricata/fast.log, and the panel says so and suggests reading it over SSH instead. Everything else on the page still works, because it comes from the configuration tree and the process table.

What the IDS does not do#

• It does not drop anything. See inline IPS for the arrangement that can, and what that costs.
• It does not fetch rules. update suricata on the router does, and nothing in the UI runs it.
• It does not tune the engine. What the page edits is the interface list and the address and port groups. Anything else under service suricata can be set from the console or the Config tree and will be shown here as configuration.
• It does not silence a signature. There is no per-signature suppression control in the page.

See also#

• Inline IPS — NFQUEUE, the two fail-open layers, and the safe way in.
• Firewall — the rules that actually stop traffic.
• Worked rulesets — what "the firewall is still the control" looks like in practice.
• Apps — where the feature module is switched on.
• Logs — why a declared engine is not running.

Checked against#

ui/src/pages/Ids.tsx, ui/src/components/nav.ts, ui/src/lib/api.ts, agent/ids.go, agent/apps.go, agent/catalog.json, agent/main.go.