Security is one of the most important parts of any computer system. For this reason, in web environments where we work with important data from visitors and customers, we must pay close attention to security.
WordPress is the most used CMS in the world, with a much higher market share than its competitors. As a consequence, it is also the most attacked and the one that is most sought for “tickles” to try to access the data.
Unfortunately, most WordPress hacking or intrusion cases are not the results of being the most attacked CMS, but of bad practice or mismanagement on the part of the website administrator. You don’t have to be a great expert to protect WordPress from hackers and other types of attackers: you just need to apply logic and pay attention.
On the other hand, I strongly condemn the use of WordPress security suites, that is, all-in-one plugins like iThemes Security, WordFence Security, or All in One Security.
The reason? Well, under normal circumstances, you will not use 90% of the functionalities that they bring and others (such as live analysis systems or firewalls that analyze live traffic) will consume excessive resources and slow down the loading of the website.
Personally, I prefer to implement the functionalities separately as I need them instead of installing one of these giants that are the cause of the poor performance of many websites due to PHP overload.
To understand this, you must first know that running a WAF at the WordPress level (such as WordFence Security) is not the same as running a WAF at the server level such as mod_security with good rules. They neither consume the same resources (it consumes less mod_security), nor do they operate at the same level, nor are they equally effective.
In this post, we will talk about security for WordPress, but we will try to explain what fronts we must protect, when, and how to avoid damaging the user experience and the performance of the website.
To give you an idea of the performance impact of security suite plugins, they are always the first thing I disable when doing WPO work on a website.
A website with a live scan of WordFence Security (for example) will NEVER be able to compete in loading speed with a site that does not use it, since there will always be a delay due to the WordFence scan.
This is an example of overuse of resources and saturation of hosting with 1GB of RAM memory by the All in One Security plugin:
In the test of the previous capture, with the graphs of CloudLinux on cPanel, we can see the impact of activating this plugin on a web with traffic that was working well and without problems until the moment of activating the plugin.
Now that I have already commented on my intentions for this post, let’s go with the real introduction to the subject.
Prevention and logic: the two pillars
As I have said before, logic plays a very important role in WordPress security . Most cases of infection simply would not have happened if logic had been applied.
There are two weak points through which WordPress is usually hacked:
- Plugins that are not updated, have security flaws or are downloaded from malware sources.
- Weak passwords or insecure authentication.
These are just the two main reasons, but there are many more factors that affect the security of WordPress and many other things that we must take into account. However, I want it to be very clear that with basic security measures and a bit of logic and prevention, we can have a secure and completely protected WordPress against any type of threat.
Infections and “relapses”
Do you know what is the main reason why it is better that you NEVER get infected? Well, because if you get infected once, you will have to perform complete disinfection of your website if you do not want to be infected again and again.
During an infection, in addition to deleting files, the attacker can modify many WordPress files and plugins, causing that, even if you delete the files you see with the naked eye, there may be a Trojan horse that gives the attacker access again.
This is why WordPress sanitization processes exist. At Raiola Networks we have been offering this service in a specialized way since 2014. The important thing is that you know that if you have been infected and you have not disinfected your WordPress as thoroughly as possible, it is most likely that your installation is still infected.
Plugins: What should we take into account?
As we have already said, WordPress plugins are one of the weak points with the most possibilities of being hacked if we are not careful.
The ideal is to update the plugins whenever a new version appears. This is what the theory says, but in practice… well, we must adapt to the developer and to the operating bugs. An example of this is Yoast SEO, which would be suicidal to update on the same day the update is released, as it has caused many websites to crash lately for this reason.
In addition to plugins not being updated, there may be different reasons why a WordPress is infected through plugins :
- That the plugins have not been updated for a long time or that their author has abandoned development.
- That a security flaw or zero-day appears and that the possibilities of defense are low due to the “novelty”.
- That the plugin is nulled or downloaded from an unreliable source, that it brings malware or a backdoor.
Knowing this, we can make certain decisions, although in some cases it is difficult to carry out these decisions due to the work they give.
If the plugin is no longer updated
If the plugin in question has not been updated for a long time and its development has been stopped for more than 6 months or if a zero-day has appeared and the plugin has not been updated for a long time, we must change that plugin.
I understand the difficulty of changing one plugin for another, especially when we are looking for certain specific functionalities, but it is VERY necessary and we should not be lazy, for the sake of the security of our WordPress.
If the plugin is nulled or contains malware
It is very common for certain attackers to have websites where that offer Premium plugins with a cracked license in order to infect those who install these plugins.
It is a great claim for many people who are looking for premium plugins for free. This makes this one of the main reasons for infection. In fact, even if we install them just to test and uninstall them later, modified or hidden files may remain to infect you months later by order of the attacker.
What I have just explained is something VERY common and the main reason for infection.
If a zero-day appears in a plugin
Something we cannot prevent is a zero-day. Although in some cases we can protect the website with a WAF, it depends on the nature of the attack.
If a zero-day appears in a plugin, the idea is to reinforce security with a WAF while the author does not publish an update, although this does not guarantee anything. Certain reverse proxy systems, such as Cloudflare or Sucuri, can help you protect your website in these cases.
As I said before, if the plugin in question does not receive updates for a long time, we should immediately change it to an alternative that does the same and receives updates.
Manage plugin updates
As I have already mentioned, the theory says that we should update the plugins as soon as the most current versions are released.
This is the theory, but in practice, it can be difficult to manage updates for a bunch of WordPress installations with different plugins and configurations.
For this, there are tools like InfiniteWP, which offer us the possibility of managing the updates of many installations at the same time.
In version 5.5 of WordPress, auto-updates of plugins installed from the official WordPress repository are implemented.
This is good but also bad since the updates will be made right when they are released and this can cause crashes on your website.
Themes: What should we take into account?
WordPress themes and templates work the same way as plugins. We must take the same precautions and carry out the same preventive actions as in the case of supplements.
The themes can also be downloaded nulled and with malware from “pirate” pages, they also receive constant updates and we must also change them if they stop updating.
The problem with themes is that, in many cases, code modifications are made without implementing a child theme. This causes many administrators to be reluctant to update the theme.
If we have a theme without updates for a long time, they can infect us in the same way as through plugins. We must change it for another one even if this supposes extra work for “redesign”.
WordPress updates
WordPress core also needs to be updated from time to time. This type of update must go accordingly with the updates of the plugins and themes. What do I mean by this? Well, if we update all the plugins to the latest version available, the ideal is to have WordPress in the latest stable branch to avoid compatibility problems.
For quite some time, WordPress has had an auto-update system that can automatically update minor versions within the same stable branch. However, it requires manual intervention to switch branches or for major updates.
Currently, it is very “rare” for WordPress to be hacked due to a security flaw in WordPress itself since normally the problems come from security flaws in plugins and themes. Even so, we must have WordPress updated to the latest version of the branch we are on, preferably the latest.
Remember that you can roll back to the latest version of WordPress. If you don’t know how to do it, take a look at this post on how to go back to the previous version of WordPress.
Secure access and authentication
As I said before, authentication is one of the weak points of WordPress.
In many cases, the problem may be the access password, but in many others, the problem comes from the environment in which one of the website administrators works.
The good thing is that there are methods to secure all these parts and avoid brute force attacks against accesses, at the same time that we block all possible attackers.
Passwords and authentication
Although it seems insignificant, in many cases the intrusions come from the users’ own passwords.
In this area, we find two weak points that we must take into account:
- Weak passwords that we must strengthen.
- Phishing cases where passwords are stolen from an administrator’s computer.
Sometimes these two weaknesses are combined with excessive permissions or misconfigured user roles.
Strengthening a password has no science, it is pure logic: you have to put a strong password and be able to generate it.
As for phishing and other password stealing techniques on a website administrator’s computer, I won’t say much as I don’t want to get into Windows security issues. The basic thing is to have a good antivirus on your computer if you use Windows and take certain precautions in Macintosh or Linux environments. The rest is also a matter of prevention and logic, as in the case of WordPress.
There is another way to protect access to WordPress, through two-step authentication. If you want to know how to implement two-step or two-factor authentication in WordPress, you can watch the following video:
Other methods, such as USB Key access, can also be used.
The objective of these two methods is to dispense with passwords and make access to private areas, such as the WordPress dashboard, as secure as possible.
Change WordPress login URL
In addition to all of the above, we can protect WordPress access URLs by changing them.
This is something that other CMS, like Prestashop, allow natively. However, in the case of WordPress, we must use plugins.
To give you an idea, 99.9% of attacks are carried out by bots that identify and follow patterns. Among those patterns is attacking default login URLs if they detect a CMS.
Some security suites, like WordFence Security or iThemes Security, allow you to change the URL of wp-admin and wp-login.php, but you don’t need to use such heavy plugins to do this. With plugins like Change wp-admin login, we can change the URL easily and for free: https://es.wordpress.org/plugins/change-wp-admin-login/
Block brute force attacks
To block brute force attacks we can use different methods implemented in different parts of the web environment.
A brute force attack is considered to have taken place when the attacker performs authentication attempts in order to find the correct access password. Ideally, these users should be blocked after X access attempts (for example, after 5 failed attempts).
This can also be done with most WordPress security suites, but I find it unnecessary to spend resources on complex plugins when there are much simpler ones that already cover this functionality.
The easiest way to block WordPress brute force attacks is to use plugins like Limit Login Attempts: https://es.wordpress.org/plugins/limit-login-attempts-reloaded/
It is also possible, as is the case with Raiola Networks shared hosting servers, that the server has mod_security with fail2ban, which blocks failed access attempts directly from the server much more effectively.
WAF or Web Application Firewall
I’ve been quite a fan of WAF or Web Application Firewall for a long time and what they can do for any website at a security level.
A well-implemented WAF can consume few resources and at the same time protect WordPress even from never-before-seen threats.
We have three ways to configure a WAF in WordPress: through service on the server, through an external service, or through a plugin.
In the case of a WAF on the server, systems like mod_security are normally used.
If we are looking for a plugin to implement a WAF in WordPress, we can do it with iThemes Security or WordFence Security, but there are also other powerful solutions that consume few resources, such as Ninja Firewall:
As for external services to implement a WAF, CloudFlare is an example. Cloudflare can protect any website if we know how to configure it correctly, but we will talk about this in the next section.
Cloudflare as a firewall
I love Cloudflare. I think it is an exceptional CDN, the fastest anycast DNS in the world according to DNSPerf, and also an excellent firewall or WAF when placed as a reverse proxy of a website.
Cloudflare allows us to implement some tweaks to protect the website we configure it for:
StartBlogwordpressSecurityWordPress security guide
WordPress security guide
Security is one of the most important parts of any computer system. For this reason, in web environments where we work with important data from visitors and customers, we must pay close attention to security.
WordPress is the most used CMS in the world, with a much higher market share than its competitors. As a consequence, it is also the most attacked and the one that is most sought for “tickles” to try to access the data.
Unfortunately, most WordPress hacking or intrusion cases are not the results of being the most attacked CMS, but of bad practice or mismanagement on the part of the website administrator. You don’t have to be a great expert to protect WordPress from hackers and other types of attackers: you just need to apply logic and pay attention.
On the other hand, I strongly condemn the use of WordPress security suites, that is, all-in-one plugins like iThemes Security, WordFence Security or All in One Security.
The reason? Well, under normal circumstances, you will not use 90% of the functionalities that they bring and others (such as live analysis systems or firewalls that analyze live traffic) will consume excessive resources and slow down the loading of the website.
Personally, I prefer to implement the functionalities separately as I need them instead of installing one of these giants that are the cause of the poor performance of many websites due to PHP overload.
To understand this, you must first know that running a WAF at the WordPress level (such as WordFence Security) is not the same as running a WAF at the server level such as mod_security with good rules. They neither consume the same resources (it consumes less mod_security), nor do they operate at the same level, nor are they equally effective.
In this post, we will talk about security for WordPress, but we will try to explain what fronts we must protect, when, and how to avoid damaging the user experience and the performance of the website.
To give you an idea of the performance impact of security suite plugins, they are always the first thing I disable when doing WPO work on a website.
A website with a live scan of WordFence Security (for example) will NEVER be able to compete in loading speed with a site that does not use it, since there will always be a delay due to the WordFence scan.
This is an example of overuse of resources and saturation of hosting with 1GB of RAM memory by the All in One Security plugin:
In the test of the previous capture, with the graphs of CloudLinux on cPanel , we can see the impact of activating this plugin on a web with traffic that was working well and without problems until the moment of activating the plugin.
Now that I have already commented on my intentions for this post, let’s go with the real introduction to the subject.
We won’t spam you, we promise! We send our subscribers our content on WordPress, hosting, digital marketing, and programming.EmailBasic information on data protection: Privacy Policy I have read and accept the privacy policy *https://www.google.com/recaptcha/api2/anchor?ar=1&k=6Lc1StoUAAAAAKI1oisF2YzV-7RTJVYac8d9mYBf&co=aHR0cHM6Ly9yYWlvbGFuZXR3b3Jrcy5lczo0NDM.&hl=en-GB&type=v3&v=Y-cOIEkAqcfDdup_qnnmkxIC&size=invisible&badge=bottomright&sa=Form&cb=mceyu1tyuh2SEND
Prevention and logic: the two pillars
As I have said before, logic plays a very important role in WordPress security . Most cases of infection simply would not have happened if logic had been applied.
There are two weak points through which WordPress is usually hacked:
- Plugins that are not updated, have security flaws, or are downloaded from malware sources.
- Weak passwords or insecure authentication.
These are just the two main reasons, but there are many more factors that affect the security of WordPress and many other things that we must take into account. However, I want it to be very clear that with basic security measures and a bit of logic and prevention, we can have a secure and completely protected WordPress against any type of threat.
Infections and “relapses”
Do you know what is the main reason why it is better that you NEVER get infected? Well, because if you get infected once, you will have to perform complete disinfection of your website if you do not want to be infected again and again.
During an infection, in addition to deleting files, the attacker can modify many WordPress files and plugins, causing that, even if you delete the files you see with the naked eye, there may be a Trojan horse that gives the attacker access again.
This is why WordPress sanitization processes exist. At Raiola Networks we have been offering this service in a specialized way since 2014. The important thing is that you know that if you have been infected and you have not disinfected your WordPress as thoroughly as possible, it is most likely that your installation is still infected.
Plugins: What should we take into account?
As we have already said, WordPress plugins are one of the weak points with the most possibilities of being hacked if we are not careful.
The ideal is to update the plugins whenever a new version appears. This is what the theory says, but in practice… well, we must adapt to the developer and to the operating bugs. An example of this is Yoast SEO, which would be suicidal to update on the same day the update is released, as it has caused many websites to crash lately for this reason.
In addition to plugins not being updated, there may be different reasons why a WordPress is infected through plugins :
- That the plugins have not been updated for a long time or that their author has abandoned development.
- That a security flaw or zero-day appears and that the possibilities of defense are low due to the “novelty”.
- That the plugin is nulled or downloaded from an unreliable source, that it brings malware or a backdoor.
Knowing this, we can make certain decisions, although in some cases it is difficult to carry out these decisions due to the work they give.
If the plugin is no longer updated
If the plugin in question has not been updated for a long time and its development has been stopped for more than 6 months or if a zero-day has appeared and the plugin has not been updated for a long time, we must change that plugin.
I understand the difficulty of changing one plugin for another, especially when we are looking for certain specific functionalities, but it is VERY necessary and we should not be lazy, for the sake of the security of our WordPress.
If the plugin is nulled or contains malware
It is very common for certain attackers to have websites where that offer Premium plugins with a cracked license in order to infect those who install these plugins.
It is a great claim for many people who are looking for premium plugins for free. This makes this one of the main reasons for infection. In fact, even if we install them just to test and uninstall them later, modified or hidden files may remain to infect you months later by order of the attacker.
What I have just explained is something VERY common and the main reason for infection.
If a zero-day appears in a plugin
Something we cannot prevent is a zero-day. Although in some cases we can protect the website with a WAF, it depends on the nature of the attack.
If a zero-day appears in a plugin, the idea is to reinforce security with a WAF while the author does not publish an update, although this does not guarantee anything. Certain reverse proxy systems, such as Cloudflare or Sucuri, can help you protect your website in these cases.
As I said before, if the plugin in question does not receive updates for a long time, we should immediately change it to an alternative that does the same and receives updates.
Manage plugin updates
As I have already mentioned, the theory says that we should update the plugins as soon as the most current versions are released.
This is the theory, but in practice, it can be difficult to manage updates for a bunch of WordPress installations with different plugins and configurations.
For this, there are tools like InfiniteWP, which offer us the possibility of managing the updates of many installations at the same time.
In version 5.5 of WordPress, auto-updates of plugins installed from the official WordPress repository are implemented.
This is good but also bad since the updates will be made right when they are released and this can cause crashes on your website.
Themes: What should we take into account?
WordPress themes and templates work the same way as plugins. We must take the same precautions and carry out the same preventive actions as in the case of supplements.
The themes can also be downloaded nulled and with malware from “pirate” pages, they also receive constant updates and we must also change them if they stop updating.
The problem with themes is that, in many cases, code modifications are made without implementing a child theme. This causes many administrators to be reluctant to update the theme.
If we have a theme without updates for a long time, they can infect us in the same way as through plugins. We must change it for another one even if this supposes extra work for “redesign”.
WordPress updates
WordPress core also needs to be updated from time to time. This type of update must go accordingly with the updates of the plugins and themes. What do I mean by this? Well, if we update all the plugins to the latest version available, the ideal is to have WordPress in the latest stable branch to avoid compatibility problems.
For quite some time, WordPress has had an auto-update system that can automatically update minor versions within the same stable branch. However, it requires manual intervention to switch branches or for major updates.
Currently, it is very “rare” for WordPress to be hacked due to a security flaw in WordPress itself since normally the problems come from security flaws in plugins and themes. Even so, we must have WordPress updated to the latest version of the branch we are on, preferably the latest.
Remember that you can roll back to the latest version of WordPress. If you don’t know how to do it, take a look at this post on how to go back to the previous version of WordPress.
Secure access and authentication
As I said before, authentication is one of the weak points of WordPress.
In many cases, the problem may be the access password, but in many others, the problem comes from the environment in which one of the website administrators works.
The good thing is that there are methods to secure all these parts and avoid brute force attacks against accesses, at the same time that we block all possible attackers.
Passwords and authentication
Although it seems insignificant, in many cases the intrusions come from the users’ own passwords.
In this area, we find two weak points that we must take into account:
- Weak passwords that we must strengthen.
- Phishing cases where passwords are stolen from an administrator’s computer.
Sometimes these two weaknesses are combined with excessive permissions or misconfigured user roles.
Strengthening a password has no science, it is pure logic: you have to put a strong password and be able to generate it.
As for phishing and other password stealing techniques on a website administrator’s computer, I won’t say much as I don’t want to get into Windows security issues. The basic thing is to have a good antivirus on your computer if you use Windows and take certain precautions in Macintosh or Linux environments. The rest is also a matter of prevention and logic, as in the case of WordPress.
There is another way to protect access to WordPress, through two-step authentication. If you want to know how to implement two-step or two-factor authentication in WordPress, you can watch the following video:
https://youtube.com/watch?v=hGLBPKd_i4c%3Ffeature%3Doembed%26enablejsapi%3D1%26origin%3Dhttps%3A
Other methods, such as USB Key access, can also be used.
The objective of these two methods is to dispense with passwords and make access to private areas, such as the WordPress dashboard, as secure as possible.
Change WordPress login URL
In addition to all of the above, we can protect WordPress access URLs by changing them.
This is something that other CMS, like Prestashop, allow natively. However, in the case of WordPress, we must use plugins.
To give you an idea, 99.9% of attacks are carried out by bots that identify and follow patterns. Among those patterns is attacking default login URLs if they detect a CMS.
Some security suites, like WordFence Security or iThemes Security, allow you to change the URL of wp-admin and wp-login.pBlock the XMLRPC.PHPhp, but you don’t need to use such heavy plugins to do this. With plugins like Change wp-admin login, we can change the URL easily and for free: https://es.wordpress.org/plugins/change-wp-admin-login/
Block brute force attacks
To block brute force attacks we can use different methods implemented in different parts of the web environment.
A brute force attack is considered to have taken place when the attacker performs authentication attempts in order to find the correct access password. Ideally, these users should be blocked after X access attempts (for example, after 5 failed attempts).
This can also be done with most WordPress security suites, but I find it unnecessary to spend resources on complex plugins when there are much simpler ones that already cover this functionality.
The easiest way to block WordPress brute force attacks is to use plugins like Limit Login Attempts: https://es.wordpress.org/plugins/limit-login-attempts-reloaded/
It is also possible, as is the case with Raiola Networks shared hosting servers, that the server has mod_security with fail2ban , which blocks failed access attempts directly from the server much more effectively.
FREE maintenance checklist
Improve the health of your WordPress!
- Email *
- Basic information on data protection:
- The privacy policy has read and accepted the privacy policy.
- CAPTCHAhttps://www.google.com/recaptcha/api2/anchor?ar=1&k=6Lc1StoUAAAAAKI1oisF2YzV-7RTJVYac8d9mYBf&co=aHR0cHM6Ly9yYWlvbGFuZXR3b3Jrcy5lczo0NDM.&hl=en-GB&v=Y-cOIEkAqcfDdup_qnnmkxIC&theme=light&size=invisible&badge=bottomright&cb=ngazusne43t6
WAF or Web Application Firewall
I’ve been quite a fan of WAF or Web Application Firewall for a long time and what they can do for any website at a security level.
A well-implemented WAF can consume few resources and at the same time protect WordPress even from never-before-seen threats.
We have three ways to configure a WAF in WordPress : through a service on the server, through an external service or through a plugin.
In the case of a WAF on the server, systems like mod_security are normally used.
If we are looking for a plugin to implement a WAF in WordPress, we can do it with iThemes Security or WordFence Security, but there are also other powerful solutions that consume few resources, such as Ninja Firewall:
If you want to see a little better how Ninja Firewall for WordPress works, you can watch this video tutorial:
https://youtube.com/watch?v=dMlueSs2OBk%3Ffeature%3Doembed%26enablejsapi%3D1%26origin%3Dhttps%3A
As for external services to implement a WAF, CloudFlare is an example. Cloudflare can protect any website if we know how to configure it correctly, but we will talk about this in the next section.
Cloudflare as a firewall
I love Cloudflare. I think it is an exceptional CDN, the fastest anycast DNS in the world according to DNSPerf, and also an excellent firewall or WAF when placed as a reverse proxy of a website.
Cloudflare allows us to implement some tweaks to protect the website we configure it for:
If we want to go a little further, we can set rules in the firewall that allow us to block depending on what we need.
And, most importantly, these blocks will be carried out completely externally and without impact on the performance of the hosting, that is, without consuming hosting resources.
Here is a video on the subject:
There are other options than CloudFlare for external security, such as Incapsula or Sucuri, but they are security-focused alternatives with almost no performance options. On the other hand, by blocking major attacks, Cloudflare (with its large worldwide network) has proven to be the best solution and the one of choice for many major websites.
Protect WordPress from SPAM
Currently, SPAM is very common on social websites where the user is given the possibility of interaction, such as blogs.
SPAM is not only annoying but, if certain links or certain keywords are inserted, it can be considered a negative SEO attack and cause us to lose positioning.
In WordPress, depending on the type of website, SPAM can go to different places :
- Spam users can be registered in WooCommerce online stores.
- In forums and communities, spammers can register and leave comments.
- In blogs, they can leave us spam comments.
- In any contact form, we can get spam.
What can we do to protect ourselves from spam? Well, depending on the area that we want to protect, we will have to carry out one or another action.
At Raiola Networks, we recommend three anti-spam techniques in web environments :
- Blocking through blacklists.
- Google Recaptcha V3 (the invisible).
- The honeypot technique.
Depending on the area where we want to apply it, we must use one technique or the other.
Protect WordPress comments
The native WordPress commenting system is quite limited and, as I always say, quite lacking because it hasn’t been updated in a long time.
The problem with WordPress comments is that they are easily discoverable by a bot using footprint. This makes them the target of many bot spammers.
We can protect comments in many ways. Even if we remove the URL field from the fields that users have to fill in, we will reduce the number of spammers because they will lose interest.
The most radical way to protect WordPress comments is to implement a captcha, but this can hurt the user experience quite a bit. The only captcha that does not harm the user experience is Google Recaptcha V3 because it is invisible.
Finally, we can use the honeypot technique to protect comments from SPAM. At Raiola Networks we have a WordPress plugin that allows us to apply this anti-spam technique: https://raiolanetworks.es/blog/anti-spam-wordpress/
Protect records from SPAM
This part is very easy to understand and apply.
If your website needs the registration part (ie online stores, social networks, forums, etc.) you must protect the registrations with blacklists.
If you have a normal blog or a corporate website where you do not need user registrations, you must disable them from the WordPress “Settings”:
In this way, no one will be able to register on our website and we will not have problems with this. However, sites that do not have user registration do usually have comments and contact forms that will have to be protected from SPAM.
Protect communities and forums
When we work with BuddyPress or similar communities and in WordPress forums such as bbPress or wpForo, it is necessary to cover all fronts where spam can enter.
The problem with websites that allow open user registration and a place to leave SPAM is that they are clear targets for bots. Based on the system used, they already identify patterns to register. When the bots do not arrive, the manual spam begins.
When manual SPAM starts, there is no longer anything to do with honeypot or captcha. We will have to resort to blacklists and systems like CleanTalk.
CleanTalk uses very comprehensive databases to detect spammers in both logs and content. For websites with content updated by users, such as forums or communities, it is the most complete I have found.
If you are looking for more information about CleanTalk, you can find the plugin here: https://es.wordpress.org/plugins/cleantalk-spam-protect/
It is a free plugin, but the service is paid for by subscription, although VERY cheap.
Protect forms in WordPress
To protect contact forms, I usually recommend Honeypot or Google Recaptcha V3 (invisible).
The way to implement this totally depends on the plugin with which we implement the contact form. I am going to go through parts giving you some cases that I am used to working with.
- Gravity Forms comes with its own module to implement honeypot protection, although it can also be complemented with Google Recaptcha V3 using this plugin: https://es.wordpress.org/plugins/cleantalk-spam-protect/
- Contact Form 7 must be protected by plugins. We can protect it with Honeypot ( https://wordpress.org/plugins/contact-form-7-honeypot/ ) or with Google Recaptcha ( https://wordpress.org/plugins/advanced-nocaptcha-recaptcha/ ).
- The Elementor Pro forms have a honeypot for a few versions and we simply have to activate it. The same goes for Google Recaptcha V3.
In other contact form plugins, the implementation depends on the case.
Other tweaks to protect WordPress
Although what we have explained in this post are areas or weak points of WordPress that we must pay attention to, there are other more specific parts of the CMS that we can modify with tweaks to protect our website.
Block the XMLRPC.PHP
Now, these types of attacks have dropped quite a bit, but a few years ago a series of problems appeared in WordPress that caused these types of attacks to become widespread.
The attack against XMLRPC.PHP was a brute force attack that was not blocked by most WAFs and caused significant server resource usage.
With plugins like Perfmatters, we can deactivate it, although there are also plugins like Manage XML-RPC that allow us to modify its operation: https://wordpress.org/plugins/manage-xml-rpc/
file and folder
Although this alone is not enough to protect a WordPress installation, it is very important to have everything covered.
WordPress, in its documentation, specifies some CHMOD permissions to put on the installation files and folders. This recommended configuration is what we should put: 755 for the installation folders and 644 for the.
If we want to go a little further, we can use this parameter in wp-config.php that blocks file editing, although we must bear in mind that we cannot even update plugins:
This is useful to shield the installation and protect us from certain code injections, although it is a rather annoying technique to manage the installation on a day-to-day basis.
Backups or security copies
And when all else fails… there are backups.
No matter how many precautions we take, there are cases where a catastrophe is predicted and we will not be able to do anything. For these cases, what we must have are backup copies available.
Currently, there is no excuse not to have WordPress backups. There are many ways to set them up automatically and with cloud saves (Dropbox, Google Drive, Amazon S3, etc.). We can do them from the server or from a WordPress plugin.
At Raiola Networks, we offer all our cPanel platform clients the Installatron tool , which is an application auto-installer that also allows you to manage configurations and backups :
As you can see, with Installatron you can not only create scheduled backups and upload them to the cloud automatically, but you can also restore them with one click without having any technical knowledge.
In Raiola’s cPanel hosting servers, we even have another powerful backup system called JetBackup, which creates incremental copies of the content and allows individual files to be restored.
In the case of VestaCP, it also has a backup tool for the accounts that you can create and restore with a click (in addition to the programmed ones, of course). However, this is a much less complete system:
If your server or hosting does not have a powerful backup system, if it does not directly have any, or if you want to go it alone and have your own backups, you can use a WordPress plugin. There are many WordPress backup plugins out there, but my favorites are BackWPup and Updraft Plus.
- BackWPup in its free version offers scheduled backups to Dropbox.
- Updraft Plus in its free version offers scheduled backups to Google Drive
- .
Do you see the difference between both plugins in their free version? If we compare them with their paid versions, they are more or less similar plugins with similar functionalities.
The problem with this type of WordPress plugin is that we cannot restore copies with a click, but to recover them we must upload the files to the server as if we were doing a migration.
There are solutions that allow one-click restore, but they are usually subscription-based or pay-per-use solutions that store the backup files on their own servers.
Another point is that it is advisable to test the saved backups from time to time to avoid finding corrupted copies if we ever need them to restore the web.
Finally, it must be remembered that backup copies, in case of infection, may be useless. If the web has been infected for a long time and this has not manifested itself, you may not have such old backups or you may not be able to restore them so as not to lose content. If this happens, the thing to do is disinfect.
WordPress Sanitization
As I said at the beginning of the post, at Raiola Networks we have been disinfecting WordPress installations for several years with a 100% success rate as long as the client pays attention to us and takes the appropriate measures after the infection.
In our sanitization process, we replace ALL WordPress files without exception with the original equivalents. When I say no exceptions, I mean NO EXCEPTIONS. No files can remain from the infected installation. If any file cannot be replaced (for example, the wp-config.php), we will have to check it manually.
To review the installation after disinfection we can use plugins such as Anti-Malware and Brute Force Firewall or even the WordFence Security scanner.
Checking the database is also recommended, as some types of infections can cause malware injections in the WordPress database.