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 get attacked several thousand times (sometimes in one hour) every 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 that it slows your users or worse (it blocks legitimate users).
Today we will share a set of tips on website security optimization provided by Johnny Nguyen in The Ultimate WordPress Speed Optimization Guide. Each security optimization below hint will be marked with the level of required skills to implement and the impact it will bring.
SKILL:
BEGINNER – can Google and follow instructions.
INTERMEDIATE – working as WordPress contractor.
ADVANCED – programmer or server-admin.
IMPACT:
LOW – maybe 100-200ms difference. Possibly unnoticeable.
MEDIUM – around 500ms difference.
HIGH – 1 second difference or more.
1. 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 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.
2. Server firewall configuration (ADV, HIGH)
Most default firewall configurations are set too lax to avoid causing issues. You should jump in there and block off as much as possible. Some example logic 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 country (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 country – if you have many attacks coming from certain countries or regions, you can ban by country or entire IP ranges.
There are many server firewalls out there. Each with their own pros and cons and recommended for different uses cases. You can read up online how others use and configure them. It’s easiest to start with the default one that comes with your stack.
3. 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 putting in the wrong authentication, or using blacklisted generic user-names, 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 came with your server and enable it. Maybe don’t set it so strict if you have many users on this server.
4. Brute-Force Protection on wp-login.php (BEG, HIGH)
The WordPress admin login page is often bombarded by bots trying random user-names 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 their pros and cons.
Server-level brute force protection – easy and efficient but can lockout legitimate users on busy servers with sites using Cloudflare. Problem is brute-force lockouts block by IP and visitors coming in through Cloudflare all share the same (proxy) IP. Sure, you can configure to pass true client IP through Cloudflare headers but this slows down page load!
Application-level brute force protection – many WordPress security plugins can do 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 on it from using resources.
Other plugins protect the login form by putting a captcha and banning certain robots, crawlers, devices. This can work well but might annoy or false-flag legitimate users.
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.
5. HTTP Authentication (BEG, MED)
Do you have specific pages being bombarded and no convenient way of blocking access to them? HTTP AUTH is a quick-and-dirty way of locking out all users. 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 passwords generator
6. 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 IP’s (and also for Jetpack, if you use it).
7. 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)…but 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 is still a useful option to block attacks that the server doesn’t, and/or prevent hacked sites from doing more damage.
My favorite WordPress security plugin is WordFence.
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 on security plugins probably aren’t needed if you have a server firewall already. Firewalls activated at the PHP level slow all incoming requests.
The performance problem with security plugins is due to A) over-aggressively filtering all incoming traffic, and B) scanning too often. Both eat up many resources especially on large sites with many pages and visitors. I suggest not using software firewall, and also to set your malware scans to a slower speed.
8. 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. Only downside is it uses your server resources and also that you need admin skills.
Dealing with security via another server (like DNS proxy, Cloudflare) or security service (Sucuri) saves your server precious resources but might add slight load delay issues since visitors are passing through an extra proxy before reaching your web-server.
The weaker your server and server-admin skills, the more likely a security service is more efficient at blocking DDOS requests. Then again, for a smaller site you might not have so much 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 are the ones that overwhelm servers (even with good security) but they cost money and concentrated effort from hackers. Unless someone is specifically targeting you, you don’t have to worry about them.
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 that you mostly won’t need.
9. HTTPS and HTTPS Redirect (BEG, LOW)
You should absolutely be using HTTPS. (It’s the only way to get the benefits of HTTP/2 protocol.)
Put 301 HTTPS redirects on your server so visitors are quickly redirected to the proper HTTPS protocol and correct 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 make sure all your internal urls are using HTTPS. Don’t rely on SSL plugins (unnecessary) or WordPress (slow) to redirect you. Set the redirects from the server!
Bonus tip: if using Cloudflare, set a page rule to do your HTTPS 301 redirects from there as well. (Even faster than from local server!)
Need an optimized and secure WordPress hosting that meets the needs of your project? Get in touch with CirrusGrid for choosing the best option and receiving technical assistance while migration.
By Tetiana Fydorenchyk of Jelastic | June 24, 2020
