In-Depth

First Look: Azure Web Application Firewall

Learn how to configure and protect cloud-based apps in Azure.

• By Brien Posey
• 07/25/2017

Despite the relative maturity of the Web, it is still the most hostile environment imaginable. Given the vast array of threats that exist online, including distributed denial-of-service (DDoS) attacks, it's important to protect your Web applications to the greatest extent possible. Web Application Firewalls (WAFs) are the best line of defense. Microsoft has recently added an option to its Azure public cloud to build application gateways that have a built-in WAF.

Although the Azure Web Application Firewall is a Microsoft solution, certainly there's no shortage of WAFs available from the likes of Akamai Technologies Inc., Barracuda Networks Inc., Citrix Systems Inc., Cloudflare Inc., F5 Networks Inc., Fortinet Inc., Radware Ltd. and Trustwave, among others.

WAFs work differently from a standard IP firewall. A normal firewall is designed to block individual TCP or UDP ports, or to restrict the type of traffic that's allowed to flow across a particular port. However, WAFs are designed to monitor HTTP or HTTPS traffic that's being sent to a Web application. The firewall's job is to determine whether the traffic is normal user traffic, or if it's something malicious. An example of a malicious request might be a hidden field manipulation attack. If malicious traffic is detected, then the WAF will block the request to prevent it from reaching the Web application server, and will typically also terminate the session.

In addition to the obvious secur­ity benefits of a WAF, there's another advantage to its use. Imagine for a moment that an organization has numerous Web applications that it needs to protect. In such a situation, a WAF could act as a centralized security mechanism that protects all of the organization's Web applications against malicious HTTP or HTTPS requests.

Although WAFs can make security more convenient, it's important to continue to practice defense in depth. After all, a WAF can act as a centralized access control mechanism, but it can also become a single point of failure. Consequently, WAFs don't replace the need to maintain established security best practices for all Web application servers, rather than depending solely on a WAF to keep the Web applications secure.

Microsoft's new WAF is available to Azure subscribers. Although the WAF is a new feature in Azure, Microsoft exposes it through application gateways, which have existed in Azure for quite some time.

The setup screen for the WAF option in Azure creates an appli­cation gateway. As shown in Figure 1, a new Tier option lets you create either a standard gateway or a WAF-enabled gateway.

If you already have one or more application gateways in place, you'll welcome the fact that you don't have to create a brand-new application gateway in order to implement a WAF. It provides a way to upgrade an existing gateway to the WAF tier.

In my sample gateway (see Figure 2), which is a standard application gateway, when I select it, the WAF is listed among the application gateway's settings.

Clicking on the WAF setting causes Azure to display an option to upgrade to the WAF tier. At first glance, this screen is a little bit misleading (see Figure 3). The screen prominently displays an error message, indicating the current tier doesn't support WAF. However, this error message doesn't mean that you cannot enable the WAF for the application gateway. It merely means that you're going to need to upgrade to the WAF tier before you do. Thankfully, there's a simple checkbox that you can use to upgrade to the WAF tier.

When you select the Upgrade to WAF Tier checkbox, the Azure portal reveals a few extra options (see Figure 4). It's important to note that a message is displayed when the Azure portal indicates the upgraded tier will be a WAF, and that the SKU size will be Medium. This is important because the WAF can't run on a small-sized SKU. As such, there might be increased costs associated with upgrading your application gateway tier.

The WAF service is available in several configuration options. The first is the Firewall Status option. While it's self-explanatory, it lets administrators enable or disable the WAF. The second option that's available for configuration is the Firewall Mode. As you can see in Figure 4, the Firewall Mode can either be set to Detection or to Prevention.

When the firewall runs in Detection mode, the WAF will monitor the application firewall for any perceived threats, but will not take any action beyond logging those threats. It's a good idea to initially configure the WAF to use Detection mode, and then eventually switch to Prevention mode. Detection mode gives you a chance to find out exactly how the firewall is going to behave without putting your Web application at risk in the process. If after reviewing the logs, you determine that everything is working correctly, you can easily switch to Prevention mode. If, on the other hand, you discover problems with the way that the firewall is working, you'll have a chance prior to enforcing the firewall's rules through prevention mode.

Also important, you'll notice in Figure 4 that the firewall mode is currently set to Detection. Likewise, it will be apparent if Azure is displaying an error message warning that to view your detection logs, you must have diagnostics enabled. Diagnostics are not enabled by default, but you can easily enable them.

To enable diagnostics, click on the Diagnostic Logs tab, and then click on the Turn on Diagnostics link. When prompted, set the Status option to On, enable any additional logging options that you wish to use, and then click the Save button.

Enabling Prevention mode causes the firewall to actively block any attacks that it detects. Whenever the firewall detects an attack or an intrusion attempt, it'll send a 403 error (unauthorized access) to the attacker, and then sever the attacker's connection. The last option shown on the WAF configuration screen is the Rule Set option. WAFs work by evaluating inbound traffic against a set of rules. These rules help to determine whether the traffic fits into normal usage patterns, or if it's something potentially malicious. These rules function somewhat similarly to the way that the virus definition database works within an anti-malware program. In essence, the rule set contains a series of attack signatures. For example, a rule that might contain attack signatures will allow the firewall to recognize a SQL Server injection attack, or a cross-site scripting attack.

Currently, Microsoft provides two different rule sets that you can choose from: CRS 2.2.9 and CRS 3.0. CRS 3.0 is the preferred rule set because it's newer. Because the WAF works based off of a series of rules, administrators must consider what would happen if a rule ends up causing problems for their particular Web application. This isn't really all that common of a situation, but in the event a rule does prove to be problematic, you can disable it.

An Advanced Rule Configuration checkbox is also displayed in Figure 4. Selecting this checkbox causes the Azure portal to list the available rules (see Figure 5).

The rule set is divided into a series of categories, and each category contains multiple individual rules. In Figure 5, for example, REQUEST-910-IP-REPUTATION and REQUEST-911-METHOD-ENFORCEMENT are both rule categories. The REQUEST-911-METHOD-ENFORCEMENT cat­egory has been expanded to reveal the rules that fall into the category. The rules in this category are numbered 911011, 911012, 911013 and so on.

Given the WAF uses such obscure names for its rules and rule groups, you may wonder how to determine which rule does what. The rule group names do provide a bit of a hint as to what the rules within the group do, although in some cases these hints are more obvious than others. For example, the REQUEST-910-IP-REPUTATION rule group contains rules that protect your application based on the reputation of the IP address that's making the request. Essentially, the rules in this rule group protect you against those who are known to have malicious intent.

The REQUEST-911-METHOD-ENFORCEMENT rule group's purpose is a little bit less obvious. This rule group contains rules that are designed to lock down methods such as PUT and PATCH.

If you want to explore the rules and rule groups, check out Microsoft's documentation here. This page contains a list of every rule group, and what those rule groups do. Keep in mind that CRS 2.2.9 and CRS 3.0 use different rules and rule groups, so be sure to look at the rule groups that correspond to your selected set of rules. Incidentally, clicking on a rule group opens a page that lists the individual rules within the group. Microsoft provides descriptions for some of the rules, but provides no hint at what most of the rules do. If you really need to know what a particular rule does, you may be able to do a Web search on it, or contact Microsoft support. You may also be able to find some useful information posted by The Open Web Application Security Project here.

Microsoft's Web Application Firewall is a handy tool for protecting Web applications running on Azure. Because the WAF leverages the Azure application gateway, it's possible for a single WAF to protect multiple Web applications.