Schneier usually puts out good stuff but sometimes rambles. This is tending towards that second one. I respect him and his journalism but this article is “because I say so” and I don’t see how it benefits anyone aside from possible fear mongering or becoming the definitive source of future citations, establishing a shaky foundation.
This is one of those stories where translating “several” or “many” to “two” helps.
A friend of mine commented that DDoS attacks are typically a flood of UDP packets with forged IP headers. Why don’t ISPs simply block all packets with a forged origin? Since ISPs are the ones allocating addresses to end-users in the first place, detecting IP forgery would be dead simple.
This solution sounds too easy. Are there any problems that would arise from dropping packets with forged headers?
ISP engineer here.
Majority of DDoS attack are made with UDP, but it’s not easy at all to detect them because the spoofing parts it’s about the protocol payload (NTP, DNS).It would require very expensive hardware to inspect the application layer.
Furthermore, when a DDoS is arrived on the ISP network it’s too late because the upstreams link or routers may be already saturated.
The more you block close to the sources, the more it will be effective.
Even blackholing the destination should be not so much useful.
You should use some BGP tricks (like the smart use of communities), but fighting DDoS it’s an hard work.
I think ChadSki here is referring not how to detect and drop DDoS traffic at the receivers end but why this problem is not solved at the source by the network providers who do know what IP addresses they have assigned and use and to filter out the (egress) traffic leaving their network that claims to have a source IP from outside those ranges. If the sender is unable to get spoofed source IP packets beyond their network providers borders, it kills the DoS at source.
The answer is, they could, this is covered in BCP38 and when I used to follow it the NANOG mailing list had plenty of grumbings about the lack of uptake.
Typically this is implemented by using reverse path filtering so that before a router forwards the traffic, it looks at its own routing table to see if to send traffic back to the ‘source’ (maybe spoofed) it would send it back over the network interface the packet arrived on. If it matches, the packet is ok to forward, if not it is dropped.
This is something most ISP’s (users behind xDSL, leased line, fibre, etc) and hosting providers (co-location, VPS, cloud, etc) can do. It is functionality that has been baked into software and hardware routers for over a decade.
There are some reasons why this may not be a straight forward and possible for some ISP’s, typically if they also offer transit provider, but this is now pushing me past my rusty memory as an “ex-ISP network administrator” and I would need to do some catch up reading before I declare all ISPs lazy/stupid/… :)
OpenBSD’s pf has an antispoof rule for just this. Maybe someone with more knowledge of it, can comment on its effectiveness, but yeah, it seems plausible.
But, I also highly doubt that spoofing source IPs is the leader in DDoS techniques. If I can purchase time on bot nets across 20,000 different nets, I can simply use the source IP of the bot, and get a ton of legitimate looking, randomly distributed sources, which are not so easy to deal with without disruption. If I can get 200,000 different net sources, then any operator trying to block them all, has a high probability of blocking legitimate, customer traffic, which is denial of service in and of itself.
I am not trying to defend Cloudflare here, but its CAPTCHAs and Kill-Bots itself seem like really good strategies for dealing with this, unfortunately.
As far as I know, udp based amplification reflection attacks with spoofed sources, are still a big problem.
Some do, but there’s no incentive. Outbound traffic is rarely an issue.
For big carriers, I imagine you are often dealing with lots of transit and peering, so you may not always know the full sources of an eventually reachable AS being routed through you.
But for last mile connectivity networks, you would certainly think it would make sense. I wonder if it comes down to the fact that unless most people do it, it probably doesn’t help much…and until most people do it, it probably doesn’t make it worth the effort to do it and maintain it.
Big carriers (Tier 1) have some complex network policies, but they must know how the AS traffic is flowing through the network. There are some BGP filters about AS paths on the incoming ports just to prevent DDoS.
Last mile connectivity network has a few BGP peers (providing default route), than it’s easy to control traffic flows.
If you are interested in some products that can fight DDoS look for Arbour Network or Radware.
There were also 100Gbit NIDS built a while back to enable such applications. So, it could be done. Priorities and pricing are key issues as usual.
Priorities and pricing are key issues as usual
You cannot pretend to pay an 20MB ADSL 20€/month and have also DDoS protection.
It’s like buying a Fiat Panda and expect to have Ferrari engine.
What are you talking about? Im clearly talking about the Tier 1-3’s backbones who could actually afford or use a 100Gbps appliance. A customer with ADSL is screwed the second the traffic hits their line. Saturation attacks should be handled upstream of them where the pipes are big and pockets are deep.
ACK. Will take that into account.
I keep wondering how long the shared trust model the internet is based on can survive in the modern day.