[149518] in North American Network Operators' Group
RE: UDP port 80 DDoS attack
daemon@ATHENA.MIT.EDU (George Bonser)
Tue Feb 7 13:06:19 2012
From: George Bonser <gbonser@seven.com>
To: Joe Greco <jgreco@ns.sol.net>
Date: Tue, 7 Feb 2012 18:05:03 +0000
In-Reply-To: <201202071428.q17ESPLA083237@aurora.sol.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> 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.=20
I think one of the problems is that with modern bot-nets, traffic can be ge=
nerated by a huge number of hosts and assuming your DoS traffic is coming f=
rom 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 o=
nly 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 th=
e source IP of the traffic is really where it is coming from since there ar=
e still a good number of providers out there who don't install packet filte=
rs on their customer links. They accept any traffic their customer sends t=
hem even if the source IP isn't within the customer's network range. So th=
at 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 so=
urce network, as soon as you block those source addresses, the DoS has succ=
eeded.
> And you probably don't want to use just this one technique,
> you want to combine it with others. =20
I think "probably" is the wrong word here. The word "certainly" leaps to m=
ind.
> 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 a=
n 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 hardwa=
re has greatly reduced the CPU expense of filtering on edge ports but the h=
uman resource expense of maintaining those is still high unless automation =
is brought into the mix so that those filters are changed when the addresse=
s 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 ple=
nty of "low hanging fruit" out there still.
