Snort not blocking ET trojan Alerts
-
PFSense Release: 2.4.4-RELEASE-p3 (amd64)
Snort Package version: 3.2.9.10
Block Offenders is checked
ETOpen usedThe issue I am having is I am finding several alerts in the alert log but not corresponding blocks on the block tab. I do see plenty of blocked items like port scans or ET Scan SSH. What I was concerned about is I found an alert entry for ET TROJAN OSX/Shlayer CnC Landing M2 but I do not see that it blocked anything. I would assume since it alerted, and I have block offenders checked, that it would have blocked the source when that was alerted but it didnt.
Is there something I need to configure to make the et.trojan ruleset automatically block?
Here is the rule in question:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN OSX/Shlayer CnC Landing M2"; flow:established,to_server; content:"GET"; http_method; content:"/hyllkjit/"; http_uri; depth:10; fast_pattern; content:"/?n="; http_uri; pcre:"/^/hyllkjit/[a-f0-9]{8}/?n=\d{4,10}$/Ui"; metadata: former_category MALWARE; reference:url,www.carbonblack.com/2019/02/12/tau-threat-intelligence-notification-new-macos-malware-variant-of-shlayer-osx-discovered/; classtype:trojan-activity; sid:2026911; rev:3; metadata:affected_product Mac_OSX, deployment Perimeter, signature_severity Major, created_at 2019_02_14, malware_family Shlayer, performance_impact Low, updated_at 2019_02_14;)
-
You do know that blocked hosts will timeout if the setting is configured on the GLOBAL SETTINGS tab? Also, if you reboot the firewall or if the firewall internal tables are flushed and reloaded that Snort blocks will disappear.
So I'm guessing that either one of the above conditions resulted in the former block being cleared, or one or both of the IP addresses in the alert is interpreted as being part of a Pass List (likely the default pass list).
Snort blocks by making a FreeBSD system call to insert offending IP addresses into a built-in pfSense
pf
table called snort2c. IP addresses in that table are blocked. If the table is flushed by some external event, the blocks disappear. The BLOCKS tab in Snort is populated by reading the contents of that snort2cpf
table. -
You would be assuming and guessing wrong. I have it set to never clear blocked hosts in the global settings. I have also not rebooted the firewall and this was witnessed live in action. There are nothing in the pass lists either that would prevent it from blocking. It simply does not block for this threat. I have rebooted since this thread was made so its obviously not there now but the issue im posting about happened in real time and should have blocked I thought.
But sadly I think its just something as dumb as my looking at the block logs incorrectly. I might have been assuming the newest alert was on top. As I already cleared everything and watching again I will keep an eye out to see if thats the case now that I noticed the logs in in defending order with the newest last and the oldest listed first in the list.
-
@jeremym said in Snort not blocking ET trojan Alerts:
But sadly I think its just something as dumb as my looking at the block logs incorrectly. I might have been assuming the newest alert was on top. As I already cleared everything and watching again I will keep an eye out to see if thats the case now that I noticed the logs in in defending order with the newest last and the oldest listed first in the list.
The ALERTS tab data is sortable by column. So if you click on the columns the data will sort using the selected column as the sort key. The default is to sort by event time descending which would put the most recent alerts at the top of the page.
The BLOCKS tab is just reading out the contents of the snort2c
pf
table and displaying the data. It also reads the alert log to get some extra data to associate with the blocked IP addresses so it can show some context around each block. All it gets from the snort2c table is just the IP address, so without reading some context from the alert log the blocked tab results would be pretty plain. So it reads in the currently active alert log file and finds all the alerts whose IP addresses (source and/or destination) match up with an IP address currently stored in the snort2c table.It is basically impossible within the blocking module code for some rules to block and others not. The logic does not look at the rule's content or action at all. The only two things that can prevent a block are if the alerting packet has an invalid IP header (which is highly unlikely) or if one of the IP addresses in the packet matches a pass list entry.