Date: Mon, 24 Sep 2001 02:56:40 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: David G Andersen <danderse@cs.utah.edu> Cc: Chris Byrnes <chris@JEAH.net>, security@FreeBSD.ORG Subject: Re: New worm protection Message-ID: <Pine.BSF.3.96.1010924022816.9322B-100000@gaia.nimnet.asn.au> In-Reply-To: <200109230836.f8N8akx29012@faith.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > <EOF> > > cat > DOCROOT/scripts/nph-foo.cgi > #!/usr/bin/perl > sleep(5); > exit(0); > <EOF> 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 (?) Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1010924022816.9322B-100000>