cancel
Showing results for 
Search instead for 
Did you mean: 

Coaching on Content Filtering via ICAP?

I've marked this as a question, but I've been informed that what's needed comes down to a feature request.  But, of which product?

I got to tinkering after trying to make sense of this discussion:

And:

First, I needed to prove a few things to myself.  I grabbed a packet trace of a block from an nDLP ICAP server from the proxy (one for which I was triggering the block [very useful: HTTP Post | DLP Test]).  I could see the "HTTP/1.1 403 Forbidden\r\n", along with the block page coming from the ICAP server—which is the content that was displayed in my browser (by way of MWG).

I then altered the rule to block on the ICAP.ReqMod.Satisfaction, and that did result in a proxy block page—instead of the ReqMod response.

With a bit more tinkering, I cobbled together a combination of the coaching rule sets and the DLP via ICAP rulesets.  And, I was able to get a coaching page to display.  However when I tried to click through, I got the block page from the ICAP server.

With a bit more tinkering, I was able to get coaching to work—but I do not like what it took to make it work.  Guess why?  Because the DLP ICAP server doesn't get to log the the results of the content server—because the DLP ICAP server never gets to look at that content.

Oh, I suppose I could rig logging for this, but that would result in a split solution for those who review the DLP incidents, and I know that's never going to fly.

What would be better is if either, the ICAP product had coaching or there was a variation of ICAP.ReqMod.Satisfaction that ignored the ICAP server's modified response.  I don't think the latter is a great option, but it's better than what I've created so far.  The best would be an ICAP server with a coaching option, which would allow it to log when it prompts for coaching and when it doesn't (if anyone thinks that makes any difference, and some might).  I suppose one might wonder what it would look like if the ICAP protocol had features to facilitate coaching (AFAIK).

Am I missing anything here?  Any other thoughts on the subject?


Rule Sets
Data Loss Prevention, Coaching

[Encourages users to follow web usage guidelines by limiting session times]

[✘] Disabled [✘] Disabled in Cloud
Applies to: [✔] Requests [✘] Responses [✔] Embedded Objects
1: SSL.ClientContext.IsApplied equals true
2: OR Command.Name does not equal "CONNECT"
EnabledRuleActionEventsComments
[✔] EnabledSkip Empty Host Names
1: URL.Host equals ""
Stop Rule Set
[✔] EnabledSkip GET and HEAD requests
1: Command.Name equals "GET"
2: OR Command.Name equals "HEAD"
Stop Rule Set
[✔] EnabledSkip Requests That Do Not Carry Information
1: Body.Size equals 0
2: AND List.OfString.IsEmpty(URL.Parameters) equals true
Stop Rule SetOnly requests that contain some data will be sent to the ICAP server
[✔] EnabledSkip Body That Is Greater Than 50 MB
1: Body.Size greater than 52428800
Stop Rule SetOnly requests that contain some data will be sent to the ICAP server
[✔] EnabledSkip Requests to Internal IP Addresses
1: URL.Destination.IP is in range list RFC 1918 Internal IPs
Stop Rule Set
Coaching With URL Configuration
[✔] Enabled [✘] Disabled in Cloud
Applies to: [✔] Requests [✔] Responses [✔] Embedded Objects
1: Quota.Coaching.IsActivationRequest.Strict<Data Loss Prevention> equals true
2: OR Quota.Coaching.SessionExceeded<Data Loss Prevention> equals false
3: OR ICAP.ReqMod.Satisfaction<Lab DLP Servers> equals true
EnabledRuleActionEventsComments
[✔] EnabledRedirecting After Starting New Coaching Session
1: Quota.Coaching.IsActivationRequest.Strict<Data Loss Prevention> equals true
Redirect<Redirection After Coaching Session Activation, nDLP>This rule redirects the user back to the requested URL after the user started a new session by pushing the button in the HTML Session template.
[✔] EnabledCheck If Coaching Session Has Been Exceeded
1: Quota.Coaching.SessionExceeded<Data Loss Prevention> equals true
Block<Action Coaching Blocked, nDLP>This rule shows a block html site for Coaching after the session for Coaching has been exceeded and one of the URLs is in the URL blocklist.

