From owner-freebsd-questions Mon Sep 25 8:33: 7 2000 Delivered-To: freebsd-questions@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.42.130.87]) by hub.freebsd.org (Postfix) with ESMTP id 5014837B43C for ; Mon, 25 Sep 2000 08:33:01 -0700 (PDT) Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.10.1/8.9.2) with SMTP id e8PFWqs79140; Mon, 25 Sep 2000 11:32:53 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <004801c02705$d3767750$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Troy Settle" , , References: Subject: Re: tarpitting bad HTTP requests (WAS: RE: question) Date: Mon, 25 Sep 2000 11:32:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've not tested this myself, but you might have good luck with using the > ErrorDocument directive to redirect to either a cgi script or just your main > page. > > ErrorDocument 401 /index.html > or > ErrorDocuemnt 401 /cgi-bin/tarpit.pl > > If you opt for the cgi idea, you can then use a perl or other script to do > your tar pitting. But, before you make this effort, make sure that this > will do what you expect. I assume that you've actually examined the logs to > see that the /same/ host is sending several bad requests in rapid > succession? But wouldn't this just create a time-backlogged queue of requests to be sent out? (ie If someone hammers the webserver with 10 requests, and we do a base-2 backoff, then the responses for these 10 queries would be sent out at 1,2,4,...1024 seconds) This would mean that a zillion perl processess would be running and sleep()ing before they send out the responses, and by that time the client would have most likely gone away. If the /same/ host is sending several (unique) bad requests in rapid succession, it's probably a messed-up HTTP proxy attempting to do a mass update of its cache. Some proxy software doesn't properly recognize 404 responses (strange, but true). If you're using Apache, consider using some mod_rewrite rules to send back a 403 (Forbidden) or 405 (Gone) response, which the proxy may properly identify (meaning that it would remove it from its cache). If it's just a random client (check the User Agent string in your logs), consider writing a script to track your webserver's error logs for client attacks, and once one is found, then add a ipfw deny rule to refuse access from that client. -- Matthew Emmerton GSI Computer Services +1 (800) 217 5409 (Canada) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message