On Sun, 23 Sep 2001, David G Andersen wrote:
> Lo and behold, Chris Byrnes once said:
> > Has anyone written an easy-to-use ipfw rule or some kind of script
> > that will help with this new worm?
> Someone already pointed out disabling logging on your webserver.
Not an option here, but it's the large number of entries in *-error.log
that I'd like to be rid of. *-access.log I can just grep out before log
analysis, if not exclude in the analyser config.
> He also suggested a Tarpit-like approach. I like the following
> simple script, which is what I run on my webservers.
> mkdir DOCROOT/scripts
> # Cover the two alternate bits as well
> ln -s DOCROOT/scripts DOCROOT/_mem_bin
> ln -s DOCROOT/scripts DOCROOT/_vti_bin
> cat > DOCROOT/scripts/.htaccess
> ErrorDocument 404 /scripts/nph-foo.cgi
> cat > DOCROOT/scripts/nph-foo.cgi
Cute. Will play. However there are other directories too; dumping
ANY request containing cmd.exe or root.exe would do it best here.
> NIMDA doesn't hang out for very long waiting for a response
> to the script headers, so a labrea-tarpit like approach won't
> actually be particularly effective. The sleep(5) will slow
> it down a little bit, and the exit(0) will make it
> return with no data sent back, not even a 404. Which
But does *error.log still get hit? I dealt with /default.ida by giving
'em a one-line one, which at least meant no error logging while reducing
response traffic by two thirds, but poring through apache docs - which I
must be too thick to find easy reading, looking for some way to provide
some short but valid response to such a range of URLs, I've not yet been
able to nut out. Any suggestions?
> will help a bit on the outbound bandwidth, but, of course
> won't help on the inbound. Others have posted scripts to
> NANOG (see http://www.nanog.org/ and check the archive)
> that will automatically trigger ipfw / ipchains additions,
> but, as always, be particularly careful with those.
Will have a look at these, however carpet bombing whole /24s for the not
even deliberate misdeeds of a few (ok, plenty of) unpatched m$junk seems
rather an overreaction <&^}=
The other thing here (ie in 203/8) is the large number of unsuccessful
DNS requests for reverse mapping of particularly North Asian addresses,
often ending with Server Failures and such - but I guess misconfigured
DNS is no more surprising than zillions of compromised webservers ..
I'd love to find some way of pre-filtering these NIMDA requests and just
dropping them on the floor before apache even considered DNS lookups (?)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message