Suricata blocking hosts in the passlist (6.0.4)
-
There's been a few posts along these lines but I couldn't find anything relevant to solve my issue.
We have some users who connect to the network via openvpn (10.40.12.0/24) and run large sql queries on some hosts (10.40.0.0/24). The firewall allows all traffic between those two networks and there is otherwise no traffic blocked... until they run their sql query. At that point a BLOCK is registered in suricata:
01/25/2022-17:03:13.687788 [Block Src] [**] [1:2001583:16] ET SCAN Behavioral Unusual Port 1433 traffic Potential Scan or Infection [**] [Classification: Misc activity] [Priority: 3] {TCP} 10.40.12.2:50042I have suricata listening on the LAN and WAN interfaces and it's otherwise doing a great job keeping out the onslaught of legitimately bad traffic which trips the same SID so I don't want to stop tracking it.
My passlist includes the IP range of my LAN and the VPN net (edited to leave out some private IPs)
8.8.8.8/32 10.40.0.0/24 10.40.0.1/24 < LAN 10.40.0.5/32 10.40.0.17/32 10.40.4.0/24 10.40.4.1/24 10.40.8.0/24 10.40.8.1/24 10.40.12.0/24 < VPN 127.0.0.1/32 172.16.40.0/24 ::1/128 fe80::208:a2ff:fe0e:a3cd/128 fe80::208:a2ff:fe0e:a3ce/128The IP blocked in the log snip above (10.40.12.2) is in the network passlist (10.40.12.0/24). It shouldn't be blocked, right? Where else should I look to get to the bottom of this?
-
@troutpocket said in Suricata blocking hosts in the passlist (6.0.4):
There's been a few posts along these lines but I couldn't find anything relevant to solve my issue.
We have some users who connect to the network via openvpn (10.40.12.0/24) and run large sql queries on some hosts (10.40.0.0/24). The firewall allows all traffic between those two networks and there is otherwise no traffic blocked... until they run their sql query. At that point a BLOCK is registered in suricata:
01/25/2022-17:03:13.687788 [Block Src] [**] [1:2001583:16] ET SCAN Behavioral Unusual Port 1433 traffic Potential Scan or Infection [**] [Classification: Misc activity] [Priority: 3] {TCP} 10.40.12.2:50042I have suricata listening on the LAN and WAN interfaces and it's otherwise doing a great job keeping out the onslaught of legitimately bad traffic which trips the same SID so I don't want to stop tracking it.
My passlist includes the IP range of my LAN and the VPN net (edited to leave out some private IPs)
8.8.8.8/32 10.40.0.0/24 10.40.0.1/24 < LAN 10.40.0.5/32 10.40.0.17/32 10.40.4.0/24 10.40.4.1/24 10.40.8.0/24 10.40.8.1/24 10.40.12.0/24 < VPN 127.0.0.1/32 172.16.40.0/24 ::1/128 fe80::208:a2ff:fe0e:a3cd/128 fe80::208:a2ff:fe0e:a3ce/128The IP blocked in the log snip above (10.40.12.2) is in the network passlist (10.40.12.0/24). It shouldn't be blocked, right? Where else should I look to get to the bottom of this?
One thing I see wrong is that your Pass List contains overlapping networks. That very well could be confusing the Radix Tree code used for managing pass lists. These pairs of IP ranges are overlapping:
10.40.0.0/24 10.40.0.1/24 10.40.4.0/24 10.40.4.1/24 10.40.8.0/24 10.40.8.1/24Did you enter these addresses manually, or are they being automatically added?
-
Interesting. I did not enter those manually. They show up with PASSLIST set to default. Suricata is running on only one of a pair of HA firewalls. The addresses ending in .1 are the VIP for the HA interfaces (wan, lan, corp, guest, etc). I have about 20 locations with HA pairs of 7100's that run suricata and all of them have the VIP listed in the PASSLIST default.
I do not sync the config to the other firewall, nor is suricata installed there. I need to get it working on one firewall first.
-
@troutpocket said in Suricata blocking hosts in the passlist (6.0.4):
Interesting. I did not enter those manually. They show up with PASSLIST set to default. Suricata is running on only one of a pair of HA firewalls. The addresses ending in .1 are the VIP for the HA interfaces (wan, lan, corp, guest, etc). I have about 20 locations with HA pairs of 7100's that run suricata and all of them have the VIP listed in the PASSLIST default.
I do not sync the config to the other firewall, nor is suricata installed there. I need to get it working on one firewall first.
The GUI code makes a series of pfSense system calls to obtain the various interface IP addresses and networks in use on the firewall locally. It then adds those to the automatic (or default) Pass List.
I wonder if there is an error in the VIP code system API call. I will look into that further, but I'm not 100% convinced that's your issue here.
As has been reported in other threads (with my replies in them), this problem with random IPs seeming to bypass a Pass List has been an ongoing issue for quite some time. And I have never been able to reproduce it, let alone reliably reproduce it. Thus troubleshooting is relegated to trying various "shots in the dark" in an attempt to address it.
Are you currently running the latest version of Suricata? The most recent version is 6.0.4. That update has a couple of changes in the custom blocking module that may help.
-
Yes, suricata 6.0.4 and pfsense+ 21.05.2 release.
Would adding a couple custom rules that indicates the network and SID be a good idea? I'm not 100% sure of the syntax...
pass net 10.40.0.0/24 any <> any any (msg:"pass all traffic from/to 10.40.0.0/24"; sid:2001583;) pass net 10.40.12.0/24 any <> any any (msg:"pass all traffic from/to 10.40.12.0/24"; sid:2001583;) -
@troutpocket said in Suricata blocking hosts in the passlist (6.0.4):
Yes, suricata 6.0.4 and pfsense+ 21.05.2 release.
Would adding a couple custom rules that indicates the network and SID be a good idea? I'm not 100% sure of the syntax...
pass net 10.40.0.0/24 any <> any any (msg:"pass all traffic from/to 10.40.0.0/24"; sid:2001583;) pass net 10.40.12.0/24 any <> any any (msg:"pass all traffic from/to 10.40.12.0/24"; sid:2001583;)PASS rules will work, but should be used carefully. For example, with those rules you gave, are essentially whitelisting two entire Class C subnets. That's probably not what you want to do.
PASS rules are evaluated first, and any traffic matching such a rule is immediately exempted from all other inspection. It is unconditionaly passed.
Your alert is a false positive originating from a particular IP address. So why not just use alert suppression on that single IP? You can automatically create Suppress Rules by clicking on the appropriate icon on the ALERTS tab. You can suppress by IP in either the SOURCE or DESTINATION columns. You can also suppress by SID, but you say you want that rule active for other hosts, so suppressing by SID would not be an option in that case.
-
In any case my syntax was wrong and suricata wouldn't start with those rules. I thought the way I wrote them would only pass the SID "2001583" on those networks and hopefully continue scrutinizing everything else. If it's allowing everything regardless of traffic then I won't do it.
If I do as you suggested, will that prevent the block action? A computer connecting to the VPN is assigned an IP from the 10.40.12.0/24 pool. My searching isn't turning up many examples... would this work as a line in the suppress list:
suppress gen_id 1, sig_id 2001583, track by_src, net 10.40.12.0/24 -
@troutpocket said in Suricata blocking hosts in the passlist (6.0.4):
In any case my syntax was wrong and suricata wouldn't start with those rules. I thought the way I wrote them would only pass the SID "2001583" on those networks and hopefully continue scrutinizing everything else. If it's allowing everything regardless of traffic then I won't do it.
If I do as you suggested, will that prevent the block action? A computer connecting to the VPN is assigned an IP from the 10.40.12.0/24 pool. My searching isn't turning up many examples... would this work as a line in the suppress list:
suppress gen_id 1, sig_id 2001583, track by_src, net 10.40.12.0/24Yes, that should work for you.
You can't use SIDs in rules, as you have seen. That's because rules actually only scan the contents of packets on the wire. That content is the IP header and then any payload data. Usually the payload these days is encrypted, so all the IDS/IPS can really do is look at the header info. SID is a construct of the rule writer and is used simply to uniquely identify each rule. It is not transmitted across the network, and it cannot be used for "matching" in a rule.
If you are thinking about writing rules, you really need to read and understand the syntax of rules. This is also invaluable for interpreting what a triggered rule is telling you.
-
FYI this is still happening on 22.05 with Suricata 6.0.4_1. I also have a /24 subnet in the passlist which overlaps with the automatically added values. If I remember correctly, I added this because the auto-added IP addresses were being blocked before, hence I'm not convinced that overlapping entries are the issue. I've removed the /24 for now, but I hope this issue gets more attention. Many of us are still stuck with hardware that can't properly do inline mode :(
-
@marc05 said in Suricata blocking hosts in the passlist (6.0.4):
FYI this is still happening on 22.05 with Suricata 6.0.4_1. I also have a /24 subnet in the passlist which overlaps with the automatically added values. If I remember correctly, I added this because the auto-added IP addresses were being blocked before, hence I'm not convinced that overlapping entries are the issue. I've removed the /24 for now, but I hope this issue gets more attention. Many of us are still stuck with hardware that can't properly do inline mode :(
Will you share your Passlist IP addresses please? I would like to try and reproduce your scenario inside my virtual machine test environment. I need the IP addresses and subnets so I can precisely duplicate your setup.
-
Here it is. Interestingly, the WAN DHCP6 address/subnet is not included in the list, only the LAN tracked interface IPv6 subnet. Note: all "Auto-Generated IP Addresses" options are checked.
To get around the antispam checks:
path tld domain
nf169373 net cl1p -
@marc05 said in Suricata blocking hosts in the passlist (6.0.4):
Here it is. Interestingly, the WAN DHCP6 address/subnet is not included in the list, only the LAN tracked interface IPv6 subnet. Note: all "Auto-Generated IP Addresses" options are checked.
To get around the antispam checks:
path tld domain
nf169373 net cl1pGot the list. Can you also tell me which IP or IPs on the list is getting blocked when it should not be?
-
The one ending in ".7/32". Thank you for looking into this. If there's anything else I can assist with, I'd be glad to help.
-
@marc05 said in Suricata blocking hosts in the passlist (6.0.4):
The one ending in ".7/32". Thank you for looking into this. If there's anything else I can assist with, I'd be glad to help.
Thanks. I'm trying once more to replicate this so I can find the cause. It is somewhat rare (or at least I've never been able to replicate it in my VM test setup), but it apparently does happen to some users.
Suricata upstream also made changes to the Radix Tree code that I use in the PassList logic within the custom blocking module on pfSense. They found some errors in that original code and fixed them in the 6.0.5 release.
-
Thinking out-loud, maybe the issue isn't on the matching code but rather some race condition where the block/snort2c alias addition happens before the passlist check.
-
@marc05 said in Suricata blocking hosts in the passlist (6.0.4):
Thinking out-loud, maybe the issue isn't on the matching code but rather some race condition where the block/snort2c alias addition happens before the passlist check.
No, I don't believe that's possible with the way the code is written. The check of the pass list is done first, and only if negative is the system call made to put the block in place. It is serial code all running in the same thread.
-
Something I've noticed is that my config.xml no longer contains
<wanips>, and I don't see an option for that in the GUI. Looks like it was removed and never put back in, but there's still logic using it.https://github.com/pfsense/FreeBSD-ports/commit/22dc43fe8858ef0b724eb4bbcdd1a86b152b33c4
https://github.com/pfsense/FreeBSD-ports/blob/1fd0a3eecbfc1626d76716fdf2869c1057cabe22/security/pfSense-pkg-suricata/files/usr/local/pkg/suricata/suricata.inc#L340
-
@marc05 said in Suricata blocking hosts in the passlist (6.0.4):
Something I've noticed is that my config.xml no longer contains
<wanips>, and I don't see an option for that in the GUI. Looks like it was removed and never put back in, but there's still logic using it.https://github.com/pfsense/FreeBSD-ports/commit/22dc43fe8858ef0b724eb4bbcdd1a86b152b33c4
https://github.com/pfsense/FreeBSD-ports/blob/1fd0a3eecbfc1626d76716fdf2869c1057cabe22/security/pfSense-pkg-suricata/files/usr/local/pkg/suricata/suricata.inc#L340
That line is meaningless code now. It needs to be removed for cosmetics, but it has no impact on the real WAN IP getting into the Pass List. That is now pulled in automatically by code within the binary portion of the custom blocking module. It gets those by asking the operating system for local interface addresses.
Here is a link to where this is handled now within the custom blocking module portion of the binary: https://github.com/pfsense/FreeBSD-ports/blob/devel/security/suricata/files/patch-alert-pf.diff#L515.
