Events and logs

Suricata's events appear in three places: the Threat Protection tabs in Cockpit, the suricata journal namespace those tabs read, and log files under /var/log/suricata. This page covers each one, the commands that show whether inspection is working, and fixes for common problems. To act on an event, see Tune the rules.

Overview tab

Threat Protection → Overview summarizes the last 7 days:

• Status:

  • Service is the state of suricata.service: active, activating, inactive or failed.

  • Protection is IPS — dropping, IDS — alert only or disabled, from the settings that are applied. Saved but unapplied changes don't show here.

  • Events (7d) counts alerts and drops.

  • By severity splits that count into high, medium and low.

• Malicious events — last 7 days shows one bar per day, stacked by High, Medium and Low. Hover over a bar to see its counts.

• Top offending sources (7d) lists the ten source addresses with the highest score. Each High event counts 3, Medium 2 and Low 1. An address that answers mDNS lookups shows its name too.

A source can be one of your own hosts: for an outbound alert, such as malware calling home, the source is the infected device. The tab loads once when you open it; switch tabs and back to refresh it.

Statistics tab

Threat Protection → Statistics ranks events over a time range. Choose 7 days, 30 days or All; the number of events in the range appears next to the list. The cards are:

• Top source IPs and Top destination IPs

• Top signatures and Top categories

• By severity

• By protocol: the application protocol when Suricata identified one, otherwise the transport protocol

Each card shows the top five. All covers everything the suricata journal namespace still holds.

The Overview and Statistics tabs read at most 5,000 events per query. When a range has more, Statistics shows Showing the most recent events only, and older events are left out of the totals. The Overview is capped the same way, without the warning.

Where events come from

Suricata writes its events twice:

• Alerts go to the journal. A second output sends alert events, and nothing else, through syslog into the journald namespace suricata. The Cockpit tabs read them with journalctl --namespace suricata. Packets Suricata dropped appear as alerts whose action is blocked. The namespace also holds Suricata's own messages, such as start-up notices and errors.

• The full record goes to a file. /var/log/suricata/eve.json holds alerts plus DNS, TLS, HTTP and flow records; see Logs on disk.

To read the journal from a shell:

# Follow new entries as they arrive
sudo journalctl --namespace suricata -f

# Today's alerts as columns: time, action, source, destination, SID, signature
sudo journalctl --namespace suricata -o cat --since today \
  | jq -rR 'fromjson? | select(.event_type == "alert") | [.timestamp, .alert.action, .src_ip, .dest_ip, .alert.signature_id, .alert.signature] | @tsv'

The router sets its journal limits (500 MB, 30 days) for the main system journal. It sets none specifically for the suricata namespace.

Logs on disk

logrotate rotates both files daily and keeps 14 old copies. The previous day's file is eve.json.1; older ones are compressed, as eve.json.2.gz and so on. After rotating, logrotate tells Suricata to reopen its files, so logging carries on in a fresh eve.json without a restart. On a busy network a single day's eve.json can still be large; check the total with sudo du -sh /var/log/suricata. To search an older day, read its compressed copy with zcat, for example sudo zcat /var/log/suricata/eve.json.2.gz | jq -c 'select(.event_type == "alert")'.

Because eve.json also has TLS and flow records, you can use it to see what a host was doing around the time of an alert:

# Follow alerts as one line of text each
sudo tail -f /var/log/suricata/fast.log

# Server names that 192.168.1.20 connected to over TLS
sudo jq -r 'select(.event_type == "tls" and .src_ip == "192.168.1.20") | [.timestamp, .dest_ip, .tls.sni] | @tsv' /var/log/suricata/eve.json

Useful commands

# Is the service running?
systemctl status suricata.service

# Has Suricata loaded its rules and attached to the queue?
sudo journalctl --namespace suricata -b -o cat | grep 'Engine started'

# Suricata's own messages since boot, without the alert records
sudo journalctl --namespace suricata -b -o cat | grep -v '^{'

# When is the next rule update, and how did the last one go?
systemctl list-timers suricata-update.timer
sudo journalctl -u suricata-update.service -n 50

# Is the queue rule in place?
sudo nft list table inet ips

# Is anything attached to the queue? Look for a line whose first number is 0.
sudo cat /proc/net/netfilter/nfnetlink_queue

# Ask the running engine through its command socket:
# how long it has run, and how many rules loaded or failed at the last (re)load
sudo suricatasc -c uptime
sudo suricatasc -c ruleset-stats

