Sucuri (specifically their web application firewall or WAF) was something I never really considered until I started to notice that my World of Waterfalls website has been under attack more frequently by people with malicious intent.

These were manifested in failed login attempts, requests aimed at flooding the host server in denial of service (DDOS) attacks, and probing for website vulnerabilities to exploit (especially since WordPress and its plugins have been consistent targets).

Because my website was hosted on premium Kinsta servers, which provided me with dedicated resources, I was also keenly aware that my resource utilization costed me money.

This meant that I had to pay particular attention to website visits, cloud bandwidth utilization, memory usage, and disk drive utilization, among other things.

Indeed, after confirming with Kinsta technical support that the bad actors were running up my resource utilization quota on my plan, Kinsta recommended that that I look into a WAF to address this issue.

And that was when I evaluated prospective WAF vendors where I ultimately decided on giving Sucuri a try. This was largely because they had a basic service level that was affordable while also giving me a 30-day try before I buy trial.

I figured that would at least let me see what’s really going on with the Sucuri WAF, and whether it would indeed do the job of shoring up my website’s security.

As a result, this review covers my experiences with the Sucuri WAF so far as I discuss my actual experiences in applying this firewall with the existing infrastructure I have for the World of Waterfalls website.

What is the Sucuri WAF?

The Sucuri Web Application Firewall is basically a cloud-based web application that seeks to stop illegitimate traffic while at the same time letting through legitimate traffic.

Because the firewall sits in the cloud in front of my host Kinsta server, it essentially acts as my first line of defense as it fields all comers on the cloud network before passing the “valid” traffic to my website and its server resources.

As a result, Sucuri WAF is also its own cloud distribution network (or CDN) where there are servers distributed throughout the world to serve cached content from my website to visitors from all around the world in an attempt to speed up page load times (provided the requester got through the WAF filters).

By having the Sucuri WAF in front of my site, that meant that I had to bypass the included Kinsta CDN that was included with my plan.

The cloud-based firewall was the key service that motivated me to pay more for it, but I’m aware that Sucuri also offers different levels of WAF protection as well as different levels of broader security with their comprehensive plans.

The broader comprehensive plans also include malware scanning and clean-up, file server monitoring, and other things to further improve your website’s security posture.

To make a long story short, the difference in their WAF pricing plans is that the pro plan includes SSL support and monitoring while the basic plan can support SSL if you already have a pre-existing one (I believe I had mine through GoDaddy and/or Kinsta already).

For the more comprehensive plans, the malware detection and removal times reduce from 30 hours to as little as 6 hours while the frequency of security scans reduce from every 12 hours to as little as every 30 minutes.

Who is the Sucuri WAF for?

I’d argue that the Sucuri WAF is really for websites that are doing well enough to start paying attention to web security more.

By this, I mean that if you’re starting out or you’re still not getting significant traffic numbers to even make it worthwhile for a would-be hacker to poke at your site and “mine for gold”, so to speak, then the return on investment might not be there yet.

While hackers can still get to your site, there are still some things that you can do to be vigilant (e.g. using free plugins like Simple History or WP Activity Log to monitor activity from within your WordPress backend).

If your host also gives you Linux command line access or even FTP access, then you might even be able to look at the server logs directory, but that is something that is too technical for most users who aren’t comfortable navigating the command line.

Nevertheless, if your website starts becoming successful, or you’ve upgraded from shared hosting to higher-performing dedicated hosting (where you start getting nickel-and-dimed for the traffic your website generates), then it might be worth soliciting a WAF.

In my case, my Kinsta host plan charges me for overages if my traffic exceeds my plan’s quota regardless of whether the traffic is legitimate or not.

That’s where using Sucuri WAF to intercept the bad traffic would theoretically reduce the host server’s resource utilization (and thus the overall cost to me).

Just to give you an idea of how easy a hacker can exploit a vulnerable website, here’s a video demonstrating this…

Why Should You Use Sucuri WAF?

