Date: Mon, 25 Sep 2000 13:55:26 -0400 (EDT) From: Matthew Emmerton <matt@gsicomp.on.ca> To: treif1@netaxs.com Cc: matt@gsicomp.on.ca, questions@freebsd.org, net@freebsd.org Subject: Re: tarpitting bad HTTP requests (WAS: RE: question) Message-ID: <Pine.BSF.3.96.1000925133428.79296A-100000@xena.gsicomp.on.ca> In-Reply-To: <39CF7542.9795E517@reif.cncdsl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ crossposting to freebsd-net since this concerns TCP connection limiting ] On Mon, 25 Sep 2000, webmaster wrote: > Well, thats just it. > I'm thinking if I can slow down the attacks then have the > perl program wite a redirect to the htaccess it will save > resources. In other words, I have a random mix of proxy > servers and script kiddies hitting this server. > All of them are on very fast connections and sometimes > will hit the server 30,000 times each before the software > can redirect them. If I can find a way to slow the attacks > the perl program can then execute and redirect without using > up all these resources or generating thousands of logs. There are really two issues to this problem: - how to detect people who are flooding the server - how to handle those who are. If there is some type of distinct pattern of URLs that originate from a single host, then that can be captured. However, I doubt this so the only resort is to have some sort of threshold on the number of times a single client can connect to the server during a specific timeframe. Although this could be implemented in the web server, there are problems: - the threshold would have to be keyed to the website so that sites that legally go out and pick up the HTML, then send out n parallel requests (one for each graphic) won't be restricted. - the information on clients would have to be shared across all server instances, as people hammering the server will most likely have requested processed by all instances The better place to implement this kind of 'bandwidth control' would be at the kernel or network level, similar to how ICMP flooding is handled. Does anyone know of a way to control TCP flooding for servers that don't run from inetd and serve multiple client requests from one instance? (These two conditions are limitations of tcpwrappers) THe "how to control those who are" would be a user-defined hook, provided that it could be triggered by some sort (log message, for example) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" 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.1000925133428.79296A-100000>