Protecting Web Application:
Cloudflare vs AWS WAF
When we hear the term Firewall, we often think about the Standard/Network Firewall. This kinds of Firewall offer OSI Layer 3 and layer 4 protection, which consists of checking the traffic source and destination IP addresses, protocol, source and destination ports. They are often called first and second generation firewalls.
As the Network Firewall can be still very useful, it’s not everything that Firewall technology has to offer. In this article, we will focus on the third generation, the Application Firewall.
Do you need a Web Application Firewall?
The key differentiator of an Application Firewall is the fact that it works on OSI layer 7, which means it can understand certain applications protocols like FTP, DNS and HTTP – which is most useful from a web application perspective.
Understanding HTTP in conjunction with other technologies like the Deep Packet Inspection means that a well-configured Web Application Firewall can help you protect your application against the most common web application attacks including the OWASP Top Ten attacks. A very simple configuration can protect you against File inclusion, Cross Site Scripting, SQL injections and much more. Of course, an Web Application Firewall is not a silver bullet solution and it can’t mitigate all attack vectors, but definitely it can be very helpful.
Let’s answer the question from the section title: “Do you need a Web Application Firewall?”. The answer can be: “It depends”.
Suppose your application is written in a truly secure way. In that case, you are sure that there are no security gaps in the application and the infrastructure now and in the future, and there are no and will be no reported Common Vulnerabilities and Exposures for your framework and libraries in the future. The answer can be “no”.
As you might suspect, it’s impossible to meet the above circumstances in the real world. Because of that, the real-world answer is: “yes – you need a Web Application Firewall”.
Web Application Firewall can be also very useful in the microservices architecture. Using a Firewall as a first line of defence that verifies all HTTP traffic, in case of detecting the same security issue in many microservices, you can implement the mitigation strategy directly on the Firewall fastly by a small team. Then, over time, you can implement it in each microservice with a respect to the given microservice team roadmap.
Cloudflare WAF
Cloudflare is a company that gathered a lot of traction a few years ago with the DDoS Protection product. Currently, it’s offering a wide range of products and the Web Application Firewall is one of them.
Cloudflare WAF offers easy integration with your current infrastructure, with a few limitations. This service setup requires using Cloudflare DNS, there’s no other need to change existing infrastructure or sacrifice performance. CloudFlare needs to have control over your DNS records, so if you are using other tools like AWS Route53 for DNS, using CloudFlare is not an option.
Source: https://www.linkedin.com/products/cloudflare-waf/
CloudFlare uses a crowd sourced engine from all of its clients to learn about the attacks, and help create rules automatically for you. Also, a certain amount of customization is possible. To be more specific, the CloudFlare WAF contains the following rulesets:
- Cloudflare Managed Ruleset
- OWASP ModSecurity Core Ruleset
- Custom Firewall Rules
This solution offers quite an easy to use dashboard to visualize and analyze threats with Firewall Analytics. It helps you tailor your security configurations. The Simulate feature is very useful when adding a new Custom Firewall Rule, as it allows you to preview the new rule results to reduce false positive marks.
The CloudFlare WAF is quite a cheap solution. There’s no option to buy just the WAF, but the whole CloudFlare Pro package, which is the cheapest one containing WAF, costs 20 $ per month.
Adding CloudFlare to an existing project seems to be very easy at first glance, but be ready for some unexpected issues. We’ve encountered issues with handling external APIs webhooks and the WYSIWYG editor. Both issues have been resolved by adding custom rules. After using such a product, the proper Quality Assurance process is essential to keep the application working as expected.
AWS WAF
Amazon Web Services is a hyperscaler cloud computing platform. It’s the industry leader that is the most comprehensive and enterprise-ready service offerings. It offers over 200 services, which can be overwhelming at the beginning, but in this article, we will focus just on services connected with the Web Application Firewall functionality.
Source: https://aws.amazon.com/waf/
The main service is the AWS WAF, it’s offering protection at the OSI Layer 7 (Application Layer) for your business logic.
Other useful services are:
- AWS Shield – managed DDoS protection.
- AWS Network Firewall – protection at the OSI Layer 3 and 4 (Network/Transport Layer) for your VPCs.
- AWS Firewall Manager – centrally configure and manage security rules across accounts and applications.
If you are already hosting your application on AWS, the setup of the AWS WAF is frictionless, you can deploy it without changing your existing infrastructure. It can be assigned directly to a few of AWS services including Application Load Balancer, CloudFront distribution, and Elastic IP address. No changes in DNS records are required.
AWS WAF also offers a low operational overhead. It offers ready-to-use, built-in managed rules as well as wide rulesets from AWS Marketplace. AWS Managed Rules offers functionality similar to CloudFlare managed rules, including protection against OWASP Top 10 and other common attack vectors and threads. The rule engine also offers an advanced customisation mechanism.
The AWS WAF Metrics are sent to the CloudWatch service, where you can set up dashboards and alarms according to your needs. The rules insight is available directly in the WAF dashboard, you can use it to inspect requests with single millisecond latency.
The pricing for AWS WAF is usage-based, as often in AWS. It’s based on the AWS WAF Web ACL capacity units (WCU). WCU is a dimension used to calculate and control the operating resources that are used to process your rules within a web ACL. As a rule of thumb, we can assume AWS WAF is more expensive than the CloudFlare solution. For small scale deployments, we are seeing a running monthly cost of about $30. There are also more expensive setups available, for example, the feature-rich Shield Advanced costs 3000$ per month as a fixed price.
The AWS WAF offers great integration with other AWS services, but when adding it to an existing application be prepared for some unexpected issues. We’ve encountered problems with the E2E testing tool – Cypress.
Final thoughts
In the past, there was a significant difference between the CloudFlare WAF and AWS WAF. Cloudflare was a more automatic and easy to set up product, and the AWS solution was a more customizable and advanced tool. The two products were aimed at different markets, CloudFlare was more customer grade, mass market, and provide peace of mind by hiding the complexities in the background. AWS was a more powerful toolset for people who like to get their hands dirty and know the details.
Right now this distinction is not so clear anymore. CloudFlare introduced more advanced customizations, AWS added managed rules and make the product easier to setup. Be aware that the distinction from the past can still be visible in some areas of the solution.
If you have your infrastructure on AWS, choosing AWS WAF means easier setup, procurement, access and payment management. CloudFlare is a 3rd party tool that you have to manage. On the other hand, CloudFlare can be beneficial when using other cloud providers, on-premises or multi-cloud solutions.
Whatever you choose, both will help you in the first line of defence against SQL Injection attacks, Cross Site Scripting, CSRF and basic IP blocking. It’s definitely worth to use them.