How do I limit my number of PHP hits per second?

[Nu]

I want to protect myself from if someone with a fast connection hammers my
site. It's not denial of service attacks, but offline downloaders (of course
that don't show they're offline downloaders in the useragent so I can't
filter them by that). My main issue is my site is PHP so if they hammer it,
it gets all the PHP files executing and overwhelms the CPU. I'd like to be
able to after a certain amount of hits on my index.php per second, so just
refuse.

I can't find how to do that. Can it be done in PHP, htaccess, etc.

Any ideas?

[P Pulkkinen]

"Nu" <[e-mail] joitti
viestissä:uE*** *************** **@bgtnsc05-news.ops.worldn et.att.net...

>I want to protect myself from if someone with a fast connection hammers my
site. It's not denial of service attacks, but offline downloaders

Even I have not dealt with this specific issue, I want help by asking these
questions:

1) What info offline downloaders bring to phpinfo():

[Rik]

Nu <[e-mail] te:

I want to protect myself from if someone with a fast connection hammers
my
site. It's not denial of service attacks, but offline downloaders (of
course
that don't show they're offline downloaders in the useragent so I can't
filter them by that). My main issue is my site is PHP so if they hammer
it,
it gets all the PHP files executing and overwhelms the CPU. I'd like to
be
able to after a certain amount of hits on my index.php per second, so
just
refuse.

I can't find how to do that. Can it be done in PHP, htaccess, etc.

I'd say this would have to be done on server-level, anything in PHP would
still need/eat quite some resources.

May I suggest you ask this on alt.apache.conf iguration?
--
Rik Wasmus

[Sanders Kaufman]

Nu wrote:

I want to protect myself from if someone with a fast connection hammers my
site. It's not denial of service attacks, but offline downloaders (of course
that don't show they're offline downloaders in the useragent so I can't
filter them by that). My main issue is my site is PHP so if they hammer it,
it gets all the PHP files executing and overwhelms the CPU. I'd like to be
able to after a certain amount of hits on my index.php per second, so just
refuse.

I can't find how to do that. Can it be done in PHP, htaccess, etc.

Any ideas?

Can't be done. You cannot control what other people on the web
do. You can only control how you react.

Any measure you take against the dishonest folks, you also take
against the honest ones. To that end, there are services out
there who will gladly charge you thousands of dollars to sell
you service packages for several thousand per month. And some
of those might even help to track down your abusive user.

But your best bet is to just make sure you have capacity to
handle peak loads, and that overloaded systems throttle down
gracefully.

[Sanders Kaufman]

Rik wrote:

I'd say this would have to be done on server-level, anything in PHP
would still need/eat quite some resources.

Personally, I do it by primarily serving up static HTML pages,
instead of PHP. I reserve PHP for active content and such.

You can still get hammered, but the PHP system isn't going wild.

[Nu]

Sanders Kaufman" <bu***@kaufman. netwrote in message
news:yW******** **********@news svr27.news.prod igy.net...

Nu wrote:

I want to protect myself from if someone with a fast connection hammers

my

site. It's not denial of service attacks, but offline downloaders (of

course

that don't show they're offline downloaders in the useragent so I can't
filter them by that). My main issue is my site is PHP so if they hammer

it,

it gets all the PHP files executing and overwhelms the CPU. I'd like to

be

able to after a certain amount of hits on my index.php per second, so

just

refuse.

I can't find how to do that. Can it be done in PHP, htaccess, etc.

Any ideas?

Can't be done. You cannot control what other people on the web
do. You can only control how you react.

Any measure you take against the dishonest folks, you also take
against the honest ones. To that end, there are services out
there who will gladly charge you thousands of dollars to sell
you service packages for several thousand per month. And some
of those might even help to track down your abusive user.

But your best bet is to just make sure you have capacity to
handle peak loads, and that overloaded systems throttle down
gracefully.

Actually, my site goes to index.php and then index.php digs around in other
PHPs and MySQL. If I stop it right at index.php, I can keep my account from
overloading the CPU.

