|
Posted by on June 23, 2008, 6:03 pm
If you were Registered and logged in, you could reply and use other advanced thread options > Hello all, first quickly I'm sorry if this is the wrong place, but it
> seemed the most appropriate usenet group.
>
> My server is currently receiving a barrage of requests straight for
> the largest files (videos) on my web server, which was causing the
> server to become dreadfully slow to respond (at least a minute before
> it hints a response) and sometimes not even at all.
>
> This is the 3rd day it's been going on.
>
> I've been keeping track of stats from the bots for the last 16
> hours...
> - Requests were from 845 different IP addresses
> - Nearly all the IP addresses are from China
> - 30,377 requests for video files (not the video pages)
> - 40 distinct video files were requested
> - One host made 13,000 requests within those 40 files.
>
Since the same IP requests the file a bunch of times, maybe
you could put a CGI interface infront of the file instead of
serving the file directly then log the IPs in a database with
a time stamp (or use the webserver logs or whatever) to
see if multiple requests have been made in a short period of
time. If the same IP is requesting it over and over again
while true
do
sleep 1
transmit byte
done
Transmit the file really slowly so that the connection
stays active, but does not use up your bandwidth.
You could also check the referer in the CGI and block
anything which does not have a referer page at least
from the same domain.
There is probably a way to do a better job with a
rate limiting firewall rule. Maybe spamd on OpenBSD
perhaps?
iptables has a rate limiting option
limit
This module matches at a limited rate using a token bucket
filter. A
rule using this extension will match until this limit is
reached
(unless the =91!=92 flag is used). It can be used in combination
with the
LOG target to give limited logging, for example.
--limit rate
Maximum average matching rate: specified as a number,
with an
optional =91/second=92, =91/minute=92, =91/hour=92, or =91/d=
ay=92
suffix; the
default is 3/hour.
--limit-burst number
Maximum initial number of packets to match: this
number gets
recharged by one every time the limit specified above
is not
reached, up to this number; the default is 5.
Maybe you could create a rule limiting the average rate and the burst
rate for these subnets. That way they can still connect but only
use a fraction of your bandwidth.
> I'm running a dedicated server.
>
> I've had a few similar "attacks" (or algorithm malfunction?) in the
> past, but it was only by 3 or 4 different IP addresses and so it was
> easy enough to just block them using iptables.
>
> The only way I'm able to block the current "attack" and get these
> stats is that for some reason they all have the same referer:http://www.1=
73la.cn/u/egao/-- which I don't know about you but it
> doesn't even seem like a real website to me.
>
> If the requests didn't have this referer, I would not have a way to
> block these requests and my server would be beaten to a pulp. Right
> now I'm redirecting any request with that referer to my logger script.
>
> Any ideas of a better way to solve this once and for all? I'm
> passively blocking them, but they are still trying to jam the same
> requests down my server's throat. And I'm afraid that they'll get rid
> of the referer if I try any sort of active block rather than my
> passive method, and I'll be screwed.
>
> The IP addresses also seem to be from several different hosts (judging
> from the whois data), so it's not exactly easy to inform them all...
>
> An example of one of the bots from the access_log:
> 211.139.255.10 - - [06/May/2008:22:45:31 -0400] "GET /videos/content/
> 439_poppy2606.wmv HTTP/1.1" 403 317 "http://www.173la.cn/u/egao/"
> "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; )"
> (Notice it's 403 because I'm blocking them myself)
>
> Any tips at all?
>
> Thanks in advance!!
> - Richard
----
http://www.1150riverviewdr.com/
| 
XML site map