WordPress Security Optimization

Hacking and cyber attacks can cause massive server performance problems if not outright interruptions. Many people have no idea how often servers get attacked because they never see the logs. Every server will be attacked several thousand times (sometimes as many as 1,000 times) each month. Your site might even be attacked right now, but you just don’t know it.

Securing against these attacks requires a delicate balance. You don’t want a server that lets hackers freely bombard your ports and resources. But you also don’t want a server that’s too secure and excessively auditing all traffic to the point that it slows your users or worse (it blocks legitimate users).

Security Optimization Tips

• Shutdown Unnecessary Server Services (ADV, HIGH)
• Server firewall configuration (ADV, HIGH)
• Server Brute Force Protection (ADV, HIGH)
• Brute-Force Protection on wp-login.php (BEG, HIGH)
• HTTP Authentication (BEG, MED)
• Disable XML-RPC Protocol (BEG, MED)
• Security Plugin Configuration (BEG-INT, MED)
• DNS Edge-Level Security Configuration (BEG, MED)
• HTTPS and HTTPS Redirect (BEG, LOW)

Shutdown Unnecessary Server Services (ADV, HIGH)

You can think of unused services as unused phones or email accounts. They sit around eating up resources (MEMORY) and take up your time with unwanted connections (SPAM, HACKERS). Whatever you’re not using, disable it from your server!

• DNS – disable if using an external DNS server (Cloudflare, DNSME, etc.)
• Email – disable if using 3rd-party email (G-Suite, MXroute, etc.)
• FTP/SFTP – disable if not using
• Other proxies – like Varnish

Many of these services are enabled by default with your server stack or control panel. You can read their documentation to get a list. For services that need to be running, you can limit their exposure to bad traffic using firewalls.

Server firewall configuration (ADV, HIGH)

Most default firewall configurations are set too laxly to avoid causing issues. You should jump in there and block off as much as possible. Some examples of logic are below:

• Ports used by specific people (SSH, FTP) – only you or a few others. Do an IP whitelist and block the rest.
• Ports used by certain countries (POP3, IMAP, FTP) – if some services are only used from within one country, you can block all other countries. Be careful, though, as someone traveling will lose access!
• Ports attacked only by certain countries – if you have many attacks coming from certain countries or regions, you can ban them by country or entire IP ranges.

There are many server firewalls out there. Each has its own pros and cons and is recommended for different use cases. You can read up online on how others use and configure them. It’s easiest to start with the default one that comes with your stack.

Server Brute Force Protection (ADV, HIGH)

Brute-force protection is like a smart firewall. It leaves services and ports open but automatically bans the obvious offenders.

• It automatically bans anyone who enters incorrect authentication or uses blacklisted generic usernames, etc.

They’re easy to set and very powerful. Just be careful that they don’t block legitimate users/traffic. You can see what brute-force or DDoS protection is included with your server and enable it. Maybe don’t set it so strictly if you have many users on this server.

Brute-Force Protection on wp-login.php (BEG, HIGH)

The WordPress admin login page is often bombarded by bots trying random usernames and passwords to get through. While they might not get in, their constant attempts eat up lots of resources. There are several ways to prevent them, each with its pros and cons.

• Server-level brute force protection – easy and efficient, but can lock out legitimate users on busy servers with sites using Cloudflare. The problem is that brute-force lockouts are blocked by IP, and visitors coming in via Cloudflare all share the same (proxy) IP address. Sure, you can configure to pass the true client IP through Cloudflare headers, but this slows down page load!
• Application-level brute-force protection – many WordPress security plugins can provide this. They secure the login page by banning users with bad credentials.
• Some plugins hide the login page – moving it to a different URL. Just make sure the standard login URL is either blocked or cached to prevent visits to it from using resources.
• Other plugins protect the login form by putting a captcha and banning certain robots, crawlers, and devices. This can work well but might annoy or false-flag legitimate users.

The only server I know with native brute-force protection on wp-login.php is LiteSpeed. All other servers (Apache & NGINX) will have to enable it with either a security plugin or HTTP auth.

