Forum Discussion

Arthur_7109's avatar
Icon for Nimbostratus rankNimbostratus
Jan 04, 2011

The Blocking Reponse Page is blocked and looping :-)

Hi there,


On our ASM, for the Blocking Reponse Page, we use a redirect to a page on the application server:



So the browser is requesting




or so (which also goes through the ASM).


That works OK, most of the time.


What we have noticed is that occasionally, the request for that blocking page is blocked itself, causing a loop.


On one occasion, it appears that the cause was a mobile device that caused an HTTP Protocol Compliance violation.


That resulted in blocking and a request for the Blocking Response Page, which again caused that same HTTP Protocol Compliance violation, which resulted in blocking, which ...


Today I reproduced the issue by making Firefox use a "User-Agent: wget test" header. This triggers the Attack Signature "Automated client access wget", which again triggers the blocking page request loop.


Has anyone found an easy / straightforward / effective way to address this?


We will eventually run version 10.2.1, so I was thinking of an irule like




if the requested URI is the Blocking Response Page


then HTTP::respond with a simple error message instead of the Javascript redirect




This should work I think, but I'm wondering if anyone else has faced this issue, and found an elegant solution.


Thanks and kind regards,






4 Replies

  • You could also use ASM::disable.

    Since disabling ASM disables it for the entire tcp connection, re-enabling it within the rule would seem necessary.

    Slightly editing the example iRule in that article:

     Disable ASM for URIs containing "blocking-page"
      if { [HTTP::uri] contains "blocking-page" } { 

    Give that a shot perhaps?
  • Another option is to use an iRule to sanitize requests to the blocking page when the blocking page is hosted behind an ASM policy. Here's a version I did for 9.x. You could update it for 10.x relatively easily by changing the global variables to the static namespace, change the headers_to_preserve list to a datagroup and change the setting of $asm_bypass to ASM::enable/ASM::disable.



    Here are some related links:









    But actually, I think your method of using HTTP::respond on violations to the blocking URI makes very good sense. The nice part is that you don't deal with sanitizing the requests or bypassing ASM. The only downside I can think of is that you're having to host application content within LTM.



  • Having an iRule for this is a CPU and maintenance overhead. You can do this WITHOUT iRules:



    Create a new HTTP-Class with Match URI: "/path-to/blocking-page*" and set the Action to go directly to your pool (or even better, set up a new "blocking_page_pool"). Then configure that HTTP Class to be processed prior to the ASM-enabled one on your Virtual Server (using Up/Down buttons on Virtual Server Resource screen). This way any request to your blocking page will bypass ASM as the HTTP class match will take that request directly to the pool.



    ...or (if you can) just host the blocking page elsewhere (i.e. on a different Virtual Server/Website which only hosts plain HTML and images)









  • Hey Sam,



    The downside to using an HTTP class with filters to selectively disable ASM is that TMM doesn't do any URL normalization. So if an attacker knew you were bypassing ASM for /path/to/*, they could use a URI like /path/to/ to get to /attack.exe without going through ASM.



    That's why I really like Arthur's idea of sending an HTTP response from an iRule in the ASM_REQUEST_VIOLATION event when the URI is the blocking page. It's lighter weight than the sanitization iRule for 9.x ASM and still provides good security.