Trying to get snort to block local client if they have a trojan

[jimmychoosshoes]

we have a guest wifi. Snort if is running on the wifi interface and the WAN interface. WIFI interface is set to block BOTH with the intention that the client could be blocked. WIFI interface uses DNS resolution and an opendns IP

I had a guest that was triggering snort alerts:

ET TROJAN SOMNIRECORD Backdoor DATA Command in DNS Query

What happened is that the alert was generated in the WIFI interface, snort gives me the client IP and says the destination is the WIFI interface IP (correct, that is what DHCP says is the gateway and the DNS). But the openshield IP gets blocked by snort because it thinks the WAN IP is chatting with the DNS server for the "ET TROJAN SOMNIRECORD Backdoor DATA Command in DNS Query"

How can I get snort to allow local IP on my WIFI interface to be blocked? I believe snort naturally stops blocking on local NIC.

I took a brief look at "Home Net" and "External Net" but couldnt figure out how to create new ones - the Home Net has the network interfaces in pfsense, the "External Net" has the same but with ! in front of them.

Is there acustom setting I can use to allow my WIFI address range to be blocked?

With DHCP I dont want to manually block IPs as they will cycle.

[joshs922]

@jimmychoosshoes I'm having a similar issue this morning. I use OpenDNS and my pihole/DNS server is triggering this 1:2044746 rule "ET TROJAN SOMNIRECORD Backdoor DATA Command in DNS Query" as it makes DNS queries. The rule is unsearchable/unknown apparently. I wish I knew how to figure out of this is a false positive. I found some things online about the somnirecord exploit, but so far I can't find any ofthe supposed suspect apps or services running on my client. Anyone else having this issue?

[bmeeks]

The default pass list for Snort (a pass list contains IP addresses or networks that should never be blocked) includes all the locally attached subnets except the WAN. So, for example, if you have three locally-attached interfaces as follows:

• 192.168.0.0/24 (with the firewall interface at 192.168.0.1)
• 192.168.10.0/24 (with the firewall interface at 192.168.10.1)
• 192.168.20.0/24 (with the firewall interface at 192.a68.20.1)

The default pass list will include these entries: 192.168.0.0/24, 192.168.10.0/24, and 192.168.20.0/24). It will also include the WAN interface IP, the default gateway IP, and any VPNs, Virtual IPs, and configured DNS servers.

In your scenario, the Wi-Fi network is a "locally attached" subnet and thus will live on the default pass list and clients on that network will NOT be blocked. However, clients they "talk to externally" (meaning Internet addresses) will be blocked.

You generally should not run Snort on the WAN. It is somewhat useless there, especially if also running instances on your local internal interfaces. Snort sees incoming traffic on the WAN before the firewall acts upon it, so this results in two undesirable outcomes. First, you are wasting CPU cycles and RAM intercepting and analyzing traffic the firewall rules are likely going to drop anyway. Second, all the addresses you see there for internal hosts are hidden by the NAT. So, all the internal hosts show up as the WAN IP in the alerts. You can't easily determine which internal host was the source or destination of the alert.

If you desire to actually block clients on your Wi-Fi, then you will need to create a custom Pass List that omits the subnet for your Wi-Fi but includes all of your other subnets. There is a checkbox option when creating a custom pass list that omits automatically including locally-attached subnets.

Your comment about HOME_NET and EXTERNAL_NET indicates to me that you have limited experience running an IDS/IPS such as Snort. You should NOT monkey around with the HOME_NET and EXTERNAL_NET variable settings unless you fully understand what they are for and how they work. Incorrectly setting those variables will result in large numbers of the Snort rules ceasing to trigger properly.

[bmeeks]

As for that particular rule (SID 2044746) now suddenly triggering, my guess is the rule author made a recent change that is resulting in an increase in false positives. If so, that is certainly not the first time such an error has been made by the rule creators.

Unless I could prove to myself via packet captures that the traffic was truly malicious, I would be strongly inclined to simply disable that rule for now until is is fixed up by the author.

[joshs922]

@bmeeks said in Trying to get snort to block local client if they have a trojan:

You generally should not run Snort on the WAN. It is somewhat useless there, especially if also running instances on your local internal interfaces. Snort sees incoming traffic on the WAN before the firewall acts upon it, so this results in two undesirable outcomes. First, you are wasting CPU cycles and RAM intercepting and analyzing traffic the firewall rules are likely going to drop anyway. Second, all the addresses you see there for internal hosts are hidden by the NAT. So, all the internal hosts show up as the WAN IP in the alerts. You can't easily determine which internal host was the source or destination of the alert.

Why have I never thought of this? This makes perfect sense. So, run snort on the LAN interface then? Sheesh I'm an idiot.

[bmeeks]

@joshs922 said in Trying to get snort to block local client if they have a trojan:

So, run snort on the LAN interface then?

Yes, on the LAN and/or any other internal interface as desired. I've shared these two diagrams a lot over the last few months. They show the traffic flow when Snort or Suricata is in service with either the Legacy Blocking Mode or Inline IPS Mode.

I've also mentioned in previous posts about this that you don't run Snort to protect the firewall. If you think your firewall needs an IDS/IPS, then you need a new firewall software . When run on internal interfaces, the IDS/IPS still offers maximum protection because no traffic from the Internet can reach an internal host without first traversing the internal interface. And if the IDS/IPS is running on that internal interface, the traffic is checked in both the inbound and outbound directions.