In my experience, I would say that Sucuri has provided me with the following that I previously didn’t have…

• Having a first line of defense against the mean web
• Freeing up website host resources
• Complementing existing website infrastructure
• Providing features to customize security settings for my situation
• Providing detailed logs to further empower me to be proactive

As a result of the WAF acting as a first line of defense on the cloud to limit traffic hitting the website’s host server, I’ve found that the WAF frees up the host server’s resources.

Not only would that save me money as mentioned earlier, but it would theoretically also speed up the host server (as resulting page load times) because it’s not burdened with the same security-related duties that Sucuri is taking from the website host.

Of course, there are still policies and infrastructure in place for the host server to maintain a last line of defense against bad actors so Sucuri’s web-based offering complements (i.e. it shouldn’t conflict with) the existing host server’s services.

Sucuri also provides me several features to customize or fine tune my security settings to further support my particular website’s needs.

Such features include IP Blocking, URL Path Blocking, Geo-Blocking (if you know traffic from certain countries are unlikely to be valid), User-Agent Blocking (if you know what are bad bots), HTTP Cookies Blocking, HTTP Referers Blocking, Page Protection, etc.

There are also advanced features like restricting the admin panel and preventing firewall bypass.

I’ll get into how I configure these security features for my site later on in this post.

Finally, Sucuri provides me a more detailed log showing me who is trying to access the website since they now see everything.

This complements my Kinsta and WordPress backend logs so I have a more full picture of what is hitting my website in a way that the logs on my host server weren’t able to do previously without intervention from their technical support.

Indeed, with all this data and features, I feel like they have greatly enhanced my website’s security posture, which in turn, allowed me to take further measures to harden my site even more.

What Are Sucuri WAF’s Weaknesses?

While I feel that Sucuri WAF has improved my website’s security in ways the security measures within WordPress and my dedicated host couldn’t, there have also been some aspects of the firewall that didn’t meet my expectations.

In particular, here are some of the things that I’ve noticed…

• Its default security settings out-of-the-box were insufficient
• It required some technical intervention on my part before I started seeing the WAF’s value
• Technical support can be dismissive before being helpful
• Its limited regex support meant some block rules couldn’t be set
• Undoing collateral denials is case-by-case and only flagged after the fact

Regarding the out-of-the-box configurations when I had Sucuri installed, I realized that bad actors were still getting through to my host server as if the firewall hadn’t existed in the first place.

That was when I reached out to Sucuri support, where they then set up a WAF Bypass Protection service (not enabled by default) as well as pointing me to some settings that I can tweak in their dashboard (which I was already aware of).

I also had to intervene by reaching out to Kinsta support to make sure that they set up their end properly so as to not clash with the Sucuri WAF.

And even with these measures that have taken place, I still saw some illegitimate traffic hitting the Kinsta host.

It was only after a fairly contentious back-and-forth discussion with Sucuri’s tier 3 technical support did I come to the realization that the WAF cannot filter out all bad traffic.

Indeed, it’s a tricky and complex game of cat and mouse where the WAF on the one hand tries to block bad traffic without also blocking legitimate traffic as collateral damage.

That’s when I realized that I had to temper my expectations with how the WAF works because they have a more lenient view (out of necessity) of what is considered “valid” traffic versus invalid traffic.

Even with my proactive technical intervention by digesting the logs and trying to employ rules and policies to protect my website (more on this later), I still had to live with some bad traffic getting through the cracks.

Now when it came to my dealings with their technical support, I did find that my first impressions were such that they seemed pretty dismissive of my concerns that I had brought to them.

It initially rubbed me the wrong way before I realized through this exchange that I had to reset my own expectations on the capabilities of the WAF at filtering out bad traffic while letting through the good traffic.

There’s only so much that the firewall can do.

Still, my dealings with the Sucuri technical support were seemingly more contentious than the Kinsta technical support, where the latter was a far better experience.

