I wouild block them using "IP Deny Manager" from my cpanel and let it write the values into my .htaccess file.

Thanx EdB - got me looking in the right direction. The large variety of ip's that are GET'ing that blog from my site makes me want to find the base ip / range - which I can do, manually. An ARIN or APNIC lookup provides the allocation range - and I'm fine denying service to every domain there.

It would be nice to have this automated - a search of the log file, extraction of the ip, optional lookup of the ip range, and generation / update of the htaccess file. I know it would block legit accesses, so I'd probably want to see the domain name and decide whether or not to block it.

Other ideas???

Maybe you should ask your host.

I've had the same problem, my blog has been (partly) down for one day after extremely many hits to the commentpost-file. My host took a look and then blocked several IP-ranges that are known for their spam-activities and I haven't had problems since then.

Yes, I tried it all

I removed the one blog that the repeated GET is referring to...
I moved the directory so the attacker's url wouldn't resolve to a known file.
I implemented .htaccess deny for the most frequent accessing ip addresses, both fully resolved and with a range specification.

When I tried to access the blog in question, I can't see it. So each of my changes works.

And still, my apache server log indicates that various ip addresses are sending a GET request, about one every ten seconds. Something out there is continuously executing the GET request and doesn't seem to want to stop.

GET /blog/index.php?blog=5&disp=comments HTTP/1.0

At least my system is no longer being choked and brought to its knees (the blog isn't accessed and therefore there isn't a mysql query, etc). But the system does spend cycles replying.

Any idea how to get the requests to stop?

Ask whoever is doing it to stop?

Hi EdB,

I don't know who it is. That's the problem. I can't even tell what network it is coming from because there are many, many ip addresses that are being reported.

Here are the deny lines that I've added so far: (I don't mind the over deny impact - I'm trying to quiet the system down...)

deny from 60.0.0.0/8
deny from 67.0.0.0/7
deny from 72.0.0.0/8
deny from 124.0.0.0/7
deny from 202.0.0.0/7
deny from 210.0.0.0/7
deny from 218.0.0.0/8
deny from 219.0.0.0/8

I did have another idea - I've added a robots.txt entry to disallow access to the blog. I think that an automated system might be at fault and perhaps the robots.txt can keep it from trying the blog directory.

um... I was kidding. You're not going to stop the hits from being made. All you can do is minimze the load they place on your server. blocking via .htaccess is one. AFAIK robots.txt would be a waste of time because (a) you're already blocking them via .htaccess they'll never have a chance to see your robots.txt file and (b) the only time that does any good is if the visit is from a robot that respects the instructions in the file.

In short: you can NOT stop the requests from being made unless you can actually get someone to stop doing it. Obviously that's not going to happen, so you have to try to stop the effort from providing them any value.

The exact same "attack" is occurring on two other of my b2evolution blog sites. A variety of IP addresses are "GET" reading the same blog URL - over and over and over again. This is an attack to the extent that a GET operation puts a load on the web server and the mysql database - when the attacks occur frequently, the web sites on the web server begin to timeout (fail) for all other visitor requests.

I effectively prevented any detrimental impact to the initial site under attack and I can propagate the same prevention measures to these (and all my other) b2evolution blogs. OK there...

But I wonder - Am I the ONLY one seeing this? If so, I wonder why. If not, I would like the b2evolution folks to be aware and to see what they can do to prevent it.

