Skip site navigation (1)Skip section navigation (2)
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>