This was further exacerbated by the fact that the Sucuri support system is ticket based so I had to spend a good deal of time composing messages and trying to submit it before the Sucuri dashboard would log me out automatically.

To defend against that, I learned to copy-paste everything to the clipboard before hitting the submit button.

Nevertheless, given the limitations of the WAF at adapting its filters to the ever-evolving cat-and-mouse game of identifying and blocking bad actors, I had to resort to tweaking the settings that I can control on a case-by-case basis.

That was where I learned that their URL Path Blocking was limited in that it didn’t support regular expressions (i.e. regex) natively.

Therefore, I couldn’t block some URL Paths (like the WooCommerce Ajax cart fragment DDOS exploit) thanks to its inability to handle special characters like “?” (which happens a lot in website URLs).

Finally, I experienced some partially-working functionality (particularly WooCommerce store integrations with third-party vendors) that I only realized and seeked out tech support for when I saw errors after the fact (generally people don’t bring this up).

Unfortunately, firewall rules are an inexact science, and sometimes these filters can be set to be overreaching or blocking legitimate requests or traffic.

In my case, I only noticed the malfunctioning integration 2 months after setting up Sucuri WAF, and then I got Sucuri’s tech support involved after other tech support inquiries with my Kinsta Host as well as the third party vendor.

A two-month outage like this can be a significant amount of lost business, but this just goes to show you that filtering legitimate versus illegitimate traffic can be messy.

How Did I Tailor Sucuri’s WAF Configurations To Suit My Needs?

To end off this review, I thought I might share some of the specific interventions that I have done to make Sucuri effective for my particular situation.

After all, I did mention that I felt Sucuri’s WAF offering right out-of-the-box was pretty weak at blocking bad actors that I noticed in my host server’s logs (meaning they got through Sucuri’s firewall).

This section may or may not apply to you, but it should at least provide you some insight as to the measures that I had to take to make it more difficult for bad actors to carry out whatever malicious intentions they had at my website’s expense.

We already talked about involving Sucuri Support to enable WAF Bypass Protection and involving Kinsta Support to ensure the host was optimized to accept Sucuri’s filtered traffic.

Geo and IP Blacklisting

The first thing I tried was Geo Blocking when I saw that some malicious attempts were coming from countries like China, Russia, and Turkey or other developing countries known to harbor attackers.

The problem with this is that you’re assuming that no valid content will ever come from the geo-blocked countries.

And what if attackers are coming from the USA, Canada, the UK, Australia, New Zealand, Hong Kong, Singapore, and more (where blocking these countries means blocking tons of legitimate traffic)?

Therefore, this is a case where administrator has to evaluate the likelihood of getting valid traffic versus the flood of invalid traffic he’s getting already. In my case, I actually have this turned on.

As far as IP blocking is concerned, it’s really only a temporary and responsive (i.e. it may already be too late) fix because most tech savvy programmers know how to use VPNs to constantly change the IP address and easily defeat IP blacklists.

In my situation, I selectively blacklist IPs if I see that it’s obviously a bad actor, but there are so many gray areas here that it may not be worth the time and effort to keep adding IPs to the blacklist.

Protecting the Admin Panel

Even though the World of Waterfalls website accepts user submissions, it is only done through the front-end.

There is no reason anyone should be accessing my admin area in the back-end, which is why I restricted the admin panel to only allowed IP addresses.

Now since I also use a VPN, Sucuri WAF does block me from getting into my own admin area from time to time as I get assigned a new IP every so often.

Therefore, Sucuri kind of acts as an informal 2FA (two-factor authentication) where I actually have to log into Sucuri first in order to enable my current IP before I can finally get into my admin dashboard in the WordPress back-end.

It’s inconvenient, but I’d rather be overprotective of my admin area as opposed to letting other people have more chances at penetrating that area.

Blocking URL Paths

This is one area where I constantly have to be vigilant by looking at a combination of Sucuri logs, Kinsta Analytics, my WordPress back-end activity through the Simple History as well as WP Activity Log plugins, and the Linux command prompt.

