The two most common reasons for security issues in WordPress projects I have handled in the past are:
- The website does not have security protection plug-ins installed, or it is installed but not activated for some reason.
- Accounts with high authority (Subscriber and above) used weak passwords or reused the same passwords and were leaked on other websites.
The vast majority of WordPress websites are not high-value attack targets. As long as you can take the above two protections, you don’t need to worry about being hacked.
There are three first-line security plug-ins: WordFence , Sucuri , and iThemes Security Pro . Friends who don’t have much budget at the moment can start with the free version of WordFence .
After WordFence is installed and activated, it will automatically prompt to set up the firewall. It can automatically detect the web server (nginx or apache) and automatically configure it. Ordinary webmasters can also easily activate the application firewall (WAF), which can handle most automatic attack methods such as wp- Admin brute force cracking, various SQL Injection, PHP Injection, XSS attacks… When you first open the firewall, you may be in Learning Mode. Don’t worry, WF will set a date to turn on protection. In learning mode, the plug-in will still synchronize a large amount of data from the official website. Protection rules, 99% of firewalls are actually turned on.
Another WF function you need to turn on is scheduled scanning (Scan). You can find the configuration options in All Options => Scan Scheduling. The free version only provides the option to let WF schedule the scan time by itself. The paid version allows the webmaster to specify the scan. time. For websites that have a history of being hacked (and later restored), I recommend that you set the Scan Type to High Sensitivity. Some WordPress malicious codes are very cunning, may be re-infected, and may be very hidden. I once helped a client deal with an advertising Trojan. , the infection method is to impersonate the well-known Matomo statistics js import code, without the knowledge of the customer (who also happens to be using Matomo), the Trojan ran on the website for several months before it was finally discovered by Google reporting dangerous websites.
Also, make sure these email alert (notification) options are turned on in Email Alert Preferences:
- Email me if Wordfence is deactivated (email alarm when WF is closed)
- Email me if the Wordfence Web Application Firewall is turned off (email alarm when the WF firewall is turned off)
If you can use WordFence correctly, 95% of the website’s security problems have been solved. The other 4% of security problems are often due to perceived laziness. For example, accounts assigned to Author, Editor, or even Administrator permissions use good memories but are very weak. Passwords, or users who lack security awareness simply use their most commonly used passwords, and this password has long been leaked due to security flaws in other platforms.
It’s not difficult to force WordPress core account processes (signup, login, forgotten password) to use strong passwords. The settings provided by WordFence are:
- Enforce strong passwords
- Check password strength on profile update (force strong password when users modify information)
However, WF may not be able to intervene in non-WordPress core account processes, such as various form plug-ins that can replace the default registration login form, and various third-party account process plug-ins. Not all of them have such strong security awareness. If you use such plug-ins , you need to pay attention to the security instructions in the document, or contact the author on how the plug-in will protect user accounts.
For the problem of repeated passwords, WF also has protection options:
- Alert when someone is blocked from logging in for using a password found in a breach (Alert when a website user logs in to the website with a leaked password)
But it may not be a technical issue, but a process issue. To prevent password reuse in the process, accounts with write permissions must be assigned by administrators (assigning strong passwords that cannot be repeated), rather than registered by users themselves. Turn off the ability to manually change passwords for such accounts through technical means:
add_filter( 'allow_password_reset', 'wss_disable_password_reset' );
funciton wss_disable_password_reset() {
if（current_user_can('edit_posts') || current_user_can('manage_options')) {
return false;
}
return true;
}Of course, there are more things that can be done to harden the security of a WordPress site, but I am afraid that the vast majority of WordPress webmasters do not have the time and technical ability to do more in-depth configurations. I am confident that if readers can solve the problems described in this article, Two types of questions can ensure the security of your WordPress website. I repeat:
- Using security plugins, you can start with WordFence
- Enforce strong passwords and prevent password reuse from the process
More links:
Leave a Reply