LTM ICAP via Internal VS and possible ASM integration

I'm trying to get this answered myself and posted a similar question (see below), but yet to be answered.

My Post: https://devcentral.f5.com/questions/icap-with-irule-response-page

We were told by an FSE that you needed to get to 11.6 to raise ASM violations, we upgraded and have the LTM ICAP virus scan working but cant get the ASM trigger violation invoked.

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

HTTP::header value ICAP_UID

ICAP::header value ICAP_UID

HTTP::header value ICAP_UID