SAD DNS and unbound question
-
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
-
@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..
-
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.
-
Well did you go to the test site?
Example I just did and
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..
-
I'm seeing the same (surprise ...)
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
-
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. -
@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.
-
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.
-
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..
-
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.
-
@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. :-/
-
@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.
-
@bwoodcock said in SAD DNS and unbound question:
It turns something which should be predictable into a crapshoot.
Exactly.. Well put ;)
-
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.
-
@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.
