[squid-users] Squid and url modifying
Alex Rousskov
rousskov at measurement-factory.com
Tue Mar 5 16:45:43 UTC 2019
On 3/5/19 1:57 AM, Egoitz Aurrekoetxea wrote:
> I have Squid configured with the virus scanning software using ICAP and
> working. But, when I do :
>
> acl matchear_todo url_regex [-i] ^.*$
FYI: "[-i]" is documentation syntax that means an optional flag called
"-i". If you want to use that "-i" flag, then type
acl matchear_todo url_regex -i ^.*$
... but keep in mind that "-i" makes no sense when you regular
expression does not contain small or capital characters. Adding "-i"
would not change what URLs such a regular expression would match.
> http_reply_access deny matchear_todo
> deny_info http://172.16.8.61/redirigir.php?url=%s matchear_todo
Why are you blocking based on URL instead of blocking based on the ICAP
scan result? In your earlier specifications, you wanted to
block/redirect only those transactions that were certified virus-free by
your ICAP client. The above matchear_todo ACL does not do that.
> it's always redirecting me without passing the own ICAP system...
Looking at the Squid code, what you describe overall seems impossible --
Squid checks http_reply_access _after_ the RESPMOD transaction, not
before it. Adding http_reply_access cannot disable ICAP scans AFAICT!
Are you sure it has that effect in your use case?
> I
> wanted the redirection to be done only when content is clean... this is
> doing it always... have I missed something?
Your ACL says nothing about "clean". It says "always". How does your
ICAP service mark "clean" (or "dirty") HTTP responses? Your ACL needs to
match that marking (or the absence of that marking).
Alex.
> El 2019-03-05 08:13, Alex Rousskov escribió:
>
>> On 3/4/19 11:20 AM, Egoitz Aurrekoetxea wrote:
>>
>>> Clients, will ask :
>>>
>>> https://oooeeee.eeee.ttt.thesquidserver.org/
>>
>>> So the answer [to the second question] I assume should be yes.
>>
>> If I am interpreting your answers correctly, then your setup looks like
>> a reverse proxy to me. In that case, you do not need SslBump and
>> interception. You do need an web server certificate for the
>> oooeeee.eeee.ttt.thesquidserver.org domain, issued by a well-trusted CA.
>> Do you already have that?
>>
>>
>>> I have DNAT rules, for being able to
>>> redirect tcp/80 and tcp/443 to squid's port silently.
>>
>> Please note that your current Squid configuration is not a reverse proxy
>> configuration. It is an interception configuration. It also lacks
>> https_port for handling port 443 traffic. There are probably some
>> documents on Squid wiki (and/or elsewhere) explaining how to configure
>> Squid to become a reverse proxy. Follow them.
>>
>>
>>> I wanted to setup a proxy machine which I wanted to be able to receive
>>> url like :
>>>
>>> - www.iou.net.theproxy.com/hj.php?ui=9
>>> <http://www.iou.net.theproxy.com/hj.php?ui=9>
>>>
>>> If this site returns clean content (scanned by Icap server) the url
>>> redirector should return :
>>>
>>> - www.iou.net/hj.php?ui=9 <http://www.iou.net/hj.php?ui=9>
>>> <http://www.iou.net/hj.php?ui=9> (the real
>>> url) as URL.
>>
>> OK.
>>
>>
>>> - Is it possible with Squid to achieve my goal?. With Squid, a
>>> redirector, and a Icap daemon which performs virus scanning...
>>
>> A redirector seems out of scope here -- it works on requests while you
>> want to rewrite (scanned by ICAP) responses.
>>
>> It is probably possible to use deny_info to respond with a redirect
>> message. To trigger a deny_info action, you would have to configure your
>> Squid to block virus-free responses, which is rather strange!
>>
>>
>>> - For plain http the config and the URL seem to be working BUT the virus
>>> are not being scanned. Could the config be adjusted for that?.
>>
>>
>> I would start by removing the redirector, "intercept", SslBump, and
>> disabling ICAP. Configure your Squid as a reverse proxy without any
>> virus scanning. Then add ICAP. Get the virus scanning working without
>> any URL manipulation. Once that is done, you can adjust Squid to block
>> virus-free responses (via http_reply_access) and trigger a deny_info
>> response containing an HTTP redirect.
>>
>>
>> Please note that once the browser gets a redirect to another site, that
>> browser is not going to revisit your reverse proxy for any content
>> related to that other site -- all requests for that other site will go
>> from the browser to that other site. Your proxy will not be in the loop
>> anymore. If that is not what you want, then you cannot use redirects at
>> all -- you would have to accelerate that other site for all requests
>> instead and make sure that other site does not contain absolute URLs
>> pointing the browser away from your reverse proxy.
>>
>>
>> Disclaimer: I have not tested the above ideas and, again, I may be
>> misinterpreting what you really want to achieve.
>>
>> Alex.
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> <mailto:squid-users at lists.squid-cache.org>
>> http://lists.squid-cache.org/listinfo/squid-users
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
More information about the squid-users
mailing list