problem with url_fopen on free hosting environment

Hey guys,

I am running an free hosting environment and do have some trouble with
allow_url_fopen. Right now we prohibit this, but it's requested by many
of our users.
The problem is something like to following script, which calls itself
over and over again, being run on our server:
<?php
while(true)
file_get_contents("http://domain.com/crash.php");
?>

From the outside our anti-dos measures would take effect, but not when
the requests are comming from our own server.
We have max_execution_time set to 5, but this does not take effect on
this script. It just calls itself until the server queue is full. We run
mod_security on our servers, which seems to ease the situation somewhat.
But some time sooner or later apache crashes and is restarted by monit.

We would like to enable allow_url_fopen, but under those circumstances
this is not possible.
Could anybody please give me a hint on how to resolve this situation?

Regards,
Samy

I might be wrong but I think your problem goes beyond allowing URLs in
fopen. A user could just as well use cURL to build a self-calling script.
You might need to put a filter on apache on the number of requests (what's
the version of apache?).

The usual problem with allowing URLs in fopen and in "include" or "require"
is that users do some stupid stuff like include($_GET['script'].'.php') and
get a myriad of remote code executed on your server (usually used by
spammers to send email using your server).

However, to secure a php installation on a per-domain basis you can try
http://www.hardened-php.net/suhosin. I can't remember if it covers the URL
stuff, but you can enable/disable PHP functions on a per-domain basis
(apache virtual host configuration) which you will likely need if you are
the manager for a shared hosting enviroment.

Rob


Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308
| TEL 954-607-4207 | FAX 954-337-2695
Email: info@bestplace.net | MSN Chat: best@bestplace.net | SKYPE:
bestplace | Web: http://www.bestplace.biz | Web: http://www.seo-diy.com
> -----Original Message-----
> From: Samuel Vogel [mailto:samy-delux@gmx.de]
> Sent: Tuesday, November 27, 2007 6:13 PM
> To: php-general
> Subject: [php] problem with url_fopen on free hosting environment
>
> Hey guys,
>
> I am running an free hosting environment and do have some trouble with
> allow_url_fopen. Right now we prohibit this, but it's requested by many
> of our users.
> The problem is something like to following script, which calls itself
> over and over again, being run on our server:
> <?php
> while(true)
> file_get_contents("http://domain.com/crash.php");
> ?>
>
> From the outside our anti-dos measures would take effect, but not when
> the requests are comming from our own server.
> We have max_execution_time set to 5, but this does not take effect on
> this script. It just calls itself until the server queue is full. We
> run
> mod_security on our servers, which seems to ease the situation
> somewhat.
> But some time sooner or later apache crashes and is restarted by monit.
>
> We would like to enable allow_url_fopen, but under those circumstances
> this is not possible.
> Could anybody please give me a hint on how to resolve this situation?
>
> Regards,
> Samy
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

I know that the same is possible using curl, but with url_fopen on it's
just way easier.
We also allready use the suhosin patch & extension, but there is no
directive to limit fopen, you can just limit include directives.

We also have a limited number of requests, but that's not the point. The
point is, that the requests are comming in and are makeing Apache
unresponsive.

Any other suggestions? ;)

Regards,
Samy