[Nu]

"P Pulkkinen" <pe************ *************@P OISTATAMA.elisa net.fiwrote in
message news:2N******** ********@reader 1.news.saunalah ti.fi...

"Nu" <[e-mail] joitti
viestissä:uE*** *************** **@bgtnsc05-news.ops.worldn et.att.net...

I want to protect myself from if someone with a fast connection hammers

my

site. It's not denial of service attacks, but offline downloaders

Even I have not dealt with this specific issue, I want help by asking

these

questions:

1) What info offline downloaders bring to phpinfo():

I don't understand that question.

[P Pulkkinen]

"Nu" <[e-mail] joitti
viestissä:uE*** *************** **@bgtnsc05-news.ops.worldn et.att.net...

>I want to protect myself from if someone with a fast connection hammers my
site. It's not denial of service attacks, but offline downloaders

Sorry, if I misunderstand or miss something. I understood that you mean
persons that use some batch to fetch the _output_ of your script, perhaps
automaticly on timely basis. But not _download_ it in sense of ftp/scp.

1) Can you use $_SERVER["REMOTE_ADD R"] to identify downloaders from each
other?

2) Does it really matter if they are online or offline, if the POINT is
that some people (or machines) execute your index.php or other script
_too_often_?

3) How about this scenario:
You have two database tables:
DOWNLOADS
- download_id
- filepath
- remote_ip
- timestamp
TROUBLEMAKERS
- remote_ip
- filepath

In the END of every script execution you add an entry to downloads table.
You also check, if that filepath/remote_id-combination has become bad enough
to be inserted into troublemakers table. You use some mathematics to define
characteristics of being evil downloader.

In the BEGINNING of every script, you make a database query to troublemakers
table and if current filepath/remote_id-combination is there, stop the
execution immediately.

Downside here is that mysql traffic increases, even php traffic may
decrease. If they was a way to check evil filepath/remote_id-combinations in
apache side, of course troublemakers table could be replaced with
troublemakers-file as well or a file that would be apache magik with that
data inside.

[Sanders Kaufman]

Nu wrote:

Sanders Kaufman" <bu***@kaufman. netwrote in message

>But your best bet is to just make sure you have capacity to
handle peak loads, and that overloaded systems throttle down
gracefully.

Actually, my site goes to index.php and then index.php digs around in other
PHPs and MySQL. If I stop it right at index.php, I can keep my account from
overloading the CPU.

In that case - you just have to choose one or more methods among
the several (labor-intensive) ones out there.

You can exit based on IP's - but they can be spoofed. You can
exit based on other headers - but they can be spoofed, too.

This is why developers talk so much about "scalabilit y". If
your site isn't designed to handle peak loads, and to exit
gracefully during overload - all of the other measures won't help.

That's usually an OK design flaw behind a firewall, but not out
in open water.

[Nu]

"Sanders Kaufman" <bu***@kaufman. netwrote in message
news:yp******** ***********@new ssvr27.news.pro digy.net...

Nu wrote:

Sanders Kaufman" <bu***@kaufman. netwrote in message

But your best bet is to just make sure you have capacity to
handle peak loads, and that overloaded systems throttle down
gracefully.

Actually, my site goes to index.php and then index.php digs around in

other

PHPs and MySQL. If I stop it right at index.php, I can keep my account

from

overloading the CPU.

In that case - you just have to choose one or more methods among
the several (labor-intensive) ones out there.

You can exit based on IP's - but they can be spoofed. You can
exit based on other headers - but they can be spoofed, too.

This is why developers talk so much about "scalabilit y". If
your site isn't designed to handle peak loads, and to exit
gracefully during overload - all of the other measures won't help.

That's usually an OK design flaw behind a firewall, but not out
in open water.

So how do I handle peak loads and exit gracefully during overloads?

Basically something like X hits per 10 seconds to index.php sounds simple
enough. I can't find out how to do that, though.