Outgoing traffic being blocked to strange dns servers
-
@stepariley said in Outgoing traffic being blocked to strange dns servers:
So, I tried blocking requests on lan for port 53 that weren't going to the firewall directly, and all of a sudden my zimbra server started complaining. Not sure what it's doing, since it's resolv.conf file is the same as every other client, i.e. use the firewall for dns. It starts to fail to respond to smtp requests of all things.
If you cannot change the DNS settings on the host, however, by adding the NAT suggested by @provels you can direct its request to pfSense without taking a notice.
-
I just added the NAT rule suggested. Checking the log, I still see the same snort messages. So, I'm not sure what this means.
-
Also, putting some filtering in place, I don't see any logs showing requests coming from LAN that don't go to the LAN address of the firewall or the 8.8.8.8 server.
-
You make not mention of actually setting up forwarding in unbound or using dnsmasq.
You do understand that out of the box unbound is a resolver right? Doesn't matter what you put in the dns settings under general.. Unless you told unbound to forward.
-
Where do you configure that? I don't know anything about unbound.
-
unbound is the default dns for pfsense, out of the box. It resolves, it doesn't forward by default.. So you have no need to put anything in dns for general, or even get dns from isp.
Its under services menu, dns resolver.
-
Ok, so I looked in the resolver, and I saw that my Enable Forwarding was turned off. I turned it on, and I haven't seen any snort warnings in the last 10 minutes since then. So, maybe this is snort being overly aggressive on outgoing dns queries? My other firewall was the same, and I never got any snort errors.
-
So you would have to look in the snort log for why something was specific blocked. But I do know it can be very aggressive for specific tlds, like biz as example.. and some of the other ones that are cheap and not really used for normal major business..
I do see with that specific IP a wuai.biz related to it - atleast at one point in time, as well as ns4.cloudflare.net etc.
-
Yeah, I will look at the snort logs for that, but I think for now, I'm happy with the firewall not going out to the root dns servers. Just makes me nervous to see queries like that, especially when they are going outside the country.
-
And where do you think they go when you forward to 8.8.8.8 ;)
That is an anycast IP, you have no idea where the actual server that answers you might be..
-
Yeah, I realize that, but at that point, I feel it's someone else's problem.
-
Huh, Im not talking about where they go to resolve.. You have no idea where the actual servers are that your asking.. While you hope they are close to you - its an anycast IP.. It could be anywhere on the planet, in your country or not, etc.
Not sure why should be concerned with directly talking to the authoritative NS you asked for.. Its not like your resolving for anything your own devices didn't ask to resolve, etc.
But sure if you feel better handing over everything you look for to 1 company.. Then sure do that.
-
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.
