Forum Discussion

cmard_195831's avatar
cmard_195831
Icon for Nimbostratus rankNimbostratus
Dec 28, 2017
Solved

irule task conformation

Hello,

 

I have the following i-rule and I would like your advise if it is valid or not before trying this out: Q1) The if part is clear, i.e. if the URI contains the string "landing-page", it will not apply the ASM rules. Please confirm. Q2) The fact that it will disable the ASM, does that mean that the ASm will remain disabled for the rest of the URIs that do not contain the said string ? Q3) What is the need for the "else" statement, if the disabling is done only for the pages whose URI string contains the "landing-page" label ?

 

F5 firmware version 12.1.2

 

when HTTP_REQUEST { if { [HTTP::uri] contains "landing-page" } { ASM::disable log local0. "ASM disabled." } else { ASM::enable /Common/myasmpol log local0. "ASM enabled. Current ASM policy is [ASM::policy]" } }

 

All comments are welcomed

 

  • The iRules wiki documentation clearly states that when you call ASM::disable or ASM::enable, you enable or disable ASM for the ENTIRE connection, not just the request, UNTIL the opposite command is called. In that sense, your logic is valid and that is why you need the "else." That takes care of all 3 questions. Additionally, I'd check to see if ASM is already enabled when a request comes in that doesn't contain landing-page and issue a return command if it is.

    Like this:

    when HTTP_REQUEST {
     if { [HTTP::uri] contains "landing-page" }
     {
       ASM::disable
       log local0. "ASM disabled."
     }
     else {
          if { [POLICY::controls asm] == 1 }
          { return }
          else {
               ASM::enable /Common/myasmpol
               log local0. "ASM enabled. Current ASM policy is [ASM::policy]"
          }
     }
    }
    

    As for whether it will work the way you expect it to, I can't say. I would suggest spinning up an internal test VIP with the same policy and pool and using a host file entry to test the behavior.

4 Replies

  • The iRules wiki documentation clearly states that when you call ASM::disable or ASM::enable, you enable or disable ASM for the ENTIRE connection, not just the request, UNTIL the opposite command is called. In that sense, your logic is valid and that is why you need the "else." That takes care of all 3 questions. Additionally, I'd check to see if ASM is already enabled when a request comes in that doesn't contain landing-page and issue a return command if it is.

    Like this:

    when HTTP_REQUEST {
     if { [HTTP::uri] contains "landing-page" }
     {
       ASM::disable
       log local0. "ASM disabled."
     }
     else {
          if { [POLICY::controls asm] == 1 }
          { return }
          else {
               ASM::enable /Common/myasmpol
               log local0. "ASM enabled. Current ASM policy is [ASM::policy]"
          }
     }
    }
    

    As for whether it will work the way you expect it to, I can't say. I would suggest spinning up an internal test VIP with the same policy and pool and using a host file entry to test the behavior.

  • The iRules wiki documentation clearly states that when you call ASM::disable or ASM::enable, you enable or disable ASM for the ENTIRE connection, not just the request, UNTIL the opposite command is called. In that sense, your logic is valid and that is why you need the "else." That takes care of all 3 questions. Additionally, I'd check to see if ASM is already enabled when a request comes in that doesn't contain landing-page and issue a return command if it is.

    Like this:

    when HTTP_REQUEST {
     if { [HTTP::uri] contains "landing-page" }
     {
       ASM::disable
       log local0. "ASM disabled."
     }
     else {
          if { [POLICY::controls asm] == 1 }
          { return }
          else {
               ASM::enable /Common/myasmpol
               log local0. "ASM enabled. Current ASM policy is [ASM::policy]"
          }
     }
    }
    

    As for whether it will work the way you expect it to, I can't say. I would suggest spinning up an internal test VIP with the same policy and pool and using a host file entry to test the behavior.