A funny thing about IDS/IPS.... /DNS related
-
When you have blocked DNS from anything other than the FW itself and you run DNS rules in Suricata....
Its just a matter of time before the FW itself cannot resolve DNS and everything stops.
-
@cool_corona Are you running pfBlocker and Suricata DNS rules on the WAN interface.
I’ve seen these issues when pfBlocker tries to resolve suspect hosts when they hit the WAN interface.
-
@nogbadthebad Pfblocker and Suricata on LAN
-
The DNS server IP used by the firewall is automatically added to the default Pass List, so it should not get blocked. This would change only if you customized your own Pass List and did not include the firewall's DNS server IP in the custom list.
The automatic Pass List function pulls the DNS IP for the firewall from a pfSense system call. So I'm not sure I understand how what you are describing can happen, especially in a default installation.
Are you sure the actual DNS server IP is blocked? Do you see its IP listed in the BLOCKS tab?
-
@bmeeks Hi Bill
No no IP listed but I see blocks to domains using the built in DNS.
But no blocks systemwide for the localhost DNS
-
@cool_corona said in A funny thing about IDS/IPS.... /DNS related:
@bmeeks Hi Bill
No no IP listed but I see blocks to domains using the built in DNS.
But no blocks systemwide for the localhost DNS
Then with no DNS IP listed on the BLOCKS tab, Suricata can't be the cause of the DNS failure (if using Legacy Blocking Mode). Are you perhaps using Inline IPS Mode? If so, are there any DROP alerts listed on the ALERTS tab for the DNS server IP? Again, if not, then Suricata is not the issue.
-
Running Legacy Mode.
A peculiar oberservation. Some of the blocks are related to AAA Adult sites and the servers blocked is Root DNS servers.
I bet that running for sometime, the entire Root DNS ecosystem is blocked one by one until Unbound cant make any lookups.
Blocks are never removed.
-
@cool_corona said in A funny thing about IDS/IPS.... /DNS related:
Running Legacy Mode.
A peculiar oberservation. Some of the blocks are related to AAA Adult sites and the servers blocked is Root DNS servers.
I bet that running for sometime, the entire Root DNS ecosystem is blocked one by one until Unbound cant make any lookups.
Blocks are never removed.
What you are describing appears to have zero to do with IDS/IPS. Why did you put IDS/IPS in the title?
If nothing is showing in the ALERTS or BLOCKS tabs for the blocked IP addresses, then the IDS/IPS is not responsible for the blocking. You likely have something else going on.
And I don't understand the purpose of the screenshot of the IDS INTERFACES tab in your last post. How is that relevant at all to the discussion? Not yelling at you, but just confused how it relates.
-
@bmeeks Its Suricata related since when I clear the blocks, then all is fine.
I usually happens overnight. I cant find anything related to DNS in the logs
-
Over time I bet I will see the root servers blocked that unbound uses to resolve queries.
I have manually added 5 root servers to the DNS to see of that changes behaviour.
-
@cool_corona and your WAN by the looks of the screenshot.
Disable ET DNS if you don’t host a DNS server, what’s happening is hosts with a .top, .su, .to etc ... are hitting the WAN interface, pfBlocker is then doing a lookup of the ip address for reporting, then its blocking the servers resolver is trying to get the fqdn from.
I had a the same type issue and after looking at a packet capture from snort I set up a snort rule to capture dns requests to ns.hetsptt.net.cn, guess what not a single host on my LAN did a request.
# pcap udp any any -> any 53 ( msg:"ns.hetsptt.net.cn"; flow:to_server; byte_test:1,!&,0xF8,2; \ # content: "|02|ns|07|hetsptt|03|net|02|cn|00|"; nocase; sid:20000010; rev:001;classtype:string-detect;) -
@nogbadthebad Done and thanks :)
-
@cool_corona said in A funny thing about IDS/IPS.... /DNS related:
@nogbadthebad Done and thanks :)
Ah, I think I understand now. You were running the ET DNS rules on your WAN. Your screen shot earlier showed blocking disabled on the WAN, but apparently you changed it from blocking to "not blocking", but you were having the trouble when it was blocking ??
pfBlockerNG will do DNS lookups on things in its logs in order to show domain names. So that activity is going to show up as a "host" performing a lookup against malware domains. That "host" is the firewall itself in the persona of
unbound. It's not really malicious traffic. The host is not looking up the domain in order to communicate or download more malware. It is simply checking for the name and/or associated IP. That's not malicious. But Suricata's rules don't know that and don't care.So two things you should do. First, only run the IDS/IPS on your internal LAN interfaces (LAN, DMZ if you have one, WLAN, etc.). Don't run the IDS/IPS on the WAN. Second, you never need all the rules enabled. You certainly don't need the server rules if you do not have publicly exposed servers on your network. So don't run web server rules, mail server rules, DNS server rules, etc., unless you have those servers on your networks exposed to the Internet via port forwards.
@NogBadTheBad gave you good advice about those ET DNS rules. They need to be used only when you are able to use Inline IPS Mode and those rules can then more selectively police traffic with packet drops instead of hard blocks of all traffic for a given IP. The Legacy Blocking Mode is a very large hammer. Once it puts an IP in the firewall table, all subsequent traffic for that IP is blocked. With Inline IPS Mode, individual "bad" packets are dropped while other non-malicious traffic is allowed to pass. Thus a much more fine-grained hammer.
-
@bmeeks Yup it had me baffled for ages as I couldn't see any lookups from my LAN interface to the offending FQDNS.
Andy
1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22
-
@bmeeks Thanks man :)
Yes I have pbulic facing servers ( a lot ) but no DNS.
So disabled the rule. And yes I have tried a lot of things changing the blocking mode to disable (alert only) on different interfaces to trace the culprit.
Regaring Inline mode, I run Vmxnet3 interfaces so inline mode is not possible with netmap.
-
@nogbadthebad Exactly my issue.
-
@nogbadthebad said in A funny thing about IDS/IPS.... /DNS related:
@bmeeks Yup it had me baffled for ages as I couldn't see any lookups from my LAN interface to the offending FQDNS.
Yes, the firewall itself sources the connection for the DNS lookup, and that traffic will exit the WAN on the way to either the DNS root servers or whatever DNS forwarder might be configured. So the IDS rules on the WAN see the traffic and alert. Since it's on the WAN, and the IDS sits beyond the firewall, the IDS sees your firewall's public WAN IP as the "source". The natural inclination is to assume the traffic originated on your LAN, but it actually did not.
