• The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

.htaccess files/filesmatch not processed

John Weng

New Pleskian
I'm trying to block xmlrpc.php access from offsite, but it's somehow being ignored. I've tried editing .htaccess manually entered as suggest by
http://forum.ait-pro.com/forums/top...mlrpc-php-block-xmlrpc-php-forbid-xmlrpc-php/
Code:
<FilesMatch "^(xmlrpc\.php)">
Order Deny,Allow
Deny from all
Allow from xx.xx.xx. #my ip address range
</FilesMatch>

and automatically by the iTheme Security plugin.
Code:
# BEGIN iThemes Security - Do not modify or remove this line
# iThemes Security Config Details: 2
    # Disable XML-RPC - Security > Settings > WordPress Tweaks > XML-RPC
    <files xmlrpc.php>
        <IfModule mod_authz_core.c>
            Require all denied
        </IfModule>
        <IfModule !mod_authz_core.c>
            Order allow,deny
            Deny from all
        </IfModule>
    </files>
# END iThemes Security - Do not modify or remove this line

Neither way worked. I don't see errors in the log, and xmlrpc.php is still being accessed.
I'm on CentOS Linux 7.2.1511 with Plesk 12.5.30 Update #18.

Thanks,
John
 
Instead of creating custom .htaccess file try to use "Additional Apache directives" or "Additional nginx directives" fields in Plesk interface for applying your options.
 
Thanks IgorG. I tried the following on both .htaccess and "Additional Apache Directives" to no avail. The file (same with wp-login.php) is still accessible offsite. The same configuration works as expected on a different server without Plesk. Any ideas? Thanks.

Code:
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
    Allow from 172.16.0.0/12 10.0.0.0/8 127.0.0.1
</Files>
 
Apache directives (Files and FilesMatch) aren't working at all. I see the changes in "/var/www/vhosts/system/mysite.com/conf/vhost_ssl.conf", but its somehow being ignored.

Nginx on the other hand worked to some degree. It rejects external request, but internal requests are forcing download of PHP files instead of executing and returning HTML...

Any ideas? Did I screwup Plesk somehow? Any Plesk configuration I should be checking?

Thanks,
John
 
Same problem here.

Apache directives in Plesk in Additional Apache Directives (Files/FilesMatch) are ignored for php files. The directives will work for a html file, but not for php files. I don't want to work with plesk mod_security work around. I just want the Additionial Apache Directives in Plesk to work normally.

Someone knows whats going on here?

Edit: I found out that the Files/FilesMatch directives in .htaccess or in Plesk, Additional Apache Directives, doesn't work on php files when when php is run as fpm-php application. Selecting "run as fastcgi application by apache" in the php settings of the domain, will work and the directives are no longer ignored.

Thank you,
Chris
 
Last edited:
If someone could explain why fastcgi works but fpm-php not, as described in the extra edit of the post I wrote before, that would be very helpful. Thanks.
 
All,

I know this is an older post. But our wordpress installation is now getting attacked and apache log files include lots of requests to "POST /blog/xmlrpc.php". Banning the offending IPs worked for the moment, but a longer term solution is needed.

Any final resolution on best practices to mitigate? Thanks.
 
After selecting the domain to manage, click "Apache & nginx Settings", under Additional directives for HTTP and Additional directives for HTTPS, I've entered the following to restrict wp-login.php and xmlrpc.php access to only internal IP addresses.
Code:
<FilesMatch "^(wp-login|xmlrpc)\.php$">
    Order deny,allow
    Deny from All
    allow from xxx.xxx.xxx.xxx
</FilesMatch>

For NEW sites, you can apply the above via Service Plans => *select your plan* => Web Server.

For existing sites, if you don't want to manually edit each site with the GUI, you'd need to use a script to add the above code to /var/www/vhosts/system/xxxxx.domain.name/conf/vhost.conf and /var/www/vhosts/system/xxxxx.domain.name/conf/vhost_ssl.conf, then apply the fix with the command
Code:
/usr/local/psa/admin/sbin/httpdmng --reconfigure-domain xxxxx.domain.name
 
Back
Top