From owner-freebsd-security Sun Sep 23 9:57:15 2001 Delivered-To: freebsd-security@freebsd.org Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by hub.freebsd.org (Postfix) with ESMTP id 80D2937B430 for ; Sun, 23 Sep 2001 09:57:09 -0700 (PDT) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.2) with SMTP id CAA10601; Mon, 24 Sep 2001 02:56:40 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 24 Sep 2001 02:56:40 +1000 (EST) From: Ian Smith To: David G Andersen Cc: Chris Byrnes , security@FreeBSD.ORG Subject: Re: New worm protection In-Reply-To: <200109230836.f8N8akx29012@faith.cs.utah.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 > #!/usr/bin/perl > sleep(5); > exit(0); > 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