Re-read the blog post. He's speculating the attack used DNS. (Though he has no proof.) In that case, with UDP, spoofed headers are allowed out. Connectionless.
Cloudflare uses anycast DNS - machines in different geographically located data centers all sharing the same IP.
If you want to try to make your site DOS-proof (and potentially faster), one way is to move the site to the network edge. Move the data closer to the user. Put a copy on a machine in the data center nearest the user. Do this in data centers around the world. ("CDN") Give all the machines the same IP. ("Anycast") Your users will be accessing a mirrored copy of your site at some regional data center, instead of actually sending requests that go out to the internet. Does Google do this? Akamai? Netflix?
Next time you access a popular website ask yourself "Am I actually accessing the internet? Or am I just downloading a copy of something from a local data center?"
A lot of these services are just marketing. In theory they sound great, but things may be different in practice. And that's why we frequently see comments that things did not work as expected.
I did some CDN experiments downloading pages using Akamai where I accessed content on the "true IP address" (the master copy so to speak) versus the regional IP address they provide through stupid DNS tricks. Guess which one was faster?
It all depends on caching: what is in the cache and what isn't. Same applies to DNS. A DNS caching server (resolver) is only faster than non-caching DNS server (authoritative) if it's primed with the records you're after. If they are not in the cache, it will not be faster. In fact, it will be slower because there are more steps to the process.
These strategies are often based on 80/20, power law thinking. If you are not in the 20 percent of content being accessed 80 percent of the time, then you do not see the benefits. If no one in your region has requested a given page, and you're the first, it will be slower to wait for it to be cached at your regional data center than if you just grabbed it from the internet.
> In that case, with UDP, spoofed headers are allowed. Connectionless.
rachelbythebay is asking which ISPs allow spoofed UDP packets.
The way this attack works is you send a query to an open resolver, using the target's IP address as the "source" IP address in the UDP header instead of your own.
However, ISPs can (and should) block UDP packets where the source IP address is outside the IP-blocks they own. Why don't ISPs do this?
I'm not really sure what the rest of your post has to do with any of this.
So you are saying it is common practice to block outgoing UDP packets based on source IP? I did not know this. Does your ISP do that? Everyone is expected to block ingress with spoofed IP. But I can't find an BCP for blocking UDP egress based on source IP. Does it exist?
As for the rest the comment, this appears to be an "informational advertising" style marketing piece for Cloudflare so I think it's relevant.
Right. As the top post also points out. There's no way to distinguish incoming UDP traffic as "spoofed".
My question is does anyone filter UDP egress based on source IP? Is there guidance somewhere that tells admins to do this?
Let me put it another way: If it was a workable solution to get admins to do this - to filter outgoing UDP based on source IP, then why are people trying to get network admins to change their DNS server settings as a way to reduce the possibility of DNS-based DDOS? That seems like a far more difficult task given that there hundreds of thousands of open resolvers and most admins understand working with firewall rulesets better than DNS configuration.
Sure you can at the carrier level, it's called unicast reverse path forwarding. Any incoming packets from a network with a source IP not being advertised via BGP by that network would be spoofed.
One person accessing data from "origin" is faster then getting it from the "cdn" but the cacheing lets you leverage bandwidth. Instead of building 100gbps of capacity I can instead build a origin server with 5gbps of capacity and let the CDN do the heavy lifting.
If every user where to go around the cdn then the site would break.
Comments
Re-read the blog post. He's speculating the attack used DNS. (Though he has no proof.) In that case, with UDP, spoofed headers are allowed out. Connectionless.
Cloudflare uses anycast DNS - machines in different geographically located data centers all sharing the same IP. If you want to try to make your site DOS-proof (and potentially faster), one way is to move the site to the network edge. Move the data closer to the user. Put a copy on a machine in the data center nearest the user. Do this in data centers around the world. ("CDN") Give all the machines the same IP. ("Anycast") Your users will be accessing a mirrored copy of your site at some regional data center, instead of actually sending requests that go out to the internet. Does Google do this? Akamai? Netflix?
Next time you access a popular website ask yourself "Am I actually accessing the internet? Or am I just downloading a copy of something from a local data center?"
A lot of these services are just marketing. In theory they sound great, but things may be different in practice. And that's why we frequently see comments that things did not work as expected.
I did some CDN experiments downloading pages using Akamai where I accessed content on the "true IP address" (the master copy so to speak) versus the regional IP address they provide through stupid DNS tricks. Guess which one was faster?
It all depends on caching: what is in the cache and what isn't. Same applies to DNS. A DNS caching server (resolver) is only faster than non-caching DNS server (authoritative) if it's primed with the records you're after. If they are not in the cache, it will not be faster. In fact, it will be slower because there are more steps to the process.
These strategies are often based on 80/20, power law thinking. If you are not in the 20 percent of content being accessed 80 percent of the time, then you do not see the benefits. If no one in your region has requested a given page, and you're the first, it will be slower to wait for it to be cached at your regional data center than if you just grabbed it from the internet.
> In that case, with UDP, spoofed headers are allowed. Connectionless.
rachelbythebay is asking which ISPs allow spoofed UDP packets.
The way this attack works is you send a query to an open resolver, using the target's IP address as the "source" IP address in the UDP header instead of your own.
However, ISPs can (and should) block UDP packets where the source IP address is outside the IP-blocks they own. Why don't ISPs do this?
I'm not really sure what the rest of your post has to do with any of this.
So you are saying it is common practice to block outgoing UDP packets based on source IP? I did not know this. Does your ISP do that? Everyone is expected to block ingress with spoofed IP. But I can't find an BCP for blocking UDP egress based on source IP. Does it exist?
As for the rest the comment, this appears to be an "informational advertising" style marketing piece for Cloudflare so I think it's relevant.
You can't tell that incoming UDP is spoofed. The only filtering you can reliably do is outgoing.
Right. As the top post also points out. There's no way to distinguish incoming UDP traffic as "spoofed".
My question is does anyone filter UDP egress based on source IP? Is there guidance somewhere that tells admins to do this?
Let me put it another way: If it was a workable solution to get admins to do this - to filter outgoing UDP based on source IP, then why are people trying to get network admins to change their DNS server settings as a way to reduce the possibility of DNS-based DDOS? That seems like a far more difficult task given that there hundreds of thousands of open resolvers and most admins understand working with firewall rulesets better than DNS configuration.
Of course they do.
Any responsible host filters all outgoing packets to limit them to <only IP addresses we own>.
For example, linode does this afaik.
Thanks.
http://tools.ietf.org/html/rfc4732
Sure you can at the carrier level, it's called unicast reverse path forwarding. Any incoming packets from a network with a source IP not being advertised via BGP by that network would be spoofed.
One person accessing data from "origin" is faster then getting it from the "cdn" but the cacheing lets you leverage bandwidth. Instead of building 100gbps of capacity I can instead build a origin server with 5gbps of capacity and let the CDN do the heavy lifting.
If every user where to go around the cdn then the site would break.
> Re-read the blog post. He's speculating the attack used DNS. (Though he has no proof.)
You may want to re-read it yourself:
"The attack on Saturday used one such amplification technique called DNS reflection."
I did re-read it.
But where's the proof they used DNS? Upload a packet capture and let us be the judge.