Date: Mon, 25 Sep 2000 11:32:32 -0400 From: "Matthew Emmerton" <matt@gsicomp.on.ca> To: "Troy Settle" <troy@psknet.com>, <treif1@netaxs.com>, <freebsd-questions@FreeBSD.ORG> Subject: Re: tarpitting bad HTTP requests (WAS: RE: question) Message-ID: <004801c02705$d3767750$1200a8c0@gsicomp.on.ca> References: <BFEGKDHLHDNOJEIHJDBACECFCAAA.troy@psknet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?004801c02705$d3767750$1200a8c0>