Here's another version:
http://www.rubylane.com/public/nimda.tcl.txt
This adds a 60-second delay before the redirect and has a maximum # of
connections that will be "held up" on your server. I have our server
set to hold up to 10 attackers. Once this limit is exceeded the
redirect is issued immediately to subsequent attackers.
The attack code isn't multi-threaded: if you delay it, it doesn't issue
subsequent requests until you release it.
Jim
>
> The web server will respond with some amount of traffic. I'd imagine the
> 302 redirect response would be shorter, overall, than a 404 response with
> a "not found" page--especially if the site has a custom 404 page.
>
> If the worm actually follows the redirect it will end up talking to itself
> and, hence, won't generate any additional Internet traffic.
>
> I am using:
>
> ns_register_proc GET /*.exe nimda_worm
> ns_register_proc POST /*.exe nimda_worm
> ns_register_proc HEAD /*.exe nimda_worm
>
> proc nimda_worm {} {
> set ip [ns_conn peeraddr]
> set url http://$ip/[ns_conn url]?[ns_conn query]
> ns_log warning "Probable Nimda Worm Detected from $ip, redirecting to $url"
> ns_returnredirect $url
> }
>
> On Tue, 18 Sep 2001, Chuck Kimber wrote:
>
> > The problem with doing this is that this thing is already causing DoS
> > symptoms on the internet due to the massive amount of traffic it is causing.
> > Returning it will only double network traffic. Are you sure you want to add
> > to the problem?
>
