This is a discussion on PHP Denial of service within the PHP General forums, part of the PHP Programming Forums category; # ryan@rbftpnetworks.com / 2006-10-13 22:16:18 +0100: > A simple question I imagine, but I am wondering ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
# ryan@rbftpnetworks.com / 2006-10-13 22:16:18 +0100:
> A simple question I imagine, but I am wondering how I would combat DoS > attacks by users holding the REFRESH key on their browsers? > > I have reproduced this error on a PHP-MYSQL website and when I hold the > REFRESH key on for a while, page gen times shoot up dramatically and > hundreds of processes are created. > > Is there a way I can stop this/limit the connections/processes in apache > conf/php.ini? > > What can I do to combat this method of DoS? I haven't tried it, but perhaps this would work: apache-1.3: http://dominia.org/djao/limitipconn.html apache-2.0: http://dominia.org/djao/limitipconn2.html -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 |
|
|||
|
On Oct 14, 2006, at 4:05 AM, Ryan Barclay wrote: > It hasn't actually been attempted. However, if a couple of a users > were to hold the refresh, the page generation times would go up > ridiculously and clients would be waiting over 20sec for pages. As > mentioned, it's a very heavy php-mysql script with lots of queries. I see what you're talking about. Does everyone need live data for each page request? It seems like a great opportunity for data / page caching. I'm trying to remember the name of the caching tool I used, but I ran into something similar on one of my websites a few years ago. Each page was dynamic and the server load was high. I installed caching and pages would only update occasionally... meaning that users received pages from the cache, instead of each page getting processed with each request. You could also try a reverse proxy with apache to do something similar. The limit IP stuff from Roman also looks interesting. -Ed |
|
|||
|
On Fri, October 13, 2006 4:16 pm, Ryan Barclay wrote:
> A simple question I imagine, but I am wondering how I would combat DoS > attacks by users holding the REFRESH key on their browsers? > > I have reproduced this error on a PHP-MYSQL website and when I hold > the > REFRESH key on for a while, page gen times shoot up dramatically and > hundreds of processes are created. > > Is there a way I can stop this/limit the connections/processes in > apache > conf/php.ini? > > What can I do to combat this method of DoS? Well, one thing for sure... This question would be better addressed to Apache list. To stay on topic, however, you could log each action the user takes, and if they are "too fast" you can put a "sleep" call into your PHP scripts. This will only stop the user from doing what you did, not from a more generalized DoS attack using something (slightly) more sophisticated than the "refresh" button. So trying to solve this at the PHP level is most likely a Wrong Approach. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? |
|
|||
|
On 10/14/06, Ryan Barclay <ryan@rbftpnetworks.com> wrote:
> It hasn't actually been attempted. However, if a couple of a users were > to hold the refresh, the page generation times would go up ridiculously > and clients would be waiting over 20sec for pages. As mentioned, it's a > very heavy php-mysql script with lots of queries. A few questions: #1: are those queries optimized (using indexes where needed)? #2: is the code optimized.. no stupid loops. #3: in order for php to know a user aborted it has to try to output something (at least with apache on unix) to deal with #3, i used to do a little trick: <?php // some standard things like <html><head>.... ?><?php // do intensive stuff ?> I dont know if that ?><?php trick still works but it used to force php to talk to apache and if apache said: oh you know what.. there isn't a connection so a user aborted request will exist, or if it is set to ignore user aborts, connection_aborted() will report true. Curt. |
|
|||
|
On 10/16/06, Richard Lynch <ceo@l-i-e.com> wrote:
> On Fri, October 13, 2006 4:16 pm, Ryan Barclay wrote: > > A simple question I imagine, but I am wondering how I would combat DoS > > attacks by users holding the REFRESH key on their browsers? > > > > I have reproduced this error on a PHP-MYSQL website and when I hold > > the > > REFRESH key on for a while, page gen times shoot up dramatically and > > hundreds of processes are created. > > > > Is there a way I can stop this/limit the connections/processes in > > apache > > conf/php.ini? > > > > What can I do to combat this method of DoS? > > Well, one thing for sure... > > This question would be better addressed to Apache list. > > To stay on topic, however, you could log each action the user takes, > and if they are "too fast" you can put a "sleep" call into your PHP > scripts. ouch.. mabey a usleep() but that is a bad way to deal with things. [getting off topic] that just makes it so you get all those requests and apache grows closer to max_connections as ^R is hit. [Back on topic or close] if ^R forces the system to freeze up there is something wrong somewhere. For Starters... I doubt you can hit ^R, or your client will allow ^R 200 times a second.. and i know of systems that can handle 200 requests per second that use a db connection via php without the server load going over 1.0. At this point i think it is the magic eight ball that can only solve this solution.. there are to many unknowns to really know what the issue is. > > This will only stop the user from doing what you did, not from a more > generalized DoS attack using something (slightly) more sophisticated > than the "refresh" button. Yeah like requesting from multiple machines all at the same time multiple times. or would that be considered a DDoS? if memory serves me right, DoS is usually network flooding related vs trying to flood processes handling. > > So trying to solve this at the PHP level is most likely a Wrong Approach. For true DoS, yeah very wrong place. i sort of have a feeling that code/db/apache optimizations could occur before even considering DoS things. Curt. |