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/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/24
Yes, 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.