Forum Discussion

arpydays_190826's avatar
arpydays_190826
Icon for Nimbostratus rankNimbostratus
Jul 06, 2015

LTM ICAP via Internal VS and possible ASM integration

Hi,

 

I've been told by F5 FSE that if we do ICAP via LTM and internal VS instead of ASM for AV Scanning of uploads (to get round buffer size limitation) we can use new rule events in v11.5 to raise ASM violations and even blocking response behaviours.

 

I'm trying to understand how this would work as I believe these are new ASM events for raising custom violations etc, therefore requiring ASM to handle the traffic...

 

has anyone had any experience with how you would integration LTM based ICAP with ASM violations?

 

10 Replies

  • The gist is as follows:

    yes, you will need to create a custom ASM violation in ASM and the traffic will still need to pass to ASM. It will, however, be sent to the ICAP server before hitting ASM - and if we get an ICAP response that indicates that the payload is unsafe/infected/malicious, the goal is to to override that response and set a specific flag in the iRule to indicate to the ASM_REQUEST_DONE event that it should raise that violation about ICAP-based compliance. I am currently playing with different scenarios and will post more details, but assuming you have ICAP integration on the LTM working, try this iRule:

    when ADAPT_REQUEST_RESULT {
       log local0. "ICAP response is [ADAPT::result]"
       if { ! ([ADAPT::result] contains "bypass") } {
         set icap_blocked 1
         ADAPT::result bypass
       } else {
          set icap_blocked 0
       }
    }
    when ASM_REQUEST_DONE {
       if { [info exists icap_blocked] && $icap_blocked == 1 } {
       ASM::raise ICAP
       log local0. "Raising custom ASM Violation."
       set icap_blocked 0
       }
    }
    

    In order for this to work, you need to:

    • Have LTM-based ICAP integration working
    • Have ASM policy assigned to the VS and also have iRules Triggering enabled on that policy(this is needed for ASM_REQUEST_DONE event to fire).
    • Create a custom Violation(in my case, the name of the violation is ICAP - either use the same name or adjust the name in the iRule)
    • Adjust the Blocking mask in the Security Policy to alarm/block on the new custom violation.
  • Hi Michael,

     

    In my testing the ADAPT::result value is either "respond" indicating that a block page response has been returned from the ICAP server or "modify" meaning that there may no violation and the ICAP server is simply returning the full request to the ICAP client - this may need consideration in the logic. I've not come across any use-cases for "bypass" with our implementation, I think this may only apply "204 No modification needed" but this is not offered as a supported option by the F5 ICAP client and I have preview turned off (due to some other issues noted while testing)

     

    cheers

     

  • I've also done some basic testing and was able trigger a blocking page based on the ADAPT::result value as described by Michael above, nice one Michael.

    I also wanted to log info why the ICAP request was blocked in ASM. To do this I've added an irule to the Internal VS to capture the ICAP header that indicates the block reason. To be able to pass this variable from the internal VS irule to the HTTP VS irule I needed to create a session table variable. Other thing I needed to do was a way to make this variable unique for each request and accessible by both irules. To do this I inserted a HTTP header at the start with a unique ID and on the ICAP server mapped this through to an ICAP Response header therefore making it available to the Int VS irule for setting the table name. Then when raising the violation I was able to add in the extra info.

    The irules I used are below;

     HTTP VS
    
    when HTTP_REQUEST {
      if {[HTTP::method] ne "POST"} {
        ADAPT::enable request false
      } else {
        set uid [expr {int(rand()*1e9)}]
        HTTP::header insert ICAP_UID $uid
        log local0. "$uid Sending to ICAP server"
      }
    }
    
    when ADAPT_REQUEST_RESULT {
      log local0. "$uid ICAP Response is [ADAPT::result]"
      if { ([ADAPT::result] contains "respond") } {
        set icap_blocked 1
        ADAPT::result bypass
      } else {
        set icap_blocked 0
      }
    }
    
    when ASM_REQUEST_DONE {
      if { [info exists icap_blocked] && $icap_blocked == 1 } {
        set x []
        set y []
        lappend y "description" "[ table lookup $uid ]"
        lappend x $y
        log local0. "$uid Raise AV_BLOCK $x [ASM::raise AV_BLOCK  $x]"
        set icap_blocked 0
        table delete $uid
        HTTP::header remove ICAP_UID
      }
    }
    
     Internal ICAP VS
    
    when ICAP_RESPONSE {
      if { [ICAP::header exists X-Virus-Name] } {
        table set [ICAP::header value ICAP_UID] [ICAP::header value X-Virus-Name]
        log local0. "Table name is [ICAP::header value ICAP_UID] value is [table lookup [ICAP::header value ICAP_UID]]"
      }
    }
    

    This allowed for the block reason details to be displayed;

  • Hi,

    I've been testing the above setup and functionally it seems to be working as expected. I do notice this in the logs though just after the ASM_REQUEST_DONE event and log entry. Any ideas what this refers to and if it is something to be concerned about?

    warning tmm[10839]: 01480001:4: No held transaction to sink.

    cheers

  • I suggest opening a support case to investigate that message and share the answer back on this thread

     

  • ICAP::header value ICAP_UID

    replaced by

    HTTP::header value ICAP_UID

    in v12.0.0. The HTTP headers are available inside the ICAP envelope and UID in HTTP header and not in ICAP.

    Modify the ADAPT::response to bypass causes OOPS on v12.0.0 - ticket in progress
    • EM's avatar
      EM
      Icon for Nimbostratus rankNimbostratus

      Any news on the ticket?

      I am running also into troubles with 12.1.2 using these iRules... After the ADAPT_REQUEST_RESULT event the BIGIP sends a TCP RST:

      rst_cause="[0x22280f3:1808] ADAPT unexpected state transition (old_state 10 event 9)”

  • ICAP::header value ICAP_UID

    replaced by

    HTTP::header value ICAP_UID

    in v12.0.0. The HTTP headers are available inside the ICAP envelope and UID in HTTP header and not in ICAP.

    Modify the ADAPT::response to bypass causes OOPS on v12.0.0 - ticket in progress
    • EM's avatar
      EM
      Icon for Nimbostratus rankNimbostratus

      Any news on the ticket?

      I am running also into troubles with 12.1.2 using these iRules... After the ADAPT_REQUEST_RESULT event the BIGIP sends a TCP RST:

      rst_cause="[0x22280f3:1808] ADAPT unexpected state transition (old_state 10 event 9)”