Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    SAD DNS and unbound question

    Scheduled Pinned Locked Moved DHCP and DNS
    15 Posts 4 Posters 1.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jsbsmd
      last edited by

      I am no DNS expert and would like to know if we need to worry about this type of attack that is re-surging

      re:
      https://www.zdnet.com/article/dns-cache-poisoning-poised-for-a-comeback-sad-dns/

      I am using unbound with dnssec/853 and pointing to 1.1.1.2 and 9.9.9.9

      network interfaces are set to ALL as well as outgoing network interfaces

      B 1 Reply Last reply Reply Quote 0
      • johnpozJ
        johnpoz LAYER 8 Global Moderator
        last edited by johnpoz

        @jsbsmd said in SAD DNS and unbound question:

        I am using unbound with dnssec/853 and pointing to 1.1.1.2 and 9.9.9.9

        There is no point to setting dnssec when you forward - the place you forward to does dnssec or not.. No reason for you to ask for this info. It does nothing but cause extra queries.

        When you forward you trust what they hand back to you - if its bad its bad.. Since they are doing the resolving, they are the ones that need to protect against such attacks.

        Also forwarding to 2 different services that do different filtering.. Is problematic at best.. If you query service A and it does not filter, then its cached to not be filtered.. But if you had queried B and it was filtered then it would be cached filtered. But you have no idea which one was used to place the item in your cache.

        If your going to use a service - pick one, and use that 1.. If one of the major providers goes down the whole internet is pretty much screwed... You pointing to some other service isn't going to magically keep you up and running.. If it was such a problem, it takes all of 2 seconds to switch what dns you forward too..

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.8, 24.11

        B 1 Reply Last reply Reply Quote 1
        • J
          jsbsmd
          last edited by

          I have disabled dnssec and am pointing only to 1.1.1.2. Thanks.

          My initial question though was do we need to worry about unbound on pfsense and SAD DNS.

          re:
          This new flaw affects operating systems Linux (kernel 3.18-5.10), Windows Server 2019 (version 1809) and newer, macOS 10.15 and newer, and FreeBSD 12.1.0 and newer.

          thanks.

          1 Reply Last reply Reply Quote 0
          • johnpozJ
            johnpoz LAYER 8 Global Moderator
            last edited by johnpoz

            Well did you go to the test site?

            Example I just did and

            test.png

            Look at how the attack works.. Pfsense out of the box does not answer a closed port with an ICMP message that the port is closed... Pretty much no firewall would do this - its bad setup.. An OS might do that.. Is your client directly exposed to the internet?

            But again - since you forward.. Doesn't matter what your system does or doesn't do correctly or incorrectly.. Your going to trust whatever the F where you forward to sends back to you - be it right wrong, doesn't matter.. If they have poison in their cache - then they hand you poison, and you drink it like its grape flavored Kool-Aid and Jim Jones handed it to you himself..

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 24.11 | Lab VMs 2.8, 24.11

            1 Reply Last reply Reply Quote 0
            • bingo600B
              bingo600
              last edited by

              I'm seeing the same (surprise ...)

              7e951e8b-ae9e-476b-9ae5-815819fffaed-image.png

              I'm using a setup where my pfSense (Unbound) is forwarding queries to two linux bind9 servers i have locally , and those queries the "A-root servers".

              But as @johnpoz says - it's prob not my local system that is vulnerable, they would need access to one of my local machines to inject stuff into my local caches.

              But i will trust any "sh.." i get returned from "foreign" authorotive servers.

              Btw: I just got kernel updates for my desktop linux ...
              Could be the linux mitigation : icmp: randomize the global rate limiter
              https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b38e7819cae946e2edf869e604af1e65a5d241c5

              /Bingo

              If you find my answer useful - Please give the post a šŸ‘ - "thumbs up"

              pfSense+ 23.05.1 (ZFS)

              QOTOM-Q355G4 Quad Lan.
              CPUĀ  : Core i5 5250U, Ram : 8GB Kingston DDR3LV 1600
              LANĀ  : 4 x Intel 211, DiskĀ  : 240G SAMSUNG MZ7L3240HCHQ SSD

              1 Reply Last reply Reply Quote 0
              • J
                jsbsmd
                last edited by jsbsmd

                here is my results. btw i'm running windows 10 and my pfsense is now pointing to 9.9.9.9

                Your DNS server IP is 108.162
                It seems your DNS server is running Linux > 3.18
                Since it is running the vulnerable version of OS that has not been patched yet, your DNS server is vulnerable.
                The test is conducted on 2020-11-16 21:18:23.196109952
                Disclaimer: This test is not 100% accurate and is for test purposes only.

                1 Reply Last reply Reply Quote 0
                • johnpozJ
                  johnpoz LAYER 8 Global Moderator
                  last edited by johnpoz

                  @jsbsmd said in SAD DNS and unbound question:

                  It seems your DNS server is running Linux > 3.18

                  So that is what the resolver that 9.9.9.9 must be using..

                  my pfsense is now pointing to 9.9.9.9

                  My question is how do they know what version of linux it is - other than > than 3.18 ;) I could see if it said < then X, while less than X has not been patched.. But with a > how do they know what its running? ;)

                  I would guess most likely they are running something custom for sure and not just out of the box linux ;)

                  Again - let me stress.. You are forwarding.. Whatever they hand back to you is going to be gospel.. Poison or not.. Kool-Aid is tasty ;)

                  Here is some more info you can read on the attack..
                  https://blog.cloudflare.com/sad-dns-explained/

                  Keep in mind this point.. "If you are an operator of an DNS forwarder or recursive DNS resolver, you should consider taking the following steps to protect yourself from this attack:"

                  The key here if your running a forwarder, which you are - is that were you forward too is protecting against such attacks.. All forwarders at some point have to talk to a resolver - dns doesn't work without resolvers.. Your just trusting quad9 do the resolving part for you - they could be forwarding to another forwarder, which forwards to another.. Don't really know how they have it setup, but at some point there has to be a resolver. That resolver is where the poison could enter the cache, and be handed down to any downstream forwarders asking it for the dns records.

                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                  If you get confused: Listen to the Music Play
                  Please don't Chat/PM me for help, unless mod related
                  SG-4860 24.11 | Lab VMs 2.8, 24.11

                  1 Reply Last reply Reply Quote 0
                  • J
                    jsbsmd
                    last edited by jsbsmd

                    I get it about forwarding and poisoning šŸ‘
                    I chose quad9 and cloudflare specifically because of their dnssec support as all as malware blocking.

                    They SHOULD be smarter than little old me when it come to dns protection.

                    With all this ransomware and crap happening now adays you can't be too carefull.

                    thanks again.

                    1 Reply Last reply Reply Quote 0
                    • johnpozJ
                      johnpoz LAYER 8 Global Moderator
                      last edited by

                      If what your after is their filtering of malware.. That is fine.. But pfblocker in unbound can do the same thing for you - just have to pick which lists you want to you..

                      Keep in mind - you are trusting them, and you are handing them everything you query for..

                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                      If you get confused: Listen to the Music Play
                      Please don't Chat/PM me for help, unless mod related
                      SG-4860 24.11 | Lab VMs 2.8, 24.11

                      B 1 Reply Last reply Reply Quote 0
                      • B
                        bwoodcock @jsbsmd
                        last edited by bwoodcock

                        @jsbsmd

                        Hi, I'm on Quad9's board, and can answer questions about how Quad9 handles things. @jonpoz is correct, if you're using 9.9.9.9, which already DNSSEC validates, repeating the process yourself is redundant. You can also receive unvalidated answers from Quad9, on 9.9.9.10, which may make more sense if you plan to do validation yourself.

                        In the long term, it's always good to do DNSSEC validation as close to (and, ideally on) the endpoint as possible. We lobby OS vendors to include client-side DNSSEC validation, but no major ones do yet, unfortunately. Quad9 provides DNSSEC validation because it's better to have it than not, not because we think you shouldn't do it yourself. We don't have any reason to want you to trust us, and as a matter of policy, we don't like things that require trust. We're not faith-based. :-)

                        It's also worth distinguishing between Cloudflare and Quad9, and not use them interchangeably. As organizations, they have diametrically opposed reasons for existence, organizational models, policies, et cetera... The superficial resemblance shouldn't lead you to think of them as being reasonable to use as "backups" for each other. Quad9 exists specifically for the purpose of not collecting user data, so if you're after privacy, that's worth considering. If you're after malware blocking, you can look at third-party comparisons:

                        https://www.skadligkod.se/general-security/phishing/malicious-site-filters-on-dns-in-2020/

                        Two things aren't necessarily similar just because one of them spends a lot of marketing money to assert that they are.

                        Regarding the original question, you're right to use DNSSEC to validate answers (or to depend upon Quad9 to do that for you if you need to, or want to, trust us to do that for you), and this attack does not succeed against a signed domain; but unfortunately very few people actually sign their domains. So DNSSEC validation, regardless of who does it, only provides a partial answer to this problem.

                        Quad9 is an operational project, not a software-development project, so we use entirely open-source tools that anyone else can use. In theory, there's nothing that we do that anyone can't replicate. Part of our defense against attacks like this, though, is where there's a divergence between that theory and reality. What we do that Cloudflare or a home PFSense user can't do is have back-to-back connections with the world's largest collection of authoritative servers, such that no attack surface exists between them; attacks like this one depend upon the "upstream" interface of a recursive nameserver being reachable in order to impersonate traffic from an authoritative nameserver. When the authoritative nameserver is another VM on the same backplane, or is reached across a private crossconnect in a datacenter, as is the case between Quad9 and hundreds of TLDs, those interfaces aren't reachable from the Internet, and so none of the attacks like this which depend upon compromising communications between recursive and authoritative servers can succeed.

                        Ultimately, though, we only succeed if everyone's protected, so a protection that only works for Quad9 and its users isn't sufficient. To that end, we've been working hard to support the development of authenticated ADoT, which would allow any recursive resolver operator to communicate privately with, and authenticate, any authoritative nameserver.

                        We'll get there eventually.

                        1 Reply Last reply Reply Quote 1
                        • B
                          bwoodcock @johnpoz
                          last edited by

                          @johnpoz said in SAD DNS and unbound question:

                          But pfblocker in unbound can do the same thing for you

                          That'll get you a bit of the way there. The problem being that it can only block lists you can feed it, and none of the most effective ones are publicly available. That's how you get from 50% blocking to 98% blocking. :-/

                          1 Reply Last reply Reply Quote 0
                          • B
                            bwoodcock @johnpoz
                            last edited by

                            @johnpoz said in SAD DNS and unbound question:

                            Also forwarding to 2 different services that do different filtering.. Is problematic at best.. If you query service A and it does not filter, then its cached to not be filtered.. But if you had queried B and it was filtered then it would be cached filtered. But you have no idea which one was used to place the item in your cache.
                            If your going to use a service - pick one, and use that 1.. If one of the major providers goes down the whole internet is pretty much screwed... You pointing to some other service isn't going to magically keep you up and running.

                            Yes, I couldn't agree more, for basically the same reasons. Having two will make debugging a really frustrating experience, and won't guarantee you whatever protections you're looking for. It turns something which should be predictable into a crapshoot.

                            1 Reply Last reply Reply Quote 0
                            • johnpozJ
                              johnpoz LAYER 8 Global Moderator
                              last edited by

                              @bwoodcock said in SAD DNS and unbound question:

                              It turns something which should be predictable into a crapshoot.

                              Exactly.. Well put ;)

                              An intelligent man is sometimes forced to be drunk to spend time with his fools
                              If you get confused: Listen to the Music Play
                              Please don't Chat/PM me for help, unless mod related
                              SG-4860 24.11 | Lab VMs 2.8, 24.11

                              1 Reply Last reply Reply Quote 0
                              • J
                                jsbsmd
                                last edited by

                                What a wealth of information. Thanks. I do agree that using quad9's dns for a small business or home user is probably the wisest choice as they will have access to multiple blocking lists that "I hope" staff will be monitoring them.

                                I come from 30 years of monitoring experience (retired now :)) but still love to learn as much as I can as well as be comfortable with my limitations.

                                So one last question.

                                Will connecting to 9.9.9.9 using udp 53 protect a user or is it a must to use ssl/tls 853? Just thinking about man in the middle attacks.

                                1 Reply Last reply Reply Quote 0
                                • B
                                  bwoodcock
                                  last edited by

                                  @jsbsmd said in SAD DNS and unbound question:

                                  they will have access to multiple blocking lists that "I hope" staff will be monitoring them.

                                  Quad9 is a non-profit project funded by donations, so we don't have a lot of staff, but there's a field and button on the front page of the web site for checking whether we're blocking a domain in the malware-blocking version of the service, and if so, which feed reported it, and any reasons they may have stated. There's also a button for people to report something as a false positive, and we do investigate anything that's reported as a false positive, though that's kind of time-consuming, because the badguys of course report all their stuff as false positives too... And we keep stats on how many times each blocking rule gets exercised without a false-positive report, and reputation-score each of the threat intel feeds. And we keep a list of things that should never be blocked even if they come up in a threat intel feed, so when a threat intel feed includes something on that list, that also contributes (negatively) to their reputational score. Since there are, at any time, millions of things being blocked, and the level of churn is very high (as domains stop being used by badguys and leave the list), there's no way for our small group of staff and volunteers to proactively research each case before it goes into the blocklist, but also the vast majority (more than 99.99%) of blocked domains are never reported as false-positives, either while they're blocked, or after the fact.

                                  Will connecting to 9.9.9.9 using udp 53 protect a user or is it a must to use ssl/tls 853? Just thinking about man in the middle attacks.

                                  "Defense in depth" means a series of layers and complimentary security measures which all contribute to a more safe posture. So, there are several answers to that question, all valid and cumulative:

                                  Using 9.9.9.9 gives you access to an aggregate set of threat intel which is not available in any other way (since it includes internal (not-available-as-a-product) threat data from several large security teams in companies which compete with each other). That's one benefit, and is available regardless of the transport protocol between the user and our recursive resolver.

                                  Using 9.9.9.9 also gives you an external DNSSEC validator. It's better to not have to rely upon someone else for that, but relying on someone else is better than not doing it at all. And for most people, most of the time, there's no mechanism by which they could do it themselves, since it's unfortunately not supported in any significant number of endpoints, and most people don't run their own forwarding/validating or recursive/validating resolver. To be clear, the correct place to do DNSSEC validation is in the endpoint, but there's almost no support for that by vendors, and it's not something that can be easily added in to many platforms by a third party. So we all have to keep pushing for that over time.

                                  Using 9.9.9.9 protects you from the recursive resolver recording your DNS resolution history, and protects you from parties upstream from the recursive resolver seeing your query or associating it with you, but if you use a UDP/53 transport rather than one of the encryption methods (DoT, DoH, or DNScrypt), any party between you and the recursive resolver can record your query and associate it with (at best) the public-facing IP address used to transmit it, or (at worst) a unique "cache busting" key tied to your identity.

                                  In addition, using UDP/53 also leaves you open to man-in-the-middle attacks in which the recursive resolver is impersonated by another entity, usually the access-providing ISP, who may have contracted with a third party to capture and monetize queries.

                                  So, we strongly recommend encrypting the connection between you and your recursive resolver, both for your privacy, and also as a step toward authenticating the recursive resolver. While that authentication currently depends on CA certs, which don't actually provide any security, as that process gets upgraded to DANE certs, that will become real strong authentication that you could rely upon.

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post
                                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.