I've set up ASE v2 and enabled WAF. But one of the web apps behind it requires ".axd" requests to be enabled. WAF rules block such requests (.../something.axd) - specifically, I see WAF blocks it with 'rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf'. I'd just remove '.axd' extension for this rule and for one particular web app (url). Can I do this?
It's not supported. But is under consideration.
Related
We apply the Azure Application Gateway Web Application Firewall (WAF) to provide additional preventions against malicious attacks such as SQL Injection, Cross-Site Scripting, etc on an Azure App Service. However, when I put the WAF in prevention mode, socket.io traffic are also getting blocked. I'm looking for the right exclusion rule to allow socket.io traffic to go through.
What exclusion rules should I use?
I have a classic ASP.NET 4.7 Azure Web service with an Web API.
How to restrict access to some URL-path of Azure Web service from Internet while allow to access the whole web site, and allow access to the restricted path from a VNet?
I tried to solve the problem using Azure Application Gateway, but it does not work properly. Here is the question How to route to another path with Azure Application Gateway?
From perspective of coding, you could use this similar way instructed here to authorized on specific URL based on IP address.
From perspective for Azure Application Gateway, you could try using custom rules:
Allowing and blocking traffic is simple with custom rules.
For example, you can block all traffic coming from a range of IP addresses.
You can make another rule to allow traffic if the request comes from a specific browser.
You can leverage "RequestUri" variable in Match variable section. (Not professional on WAF, so didn't test this way)
I'm setting up WAF rules for azure front door services provided by Microsoft Azure. Currently, I'm using default ruleset 1.0 provided OTB to block top 10 OWSAP threats.
When default rules are enabled, we observe 403 error and not able to understand which policy is blocking the request.
Any change to WAF policy takes minimum 7 to 15 minutes to get applied. I need to understand if there is any efficient way to make the change and test.
What is the best possible way to determine what ruleset needs to be enabled or disabled ?
We tried enabling all ruleset and website started throwing 403 error. Currently, we are enabling one rule at a time and verifying if the rule blocks any requests.
WAF with FrontDoor log is integrated with Azure Monitor. You could enable diagnostics settings and track any request that matches a WAF rule in the FrontdoorWebApplicationFirewallLog logs. The following example query obtains WAF logs on blocked requests:
AzureDiagnostics
| where ResourceType == "FRONTDOORS" and Category == "FrontdoorWebApplicationFirewallLog"
| where action_s == "Block"
Additionally, you could refer to monitoring metrics and logs in Azure Front Door Service and a good blog which tells how to view WAF diagnostic logs and tune the WAF policy rules even it's for app GW example.
We are using Azure Application Gateway and Web Application Firewall (WAF) and what we want to do is we want to change the PARANOIA LEVEL from 2 to 1.
One of the OWASP Engineer helped me the command we can use to switch it setvar:tx.executing_paranoia_level=1 in the crs-setup.conf. But now I am not aware in Azure and App Gateway WAF where we make this change?
Anyone aware of where this CRS-SETUP.CONF exists and how we can modify the PARANOIA LEVEL?
Thank you,
I am not aware of the CRS-SETUP.CONF existence. I think Azure WAF is like a PaaS service Azure should not expose the underlying configuration to users. Azure Application Gateway (WAF) protects web applications through rules that are defined based on the OWASP core rule sets 3.0 or 2.2.9. If you want to control the conf file, you may contact Azure support.
If you have some false positives, you can do a few things to stop this from blocking your traffic.
Use a WAF Exclusion List. WAF exclusion lists allow you to omit certain request attributes from a WAF evaluation.
Disable the rule. See Customize web application firewall rules through the Azure portal for details.
To disable rule groups or specific rules
Search for the rules or rule groups that you want to disable.
Clear the check boxes for the rules that you want to disable.
Select Save.
It's recommended to go through this article to learn troubleshooting Web Application Firewall (WAF) for Azure Application Gateway.
I'm trying to understand whether the Azure API Management suite includes any WAF functionality (as described by OWASP for example) within its Security or Policy settings.
If "no" or "don't" know does it make sense to front public-facing APIs (that handle PII), exposed via the Azure API Management with a Web Application Firewall (WAF), or anywhere else in the Cloud -> APIM -> VPN -> Firewall -> On-Premise services topology?
Thanks in advance
Based on this list of WAF capabilities, API Management can do some of these things out of the box, many could be implemented using custom policies and some of these things cannot be done. Policies can manipulate HTTP requests and responses. However they cannot function at a level lower than this.
There is no built-in functions to try and prevent injection attacks, but it is possible to build them. It is also a reasonable option to deploy a dedicated WAF between API Management gateway and your APIs.
You can make your API Management Service private inside a subnet and put App Gateway with WAF in front of it. The tricky part is that this is available only in the Premium plan for API Management.
However, since ultimately you want to protect your application not the APIMS from attacks like SQL injection, you can put AppGateway+WAF between APIMS and your application. At the same time AppGateway will be your Load Balancer.
SSL and end-to-end encryption will need some attention.
Its best to have a separate WAF module on top of your APIMS.
APIMS <-> WAF <-> LB
API abusing is trending these days .I think WAF protection inbuilt to many cloud providers are basically in its infantry stage . Better to use some dedicated WAF modules