Surricata blocks wan ip after change - pppoe
-
Hy all,
Allready since i installed and configured suricata (a few months ago), it blocks my wan ip sometimes after it changes. I have a pppoe connection and the WAN ip changes every few days.
Kind regards.
-
Hy all,
Allready since i installed and configured suricata (a few months ago), it blocks my wan ip sometimes after it changes. I have a pppoe connection and the WAN ip changes every few days.
Kind regards.
That is not supposed to happen. There is a thread that launches with Suricata that is supposed to monitor the firewall interface IP addresses and update an internal whitelist table as the interface IPs change. Sounds like that thread may not be running or working in your case. I will test that in the binary to see if something has changed recently in FreeBSD that might have impacted how that IP address monitoring thread works.
On a related topic, you generally should run an IDS/IPS on the LAN for home networks. This way you are not bothered with the WAN IP showing up for all local hosts due to NAT. Running it on the LAN would also stop it from blocking your WAN IP.
You are not really using Suricata to protect your firewall – you should be more interested in your LAN hosts. The pfSense firewall is very secure by default and can basically take care of itself. All unsolicited inbound traffic on the WAN is blocked by the out-of-the-box configuration of pfSense.
Bill
-
Follow-up on the issue of WAN IP blocking when using Legacy Mode. I did a quick test in my virtual machine lab and found out that the automatic background thread for detecting firewall interface IP changes no longer appears to be working correctly. I will need to create a debug build of the binary and walk through all the function calls to see what changed. I'm not sure what broke it. Maybe it was the update to FreeBSD 11, or maybe it was a change within the upstream Suricata binary.
For now, if you have a frequently changing WAN IP and you use NAT and you have Suricata running on your WAN interface, you very well may experience blocking of your WAN IP if it changes while Suricata is already running. My suggested workaround is to run Suricata on the LAN instead (especially if the WAN IP blocks are giving you heartburn).
I will debug the issue and try to get a fix out soon.
Bill
-
Thanks for your quick reply and suggestions.
As for now, i followed your suggestions. it makes sense off course. I noticed allready that the blocks by surricata (on wan) were allready blocked by the firewall (deny all…).
What could be the purpose of running suricata on wan?
Kind regards.
-
Thanks for your quick reply and suggestions.
As for now, i followed your suggestions. it makes sense off course. I noticed allready that the blocks by surricata (on wan) were allready blocked by the firewall (deny all…).
What could be the purpose of running suricata on wan?
Kind regards.
I found the bug in the custom blocking plugin for the binary that made it fail to recognize changes in firewall interface IP addresses. A fix will be out soon.
For home networks, and even many small business networks, there is no good case for running an IDS/IPS on the WAN. If you don't host externally accessible services such as DNS, web, etc. (I mean public services, this does not apply to something like a VPN), then the firewall already will default deny all unsolicited inbound connections. So having Suricata or Snort alert on something the firewall is going to deny anyway is not too helpful. The only exception would be if you as the admin just have a burning desire to know what hits your firewall's public interface.
Even with a network where you hosted publically available hosts, they would likely be in a DMZ and you would be better off to run the IDS/IPS on the firewall's DMZ interface.
Bill
