Vasily

My feedback

  1. 207 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    started  ·  14 comments  ·  Networking » Azure Front Door Service  ·  Flag idea as inappropriate…  ·  Admin →
    Vasily supported this idea  · 
    Vasily commented  · 

    This is a showstopper for us too. There is a case, in our we app, when the timeout exceeds 30s. The request is issued by a popup window where the long delay doesn't look particularly "user unfriendly". With the Front Door, the user receives an error (the Front Door service unavailability page) in the popup. A workaround could be to re-implement the client/server interaction so it became asynchronous, but, currently, such a refactoring is problematic for us.

    Microsoft, please let us configure the timeout! (And not the way you let us configure the request body SIZE limit for the Application Gateway based WAF: its maximum of 128kb is "utterly" insufficient, and there is no way to avoid the check for specific URLs.) For the TIMEOUT, the maximum should be no less than an hour - for guaranteed allowance.

    In some scenarios, we aren't even going to use the load balancing capability of the Front Door: just the firewall one. Alas, we can't do even that!

    We are a company that's been developing accounting and planning software for about 30 years.
    We've migrated our software to Azure, and are trying to implement a Windows Application Firewall to be protected from OWASP top 10 vulnerabilities. Our attempt to implement the WAF based on the Application Gateway has failed because of the request body size limit. Even using the Firewall Policy (custom rules), it is impossible to define requests that would be exempt from the size check. Our attempt to implement the WAF based on the Front Door has failed because of the request timeout limit. The failure is preventing us from the implementation of our systems on MS Azure platform *for demanding customers*. We've been able to run our software as an Azure cloud service (classic) for years.

    Thank you for your attention to this issue!

  2. 331 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    16 comments  ·  Networking » Application Gateway  ·  Flag idea as inappropriate…  ·  Admin →
    Vasily supported this idea  · 
    Vasily commented  · 

    This is a showstopper for us too. Our client app may post a sizable request to a SOAP web service (not a file upload). The request size may grow up to tens of Megabytes. We could disable the rule check for a particular path using a WAF Policy custom rule - alas, the request size check is a global mandatory rule that can only be disabled along with the "entire firewall".
    The protection from the OWASP Top 10 vulnerabilities is the main reason why we have implemented the Application Gateway with our ERP Suite. Now, we cannot enable the protection.
    It's understood why Microsoft is "limiting the request size configurable limit" to a relatively small value of 128kb - performance concerns. OK, please let us completely exclude a particular path from the WAF processing - so the request size check was also disabled.
    Thank you for your attention to this issue!

  3. 174 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    10 comments  ·  Networking » Application Gateway  ·  Flag idea as inappropriate…  ·  Admin →

    Thanks for the valid suggestion. Your feedback is now open for the user community to upvote which allows us to effectively prioritize your request against our existing feature list and also gives us insight into the potential impact of implementing the suggested feature

    Vasily commented  · 

    Thank you for your instructions, Chris!
    Unfortunately, the custom rule approach does not work for us: our rule that allows traffic is triggered, but the request fails anyway because the Request Body Size Limit is a mandatory rule that cannot be overridden, AFAIU. There is a case in our web app when a big chunk of data is posted to the server in a "regular" request (not a file upload). We've set up a WAF v2 Policy with a custom rule that Allows traffic for this type of requests, alas, we're getting 413 Request too large error again!
    It's like we've hit the wall! Our WAF has been fully set up and tuned up for our web app, now we can't use it. While it could be possible to re-implement the problem request in our app, it would be very complex a task.
    It would be great if WAF allowed to exclude specific requests from the Inspection completely, including the body size!

    Can anyone suggest a solution or a workaround for the issue?
    Is Microsoft planning to address this issue in any way?
    Is it possible to override or ignore the Request Body Size Limit for certain requests?

    Thank you!

    P. S. What's also strange about the custom rule we've set up, in the firewall log, the action recorded for it is still Blocked! The Message, in the Details, nevertheless spells "Allowed":

    { "resourceId": "/SUBSCRIPTIONS/***/RESOURCEGROUPS/***/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/WAFV2", "operationName": "ApplicationGatewayFirewall", "category": "ApplicationGatewayFirewallLog", "properties": {"instanceId":"appgw_3","clientIp":"***","clientPort":"","requestUri":"\/stocksimportdata\/nasdaq.aspx","ruleSetType":"","ruleSetVersion":"","ruleId":"40","message":"Mandatory rule. Cannot be disabled. Custom rule with name: excludeimpdata, priority: 40","action":"Blocked","site":"Global","details":{"message":"Access allowed (phase 2). Pattern match \\\"(importdata\/)\\\" at REQUEST_URI. ","data":"","file":"\\\"\/etc\/nginx\/modsec\/AppGw-CustomRules.txt\\\"","line":"2"},"hostname":"vm000003","transactionId":"AcDcAcAXocAJAcAcAcAcAcAm"}}

    I wonder if the Action value is simply hardcoded in the log generator - ?

Feedback and Knowledge Base