Am 13.04.2010 um 12:05 schrieb guest01:
Hi guys,
I may have found a bug related to the ICAP capabilities of Squid 3.1.1
(on RHEL5.4). We are currently evaluating a squid deployment which is
referenced by this url [1].
We want to use Squid as Caching/Authentication-Proxy and ICAP Client,
which talks to the Webwasher-server (content filtering proxy) via
ICAP. Our Squid has following ICAP configuration:
#icap
icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_preview_enable on
icap_preview_size 30
icap_client_username_encode on
icap_client_username_header X-Authenticated-User
icap_service service_req reqmod_precache bypass=0
icap://yyy.yyy.yyy.21:1344/wwreqmod
adaptation_access service_req allow all
icap_service service_resp respmod_precache bypass=0
icap://yyy.yyy.yyy.21:1344/wwrespmod
adaptation_access service_resp allow all
(Unfortunately, we can only specify one ICAP server per Squid, but
that's another issue/limitation)
This deployment is supported by McAfee (Webwasher) and there is even
an example configuration[2] for squid and documents for configuring
the webwasher by McAfee.
ICAP reqmod looks good, everything as expected:
Host: yyy.yyy.yyy.21:1344
Date: Mon, 12 Apr 2010 10:54:27 GMT
Proxy-Authorization: NTLM <BASE64 STRING>
Encapsulated: req-hdr=0, null-body=184
Preview: 0
Allow: 204
X-Client-IP: bbb.bbb.bbb.71
X-Authenticated-User: <BASE64 encoded USERNAME>
GET / HTTP/1.1
Host: www.playboy.com
Accept: text/html, text/plain
ICAP/1.0 200 OK
Encapsulated: res-hdr=0, res-body=170
ISTAG: "001-000-000003"
X-Attribute: sx
X-ICAP-Profile: PoC_Policy_TEST
X-WWBlockResult: 10
X-WWRepScore: 11
HTTP/1.1 403 Forbidden
Content-Length: 1480
Content-Type: text/html; charset=ISO-8859-1
Pragma: no-cache
Proxy-Connection: close
X-Error-Name: requestdynablocked
In that case we were assigned to PoC_Policy_TEST and the request to
www.playboy.com was blocked. (It seems that we are not supposed to see
nice girls at work ;-))
If we want to serve to a page which is not blocked (e.g. google.com),
we get following request:
ICAP/1.0 200 OK
Encapsulated: res-hdr=0, res-body=166
ISTAG: "001-000-000003"
X-ICAP-Profile: default
X-WWBlockResult: 81
X-WWRepScore: 0
HTTP/1.1 403 Forbidden
Content-Length: 1279
Content-Type: text/html; charset=ISO-8859-1
Pragma: no-cache
Proxy-Connection: close
X-Error-Name: authorizedonly
And there is the problem. The ICAP respmod (3.1.1) request does NOT
contain the X-Client-IP: bbb.bbb.bbb.71 and X-Authenticated-User:
<BASE64 encoded USERNAME> values and that's why the webwasher cannot
assign the right policy!
If we are using squid 3.0, it works. So in my opinion, this sound like
a bug. Right? Has anyboy experiences with ICAP or ICAP issues with
Squid 3.1.1?
Anyway, besides that problem which I solved by using squid 3.0, there
are a couple of other limitation which I don't really want to
implement, but I don't see any other change, do you? ;-) At least it
does not sound very complicated to implement in c++ ...
- possibility to specify more than one ICAP server for a Squid
configuration (for example with round robin load balancing or any
other kind of loadbalancing)
- the much bigger issue is, that Squid as ICAP client does NOT send
any group information to the ICAP server, only X-Client-IP and
X-Authenticated-User values and no X-Authenticated-Groups attribute.
Unfortunately, a policy will be assigned by a group membership. That's
why the ICAP server needs that information and it is not a good idea
to let the ICAP server lookup this user again (huge performance
issue).
So, this is quite a long mail, I would appreciate any feedback.
best regards
Peter
[1] http://img714.imageshack.us/img714/7457/topology.png
[2] http://wiki.squid-cache.org/ConfigExamples/Webwasher (they are
using a proxy chain instead of a icap solution)
You?
http://bugs.squid-cache.org/show_bug.cgi?id=2903
Michael Portz wrote:
> Did you use the
>
> follow_x_forwarded_for
>
> option in your squid.conf? (Doc for example to be found here)
>
That is only needed if the client IP is being located inside the XFF header.
The icap_send_client_ip setting already turned on should have been
adding X-Client-IP with at least the directly connected requestor IP
regardless of XFF.
For some strange reason the client_addr seem to be empty in the HTTP
request details used to construct the ICAP request.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.1
