Setting Timeout to 10 helped. Thanks for the tip!
Hope a permanent solution to this will be found soon.
Setting Timeout to 10 helped. Thanks for the tip!
Hope a permanent solution to this will be found soon.
Looks like phpbb again;
http://www.phpbb.com/phpBB/viewtopic.php?t=258892
That might be part of it but I have the modsec filter
SecFilterSelective ARG_highlight %2527
This filters out those sanity worm requests. Is that where all those ??...reading...?? enteries are comming from? The darn mod_security log in cpanel does not update in real time so I cant use that to see the mod_security enteries in real time.
The particular account I am seeing under attack on the one server is running VB. Albeit they recently updated from an outdated phpbb.
In addition in my case when I grep the IP's I see in the error log in the /usr/apache/domlogs/ file for the approrate domain I dont get a single entry. Again implying mod_security is getting it?
I was getting mostly "...reading..." requests too, and setting the timeout value to 30 lessened them, then lowering the keepalive connections to 10 and the keepalive timeout value to 10 pretty much put an end to my httpd load problems.
Plus, my upstream host is in the loop now, trying to filter this stuff out before it hits my box.
If you're having the problem, by all means let your hosting or bandwidth provider know about it, and point them to this thread so they can help all of their customers at once.
At least Servermatrix are aware of this problem and are trying to figure out how to stop it on their network.
Yes, that's my provider. Gotta love those guys.
Ironically, they opened a new security center today. So they should have the staff on hand to get this taken care of. I hardly notice any symptoms of this attack already (although I say this with a whisper so my server doesn't hear me and crash).
I'm with servermatrix so I'm really happy to hear that they are working on this.
I have a question, though - my server is getting slammed with this problem, and apache is constantly overloading then dying, requiring restart. As a precautionary measure, I suspended (from whm) all the accounts that run a phpbb installation. There are 3 such accounts. I also suspended a bunch of other domains as a diagnostic.
All of the domains on my server are mine, so I can get away with this. Surprisingly, it didn't affect the problem at all! Doesn't suspending an account prevent any attack of this type?
any advice appreciated!!
I am @ servermatrix as well...in a matter of fact they haven't solution yet, i got reply one hour ago, workaround is (so far) is to lower timeuots in httpd.conf as mentioned above on afected servers, and watch others....they assume that this is php worm of some kind. I had problems only on two boxes (complete rendom situation), after workarond, situation is allmost ok (still some reading requests, but only few, not hundreds).
Thats exactly what I experenced above. Suspending the account that the attack is directed toward does not stop the reading requests. If you look at your error log the enteries are then for /usr/local/apache/ instead of /home/username/public_html/Originally Posted by dhecker
So, is this really a phpbb problem? Or is it just attacking apache?
Looks like phpbbOriginally Posted by dhecker
http://www.webhostingtalk.com/showth...5&pagenumber=2![]()
So.... is there anything that can be done about this issue or do we just wait it out? I've got one server that has just been punished all day today with this nonsense.
PHP suEXEC support enabled in your apache build might be a good startOriginally Posted by 0utlier
![]()
This is a pretty interesting thread to read, especially the offsite links... I didn't realize how hard some folks are getting hit.![]()
phpsuexec would not help with this one. People that are getting hit are typically just getting hit with hundreds and hundreds of read quests to sites. Doesn't matter if they are running phpsuexec, mod_security or current phpBB applications. The reads are just going and overloading servers.
same thing here.... bringing down the timeout a bit seems to help.