Message was edited by: John Aldridge (added description of coaching rules)

3 Replies
Highlighted
McAfee Employee jebeling
McAfee Employee
Report Inappropriate Content
Message 2 of 4

Re: Coaching on Content Filtering via ICAP?

Hey John,

The problem with trying to do this all on MWG is that I don't think there is any way to save the body during a transaction, and even if you could, I think there might be issues with memory usage and performance. I believe you are right that coaching really needs to be implemented in the DLP device, or at least in cooperation with it, rather than the gateway.

You might be able to  make this work if the DLP device supports different profiles via parameters. Send something like profile=modify on first request (you can leave in the criteria as long as its last because session exceeded will be false on second pass and ICAP.ReqMod.Satisfaction will not be evaluated), profile=monitor, ICAP.ReqMod.Satisfaction equals false  with continue action as last rule in coaching ruleset.

You would need to always set an event (ICAP.addRequestInformation, uriparam) before the coaching ruleset to add the parameter used by DLP to determine policy (monitor or modify) and then always set the same event to monitor in the coaching ruleset before you call/check ICAP.ReqMod.Satisfaction

Re: Coaching on Content Filtering via ICAP?

Thank you for your insight.

I had to re-read my post, because what I'm learning about ICAP doesn't seem to be sinking in.  But, configure and diagnose ICAP so rarely, my only hope is to keep writing long posts about it until it does.

What I've recently learned is this: when you block by way of ICAP, you do a stop cycle—to allow the ICAP server to fully determine how the return result will be handled (strongly implying that ICAP handling be towards the end of your rules—except for any that should be skipped on an ICAP incident).  The thing I have trouble hammering into my head is that the logic in MWG about what to do for a particular ICAP response is so opaque.  If the ICAP server says allow it, then the MWG allows the site and rules continue on normally; but if the ICAP server says modification is necessary, then MWG allows the ICAP server to provide the response to the user—even though it does so through MWG.

On some recent work, I ended up opening a support ticket ask some questions.  What I found out—if I understand correctly—was that the return value of ICAP.ReqMod.Satisfaction will be true under two conditions: 1) the ICAP server wants to block, 2) the option to respect the maximum connection limit is set and the connection limit is exceeded (meaning no ICAP reqmod was sent).  The lack of flexibility this presents seems awkward, but I guess the philosophy of using ICAP services is to pass the workload elsewhere; and once you're doing that, then you apparently just want to surrender any further control over the process.

Again, thanks for the response.

McAfee Employee jebeling
McAfee Employee
Report Inappropriate Content
Message 4 of 4

Re: Coaching on Content Filtering via ICAP?

You are welcome.

Looks like you have it right.

Basically ICAP.reqmod.satisfiaction equals true means that the request was successfully sent (original request encapsulated by ICAP header) AND a response was received from the server. Evaluating the property sends the request.Returned information is found in the ICAP.ReqMod.Response* properties.

I believe the MWG always sends Allow 204 with the request which means that if the ICAP server wants to, it can send back a message with status code 204 at any time indicating that no modification is required and no content is returned. At that point the web gateway allows the request to go on to the destination server unaltered.

The other terminal response that ICAP can send  from the server is an ICAP 200 status code which indicates that (in the case of reqmod with Allow 204) the original request was blocked or needed to be modified in some way. Content returned by the server following the ICAP header should be sent on to the destination server if still in the form of a properly formatted HTTP request. I have not tested MWG as an ICAP client, but I suspect if the ICAP server sends back a properly formatted HTTP response, that is what is sent on to the client, thus bypassing the server,

My suggestion is if a coaching session has not been established send the request as a modify (what currently happens in your ruleset), if a session has been established, send it as a monitor (same service, different param/profile). It would then be up to the DLP server to properly interpret those two types of requests and act accordingly.

