Inspecting eve.json logs for blocked hosts

Troutpocket

I'm dumping my interface logs to eve.json for analysis elsewhere. I'm curious why log entries for block actions say "action:allowed" when suricata blocked the IP. Example:

{"timestamp":"2022-09-14T11:38:17.508248-0700","flow_id":1519261459267928,"in_iface":"igb0","event_type":"alert","src_ip":"123.123.123.123","src_port":52404,"dest_ip":"my.ip.add.ress","dest_port":2614,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":2525039,"rev":561,"signature":"ET 3CORESec Poor Reputation IP group 40","category":"Misc Attack","severity":2},"packet":"ZGJmIR1Y7Kgf/oVzCABFIAAohUsAANwG9TNZ+KUIMtYyWsy0CjbCy70nAAAAAFACBADw0wAAAAAAAAAA","packet_info":{"linktype":1}}

I checked pfctl and the src_ip was just added. The suricata "block" tab shows it blocked there, also.

I suspect "action" isn't the relevant part of the log entry pertaining to the block status? Is there a way to get the block status of a log entry into the eve output?

bmeeks

If you are using Legacy Blocking Mode, that employs a custom plugin created just for pfSense that is compiled into the Suricata binary. That plugin receives a copy of every ALERT generated by Suricata, and if the IP address in the alerting packet is not covered by a Pass List entry, the IP is added to a pre-existing pf table in pfSense via a system call. A built-in hidden rule in pfSense then blocks all IP addresses contained in the table (the table is snort2c).

Because the action verb in the rule is ALERT, the Suricata signature analysis engine sends the status to the EVE.JSON logging engine as "allowed" since it did not DROP the packet. Legacy Blocking does not work by dropping just the offending traffic. It works completely differently by adding the source and/or destination address to the pf table in the firewall engine and then depending on the firewall to block ALL future traffic for that IP. To see what Legacy Blocking Mode is doing, you need to examine the alert.log file for the interface found in /var/log/suricata/suricata_xxxx where xxxx is a GUID and the interface name.

So Legacy Mode Blocking is a little strange in terms of what the signature analysis engine will log via the EVE.JSON logs. If your hardware supports it and you are not using VLANs, you can switch to Inline IPS Mode and modify your rule actions to DROP for those rules which you wish to block. Using Inline IPS Mode, when a DROP rule prevents traffic flow you will see a matching entry showing the traffic was dropped in the EVE.JSON log.

Troutpocket

@bmeeks Great description, well detailed. It's what I suspected. I compared the block.log and alert.log against the eve.json output and the relevant alerts matched what I found in alert/block.log.