Suricata IDS — network detector

Suricata alerts without an ELK stack

Suricata writes its findings to eve.json, one JSON object per event, and the usual advice is to ship that into Elasticsearch and look at it through Kibana. On a cluster that is sound. On a single VPS it means running a search engine, a log shipper and a dashboard server — several gigabytes of memory and a second system to maintain — so that you can read alerts from the machine they were already written on.

This page reads eve.json directly, along with fast.log where that is what your build produces. It shows the alerts from the last twenty-four hours grouped by category, the addresses generating the most of them, and the individual signatures with source, destination, protocol and severity.

If Suricata is running but reporting nothing, the cause is almost always rules rather than traffic: a fresh install ships with no signatures until suricata-update has run at least once. The other common surprise is severity. Most of what a public-facing sensor reports is low-severity scanning that never becomes anything, so read the categories before the count.

A sensor on the wire has a limit people trip over regularly: encrypted traffic looks to it like a stream of bytes. It will tell you a connection to your site came from this address; it will not tell you the request carried an attempted SQL injection. That is read inside the web server, after decryption, by ModSecurity. The two do not replace each other: one looks at the network from outside, the other at the request from inside.