How to Block IP Addresses with .htaccess - Including .php URL requests?

[martinibuster]

Never mind the title. I think the problem is that the .htaccess doesn't work for files with php on the end.

I've got an .htaccess file blocking bots and hackers from rogue IP addresses.
Bots coming from blocked IP addys can't access the site. EXCEPT when there's a forward slash and anything.php.

The .htaccess isn't working for ANY URL that ends in PHP.

If the URL is /example/ then the blocking works.

If the URL is /example/index.php then the blocking does NOT work.

Instead of doing a regular .htaccess deny IP, should I just do it like this:

<Files ~ "\.php$"> 
 Order Allow,Deny
 Deny from 111.111.111.255/24
 Deny from 112.111.111.255/24
</Files>

Is there anything that can be done for this?

Thanks!

[tangor]

Since I have no php on site I block all with:

SetEnvIfNoCase Request_URI "\.php" ban

Not sure that is what you want.

[w3dk]

.htaccess would "normally" work for ".php" files, so either:

- There is a conflict with other directives.

OR

- Because of the way PHP is installed on your server means that requests for ".php" files are effectively proxied to the backend PHP engine and your .htaccess file is bypassed entirely for these requests.

EXCEPT when there's a forward slash

At the end of the URL? Is this a directory? Or a file (with PATH_INFO)? Or some virtual URL-path?

Instead of doing a regular .htaccess deny IP, should I just do it like this:

If you mean with/without the "<Files>" wrapper. Then that will effectively just change the order of processing, since "<Files>" containers are merged late. If there is a conflict with other auth directives then this could resolve the issue, but otherwise it is unnecessary if you are wanting to block all requests from those IPs.

Note also that Order and Deny directives are Apache 2.2 directives and formerly deprecated on Apache 2.4. You should be using the equivalent "Require" directives instead (but never mix the two - you need to upgrade everything in one go).

SetEnvIfNoCase Request_URI "\.php" ban

This simply sets an environment variable. You still need the appropriate "Deny" or "Require" directives etc. to actually do the blocking.

[not2easy]

I'm not the wiz on these things, but doesn't the allow,deny part want the allow lines first?

A few things that might change the ideal solution:
Apache version?
Is .php file extensions a small minority of files or the main file type?
(trying to see why the <Files envelope is the best way to do this) If it is a few specific files being blocked, sometimes it is simpler to change permissions.

[martinibuster]

Because of the way PHP is installed on your server means that requests for ".php" files are effectively proxied to the backend PHP engine and your .htaccess file is bypassed entirely for these requests.

The PHP setting for my site is:

Run PHP as FPM application served by nginx

"At the end of the URL? Is this a directory? Or a file (with PATH_INFO)? Or some virtual URL-path?"

A directory.

.htaccess works here:

example.com/folder/

.htaccess does not work here:

