Code Red 2 Erratication

Joe Blanchard jblanchard at wyse.com
Sun Aug 19 09:49:05 UTC 2001


Who was/is talking about a DOS??? I wasn't. Your impling that my fix (which
doesn't work and I've gotten many responses about having "tried that")
causes a DOS. Um, Please re-evaluate the data I have shared. There is
NOTHING I have offered that is not already known. You come to my website,
ask for a file (default.ida) and I send it to you, Wheres the DOS in that? 
Legal or not, Um, next case... 



-----Original Message-----
From: Christian Kuhtz [mailto:ck at arch.bellsouth.net]
Sent: Sunday, August 19, 2001 2:34 AM
To: Joe Blanchard
Subject: Re: Code Red 2 Erratication


On Sun, Aug 19, 2001 at 02:02:10AM -0700, Joe Blanchard wrote:
> With regard to the legality of sending back such packets I have to laff,
and
> hard at this. Your certainly under some misguided Idea that the laws have
> actually any presidense in this case, that is regarding sending back
packets
> to an attacking party that kills their OS. 

The infected host is not what matters, and none of my recent statements have

been about 'killing somebody's OS' if you read them carefully. 

As I tried to explain to you before, hypothetically speaking, if you happen
to 
take out, say, a DSL cloud (if you had a larger pipe or used different
method 
of responding to the probe which wasn't as bw intensive and caused greater 
damage proportional to bw used), perhaps take the ATM cloud out with it 
because of, for instance, massive demand for bw.. you're in essence 
enacting a DoS and are subject to the same sort of procedures with which DoS

are responded to.  I'm amazed your providers aren't taking the same steps 
with your current problem.  Further, if perhaps you end up taking out vital 
national infrastructure with your attack you will end up facing the 
consequences (remember, some of the ckts used for inet traffic share
resources
with the rest of the world).  A DoS in response to a DoS can also lead to
your
networks being cut off from the rest of the world as well.  Significant 
backlash in various colors is not far fetched at all.

These scenarios have been discussed quite frequently in various forums as
well
as in various legal departments, and depending on the circumstances there
are 
legal issues you might want to consider.  You might want to consult those in

your legal department with background in telecommunications litigation.  Go 
ahead, test the legal system.  I am not making this up.  It's your choice,
not
mine.

I am trying to share information with you in the hope that it may help you
understand the shortcomings of your approach and perhaps helps you find a 
better solution.

It may be worthwhile to take up the typical emergency response procedures
and
do things like summarize the ip addrs of the offending hosts with individual

date/timestamps and submit them to providers with the remark that they are 
causing a DoS on your network.  The fact that your direct providers aren't 
willing to help you as the customer is very regrettable.  You might also
have 
angles by engaging your legal department depending on what sort of contracts
you have with your provider(s).  Contesting the billing sometimes gets a
provider's attention.  I don't see why escalating thru your provider up the
food chain doesn't get you results.  The reply that it is 'too difficult'
most certainly doesn't ring true in this matter.

I don't speak for or represent BellSouth. The Security & Abuse team @ 
BellSouth.net can be reached at abuse at bellsouth.net and in general that
should
be your primary point of contact if you have issues with BellSouth.net 
customers.  If you have any problems with BellSouth.net responding to your 
requests feel free to contact me and perhaps I can help with the escalation.


If you have any other questions, send them on.

-- 
Christian Kuhtz <ck at arch.bellsouth.net> -wk, <ck at gnu.org> -hm
Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S.
I speak for myself only."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20010819/2ea6c67f/attachment.html>


More information about the NANOG mailing list