WordPress Security
WordPress is the most popular CMS for running a website. As such, it is the target for all kinds of malicious bots.
The most effective way of reducing security risks associated with WordPress is the proper server configuration.
Secure WordPress NGINX configuration must be built on the assumption that any unknown script is malicious.
User-uploaded scripts should not be allowed for execution as their execution is #1 of a defaced website.
Thus our configuration example is built upon a whitelist approach.
While we’re at it, we also eliminate the negative effects of try_files and improve performance overall.
Pre-requisites
WordPress settings
Pretty Permalinks in WordPress must be enabled.
NGINX modules
There are some NGINX modules required for achieving higher security.
For CentOS/RHEL servers without control panels
sudo yum -y install https://extras.getpagespeed.com/release-latest.rpm
sudo yum -y install nginx-module-length-hiding nginx-module-immutable nginx-module-security-headers
Enable the modules in /etc/nginx/nginx.conf by placing at the top of the file:
load_module modules/ngx_http_length_hiding_filter_module.so;
load_module modules/ngx_http_immutable_module.so;
load_module modules/ngx_http_security_headers_module.so;
Alternatively, these modules can be installed from source, which is, however, only advisable for testing, on a development system.
Our secure NGINX configuration relies on a typical structure and file naming conventions.
As we go ahead with creating and modifying, we’ll review their purpose.
/etc/nginx/includes/php-example.com.conf
Create directory /etc/nginx/includes if it doesn’t exist. The file php-example.com.conf serves as a connecting point between NGINX and PHP-FPM.
In there, we specify the path to the UNIX socket file, which should match your PHP-FPM pool configuration.
fastcgi_pass unix:/var/run/php-fpm/example.com.sock;
include fastcgi_params;
/etc/nginx/sites-available/example.com.conf
NGINX configuration is typically organized in a way that website-specific is stored in its own configuration file under directory /etc/nginx/sites-available.
Let’s create a secure configuration for the website example.com.
We’re not touching upon TLS configuration, as we want to concentrate on WordPress security requirements:
server {
server_name example.com;
root /srv/www/example.com/public;
security_headers on;
# do not load WordPress when redirecting /index.php to /
location = /index.php {
return 301 /;
}
# do not load WordPress when redirecting /wp-admin to to /wp-admin/
location = /wp-admin {
return 301 /wp-admin/;
}
location / {
# any URI without extension is routed through PHP-FPM (WordPress controller)
location ~ ^[^.]*$ {
length_hiding on;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include includes/php-example.com.conf;
}
# allow only a handful of PHP files in root directory to be interpreted
# wp-cron.php ommited on purpose as it should *not* be web accessible, see proper setup
# https://www.getpagespeed.com/web-apps/wordpress/wordpress-cron-optimization
location ~ ^/wp-(?:comments-post|links-opml|login|mail|signup|trackback)\.php$ {
length_hiding on;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include includes/php-example.com.conf;
}
location ^~ /wp-json/ {
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include includes/php-example.com.conf;
}
# other PHP files "do not exist"
location ~ \.php$ {
return 404;
}
}
location = /xmlrpc.php {
# allows JetPack servers only
allow 192.0.0.0/16;
deny all;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include includes/php-example.com.conf;
}
location /wp-admin/ {
index index.html index.php;
location = /wp-admin/admin-ajax.php {
# this location often spits json, which will be broken if length hiding is used
# so no length hiding here
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include includes/php-example.com.conf;
}
# numerous files under wp-admin are allowed to be interpreted
# no fancy filenames allowed (lowercase with hyphens are OK)
# only /wp-admin/foo.php or /wp-admin/{network,user}/foo.php allowed
location ~ ^/wp-admin/(?:network/|user/)?[\w-]+\.php$ {
length_hiding on;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include includes/php-example.com.conf;
}
}
location /wp-content/ {
# contents under wp-content are typically highly cacheable
immutable on;
# hide and do not interpret internal plugin or user uploaded scripts
location ~ \.php$ {
return 404;
}
}
# hide any hidden files
location ~ /\. {
deny all;
}
# hide any backup or SQL dump files
location ~ ^.+\.(sql|bak|php~|php#|php.save|php.swp|php.swo)$ {
return 404;
}
}
After editing your configuration, don’ forget to reload NGINX, e.g.:
systemctl reload nginx
Verification
- Access a known PHP script that is not meant for web browser access, e.g. example.com/wp-blog-header.php. On successful configuration, you will get a 404 (Not Found) error.
- Pretty permalink URLs are fully functional
- Open HTML source of any page, and locate
random-length HTML comment. It should be present.
How it works
Let’s review all the pieces of our secure WordPress configuration.
The security_headers on; enable sending security headers via ngx_security_headers module. This one-liner configuration allows sending them “the right away”, as in while required only and according to their specification
Next up, we created a couple of locations:
# do not load WordPress when redirecting /index.php to /
location = /index.php {
return 301 /;
}
# do not load WordPress when redirecting /wp-admin to to /wp-admin/
location = /wp-admin {
return 301 /wp-admin/;
}
The comments are self-explanatory. When WordPress sees URIs /index.php, it redirects to the base URL of your website.
It helps with SEO content duplication reduction.
Having those redirects in NGINX allows reducing CPU use by avoiding a load of heavy WordPress stack for the simple task of redirecting.
Next up, you’ll note the use of nested locations wherever possible. This is as per the NGINX author’s recommendation.
Nested locations allow isolating the use of regular expressions and an NGINX configuration that can scale well, in terms of maintenance.
Our key location which handles SEO-friendly URLs builds on a simple assumption that they do not include dots, which typically indicates an actual file with an extension.
Thus we default to serving URIs without dots through the WordPress’ front-controller file, /index.php:
location ~ ^[^.]*$ {
length_hiding on;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include includes/php-example.com.conf;
}
The length_hiding on; enables insertion of randomly generated HTML comment:
<!-- random-length HTML comment: JnSLGWeWYWsoJ4dXS3ubLw3YOu3zfGTotlzx7UJUo26xuXICQ2cbpVy1Dprgv8Icj6QfOZx2Ptp9HxCVoevTxhKzMzV6xeYXao0oCngRWJRb4Tvive1iBAXLzrHlLg6jKwNKXrct0tJuA2TvWIRVIng6UoffIbCQLPbi63PwmWemOxVi6m3CPa6hCbAK2CaBR1jLux7UJa4WNN4H0yIDMElMglWWouY5m5FUqAn0afMmtErj0zkA2LMWxisZRES38XLoYycySmaBrIih5IixUsJFR0ei4uZ0IifgV5SnitoNzMusSQem9npObHuU2HKApneAjwnFdPSQZA9sRdSOE8agDI05P832mV1JIcOjsg0FgzxvSG7UEX0HdqBqp2jPOYYW0k5gGtmkiXWydRJfn9lGomxReUeqq2Aec69gplEM6a8aqH5TFgXrGK8jcaPISQlsKkMxJQ7Fp6fVDbmI59xCIvlk -->
This is a measure that eliminates the possibility of a BREACH attack.
Next, we specify which .php files are allowed for execution, other than index.php:
# allow only a handful of PHP files in root directory to be interpreted
# wp-cron.php ommited on purpose, see proper setup
location ~ ^/wp-(?:links-opml|login|mail|signup|trackback)\.php$ {
length_hiding on;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include includes/php-example.com.conf;
}
# other PHP files "do not exist"
location ~ \.php$ {
return 404;
}
The secure configuration only allows a few well-known PHP files to be executed.
Unlisted PHP are silently discarded with HTTP status code 404, thus preserving information disclosure wherever possible.
The /wp-content/ directory is the primary source of user-uploaded images, plugins, and their scripts.
A well-coded plugin never needs to be executed by its direct URI under /wp-content/<handle>/foo.php.
If you find that such a plugin is present in your WordPress instance, it is a candidate for removal, and in very exceptional cases, whitelisting in NGINX configuration.
A perfect WordPress website allows no execution of PHP scripts under /wp-content/ directory.
Once you know you have no bad players (plugins) in your /wp-content, you can apply the honeypot approach to it.
Add all the necessary configuration from the linked article, then update the location ~ \.php$ { in a way that instead of returning 404, it will include the honeypot configuration.
This will make any bad bots trying to access plugins’s PHP files under wp-content immediately blocked:
# other PHP files cause automatic ban:
location ~ \.php$ {
include includes/honeypot.conf;
}
The publicly accessible files in wp-content are highly cacheable (images). The immutable on; enables sending caching headers with Far Future Expiration, as well as the immutable attribute.
This ensures the highest browser cachability for your WordPress while reducing network usage on both the server and client-side.