At its heart, WordPress is the easiest, most popular platform to create your own site or blog. In actuality, WordPress powers over 37.6percent of all of the websites online. Yes — more than one in four sites that you see are likely powered by WordPress.
On a slightly more technical level, WordPress is an open-source content management system licensed under GPLv2, meaning that anybody can use or modify the WordPress software at no cost. A content management system is essentially a tool which makes it effortless to manage important areas of your site — such as content — without having to know anything about programming.
Due to its huge popularity, WordPress frequently becomes a goal of security threats.
The nginx server
NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and much more. It started out as a web server designed for maximum stability and performance. Besides its HTTP server capacities, NGINX can also be a proxy server for email (IMAP, POP3, and SMTP) and a reverse proxy and load balancer for HTTP, TCP, and UDP servers.
As hundreds of thousands of WordPress sites run on Nginx, this tutorials gives basic methods or Nginx principles to harden your WordPress website security.
1.Limit Requests
The WordPress login page, wp-login.php, is a common endpoint for a brute-force assault. The attacker will attempt to break through your website by submitting multiple username and password combination and this usually done multiple times in a second.
For this, we can employ a rule which will limit the amount of requests which the page can handle per second. Here we set the limit to two requests per second, otherwise, the request will be blocked.
limit_req_zone $binary_remote_addr zone=WPRATELIMIT:10m rate=2r/s;
location ~ \wp-login.php$ {
limit_req zone=WPRATELIMIT;
}
2. How to limit request types
The majority of the time your site may only perform two kinds of requests i.e. GET to fetch data from your website and POST to upload information to your website.
Limiting the sort of request that our website can handle to only both of these sounds like a fantastic idea here.
if ($request_method !~ ^(GET|POST)$ ) {
return 444;
}
3.How to Disable Direct PHP File Access
If somehow, a hacker successfully sneaks in a PHP file on your website, they will have the ability to run this file by loading file that effectively becomes a backdoor to infiltrate your website. We ought to disable direct access to any PHP files by adding the following rules:
location ~* /(?:uploads|files|wp-content|wp-includes)/.*.php$ {
deny all;
access_log off;
log_not_found off;
}
4.Disabling the Access to the Dotfiles
Similar to PHP file, a dotfile such as .htaccess, .user. ini, and .git may contain sensitive information. To be on the other hand, it is far better to disable direct access to such files.
location ~ /\.(svn|git)/* {
deny all;
access_log off;
log_not_found off;
}
location ~ /\.ht {
deny all;
access_log off;
log_not_found off;
}
location ~ /\.user.ini {
deny all;
access_log off;
log_not_found off;
}
5.Hide Nginx and PHP version
Certain information shouldn’t to be exposed such as the Nginx version in addition to the PHP version. This won’t stop the attack itself. But, assuming particular Ningx or PHP version turns out has exposed, the attacker will not get to know easily from the website. To conceal the Nginx version:
#Hide the nginx version. server_tokens off; #Hide the PHP version. fastcgi_hide_header X-Powered-By; proxy_hide_header X-Powered-By;
6.Blocking the Subdirectory Access
If your website runs on a sub-directory like /website, it is far better to allow access to this sub-directory. It means that any vague access to other directories that an attacker always looks for, for example, /82jdkj/? . php are blocked.
location ~ ^/(?!(blog)/?) {
deny all;
access_log off;
log_not_found off;
}
7. Limit XMLRPC Access
XMLRPC endpoint in WordPress is used to allow an external program to interact with WordPress data. By way of example, it can allow adding, creating, or deleting a post. But, XMLRPC is also a common attack vector in which the attacker might have the ability to execute those operations without consent. It is better to allow request to XMLRPC from authorized IP which you trust, like so:
location ~* /xmlrpc.php$ {
allow 210.0.1.5;
deny all;
}
After the above is added, you should see the 403 error code response when loading xmlrpc.php from the browser.
8.How to Disable Directory Listing
Last but not least, you need to disable the directory listing so the attacker will not have to know what’s in the directory. To make the directory listing off, you may use the following single liner:
autoindex off;