PHP Denial of service

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?

On Fri, 2006-10-13 at 22:16 +0100, 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?

Check if the following is enabled in php.ini

ignore_user_abort

Or in the code via:

ignore_user_abort()

Cheers,
Rob.
--
..------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

Robert,

Thanks for the reply. I can't seem to find ignore_user_abort in my
php.ini. I would like to do it at server level, rather than individual
scripts. Do you know roughly where is it? I think there were some
versions with this missing in the ini, which was later fixed.

I'm guessing that if ignore_user_abort is set to on, this could be the
culprit?

Would simply adding the following to the ini work?:

ignore_user_abort = off

Best,

Ryan

Robert Cummings wrote:
> On Fri, 2006-10-13 at 22:16 +0100, 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?
>
> Check if the following is enabled in php.ini
>
> ignore_user_abort
>
> Or in the code via:
>
> ignore_user_abort()
>
> Cheers,
> Rob.

Robert,

Thanks for the reply. I can't seem to find ignore_user_abort in my
php.ini. I would like to do it at server level, rather than individual
scripts. Do you know roughly where is it? I think there were some
versions with this missing in the ini, which was later fixed.

I'm guessing that if ignore_user_abort is set to on, this could be the
culprit?

Would simply adding the following to the ini work?:

ignore_user_abort = off

Best,

Ryan

--
Ryan Barclay

RBFTP Networks Ltd.

DDI: +44 (0)870 490 1870
WWW: http://www.rbftpnetworks.com
BBS: http://forums.rbftpnetworks.com



Robert Cummings wrote:
> On Fri, 2006-10-13 at 22:16 +0100, 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?
>>
>
> Check if the following is enabled in php.ini
>
> ignore_user_abort
>
> Or in the code via:
>
> ignore_user_abort()
>
> Cheers,
> Rob.
>

On Sat, 2006-10-14 at 01:25 +0100, Ryan Barclay wrote:
> Robert,
>
> Thanks for the reply. I can't seem to find ignore_user_abort in my
> php.ini. I would like to do it at server level, rather than individual
> scripts. Do you know roughly where is it? I think there were some
> versions with this missing in the ini, which was later fixed.
>
> I'm guessing that if ignore_user_abort is set to on, this could be the
> culprit?
>
> Would simply adding the following to the ini work?:
>
> ignore_user_abort = off

If it's not in your php.ini and not in your source code then it's
already off, unless it's being activated by an http.conf or .htaccess
setting. The default for ignore_user_abort is 0.

What exactly does your script do? It may be possible that whatever task
it is performing prevents PHP from immediately recognizing the user
abort and subsequently terminating.

Cheers,
Rob.
--
..------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

