Forum Discussion

Stefan_Klotz_85's avatar
Stefan_Klotz_85
Icon for Cirrus rankCirrus
Dec 21, 2015

ASM disable violations just for specific requests

During creation and fine-tuning of an ASM-policy (based on manually Rapid Deployment) we found lots of valid requests, which trigger for example an Attack Signature or RFC compliances checks. But instead of disabling the Attack Signature or the specific RFC compliance check for the whole policy, I would prefer to disable it just for the specific request. The source for such a trigger might be different (URL, parameter, header, content), but from my point of view the easiest and "top level" way to specify an exception would be the URL. But would this be possible, especially when there is a global wildcard URL (*) defined (does a more specific URL gets preferred, I would say yes based on the "Wildcards Order")?

 

I did some testing e.g. a request with a header, whose value triggers the "High ASCII character" violation. I tried different settings:

 

  • disable "Check characters on this URL"
  • set "Request Body Handling" to "Do nothing" for the wildcard header
  • set "Parameter Value Type" to "Ignore Value" (for another request where the trigger was on a parameter)

But the request was still blocked.

 

So in general, which type of violation can be disabled/configured on which level (URL, file type, parameter, header)? And if possible, how to configure this. Or is there any good documentation available, which handles such granularity?

 

Thank you!

 

Ciao Stefan :)

 

ASM Advanced WAF
security
waf

8 Replies

Sort By
  • Jinshu's avatar
    Jinshu
    Icon for Cirrus rankCirrus
    Dec 21, 2015

    Here you go..

    Local Traffic > Policies > asm_l7_policy_whatever.website.com > under Rules click on Add, give it a name, like policy_whitelist, operand: http-uri (leave rest of fields default) > condition: choose equals/contains/etc, value = your URI, click add, then click the Add further down where operand/event/etc is located.

    In the Actions area, target > asm, action > disable. Click Add where target/event/etc are. and Finished.

    Then once back at the main policy page, do a re-order and move the policy_whitelist you created above default, so it will disable on the URI string prior to hitting the default ASM enable.. once you done this once or twice, pretty simple and can be used a lot.

    Below Irule also does the same. If you are applying Irule please ignore the above section.

    when HTTP_CLASS_SELECTED { 
ASM::enable 
if { [HTTP::uri] starts_with "/sites/pentest/" } { 
ASM::disable 
} 
}

    -Jinshu

  • Tzoori_Tamam_95's avatar
    Tzoori_Tamam_95
    Historic F5 Account
    Dec 21, 2015

    I think that ASM::disable is a bit too harsh... It is preferable to unblock the specific request rather than disabling inspection totally.

     

    • Jinshu's avatar
      Jinshu
      Icon for Cirrus rankCirrus
      Dec 21, 2015
      It is disabling ASM inspection only the URI /sites/pentest/. :)
    • Stefan_Klotz_85's avatar
      Stefan_Klotz_85
      Icon for Cirrus rankCirrus
      Dec 21, 2015
      Yes correct Jinshu, but if the policy for example contains 20 checks and I just want to disable 2 of them, I'm losing the security advantages of the other 18 as well. And this is what I want to avoid.
  • Stefan_Klotz's avatar
    Stefan_Klotz
    Icon for Cumulonimbus rankCumulonimbus
    Dec 21, 2015

    Thanks for the quick responses.

     

    Jinshu: I'm aware of this method, but I don't want to disable the whole policy for the specific request.

     

    Tzoori: Seems to be interesting, especially with the ASM::violation command. But isn't there a more "straight forward" approach via the WebGUI? I'm having enough experiences with iRules, but the support-team not ;) Also it makes troubleshooting more complicate as such rules are not directly visible within the different ASM menu options.

     

    Ciao Stefan :)

     

  • Hannes_Rapp's avatar
    Hannes_Rapp
    Icon for Nimbostratus rankNimbostratus
    Dec 21, 2015

    It will be a difficult choice. Assuming that you do not want to implement any iRules, the second-best option I see is using two ASM security policies where one policy is the "lite version" of your main policy (duplicate of your main policy, minus several signature IDs). You can implement the trigger-logic in an LTM policy where instead of disabling the ASM checks, you conditionally select the lite policy for some specific HTTP paths, whereas your main policy is the default selection.

     

    This will enable you to avoid false positive alerts/blocks, but still grant you a decent level of security.

     

  • Stefan_Klotz's avatar
    Stefan_Klotz
    Icon for Cumulonimbus rankCumulonimbus
    Dec 21, 2015

    So isn't there any overview, which violation types (currently we are only talking about Attack Signatures and RFC violations) can be disabled on a specific entity instead of disabling it globally for the whole policy? I mean for headers for example there is a option to disable "Evasion Techniques Violations". Or Attack Signatures can be disabled just for a specific parameter. Is something similar possible on URL-level as well?

     

    The problem I have is that the application code contains valid requests, which trigger specific violations. And although some of them are also not RFC compliant and I assume changing this directly in the application is not possible, I was wondering (to minimize security risk) if it's possible to exclude these specific violations just for affected requests (e.g. URL).

     

    Ciao Stefan :)