Andrés Robinet schrieb:
> I might be wrong but I think your problem goes beyond allowing URLs in
> fopen. A user could just as well use cURL to build a self-calling script.
> You might need to put a filter on apache on the number of requests
> (what's
> the version of apache?).
>
> The usual problem with allowing URLs in fopen and in "include" or
> "require"
> is that users do some stupid stuff like
> include($_GET['script'].'.php') and
> get a myriad of remote code executed on your server (usually used by
> spammers to send email using your server).
>
> However, to secure a php installation on a per-domain basis you can try
> http://www.hardened-php.net/suhosin. I can't remember if it covers the
> URL
> stuff, but you can enable/disable PHP functions on a per-domain basis
> (apache virtual host configuration) which you will likely need if you are
> the manager for a shared hosting enviroment.
>
> Rob
>
>
> Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
> 5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL
> 33308
> | TEL 954-607-4207 | FAX 954-337-2695
> Email: info@bestplace.net | MSN Chat: best@bestplace.net | SKYPE:
> bestplace | Web: http://www.bestplace.biz | Web: http://www.seo-diy.com
>
>> -----Original Message-----
>> From: Samuel Vogel [mailto:samy-delux@gmx.de]
>> Sent: Tuesday, November 27, 2007 6:13 PM
>> To: php-general
>> Subject: [php] problem with url_fopen on free hosting environment
>>
>> Hey guys,
>>
>> I am running an free hosting environment and do have some trouble with
>> allow_url_fopen. Right now we prohibit this, but it's requested by many
>> of our users.
>> The problem is something like to following script, which calls itself
>> over and over again, being run on our server:
>> <?php
>> while(true)
>> file_get_contents("http://domain.com/crash.php");
>> ?>
>>
>> From the outside our anti-dos measures would take effect, but not when
>> the requests are comming from our own server.
>> We have max_execution_time set to 5, but this does not take effect on
>> this script. It just calls itself until the server queue is full. We
>> run
>> mod_security on our servers, which seems to ease the situation
>> somewhat.
>> But some time sooner or later apache crashes and is restarted by monit.
>>
>> We would like to enable allow_url_fopen, but under those circumstances
>> this is not possible.
>> Could anybody please give me a hint on how to resolve this situation?
>>
>> Regards,
>> Samy
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>

Thanks for the infos.
I read through the very interesting post, but I did not find it to be a
solution for my problem.
I tried to limit connections with iptables, but it did not work out. I'm
not an expert at this, I tried like it is described here:
http://www.linux-noob.com/forums/ind...showtopic=1829

I know it just limits new connections, and I thought this would work
out, but it didn't. Should I try to limit all connections?

Also it makes me wonder why mod_evasive for apache does not block this.
I will probably try to come up with a solution by using mod_security.
But it would be much nicer if it would work on the iptables level.

Regards,
Samy

Andrés Robinet schrieb:
>
> Hi Samuel,
>
>
>
> I found this forum topic the other day http://uclue.com/?xq=874, and I
> thought it's pretty nice as a start/overview. There's also
> mod_bandwidth for Apache, not included in the aforementioned topic.
>
> We are not currently having an issue with bandwidth and/or bots
> causing overload in the domains hosted with us, so I can't speak >from
> our experience with those apache modules. All of our hosting clients
> are known by us, and are not constantly changing (as it would be the
> case in a free hosting environment). So, these kind of issues are rare
> for us, easily identifiable, and from external sources. None of our
> clients will try to bypass open_base_dir, or safe_mode, or
> allow_url_fopen.
>
> If all of these apache modules are not doing their job and apache is
> still overworked... then either they need a tune up in their
> configuration or there must be something else behind the scenes and
> you'd better off checking your firewall ruleset or a kernel
> vulnerability. Probably you'll need to tackle the problem yet one
> layer down (firewall), but I'd say first exhaust all choices in the
> layer you are working on right now.
>
> Also.. don't forget about mod_security and the like. You could try a
> filter on headers. First, do a unit test and check what HTTP_REFERER,
> HTTP_USER_AGENT, REMOTE_ADDR, etc look like for a self-calling script.
> So, if, say, the user agent is "XXXXX" and the local IP address is the
> same as the remote ip address then you invalidate the request for that
> particular domain.
>
> Ok... hope you get to the solution, and then let us know on the
> mailing list
>
>
>
> Rob
>
> ------------------------------------------------------------------------
>
> Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
> cid:000701c7e78a$801a5160$0200a8c0@SAINTTHERESA
>
> ------------------------------------------------------------------------
>
> 5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL
> 33308 | TEL 954-607-4207 | FAX 954-337-2695 |
> Email: *info@bestplace.net <mailto:info@bestplace.net>** * | MSN Chat:
> *best@bestplace.net <mailto:best@bestplace.net> * | SKYPE:
> *bestplace* | Web: *bestplace.biz* <http://www.idsil.com/> | Web:
> *seo-diy.com
> *
>
> Confidentiality:
> "All information in this email message, including images, attachments,
> contains confidential and proprietary information of BESTPLACE
> CORPORATION and should only be used or serves for the intended purpose
> and should not be copied, used or disclosed to anyone other than the
> sole recipient of this e-mail message."
>