Ryan Barclay wrote:
> Thanks for the reply. I can't seem to find ignore_user_abort in my
> php.ini. I would like to do it at server level, rather than
> individual scripts. Do you know roughly where is it? I think there
> were some versions with this missing in the ini, which was later fixed.
>
> I'm guessing that if ignore_user_abort is set to on, this could be the
> culprit?
>
> Would simply adding the following to the ini work?
Ignore user abort defaults to off, and doesn't necessarily help you if
the clients don't terminate their connections properly, or they're
actually trying to DoS you. I think your best bet is to either use some
lightweight detection in PHP (and maybe send an HTTP error header if
you're getting hit), or better yet, use a firewall if one is available
to prevent the connections from even getting to your webserver and
wasting its resources. (If your server is running on Linux, iptables
should be able to do what you need, and there are more complicated
solutions too.)

jon

On Oct 13, 2006, at 2: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?

Apache.conf ThreadsPerChild?

> What can I do to combat this method of DoS?

How do you consider this a DoS attack? Are you seeing servers
crippled because a user or a couple of users keep hitting the refresh
key? Honestly, it seems extreme. Your server should be able to
handle much higher loads than that, especially when PHP starts
caching pages, etc.. I would start double checking the server
config, etc..

Also, if you're really worried about someone "attacking" a site like
this, you could just take advantage of PHP's auto_prepend to
automatically log the IP and a time stamp of each page request... and
if the last page request is within N seconds of the current request,
you just redirect the user to a page that says something like "server
busy, try again in a moment".

-Ed

I have just run a phpinfo and ignore_user_abort is indeed defaulting to off.

It's a pretty heavy php-MySQL script. I noticed on scripts without the
MySQL interaction, the server can keep up much better with the forced
refreshes.

Are there any other liming settings I can change?

All the best,

Ryan

--
Ryan Barclay

RBFTP Networks Ltd.

DDI: +44 (0)870 490 1870
WWW: http://www.rbftpnetworks.com
BBS: http://forums.rbftpnetworks.com



Robert Cummings wrote:
> On Sat, 2006-10-14 at 01:25 +0100, Ryan Barclay wrote:
>
>> Robert,
>>
>> Thanks for the reply. I can't seem to find ignore_user_abort in my
>> php.ini. I would like to do it at server level, rather than individual
>> scripts. Do you know roughly where is it? I think there were some
>> versions with this missing in the ini, which was later fixed.
>>
>> I'm guessing that if ignore_user_abort is set to on, this could be the
>> culprit?
>>
>> Would simply adding the following to the ini work?:
>>
>> ignore_user_abort = off
>>
>
> If it's not in your php.ini and not in your source code then it's
> already off, unless it's being activated by an http.conf or .htaccess
> setting. The default for ignore_user_abort is 0.
>
> What exactly does your script do? It may be possible that whatever task
> it is performing prevents PHP from immediately recognizing the user
> abort and subsequently terminating.
>
> Cheers,
> Rob.
>

Jon,

Thanks for the reply. Yes, ignore_abort is defaulting to off, as stated
in my other post. We have a Firebox III 1000 firewall on our external,
however this does not have any features like this. I will look into
iptables.

Thanks,

Ryan

--
Ryan Barclay

RBFTP Networks Ltd.

DDI: +44 (0)870 490 1870
WWW: http://www.rbftpnetworks.com
BBS: http://forums.rbftpnetworks.com



Jon Anderson wrote:
> Ryan Barclay wrote:
>> Thanks for the reply. I can't seem to find ignore_user_abort in my
>> php.ini. I would like to do it at server level, rather than
>> individual scripts. Do you know roughly where is it? I think there
>> were some versions with this missing in the ini, which was later fixed.
>>
>> I'm guessing that if ignore_user_abort is set to on, this could be
>> the culprit?
>>
>> Would simply adding the following to the ini work?
> Ignore user abort defaults to off, and doesn't necessarily help you if
> the clients don't terminate their connections properly, or they're
> actually trying to DoS you. I think your best bet is to either use
> some lightweight detection in PHP (and maybe send an HTTP error header
> if you're getting hit), or better yet, use a firewall if one is
> available to prevent the connections from even getting to your
> webserver and wasting its resources. (If your server is running on
> Linux, iptables should be able to do what you need, and there are more
> complicated solutions too.)
>
> jon

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.

Ryan

--
Ryan Barclay

RBFTP Networks Ltd.

DDI: +44 (0)870 490 1870
WWW: http://www.rbftpnetworks.com
BBS: http://forums.rbftpnetworks.com



Ed Lazor wrote:
>
> On Oct 13, 2006, at 2: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?
>
> Apache.conf ThreadsPerChild?
>
>> What can I do to combat this method of DoS?
>
> How do you consider this a DoS attack? Are you seeing servers
> crippled because a user or a couple of users keep hitting the refresh
> key? Honestly, it seems extreme. Your server should be able to
> handle much higher loads than that, especially when PHP starts caching
> pages, etc.. I would start double checking the server config, etc..
>
> Also, if you're really worried about someone "attacking" a site like
> this, you could just take advantage of PHP's auto_prepend to
> automatically log the IP and a time stamp of each page request... and
> if the last page request is within N seconds of the current request,
> you just redirect the user to a page that says something like "server
> busy, try again in a moment".
>
> -Ed
>
>