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.
Related
Yesterday Azure Frontdoor was down for 45 mins, and i could not access my webapps.
Can I put something in front of my Azure Frontdoor to handle this downtime ?
One of the workaround you can follow to resolve the above issue,
As of now i have not faced this issue .
Please Make sure that you have enabled below configuration in your routing rules .
Also in App service configuration by default its of , On this feature for redirect all HTTP traffic to HTTPS . Post that restart your webapp and run.
NOTE:- In backend pool there is configuration Priority and weight which have default value 1 and 50 ,Try to increase the weight as well which has max limit upto 1000.
For more information please refer the below links for Azure front door configuration:-
MICROSOFT DOCUMENTATION|CREATE FRONTDOOR FOR YOUR APPLICATION.
BLOG| Steps to implement Microsoft Azure Front Door Service.
I had the same issue and ended up using Application Gateway when outages are happening. Depending on how you do this it can be manual or automatic.
Hope this helps!
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'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.
What am I trying to do
I have to azure apps deployed as App services. To make rest post easy let's call them "blog" and "landing_page". Both of them are hosted, so they URL are blog.azurewebsites.net and landing_page.azurewebsites.net.
I want to configure "something" in Azure with following rules:
if user access http://mydomain/ - content of landing_page.azurewebsites.net
if user access http://mydomain/blog - content of blog.azurewebsites.net
What I tried
After reading documentation, I have to reject Traffic Manager because it works on DNS level. From the other two I decided to use Application Gateway, because it should work on eny Endpoint (Any Azure internal IP address, public internet IP address, Azure VM, or Azure Cloud Service).
I configured my Application Gateway setting backend to: landing_page.azurewebsites.net. But in "Backend health" the app status is unhealthy. I tried also:
blog.azurewebsites.net - unhealthy
www.wp.pl (polish news portal) - is working
gazeta.pl (polish news portal) - is working
stapp.space (my blog) - this is same as piotrstapp.azurewebsites.net and status is unhealthy
Question :)
What did I wrong? Maybe should I use something else on Azure? Or am I missing something?
Make sure that custom probes is turned on and configured in the HTTP settings of the WAF for your site. If you don't the Application Gateway will try to go to the IP of the App Service Environment without passing a Host header, which won't work and will throw the probe into an unhealthy state resulting in a "502 Gateway Proxy" error.
There is a great article here
You may want to check out Azure's application gateway path-based rules function:
Create a path-based rule for an application gateway by using the Azure portal
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