The ONLY time in my view that you might consider putting Snort on the WAN is if you have very limited RAM and CPU horsepower and running multiple instances (one per internal interface) would bog down the system. But really, at that point, you should seriously consider new hardware.

[michmoor]

@bmeeks so is it fair to say that if you want protect your Server vlan from your LAN vlan (there is necessary cross talk needed) then a custom pass list is needed? do I attach that custom list to the LAN interface?

[bmeeks]

@michmoor said in Trying to get snort to block local client if they have a trojan:

@bmeeks so is it fair to say that if you want protect your Server vlan from your LAN vlan (there is necessary cross talk needed) then a custom pass list is needed? do I attach that custom list to the LAN interface?

Yes, a custom list would be needed. You can attach it to either or both interfaces as desired dependent upon exactly how you define the locally-attached subnets in the list.

But this idea of blocking hosts in locally-attached networks is a very bad one! Let me explain why. Pass Lists only come into play when using Legacy Mode Blocking. That mode works by adding a host's IP address to an internal pfSense firewall table. All IP addresses placed in that table are blocked by the firewall. ALL traffic to/from that host is blocked. This includes all protocols. That host will not even be able to perform DNS lookups nor receive an IP from DHCP once blocked. You really don't want that on internal hosts as it is a recipe for unending headaches from false positives (and there will be many false positives, I can guarantee that).

If you want to do something like that, then Inline IPS Mode is a much better fit as it selectively drops just offending packets. It does not block the host entirely. Inline IPS Mode is a much finer tool for selective enforcement of a security policy. Legacy Mode Blocking, in contrast, is a gigantic sledgehammer. Because Inline IPS Mode does not block all traffic from a host, there is no need for a Pass List and thus that feature is disabled when using Inline IPS Mode.

[michmoor]

@bmeeks ok I’m clear on the different blocking modes, thanks for that.
So to make sure I understand, if my LAN reaches out to my SERVER vlan and let’s say there is some Trojan on the LAN side, will Suricata/Snort drop the flow even tho these are directly connected networks on the firewall and not external (WAN side)

[jimmychoosshoes]

My snort knowledge is not high but I am experienced in IDS. I have found my own answer by using the whitelist pass with internal interfaces unticked and add required subnets manually. home and external net remain default.

I incorrectly thought that home and external nets changed the behaviour of automatic blocking. I was incorrect but have now found the information I need and am more familiar with snort terminology.

As for the original intent, it is my understanding that there are a lot of false positives. I have traced one of the guests and they use a macbook air. The SOMNIRECORD trojan does not have a mac component yet so this was a false positive.

In my previous best practice it was usually desirable to have edge WAN incoming blocked first, hence WAN blocking. LAN blocking was also desirable. Of course it is up to individuals for their purposes. CPU and RAM is ok.

[bmeeks]

@michmoor said in Trying to get snort to block local client if they have a trojan:

will Suricata/Snort drop the flow even tho these are directly connected networks on the firewall and not external (WAN side)

No, in Legacy Mode Blocking it will not unless the default Pass List is replaced by a custom one in the manner @jimmychoosshoes describes in his post just above this one.

The default behavior for the IDS/IPS packages is to NOT block host IPs from locally-attached networks. They will block external IPs, however, and that accomplishes what is normally required for protection.

But when using Inline IPS Mode, there is no Pass List logic involved. Any malicious traffic would be dropped (not forwarded), but only if the detection rule is properly triggered. But one issue with detection is the composition of the HOME_NET variable. That variable will, by default, contain all the locally-attached subnets. And EXTERNAL_NET will, by default, be defined as !HOME_NET (which means all IPs not defined in HOME_NET are in EXTERNAL_NET). Many IDS/IPS rules are written with $HOME_NET and $EXTERNAL_NET as part of the triggering condition along with traffic direction. For example, the vast majority of rules start like this:

alert tcp $EXTERNAL_NET any -> $HOME_NET any .....

The very first condition of this rule is that the traffic flow must be from an IP defined in the $EXTERNAL_NET variable towards an IP defined in the $HOME_NET variable. So, the source IP must be in EXTERNAL_NET and the destination IP must be in HOME_NET. Because locally-attached subnets are all included in $HOME_NET by default, this condition would not be satisfied in your example of a device in SERVER communicating with a device in LAN, and the rule would never trigger.

While the default behavior of Pass Lists and the HOME_NET variable could certainly be changed by altering the code of the packages, it would generate no end of howling from the majority of users because as I described earlier, Legacy Mode blocking blocks the IP completely. All traffic is blocked. That will result in a lot of problems for your users. And there are just too many false positives these days for that change in default behavior to be workable.

The whole premise of the IDS/IPS packages today in pfSense is to protect from external threats. External in this context means beyond the network perimeter as in "the Internet". The packages are not set up by default to block internal threats from one local network over to another. But you can customize the configuration to accomplish that if you desire. Simply create as many custom Pass Lists as required and then assign them to interfaces. Remember that Pass Lists are simply collections of IP addresses, so a custom Pass List can be selected and applied as the HOME_NET variable if needed. That's how you would customize the content of the $HOME_NET variable used in rules. I would probably never monkey with EXTERNAL_NET, though. Leave it set to "default" and that will result in it always being set to !HOME_NET (which is almost always what you want).