example.com/folder/*.php

sometimes it is simpler to change permissions.

It's not an issue of permissions.
These are normal files that my site visitors must get to like this:

example.com/folder/search.php

It's just that blocking IP addresses with .htaccess doesn't work on URLs with the .php at the end.

[lucy24]

You keep saying “.htaccess” but that doesn’t mean anything. What directive, in what module are you using to block the request? Is it inside a <Files> envelope, or does it apply to all requests?

Are you really still on Apache 2.2? If so, you are seriously overdue for a server upgrade.

Tangentially:

Deny from 111.111.111.255/24
Deny from 112.111.111.255/24

Was this bit typed at random for posting purposes?
111.111.111.255/24 = 111.111.111.0/24 = 111.111.111
for a savings of up to seven bytes on each request (which has to be read every time, since it's htaccess).

[martinibuster]

You keep saying “.htaccess” but that doesn’t mean anything

htaccess means, I create a file, name it .htaccess and upload it to the root.

This is how it begins

order allow,deny
allow from all
Deny from x.x.x.x/xx

Was this bit typed at random for posting purposes?

Yes, it's an example. ;)

[w3dk]

Run PHP as FPM application served by nginx

Well, that would seem to answer the question as to why the directiives in ".htaccess" are not doing anything to block ".php" requests. ".php" requests are handled by Nginx and ".htaccess" (and possibly Apache) is bypassed entirely.

Where/how you would block these requests depends on your server config. Is there a front-end proxy sending requests to Nginx and Apache? Is Nginx itself the proxy? Is Apache proxying requests to Nginx? (If the later then the request could potentially be blocked in the Apache server config, before the request is forwarded to Nginx.)

A directory.

.htaccess works here:

example.com/folder/

Although, I thought you said this didn't work..."EXCEPT when there's a forward slash and anything.php." ?

[lucy24]

overlapping w3dk

This is how it begins

OK, so the question is about mod_auth-whatever-it-was-called-in-2.0, as indicated by the Allow/Deny syntax. Unless you've got a seriously antiquated server, we're talking about 2.4 with mod_access_compat. In that case, you have to watch our for conflicts with mod_authz_core, the one that uses directives in “Require” form, either in the same htaccess or deeper down.

But the actual question is, are the rules-that-don't-work located inside a <Files> envelope? This may not be the best approach in the specific case of php; it's more appropriate for ordinary physical files like images or text files.

the URL is /example/index.php

If in fact you are using <Files> envelopes, then you have to put URL out of your mind. The envelope applies to physical files--and, of course, it only applies to files that are on the path served by the current htaccess. If the php files are elsewhere in the server, a <Files> envelope will have no effect. (<Location> might, but it can't be used in htaccess.)

[martinibuster]

But the actual question is, are the rules-that-don't-work located inside a <Files> envelope?

No, I'm not using that. I was just asking if that might be a solution.

My Apache is the latest version. My Plesk dashboard automatically updates all the components so I'm very sure Apache is up to date. In fact, this server was recently provisioned about a year ago.

So is my htaccess written wrong?

Because of the way PHP is installed on your server means that requests for ".php" files are effectively proxied to the backend PHP engine and your .htaccess file is bypassed entirely for these requests.

Hmm... was wondering about that.

"EXCEPT when there's a forward slash and anything.php."

Emphasis should be on the AND. The forward slash is not causing the issue. It's what comes after the forward slash.

EXCEPT when there's a forward slash and anything.php.

:)

[robzilla]

Wouldn't anything.php always be preceded by a forward slash?

If nginx passes all PHP requests to PHP-FPM and everything else is forwarded to Apache, then there's your answer.

Ideally you would take care of any IP blocking in the web server that is first in line to handle requests*, i.e. the one listening on 80/443. In the case of nginx unfortunately that means you can't use .htaccess, but there are lots of other ways of course.

(* Or earlier still, in your firewall.)

[not2easy]

No, I'm not using that. I was just asking if that might be a solution.

My Apache is the latest version.

That's why I asked the version, it seemed impossible.

[tangor]

This simply sets an environment variable. You still need the appropriate "Deny" or "Require" directives etc. to actually do the blocking.

Of course:

Deny from env=ban
Allow from env=pass

However, this method would not address OP's question.

[tangor]

This simply sets an environment variable. You still need the appropriate "Deny" or "Require" directives etc. to actually do the blocking.

Of course:

Deny from env=ban
Allow from env=pass

However, this method would not address OP's question. But it does block ALL .php with strings or not.

[martinibuster]

* Or earlier still, in your firewall.

I poked around and researched and it looks like I can't ban a CIDR address, i.e. x.x.x.x/xx

The instructions online say something like one can ban an IP address or the network, but it doesn't clarify what network means and I couldn't find clarification of that.

Here's what it says on Plesk: [docs.plesk.com]

Managing Custom Rules
To add a custom rule:
1. Go to Extensions > Firewall > Modify Plesk Firewall Rules.
.
.
.
6.To specify the IP address or network address, type it into the Add IP address or network input box, and click Add.

7. Specify the action that will be applied to the communications that match the defined criteria: allow or deny.

8.Click OK to submit the rule

[phranque]

are you seeing any clues of these requests in your apache web server log files?

[martinibuster]

I blocked my IP address and visited the site using that IP to figure out why spammers on blocked IPs were still getting through.
That's how I discovered that example.com/directory/*.php pages were still accessible while other pages were not accessible because the .htaccess IP block worked there.

[martinibuster]

are you seeing any clues of these requests in your apache web server log files?

No clues. Checked Apache and Nginx access/error/etc logs and didn't really see anything that stood out.

Anything in particular that I should be looking for?

Is my .htaccess coded wrong for the latest version of Apache?

order allow,deny
allow from all
 Deny from x.x.x.x/xx

[lucy24]

Anything in particular that I should be looking for?

Yes: look for accesses from your own IP in the appropriate time frame. If you don't see yourself at all, that confirms that php is routed a different way. (But what about supporting files such as images and stylesheets? Do those live in the same place as the php?)

Is my .htaccess coded wrong for the latest version of Apache?

Your access rules worked in Apache 2.2 using mod_auth-whatever. They continue to work in Apache 2.4 thanks to mod_access_compat, created solely to prevent servers everywhere from exploding. It is safe to predict that Apache 2.6 will no longer have mod_access_compat, because everyone will have long since upgraded their access controls to use the new format. It can be done with little more than a few global replaces.

[phranque]

Checked Apache and Nginx access/error/etc logs and didn't really see anything that stood out.

Anything in particular that I should be looking for?

i would be looking for clues of YOUR REQUEST(s) in the log files.
i would also be looking for clues that your request got sent to the nginx server before apache had a chance to block it.
if you have access to the server config files, you might consider turning up the per-module logging for the relevant apache module(s) to see if that reveals anything informative:
https://httpd.apache.org/docs/2.4/logs.html#permodule
https://httpd.apache.org/docs/2.4/mod/core.html#loglevel

[martinibuster]

They continue to work in Apache 2.4

So... what's the updated way of blocking in 2.4?

Yes: look for accesses from your own IP in the appropriate time frame.
...i would also be looking for clues that your request got sent to the nginx server before apache had a chance to block it.

I checked and saw my access to the .php file in this log file: nginx SSL/TLS access

So what's next? Will updating the .htaccess to 2.4 fix it or is there something else I should be doing? :(

[phranque]

it appears that .php requests never hit the apache server.
therefore you must do your IP blocking in the nginx server as well.
or perhaps at the upstream server if there is one and if that is possible for you to configure.

[martinibuster]

or perhaps at the upstream server

I'm on a dedicated server.

Okay, I'll research this later today. Thanks!

R

[phranque]

which is the "front end" server?
nginx or apache?

[martinibuster]

"Plesk configures it as a reverse proxy server that stands between the Internet and Apache (see the diagram below).

This means that nginx becomes a frontend web server that processes all incoming requests from site visitors.

The requests are sent to Apache which, in turn, distinguishes requests for static and dynamic content. If a request is for a static file (such as jpg, css, html, and so on), Apache passes the request through all registered handlers (applies .htaccess directory-level configuration, rewrites a URL, and so on) and returns to nginx a response which contains only the location of the requested file on the file system.

nginx locates the file and sends it to the client. If the request is for a dynamic file (such as a PHP script), Apache executes the file and sends the response to nginx, which delivers it to the client.

[robzilla]

Earlier, you wrote:

The PHP setting for my site is:

Run PHP as FPM application served by nginx

Which contradicts the above.

If PHP requests are proxied to PHP-FPM by nginx, Apache doesn't come into play at all. Actually, if nginx also serves static files, I'm not sure what Apache is doing, but if .htaccess works for non-PHP requests, it must be doing something.

Is .htaccess only "ignored" when a request directly references a .php files, e.g. example.com/whatever/script.php, or also when a PHP script is the directory index file of a path like example.com, i.e. where there's no .php extension in the URI?

[martinibuster]

Is .htaccess only "ignored" when a request directly references a .php files, e.g. example.com/whatever/script.php, or also when a PHP script is the directory index file of a path like example.com, i.e. where there's no .php extension in the URI?

It's ignored only when there's a php extension.

.htaccess does not work:
example.com/index.php
example.com/folder/*.php

.htaccess works when I visit:
example.com
example.com/folder/

Apache and nginx Logs
I can see the access in the following nginx access log: nginx SSL/TLS access
I can see the blocks in the Apache error logs

[lucy24]

One more gap to fill in: Does your Apache--either in the htaccess we've been talking about, or in the overall config file--have a directive along the lines of

DirectoryIndex index.php

and, if so, does “index.php” exist anywhere as a real, physical file? (I had to double-check this in docs. The default remains “index.html” and-that's-all, so if the site uses index.php, it has to say so somewhere.)

[robzilla]

OK, then there's likely a location block in the nginx config looking for the .php extension, like so:

location ~ \.php$ {

A request for /folder/index.php would hit that (and never see Apache), one for /folder/ would not (and be forwarded to Apache).

Apparently Plesk does not configure the nginx [index] directive to include index.php, otherwise a request for /folder/ should still be processed by nginx/php-fpm and not be forwarded to Apache.

So the processing goes like this:

/folder/index.php > nginx > php-fpm
/folder/ > nginx > Apache

If you want to keep using .htaccess, I suggest you just switch your Plesk setting to a different PHP handler, probably "FPM application served by Apache".

[martinibuster]

I suggest you just switch your Plesk setting to a different PHP handler, probably "FPM application served by Apache".

Yesss! That's worked! :) :) :)

Thank you everyone who helped to troubleshoot this!

Forums are so much better than trying to Google for an answer!

Thanks again!

Roger