> Of course it's not possible ... if you use a crummy design. It's > trivial to come up with non-completely-crummy designs. For example, > adding a front-end where you take a hash of source-ip/dest-ip and run > it through a smallish hash table, you can use that as a filter to > eliminate a lot of traffic that's just normal and non-interesting. You > want to take a closer look at the traffic that's heaviest (read: most > hits) or new and significant (read: diff against an hour ago). You > probably don't want to do this just per-IP, but likely also per- > network.
I think one of the problems is that with modern bot-nets, traffic can be generated by a huge number of hosts and assuming your DoS traffic is coming from a source that can be blocked might be an unreasonable expectation. You can't assume that you are going to get a flood of traffic from some source that you can pin down and block. You might get flood of traffic from tens of thousands of source IPs from all over the world with each one sending only a very small amount AND the source IPs constantly changing. They might even be sending traffic that looks perfectly legitimate on the surface and might need to be profiled/fingerprinted in some manner at layer 4. It isn't as easy as just handling it at the router. And there is no guarantee the source IP of the traffic is really where it is coming from since there are still a good number of providers out there who don't install packet filters on their customer links. They accept any traffic their customer sends them even if the source IP isn't within the customer's network range. So that is part of the game, too. If you have 10,000 hosts sending packets with spoofed IP addresses where the goal is to get you to block the apparent source network, as soon as you block those source addresses, the DoS has succeeded. > And you probably don't want to use just this one technique, > you want to combine it with others. I think "probably" is the wrong word here. The word "certainly" leaps to mind. > And you probably need to consider > the types of attacks that are known, likely, etc., and design > accordingly, because this one little example I've provided is just one > part of a comprehensive solution, but it is capable of dealing with any > amount of traffic and it would be a very useful filter to start pulling > out potentially interesting stuff. The problem is that you have a game of cat and mouse with what amounts to an infinite supply of mice. It takes cooperation between the source and the provider networks. The "eyeball" heavy networks need to ensure they can't source bogus traffic. Having gear these days where the ACLs are in hardware has greatly reduced the CPU expense of filtering on edge ports but the human resource expense of maintaining those is still high unless automation is brought into the mix so that those filters are changed when the addresses served by a port change. > This stuff isn't *easy*. Fine. But it certainly *is* possible. Of course it isn't easy. It is designed to be difficult. But there is plenty of "low hanging fruit" out there still.
