Ask A Security Pro: Firewall Series – Part 2: WAFs

Part Two: Firewalls -> Web Application Firewalls (WAF)

Every website uses web applications, some more intricate than others. More and more website owners are turning to robust web applications like WordPress to build and manage their websites. In fact, over a quarter of all websites on the internet use WordPress as a platform, and nearly half of the web is estimated to utilize some kind of content management system.

As the interactivity offered by websites increases, so too do the vectors for potential attack. As with any mechanism, by introducing additional moving parts, the possibility for a flaw to exist increases. To protect these new potential vectors from attack, the Web Application Firewall (WAF) was developed. A WAF does not replace the Network Firewall, nor vice-versa. Rather, a WAF enhances the existing security structure by extending protection to the application layer. WAFs are almost always used in conjunction with some type of Network Firewall.

WAFs, like Network Firewalls, also utilize a form of packet filtering, but are able to take action on a per-process basis rather than simply a per-connection basis, often resulting in more precise blocking functionality and increased aptitude against zero-day exploits. Being able to set application-specific policies allows you to define exactly how a web application is allowed to behave, blocking only specific behavior with surgical precision. For example, you could allow a visitor to subscribe to your newsletter, but block the visitor if a code injection attempt is detected in the form input fields.

A WAF can be deployed as either a piece of software installed to your WordPress website’s web server (e.g. ModSecurity or the Wordfence plugin’s WAF), or as a cloud-based mechanism. Unfortunately, running a state-of-the-art WAF as software on the same server that is delivering your website’s content will almost always introduce some amount of additional latency in content delivery. As we’ve been informed by Google, site speed plays a part in calculating page ranking, so installing WAF software to the web server is often not a viable solution for WordPress websites where site speed is critical, or where protection against distributed denial-of-service (DDoS) attacks is warranted. Cloud-based solutions like SiteLock® TrueShield™ eliminate the additional tax via a system of reverse proxies that also form a Content Delivery Network (CDN). What this means is that you’re actually utilizing the processing power of the proxy servers instead of your server in order to enforce your security policies. By coupling a WAF with a CDN, you’re not only able to eliminate the additional processing tax, but even increase the website’s load speed by caching your content at strategically located data centers across the world.

I mentioned distributed denial-of-service (DDoS) attacks a moment ago, but let’s talk a little more about DDoS attacks. DDoS is not just a “buzz word.” DDoS attacks against WordPress websites are trending upward at alarming rates. It is important to take the lessons learned from widespread WordPress DDoS attack vectors like the recent xmlrpc.php exploit and apply them to our WordPress website security posture. For me, the two largest take-aways from the xmlrpc.php incident were:

Reduce your processing tax.

Every bit of processing tax increases the potential damage of a DDoS attack. Large or small, any additional thinking your WordPress website’s web server has to perform can and will be weaponized against you during a DDoS attack. Don’t cut corners on performance, make sure every additional amount of processing tax is justified. Cache where possible. Consider outsourcing process tax where you’re able to by using services like CDNs or cloud-based WAFs.

Reduce time-to-production on patches.

Thanks to the vigilance of the WordPress community, patches/workarounds became available in a very short amount of time. The downside is that you basically needed to know where to look to find them, and then apply them yourself. The benefit of a WAF in these scenarios is that many offer real-time updates to their rulesets as
threats are identified, which means the security professionals are doing the work for you and deploying the best defenses on your website as soon as they’re developed. However, as I mentioned a earlier, if you’re using a WAF that is installed as software on the same server you’re using to deliver your website, the WAF will also be impaired by the DDoS event and likely rendered inoperable during the event. Globalized cloud-based WAF+CDN solutions like SiteLock® TrueShield™ are inherently more capable of withstanding DDoS attacks than smaller networks and certainly more than single-server WAF configurations simply due to their broad physical distribution of servers and larger bandwidth capacity.

By routing your website traffic through a reverse-proxy WAF, you’re also able to conceal your original web server (‘origin’) from the public internet, further reducing any would-be hackers’ visibility into your infrastructure. The traffic from visitors to your website is first routed through the WAF’s cloud infrastructure where it can be analyzed for potential threats and filtered before your origin server, or your network firewall, even have to lift a finger, so to speak. By using a network firewall and a web application firewall in tandem, your WordPress website security posture will be greatly increased, and you’ll be more prepared for anything that gets thrown your way.

Have a question or topic that you’d like our security professionals to write about? Message @SiteLock and use the #AskSecPro tag!