REQMOD examples wireshark traces on ICAP client:

Example allowed URL (Original request should be sent on to server):

REQMOD icap://192.168.11.122:1344/wwreqmod?profile=default ICAP/1.0

Connection: close

Host: 192.168.11.122

Encapsulated: req-hdr=0 null-body=43

User-Agent: JavaICAPClient

X-Client-IP: 192.168.11.77

Allow: 204

GET / HTTP/1.1

Host: www.mcafee.com:80

ICAP/1.0 204 No modification needed

ISTag: "00000930-14.38.32-00008745"

X-Categories: Business, Software/Hardware

X-Media-Type: application/x-empty

Example redirected URL (Response should be sent back to client):

REQMOD icap://192.168.11.122:1344/wwreqmod?profile=default ICAP/1.0

Connection: close

Host: 192.168.11.122

Encapsulated: req-hdr=0 null-body=49

User-Agent: JavaICAPClient

X-Client-IP: 192.168.11.77

Allow: 204

GET / HTTP/1.1

Host: www.goldenpalace.net:80

ICAP/1.0 200 OK

ISTag: "00000930-14.38.32-00008745"

Encapsulated: res-hdr=0, res-body=132

X-Categories: Gambling

X-Media-Type: application/x-empty

HTTP/1.1 302 redirected

Location: http://www.mcafee.com

Content-Type: text/html

Cache-Control: no-cache

Content-Length: 7005

1B5D

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!--

  Message.TemplateName: redirected

  Message.Language: en

-->

<html>

<!-- head -->

<head>

... rest of HTML page to be returned to client

0

Example modified URL (Modified request should be sent on to server):

REQMOD icap://192.168.11.122:1344/wwreqmod?profile=default ICAP/1.0

Connection: close

Host: 192.168.11.122

Encapsulated: req-hdr=0 null-body=45

User-Agent: JavaICAPClient

X-Client-IP: 192.168.11.77

Allow: 204

GET / HTTP/1.1

Host: www.symantec.com:80

ICAP/1.0 200 OK

ISTag: "00000930-14.38.32-00008745"

Encapsulated: req-hdr=0, null-body=55

X-Categories: Business, Software/Hardware

X-Media-Type: application/x-empty

GET /pathmodified/ HTTP/1.1

Host: www.symantec.com

Example blocked URL (Response should be sent to client):

REQMOD icap://192.168.11.122:1344/wwreqmod?profile=default ICAP/1.0

Connection: close

Host: 192.168.11.122

Encapsulated: req-hdr=0 null-body=45

User-Agent: JavaICAPClient

X-Client-IP: 192.168.11.77

Allow: 204

GET / HTTP/1.1

Host: www.gambling.com:80

ICAP/1.0 200 OK

ISTag: "00000930-14.38.32-00008745"

Encapsulated: res-hdr=0, res-body=99

X-Categories: Gambling

X-Media-Type: application/x-empty

X-Block-Reason: Blocked by URL filtering

X-WWBlockResult: 10

HTTP/1.1 403 URLBlocked

Content-Type: text/html

Cache-Control: no-cache

Content-Length: 9599

257F

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!--

  Message.TemplateName: URLBlocked

  Message.Language: en

-->

<html>

<!-- head -->

<head>

  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>

  <title>McAfee Web Gateway - Notification - Blocked by URL filtering</title>

  <script src="/mwg-internal/de5fs23hu73ds/files/javascript/sw.js" type="text/javascript" ></script>

  <link rel="stylesheet" type="text/css" href="/mwg-internal/de5fs23hu73ds/files/default/stylesheet.css" />

</head>

<!-- /head -->

... rest of HTML page to be returned to client

0

Hope this helps.

Member Rewards
McAfee Community rewards active and helpful members just like you. Click here to take a look at the first community members who received a special reward and were recognized by McAfee leader, Aneel Jaeel, for their participation and trusted knowledge in the community.