Suricata is blocking LAN and WAN IPs
-
@bmeeks Interestingly for me the problem is not occurring if I run those rules on the WAN-Interface with Suricata. Also please note that in my case the "offender" is a local Windows, as those rules are privacy-focused rules and not against attacks from outside.
So maybe this is part of the problem in my case.1:2025275 emerging-info.rules drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO Windows OS Submitting USB Metadata to Microsoft"1:2027390 emerging-user_agents.rules drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-Agent";You can trigger those if you (re-)connect a bluetooth device to Windows.
-
@bob-dig me too, on the WAN side no problem at all.
I'm testing the newer binary from @bmeeks and i have some news.
Suricata only blocks the parent interface's IPs, so in my case the subnet 10.10.20.0/24, but not the VLAN on that interface as you can see in the screenshot.
I have also tried to Drop a Rule where the Src is 192.168.1.10 (igb0 interface, that's my ISP modem) and the destination is 10.10.20.201 (my desktop), 192.168.1.10 wasn't blocked.
That's another rule, where the VLAN 69 (an IOT device, ip: 172.168.69.33) wasn't blocked by suricata.
-
@xm4rcell0x Thanks. Kinda the same here, I only noticed it on parent interface or interface without vlans. But also could be a coincidence.
-
@bob-dig said in Suricata is blocking LAN and WAN IPs:
@bmeeks Interestingly for me the problem is not occurring if I run those rules on the WAN-Interface with Suricata. Also please note that in my case the "offender" is a local Windows, as those rules are privacy-focused rules and not against attacks from outside.
So maybe this is part of the problem in my case.1:2025275 emerging-info.rules drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO Windows OS Submitting USB Metadata to Microsoft"1:2027390 emerging-user_agents.rules drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-Agent";You can trigger those if you (re-)connect a bluetooth device to Windows.
The type of rule and the direction of traffic flow have no significance. What is happening is that when the IP addresses from the rule are compared to the IPs and subnets stored in the Pass List Radix Tree, the comparison seems to fail for you. I don't know why, because it does not fail for me. When the comparison fails, the blocking code thinks the IP address is not in the Pass List and thus blocks it. That's the problem. At the point this decision is made in the code, it is not looking at anything other than the IP address. Nothing else.
-
So you are getting blocks of hosts residing on the parent interface (the LAN, for example), but not on VLANs defined on that parent? Is that correct?
That can be a hint. It seems I need to work on setting up an environment where I can use actual VLANs for more testing.
-
@bmeeks yes, that's what I've seen for now.
-
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
@bmeeks yes, that's what I've seen for now.
Can you please list for me (or else screenshot it from the firewall) the physical interfaces defined and then the VLANs assigned to each one? I need to know which of the subnets in your Pass List are VLANs and which are on parent interfaces.
Also provide a list of all the packages you have installed. You mentioned once about having DNSBL (from pfBlockerNG-devel) and HAProxy. Do you still have those installed?
This will help me duplicate your setup better.
-
@bmeeks
I have these packages:
Acme, Avahi, bandwidth, ntopng, freeradius3, Cron, haproxy-devel, pfblockerng-devel , suricata, pimd, service watchdog . If you need to take a look for my packages configuration let me know.These are the interfaces and the VLANs.
-
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
@bmeeks
I have these packages:
Acme, Avahi, bandwidth, ntopng, freeradius3, Cron, haproxy-devel, pfblockerng-devel , suricata, pimd, service watchdog . If you need to take a look for my packages configuration let me know.These are the interfaces and the VLANs.
Thanks for all of the details. Let me work on creating an environment in my test suite that duplicates yours as best I can. I need to be able to reliably reproduce the problem you, @Bob-Dig and others are having with Pass List IPs getting blocked. Once I can reproduce the problem, then fixing it should be easy.
-
One more request please -- will you screen-capture your Suricata interfaces for me? Just go to the INTERFACES tab in Suricata and post up a copy of that tab so I can see how many instances you are running. I want to duplicate everything as fully as possible ...
. Feel free to obfuscate any real public IP addresses, but I don't believe anything private will show up there. It should just show the interfaces and their names and the current Suricata status. -
@bmeeks
Yeah no problem. I only have LAN and WAN, i wanted to add iot and guest, but I ran in this problem so I didn't.
All default settings. I have the et-scan , p2p on the lan (only for testing purposes), on the wan i have p2p, ciarmy, compromised. -
@xm4rcell0x:
On all of your Suricata interfaces except for the WAN (because it is PPPoE), you could be running Inline IPS Mode. That would do away with the need for a Pass List. Looking at your physical interfaces, all of them except the PPPoE virtual interface on the WAN are netmap-compatible.I recommend you consider changing your LAN interface over to Inline IPS Mode. That will automatically over all of your defined VLANs as well. You already have selected rules configured for the DROP action, so you would not need to change anything in your rules configuration.
Simply stop Suricata on the LAN, go to the INTERFACE SETTINGS tab for the LAN and change the blocking mode from Legacy to Inline IPS. I also recommend scrolling down a little farther and changing the Suricata Runmode from autofp to workers. That improves performance a little bit when using the netmap kernel device. Save the changes, then go back and start Suricata.
-
@bmeeks thanks Bill, I'll give it a try. I'm still scared from 2y ago when I disable my checksum offload on the ix0 and my pfSense crashed.
Later this month I'll surely give it a try, i have to put a newer CPU so that's not a problem if it will crash. -
For me it even had happened in inline-Mode.
Running it on WAN in Legacy Mode for many days now, no problem at all (WAN IP never got blocked).
One Difference between WAN and LAN would be that there are absolutely no VLANs on WAN in my setup... -
I haven't tried it yet
At the end of the month I'll surely try to switch to inline. -
@bob-dig said in Suricata is blocking LAN and WAN IPs:
For me it even had happened in inline-Mode.
Running it on WAN in Legacy Mode for many days now, no problem at all (WAN IP never got blocked).
One Difference between WAN and LAN would be that there are absolutely no VLANs on WAN in my setup...There is not even a blocking module loaded when using Inline IPS Mode, so it would be impossible for Suricata to block an IP completely using Inline IPS Mode. Add to that the Pass List is not used at all in that mode (in fact, the option is hidden when Inline IPS Mode is selected for an interface).
So not sure what you are talking about here. The only thing I can imagine is you had DROP rules triggering on some traffic. And it is expected for them to block the traffic they trigger on. They do this by dropping individual packets from the triggering stream, not by putting the host's IP address in the snort2c blocking table. Inline IPS Mode does not block by IP address, it simply drops (or does not forward) select packets that match rules with the DROP action.
-
@bmeeks said in Suricata is blocking LAN and WAN IPs:
The only thing I can imagine is you had DROP rules triggering on some traffic.
Yup, that's it.
Problem for me was and is, because those "rules" I use gets triggerd also when Windows boots. And when my machine got blocked and I tried another machine, it also could get blocked (or dropped) which really gave me headache, because all my browser are only on Windows machines (real or VMs).
-
@bob-dig said in Suricata is blocking LAN and WAN IPs:
@bmeeks said in Suricata is blocking LAN and WAN IPs:
The only thing I can imagine is you had DROP rules triggering on some traffic.
Yup, that's it.
Problem for me was and is, because those "rules" I use gets triggerd also when Windows boots. And when my machine got blocked and I tried another machine, it also could get blocked (or dropped) which really gave me headache, because all my browser are only on Windows machines (real or VMs).
Yes, but that is not really the thrust of this thread. The problem other users in this thread were describing occurred with Legacy Mode where the Pass List and the snort2c IP blocking table are used. Neither of them have any relevance to Inline IPS Mode. So it's crossing up apples and oranges to use an old analogy.
Inline IPS Mode does not "block an IP". It selectively drops certain packets. That is an important distinction! Legacy Mode literally blocks an IP address entirely. No traffic of any kind can come and go from a blocked IP address in Legacy Mode. Contrast that to Inline IPS Mode where only specific rule-triggering packets are dropped. The host at that IP is still perfectly free and open to swap other kinds of data across the network, because its IP address is not blocked.
So for example, with Inline IPS Mode I might choose to block
icmp-replypackets from IP address 1.2.3.4 with a DROP rule. So noicmp-replypackets from that host will ever get passed. But that host can still send TCP or UDP packets freely (because the IP is not blocked, only selected packets are dropped). It can even sendicmp-requestpackets if I'm not blocking those, but it can't sendicmp-replypackets due to the drop rule. But if I was using Legacy Mode Blocking and had the same rule in place, the very firsticmp-replypacket that crossed the network from IP 1.2.3.4 would result in IP address 1.2.3.4 being added to the snort2c blocking table. Now ALL traffic from that host, including TCP and UDP traffic, will get blocked. That's because Legacy Mode blocks at the IP level, not at the packet level. -
@bmeeks Now I got you, thanks for the detailed explanation. So it must have been different then I thought.
