The more popular a system becomes, the more attractive it becomes to attackers. WordPress is the most popular CMS in the world, which means WordPress sites on the internet are constantly being targeted. Many client sites are hosted on our servers, so maintaining their security is a serious ongoing responsibility.
Common Types of Attacks Against WordPress
Most attacks against WordPress are performed at scale. Attackers scan large numbers of sites with automated tools and then try whatever exploit matches the target. Because there are so many WordPress sites online, large-scale scanning is far more efficient than attacking one site manually.
Brute-Forcing FTP, Server Accounts, and Administrator Logins
Brute-force attacks are one of the oldest and least sophisticated attack types, but they are still common because they are easy to automate. The good news is that they are also relatively easy to defend against.
- FTP sends passwords in plain text, which is a major weakness. Our solution is simple: we do not expose FTP at all. All code is deployed through Git.
- For server account brute-force attempts, all of our servers run CentOS and are configured to block an IP after several failed login attempts.
- For WordPress administrator accounts, we require strong passwords and recommend avoiding the default
adminusername. With those two measures alone, password guessing becomes much harder. We can also use tools such as Fail2ban to block repeated login attacks.
Even so, administrator passwords can still be leaked. The important question is how to limit damage if that happens. I will come back to that below.
Injecting Code Through Server or WordPress Vulnerabilities
This is also a very common attack type. In many cases, the goal is to inject spammy links into a WordPress site without obviously breaking the site for normal visitors. Based on our experience, a lot of this traffic comes from automated attacks rather than carefully targeted human attackers.
Our protection strategy is to make all WordPress core files, theme files, and plugin files read-only. That way, even if WordPress has an unpatched or undiscovered vulnerability, an attacker still cannot easily modify the application code. The only location that remains writable is the uploads area, which users genuinely need.
Denial-of-Service and DDoS Attacks
DDoS attacks are more malicious and usually target a specific site. Sometimes this is the result of conflict, and sometimes it is caused by unfair competition. The attacker floods the site with fake traffic until the server or the network becomes overloaded and real users can no longer access the website.
You can mitigate part of this traffic on the server itself, but that is rarely enough. In practice, this kind of problem often requires help from the hosting provider or a dedicated mitigation service.
Disable Back-End Code Editing in wp-config.php
If an administrator password is leaked, one of the biggest risks is that the attacker can install or edit themes and plugins directly in the WordPress dashboard. Our approach is to disable theme and plugin editing and installation in the admin area. Users can still see installed themes and plugins, enable or disable plugins, and switch themes, but they cannot edit files or install new packages from the dashboard. When something new must be deployed, we do it through Git.
This also helps protect less experienced users from accidentally breaking a site by editing code in the dashboard. Add the following lines to wp-config.php:
// Disallow editing and modifying files from the dashboard
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);Many brute-force attacks exist only to plant hidden spam links. Even if they do not take the site down, it is still safer to disable back-end code editing before that kind of compromise ever happens.
Regularly Check User-Generated Directories
For example, the uploads directory should never contain arbitrary PHP files during normal use. If PHP files appear there, something is wrong. The safest approach is to back them up somewhere outside the web root first and then remove them after investigation.
Because our sites all use URL rewriting, there are very few legitimate reasons for direct public access to random PHP files. Reviewing access logs regularly, especially requests that directly target PHP files, makes it much easier to detect suspicious behavior and find injected code early.
Scheduled Off-Site Backups
Our backup strategy is simple: code files are backed up off-site weekly, and databases are backed up off-site every day. Even if the entire server is lost, the damage is usually limited to at most one day of database changes.
Good backups do not prevent attacks, but they are what keep a bad day from becoming a catastrophe. For anyone running many WordPress sites on one server, that safety net is not optional.
