Identifying DoS sources quickly (was: Bogon list or Dshield.org type list)

As far as tracking DoS, I've read some good papers on the subject and it
always boils down to tracking MAC addresses and going interface by
interface to the source, demanding inter-ISP cooperation, and finally
legal assistance. This has been tried during a few severe instances with
poor results.

That's the obvious solution to the problem if the problem is how to track
down the source(s) of a DoS attack. However, in any DoS attack, there is
always a victim and one or more devices sending attack traffic to the
victim. The owners of the attacking devices are accessories to the crime
although I'm sure they could plead ignorance and avoid any liability. But
what if they could not plead ignorance? What if we could identify some of
the attacking devices, and what if the victim sent a legal "cease and
desist" letter to the owners of the attacking devices? Now, the victim is
in a position to sue the owners of these attacking devices if they don't
fix the problem by securing their machines. And once this happens and gets
some press coverage, a whole bunch of other machine owners will wake up
and realize that they could be stuck with big legal bills if they don't
secure their machines.

So, to restate the problem, how do we identify some of the sources of a
DoS attack quickly, maybe even while the attack is still in progress?

Bots/Zombies are traded openly on IRC and there is no
accountability for personal security. ISPs won't shut someone down
because they've been "hacked", merely send them a warning Email or
call--a process that takes days in my experience.

How many ISPs would identify the user of an IP address for the purposes of
sending a "cease and desist" letter when contacted by a lawyer?
Considering that failure to provide the identity would result in the ISP
themselves getting sued by the DoS victim? As long as *SOME* ISPs would
cooperate with a DoS victim, there is enough to get the legal ball
rolling. The alternative is to painfully backtrack until you find an
uncooperative ISP and then sure them.

As I said before, if there was a central registry something like
dshield.org that collected data on the destination IP addresses of DoS
attacks along with estimated magnitude based on analysing the traffic from
random source addresses blocked by ingress filters, then we have something
an ISP can use to analyze their outgoing traffic. If you are an ISP and
you have netflow data that contains destination addresses which also occur
in the DoS victim registry then you should be willing to act on that data.
Of course, it's up to you what you do with it. You may offer the DoS
victim the identity of the source provided that they serve you with the
right legal documents. Or you might go to the owner of the machine
yourself with the evidence and warn them that they are aiding and abetting
cyber terrorists and could suffer the legal consequences if they don't
secure their machines.

It's certainly not perfect but it's worth a try.

--Michael Dillon

How many ISPs would identify the user of an IP address for the purposes of
sending a "cease and desist" letter when contacted by a lawyer?

Despite 9/11, privacy still counts for something. It's rather dangerous
to give out private user information without a court order.

If one of our suscribers were involved in a DoS, we would deal with it
inernally, saving any records in the event of a court search warrant.

-Ralph

Not a complete solution but a start:
IP Source Tracker:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s21/ipst.htm

Available as of 12.0(22)S for 7500 and 12000 series Cisco routers.

-Hank

Hank Nussbacher wrote:

> So, to restate the problem, how do we identify some of the sources of a
> DoS attack quickly, maybe even while the attack is still in progress?

Not a complete solution but a start:
IP Source Tracker:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120
limit/120s/120s21/ipst.htm

Available as of 12.0(22)S for 7500 and 12000 series Cisco routers.

Hank,

one major flaw with this is that you can't track back further when you are
on an (ethernet based) IXP. IIRC older versions of IOS gave L2 information
(MAC address) as well which helped you to identify the last hop.

-- Arnold

Not a complete solution but a start:
IP Source Tracker:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120
limit/120s/120s21/ipst.htm

Available as of 12.0(22)S for 7500 and 12000 series Cisco routers.

ah yes. the new enterprise image. :frowning:

I wonder how the new pending RIAA legislation would change things, since
it proposes to totally shield the attackers from criminal penalties.

-Dan

## On 2002-07-30 08:23 -0700 Randy Bush typed:

>> Not a complete solution but a start:
>> IP Source Tracker:
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120
> limit/120s/120s21/ipst.htm
>> Available as of 12.0(22)S for 7500 and 12000 series Cisco routers.

ah yes. the new enterprise image. :frowning:

Am I missing the joke ?
AFAIK 12.0S only has the "service provider" feature set

AFAIK 12.0S only has the "service provider" feature set

i fear that the joke is on us. at least one other train seems to
have been merged into the ex-isp train. not sure how much. can't
get a straight answer. welcome back to 1997, and bye bye what
stability we had.

randy

It looks something like

                      12.0(21)S1----12.0(21)S2---- ... only for a limited time
                       /
---12.0(x)S-----12.0(21)S +---12.0(22)S----12.0(23)S---- ...
                             /
---12.0(x)ST----12.0(21)ST--+

So basicly 12.0(22)S is what would have been 12.0(22)ST if they hadn't
renumbered.

The "old" S train will be recieving bug fixes as 12.0(21)S1 S2 S3 etc.
for a limited period of time.

So be carefull when you go from 12.0(x)S, x <= 21 to 12.0(y)S, y > 21

/Jesper

## On 2002-07-31 10:09 +0200 Jesper Skriver typed:

There is a 12.2(x)S comming - as I understand it, it's a merge of
12.0(x)ST and the service provider related features in 12.2(x)T

/Jesper