Bot traffic is higher than it’s ever been. According to Distil Networks, in 2017, bad bots accounted for 21.8% of all website traffic, a 9.5% increase over the previous year. Not only that, but 74% of bad bot traffic is made up of moderate or sophisticated bots, which evade detection by distributing their attacks over multiple IP addresses, or simulating human behavior. This becomes a challenge for businesses that know nothing about how to filter out or block this type of traffic.
Today we want to introduce you to an incredibly easy way to fight back using the Sucuri Web Application Firewall (WAF). Whether your WordPress site is under a DDoS attack or you’re suffering from excessive bots and proxy traffic, a WAF can help almost instantly resolve these types of issues.
Below we’ll dive into how to set up Sucuri’s firewall on your WordPress site, along with the optimal settings and the plan you should choose to see the best results.
- About Sucuri WAF
- Do You Need Sucuri?
- Recommended Sucuri Plan
- How to Set up Sucuri Firewall
- Optimal Sucuri Settings
About Sucuri WAF
Sucuri is an all-in-one website security platform that helps protect your business from security threats as well as mitigate already ongoing attacks. They offer a variety of different products and services, such as a CDN, malware scanning, hack repairs, DNS monitoring, file change detection, brute force protection, and much more.
Today though we are only concerned with one product, and that is the Sucuri Web Application Firewall (WAF). The Sucuri Firewall is a cloud-based and is designed to stop website hacks and attacks (this includes bad traffic). How does it work? Essentially you point your DNS to them and they route your traffic to your WordPress host. The web application firewall sits in the middle, blocking traffic before it even gets to your host.
The team at Sucuri is constantly researching new ways to improve their detection and mitigation of evolving threats. They even allow you to add your own custom rules, which makes their service very powerful!
Do You Need Sucuri?
Do you really need a service like Sucuri? It depends. Having a web application firewall sitting between your WordPress site and your hosting provider is never a bad thing. 😉 In fact, it will most likely save you time and trouble down the road.
Unfortunately, we don’t typically see clients utilizing a service like Sucuri until they start running into problems. The most common scenarios are DDoS attacks and bad traffic from bots and proxy servers. When we say “bad” we don’t always mean someone trying to hack your site. Most of the time it is actually bulk traffic that causes overage issues with your hosting provider. This could be in the terms of visits, bandwidth, etc. In other words, it’s “bad” traffic because it costs you money! If you’re using a shared hosting provider, it might even result in your WordPress site getting suspended.
Below is an example of a site that was suddenly hit with bad proxy IP traffic overnight. We can see using MyKinsta analytics exactly when it started. The site went from an average of 125 visits per day to 1,500 visits per day (and unfortunately this wasn’t just temporary viral traffic). It also went from using 25 MB of bandwidth per day to 25 GB of bandwidth per day. Yikes!
Taking a deeper look into the analytics we could see that the top region visiting the site was Province of Arezzo with over 4 million requests in the past 30 days. This site usually gets over 90% of its traffic from the United States, so we can quite easily pinpoint this as the origin.
Most hosting providers, including Kinsta, block common bad bots, filter out spammy IPs, and have additional security settings in place such as IP limiting. However, this is usually not as effective as a professional WAF such as Sucuri or Cloudflare, whose entire business model revolves around innovation in terms of better ways to filter out bad traffic.
This is also why we don’t recommend using your WordPress host for email hosting. Using only the best tools and services in their respective fields and industries will help your business succeed. We focus on what we do best and that is providing high-performance hosting and world-class support. 👍
Things to Try Before Sucuri
If you’re having issues with bad traffic hitting your WordPress site, there are some things you can try before adding Sucuri.
1. Block Individual IP Addresses Manually
The first is to try blocking the offending IP addresses manually. If you’re a Kinsta client, you can use the Top Client IPs report in MyKinsta Analytics to see the top offenders.
A few searches in Google of the IPs and we can see that many of these are probably proxy IP addresses from Italy (which is where Province of Arezzo is located). So most likely they are bots or spammers.
You can then use the IP Deny tool to block the IP addresses. Monitor your visits and bandwidth afterward to see if it resolves the problem. In some cases it may just be a couple bad IPs hitting your site and once blocked, you’re good to go. However, it could also turn into a never-ending process of blacklisting IPs, which then doesn’t solve the problem fast enough.
If you’re not a Kinsta client you can use one of many WordPress security plugins, many of which have IP blocking and limiting capabilities.
But be careful with this approach. A lot of security plugins cause performance issues due to their always-on and scanning functionalities. That’s why Kinsta bans some (not all) security plugins. Kinsta also utilizes load balancers with Google Cloud Platform which means in some cases IP blocking features of some security plugins won’t work as intended.
2. Geo-Blocking
Another recommendation is to block traffic from an entire region or country. Kinsta, in fact, does support geo-blocking. You simply need to reach out to our support team for this and supply the ISO codes for the countries you want to block. Check out more details on location-based traffic denial.
Or you can try using a WordPress security plugin such as IP Location Block or WordFence, which support geo-blocking. Again, these are not supported and will not work at Kinsta.
If the above solutions don’t work for you, we recommend implementing a premium WAF such as Sucuri. There are no plugins to install or manage and it simply sits between your site and your host. This is the best method in terms of performance and it will then, almost like magic, get rid of all that bad traffic!
Recommended Sucuri Firewall Plan
We recommend the Sucuri Pro firewall plan or higher. Why? Because their Pro plan ($20/month) includes support for custom SSL certificates along with Advanced HTTPS DDoS Protection at layers 3, 4, and 7. If you’re curious, Cloudflare only includes layer 7 protection in their $200/month plan.
This helps to automatically detect sudden changes in traffic and protects against POST floods and DNS-based attacks, so they never reach your origin server. Unless you’re a security expert, it can sometimes be hard to differentiate between a small DDoS attack and simply bad traffic overwhelming your site.
An HTTP flood attack is a type of Layer 7 application attack that utilizes the standard valid GET/POST requests used to fetch information, as in typical URL data retrievals (images, information, etc.) during SSL sessions. An HTTP GET/POST flood is a volumetric attack that does not use malformed packets, spoofing or reflection techniques. – Sucuri
The Pro plan also includes HTTP/2 support which is a feature you definitely want in terms of performance. Additional features, included in all plans include:
- Intrusion Detection System
- Intrusion Prevention System
- Managed Audit Logs / Security
- HTTP Flood Protection
- Brute Force Protection
- Virtual Patching and Hardening
- SQL, XSS and code injection prevention (further reading: SQL injection)
- One-click 2FA, Captcha and Password Protection on any page
- External CDN Support
- Load Balancing
They do have a 30-day free trial.
How to Set up Sucuri Firewall
Today we’ll walk you through how to set up the Sucuri firewall on your WordPress site using the recommended Pro plan. It’s actually quite easy and only takes a few minutes.
Step 1
First, sign up for the Sucuri Pro plan if you haven’t already.
Step 2
Once inside the Sucuri dashboard click on the “Protect My Site Now!” button.
Step 3
Enter your domain name and configure the following options (we are leaving all three of these un-checked):
- Under a DDoS attack: Enabling this will automatically enable some of Sucuri’s more aggressive options. You may want to enable this if you’re positive you’re undergoing an attack. These settings can always be changed later.
- Whitelisted directories: Enable this if you want to restrict access to admin directories to only whitelisted IP addresses. (e.g. /wp-login or /admin). Note: On eCommerce sites, you will probably want to leave this disabled. Remember that customers use these areas as well.
- Sucuri DNS: Sucuri gives you the option to use their DNS infrastructure. This allows them to do geographic routing for optimized global performance, fail-over, and high availability. However, today we’ll be unselecting that option as we want to continue using our own third-party DNS provider. For example, if you’re using Kinsta DNS and want to continue managing your DNS records at Kinsta, un-select this option.
Step 4
Important: If you go with Sucuri’s Pro or higher plan, they can supply and install a GoDaddy SSL on the firewall prior to you making the DNS change. The GoDaddy certificate will auto-renew and is included in the monthly cost. Therefore, when moving to the Pro plan you should have a smooth transition and won’t incur any downtime.
Simply open up a ticket with their team and request they first install the GoDaddy certificate. You can then update your DNS.
Use Let’s Encrypt Certificates with Sucuri
Alternatively, the other option is that they provide free Let’s Encrypt certificates. However, these can only be issued after you point your domain to them. If you decide to go with their free Let’s Encrypt option, we recommend pointing your site during off-peak hours.
Use Let’s Encrypt Certificates with Kinsta
Kinsta also provides free Let’s Encrypt certificates. To use ours, you must first contact their support and have them enable the setting to “forward certificate validation.” This allows HTTPS provisioning to complete successfully. You can then install the free SSL certificate from the MyKinsta dashboard.
Step 5
Now it’s time to point your domain. Scroll down on the general dashboard page to where they provide the DNS information. You will need to update the A record for your domain to point to Sucuri’s firewall. This is typically done at your domain registrar or DNS provider.
Note: Sucuri should pick up your current IP address automatically. So once you point your domain to Sucuri they will automatically route traffic back to your WordPress host.
If you’re using Kinsta DNS, this can be done from the MyKinsta dashboard. Click on your domain and update the A name record with the provided Sucuri IP address.
DNS changes can take up to 48 hours to propagate, but typically it only takes a few hours or less. You can check if your DNS has propagated with whatsmydns.net. You can also click the little “refresh” icon in the Sucuri dashboard to confirm that your domain is pointing to them.
It will go green once they have detected that everything is routed correctly.
Step 6
If you have a firewall on your WordPress host, it’s recommended that you whitelist the Sucuri IP addresses. As all connections to your hosting server will be passing through their firewall, by whitelisting their IP addresses, it will prevent them from being blocked incorrectly. Note: the below IPs are simply examples, please see your dashboard for the correct Sucuri IPs based on your account.
192.88.134.0/23 185.93.228.0/22 2a02:fe80::/29 66.248.200.0/22
Kinsta Clients
If you’re a Kinsta client, you will need to reach out to our support team and have us add the appropriate Sucuri WAF rules on your site. Sucuri’s IPs are already whitelisted in our environment, but we have worked closely with their team and have additional Nginx rules that need to be added to ensure your Kinsta + Sucuri experience works without any problems.
Optimal Sucuri Settings
We don’t typically recommend using the Sucuri WordPress plugin as this just simply creates additional overhead, management, and performance issues. Let the Sucuri Firewall, which sits in-between your WordPress site and your host, do what it does best at the server-level.
Below are some recommended settings you should apply in the Sucuri dashboard.
Advanced Security Options
Under the “Security” tab we recommend enabling the following options:
- XMLRPC, Comments and Trackbacks blocked: If your site does not allow comments, or if you use an external commenting system (like Disqus), you can block any comment attempt, since it is likely to be spam. If you’re using native WordPress comments, don’t enable this.
- Block anonymous proxies and the top three attack countries: Enabling this option will prevent anyone from China, Russia or Turkey from interacting with your site. They are still able to view all content, but not register an account, submit comments or attempt to login (basically locked to read-only mode). The same restriction applies to users using anonymous proxies services to hide their IP addresses.
- Aggressive bot filter: This setting will block invalid user agents that do not match real browsers like empty user agents, user agents that start with PHP and improper user agents from common browsers.
- Advanced evasion detection: This option will enable Sucuri’s advanced evasion detection signatures. We recommend keeping it on, but if your site support URLs on non-ASCII characters (like Japanese, Indian, Russian, etc), you may need to disable it.
The “Enable Emergency DDoS protection” works very well if you think your site is under attack. The HTTP flood protection will prevent anyone from using a browser without JavaScript enabled from visiting the site (except major search engines). However, from our experience it also generates an additional HTTP request on the intial DOC load. So it’s recommended to turn this off after things normalize.
You can also enable additional security headers on your site such as HSTS.
Caching
Under “Performance → Caching Level” you can configure how you want Sucuri to handle caching. Most likely your site WordPress site is already setup correctly for caching. Therefore, we recommend selecting “Site caching.” This will honor your origin server’s cache instead of using Sucuri’s. If you’re a Kinsta client, this means your site will continue to use our fast full-page caching and it won’t interfere with any custom rules we have in place.
You can definitely test Sucuri’s recommended cache option, and you might even see slightly better performance with it. But one warning would be if you’re running a highly dynamic site such as WooCommerce or EDD. At Kinsta we have additional rules to not cache certain things such as cart pages, checkout pages, and most importantly cookies. Sucuri actually recommends using your own site headers for eCommerce sites.
CDN
Sucuri allows you to use your own third-party CDN (such as KeyCDN, MaxCDN) or their own CDN. Sucuri’s CDN features a fast HTTP/2 Anycast network with 6 SuperPOPs in the USA, Europe, and Asia and 3 CDN POPs in Australia, Brazil, and the Philippines. This comes at no extra charge when you’re using their firewall.
You can use the Kinsta CDN with Sucuri but their CDN is fast and reliable and we typically recommend using one or the other. If you want to use the Kinsta CDN, you will want to select “Other” under the CDN support tab.
If you want to set up your site with a third-party CDN, you can also do that as well. Simply check out their Knowledge Base for walkthroughs on third-party CDN integrations:
Compression
Under “Performance → Compression” we recommend enabling compression. This will reduce the number of bytes sent over the network and will improve your site’s performance.
And that’s it! Let Sucuri work its magic over the next couple days and you’ll probably be pleasantly surprised with the results. On the site we deployed it on the bandwidth instantly dropped and visits returned to the previous normal average per day.
Additional Useful Features and Reports
Now that you’ve configured Sucuri, there are a lot of other useful features and reports you can take advantage of to further improve the quality of traffic hitting your site.
Access Control
The “Access Control” tab gives you the ability to whitelist and blacklist IPs and paths, block user-agents, block cookies, block HTTP referrers, and also protect a certain page with a captcha, two-factor, or simple password. You can also easily block an entire country with their geo-blocking feature.
Real-Time View
The real-time view is awesome! You can quickly see an entire log of current requests, one-click blacklist or whitelist anything suspicious, and it will even give you a reason if it was already blocked.
Blocked Attacks
The blocked attacks chart allows you to quickly see a percentage of what types of attacks are being blocked, including DDoS attacks. Some other charts in this window include traffic by browser type, devices, and HTTP response codes.
Average Traffic Per Hour
The average traffic per hour chart is handy to see when the peak times are for your traffic and a ratio of requests being blocked.
Traffic By Country
The traffic by country table can help you determine if something is coming from one specific geolocation. Under their access controls, you can then easily block an entire country temporarily with a single click.
Viewing Real IP
On your end, it might appear that all users are using the same IP address. This is simply due to the WAF. If your application or host needs the real user IP, check out the Sucuri documentation.
Summary
The Sucuri firewall is very easy to set up which makes it a no-brainer if you’re having issues with low-quality traffic, DDoS attacks, or bots. For a lot of sites, the $20/month will pay for itself as it will ensure that the bad traffic is filtered out and only paying customers are allowed in. Not to mention that you’ll probably see performance increases on both the front end of your site and back-end WordPress dashboard.
What do you think about Sucuri? Have you tried it on your WordPress site? Let us know below in the comments.
Brian has a huge passion for WordPress, has been using it for over a decade, and even develops a couple of premium plugins. Brian enjoys blogging, movies, and hiking. Connect with Brian on Twitter.
Thanks for the useful blog post. I am also using the Sucuri Firewall and tested the cache options as written in this blog post and I noticed some big differences. I was testing two options: The standard cache (Enabled Cache, which is recommended in the Sucuri settings panel) and the Site caching (using my site headers). The experience was very bad: I had a 5 times better latency with the Standard Cache enabled (compared to the Site caching and the total load time was nearly 4 times better.
So I switched back to the Standard Cache (that is recommended by Sucuri).
Hey Michael! Glad you liked it.
Yes, it’s definitely recommended to test both cache options to see which one works best for your site. For blogs, news site, etc… You’ll probably have better performance using cache directly with Sucuri.
However, one warning would be with eCommerce/membership/community sites. For example, here at Kinsta we have additional rules to not cache certain things such as checkout pages, WooCommerce and EDD cookies (otherwise customers will have problems).
Sucuri actually recommends using your own site headers for eCommerce sites due to the fact that many hosts have server-level rules running behind the scenes for these solutions to work properly.
Nice post. The problem with Sucuri though is that I never was able to get real IP addreses in WordPress as I would always be getting only Sucuri IPs. My server is properly configured for X-Forwarded-For but for whatever reason that wouldn’t work with Sucuri. Never had a problem with Coudflare just for comparison. In the end I decided paying for Sucuri services but switching to them only in case of an attack.
Hey Goran! Assuming you tried all the different methods for getting the real IP? https://kb.sucuri.net/firewall/Troubleshooting/same-user-ip
One nice thing is that Sucuri is very easy to switch to. So like you said, you can use them as needed in case of an attack.
Far better to use tech to tie into Fail2Ban + block traffic either by IP or browser fingerprinting at the Kernel level. Trying to block traffic by WordPress plugin means traffic has to traverse the entire LAMP Stack + then the entire WordPress Stack… eating up massive resources along the way… before any action can be taken. For high traffic sites (real + attack traffic), this approach fails abysmally.
Hey David! We completely agree. That is why we recommend against using a WordPress security plugin and most of them are banned at Kinsta. The approach described above uses WAF at the server-level (no plugin).
1. Block Individual IP Addresses Manually
A very bad idea. As soon as a Bot Farm notices an IP is blocked, they stop using it + the IP returns to the free IP pool to potentially be used again by a real site.
Or worse, the IP is a VPN IP or Mobile network IP, so if it’s block manually forever, then you might lose massive traffic, depending on other users on the IP.
Better to use Fail2Ban to block IPs for short period, to even out server load.
2. Geo-Blocking
Far better done with Fail2Ban + ipset (for hashing large numbers of IPs) so packets are blocked at Kernel, so near zero machine load.
The massive perk with Fail2Ban is housekeeping.
Fail2Ban can block IPs for an hour or day or any time period, then self cleans.
So zero maintenance.
Once Fail2Ban is running, simply add additional recipes for blocking additional attacks.
Thanks for the comments David! Fail2Ban is a great solution, but unfortunately for a lot of users, this is not something they have easy access to. This is where a service such as Sucuri can come in handy.
Great guide. One question:
Assuming I do as recommended on this guide and I enable the Kinsta CDN, then do I need to do anything on the Sucuri site? On their site under General > CDN there’s an option for selecting a CDN. As a Kinsta customer do I need to change any settings there or in the Kinsta DNS settings?
Hey Patrick,
Yes, if you’re wanting to use Kinsta CDN, you will want to select “Other” under the CDN support tab. That’s it!
If I’m currently using SSL certicates with Kinsta, do I just stay the course and not use Securi’s SSL management?
Hey Kyle!
This is a great question and we’ve updated the post above. To use SSL Kinsta’s free SSL certificates, you must first contact Sucuri support and have them enable the setting to “forward certificate validation.” This allows HTTPS provisioning to complete successfully. You may then install Let’s Encrypt certificate from the MyKinsta dashboard.
Would like to know the answer to the SSL question @Kyle Miller asked also.
Hey Joan! We’ve updated the post above and answered Kyle’s question regarding how SSL at Kinsta and Sucuri work together. Hope that helps.
With the recent good news that all WordPress sites at Kinsta are now secured behind the Google Cloud Platform (GCP) Firewall, is adding on the Sucuri Web Application Firewall (WAF) still recommended – or needed in any way?
If yes, does having a Sucuri (or CloudFlare) WAF pose any conflicts with your GCP Firewall, or incur any performance issues from having two firewalls?
Thanks very much.
Great question JBR!
While this is a step in the right direction on our end, a WAF such as StackPath/Sucuri/Cloudflare Pro is still going to help mitigate a lot of bad traffic. This is because these providers have decades of rules and filters already in place.
There are no conflicts or performance issues due to GCP firewall implementation. We actually used a third-party firewall before, so a firewall sitting in front of Kinsta and a third-party WAF is something that was already happening.
Perfect, thanks so much for your fast response!
Hey Brian I appreciate your contributions on the blog here and this is a detailed overview, but I tried to use it as an implementation guide for adding the Sucuri Firewall in front of my Kinsta-hosted site and ran into some issues.
First, I didn’t realize that I needed to contact Kinsta only after the A records were pointed to Sucuri. I did it before and it triggered a 403 error on my site. Fortunately Kinsta support is fast, undid the change and my site was back up.
Second, an addition to your info above is that they require you have 2 A records, for both www and non-www, both pointing to the firewall. I had a CNAME for www and had to remove that and point to Sucuri.
Third, it gets a little messy here but I’ll lay out what happened. I pointed both A records to Sucuri and recontacted Kinsta support. DNS changes propagated, Kinsta said I was good on their end. And my site went down due to a redirect loop. I contacted Kinsta and they said it was an issue with Sucuri.
I contacted Sucuri via chat and support ticket and waited…the chat guy couldn’t help me but told me a tech guy was on it. Meanwhile I started going through the rest of your article here and realized that since I was already using Kinsta (Key)CDN, I needed CDN to be set to Other in Sucuri (it was set to none). I changed it, checked again, and the site was back up. Unfortunately, it had been down for a while at this point.
To complicate matters, I refreshed my support ticket in Sucuri and had gotten a response that since I already have SSL on Kinsta, I needed to change my “SSL Mode” setting to Full HTTPS from Partial HTTPS. I hadn’t changed that setting in the first place, but they made that change for me. They also said that since Kinsta is forcing HTTPS on my site, my setting under “Protocol Redirection” from “HTTPS only site” to “disabled.” He thought this fixed it, but he did that at the same time I made the CDN setting change, so I’m not sure…
So that’s it. I think it’s set up right now, and my site is loading. But it was diwn for a while and was an ordeal!
My question is similar to Kyle Miller above and wondering if Will’s answer addresses this…..
You say to reach out to Sucuri support if you want to use Kinsta’s SSL to “forward certificate validation”, but they seem confused about this request…. so I’m wondering if these are settings are self serve that you can enable yourself under SSL mode and Protocol redirection in the Sucuri dashboard?
Hi Andrew, if you are using Kinsta’s Let’s Encrypt, you will need to contact Sucuri’s Firewall team and they can enable it for you.
Like I mentioned Tom, it seems like they don’t understand the request…. so I was asking if maybe the settings are something I can do myself in the Sucuri dashboard (without relying on their support). Specifically the items mentioned in my first post are items Will said Sucuri support made changes to, which happens to be items in the dashboard you can toggle on/off without support.
I finally got a response from Sucuri. They are telling me that they made some changes since you published your article and to inform you that they have added these features in their dashboard. Specifically in your Sucuri dashboard, under the header called HTTPS/SSL there is “SSL Mode” and “Protocol Protection” that you can toggle these on and off yourself.
So, If you want to continue using your Kinsta’s Let’s Encrypt SSL certificate: under SSL mode select “Full HTTPS“, and set Protocol Redirection to “disabled.”
Very handy article to configure sucuri, thank you very much!
Hi there,
There is one piece of this article that is no longer correct. The article suggests turning on compression; however, this is no longer an option at Sucuri. Per the Sucuri support team:
“The Firewall no longer offers Brotli compression on our end. However, it does support compression when enabled on the server.”
I presume because Kinsta uses GZIP compression that everything should be good to go.
Thanks!
Hi Brian,
I found the blog very useful. I have recently moved to Kinsta and set up my firewall. I was having issues with Gzip. Enable compression is no longer a specific option in sucuri.
Response from Sucuri support – probably worth updating on the blog.
I’ve just set your Caching Level as “Site caching (using your site headers)” inside your Dashboard here:
This way, our Firewall will let your application/origin server decide what needs to be cached on our end – and the firewall will respect the cache control headers received from your server and it will cache accordingly. But, if the origin server/application doesn’t set “Cache Control” headers to explicitly ‘not cache’ or ‘cache for a different time period’, our firewall will apply the same caching rules as “Enabled”. This is recommended for sites with authenticated sections, CMS, membership domains, e-commerce sites etc. Data for logged in users shouldn’t be cached with this option, if the proper headers are set.
This option gave me the best result.
Hi all,
We will want use Sucuri full version. We have a news site and using WordPress. What is yours advisory.
Thank you.
Hello Dogukan, it really depends on your needs. I’d suggest talking to both Sucuri and Cloudflare’s sales teams – they should be able to decide which option is best for your site.
What do you mean by ”This is also why we don’t recommend using your WordPress host for email hosting. Using only the best tools and services in their respective fields and industries will help your business succeed. We focus on what we do best and that is providing high-performance hosting and world-class support. 👍” Can you Please Explain why shouldn’t I use my WordPress host for email hosting? if I have my own VPS why won’t I use WordPress + Email hosting for my business?
Hi, we explain this in details here: Why keep email and hosting separate