Hacker News Reader

Comment by rachelbythebay | Hacker News Reader

Who are these irresponsible network operators that allow spoofed source addresses out of their network? The only way to make a reflection attack like this work is to make the responses go back to the victim. For that to happen, it has to look like they generated the request.

Remember smurf? Spoof-ping a broadcast address for a multiplication effect. It's from 1997 or so. 15 years later and we're still living with that kind of problem.

http://en.wikipedia.org/wiki/Smurf_attack

View on HN

Who are these irresponsible network operators that allow spoofed source addresses out of their network?

There is at least one legitimate use for "spoofed" IPs... http://en.wikipedia.org/wiki/Mobile_IP

Of course this protocol is rarely used and can probably be blocked on most consumer ISPs...

Wouldn't this be the protocal that lets my phone switch over from 4G to wifi?

Many developing countries may have those network operators, who don't know or perhaps don't care.

Most large service providers disallow ICMP (which prevents these types of ping attacks), unfortunately that also messes with path MTU discovery. One potential way of dealing with these bot nets forging source IPs is to perform an analysis on the IP TTLs -- if a single source is sending you a large amount of traffic, I wouldn't expect to see widely varying IP TTLs as the majority of packets should take the same number of hops to reach you. If a bot net army, distributed around the globe, is spoofing the source IP, I'd expect to see a wide variance in the IP TTLs and thus know that something was up (and thus blackhole traffic claiming to be from that source IP).

Large service providers do not disallow ICMP at the network level. TCP/IP relies on ICMP for a number of purposes other than PING (ICMP ECHO), and a network would be broken without it.

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.

Reply on news.ycombinator.com