In this lab, I experimented with Suricata by writing and testing a custom rule. I ran Suricata against a provided sample.pcap file, then analyzed the alerts in fast.log and detailed events in eve.json to verify my rule’s effectiveness.
As a security analyst, I was given a base custom.rules file and a packet capture. My task was to add a rule that triggers on HTTP traffic to example.com, execute Suricata in offline mode, and then examine both the legacy fast.log and the JSON eve.json outputs.
| Task | My Actions & Findings |
|---|---|
| Edit rules | I opened custom.rules and added:alert http any any -> any any (msg:"Example.com access"; content:"Host: example.com"; sid:1000001; rev:1;)This rule matches requests to example.com. |
| Run Suricata | I executed:sudo suricata -r sample.pcap -c /etc/suricata/custom.rules --set outputs.eve.enabled=noSuricata processed the pcap and generated fast.log and eve.json.
|
| Inspect fast.log | I opened /var/log/suricata/fast.log and saw entries like:[**] [1:1000001:1] Example.com access [**]confirming my rule was triggered twice. |
| Analyze eve.json | I searched for sid:1000001 in eve.json and found JSON objects showing HTTP request details and timestamps, which validated the alerts with richer context. |
By crafting a simple HTTP rule and running Suricata in offline mode, I confirmed how custom signatures generate alerts. Reviewing both fast.log for quick checks and eve.json for detailed event data deepened my understanding of Suricata’s logging outputs.