Monitoring and logs
suricata
A network IDS/IPS: matches traffic against Suricata rules (signatures) and alerts, or drops the matching packets when inline.
Suricata reads traffic, rebuilds the protocols (TCP streams, HTTP, TLS, DNS) and checks it against rules
(signatures). Passive, it captures from a card (--af-packet=eth0), typically one fed by a mirror port, and can only
alert. Inline, it takes packets from a netfilter queue (-q 0, fed by an iptables … -j NFQUEUE rule) and gives
each a verdict, so drop rules block. It logs alerts to fast.log (a line each) and every event to eve.json
(JSON lines), and its own diagnostics to suricata.log. suricatasc talks to the running engine over its
control socket.
suricata command usage
suricata -c CONFIG [-S RULEFILE] --af-packet=CARD|-q QUEUE [-D] [-l LOGDIR] suricatasc -c COMMAND
Options
-
-c suricata.yaml - the configuration: rule files, outputs, protocol settings
-
-S file.rules - load only this rule file (turns off live reloads)
-
--af-packet=eth0 - capture from the card: passive IDS
-
-q 0 - take packets from netfilter queue 0 and give verdicts: inline IPS
-
-D - run in the background
-
-l DIR - where to write the logs
-
-T - test the configuration and rules, then exit
-
suricatasc -c reload-rules - reload the rule files without stopping
suricata examples
-
suricata -c /etc/suricata/netlab.yaml --af-packet=eth0 -D -l /var/log/suricata - Starts an IDS on the copies arriving at eth0.
-
suricata -c /etc/suricata/suricata.yaml -S local.rules -q 0 -D -l /var/log/suricata - Starts an IPS reading netfilter queue 0, with one rule file.
-
suricatasc -c reload-rules - Makes the running Suricata read its rule files again.
-
cat /var/log/suricata/fast.log - Shows the alerts, one line each, with [Drop] on the ones an IPS blocked.
Reading the output
$ cat /var/log/suricata/fast.log
10/04/2026-10:23:39.889289 [**] [1:1000001:1] NETLAB passwd file request [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 10.0.1.13:36650 -> 10.0.2.10:80 [1:1000001:1]: generator 1 (the rule engine), the rule's sid and its rev.- The message is the rule's
msg; the classification and priority come from itsclasstype. {TCP} 10.0.1.13:36650 -> 10.0.2.10:80: the flow, from the side that sent the matching packet.- An inline drop starts the line with
[Drop].
Pitfalls
- On a mirror port Suricata cannot stop anything, whatever the rule's action:
droponly works inline. - Inline, every packet waits for a verdict: if Suricata stops, traffic stops too, unless the queue rule has
--queue-bypass(fail open). - A rule matching too little of the content fires on harmless traffic: tune it before turning it into a
drop.