It’s only through these logs that I can find out about what attempted exploits managed to get through my existing filters and policies that are in place.

When I find a vulnerability, then I set a Block URL Paths rule as long as it doesn’t break the site, and that’s where it gets tricky.

Case in point, I’ve managed to find through these logs exploits such as “www.example.com/wp-json/wp/v2/posts” as well as “www.example.com/wp-json/wp/v2/users” where anyone can look up usernames and website content easily.

While I’ve set up rules to block these types of accesses through the Block URL Paths mechanism in Sucuri, there are others that I can’t set otherwise they’d break website functionality.

This includes “/wp-admin/admin-ajax.php” as well as a broadbrush rule “/wp-json”, which makes the Sucuri WAF too aggressive.

So for those cases, I just have to live with the fact that WordPress insists on exposing the user to REST API vulnerabilities (which is where the wp-json requests come from) as well as the admin-ajax.php accesses, which most search engine bots hit.

There are also plugins that access the admin-ajax.php script so that’s simply something I have to live with as there will be bad actors trying to find vulnerabilities through these mechanisms.

Now, I mentioned earlier that the WooCommerce cart fragment (to dynamically update the cart when there’s a change) can be a vector for DDOS attacks given its tendency to heavily load the host server’s resources.

These typically might look like “/?wc-ajax=get_refreshed_fragments”, which Sucuri’s existing limited Block URL Paths mechanism can’t fend off the way it’s set up right now.

So that’s a case where I had to disable such WooCommerce features within the source code itself in the functions.php file for my child theme.

While it adds to my error.log for every bad actor trying to load the server with this request, at least it’s no longer a drag on website performance.

Indeed, what I’ve explained above represent some of the key measures that I have taken beyond Sucuri WAF’s default settings.

I wish there’s a more systematic way to deal with hackers knowledgeable about such exploits (in fact if it weren’t for them, I myself wouldn’t even have been aware of them), but it is what it is.

That just goes to show you how you as the website owner with a vested interest in its security still need to exercise vigilance to at least make it less attractive for exploitation compared to other sites.

In my mind, it’s kind of analogous to would-be car thieves targeting cars with parts that have higher resale value on the after market or homes that look attractive to would-be burglars simply by their ostentatious displays of wealth.

Final Thoughts / Conclusion

At the end of the day, I eventually got Sucuri WAF to do what I intended it to do, which was a capability I didn’t have previously.

Even though I haven’t seen a noticeable reduction in my Kinsta host utilization from bad traffic (probably more attributable to a seasonal decline in the winter months), I am more situationally aware of what’s hitting my website.

If nothing else, I learned a lot about website security simply by giving Sucuri a try and utilizing their resources and tools, and at least I feel more empowered to do something about it as I’m armed with this new data.

However, as you can see with the measures I’ve had to take to earn my current security posture, web security seems to be an ever-evolving game of cat-and-mouse.

I’m hoping that Sucuri can keep up with the latest tactics that bad actors are constantly employing to exploit the latest vulnerabilities that inevitably come up.

That said, I really had to reset my expectations of the Sucuri WAF as I had to think of it as another ally in an army of allies working to protect the World of Waterfalls website.

So I have Sucuri on the front lines in the cloud, but I also have Kinsta and monitoring activities on the host server as a last line of defense.

I also use Git, which not only allows me to stage changes to code (especially if there’s bad plugin or core updates), but it also tracks changes to files being made so things like file scanning for changes aren’t doing anything I’m already doing myself.

If anything, I think it’s worth having the Sucuri WAF as long as it makes sense for your business.

While it’s next to impossible to make a website 100% fullproof without losing some of the benefits of being indexed by Google or using useful plugins, or letting people contribute to discussions, I can at least do what I can to make it less attractive to be a target for bad actors.

And with the capabilities that I’m buying with Sucuri’s WAF service, that alone is worth the money I’m spending with them…