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/index.php?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@xxxxxxxxxxxxx <mailto:info@xxxxxxxxxxxxx>** * | MSN
Chat: *best@xxxxxxxxxxxxx <mailto:best@xxxxxxxxxxxxx> * | 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."
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
