Linked by Thom Holwerda on Thu 28th Mar 2013 00:36 UTC, submitted by MOS6510
Internet & Networking "The New York Times this morning published a story about the Spamhaus DDoS attack and how CloudFlare helped mitigate it and keep the site online. The Times calls the attack the largest known DDoS attack ever on the Internet. We wrote about the attack last week. At the time, it was a large attack, sending 85Gbps of traffic. Since then, the attack got much worse. Here are some of the technical details of what we've seen."
Thread beginning with comment 557022
To view parent comment, click here.
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

Soulbender,

"And that's the only thing you need to do in order to prevent spoofing from your clients. Very simple, very effective."

At the expense of features like multi-homing.


"Not really. It's quite possible to filter without breaking the internet traffic but it does require some work. You will always know what prefixes your peers announce so you can set things up to only ever accept packets with an IP in those prefixes from a peer."


Those announcements are meant to indicate the paths for routing destination IP's, not filtering source IPs. While there is nothing stopping you from filtering in this way, at the very least this will cause network disruptions while the network is propagating new optimal paths. But it could cause persistent problems for asymmetric scenarios. For example your organization has two peers: Hurricane Electric and Cogent. A foreign router determines Hurricane Electric's network is the best way to route an IP to you, but your router determines that Cogent is the best way to send the packet back. If you filter out this IP on Hurricane Electric's interface, then you loose legitimate traffic. You have no way to determine whether packets on either interface are spoofed or not.



"No, it isn't. It's a problem combined of misconfigured DNS servers and ISP's not doing filtering on their customers. DNS itself is just doing what it was supposed to do."

Yes, it's doing what it's programmed to do, so it's not a "bug" or misconfiguration. But it causes a problem in this case because the sender isn't verified. That IS a vulnerability as this incident clearly demonstrates. Any UDP protocol is vulnerable if it responds with lots of traffic without first performing a handshake, so in a way DNS is guilty, even though it works as designed.

Edited 2013-03-29 04:41 UTC

Reply Parent Score: 2

Soulbender Member since:
2005-08-18

At the expense of features like multi-homing.


No, not at all. Ingress and egress filtering does not prevent multi-homing.

Those announcements are meant to indicate the paths for routing destination IP's, not filtering source IPs.


Those are the sources that should only ever arrive from a certain peer. They indicate exactly what I need to know: what are the valid source IP addresses from a peer. For example, if I have been assigned 1.2.3.4/24 and I peer with HE, announcing 1.2.3.4/24, they should only every accept packets from me with a source in 1.2.3.4/24.

at the very least this will cause network disruptions while the network is propagating new optimal paths.


No.

For example your organization has two peers: Hurricane Electric and Cogent. A foreign router determines Hurricane Electric's network is the best way to route an IP to you, but your router determines that Cogent is the best way to send the packet back. If you filter out this IP on Hurricane Electric's interface, then you loose legitimate traffic. You have no way to determine whether packets on either interface are spoofed or not.


Why would I "filter out this IP"? Ingress and egress filtering works perfectly in this scenario (I know, I've done it many times). The packet coming in via HE, addressed to my network, is a valid ingress source and the packet going out via Cogent is from my network and is a valid egress source. Nothing is being filtered, spoofing is prevented.
Obviously I will not accept sources from either that is in my network nor will I accept destinations that is not my network. Neither provider should accept packets from me that is not from my network.

Edited 2013-03-29 04:56 UTC

Reply Parent Score: 2

Alfman Member since:
2011-01-28

"No, not at all. Ingress and egress filtering does not prevent multi-homing."

Depends on the type of multihoming. One type is to NAT traffic across different IPs, but that might be worse than shared IP hultihoming for certain things, esp like VOIP where you really want to use one IP and let the network determine the shortest path on it's own. Admittedly this is probably very uncommon outside of the enterprise, and not very useful without the help of the ISP to cooperate in advertising your own IP routes through them.

My understanding is that many services, including the root nameservers employ this kind of shared IP address multihoming today in order to increase redundancy and decrease latency.



"Why would I 'filter out this IP'?"

I may have misunderstood you then, I thought you were advocating blocking externally generated inbound traffic from your peers based on source IP, which is what I'm refuting the benefit of.

http://www.osnews.com/thread?557011

If I misread that it could explain our disagreement ;)

Edited 2013-03-29 06:08 UTC

Reply Parent Score: 2