You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Florian Effenberger <fl...@arcor.de> on 2004/09/29 09:39:24 UTC
[users@httpd] PHP as CGI: Denial of Service?
Hello there,
PHP set up as CGI (either with binfmt and suEXEC or via suPHP) can
expose your system to a denial of service attack. Even a very simple
page like
<? echo "Hello world"; ?>
can bog down a server completely if the reload button on the browser is
pressed continously for some seconds. I already tried the RMax
directives in httpd.conf and the memory limit in php.ini, but it does
not seem to work, it is just being ignored. I think that so many
processes are spawned that the system is out of control. I can get my
load as high as 91 and my disk swaps for nearly 30 minutes until it
works again. Sometimes even the kernel crashed with out of memory errors.
Apart from trying out cgiwrap, I am completely helpless right now.
Does anyone have an idea on what to do? I can't be possible that every
PHP suEXEC install is a big security risk. Any tips are welcome!
I experienced this problem with Apache 1.3 and 2.0.
Thanks in advance,
Florian
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] PHP as CGI: Denial of Service?
Posted by Florian Effenberger <fl...@arcor.de>.
Hi,
> Nevertheless a very good option. Lets you use the (far more scalable)
> Worker MPM, for instance).
If my users need PHP, it's not an option at all. ;-)
> Loading PHP is the issue. HelloWorld isn't.
Is PHP this big and fat that it can so easily bog down a server?
> Neither would I. I recently had some attacks on my server, and after
> blocking the first few IPs they came from, I hacked up a mini-module
> to return /robots.txt to the attackers. But that was something very
> specific: for a more general solution you'd want
> http://force-elite.com/~chip/archives/mod_load_average-0.1.0-test3.tar.bz2
I'll have a look at it, thanks, but I always think that this works
around the problem instead of solving it. :-(
Florian
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] PHP as CGI: Denial of Service?
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 29 Sep 2004, Florian Effenberger wrote:
> > - consider to remove PHP
>
> Not an option.
Nevertheless a very good option. Lets you use the (far more scalable)
Worker MPM, for instance).
> > - using a caching proxy or something
>
> For a Hello world script?
Loading PHP is the issue. HelloWorld isn't.
> Sorry, but I just can't accept that a server connected with 100 MBit/s
> to the net can be brought down by a client connected with a 128 KBit/s
> upstream. This is a simple plain script that just prints out Hello
> world. I even left out most libraries in the PHP compile!
Neither would I. I recently had some attacks on my server, and after
blocking the first few IPs they came from, I hacked up a mini-module
to return /robots.txt to the attackers. But that was something very
specific: for a more general solution you'd want
http://force-elite.com/~chip/archives/mod_load_average-0.1.0-test3.tar.bz2
--
Nick Kew
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] PHP as CGI: Denial of Service?
Posted by Joshua Slive <js...@gmail.com>.
On Wed, 29 Sep 2004 10:27:01 +0200, Florian Effenberger <fl...@arcor.de> wrote:
> Sorry, but I just can't accept that a server connected with 100 MBit/s
> to the net can be brought down by a client connected with a 128 KBit/s
> upstream. This is a simple plain script that just prints out Hello
> world. I even left out most libraries in the PHP compile!
It is a fairly trivial excercise to tie up a webserver with very
little bandwidth from the client side. It can be done even if all the
files on the server are static. This is partly due to the processing
model used by apache (one thread/process per connection) and partly
due to the inherent facts of life of the internet.
The best way to protect against that is to use software/hardware
designed for the job: a firewall. A good firewall can limit the
number of connections from any particular client, rendering this type
of attack impossible.
Joshua.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] PHP as CGI: Denial of Service?
Posted by Florian Effenberger <fl...@arcor.de>.
Hi Andre,
> I don't buy that.
Sorry?
> Anyway, you *cannot* prevent a public service from being dosed. You can
> lower the issue by:
>
> - using more or better hardware
A 1.8 P4 should be fine for a Hello world script. ;-)
> - playing with MaxClients etc.
That only helps if I set it to insane low limits that prevent from
accessing the HTML pages as well.
> - consider to remove PHP
Not an option.
> - using a caching proxy or something
For a Hello world script?
> All those possibilities won't prevent you from being dosed. (e.g.lowering
> MaxClients results just in an unresponsive server, even if the system itself
> is ok -> DoS).
>
> - so finally: learn to live with it
Sorry, but I just can't accept that a server connected with 100 MBit/s
to the net can be brought down by a client connected with a 128 KBit/s
upstream. This is a simple plain script that just prints out Hello
world. I even left out most libraries in the PHP compile!
Florian
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] PHP as CGI: Denial of Service?
Posted by André Malo <nd...@perlig.de>.
* Florian Effenberger <fl...@arcor.de> wrote:
> PHP set up as CGI (either with binfmt and suEXEC or via suPHP) can
> expose your system to a denial of service attack. Even a very simple
> page like
>
> <? echo "Hello world"; ?>
>
> can bog down a server completely if the reload button on the browser is
> pressed continously for some seconds. I already tried the RMax
> directives in httpd.conf and the memory limit in php.ini, but it does
> not seem to work, it is just being ignored.
I don't buy that.
Anyway, you *cannot* prevent a public service from being dosed. You can
lower the issue by:
- using more or better hardware
- playing with MaxClients etc.
- consider to remove PHP
- using a caching proxy or something
All those possibilities won't prevent you from being dosed. (e.g.lowering
MaxClients results just in an unresponsive server, even if the system itself
is ok -> DoS).
- so finally: learn to live with it
nd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] PHP as CGI: Denial of Service?
Posted by Laura Vance <va...@winfreeacademy.com>.
Hello Florian,
I'll take a stab at this from a different angle than the other responses.
I use a combination of Perl and C++ for my web apps. PHP is essentially
based on perl, and it operates essentially the same way. Your issue is
not one of bandwidth or RAM initially, but the basic way that PHP
works. It is an interpreted language, and the interpreter basically has
to recompile the app every time it executes it. This causes a spike in
the CPU and RAM (after enough processes are used it even goes to swap).
I learned this the hard way, and it took me several days of my server
crashing before I realized that there was no Perl solution. I stayed
late one night and rewrote the app in C++ and did some load testing. I
could easily max the server on the Perl version, but I could barely get
the CPU to show any extra load when the C++ version was running. I had
to figure out a faster way to "reload" than clicking the "reload"
button, because it just wasn't fast enough to present any extra load to
the server.
I have a screen capture of that load test if you would like to see the
difference.
http://www.winfreeacademy.com/images/systemMonitor.jpg
Notice the significant difference in the CPU graph. This was done with
only about 20 refreshes, and it maxed the CPU enough that I had to wait
about 20 seconds for the system to respond. I didn't go farther,
becuase I didn't want to kill the server at the time, and it
demonstrated the problem sufficiently. The C++ version took a LOT more
effort to just get it to show the spike in the graph. I wanted to have
a visible spike, because I was going to use it to justify why I should
convert all primary software to C++.
On the NIC Transmit & Receive, notice the data throughput that
corresponds with each program. This shows that data throughput was not
the bottleneck for the Perl software, because the C++ software was able
to transfer several times more data with a fraction of the CPU.
On the Memory usage graph. Notice the spike in RAM usage for the Perl
and no spike at all for the C++ version.
The process count graph shows the spike, because of simultaneous
processes. Since the Perl takes so much longer to run by its nature
(interpreted on the fly), it had more processes in memory. This meant
more processes fighting for resources, and higher system load. The C++
version has a very tiny spike in process count, because it ran so fast
that I almost couldn't get it to have multiple instances running
simultaneously.
And last, the total sockets graph also illustrates that the Perl
software was not limited by the number of socket connections.
Do not misunderstand what I'm trying to say here. Perl/PHP are good
tools for fast development, but if you have an app that needs speed,
those are not the languages to use. If you do not know how to program
in C/C++, learn. It will be the most valuable programming investment
that you ever make.
Florian Effenberger wrote:
> Hello there,
>
> PHP set up as CGI (either with binfmt and suEXEC or via suPHP) can
> expose your system to a denial of service attack. Even a very simple
> page like
>
> <? echo "Hello world"; ?>
>
> can bog down a server completely if the reload button on the browser is
> pressed continously for some seconds. I already tried the RMax
> directives in httpd.conf and the memory limit in php.ini, but it does
> not seem to work, it is just being ignored. I think that so many
> processes are spawned that the system is out of control. I can get my
> load as high as 91 and my disk swaps for nearly 30 minutes until it
> works again. Sometimes even the kernel crashed with out of memory errors.
>
> Apart from trying out cgiwrap, I am completely helpless right now.
>
> Does anyone have an idea on what to do? I can't be possible that every
> PHP suEXEC install is a big security risk. Any tips are welcome!
>
> I experienced this problem with Apache 1.3 and 2.0.
>
> Thanks in advance,
> Florian
--
Thanks,
Laura Vance
Systems Engineer
Winfree Academy Charter Schools
6221 Riverside Dr. Suite 110
Irving, Tx 75039
Web: www.winfreeacademy.com
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org