HTTP Authentication (BEG, MED)

Do you have specific pages being bombarded with requests and no convenient way to block access to them? HTTP AUTH is a quick-and-dirty way of locking out all users. The only problem is it’s a slight hassle for legitimate users. Most guides show you how to protect the wp-admin directory, but you can protect other frequently-visited ones as well.

• Setup HTTP AUTH on Apache/LiteSpeed
• Setup HTTP AUTH on NGINX
• Handy HTTP AUTH password generator

Disable XML-RPC Protocol (BEG, MED)

The XML-RPC protocol allows external apps (like mobile apps), to log into your WordPress and edit content or view WooCommerce sales. Unfortunately, it’s often exploited by hackers and bots brute-forcing their way into your site.

• If you don’t use it, disabling XML-RPC prevents server slowdowns caused by the thousands of XML-RPC hack requests.
• If you need to leave it on, you can whitelist your IPs (and Jetpack IPs, if you use it).

Security Plugin Configuration (BEG-INT, MED)

If you don’t have access to your server, you can use security plugins. Yes, security is more efficiently run at the server level (closer to raw computing power) than at the application level (slower PHP processing). However, sometimes, it’s hard to set global security rules when you have many clients/sites and each one needs something different.

Nonetheless, a software-level security plugin like WordFence remains a useful option for blocking attacks that the server doesn’t, and/or preventing hacked sites from causing more damage.

• My favorite WordPress security plugin is WordFence.
• The most important feature of security plugins IMO is malware scanning. Scan manually or schedule during low-traffic hours. This feature doesn’t necessarily improve website speed, it detects system exploits and prevents them from using up resources (hosting spam sites or attacking other servers).
• The firewall features in security plugins probably aren’t needed if you already have a server firewall. Firewalls activated at the PHP level slow all incoming requests.

The performance problem with security plugins is due to overly aggressive filtering of all incoming traffic and frequent scanning. Both eat up many resources, especially on large sites with many pages and visitors. I suggest not using a software firewall, and also setting your malware scans to a slower speed.

DNS Edge-Level Security Configuration (BEG, MED)

Remember how I said that security is more efficiently done at the server level than at the application level? Well, doing it at the edge level (DNS level) can be even more efficient than at your server level since it’s using someone else’s servers. There are some performance implications between dealing with security at the edge VS on your server. You can decide what works best for your use case.

• Dealing with security on your server can be more convenient since you have more control. You can optimize for your specific use. The only downside is that it uses your server resources, and you also need admin skills.
• Dealing with security via another server (like a DNS proxy or Cloudflare) or a security service (Sucuri) saves your server's precious resources but might introduce a slight load delay, since visitors must pass through an extra proxy before reaching your web server.

The weaker your server and server-admin skills, the more likely a security service is to be more efficient at blocking DDoS requests. Then again, for a smaller site, you might not have so many security problems. Whatever you do, don’t try to put overly aggressive DDoS security at both levels (DNS & server). This can cause false positives where legit visitors are blocked because all visitors (good and bad) share the same IP when coming through a proxy.

• Most people don’t have to worry about DDoS attacks, ok?
• Most lower-level DDoS attacks are easily handled by your server.
• The highest-level DDoS attacks overwhelm servers (even with good security), but they require money and concentrated effort from hackers. Unless someone is specifically targeting you, you don’t have to worry about them.
• The easiest way to deal with high-level DDoS attacks is to immediately sign up with a dedicated security company like Sucuri (when it happens).
• I don’t recommend paying for fancy security services you'll mostly never need.

HTTPS and HTTPS Redirect (BEG, LOW)

• You should absolutely be using HTTPS. (It’s the only way to get the benefits of the HTTP/2 protocol.)
• Set up 301 HTTPS redirects on your server so visitors are quickly redirected to the correct HTTPS protocol and domain version of your site (with or without “www”). Without these server redirects, WordPress can still do it but it takes a little longer.

Also, don’t forget to ensure all your internal URLs use HTTPS. Don’t rely on SSL plugins (unnecessary) or WordPress (slow) to redirect you. Set the redirects from the server!