Alert rule triggering Drop rule?
-
@Gblenn: you may not have that option enabled. It's relatively new in Suricata.
Look for Engine Verdict in the EVE Output Settings section of the INTERFACES EDIT tab. See if that option is enabled. If not, enable it, save the change, and restart Suricata on the interface so the binary picks up the change.
-
-
Found this as well... checked that one as well...
-
@Gblenn said in Alert rule triggering Drop rule?:
Found this as well... checked that one as well...
Yes, that one along with the previous one should result in the final engine verdict being logged in the EVE JSON log. Hopefully that will show why that particular rule is resulting in the alert packet being flagged with DROP.
-
@bmeeks Ok thanks, I guess I'll have to wait a bit then to have some more data to look into..
-
@Gblenn Do I need to restart Suricata for this take effect, or is Save enough?
-
@Gblenn said in Alert rule triggering Drop rule?:
@Gblenn Do I need to restart Suricata for this take effect, or is Save enough?
You must always restart Suricata when making any configuration change. That's because what you are doing in the GUI is simply writing updated info to the text-based
suricata.yamlconf file for the running binary. That binary piece only reads the conf file at startup. No configuration changes are sensed after the binary has started.I will repeat this for the benefit of others in the future who might stumble upon this thread:
The Suricata package contains two related but completely different components. There is a GUI wrapper written in PHP that creates and displays the pretty web-based screens you tab around in and make configuration selections. That code has zero to do with scanning traffic, though. All of that is performed by the binary daemon that runs in the background. That daemon reads all of its configuration information from a text-based
suricata.yamlfile created individually for each configured interface by the GUI code.Suricata is distributed by upstream as just a plain-vanilla binary executable that relies upon a manually configured text conf file. That file has to be created by the user via the CLI (command line interface). On pfSense I made that process much friendlier by creating the PHP wrapper GUI. The user then can use the GUI to make various configuration selections. The chosen parameters are then written to the text-based conf file the Suricata binary piece expects. If you install Suricata on any other platform (Linux, Windows, or FreeBSD), you would have to configure everything by hand using the CLI. The pfSense package makes life easier by wrapping that hand-editing with a GUI.
-
@bmeeks Ok, restarted Suricata about 5 hours ago, and now the logs show Verdict as well...
BUT, I don't understand, there is still no Drop or Blocked action anywhere...
Here's an example of something that should generate a blocking:
Fist in the Rule category listing, it's clearly set to DROP
And here it is showing up as expected in the Blocked Hosts tab:
As well as the Alerts tab:
But, looking at the eve.json file, it is still only alert: In fact, greping all the eve.json files again for "action":"blocked" , "drop" or anything other than alert gives me nothing...
{"timestamp":"2023-12-07T20:58:35.473754+0100","flow_id":908861034418160,"in_iface":"ix1","event_type":"alert","src_ip":"51.159.221.237","src_port":30301,"dest_ip":"192.168.1.29","dest_port":6881,"proto":"UDP","pkt_src":"wire/pcap","alert":{"action":"allowed","gid":1,"signature_id":2403357,"rev":88095,"signature":"ET CINS Active Threat Intelligence Poor Reputation IP group 58","category":"Misc Attack","severity":2,"metadata":{"affected_product":["Any"],"attack_target":["Any"],"created_at":["2013_10_08"],"deployment":["Perimeter"],"signature_severity":["Major"],"tag":["CINS"],"updated_at":["2023_12_06"]}},"app_proto":"failed","direction":"to_server","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":116,"bytes_toclient":0,"start":"2023-12-07T20:58:35.473754+0100","src_ip":"51.159.221.237","dest_ip":"192.168.1.29","src_port":30301,"dest_port":6881},"payload":"Gy5ebWtMekYNAQMkZ2dpTT1UHzVhKygmSU9xQzxnZldfRERKED8QHUATQSh6KnU4fxVtYEAVBglleEwhXzJ5PnY9CAd8GCQ93nE=","payload_printable":"..^mkLzF\r..$ggiM=T.5a+(&IOqC<gfW_DDJ.?..@.A(z*u8..m`@...exL!_2y>v=..|.$=.q","stream":0,"packet":"yqgP9d0gkBsObbeFCABFAABmci1AADERBAgzn93twKgBHXZdGuEAUilRGy5ebWtMekYNAQMkZ2dpTT1UHzVhKygmSU9xQzxnZldfRERKED8QHUATQSh6KnU4fxVtYEAVBglleEwhXzJ5PnY9CAd8GCQ93nE=","packet_info":{"linktype":1},"verdict":{"action":"alert"}}
-
@Gblenn: Sorry, but I misled you about the
verdict: dropEVE log entry. That only gets logged when Suricata is running with Inline IPS Mode. That will not get logged with "drop" when running with Legacy Blocking Mode.I just finished a complete test of the suppression and blocking logic on a virtual machine, and I could not replicate your problem. Everything worked exactly as designed.
I used a Kali Linux VM to target the WAN port of a pfSense firewall VM running Suricata on the WAN. I have a ton of rules loaded for testing, but one set I frequently use for general testing is the Emerging Threats Scan rules. Those will reliably alert with a number of the rules triggering for MS-SQL, VNC, and other targeted
nmapscans.I configured Legacy Blocking Mode, turned on the "Block on DROP Only" option, saved the change and restarted Suricata on the interface.
I scanned the pfSense firewall VM from the Kali Linux VM. I immediately received a flood of alerts as expected. But no blocks were logged and no IP addresses were added to the
snort2cblock table because none of my rules were set to DROP. This was as expected.Next, I changed my SID MGMT
dropsid.conffile to include the "emerging-scan" rules, saved that change and checked the box to rebuild the rules on the interface and send Suricata a live rules update signal.I then scanned the firewall again from the Kali Linux machine. This time I received both alerts and blocks as expected.
Finally, I tested alert suppression by adding rule SID 2010936 by clicking the icon on the ALERTS tab. Here is the automatic Suppress List entry:
#ET SCAN Suspicious inbound to Oracle SQL port 1521 suppress gen_id 1, sig_id 2010936I then cleared all the blocks and alerts and repeated the Kali Linux scan of the pfSense machine. This time, I received alerts from all the same rules EXCEPT for SID 2010936 (because it was suppressed). There were no alerts from that SID and no blocks entered from it either.
This proves to me that the code logic is all working as designed. I tested all the possible scenarios.
-
@bmeeks said in Alert rule triggering Drop rule?:
Sorry, but I misled you about the verdict: drop EVE log entry. That only gets logged when Suricata is running with Inline IPS Mode. That will not get logged with "drop" when running with Legacy Blocking Mode.
No worries, I'm learning a lot and looking around in the eve.json files actually helped me figure out and remove a SMTP server on my sons PC, which had made my IP end up on Spamhaus bad rep list...
But I suppose this means that I might as well uncheck both those options as they will just add "noise" to the log file?
Your test seems conclusive and unless you have more ideas of where to look now, I'm thinking I should remove Suricata without keeping settings and reinstall fresh...? Even though I much rather figure this out...
-
Well, that didn't seem to help...
Removed Suricata completely, including log files. Restarted pfSense and installed Suricata fresh, and manually set it up as before.
But I still have this ET HUNTING rule popping up in the Blocks list.
It is set to Alert in the LAN Rule list, as are all ET HUNTING rules.
And this time I have no other references to the IP in question, other than two bits which look like the sections pasted below (with their own flow_id's).
"timestamp":"2023-12-08T14:02:46.056039+0100","flow_id":1537635578019863,"in_iface":"ix1","event_type":"http","src_ip":"192.168.1.92","src_port":51258,"dest_ip":"151.139.183.35","dest_port":80,"proto":"TCP","pkt_src":"wire/pcap","metadata":{"flowbits":["exe.no.referer","http.dottedquadhost"]},"tx_id":0,"http":{"hostname":"151.139.183.35","url":"/phf/c/doc/ph/prod5/msdownload/update/software/defu/2023/12/1024/am_delta_patch_1.403.87.0_82758fb46774249a30af8ffde579e044f936a35d.exe.json?cacheHostOrigin=download.windowsupdate.com","http_user_agent":"Microsoft-Delivery-Optimization/10.0","http_content_type":"application/json","http_method":"GET","protocol":"HTTP/1.1","status":200,"length":314,"request_headers":[{"name":"Connection","value":"Keep-Alive"},{"name":"Accept","value":"/"},{"name":"Accept-Encoding","value":"gzip, deflate"},{"name":"Content-Length","value":"0"}],"response_headers":[{"name":"Server","value":"nginx"},{"name":"Date","value":"Fri, 08 Dec 2023 13:02:39 GMT"},{"name":"Content-Type","value":"application/json"},{"name":"Content-Length","value":"314"},{"name":"Connection","value":"keep-alive"},{"name":"Cache-Control","value":"public,max-age=172800"},{"name":"Last-Modified","value":"Fri, 08 Dec 2023 09:47:20 GMT"}]}}
{"timestamp":"2023-12-08T14:02:46.602891+0100","flow_id":1948140415701057,"in_iface":"ix1","event_type":"fileinfo","src_ip":"151.139.183.35","src_port":80,"dest_ip":"192.168.1.92","dest_port":51260,"proto":"TCP","pkt_src":"wire/pcap","metadata":{"flowbits":["exe.no.referer","http.dottedquadhost","file.exe"]},"http":{"hostname":"151.139.183.35","url":"/c/msdownload/update/software/defu/2023/12/am_delta_patch_1.403.87.0_82758fb46774249a30af8ffde579e044f936a35d.exe?cacheHostOrigin=2.au.download.windowsupdate.com","http_user_agent":"Microsoft-Delivery-Optimization/10.0","http_content_type":"application/octet-stream","content_range":{"raw":"bytes 1048576-2094583/2094584","start":1048576,"end":2094583,"size":2094584},"http_method":"GET","protocol":"HTTP/1.1","status":206,"length":14046},"app_proto":"http","fileinfo":{"filename":"/c/msdownload/update/software/defu/2023/12/am_delta_patch_1.403.87.0_82758fb46774249a30af8ffde579e044f936a35d.exe","gaps":false,"state":"TRUNCATED","stored":false,"size":4096,"start":1048576,"end":2094583,"tx_id":0}}
And right after this one, there's the item where the rule is referenced:
{"timestamp":"2023-12-08T14:02:46.532735+0100","flow_id":1944640427955395,"in_iface":"ix1","event_type":"alert","src_ip":"151.139.183.35","src_port":80,"dest_ip":"192.168.1.92","dest_port":51259,"proto":"TCP","pkt_src":"wire/pcap","metadata":{"flowbits":["exe.no.referer","http.dottedquadhost","file.exe","ET.http.binary"]},"tx_id":1,"alert":{"action":"allowed","gid":1,"signature_id":2021076,"rev":2,"signature":"ET HUNTING SUSPICIOUS Dotted Quad Host MZ Response","category":"Potentially Bad Traffic","severity":2,"metadata":{"created_at":["2015_05_08"],"former_category":["INFO"],"updated_at":["2015_05_08"]}},"http":{"hostname":"151.139.183.35","url":"/c/msdownload/update/software/defu/2023/12/am_delta_patch_1.403.87
-
@Gblenn: are you running only a single Suricata instance, or do you have it running on more than one interface?
Are you using VLANs?
The blocks log file and the blocks table are common to all instances of Suricata running on a machine. If you have another Suricata interface configured, it might be adding the IP to the blocks list.
When you removed Suricata, did you uncheck the box to "Save Settings" on the GLOBAL SETTINGS tab? If not, then any configuration error you have will get brought right back in as Suricata will detected the previously saved configuration settings and use them. Uncheck that box, remove Suricata, and then reinstall it. You will then have a totally greenfield install and need to recreate your configuration from scratch.
I will mention this also, just in case. Snort shares the exact same block table with Suricata. If you are running Snort as well, then it and Suricata will both be competing for the same
pfsnort2c table. -
@bmeeks Yep only one instance, on ix1 (LAN). I am using VLANs but have not configured Suricata for any other interfaces than LAN.
And as before I only see one process running: (ps -ax | grep suricata)
Yes I made sure to uncheck Save Settings so it would be completely clean when I reinstalled. I had to recreate it manually, from my documentation (snipping tool pictures).
I am not running Snort, although I did test it just to make a performance test, many weeks ago.
-
Here's another wierd thing...
But it doesn't show up in the blocked hosts list.. this is the only entry:
Or the block.log file, last two entries...
12/09/2023-09:20:48.784801 [Block Src] [] [1:2021076:2] ET HUNTING SUSPICIOUS Dotted Quad Host MZ Response [] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 151.139.183.25:80
12/09/2023-12:07:45.248150 [Block Src] [] [1:2403359:88143] ET CINS Active Threat Intelligence Poor Reputation IP group 60 [] [Classification: Misc Attack] [Priority: 2] {UDP} 51.210.96.218:9683 -
@Gblenn said in Alert rule triggering Drop rule?:
Here's another wierd thing...
But it doesn't show up in the blocked hosts list.. this is the only entry:
Or the block.log file, last two entries...
12/09/2023-09:20:48.784801 [Block Src] [] [1:2021076:2] ET HUNTING SUSPICIOUS Dotted Quad Host MZ Response [] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 151.139.183.25:80
12/09/2023-12:07:45.248150 [Block Src] [] [1:2403359:88143] ET CINS Active Threat Intelligence Poor Reputation IP group 60 [] [Classification: Misc Attack] [Priority: 2] {UDP} 51.210.96.218:9683Your screenshots are not labeled, so I'm guessing they are showing first an entry from the ALERTS tab, then the corresponding rule's details from the RULES tab, and finally a view of the current BLOCKS tab. Assuming that is correct, here are the explanations:
The rule was triggered by traffic at 12:12:36 on 12/09/2023 and generated the alert entry. The rule's action has been changed to DROP (from the default of ALERT) by admin action (either manually clicking to change the action or using automated means through SID MGMT). The rule's action is showing as modified in the RULES tab view, and its new action is reflected in the ALERTS tab view. Note the DROP icon on the ALERTS tab simply means that is the rule's currently set action.
The alert from SID 2029493 did not result in a
block.logentry because either the IP address was covered by a Pass List entry or the IP was already blocked. The snort2c table only needs a single instance of an IP in the table to block, so multiple block requests for the same IP are ignored. The Suricata custom blocking plugin knows this, so it first checks if the IP is already in the block table. If it is, it does not try to block it twice and thus there will be no entry in theblock.logfile. However, that's not the case in your example. The next paragraph explains why I think the blocked IP is missing.The two IP addresses in that alert, 192.168.1.16 and 192.168.1.1, are in RFC 1918 space and I'm guessing are part of a local network behind the firewall (your LAN perhaps??). If so, then those addresses are automatically included in the default built-in Pass List and thus would not be blocked even though they do alert unless suppressed.
In short, I see nothing wrong with the screenshots you posted. They are consistent with designed behavior.
-
Yes, you are absolutely correct in your assumptions about the labeling... should have been clearer about that.
@bmeeks said in Alert rule triggering Drop rule?:
The two IP addresses in that alert, 192.168.1.16 and 192.168.1.1, are in RFC 1918 space and I'm guessing are part of a local network behind the firewall (your LAN perhaps??). If so, then those addresses are automatically included in the default built-in Pass List and thus would not be blocked even though they do alert unless suppressed.
Yes I started thinking that LAN gateway (pfsense) was on the list and of course I have this:
Perhaps I am getting overly suspicious, starting to imagine everything might be related to this issue I'm having...
Where, right now it seems it is only this one rule that I am seeing behaving wierdly (2021076)...
And just now it popped up again, just minutes after a block that should be there. The only thing they have in common are Port:80 and the LAN IP.
I started thinking that the external IP 151.139.183.36 might be in some other rule, from some "blacklist". But it actually looks like a completely legit webservice.12/09/2023-19:59:45.378714 [Block Dst] [] [1:2028651:2] ET USER_AGENTS Steam HTTP Client User-Agent [] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 23.73.2.86:80
12/09/2023-20:04:40.633504 [Block Src] [] [1:2021076:2] ET HUNTING SUSPICIOUS Dotted Quad Host MZ Response [] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 151.139.183.36:80 -
Here we go again, with three different IP's all showing up as Alerts in the Alerts tab (as they should)
But also showing up in the Blocked IPs tab (which they shouldn't):
