If you don’t use a WAF on your website yet, 2017 is a great time to add the security of a Web Application Firewall. The two biggest WAF vendors are Sucuri and Cloudflare. Cloudflare provides great flexibility and many configuration options, giving you enough rope to hang yourself. Sucuri’s configuration is easier, but can also have negative consequences. Read on.
This is not a “winner/loser” checklist, where we add up the features and see who comes out ahead: if you want a quick answer, flip a coin. Instead, it’s an in-depth discussion on the qualitative differences between the two services.
Website security features
Cloudflare’s free service does not provide a WAF. This discussion is based on CloudFlare’s “pro” service (which includes firewall) and Sucuri’s comparable “website firewall” service.
Both services provide a WAF as well as some controls to turn features on and off, adjust security levels, and traditional IP-based blacklist/whitelist firewall. In addition to whitelist IP addresses, both services allow you to bypass security to individual parts of the website. Who does a better job at protecting your site? I think it’s a toss-up.
I’ve heard from several sources that Sucuri’s WAF is better at stopping threats than CloudFlare. I have not found this to be the case. (Most of these sources also provide an affiliate link for Sucuri, which can smell funny if you are the cynical type.) A few things to consider:
- As I mentioned earlier, CloudFlare’s free service does not include a WAF. Make sure you are signed up for the Pro service, and the WAF is turned on.
- Cloudflare’s security profile is significantly more configurable. You can certainly choose to tune the CloudFlare WAF to be less secure, and even turn it off. This does not mean that the service is inherently less secure: you can make your own decision about how secure you want the firewall to be.
Cloudflare’s security options give you more control over how you protect your site. You can opt to reduce security, and unfortunately doing so is too-often used to prevent “false positives”. On the other hand, more control can also make your site more secure. One area where Cloudflare outperforms is allowing you to change settings based on the URL. Cloudflare calls this “page rules”, and they allow you to change each CloudFlare option for any individual page (with regular expression matching) on your website. For example: you might want to remove caching and reduce the basic security for your administration pages so your logged-in administrators don’t get blocked every time they add some HTML, but still keep the WAF rules active.
Sucuri has a similar feature called “Whitelist URL Paths” which does what it sounds: you can either whitelist all access to that page, or you don’t. If you whitelist a URL, even the most egregious hacking attempts through that URL are allowed through.
Preventing firewall bypass
Unless you take steps to prevent firewall bypass, a clever user can, with some effort and basic information, can bypass the firewall and access your website directly. You should implement rules on your server to allow access only from the firewall (and other trusted addresses), and explicitly disallow access from anywhere else. You should also whitelist the firewall’s IP addresses to prevent throttling.
Sucuri deserves kudos for giving you explicit
.htaccess rules for both apache and lighthttpd.
Cloudflare, regrettably, takes a “security through obscurity” approach to this: their solution is to hide your server’s IP so an attacker won’t know how to bypass the firewall. That said, they do make their IP ranges public. We limit access only to these IPs on a regular basis, and although CloudFlare does not support this practice, I’ve never had a problem.
I’ll break this discussion in two parts: caching static files (images, CSS, PDF, etc); and caching HTML. In general, I prefer the option to configure cache (or not cache) that Cloudflare provides. Sucuri’s limited options can be hobbling.
Caching static files
Both Cloudflare and Sucuri cache static files regularly. This is generally a good thing, but there is a big exception: when static files are meant for limited distribution. This is a concern for organizations that have members-only files in PDF or image formats.
For example, PDFs or images that are meant only for site members can become public. Since Sucuri will always cache PDFs and images, you ran a high risk that these members-only files will be accessible by anyone if they are cached. If you have private files hosted on your website, keep this in mind before using Sucuri.
Cloudflare lets you disable caching using page rules, and this includes static files as well.
Sucuri, as usual, has very simple controls for caching webpages, including HTML. You can turn cache completely off, or choose between a few other options. You can also turn off caching on specific URLs (although static files will continue to be cached.)
Cloudflare, by default, does not cache HTML. There are two exceptions:
- Cloudflare will serve cached content, including HTML, if your website is down. This is their “always online” option and can be turned off site-wide or with page rules.
- Cloudflare page rules allow you to turn on HTML caching.
Pricing for the two services is nearly identical, roughly $20/mo. There’s one important difference: Cloudflare charges per domain, and Sucuri charges per site. In other words, Cloudflare’s price includes subdomains, an Sucuri’s does not. For example let’s assume your website is www.example.com, and your blog is hosted at blog.example.com. With cloudflare you’d incur a single charge, for all of example.com. Sucuri would treat these as two separate items and would bill separately.
If the two are materially different, Sucuri’s approach makes more sense: you can set different controls for each site. With Cloudflare, you have to rely on page rules to control the settings for the two different sites.
Sucuri is happy to protect your site with a simple DNS change to your site’s
Cloudflare requires that you move full DNS/NS services to their platform. This is a huge barrier to entry, and I was initially very reluctant to recommend Cloudflare for this reason. However, after years of experience, I find Cloudflare’s DNS service to be excellent. Responses are quick, TTLs are low, and the interface is easy to use. However, for a domain with many records and uses, this continues to be a big barrier.
Server (apache) logs
One of the side effects of any WAF is that all requests to your web-server are made by the firewall instead of directly by the end-user. By extension, web-server logs show the WAF IP address instead of the end-user’s, and any log-based web analytics will be reporting. This is seldom a concern, since most webmasters now use Google Analytics, which is not affected. However, occasionally website and systems administrators continue to analyze web-server logs. Tools like webalizer and awstats have continued support because they fill a void left by JS-based analytics tools like Google Analytics. (This void includes non-JS-enabled browsers, security review, error and static-file reporting, and others.)
Cloudflare has published an apache module, mod_cloudflare, that reports the real IP in the server logs. They also publish a support article on how to report the real IP in Lighthttpd logs. I have used this on a few sites and it works as advertised.
Sucuri supports mod_remoteip. I’ve not had occasion to use this but I expect it would work just as well.
Sucuri and Cloudflare: other features
As I mentioned, each service has several features, Sucuri focuses on security, offering monitoring for hacking and (for an additional fee) services to clean a hacked website. Since we provide these services in-house, I haven’t used the clean-up services and cannot comment on them. Sucuri also provides some performance improvements by caching your site.
Cloudflare puts equal emphasis on performance enhancements as well as security. They offer an impressive array of tools and controls to improve speed, from caching to automatically managing image sizes. I’ve used these tools and they work well, although they are also out of scope. (Except caching, which is an important part of both services).
Implementing a WAF
If you need help implementing or configuring a Web Application Firewall, or have any additional questions, leave a comment or contact us and mention WAF.