Ingesting and Analyzing Suricata IDS Logs in the Elastic Stack
In previous posts, we discussed the importance of deploying an Intrusion Detection System (IDS) to monitor network traffic. Suricata is arguably the most powerful open-source IDS/IPS engine available today.
However, Suricata running on a standalone Linux box isn't very useful to a modern Security Operations Center (SOC). To generate actionable intelligence, the massive volume of alerts and network telemetry Suricata produces must be shipped to a SIEM.
In this post, we will explore how to configure Suricata, ingest its logs into the Elastic Stack using the modern Elastic Agent, and utilize the Elastic Common Schema (ECS) to normalize the data.
Step 1: Configuring Suricata for JSON Output
By default, Suricata generates a legacy, human-readable log file known as fast.log. While easy to read in a terminal, it is a nightmare for automated parsing.
To integrate seamlessly with Elastic, Suricata must be configured to output its telemetry in JSON format. This is handled by the Eve Log engine.
Open your suricata.yaml configuration file and locate the outputs section. Ensure that the eve-log is enabled and configured to log to a file (typically /var/log/suricata/eve.json).
outputs:
- eve-log:
enabled: yes
filetype: regular
filename: eve.json
types:
- alert
- http
- dns
- tls
- file
- flow
Once you restart the Suricata service, it will begin dumping highly structured JSON event data into the eve.json file.
Step 2: Ingesting Data with the Elastic Agent
In the past, engineers used a dedicated tool called Filebeat to read the eve.json file and ship it to Elasticsearch. Today, we manage this entirely through Kibana using the Elastic Agent and Integrations.
- Ensure the Elastic Agent is installed on your Suricata sensor and enrolled in Fleet.
- In Kibana, navigate to Integrations and search for Suricata.
- Click Add Suricata and assign it to the Agent Policy applied to your sensor.
- In the integration settings, specify the absolute path to your log file (e.g.,
/var/log/suricata/eve.json).
Click Save. The Fleet Server will push the configuration down to the Elastic Agent, which will immediately begin tailing the eve.json file, parsing the JSON, and streaming it directly into Elasticsearch.
The Power of the Elastic Common Schema (ECS)
The true magic of the official Suricata Integration lies in the parsing pipelines it installs behind the scenes.
When Suricata generates a log, it uses its own naming conventions (e.g., src_ip and dest_port). If every security tool (Palo Alto, Windows, Suricata) used different field names for an IP address, writing correlation rules in your SIEM would be impossible.
The Elastic Integration automatically translates Suricata's raw fields into the Elastic Common Schema (ECS).
src_ipbecomessource.ipdest_portbecomesdestination.portalert.signaturebecomesrule.name
Because the data is normalized, a single detection rule in Elastic Security looking for malicious behavior on destination.ip will apply to both your Palo Alto firewall logs AND your Suricata IDS logs simultaneously.
Analyzing the Data in Kibana
Once the data is flowing, you can use KQL to hunt through the network traffic in the Discover tab.
For example, if you want to see all Suricata alerts related to potential malware command and control (C2) traffic, you can run:
event.dataset : "suricata.eve" AND event.category : "intrusion_detection" AND suricata.eve.alert.category : "A Network Trojan was detected"
Furthermore, the Suricata integration comes with several out-of-the-box dashboards. Navigate to the Dashboards app in Kibana and search for "Suricata." You will find pre-built, interactive visualizations mapping out geographic attack origins, top triggered signatures, and TLS certificate anomalies.
Conclusion
Pairing Suricata with the Elastic Stack creates a formidable, enterprise-grade network security monitoring solution. By leveraging structured JSON output and the automated parsing pipelines of the Elastic Agent, Blue Teams can transition from fighting raw text files to actively threat hunting in a highly normalized data lake.