Website developers and operation will inevitably encounter hackers. There are many fully automated hacking tools and scripts on the Internet that can scan your website for known security vulnerabilities and launch fully automated attacks in an attempt to seize control of the server. As a result, businesses often purchase web site application firewalls (WAFs) and deploy in front of the web server to block common attacks. Microsoft Azure also has a WAF service that allows us to deploy the firewall just within a few mouse click.

About Azure WAF

"Azure Web Application Firewall (WAF) is natively integrated and platform managed service that provides protection for your web applications from common exploits and vulnerabilities. Web applications are increasingly the targets of varied types attacks such as malicious bots, SQL injection attacks, and cross-site scripting attacks which can result in website site sabotages, exfiltration of sensitive data and application unavailability. Preventing such attacks in application code can be challenging and may require rigorous maintenance, patching, and monitoring at multiple layers of the application topology. A centralized web application firewall helps make security management much simpler and gives better assurance to application administrators against threats or intrusions. In addition, a WAF solution can react to a security threat faster by patching a known vulnerability at a central location, instead of securing each individual web application."

From Azure Portal

Why Choose Azure WAF over other WAFs

Simple enough, the conclusion from a professional test discovered that:

"Azure WAF was the clear winner and the only service that performed well in blocking real-world attacks in our test." - Cloud WAF Comparison Using Real-World Attacks

Create Azure WAF

Go to Azure Portal, Click "Create a resource", search for "WAF" and select "Web Application Firewall", click "Create".

Azure WAF can be integrated with Front Door, Application Gateway and Azure CDN. I will use Front Door in my case, just give it a policy name.

Set mode to prevent, that is, intercept mode, which can prevent the hacker attack. The detection mode will only record logs, and allow attacks to pass through, pretending not seeing them.

Leave Block response body as empty, or set a "friendly greeting" to the hacker.

Several commonly used firewall rules provided by Microsoft are listed in Managed rules, and you can check the ones you need. It covers common SQL injection, XSS, Windows and Linux remote command execution, PHP injection, malicious robots, etc. Imagine, if there is no WAF, how much time would it take to write code to fully defend against these attacks? With Azure, you only need to click mouse a few times to complete the configuration.

Custom rules allow us to set custom firewall rules not provided by Microsoft. We will introduce it later. These rules along with Managed rules can be changed after the WAF is created.

Since this WAF policy is set to Front Door in the first step, we need to associate it with the domain name in Front Door. I will skip this process since I have covered Front Door in my previous blog post.

Finally, click Review + Create to complete the WAF creation. If the Front Door is successfully associated, wait about 5 minutes for the WAF to take effect.

Set Custom Rules

Azure WAF allows users to customize firewall rules very flexibly. For example, my blog is not written in PHP, so the request for .php is often a hacker scanning tool. I want to block .php requests. Then I can add a custom rule to find the request whose URL ends in .php and block it.

As for the scanning tool for hackers, I didn't make up a fake one. I can show you a practical case. During the 11 years of operation of my blog, it was frequently scanned by hacker tools. After using Azure, Application Insight was able to detect this large number of 404 requests in a short time:

I found that almost all failures during this period are 404. In fact, the website can be accessed normally during this time.

Drill into the report, I can find that these 404 requests are hacker tools trying to common PHP system vulnerabilities.

And also a few SQL injection attempts:

In fact, the managed rules of Azure WAF can prevent most of these scans, but if you want to implement custom rules, you can, for example, block all .php requests.

Enter Azure WAF, Custom rules, and add a custom rule.

Specify a name, such as BlockPHPExtension, and set the Rule type to Match

To match all requests ending in .php, we can set the rule as follows.

After saving the rules, wait about 5 minutes and try to access the URL ending in .php. It will result in a 403 error.

The response header also indicates it is blocked by Azure WAF with a x-azure-ref header, which can be used to investigate the firewall log.

This Custom rules also supports multiple condition combinations. For example, blocking or only allowing requests from certain countries and regions, blocking a large number of requests in a short time (Rate limit), blocking large data requests (Size), and so on. 

What about False Positive

Sometimes, Azure WAF will friendly fire on our website, such as blocking Azure AD SSO in my blog. 

In order to investigate these false positives, we need to first turn on WAF logs. 

Go to the Azure Front Door which is associated with this WAF, enter Diagnostic settings, click + Add diagnostic setting

Check FrontdoorWebApplicationFirewallLog in Category details. It is recommended to keep logs for 30 days. I set log destination to 2 locations, Log Analytics and storage account. Choose whatever you like.

Now, access the blocked URL again, and wait a few minutes for the logs to be sent to destination locations. Take storage account for example, WAF logs will appear in a container named ingishts-logs-frontdoorwebapplicationfirewalllog

Open the container and you will find log files in Json format. Download and open the log. 

In the log, I can see a rule named DefaultRuleSet-1.0-SQLI-942440 is blocking my request, 942440 is it's ID which can later be used to filter rules in WAF settings. The reason why this request got blocked is shown in matches node. The ASP.NET Core cookie was considered suspicious, but actually it is safe.

Now, go back to the Azure WAF in Azure portal, search for ID 942440, the particular rule is filtered out. Although I can disable the rule or set it's action as no block, this can be dangerous because by doing so also let real attacks go through. So I need to set a exclusion just for my case. Click "Manage exclusions".

Add a new exclusion for rule 942440, for quick demo purpose, I just allow anything with a .AspNetCore.Cookies cookie in this rule. In real world case, please consult your company's security expert for setting an exclusion correctly.

Save the exclusion rule and wait about 5 minutes for WAF to refresh. Now, I am able to sign in to my blog admin portal again.

Conclusion

Azure WAF is easy to deploy. Microsoft default rules are powerful for most common scenarios. Azure WAF is also flexible enough for users to set custom rules and exclusions. 

You can learn more about Azure WAF here.