Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters
Answers

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?

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
Comments on this Answer
Comment made 15-Jul-2015 by Michael Koyfman 2088
That's perfectly fine - I was just testing against my DLP server using ICAP - and that's what I was getting there - so each scenario is unique. So, if in your scenario the only valid answer is modify, then replace bypass with modify in the iRule example and see how it works for you. Separate note - curious to hear what issues you have uncovered with preview turned on.
0
Comment made 15-Jul-2015 by arpydays 1247
So using a reqmod use case and preview on and checking the trace I noticed that after the client sent the preview and the ICAP server returned a response instead of a "100 continue" that the F5 would continue to send the request to the ICAP server resulting in a ICAP 500 Server error. I haven't investigated any further yet but it is a repeatable scenario. It appears as if the client is behaving as if the sever returned a "100 continue" and not a response. 11.6HF4
0
Comment made 16-Jul-2015 by Michael Koyfman 2088
Do you have an example of a response that your ICAP server returns that BIG-IP seems to ignore?
0
Comment made 18-Jul-2015 by arpydays 1247
It's an ICAP 200 with a 403 Forbidden Response. I'll see if I can grab a wireshark screenshot if that's helpful
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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;

Image Text

0
Comments on this Answer
Comment made 16-Jul-2015 by Michael Koyfman 2088
Excellent! Please keep the thread updated on how well this approach works for you and if you find any other gotchas!
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
Comments on this Answer
Comment made 21-Mar-2017 by EM 113

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)”

0