DDoS Attack Against Dyn Managed DNS • Hacker News Board

Re: DDoS Attack Against Dyn Managed DNS

#591

Post by corvus_sapiens » Fri, Oct 21, 2016, 9:58 PM UTC

komali2 wrote: post #562

pjlegato wrote: post #477

Earlier quoted context omitted.

A company that bills themselves as a reliable, highly available disaster handling tool ought to know better than to have a single point of failure anywhere in its infrastructure. Specifically, they shouldn't have all of their DNS hosted with one company. That is a major design flaw for a disaster-handling tool.

I'm not using the service, but I'm curious what an acceptable threshold for this company is. Like, if half the DNS servers are attacked? If hostile actors sever fiber optic lines in the Pacific? I ask because my secondary question, as a network noob, is was anybody prepared / preparing for a DDOS on a DNS like this? Were people talking about this before? I live in Mountain View so I've been thinking today about the s…

I'm not using the service either, but I noticed this comment [1]. It's not the first time that a DNS server has been DDoS-ed, so it has been discussed before (e.g. [2]). At minimum, I would expect a company that exists for scenarios like this to have more than one DNS server. Staying up when half of existing DNS servers are down is a new problem that no one has faced yet, but this is an old, solved one.

[1] https://news.ycombinator.com/item?id=12759653

[2] https://www.tune.com/blog/importance-dns-redundancy/

Re: DDoS Attack Against Dyn Managed DNS

#592

Post by tim333 » Fri, Oct 21, 2016, 10:00 PM UTC

rybosome wrote: post #580

I'm wondering, from a regulatory perspective, what might be done to mitigate DDoS attacks in the future? From comments made on this and other similar posts in the past, I've gathered the following: 1) Malicious traffic often uses a spoofed IP address, which is detectable by ISPs. What if ISPs were not allowed to forward such traffic? 2) There is no way for a service to exert back pressure. What if there was? e.g. sen…

One thing that occured to me regulations wise is to require IoT devices to have some minimum level of security such as a unique hard password rather than it just being "admin" or some such. You could enforce it for items sold in the US or EU and the Chinese manufacturers would probably follow so their goods could be sold easily.

Re: DDoS Attack Against Dyn Managed DNS

#593

Post by pure_ambition » Fri, Oct 21, 2016, 10:04 PM UTC

nickbauman wrote: post #143

scrollaway wrote: post #18

Relevant (or at least a-propos) post by Bruce Schneier, from a month ago: "Someone Is Learning How to Take Down the Internet" https://www.schneier.com/blog/archives/2016/09/someone_is_le... Edit: And to be clear: I don't mean to imply there's any connection :)

Prediction: A massive, sustained attack will occur on key US Internet infra on election night in an attempt to debase the US election results.

Probably not a great idea. If the internet went down at my work, none of us would be able to do anything, so we'd probably all head out to the polls just because we have nothing better to do. Unintentionally increased turnout.

Re: DDoS Attack Against Dyn Managed DNS

#594

Post by azernik » Fri, Oct 21, 2016, 10:05 PM UTC

bhauer wrote: post #340

Kalium wrote: post #317

Earlier quoted context omitted.

The rogue ISPs thought they were helping people by serving stale data. After all, better something past its use-by date than failing, right? A low tolerance for DNS response times, and suddenly large chunks of the internet are failing a lot... Among other problems, this enables attacks. Leak a route, DDoS a DNS provider, and watch as traffic everywhere goes to an attack server because servers everywhere "protect" peo…

> A low tolerance for DNS response times, and suddenly large chunks of the internet are failing a lot... Hang on a second. I feel that you're piling on other resolver changes in order to make a point. I'm not suggesting that the tolerance for DNS response times be reduced. Nor am I suggesting a scenario where the authority gets one shot after their TTL, after which they're considered dead forever. I would expect my c…

WRT the second attack, what they're referring to is actually DNS cache poisoning - inserting a false record into the DNS pointing your name at an attacker-controlled IP address. This is a fairly common attack, but usually has an upper time limit - the TTL (which is often limited by DNS servers).

This proposal would allow an attacker to prolong the effects of cache poisoning by running a simultaneous DDoS against un-poisoned upstream DNS servers.

Re: DDoS Attack Against Dyn Managed DNS

#595

Post by Godel_unicode » Fri, Oct 21, 2016, 10:06 PM UTC

Kalium wrote: post #515

bhauer wrote: post #503

Earlier quoted context omitted.

Kalium, I really appreciate your responses. If my adversary can steal an IP from Facebook, create a valid certificate for facebook.com, and provide bogus DNS resolution for facebook.com, I feel it's game over for me. My home network is forfeit to such an adversary. But I get your point. It's about layering on mitigating factors. The lower the TTL, the lower the exposure. Still, my current calculus is that the risk of…

