Live data from Hacker News

Attack on DNS root servers

root-servers.org

61–70 of 97 posts

Re: Attack on DNS root servers

#61
post #52
post #37

Earlier quoted context omitted.

to protect a visitor's privacy

What privacy? Your IP and the hostname of the website you're connecting to isn't encrypted over HTTPS anyway. The content isn't sensitive and there's no cookies on the site. The only remotely personal data would be your accept language header (which could be guessed from your IP) and user agent string (which you can just spoof anyway if you're really that paranoid). The MITM argument has more merit, but even there I…

Your IP and the hostname of the website you're connecting to isn't encrypted over HTTPS anyway.

AFAIK website hostname is visible when using SNI.

Re: Attack on DNS root servers

#62
post #42
post #8

What made this unique now? Was it simply a high load?

The root servers get large traffic spikes quite routinely, this event was simply an order of magnitude or more larger than any previous events (AFAIK). Also, it actually managed to DoS a few instances, by way of saturating their throughput--though as the notice mentions, the overall DNS wasn't significantly affected aside from a few queries having to be retried.

You can clearly see the spike in this graph[0] (scale it down to Dec to see more detail). These graphs[1] show that it was limited to IPv4.

[0] http://a.root-servers.org/metrics.html

[1] http://k.root-servers.org/statistics/ROOT/monthly/

Re: Attack on DNS root servers

#63
post #18
post #7

"Source Address Validation and BCP-38." ISPs should validate the source address of UDP traffic from their end customers. This would end most UDP based volumetric DDoS attacks.

It would help reflection attacks that direct e.g. DNS responses to the target. It wouldn't help when the DNS servers themselves are the target.

It would make filtering out malicious requests easier, which would improve performance for people whose machines weren't botnetted.

Re: Attack on DNS root servers

#64
post #63
post #18

Earlier quoted context omitted.

It would help reflection attacks that direct e.g. DNS responses to the target. It wouldn't help when the DNS servers themselves are the target.

It would make filtering out malicious requests easier, which would improve performance for people whose machines weren't botnetted.

In this case, yes, and it would also reduce load on the servers quite a bit. But in a volumetric attack, your pipe is full already. Any filtering you apply after that can only weed out bad traffic; you can't fit any more good traffic in there.

Re: Attack on DNS root servers

#65
post #26

Earlier quoted context omitted.

It was presumably done over UDP where it's trivial to fake source IP. What's the minimum size of a valid UDP-based DNS request? Let's guesstimate 25 bytes. Then 50M/s * 25 bytes = 1.25 GB/s. Or 10 Gbit/s. Is that really so impressive these days?

Is it really that trivial to fake source IP? I think pretty much any ISP wouldn't let such packets through (or am I missing something?), and you are also easier to find then (well, if you are not careful that is).

Reality check: ~30% of active AS worldwide don't drop spoofed packets originating from their networks.

http://spoofer.cmand.org/summary.php

Re: Attack on DNS root servers

#66
post #18
post #7

"Source Address Validation and BCP-38." ISPs should validate the source address of UDP traffic from their end customers. This would end most UDP based volumetric DDoS attacks.

It would help reflection attacks that direct e.g. DNS responses to the target. It wouldn't help when the DNS servers themselves are the target.

No it would help because instead of giving up on tracing the attacks since the source address was spoofed, you would know who was spamming packets and get them black holed.

Re: Attack on DNS root servers

#67
post #61
post #52

Earlier quoted context omitted.

What privacy? Your IP and the hostname of the website you're connecting to isn't encrypted over HTTPS anyway. The content isn't sensitive and there's no cookies on the site. The only remotely personal data would be your accept language header (which could be guessed from your IP) and user agent string (which you can just spoof anyway if you're really that paranoid). The MITM argument has more merit, but even there I…

Your IP and the hostname of the website you're connecting to isn't encrypted over HTTPS anyway. AFAIK website hostname is visible when using SNI.

Indeed, but SNI is more than 10 years old now so very well supported. I'd appreciate someone else correcting me if I'm wrong here, but I believe SNI is also enabled by default (where it's supported).

In any case, even without the hostname header, it doesn't take much research to find a short list of possible candidates (eg https://www.virustotal.com/en/ip-address/193.0.6.136/informa...).

Re: Attack on DNS root servers

#68
post #31
post #26

Earlier quoted context omitted.

Is it really that trivial to fake source IP? I think pretty much any ISP wouldn't let such packets through (or am I missing something?), and you are also easier to find then (well, if you are not careful that is).

If this was a botnot, any one ISP is only seeing a tiny fraction of the load. Even if it were from a single source, it also isn't that hard to find an ISP that doesn't care. (They cost slightly more, but if you're a bad actor, presumably it is worth it.) Edit: "I think pretty much any ISP wouldn't let such packets through" If you google "BCP38", you will find well over a decade of network operators discussing specifi…

After you have been a target of ~50 Gbps NTP reflection attacks that nearly destroyed our company, it's hard to be impartial in these discussions.

Re: Attack on DNS root servers

#70
post #67
post #61

Earlier quoted context omitted.

Your IP and the hostname of the website you're connecting to isn't encrypted over HTTPS anyway. AFAIK website hostname is visible when using SNI.

Indeed, but SNI is more than 10 years old now so very well supported. I'd appreciate someone else correcting me if I'm wrong here, but I believe SNI is also enabled by default (where it's supported). In any case, even without the hostname header, it doesn't take much research to find a short list of possible candidates (eg https://www.virustotal.com/en/ip-address/193.0.6.136/informa... ).

Thanks for going deep into this, let me add though that it's not about an ideal world or bullying, HTTPS should be the default. Lets Encrypt managed that for us already, pretty soon it will be the default.
Post reply on HN