Snort Blocking DNS on LAN side
-
Using unbound in caching mode.
Thought i had a setup problem as everything could resolve from the pfsense box, but after 5 - 10min from boot up, devices on the LAN and specifically android could not resolve. From the linux box, i could resolve cnn.com for example but google.com amongst many others would stop working.
Set snort on the WAN and VPN interfaces using the "Security" profile. was receiving lots of attempted cache poising warnings.
It seems it is blocking all the android devices on wifi.
I noticed they are all flooding the network with UDP 4886. Seems to be firefox for android, so i have removed this.My problem is, i still can't figure where to see in DBNL or Snort that these devices have been blocked.
I've had to turn snort off, to allow me to continue working. How to resolve?
-
Using the Security Policy for the IPS Policy setting is NOT recommended. As you see, it can result in an overly restrictive ruleset that yields lots of false positives. I never recommend a policy more stringent than the Balanced Policy for most users. And in fact, the Connectivity Policy is more than adequate for the majority of folks.
So your issue is that you have too many rules enabled that are likely giving false positives in your network environment. If you insist on keeping the current policy setting, you will have to identify all of the triggering rules giving you unwanted blocks and then either disable those rules or create Suppression List entries for them for the impacted host IP addresses.
Contrary to what lots of new IDS/IPS admin users seem to think, jumping immediately to the maximum secure position is not the best thing to do. Start out with just using the alert-only mode with no blocking. See what kinds of alerts you are getting on your network. Investigate them and determine if they are false positives. Most of the time they likely are. Adjust your rules based on your findings and keep analzying. After say a month of watching alerts (maybe just a week if you are protecting only a home network), then you can turn on blocking. By then you have hopefully identified and mitigated the majority of the false positive rules. However, that does not mean another false positive block may not show up later as either the rule vendors update their detection rules or web sites change their behavior. Either action can trigger false positives.
-
@bmeeks appreciate your comments, but the big issue for me is, i can't see where the block is. What i know factually is,
- windows & linux wifi clients are working fine
- android devices all had firefox and all were flooding the network with UDP4886
- after some period of time, android devices show wifi connected but no internet available
- all user certificates have been removed from android devices
- IP Tools returns DNS response - error timeout (cable and non-android continue to work)
I would say there was probably a good reason these devices are blocked, and i would rather find out;
- where are they being blocked pfBlocker or Snort (i believe snort because i run 2 days without and no probs)
- which rule was triggered and then i can investigate why.
-
UDP Port 4886 is Firefox for Android's wifi tickle timer used to improve RTT (round trip time). It will send zero length UDP packet to the default gateway's IP address on port 4886 at a rate of 60 times per second (every 400ms).
See: https://bugzilla.mozilla.org/show_bug.cgi?id=888268 -
@gwaitsi said in Snort Blocking DNS on LAN side:
@bmeeks appreciate your comments, but the big issue for me is, i can't see where the block is. What i know factually is,
- windows & linux wifi clients are working fine
- android devices all had firefox and all were flooding the network with UDP4886
- after some period of time, android devices show wifi connected but no internet available
- all user certificates have been removed from android devices
- IP Tools returns DNS response - error timeout (cable and non-android continue to work)
I would say there was probably a good reason these devices are blocked, and i would rather find out;
- where are they being blocked pfBlocker or Snort (i believe snort because i run 2 days without and no probs)
- which rule was triggered and then i can investigate why.
All Snort blocks will show up in two places: (1) on the ALERTS tab and (2) on the BLOCKED tab. Both tabs will show the IP addresses of blocked hosts. I suggest using the ALERTS tab since you can click some of the columns on that tab and sort the results to make finding things easier. You can also filter using several parameters. The filter options become visible when you click the area just above the alerts listing.
But to find out if Snort blocked a given device, you will need to know what IP address that device is using. So armed with the device's IP address, scan the Snort ALERTS tab to see if that IP is showing up under either the SOURCE IP or DESTINATION IP columns. If so, then a red X beside the IP indicates that IP is currently blocked. Looking at the other data in the data row will tell you which rule (GID:SID) triggered. You can then either disable that rule or suppress it for that IP address. Depending on which particular rules you have enabled for Snort, it could be one is triggering on a false positive from some traffic pattern from the Android devices. Lots of stuff clients do is not malicious, but it may not be officially sanctioned by all of the RFCs out there. Thus IDS/IPS rules may trigger on the traffic. For example, using the info provided in the previous post from user @awebster, some rule may consider a UDP packet with zero length as "invalid" and thus trigger on it when in actual fact, in some circumstances, the packet is legit.
-
@awebster i removed firefox, but my android devices are still being blocked.
chrome and duckduckgo give me net:ERR_NAME_NOT_RESOLVED but i also notice,
i can ping devices on the same subnet from android no problem, but cannot ping the gateway/pfsense.So it is blocked on pfsense, but i can't find it in any log where the block is. i.e. pfblocker or snort.
i do notice a lot of DNSL rejections for android/google services in the log
-
@gwaitsi said in Snort Blocking DNS on LAN side:
So it is blocked on pfsense, but i can't find it in any log where the block is. i.e. pfblocker or snort.
i do notice a lot of DNSL rejections for android/google services in the log
Ding...Ding...Ding! There is most likely the source of your problem: DNSBL.
So pfBlockerNG is indirectly the cause of your blocks through its inclusion of the DNSBL setup. I would say this is the only other source of possible blocking if you do not see the blocked IPs on the ALERTS or BLOCKED tabs of Snort. Snort will log in the GUI everything it blocks. If you do not see the device's IP address listed on the BLOCKED tab, then Snort is not blocking anything for that device.
-
@bmeeks yes, confirmed it is DNSBL causing the blocks to things line express.co.uk but even after turning that off, the android clients are still blocked
-
@gwaitsi said in Snort Blocking DNS on LAN side:
@bmeeks yes, confirmed it is DNSBL causing the blocks to things line express.co.uk but even after turning that off, the android clients are still blocked
Perhaps you have not yet identified all of the issues? You might want to try restarting the firewall to make sure things are cleared out and start fresh.
I have not used the pfBlockerNG package nor the DNSBL option, so I'm not sure how it is configured in terms of running as a service. Maybe you don't actually have everything associated with it disabled yet???
-
@bmeeks you are correct.
- i have disabled both snort and dnsbl.
- strip everything down to minimum.
- created a pass all rule for a couple of android phones.
- turned off the ntp/dns forward rules. rebooted pfsense and all switches.
- have both linux and windows machines working on the wifi upstairs.
- reset the network settings on the phones
- put in static IPs and tried internal and google DNS.
Bloody phones work on the wifi downstairs by not upstairs.
Stuffed if i can workout why they are not working.
even IP Tools, can't ping the gateway or anything on the subnet -
@gwaitsi said in Snort Blocking DNS on LAN side:
@bmeeks you are correct.
- i have disabled both snort and dnsbl.
- strip everything down to minimum.
- created a pass all rule for a couple of android phones.
- turned off the ntp/dns forward rules. rebooted pfsense and all switches.
- have both linux and windows machines working on the wifi upstairs.
- reset the network settings on the phones
- put in static IPs and tried internal and google DNS.
Bloody phones work on the wifi downstairs by not upstairs.
Stuffed if i can workout why they are not working.
even IP Tools, can't ping the gateway or anything on the subnetNot knowing all the details of your setup, but my initial suspicion would be you have sort of fundamental network configuration issue.
-
Do you have multiple WiFi access points?
-
Are the WiFi access points truly access points or are they perhaps actually wireless routers?
-
Do you have any VLANs defined?
-
Setting up pfSense with Snort and pfBlockerNG should never interfere with any LAN devices unless configured to do that; so, there has to be a misconfiguration somewhere.
Or, check the Google IP address for your region (ping google.com) then add to a passlist. Sometimes if Firefox doesn't receive the correct certificate could lead to net: ERR_NAME_NOT_RESOLVED. Also, note that one can block lots of Google services with an error such as this: network >172.0.0.0/8 or 172.0.0.0/16
-
@NollipfSense i'm an idiot. I seem to have accidentally ticked "Static ARP" on one of the DHCP LAN segments.
But interestingly, it highlights a bug with pfsense.While it seems to have successfully blocked all the android phones, it did not block a netgear switch (aside from the NTP) nor did it block a couple of windows machines. My linux box had a static IP assigned, which is why it was working.
-
@gwaitsi Glad you figured it out however, don't knock yourself like that...we all make misconfiguration...that's how we learn. Congrats!
