Re: outgoing DDoS - request for comment :-)

[Valdis Kletnieks <Valdis.Kletnieks () VT EDU>]

On Tue, 07 Jun 2005 21:22:08 +0200, Sebastian Proba said:

> (some border security system). It seems to be impossible because it
> is almost impossible to get - for example - many ISP interested in
> identifying and blocking traffic which is outgoing DoS attack. But
> there may exist some ways to achieve that kind of cooperation in the
> Internet.

Yes.  Such ways may exist.  If you actually trip over one and stub your
toe in the course of your travels, please let me know.  Nobody's come up
with an actually workable solution yet.

There's multiple factors working against us here:

1) There's a *LOT* of zombied systems out there.  Possibly over 100M of them.
We're *finding* 30K new ones a day - that's close to a million new ones a month
that are *spotted*.  The ones flying under the radar, or which simply manage to
not poke a "sensor system" at a clued site aren't counted.  A recent trend has
been "botnets to order" - rather than let the botnet keep growing and get
discovered, the person creating the net makes it stop growing once it reaches
5K or 10K or whatever number of hosts is needed - which makes them a lot harder
to spot.

2) The vast majority of these zombies are owned by people who have absolutely
zero clue.  This ends up working against us every step of the way.  One large
hidden gotcha at this point is that it's very difficult for the ISP to do anything
effective - Anything the ISP does has to be usable by Joe Sixpack and a
point-n-drool interface.

3) Most of these people go for low-price, no-frills providers.  There's really
little margin to be had at $19.95/mo, so the ISPs competing in that market are
usually unable to do much about actually finding and fixing systems.  AOL's recent
move to include free A/V software is a step in the right direction - but it only
happened because AOL found it cheaper to buy 60M licenses of the A/V product than
deal with 60M worm-infested customers.

3a) The ISP usually can't afford to send out a live body to clean a machine
(unless it's an ISP that's marketing total-support service, not low-cost).  They
can't even afford to talk somebody through it over the phone.  And unlike the
EDU domain, where we can say "Tough noogies, your port stays off till you clean
your computer" to a captive audience, the average ISP knows that all *that* will
do is send the infected computer and the $19.95/mo to a competitor.

4) The same low-frills providers usually don't do sane ingress filtering, which
means that spoofed packets are still a problem.

5) It's usually *very* hard to tell at the *source* end if a given outbound
packet is part of a DDoS or totally legitimate traffic.  For that matter, it's
often hard to tell legitimate traffic from a DDoS (think "slashdotted").  As a
result, identifying the source machines has to be done fairly close to the
target, network-wise (there are BGP community tricks you can play to push a
block of an already identified source back upstream, but that's a separate issue).

6) Quite often, the victim is a customer of one provider, the source is a
customer of another provider - and there's no direct business relationship
between the two.  So let's trace it through:

a) Packet leaves the source machine - we can't stop it here, because if the
owner of the machine had enough clue to stop it, they'd probably not have
gotten infected yet.

b) Packet traverses the $19.95/mo provider's network.  They won't stop it,
because they probably don't have a functional abuse () cheap-isps-r-us com desk.

c) Packet goes over 1 or more large long-haul providers.  They won't stop it,
because (a) it's a piddling fraction of their OC192 pipe and (b) they're billing
cheap-isps-r-us for transit by the megabyte *anyhow*....

d) Packets all converge at the victim's provider.  But by then it's too late....

7) It's a lot harder than it looks to make a secure distributed scheme to disable
the source computers - most schemes don't have a good way to stop a malicious
attacker from blowing you out of the water by saying your webserver is sending
lots of traffic to lots of places....... ;)

Attachment: _bin
Description: