Marian Hettwer wrote:
I tried the very same when a webserver of mine was hitted by some
botnet. Unluckily, cron can only ran every minute as the fastest
interval and within 1 minute I already had around 1000 connections from
different IP addresses.
Ergo: A one minute interval didn't help at all..
I had and time to time still have attack like this and put together a
series of effective measure to take care of this. Some I explain and put
together on misc@ under the title:
Feedback wanted on gethttpd graylisting ideas included
So you can search marc for:
http://marc.theaimsgroup.com/?t=115784713800001&r=1&w=2
I also posted a few more things, but it is possible to control that.
I added many more things as well and here if you have URL not use what
you can do is actually may be very simple and effective right away as
well using PF and redirect if the connections are from source that
either will redirect or not.
What I did for example for source that do not redirect, or follow the
standard. If you connect to let say a URL
a.b.c/test.html
and that test.html is a huge page that many bots actually love to attack
to make you waist bandwidth and put your server to a crawl. What I did
is simply to have that page send a redirect right away and then close
the connection. So, any valid users that access that page will be
redirected to the valid page and the bot will simply have it;s
connection close. So, yes you still process all the connection, but the
handling from the server is pretty small. Just a few bytes. Also, that
same connection is logs into SQL server that I query from cron and add
to PF each minutes. Yes I need to handle all the connections for that
minute like you said, but the traffic is very minimal and before you
know it, the source is block. Then I also have built my scripts to
refresh the block IP's with time out, meaning that I wanted to be nice
and the source IP's where block in incremental time each time they were
process. So, if the source go away and was from a valid proxy from AOL
for example, I wasn't going to loose the traffic for ever, but the
traffic for the time of the attack. And in the end, all the connections
that were following the redirect were process normally. That's because
DDoS bot attack so far call URL via GET and doesn't check for the return
code, so they were never going to the redirect new location and were
block later on.
Now for crawlers that follow bad URL or attack bad URL, you can here as
well put redirect to a different port.
Like a.b.c/follow.html would redirect to a.b.c:81/follow.html and then
you simply use PF to add right away all source trying to connect to
tcp/81 to your table and be done with them. That's also quick and simple
to do as well.
Anyway, that's just some idea that are fast efficient and proved to work
very well thank you.
I have more in place as well, ut if you do just these you will see light
at the end of the tunnel.
Best,
Daniel