Now that I think about it more, it's even worse than that. A bogus non-DNSSEC resolution and a forged cert, both of which are real-life attacks that have actually happened, and you're done for. Compromising an IP isn't really necessary if you're going to hang on to a bad one forever, but it's a nice add-on. It removes the need to take out the DNS provider, but we can clearly see that that is possible. Keeping the bal…

If you can forge certs for HTTPS-protected sites, this is not what you would use them for.

Re: DDoS Attack Against Dyn Managed DNS

#596

Post by bhauer » Fri, Oct 21, 2016, 10:07 PM UTC

anfedorov wrote: post #573

Kalium wrote: post #352

Earlier quoted context omitted.

> Hang on a second. I feel that you're piling on other resolver changes in order to make a point. Yes. The point I am making is the additional failure modes that need to be considered and the pain they can cause. Historically have caused. At no point did I ever think you were suggesting that one failure to respond renders a server dead to your resolver forever. Instead, I expect that your resolver will see a failure…

Please stop trolling. None of the issues you're raising apply to his original idea, and it's already implemented by OpenDNS with significant upside and virtually no downside.

I appreciate the support. But FWIW, I don't think Kalium was trolling. Although he (I assume, but correct me if I am wrong) and I disagree on the risk versus reward of extending the time-to-live of cached resolutions beyond the authoritative TTL, I nevertheless appreciated and enjoyed his feedback.

Re: DDoS Attack Against Dyn Managed DNS

#597

Post by Godel_unicode » Fri, Oct 21, 2016, 10:09 PM UTC

phil21 wrote: post #556

slim wrote: post #494

Earlier quoted context omitted.

So if our resolver was on our resolver was on our laptop and had a nice UI that would work great. Now the question is : why is the resolver not in my laptop?

It can be if you want it to be, but it's probably much less interesting than you think. You likely underestimate the sheer number of DNS records you look up just by surfing the web, and how useful that information would be to 99.99% of users. Basically the tools exist for you to do this yourself if you are so inclined, but they may not be that user friendly since they aren't generally useful to most.

Seconded. This is a common idea which occurs to people who haven't dealt with DNS before, and it ends with a much better understanding of how many things https is used for and going back to using openDNS as your resolver.

Re: DDoS Attack Against Dyn Managed DNS

#598

Post by Godel_unicode » Fri, Oct 21, 2016, 10:13 PM UTC

JoshTriplett wrote: post #428

bhauer wrote: post #214

Out of curiosity, why do caching DNS resolvers, such as the DNS resolver I run on my home network, not provide an option to retain last-known-good resolutions beyond the authority-provided time to live? In such a configuration, after the TTL expiration, the resolver would attempt to refresh from the authority/upstream provider, but if that attempt fails, the response would be a more graceful failure of returning a la…

It'd be nice to have a "backup TTL" included, to allow sites to specify whether and how long they wanted such caching behavior. Also, that cache would need to only kick in when the server was unreachable or produced SERVFAIL, not when it returned a negative result. Negative results returned by the authoritative server are correct, and should not result in the recursive resolver returning anything other than a negativ…

This is why TTL is a variable. If you want to have your records last longer, you can. If you want to later shorten them, you can. People screw DNS up enough already, let's not make it worse by adding layers of TTL.

Re: DDoS Attack Against Dyn Managed DNS

#599

Post by Kalium » Fri, Oct 21, 2016, 10:14 PM UTC

bhauer wrote: post #596

anfedorov wrote: post #573

Earlier quoted context omitted.

Please stop trolling. None of the issues you're raising apply to his original idea, and it's already implemented by OpenDNS with significant upside and virtually no downside.

I appreciate the support. But FWIW, I don't think Kalium was trolling. Although he (I assume, but correct me if I am wrong) and I disagree on the risk versus reward of extending the time-to-live of cached resolutions beyond the authoritative TTL, I nevertheless appreciated and enjoyed his feedback.

You assume correctly.

Re: DDoS Attack Against Dyn Managed DNS

#600

Post by azernik » Fri, Oct 21, 2016, 10:14 PM UTC

MaxfordAndSons wrote: post #190

nickbauman wrote: post #143

Earlier quoted context omitted.

Prediction: A massive, sustained attack will occur on key US Internet infra on election night in an attempt to debase the US election results.

This is terrifying. Thankfully I don't think much actual voting infra is network reliant. But it could probably delay the results from being finalized for days, and allow Trump to spew further allegations of rigging. Though if they targeted electric grid, water, and public transport, starting early in the day and choosing the regions by their populations political leaning, it could easily have an effect on the result…

I'm working at the polls in CA, and can verify this; all critical information is moved by sneakernet with a two-person rule on its handling.

Of course, I have no information on the security model of the pre-election preparations and post-election tabulation, but luckily results for each polling place are also posted for the public to inspect - media outlets and campaigns can verify the tabulation themselves with a slight delay.