Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DDoS Attack Against Dyn Managed DNS

dynstatus.com

Post reply on HN
Print view View original

601–610 of 721 posts

Re: DDoS Attack Against Dyn Managed DNS

#601

Post by Kalium »

Godel_unicode wrote: post #595
Kalium wrote: post #515

Earlier quoted context omitted.

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.

It's part of what I would use them for. A big, splashy attack distracts a bunch of people while you MITM something important with a forged cert? Great way to steal a bunch of credentials with something that leaves relatively few traces while the security people are distracted.

Re: DDoS Attack Against Dyn Managed DNS

#602

Post by Godel_unicode »

cjbprime wrote: post #338
toomuchtodo wrote: post #326

Earlier quoted context omitted.

Serving wrong records is usually worse than serving no records. EDIT: It would be fine as long as your site only served HTTPS content and HSTS was enabled for your domain, preventing any sort of MITM attack.

If your DNS server is offline, is the last record it returned when it was online really the "wrong" one? There'd be no right one in that case.

Yes. You either positively know the right answer, or you return the fact that you don't know the right (currently valid per the spec) answer. The right answer in the situation you posed is "I don't know".

Re: DDoS Attack Against Dyn Managed DNS

#603

Post by pyre »

Kalium wrote: post #352
bhauer wrote: post #340

Earlier quoted context omitted.

> 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…

> 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…

> Instead, I expect that your resolver will see a failure to respond from a resolver a high percentage of the time, leading to frequent serving of stale data.

If this were true, the current failure mode would have end users receiving NX DOMAIN a "high percentage of the time," which obviously is not happening.

{edit: To be clear, I'm reading the quote as you stating that "failure to resolve" currently happens a high percentage of the time, and therefore this new logic would result in extended TTLs more often than the original post would assume they would happen}

> However, that the real problem is in another castle does not excuse technical design decisions that compound the real problem and increase the damage potential.

It's fair to point out that this change, combined with other known issues could create a "perfect storm," but as was pointed out this exploit is already possible within the current authoritative TTL window. Exploiting the additional caching rules would just be a method of extending that TTL window.

On the other hand, where do you draw the line here? If you had to make sure that no exploits were possible most of the systems that exist today would never have gotten off the ground. It seems a bit like complaining that the locks to the White House can be exploited (picked), while missing the fact that they are only supposed to slow someone down before the "men with guns" can react.

Re: DDoS Attack Against Dyn Managed DNS

#604

Post by saidajigumi »

edgartaor wrote: post #567

I'm curious. What kind of infrastructure you need to make this massive attack?

via [1]: "Dyn says today's DDoS are in part being caused by Mirai botnet, which recently caused record-sized attack [2]"

[1] https://twitter.com/AlexJamesFitz/status/789562789920636928

[2] https://krebsonsecurity.com/2016/10/source-code-for-iot-botn...

tl;dr: a substantial part of this attack is a botnet of IoT devices.

Re: DDoS Attack Against Dyn Managed DNS

#605

Post by Kalium »

pyre wrote: post #603
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…

> Instead, I expect that your resolver will see a failure to respond from a resolver a high percentage of the time, leading to frequent serving of stale data. If this were true, the current failure mode would have end users receiving NX DOMAIN a "high percentage of the time," which obviously is not happening. {edit: To be clear, I'm reading the quote as you stating that "failure to resolve" currently happens a high p…

Based on the highly unscientific sample of the set of questions asked by my coworkers in my office today, the failure mode of end users receiving NX DOMAIN has happened much more than on most days.

I don't need to make sure no exploits are possible. However, it at all possible, I'd like to help ensure that things aren't accidentally made more dangerous. It's one thing to consider and make a tradeoff. It's quite another to be ignorant of what the price is.

Re: DDoS Attack Against Dyn Managed DNS

#606

Post by thomask0 »

eridius wrote: post #565
leesalminen wrote: post #430

Earlier quoted context omitted.

> US election is in 3 weeks and Donald Trump is openly in love with Putin. He states that he's never met Putin nor has any holdings in Russia. He has stated that he is open to positive relationships with the Russian government. > Trump questioned the benefit of NATO which is the basis for Europe stability after the 2nd world war. I believe he stated that he wants NATO to "pay their fare share" in the costs of maintai…

Trump says he never met Putin, now. In the past, he said he did. I just did a search for "trump met putin" and found a bunch of news sites reporting that in a GOP debate a while ago Trump said “I got to know him very well because we were both on ‘60 Minutes,’ we were stablemates, and we did very well that night.”

Trump was boasting in that debate about nothing, they were on the same episode of 60 minutes but they were not even on the same continent for that episode.

http://time.com/4108198/donald-trump-60-minutes-putin/

Re: DDoS Attack Against Dyn Managed DNS

#607

Post by thomask0 »

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…

Let ISP's shutdown traffic of customers with compromised devices.

Re: DDoS Attack Against Dyn Managed DNS

#608

Post by pyre »

Kalium wrote: post #605
pyre wrote: post #603

Earlier quoted context omitted.

> Instead, I expect that your resolver will see a failure to respond from a resolver a high percentage of the time, leading to frequent serving of stale data. If this were true, the current failure mode would have end users receiving NX DOMAIN a "high percentage of the time," which obviously is not happening. {edit: To be clear, I'm reading the quote as you stating that "failure to resolve" currently happens a high p…

Based on the highly unscientific sample of the set of questions asked by my coworkers in my office today, the failure mode of end users receiving NX DOMAIN has happened much more than on most days. I don't need to make sure no exploits are possible. However, it at all possible, I'd like to help ensure that things aren't accidentally made more dangerous. It's one thing to consider and make a tradeoff. It's quite anoth…

Well, it obviously happens when the resolver is down, but that's the situation that this logic is being proposed to smooth over. The normal day-to-day does not see a high percentage of resolvers failing to respond, or else people would be getting NX DOMAIN for high profile domains much more often.

Re: DDoS Attack Against Dyn Managed DNS

#609

Post by Kalium »

pyre wrote: post #608
Kalium wrote: post #605

Earlier quoted context omitted.

Based on the highly unscientific sample of the set of questions asked by my coworkers in my office today, the failure mode of end users receiving NX DOMAIN has happened much more than on most days. I don't need to make sure no exploits are possible. However, it at all possible, I'd like to help ensure that things aren't accidentally made more dangerous. It's one thing to consider and make a tradeoff. It's quite anoth…

Well, it obviously happens when the resolver is down, but that's the situation that this logic is being proposed to smooth over. The normal day-to-day does not see a high percentage of resolvers failing to respond, or else people would be getting NX DOMAIN for high profile domains much more often.

I'm just trying to make sure we don't wind up making DNS poisoning nastier in an effort to be more user-friendly.

Re: DDoS Attack Against Dyn Managed DNS

#610

Post by jrochkind1 »

sinap wrote: post #323
jrochkind1 wrote: post #313

Is it time for everyone to actually start using secondary name servers/DNS resolvers too from a different provider from primary? DNS _is_ built for this, for the very purpose of handling failure of the primary resolver, isn't it? Just most people don't seem to do it -- including major players? Or would that not actually solve this particular scenario?

The attack is on the authoritative name servers, not a DNS resolver. A public DNS resolver will query the authoritative name server for a record if it doesn't exist in it's cache.

Can you have secondary name servers too though? And would it have worked to avoid outage for domains doing such in this case?
Post reply on HN