In part one of this post we looked at configuring an Azure Application Gateway to secure your web application front-end, it is available here.
In part two we will be looking at some additional post configuration tasks and how to start investigating whether the WAF is blocking any of our application traffic and how to check for this.
First up we will look at configuring some NSG (Network Security Group) inbound and outbound rules for the subnet that the Application Gateway is deployed within.
The inbound rules that you will require are below.
- Allow HTTPS Port 443 from any source.
- Allow HTTP Port 80 from any source (only if required for your application).
- Allow HTTP/HTTPS Port 80/443 from your Web Server subnet.
- Allow Application Gateway Health API ports 65503-65534. These are required for correct operation of your Application Gateway.
- Deny-all other traffic, set this rule as a high value ie. 4000 – 4096.
The outbound rules that you will require are below.
- Allow HTTPS Port 443 from your Application Gateway to any destination.
- Allow HTTP Port 80 from your Application Gateway to any destination (only if required for your application).
- Allow HTTP/HTTPS Port 80/443 to your Web Server subnet.
- Allow Internet traffic using the Internet traffic tag.
- Deny-all other traffic, set this rule as a high value ie. 4000 – 4096.
Now we need to configure the Application Gateway to write Diagnostic Logs to a Storage Account. To do this open the Application Gateway from within the Azure Portal, find the Monitoring section and click on Diagnostic Logs.
Click on Add diagnostic settings and browse to the Storage Account you wish to write logs to, select all log types and save the changes.
Now that the Application Gateway is configured to store diagnostic logs (we need the ApplicationFirewallLog) you can start testing your web front-end. To do this, firstly you should set the WAF to “Detection” mode which will log any traffic that would have been blocked. This setting is only recommended for testing purposes and should not be permanent state.
To change this setting open your Application Gateway from within the Azure Portal and click Web Application Firewall under settings.
Change the Firewall mode to “Detection” for testing purposes. Save the changes.
Now you can start your web front-end testing. Any traffic that would be blocked will now be allowed, however it will still create a log entry showing you the details for the traffic that would be blocked.
Once testing is completed open your Storage Account from within the Azure Portal and browse to the insights-logs-applicationgatewayfirewalllog container, continue opening the folder structure and find the date and time of the testing. The log file is named PT1H.json, download it to your local computer.
Open the PT1H.json file. Any entries for traffic that would be blocked will look similar to the below.
[code language=”javascript”]
{
“resourceId”: “/SUBSCRIPTIONS/….”,
“operationName”: “ApplicationGatewayFirewall”,
“time”: “2018-07-03T03:30:59Z”,
“category”: “ApplicationGatewayFirewallLog”,
“properties”: {
“instanceId”: “ApplicationGatewayRole_IN_1”,
“clientIp”: “202.141.210.52”,
“clientPort”: “0”,
“requestUri”: “/uri”,
“ruleSetType”: “OWASP”,
“ruleSetVersion”: “3.0”,
“ruleId”: “942430”,
“message”: “Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (12)”,
“action”: “Detected”,
“site”: “Global”,
“details”: {
“message”: “Warning. Pattern match \”,
“file”: “rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf”,
“line”: “1002”
},
“hostname”: “website.com.au”
}
[/code]
This will give you useful information to either fix your application or disable a rule that is blocking traffic, the “ruleId” section of the log will show you the rule that requires action. Rules should only be disabled temporarily while you remediate your application. They can be disabled/enabled from within the Web Application Firewall tab within Application Gateway, just make sure the “Advanced Rule Configuration” box is ticked so that you can see them.
This process of testing and fixing code/disabling rules should continue until you can complete a test without any errors showing in the logs. Once no errors occur you can change the Web Application Firewall mode back to “Prevention” mode which will make the WAF actively block traffic that does not pass the rule sets.
Something important to note is the below log entry type with a ruleId of “0”. This error would need to be resolved by remediating the code as the default rules cannot be changed within the WAF. Microsoft are working on changing this, however at the time of writing it cannot be done as the default data length cannot be changed. Sometimes this will occur with a part of the application that cannot be resolved, if this is the case you would need to look at another WAF product such as a Barracuda etc.
[code language=”javascript”]
{
“resourceId”: “/SUBSCRIPTIONS/…”,
“operationName”: “ApplicationGatewayFirewall”,
“time”: “2018-07-03T01:21:44Z”,
“category”: “ApplicationGatewayFirewallLog”,
“properties”: {
“instanceId”: “ApplicationGatewayRole_IN_0”,
“clientIp”: “1.136.111.168”,
“clientPort”: “0”,
“requestUri”: “/…./api/document/adddocument”,
“ruleSetType”: “OWASP”,
“ruleSetVersion”: “3.0”,
“ruleId”: “0”,
“message”: “”,
“action”: “Blocked”,
“site”: “Global”,
“details”: {
“message”: “Request body no files data length is larger than the configured limit (131072).. Deny with code (413)”,
“data”: “”,
“file”: “”,
“line”: “”
},
“hostname”: “website.com.au”
}
[/code]
In this post we looked at some post configuration tasks for Application Gateway such as configuring NSG rules to further protect the network, configure diagnostic logging and how to check the Web Application Firewall logs for application traffic that would be blocked by the WAF. The Application Gateway can be a good alternative to dedicated appliances as it is easier to configure and manage. However, in some cases where more control of WAF rule sets are required a dedicated WAF appliance may be required.
Hopefully this two part series helps you with your decision making when it comes to securing your web front-end applications.