[21692] in bugtraq
RE: Mitigating some of the effects of the Code Red worm
daemon@ATHENA.MIT.EDU (Tony Langdon)
Fri Jul 20 00:38:36 2001
Message-ID: <B17EB7B34580D311BE38525405DF62324B60BD@atc-mail-db.atctraining.com.au>
From: Tony Langdon <tlangdon@atctraining.com.au>
To: "'LARD BENJAMIN LEE'" <Benjamin.Lard@Colorado.EDU>,
BUGTRAQ <BUGTRAQ@securityfocus.com>
Date: Fri, 20 Jul 2001 11:01:04 +1000
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1252"
> I'm not sure of the ethical or legal aspects of this, but I
> don't see why
> we can't take advantage of three facts:
>
> 1) There is something of an ongoing log of affected machines
> that can be
> obtained from boxes earlier in the IP list.
> 2) Machines which have been compromised can STILL be compromised.
> 3) The worm has a "lysine deficiency" which can be remotely
> introduced.
I'd say legally, you're on very shaky ground. Not something I'd attempt,
for that reason alone. What if a bug in your "friendly worm" trashed
someone's server or DOS'd them at a critical moment? I think the lawyers
would be onto that one.
A "safer" approach would be to have something that could do a whois lookup
of the attacking netblocks and prepare a scripted email for you to review
before aending.
Besides patching the IIS server when the original advisory came out, I have
also taken the steps of heavily filtering outbound traffic from the IIS box
(stuff that should never be generated in normal use), and logging that, so I
can be aware of anything suspicious, severely limit the abilitiy of any worm
to infect other systems and minimise the risk of being involved in a DDOS
attack (except perhaps against myself, but that's my problem! :) ).
