Outgoing traffic being blocked to strange dns servers



  • Getting thousands of firewall logs with the rule "Block snort2c hosts (1000000119)" which seem to be blocking traffic from the firewall to strange remote hosts on port 53. We have another identical pfsense firewall, and we don't see any alerts like these. How can this happen?
    Capture1_SI.jpg
    Capture3.png



  • Presumably one of your internal clients is trying to access public DNS.



  • I don't think so. All the clients on that firewall use the firewall itself as their dns nameserver.



  • I see, so possibly it's the digi-ghost who is requesting the servers found in the log. 🙄

    So add a firewall rule to your internal networks, maybe a floating rule for multiple interfaces at once, and block TCP/UDP port 53 except to the firewall, enable logging and you will get the culprit on a silver table in the log.



  • @stepariley said in Outgoing traffic being blocked to strange dns servers:

    strange remote hosts on port 53

    There is another recent thread (right here - this part of the forum) that states that pfSense itself doesn't care about the forwarding to 8.8.8.8 etc and keeps resolves the old fashioned way : that is : goto a root for a tld, goto a tld for the domain and then the final real domain name server of a domain for the A, TXT, MX, AAAA or whatever.
    A bug report was opened recently.


  • LAYER 8 Global Moderator

    that IP is a cloudflare IP

    cf-198-41-223-131.cloudflare.com

    I don't think pfsense would do would be talking to that for its own stuff, but it could be some package using loopback (unbound) directly that is resolving.

    Out of the box pfsense would just check if there is an update, and pull listing of packages, etc.

    But if you have say pfblocker trying to download lists of IPs and such, then it could be asking unbound directly, which would resolve where ever that domain is..

    Why is snort blocking it? What does the snort log say? Snort likes to block specific tlds that it feels are not legit.. or used for bad stuff.



  • Try a NAT rule. Will force all LAN DNS to pfSense.
    5d14a150-9467-4805-9116-cf1cdce906b6-image.png



  • 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.



  • Also, I suspected pfBlocker and such, but like I said, I have the same configuration on a different firewall and I don't see it. I only have zimbra on the firewall that's giving me a problem.



  • @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.


  • LAYER 8 Global Moderator

    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.


  • LAYER 8 Global Moderator

    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.


  • LAYER 8 Global Moderator

    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.


  • LAYER 8 Global Moderator

    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. 🤠


  • LAYER 8 Global Moderator

    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.

    😊


  • LAYER 8 Global Moderator

    @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-44076

    Snort 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.


  • LAYER 8 Global Moderator

    @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 pf table. 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 special pf table 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.


  • LAYER 8 Global Moderator

    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.
    blockedbutnotnoticed.png

    Would never notice this, since stuff is working.. But the whatever it is still banging its head against the wall trying to resolve that.


Log in to reply