As much as we might like to think otherwise, cloud-native applications are web applications. We may build services, but their APIs are often RESTful, and where we may have used various remote procedure call technologies in the past, we’re now transitioning to the QUIC-based gRPC. All that means we’re running most of our applications’ interactions with the outside world over web protocols through the same limited set of ports.
Back in the early days of the internet, we were able to segregate applications by IP ports, using firewalls to block unwanted traffic by preventing access to unwanted ports. Attackers needed to scan the entire range of possible port numbers before finding vulnerabilities, reducing the size of the available attack surface and keeping risk to a minimum. Now, however, they can simply go to the familiar HTTP, HTTPS, and QUIC ports and try to break in using a reduced set of tools.
The shift to web-based APIs has made it easier for attackers to work at scale and harder for defenders to identify legitimate traffic and block out unwanted scans and attacks. Although it might initially be simpler to block all traffic and then scan HTTP packets, the sheer volume of traffic we’re putting through those ports can overload a traditional firewall. Then there’s the issue of how we identify and manage the traffic we do want. How can we spot the difference between valid and malicious queries on an API, blocking both denial-of-service attacks and attacks that use manipulated payloads to compromise your applications?
Secure Azure applications with Azure WAF
In Azure, that’s the role of the Azure Web Application Firewall (Azure WAF). Available as a standalone product and as part of the Azure Front Door content delivery suite, Azure WAF separates the traffic we want, or the good actors, from the traffic we don’t, or the bad actors. If you’re going to run a public-facing Azure application, a tool like this is essential. Private applications that treat Azure as an extension of your network, using VPNs or direct connections via services like ExpressRoute, are unlikely to need a WAF as only trusted and authenticated traffic should have access.
Microsoft has been regularly updating Azure WAF, and a recent major release of Azure Front Door came with a new release of WAF. Azure WAF comes in two versions: Global WAF for large-scale web applications is part of Front Door, and Regional WAF is for your own virtual infrastructures.
Which one you use will depend on how you’re deploying your application; if you’re deploying globally across multiple Azure regions using Front Door’s load balancers to direct traffic to the nearest application instance, then you’re likely to use Global and take advantage of its deployment in regional metropolitan edge data centers. Code that sits in a single region is more likely to use Regional, with the Azure WAF running as part of an Azure Application Gateway in your application infrastructure, deployed using tools such as ARM.
Deploying Azure WAF in a virtual infrastructure
If you’re running Azure WAF locally you have the choice of v1 and v2 instances. V2 was released recently and is a significant improvement over v1, adding scaling and reliability features. If you’re currently running v1, you won’t automatically upgrade to the new release and will need to upgrade manually, migrating settings and traffic to a new v2 WAF before removing any v1 instances. One important point is that you can’t move IP addresses to a new gateway, so it will need a new address. There’s a PowerShell script for the Azure CLI that will help with the update process.
The easiest way to deploy a v2 Azure WAF instance in a new environment is with an ARM template. This approach lets you build application security into any automated deployment, a key factor in delivering idempotent releases as part of any CI/CD (continuous integration and continuous delivery) pipeline.
You’ll need to first configure an application gateway for your VNet. This can be as basic as you want; what’s important is the firewall policies you apply. Microsoft uses the Open Web Application Security Project (OWASP) rulesets for its Azure WAF, so choose the version you want and apply it to your application gateway along with rules that manage basic request parameters, for example, limiting the size of request bodies to reduce the risk of malicious request payloads overloading your API with executable code. Other protections include defenses against SQL injection attacks, cross-site scripting, and malformed queries.
The latest WAF engine for the v2 release uses the OWASP core ruleset 3.2 release, which reduces the risk of false positives and adds rules that help protect Java applications. Choosing the ruleset is part of setting up your firewall. If you want to use 3.2 and the new engine, you must configure it along with your WAF instance since the default installation is the older 3.1 release. There are significant advantages to the new version: It’s up to 8 times faster on the same virtual infrastructure and can work with much larger requests. There are 14 different rule groups in CRS 3.2, allowing you to tune the rules that are applied based on your application requirements.
Integrating Azure WAF with other Azure security tools
Azure WAF is integrated with Microsoft’s Azure security tools, including Microsoft Defender for Cloud. This gives you a set of interesting options for managing your WAF, moving management out of your infrastructure team and into your security team, using their tools to manage rules once it’s deployed. Security specialists can create firewalls, manage rules, and deploy directly from the Defender for Cloud portal. One useful option is the ability to find unprotected applications using built-in scanning tools, which allows Azure WAF to protect vulnerable applications automatically.
As well as pushing alerts into the Defender for Cloud tools, Azure WAF integrates with Microsoft’s Sentinel security information event management tools. Your security team can use these to identify possible attacks quickly and use a mix of machine learning logs to hunt down new threats that may not have been initially obvious. Using a WAF as an additional sensor in your security environment is a good idea, as it sits at one of the obvious attack surfaces and can act as an early warning.
Interestingly Microsoft is taking Azure WAF outside the familiar data center with support on Azure’s global content delivery network, Azure CDN. This can perhaps best be thought of as an alternative to Cloudflare, providing protection well outside your application by protecting cached content with rate-control limits to stop DDoS attacks early. With technologies like Azure Static Web Apps taking advantage of Azure CDN to host applications at scale, using Azure WAF at the edge of the Azure network makes a lot of sense.
Microsoft makes it easy to add Azure WAF to your applications, which is a sensible approach to encourage adoption. Securing cloud-native applications shouldn’t be hard. Making it part of programmable infrastructure simplifies deployment, adhering to cloud-native architecture best practices. With web technologies key to modern application delivery, a WAF is an essential component of your infrastructure; all that matters is not whether you install one, but where.