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\u2019t know it.<\/p>\n\n\n\n
Securing against these attacks requires a delicate balance. You don\u2019t want a server that lets hackers freely bombard your ports and resources. But you also don\u2019t want a server that\u2019s too secure and excessively auditing all traffic that it slows your users or worse (it blocks legitimate users).<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
SKILL:<\/strong><\/p>\n\n\n\n BEGINNER \u2013 can Google and follow instructions.<\/p>\n\n\n\n INTERMEDIATE \u2013 working as WordPress contractor.<\/p>\n\n\n\n ADVANCED \u2013 programmer or server-admin.<\/p>\n\n\n\n IMPACT:<\/strong><\/p>\n\n\n\n LOW \u2013 maybe 100-200ms difference. Possibly unnoticeable.<\/p>\n\n\n\n MEDIUM \u2013 around 500ms difference.<\/p>\n\n\n\n HIGH \u2013 1 second difference or more.<\/p>\n\n\n\n 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\u2019re not using, disable it from your server!<\/p>\n\n\n\n DNS \u2013 disable if using external DNS server (Cloudflare, DNSME, etc.)<\/p>\n\n\n\n Email \u2013 disable if using 3rd-party email (G-Suite, MXroute, etc.)<\/p>\n\n\n\n FTP\/SFTP \u2013 disable if not using<\/p>\n\n\n\n Other proxies \u2013 like Varnish<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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:<\/p>\n\n\n\n Ports used by specific people (SSH, FTP) \u2013 only you or a few others. Do an IP whitelist and block the rest.<\/p>\n\n\n\n Ports used by certain country (POP3, IMAP, FTP) \u2013 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!<\/p>\n\n\n\n Ports attacked only by certain country \u2013 if you have many attacks coming from certain countries or regions, you can ban by country or entire IP ranges.<\/p>\n\n\n\n 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\u2019s easiest to start with the default one that comes with your stack.<\/p>\n\n\n\n Brute-force protection is like a smart firewall. It leaves services and ports open but automatically bans the obvious offenders.<\/p>\n\n\n\n It automatically bans anyone putting in the wrong authentication, or using blacklisted generic user-names, etc.<\/p>\n\n\n\n They\u2019re easy to set and very powerful. Just be careful that they don\u2019t block legitimate users\/traffic. You can see what brute-force or DDOS protection came with your server and enable it. Maybe don\u2019t set it so strict if you have many users on this server.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Server-level brute force protection \u2013 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!<\/p>\n\n\n\n Application-level brute force protection \u2013 many WordPress security plugins can do this. They secure the login page by banning users with bad credentials.<\/p>\n\n\n\n Some plugins hide the login page \u2013 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019s 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.<\/p>\n\n\n\n Setup HTTP AUTH on Apache\/LiteSpeed<\/p>\n\n\n\n Setup HTTP AUTH on NGINX<\/p>\n\n\n\n Handy HTTP AUTH passwords generator<\/p>\n\n\n\n The XML-RPC protocol allows external apps (like mobile apps), to log into your WordPress and edit content or view WooCommerce sales. Unfortunately, it\u2019s often exploited by hackers and bots brute-forcing their way into your site.<\/p>\n\n\n\n If you don\u2019t use it, disabling XML-RPC prevents server slowdowns caused by the thousands of XML-RPC hack requests.<\/p>\n\n\n\n If you need to leave it on, you can whitelist your IP\u2019s (and also for Jetpack, if you use it).<\/p>\n\n\n\n If you don\u2019t 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)\u2026but sometimes, it\u2019s hard to set global security rules when you have many clients\/sites and each one needs something different.<\/p>\n\n\n\n Nonetheless a software-level security plugin like WordFence is still a useful option to block attacks that the server doesn\u2019t, and\/or prevent hacked sites from doing more damage.<\/p>\n\n\n\n My favorite WordPress security plugin is WordFence.<\/p>\n\n\n\n Most important feature of security plugins IMO is malware scanning. Scan manually or schedule during low-traffic hours. This feature doesn\u2019t necessarily improve website speed, it detects system exploits and prevents them from using up resources (hosting spam sites or attacking other servers).<\/p>\n\n\n\n The firewall features on security plugins probably aren\u2019t needed if you have a server firewall already. Firewalls activated at the PHP level slow all incoming requests.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019s using someone else\u2019s 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019t 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.<\/p>\n\n\n\n Most people don\u2019t have to worry about DDOS attacks, ok?<\/p>\n\n\n\n Most lower-level DDOS attacks are easily handled by your server.<\/p>\n\n\n\n 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\u2019t have to worry about them.<\/p>\n\n\n\n Easiest way to deal with high-level DDOS attacks is to immediately sign up with a dedicated security company like Sucuri (when it happens).<\/p>\n\n\n\n I don\u2019t recommend paying for fancy security services that you mostly won\u2019t need.<\/p>\n\n\n\n You should absolutely be using HTTPS. (It\u2019s the only way to get the benefits of HTTP\/2 protocol.)<\/p>\n\n\n\n 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 \u201cwww\u201d). Without these server redirects, WordPress can still do it but it takes a little longer.<\/p>\n\n\n\n Also, don\u2019t forget to make sure all your internal urls are using HTTPS. Don\u2019t rely on SSL plugins (unnecessary) or WordPress (slow) to redirect you. Set the redirects from the server!<\/p>\n\n\n\n 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!)<\/p>\n\n\n\n Need an optimized and secure WordPress hosting that meets the needs of your project? Get in touch with CirrusGrid<\/a> for choosing the best option and receiving technical assistance while migration.<\/p>\n\n\n\n By Tetiana Fydorenchyk of Jelastic | June 24, 2020<\/p>\n\n\n\n To Know More<\/a> | Free Trial Now<\/a> | To Meet Us<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":3,"featured_media":10878,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[28],"tags":[],"class_list":["post-5843","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"blocksy_meta":[],"acf":[],"yoast_head":"\n1. Shutdown Unnecessary Server Services (ADV, HIGH)<\/strong><\/h3>\n\n\n\n
2. Server firewall configuration (ADV, HIGH)<\/strong><\/h3>\n\n\n\n
3. Server Brute Force Protection (ADV, HIGH)<\/strong><\/h3>\n\n\n\n
4. Brute-Force Protection on wp-login.php (BEG, HIGH)<\/strong><\/h3>\n\n\n\n
5. HTTP Authentication (BEG, MED)<\/strong><\/h3>\n\n\n\n
6. Disable XML-RPC Protocol (BEG, MED)<\/strong><\/h3>\n\n\n\n
7. Security Plugin Configuration (BEG-INT, MED)<\/strong><\/h3>\n\n\n\n
8. DNS Edge-Level Security Configuration (BEG, MED)<\/strong><\/h3>\n\n\n\n
9. HTTPS and HTTPS Redirect (BEG, LOW)<\/strong><\/h3>\n\n\n\n