If you’re wondering if your website is secure, the quick answer is no, you can if you want to improve it as much as possible, and you certainly should.
Let’s look at the three main fronts from which to attack the problem.
First of all, you should know that when a user types your web address or clicks on a link that leads to your page, several steps happen, although for this article we are going to simplify it a lot with these steps:
- A request is made to your URL and this request arrives at the DNS (Domain Names Service) which is responsible for carrying the request to the web server that hosts your page.
- The request arrives to your server and as it is through port 443 (SSL port for https, 80 for http we don’t even talk about it), it is managed by the web server (Nginx, Litespeed, Apache if there is no other choice).
- The web server calls the processes in charge of generating the web page that the end user will see, that is, our CMS which is WordPress and that in the background is the PHP programming language executing different commands.
Well, here we already have the three basic levels on which we can plan our web security.
The higher you act on the security level (which would actually be at a lower level), the more secure it will be, the more control you will have over a possible attack and the more independent it will be from our hosting service.
Let’s see an example of each type, well, the same example from all three levels:
At DNS level
At the DNS level or before it reaches our web server, we have several services available. For example, the different WAF (Web Application Firewall, defense of the layer 7 protocol in the OSI model), whether it is the AWS Network Firewall if we are on AWS services, the Sucuri WAF or the Cloudflare services with its WAF, among other tools.
In this case I’m going to talk about Cloudflare with a brief example, since the next WordPress security article will be precisely about WordPress security from Cloudflare.
One of the most common attack attempts in any WordPress installation is the attack on the XML-RPC service, which most websites do not use. Well, we are going to block access attempts before they reach our web server.
To use Cloudflare’s security services, we will have to manage the DNS from your network.
Once we meet this condition, we will create a rule from the corresponding domain in our account, Security, WAF, Firewall Rules and Create a firewall rule button. We give it the name we want, for example Block XMLRPC (yes, I know it is not very original) and from the visual constructor we create the following rule:
For this we will use the Field “URI Path” with the Operator “contains” and the Value “/xmlrpc.php”, selecting in the action “Lock”.
If we click on Edit expression, we can directly copy the following content:
(http.request.uri.path contains "/xmlrpc.php")Now we can put the web address in our browser and see how it appears blocked by the Cloudflare Firewall without the request reaching the web server. If we wait a few hours and the site has some traffic, we will see the predictions received and blocked.
From the web server
In this example we are going to deny requests to the file xmlrpc.php (the one in charge of this protocol), from the Nginx web server by putting the following code in our configuration file:
fastcgi_hide_header X-Pingback;
proxy_hide_header X-Pingback;
location = /xmlrpc.php {
deny all;
}
From WordPress
It is possible to disable the service in our WordPress by using a filter, so we can put the following code in the functions.php of our child theme or in our customizations plugin:
add_filter( 'xmlrpc_enabled', '__return_false' );
Or perform this same task by means of plugins, for example:
- Disable XML-RPC https://wordpress.org/plugins/disable-xml-rpc/
- Disable XML-RPC-API https://wordpress.org/plugins/disable-xml-rpc-api/
- Manage XML-RPC https://wordpress.org/plugins/manage-xml-rpc/
- Remove & Disable XML-RPC Pingback https://wordpress.org/plugins/remove-xmlrpc-pingback-ping/
Or most security plugins that include this option, be it Wordfence Security, iThemes Security, SiteGround Security or any other security plugin.
In the previous examples we have seen how to stop the XML-RPC access attempt from three different levels. A hypothetical very intense attack to our XML-RPC protocol and from several simultaneous fronts could take down our server if PHP is running in each request. It would be a bit more difficult if we stop it before reaching the PHP layer, acting from the web server (in this case Nginx) and impossible, since it would not reach our server if we act at DNS level.
In the case of Cloudflare’s WAF, it could be brought down in a worldwide coordinated attack, but if Cloudflare goes down, which although possible is also very unlikely, your server would have already stopped working billions of requests before.
And as I mentioned a few lines ago, the third and last post of this security triad, will be about different useful rules to apply from Cloudflare and block malicious attempts to attack our website before they reach it.
P.S.: First article: Is my website secure?
Third article: WordPress security from Cloudflare.