Here is an APACHE server-status log piece to show you what it looks like. Notice that the URL for the GET is the same for a given blog host. Sometimes I've seen the log "full" with these GETs.

Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
2-4 - 0/0/77378 . 15.06 5475 0 0.0 0.00 663.44 200.121.45.42 therhumb.com GET /blog/index.php?blog=5&disp=comments HTTP/1.0
11-4 - 0/0/20829 . 13.05 5568 0 0.0 0.00 178.64 189.137.35.76 therhumb.com GET /blog/index.php?blog=5&disp=comments HTTP/1.0
21-4 - 0/0/8953 . 13.20 5512 0 0.0 0.00 71.13 189.137.35.76 therhumb.com GET /blog/index.php?blog=5&disp=comments HTTP/1.0
23-4 - 0/0/8895 . 12.73 5578 0 0.0 0.00 73.64 217.153.73.70 therhumb.com GET /blog/index.php?blog=5&disp=comments HTTP/1.0
9-4 5156 0/869/22204 _ 18.19 0 0 0.0 5.25 185.90 86.122.65.100 filmnewsandviews.com GET /blog/index.php?blog=2&disp=comments HTTP/1.0
4-4 - 0/0/74485 . 14.05 5576 0 0.0 0.00 625.52 41.248.17.1 filmnewsandviews.com GET /blog/index.php?blog=2&disp=comments HTTP/1.0
7-4 - 0/0/44973 . 12.48 5448 0 0.0 0.00 376.89 41.248.17.1 mavensworld.com GET /blog/index.php?blog=4&disp=comments HTTP/1.0
12-4 - 0/0/13533 . 12.22 5566 0 0.0 0.00 111.00 61.6.192.33 mavensworld.com GET /blog/index.php?blog=4&disp=comments HTTP/1.0
15-4 - 0/0/11485 . 12.06 5575 0 0.0 0.00 97.27 41.248.17.1 mavensworld.com GET /blog/index.php?blog=4&disp=comments HTTP/1.0
16-4 - 0/0/11381 . 13.62 5589 0 0.0 0.00 95.63 41.248.17.1 mavensworld.com GET /blog/index.php?blog=4&disp=comments HTTP/1.0
18-4 - 0/0/9431 . 12.33 5574 0 0.0 0.00 80.59 195.229.242.84 mavensworld.com GET /blog/index.php?blog=4&disp=comments HTTP/1.1
20-4 10134 0/875/10248 _ 16.60 0 0 0.0 5.86 79.17 86.122.65.100 mavensworld.com GET /blog/index.php?blog=4&disp=comments HTTP/1.0

while I feel your pain, these sorts of attacks arent something that the devs can really do anything about. If it were there would be some magical panathea to all things spam, and there simply isnt.

If you are running your own server, and using nix/apache there is an apache module called mod_dosevasive that will throttle a fair amount of those repeated requests.

http://www.google.com/search?hl=en&q=mod_dosevasive&btnG=Google+Search

Unfortunately, or fortunately, depending on who you are, this isnt a b2evolution specific problem -- it's part and parcel of having an online presence anymore.

Thanks Whoo,

It does seem to me that the developers could implement some throttling controls. It would be something that watches for repeated GET accesses and contains a frequency limit perhaps even per "blacklisted" IP address.

The slowness to the system is a function of the way that b2evolution code accesses the mysql server. Perhaps the throttling controls should be there anyway. As it is working now, the software relies on the outside world to manage its use of system resources and, alas as you say, there really isn't any way to control spammers.

I don't know if there's a mysql server setting that might have a throttling effect too.

Thanks for the apache mod reference - I'll see if that'll work in my system.

Every one of my servers running b2evolution code have been attacked with the same repeated, unthrottled, unending access. Even blogs that did not have other activity were found. I imagine it is a spider searching for b2evolution installations. I have renamed from the standard installation naming scheme (was it my idea after all to call it /blog?) - and the attacks do seem to subside (days and days after I make the changes).

Throttling would be a nice feature - as would the obfscating of the directory into which the software is installed.

BrianBatson wrote:

Every one of my servers running b2evolution code have been attacked with the same repeated, unthrottled, unending access. Even blogs that did not have other activity were found. I imagine it is a spider searching for b2evolution installations. I have renamed from the standard installation naming scheme (was it my idea after all to call it /blog?) - and the attacks do seem to subside (days and days after I make the changes).

Throttling would be a nice feature - as would the obfscating of the directory into which the software is installed.

In short, obsfucating the install directory can be accomplished using mod_rewrite.

Looking for solutions to these sorts of things at the application level are going to result in repeated disappoints for you, I am sorry to say.

Think about this, even with a "throttling" feature built in, an application using it, still has to process whatever code is used to throttle. In other words, apache still works to process the hit, and so does the blog software - regardless of whats used.

As for the spider remark, a look at your Apache logs would save you from imagining what it is. You've pasted IPs so you've obviously looked some; Apache logs provide UAs, and referers, additionally, and such a spider would come with a distinct referer, I assure you.

. As it is working now, the software relies on the outside world to manage its use of system resources

Thats fairly normal. If you have success finding a blog application that doesn't leave this sort of footwork to Apache, feel free to share.

I'll give you an unsolicited insight. I use another well-known blog application. I assure you it behaves no differently.

Im not making excuses, im making allowances and just stating things the way they are. These are things that ought to be adressed at the server level, NOT the end-user application level.