Azure-docs: Allow Action explain

[TomaszOledzki]

“Allow – Authorizes the transaction, skipping all subsequent rules. This means that the specified request is added to the allow list and once matched, the request stops further evaluation and is sent to the backend pool. Rules that are on the allow list aren't evaluated for any further custom rules or managed rules.”

According to this, if I have a false positives on CRS and I’ll create a rule to allow request when certain regex is in the value of certain attribute on the JSON in the body in the request, then WAF stops checking such request using CRS (ie. for SQL injection in the header) and just passes it? This means custom rules aren’t really sufficient for preventing false positives on CRS rules?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 26c3e97e-759e-c50e-ce05-29dbd91830ab
• Version Independent ID: 28f16dcd-4cef-366a-154e-b56f9c29b868
• Content: Azure Web Application Firewall (WAF) custom rules
• Content Source: articles/application-gateway/custom-waf-rules-overview.md
• Service: application-gateway
• GitHub Login: @vhorne
• Microsoft Alias: victorh

[TravisCragg-MSFT]

@TomaszOledzki You should only make allow rules for things that you know will be ok to pass to the backend 100% of the time. Here is an example of a custom SQL rule.

[ketaanhshah]

@TravisCragg-MSFT Hey Travis with this new release I am not sure what has changed, anyway to know that? Also is it possible to change the PARANIOA LEVEL from default value of 4 to lets say 1? I understand that degrades security but is it possible somehow in Azure App Gate WAF to change the PARANIO LEVEL to 1 as I am not sure where the crf-setup.config exists and how we can change it? Any help on that?

[TravisCragg-MSFT]

@ketaanhshah What exactly are you referring to with the "PARANIO LEVEL"? Custom rules allow you to either Allow or Deny based upon the priority of the rule.

[ketaanhshah]

Thats correct the custom rules allow us but I was looking for an option where I can downgrade the PL from 4 to 1. More details here on this thread:-
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1449#issuecomment-501429738

[TravisCragg-MSFT]

@ketaanhshah I do not believe that you can change the default OWASP configuration, your best bet will be to make a custom rule.
I am following up now to get a definitive answer on if there is a way to change the Paranoia level, and will follow up here.

[ketaanhshah]

@TravisCragg-MSFT Thank you so much Travis that will be great as we have been struggling a lot to get out application go live on Azure just because of all the FALSE POSTIVES we getting and we really need this answer so in that case we will build the custom rules. One more question I had was..If we create a custom rule with lower number level for lets say allowing some SQLCI related warning we got from out of the box rule, in that case do we have to disable the out of the box BLOCK rule or that can remain enabled and our custom rule will superceed it and allow the request to pass thru?

[TravisCragg-MSFT]

@ketaanhshah You can disable most of the existing OWASP rules If you know which rule is giving you the issue.

If a custom rule is created and a request matches the custom rule, it will immediately be allowed or denied, and no further firewall checks will be made. If you have a custom allow rule, you will not need to disable a competing default rule.

[ketaanhshah]

@TravisCragg-MSFT you are wonderful sir, thank you so much again for super prompt response! Really apprecaite it a lot. I am fairly new to this and is there anyway you can guide me on how I can get some custom rules like REGEX rule, User agent string rule, etc.. for some of the following FP we getting?

Resource | ruleSetType_s | ruleSetVersion_s | ruleGroup_s | ruleId_s | action_s | site_s | details_message_s | details_data_s | details_file_s | details_line_s | hostname_s | Message | requestUri_s | count_
-- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
PROD2-APPGW | OWASP | 3 | 942-APPLICATION-ATTACK-SQLI | 942370 | Matched | Global | Warning. Pattern match "(?i:(?:[\"']\\s*?\\*.+(?:x?or\|div\|like\|between\|and\|id)\\W*?[\"']\d)\|(?:\^[\"'])\|(?:^[\\w\\s\"'-]+(?<=and\s)(?<=or\|xor\|div\|like\|between\|and\s)(?<=xor\s)(?<=nand\s)(?<=not\s)(?<=\\|\\|)(?<=\&\&)\w+\()\|(?:[\"'][\\s\\d]*?[^\\w\\s]+\\W*?\\d\ ..." at REQUEST_COOKIES:fs_uid. | Matched Data:4703519480414208:62 found within REQUEST_COOKIES:fs_uid: rs.fullstory.comM4G4J4703519480414208:6216073757261824 | rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf | 841 | | Detects classic SQL injection probings 2/2 | / | 1
PROD2-APPGW | OWASP | 3 | Default | 0 | Detected | Global | Warning. Operator GE matched 5 at TX:anomaly_score. | rules/REQUEST-949-BLOCKING-EVALUATION.conf | 57 | | Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded (Total Score: 5) | / | 14
PROD2-APPGW | OWASP | 3 | Default | 0 | Detected | Global | Warning. Operator GE matched 5 at TX:inbound_anomaly_score. | rules/RESPONSE-980-CORRELATION.conf | 73 | | Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): Detects classic SQL injection probings 2/2 | / | 13

[TomaszOledzki]

@TomaszOledzki You should only make allow rules for things that you know will be ok to pass to the backend 100% of the time. Here is an example of a custom SQL rule.

@TravisCragg-MSFT IMO omitting CRS on the first hit of custom rule is a bad approach. Custom rules should allow to omit certain CSR for specific requests.

[ketaanhshah]

@TravisCragg-MSFT Thank you Travis, so one of our rules we wanted to write was for allowing the requests to go thru if the cookie contained "__RequestVerificationToken" and the value for this key in the cookie can contain "--" or some special characters and then it should be allowed to go thru. So if I had to create a custom rule for this, will something like this be correct? I am not sure how we evaluate both the Key and its value to contain "--" in this rule

`

`

[ketaanhshah]

@TravisCragg-MSFT @TomaszOledzki and now with the new Custom rule I cant even associate the WAF policy with OLD Application Gateway created earlier in our environment V1 version, is this not allowed? I created a ticket/issue in for that:-

https://github.com/MicrosoftDocs/azure-docs/issues/33262#issue-455807476

[TomaszOledzki]

@ketaanhshah I believe custom rules are supported on WAF v2 only. For WAF v1 you have to use WAF exclusion lists: https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-waf-configuration#waf-exclusion-lists

[ketaanhshah]

@TomaszOledzki aah my God then it means we have to upgrade to V2 Gateway and use it as the exclusion list is not good enough of help here.

[TravisCragg-MSFT]

@TomaszOledzki I absolutely agree with you, the first hit is not enough reason to remove a rule.

@ketaanhshah Your best bet is to follow up with that ticket going forward

[ketaanhshah]

Thank you @ TomaszOledzki

[TravisCragg-MSFT]

@ketaanhshah If you would like to upgrade to a V2 Gateway, the process was recently released and you can find it here.

[ketaanhshah]

@TravisCragg-MSFT Thank you Travis this is exactly the place we used, and after doing this in our test/dev environment we re-read the warning logs and u wont blive you would ROFLOL what we found was the CRS issues/warnings were about a cookie and its value and all we needed was the exclusion rule! So we applied the exclusion rule and viola! even in V1 WAF we were able to do away all the warnings and anamolies we were getting! But in this process I learnt a lot and I really thank you for helping me throughout the way! I certainly can say now this is NEW Microsoft super prompt! super helpful!

[TravisCragg-MSFT]

@ketaanhshah I just saw your other post stating this as well. Glad to hear that everything is resolved!

[TravisCragg-MSFT]

@TomaszOledzki is there anything else that I can assist you with regarding this issue?

[TravisCragg-MSFT]

@TomaszOledzki We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.