Snort stops processing rules when WAN IP changes
-
After I upgraded to 2.2, I started having trouble with Snort.
First, when my WAN IP changed, Snort would block it due to a port scan rule. As I've read, that's because Snort only processes the pass-list on boot, and my new WAN IP is not in memory. That didn't seem to be the case before, though. My IP would change and everything would continue working as expected.
So I disabled the portscanning rules, and a NAT-PMP rule, which was also being triggered after my WAN IP changed. Now something else happens: when my WAN IP changes, and until I manually reset the Snort Interface, no rule is ever triggered.
Usually a Bad Rep rule is triggered every 15 minutes at least, so it's a good indication that Snort is not working when no rules have been triggered in the past 24 hours - the same exact time when my WAN IP changed.
Is this expected behaviour? Did I do something wrong? I've re-read all the guides, and I've been running Snort for over a year now on pfSense and have never seen this kind of issue.
I guess the solution I'm looking for is how to get Snort to read the pass-list again every time my WAN IP changes. That should fix my first issue. The second (and larger) issue - the not blocking anything issue - seems to me to be a bug.
-
Look in your system log for the time period when your WAN IP changes. Do you see a line about the packages getting a restart command (you will see a message along the lines of "…restarting packages..."). Just after that entry do you see any Snort messages logged? You should see a series of messages about Snort rebuilding rules on the interfaces (the same log messages you see when you manually stop and restart Snort).
Is your WAN IP an IPv4 or an IPv6 address, and how is it provisioned (DHCP, PPPoE, etc.)?
Bill
-
I do see a message about packages being restarted, but I don't see any messages from Snort.
My IP is IPv4, provisioned via PPPoE (VDSL2+ modem in Bridge mode).
-
I do see a message about packages being restarted, but I don't see any messages from Snort.
My IP is IPv4, provisioned via PPPoE (VDSL2+ modem in Bridge mode).
A PPPoE interface in pfSense (actually in FreeBSD) is "special" in some way if I recall. I know way back when I used PPPoE with DSL something changed between 1.2.x versions of pfSense and the 2.0.x versions. The way a PPPoE interface is treated may be at issue here, but I am not familiar enough with FreeBSD network internals to say for sure. Maybe another user will chime in with some advice.
If you restart Snort manually after a WAN IP change, does that fix it?
Bill
-
If you restart Snort manually after a WAN IP change, does that fix it?
Yep, everything goes smoothly until the IP changes again.
-
Yep, everything goes smoothly until the IP changes again.
Hmmm…let me examine the shell script code a little closer. Some logic was added a while back to try and prevent starting multiple copies of Snort upon a reboot. Perhaps that logic is too aggressive and winds up sometimes ignoring legitimate restart commands.
Bill
-
Same here!
I'm currently having some troubles to keep my WAN_PPPoE on.
I'm using OpenDNS and it seems every time there's a look up, snort probe on WAN get triggered and block the WAN Ip.
This cause PPPoE disconnection and reload.
I of course put everything on pass list but this just mitigate the issue as long as the PPPoE keep the same IP that snort whitelisted. If WAN Ip changes, then snort won't skip the block and causes the connection to drop.
I'm looking around this problem since awhile, so far I tried to:1. Replace NIC card:
2. Revert NIC order (wan with lan);
3. Pass list all internal network + check all flagsSo far no luck!
Here a quick log report during issue:
GATEWAY
apinger: alarm canceled (config reload): WAN_PPPOE(8.8.8.8) *** WAN_PPPOEdown ***
Mar 9 23:40:38 apinger: SIGHUP received, reloading configuration.
Mar 9 23:40:30 apinger: Could not bind socket on address(x.x.x.x) for monitoring address 8.8.8.8(WAN_PPPOE) with error Can't assign requested address
Mar 9 23:40:20 apinger: Could not bind socket on address(x.x.x.x) for monitoring address 8.8.8.8(WAN_PPPOE) with error Can't assign requested address
Mar 9 23:40:10 apinger: Could not bind socket on address(x.x.x.x) for monitoring address 8.8.8.8(WAN_PPPOE) with error Can't assign requested address
Mar 9 23:34:39 apinger: ALARM: WAN_PPPOE(x.x.x.x) *** WAN_PPPOEdown ***PPP
ppp: [wan] IPCP: LayerDown
Mar 9 23:40:05 ppp: [wan] IPCP: SendTerminateReq #16
Mar 9 23:40:05 ppp: [wan] IPCP: state change Opened –> Closing
Mar 9 23:40:05 ppp: [wan] IPCP: Close event
Mar 9 23:40:05 ppp: [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps
Mar 9 23:40:05 ppp: [wan_link0] Link: Leave bundle "wan"
Mar 9 23:40:05 ppp: [wan_link0] LCP: state change Opened –> Stopping
Mar 9 23:40:05 ppp: [wan_link0] LCP: peer not responding to echo requests
Mar 9 23:40:05 ppp: [wan_link0] LCP: no reply to 5 echo request(s)
Mar 9 23:39:55 ppp: [wan_link0] LCP: no reply to 4 echo request(s)
Mar 9 23:39:45 ppp: [wan_link0] LCP: no reply to 3 echo request(s)
Mar 9 23:39:35 ppp: [wan_link0] LCP: no reply to 2 echo request(s)
Mar 9 23:39:25 ppp: [wan_link0] LCP: no reply to 1 echo request(s)
Mar 9 23:35:15 ppp: [wan_link0] LCP: no reply to 4 echo request(s)
Mar 9 23:35:04 ppp: [wan_link0] LCP: no reply to 3 echo request(s)
Mar 9 23:34:54 ppp: [wan_link0] LCP: no reply to 2 echo request(s)
Mar 9 23:34:44 ppp: [wan_link0] LCP: no reply to 1 echo request(s)
Mar 9 23:30:34 ppp: [wan_link0] LCP: no reply to 4 echo request(s)
Mar 9 23:30:24 ppp: [wan_link0] LCP: no reply to 3 echo request(s)
Mar 9 23:30:14 ppp: [wan_link0] LCP: no reply to 2 echo request(s)
Mar 9 23:30:04 ppp: [wan_link0] LCP: no reply to 1 echo request(s)
Mar 9 23:25:43 ppp: [wan_link0] LCP: no reply to 4 echo request(s)
Mar 9 23:25:33 ppp: [wan_link0] LCP: no reply to 3 echo request(s)
Mar 9 23:25:23 ppp: [wan_link0] LCP: no reply to 2 echo request(s)
Mar 9 23:25:13 ppp: [wan_link0] LCP: no reply to 1 echo request(s)
Mar 9 23:21:13 ppp: [wan] IFACE: Rename interface ng0 to pppoe0 -
I'm still having the same problem.
This was not a problem a couple of years ago, it must have been introduced after the 2.0 update.
-
I'm still having the same problem.
This was not a problem a couple of years ago, it must have been introduced after the 2.0 update.
I am looking at some options to help cope with frequently changing dynamic WAN IPs (like PPPoE) in both Snort and Suricata.
Bill
-
Hi.
I did some investigations on the root cause of Snort failing e.g. for PPPoE connections with a provider-side forced DHCP renew.
The problem is that /etc/rc.start_packages (invoked indirectly by /etc/rc.newwanip) does refresh the Snort configuration file (/usr/pbi/snort-<platform>/etc/snort/snort_<…>/snort.conf), however, Snort does not read it immediately as it does in case of modifications via the GUI).
In order to reload the configuration, we need to send SIGHUP to the running Snort instance (the Snort executable that comes with pfSense is capable of reloading without restarting, see also /usr/local/pkg/snort/snort.inc (function snort_reload_config)).
A workaround without changing the PHP files would be to introduce an additional shell script placed in /usr/local/etc/rc.d.
snort_pids="$(pgrep snort | xargs)" if [ ! -z $snort_pids ]; then /usr/bin/logger -p daemon.info -i -t SnortReload "Snort RELOAD for all interfaces... (${snort_pids})" kill -HUP $snort_pids fi barnyard2_pids="$(pgrep barnyard2 | xargs)" if [ ! -z $barnyard2_pids ]; then /usr/bin/logger -p daemon.info -i -t SnortReload "Barnyard2 RELOAD for all interfaces... (${barnyard2_pids})" kill -HUP $barnyard2_pids fiThis script reloads all running Snort an Barnyard instances. Note: this is not the optimal solution if running Snort for multiple interfaces, but only one configuration changed.
Tested on pfSense 2.2.4-RELEASE (amd64), Snort 3.2.8.</platform>