Outgoing traffic being blocked to strange dns servers
-
My main concern is that snort trusts it. Before, all my dns queries were being blocked by snort. Maybe I'll spend time figuring out why that is at some point, but I have other things to do.
-
@stepariley said in Outgoing traffic being blocked to strange dns servers:
My main concern is that snort trusts it.
Not sure what you mean by this statement?
Before, all my dns queries were being blocked by snort.
This statement says that you have Snort misconfigured and are most likely running it in Blocked Mode. Until you get it tuned to your system, YOU SHOULD NOT run it in Blocked mode. Also you should not enable ALL the rules in Snort until you learn what each rules is looking for other wise you will get all kinds of false positives blocks with it. It can take several days, weeks or even months to get it tuned to your system depending on what your doing on your network.
-
No, I'm not.
-
@stepariley said in Outgoing traffic being blocked to strange dns servers:
My main concern is that snort trusts it.
Yeah, lol, Snort trust 8.8.8.8. .....
@stepariley said in Outgoing traffic being blocked to strange dns servers:
Before, all my dns queries were being blocked by snort
Snort will trust the main 13 Internet Root servers., as without them, you might as well cut the connection and go live in the forest. Snort will probably 'trust'"all tld servers, like com net org etc.
But Snort might kick in when the resolver hits the final stage : the third level is reached : the domain name servers. because they are listed as they give the IP to sites that are listed - and you want them to visit these sites.
8.8.8.8 will hide all this for you, as it does the job for you, it a resolver just like Unbound (and data mine while doing so - so they can give you the 'right' answer for you ^^).So, again :
@stepariley said in Outgoing traffic being blocked to strange dns servers:
Before, all my dns queries were being blocked by snort
You are trying to visit sites that are listed in Snort.
Up to you to decide :
The lists are wrong - adapt them,
Or,
Stop going there.
-
@stepariley said in Outgoing traffic being blocked to strange dns servers:
all my dns queries were being blocked by snort.
You sure about that? Was it blocking queries to xyz sure, as I said snort has rules to block what it considers bad domains. Here is thread from this back in 2018
https://forum.netgate.com/topic/133529/snort-blocking-dns-servers
Again you really need to look to snort on why it was blocking, and what signature..
example
https://www.snort.org/rule_docs/1-44076Snort rules need to be adjusted before you allow block mode, or yup your going to prob break way more stuff than any added security it could bring.
-
You guys seem to be getting worked up about this. Nothing is broken. Snort wasn't really "blocking" the queries. We still had normal dns functioning. It was just adding thousands of alerts per day in the logs, which I don't want. As I said before, I will look into what was causing the alerts, but even then, I don't know what to do about them other than turn them off in those cases where it's a false positive.
-
@stepariley said in Outgoing traffic being blocked to strange dns servers:
You guys seem to be getting worked up about this. Nothing is broken. Snort wasn't really "blocking" the queries. We still had normal dns functioning. It was just adding thousands of alerts per day in the logs, which I don't want. As I said before, I will look into what was causing the alerts, but even then, I don't know what to do about them other than turn them off in those cases where it's a false positive.
Snort and the Emerging Threats team both produce rules that flag DNS lookups for particular top-level domains. They classify these as "indicator/compromise" rules -- meaning that at some point those particular top-level domains had a higher than normal incidence of hosts either serving up malware or hosting CNC software for various types of malware BOT armies.
The problem with this type of approach to classifying something as potentially malicious is that a lot of innocent things are tarred and feathered as well by rules like this. The rules are basically dumb in that they simply look for resolution attempts for a top-level domain (TLD). They do not look at the content of traffic flowing from that domain to see if the actual traffic is malicious. It's basically "guilt by association" with these types of rules. It is literally as simple as "I've decided the *.info domain is bad, thus any DNS lookup against any .info domain I will flag as malicious and an indicator of host compromise." That's really a big hammer approach to what should be a much more nuanced solution.
So you have something on your network that is asking for the IP of some TLD that a Snort or Emerging Threats rule writer has decided is an indicator of compromise. Is the host really infected with malware, or is it just looking for something else in that TLD? Only way to know is to examine the packets flowing and to closely examine the software on the host itself. Odds are the lookups are completely benign. If that is the case, I would either disable the rule entirely, or at least suppress it for that internal host IP. Either method will remove the alerts from your logs.
-
Yeah, I think you are right. I'm suspecting my zimbra server. We get a lot of spam, and even though most of it is suppressed, maybe it is still causing dns lookups to strange domains. I'll try to take a closer look at that.
-
@stepariley said in Outgoing traffic being blocked to strange dns servers:
Yeah, I think you are right. I'm suspecting my zimbra server. We get a lot of spam, and even though most of it is suppressed, maybe it is still causing dns lookups to strange domains. I'll try to take a closer look at that.
Yes, a mail server trying to do some fundamental "sender" verification could easily trigger such overly broad rules (the overly broad comment is my opinion of the Snort rule itself, not of your deployment). The mail server will likely do some DNS lookups to try and verify the sending domain. So in that instance I would judge the alerts as benign and either disable or suppress the rule. Disable removes it from RAM and it will never trigger, while suppressing it can be done on source and/or destination IP basis and thus block the alert for some hosts but allow it for others.
-
@stepariley said in Outgoing traffic being blocked to strange dns servers:
Snort wasn't really "blocking" the queries.
Your firewall log you showed, not your snort log was clearly blocked. Blocking something that you don't really want, ie something phoning home, checking on something else that is not loading a website might not be noticed by you.
And when something can not resolve, quite often whatever was trying to find it - tries even harder and harder.. And yes can send 1000's of queries looking for something that is not resolving..
-
One last important point. That firewall log snippet you posted shows that at some point Snort put the IP of that DNS host (most likely the NS for that particular TLD) into the snort2c
pftable. So any additional attempts to contact that host will result in more log entries, even after you disable the Snort rule. That's because Snort does not really block things itself. It identifies something that matches a rule and triggers an alert, then it makes a system call to pfSense to add the offending IP to that specialpftable called snort2c. After that, the firewall is responsible for actually blocking the traffic.So if you decide to disable or suppress that rule, you will still need to manually clear the IP of that host from the snort2c table before blocks and the log messages will cease. You clear blocks on the BLOCKED tab or by clearing the snort2c table manually under DIAGNOSTICS > TABLES.
-
Here is an example of stuff not resolving, but not noticing because I actually want those blocked and its stuff devices, software is doing that shows some ad or whatever that is blocked.
Just in the last 24 hours.
Would never notice this, since stuff is working.. But the whatever it is still banging its head against the wall trying to resolve that.