Ok, I did find a solution by accident.
I just blocked all tcp requests on port 80 and 443 comming from my own
outside IP. Since I have a couple of servers, I just dropped the
following into rc.local on all of them:

# Blocking url_fopen requests
ownip=`curl -s http://checkip.dyndns.org | awk '{print $6}' | awk '
BEGIN { FS = "<" } { print $1 } '`
iptables -A INPUT -s $ownip -p tcp --dport 80 -j DROP
iptables -A INPUT -s $ownip -p tcp --dport 443 -j DROP

Maybe this helps somebody :)

Regards,
Samy

Samuel Vogel schrieb:
> Thanks for the infos.
> I read through the very interesting post, but I did not find it to be
> a solution for my problem.
> I tried to limit connections with iptables, but it did not work out.
> I'm not an expert at this, I tried like it is described here:
> http://www.linux-noob.com/forums/ind...showtopic=1829
>
> I know it just limits new connections, and I thought this would work
> out, but it didn't. Should I try to limit all connections?
>
> Also it makes me wonder why mod_evasive for apache does not block this.
> I will probably try to come up with a solution by using mod_security.
> But it would be much nicer if it would work on the iptables level.
>
> Regards,
> Samy
>
> Andrés Robinet schrieb:
>>
>> Hi Samuel,
>>
>>
>>
>> I found this forum topic the other day http://uclue.com/?xq=874, and
>> I thought it's pretty nice as a start/overview. There's also
>> mod_bandwidth for Apache, not included in the aforementioned topic.
>>
>> We are not currently having an issue with bandwidth and/or bots
>> causing overload in the domains hosted with us, so I can't speak
>> >from our experience with those apache modules. All of our hosting
>> clients are known by us, and are not constantly changing (as it would
>> be the case in a free hosting environment). So, these kind of issues
>> are rare for us, easily identifiable, and from external sources.
>> None of our clients will try to bypass open_base_dir, or safe_mode,
>> or allow_url_fopen.
>>
>> If all of these apache modules are not doing their job and apache is
>> still overworked... then either they need a tune up in their
>> configuration or there must be something else behind the scenes and
>> you'd better off checking your firewall ruleset or a kernel
>> vulnerability. Probably you'll need to tackle the problem yet one
>> layer down (firewall), but I'd say first exhaust all choices in the
>> layer you are working on right now.
>>
>> Also.. don't forget about mod_security and the like. You could try a
>> filter on headers. First, do a unit test and check what HTTP_REFERER,
>> HTTP_USER_AGENT, REMOTE_ADDR, etc look like for a self-calling
>> script. So, if, say, the user agent is "XXXXX" and the local IP
>> address is the same as the remote ip address then you invalidate the
>> request for that particular domain.
>>
>> Ok... hope you get to the solution, and then let us know on the
>> mailing list
>>
>>
>>
>> Rob
>>
>> ------------------------------------------------------------------------
>>
>> Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
>> cid:000701c7e78a$801a5160$0200a8c0@SAINTTHERESA
>>
>> ------------------------------------------------------------------------
>>
>> 5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale,
>> FL 33308 | TEL 954-607-4207 | FAX 954-337-2695 |
>> Email: *info@bestplace.net <mailto:info@bestplace.net>** * | MSN
>> Chat: *best@bestplace.net <mailto:best@bestplace.net> * | SKYPE:
>> *bestplace* | Web: *bestplace.biz* <http://www.idsil.com/> | Web:
>> *seo-diy.com
>> *
>>
>> Confidentiality:
>> "All information in this email message, including images,
>> attachments, contains confidential and proprietary information of
>> BESTPLACE CORPORATION and should only be used or serves for the
>> intended purpose and should not be copied, used or disclosed to
>> anyone other than the sole recipient of this e-mail message."
>>
>