If nft list table inet ips shows the table but /proc/net/netfilter/nfnetlink_queue has no line for queue 0, Suricata isn't attached and forwarded traffic is passing uninspected.

Troubleshooting

Suricata won't start or is slow to start

Symptom: Service stays activating for minutes or shows failed, or applying settings ends in Apply failed.

Cause and fix:

• Slow hardware. Before starting, Suricata runs a configuration test that loads every rule, which takes about 2 minutes on low-power hardware. Then it loads them again. The service allows 300 seconds to start. If systemctl status suricata.service reports a timeout, the router is too slow for the full rule set. Set categories you don't need to Disable to shrink it.

• A rule that doesn't parse, or a duplicate SID. Applying tests the local rules with Suricata before it changes anything, so a broken rule fails the rebuild and Suricata keeps running on the rules it had. The rebuild's log (View log in the changes panel) shows router.suricata: Suricata rejected the configuration., and the lines above it name the rule: error parsing signature or Duplicate signature, then Loading signatures failed. A duplicate is often one of the built-in SIDs, 1000001 to 1000011. Fix or remove the line in Extra local rules and apply again. The test doesn't load the downloaded rules, so a local SID that clashes with one of theirs still stops Suricata when it starts; read its messages with sudo journalctl --namespace suricata -b -o cat | grep -v '^{'. If the rule reads a file, such as a filemd5 list or a dataset with load, and the log shows opening hash file or failed to set up dataset, the rule may be fine: the test can't see that file. See Extra local rules for turning the test off.

• A bad suppression. A suppression whose host isn't an IP address or prefix fails the build with router.suricata.suppressions: SID <sid> has an invalid host '<host>' — use an IPv4 or IPv6 address or CIDR prefix. The Policies tab marks the entry; remove it, add it again with a valid host, and apply.

While Suricata is down, forwarded traffic passes uninspected.

No events appear

Symptom: the Events tab says "No matching alerts or drops." and the Overview counts stay at zero.

Cause and fix:

• Suricata isn't inspecting yet. Check for Engine started with the commands above.

• The traffic isn't forwarded. Traffic to the router itself and traffic between devices on the same network is never inspected; see What it doesn't do.

• Nothing has matched. To test the path end to end, add a temporary rule in Extra local rules, apply, and ping an internet IPv4 address from a LAN host, for example ping -c 5 9.9.9.9:

  alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL test ping"; itype:8; sid:1000199; rev:1;)

  Once the apply has finished and Suricata has reloaded its rules, an event named LOCAL test ping appears on the Events tab. Remove the rule afterwards.

• Cockpit can't read the journal. The tabs show Could not read Suricata events with the error from journalctl.

A site broke after you enabled IPS mode

Symptom: a site or app stops working for some users after you switch to IPS mode or set a drop action.

Fix:

1. Open Threat Protection → Events, set the action filter to Blocked, and search for the affected client's IP address.

2. Open the blocking event and note its signature and SID.

3. If the traffic is legitimate, choose Disable signature or Suppress for a host and click Save policy. If the drop came from a category, you can instead set that category back to Default on Policies.

4. Apply the change.

To stop all drops at once while you investigate, turn off Drop high-risk packets automatically (IPS mode) and choose Save and apply from the Save menu. This empties the drop list, but a drop rule you wrote in Extra local rules still drops. If you find no blocked event for the client, Suricata didn't drop the traffic; look at the firewall and DNS filtering instead.

IPv6 inbound traffic doesn't match $HOME_NET rules

Symptom: an IPv6 port forward gets no alerts where the same service over IPv4 does.

Cause: $HOME_NET holds the IPv4 LAN and guest subnets and the WireGuard addresses and Allowed IPs, but not the IPv6 prefix your ISP delegates. Your hosts' IPv6 addresses count as external, so rules keyed on $HOME_NET don't match. Rules written with any still do.

Fix: there's no setting that adds the delegated prefix. Forward only what must be reachable over IPv6, and narrow the forward's allowed sources where you can.

Limits

• Of Suricata's event records, the journal namespace carries alerts only. DNS, TLS, HTTP and flow records are in eve.json alone.

• The Overview and Statistics tabs read at most 5,000 events per query, and the Events tab keeps 2,000 rows.

• The logs on disk keep 14 days; see Logs on disk. The router sets no retention limit specific to the suricata journal namespace.

• There are no email or push notifications, and no export from the Cockpit tabs.

• Events only cover forwarded traffic, and only while Suricata is running.