<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br>
<br>
<br>
31.08.2016 1:24, Yuri Voinov пишет:<br>
<span style="white-space: pre;">><br>
><br>
><br>
> 30.08.2016 23:25, Marcus Kool пишет:<br>
> > Do I understand it correctly that Squid in normal proxy
mode<br>
> > allows malware to do a CONNECT to any destination, while
in<br>
> > transparent proxy mode does extra security checks which
causes<br>
> > some regular (non-malware) clients to fail?<br>
>
<a class="moz-txt-link-freetext" href="http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP">http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP</a><br>
><br>
> > And philosophical questions: is Squid the right tool<br>
> > to stop malware? If yes, is it acceptable that
connections<br>
> > of regular (non-malware) clients are wrongly dropped?<br>
>
<a class="moz-txt-link-freetext" href="http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP">http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP</a></span><br>
Not stop all. But reduce.<br>
<span style="white-space: pre;">><br>
><br>
> > IMO Squid should do all it can to be a secure proxy.<br>
> > Doing security checks on connections in an attempt<br>
> > to stop malware sounds like a job for an antivirus / IDS
tool.<br>
>
<a class="moz-txt-link-freetext" href="http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP">http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP</a><br>
> <a class="moz-txt-link-freetext" href="http://wiki.squid-cache.org/Features/SslPeekAndSplice">http://wiki.squid-cache.org/Features/SslPeekAndSplice</a><br>
><br>
><br>
><br>
> > Marcus<br>
><br>
><br>
> > On 08/30/2016 01:01 PM, Amos Jeffries wrote:<br>
> >> On 26/08/2016 6:34 a.m., reinerotto wrote:<br>
> >>> Hack the code. Because it is even worse, as
firefox for example does<br>
> not obey<br>
> >>> to the TTL.<br>
> >>><br>
> >><br>
> >> It is not that simple. The checks are there for very
good reason(s)<br>
> >> related to security of the network using the proxy.<br>
> >><br>
> >> The Host forgery issue being checked for allows
network firewall rule<br>
> >> bypass, browser same-origin bypass, and browser
sandbox bypass - in a<br>
> >> way which places the attacker in control of what
logs you see [aha!<br>
> >> invisible access to the network]. With all the
related nasty<br>
> >> side-effects those allow. There is both malware and
services for sale<br>
> >> around the 'net that take advantage of the attack to
do those bypasses.<br>
> >> => Simply disabling the check code is a *very*
risky thing to do.<br>
> >><br>
> >><br>
> >> The cases where Squid still gets it wrong are where
the popular CDN<br>
> >> service(s) in question are performing DNS actions
indistinguishable to<br>
> >> those malware attacks. If Squid can't tell the
difference between an<br>
> >> attack and normal DNS behaviour the only code change
possible is to<br>
> >> disable the check (see above about the risk level).<br>
> >><br>
> >><br>
> >> FYI: I have a plan to reduce the false-positive rate
from DNS rotation<br>
> >> effects. But that requires some deep redesign of the
DNS code, which I'm<br>
> >> intending to do as part of the Squid-5 roadmap to
avoid further<br>
> >> destabilizing 4.x while its in beta.<br>
> >><br>
> >> For now the workarounds are:<br>
> >><br>
> >> * obey the requirement that destination NAT (if any)
is performed only<br>
> >> on the Squid machine.<br>
> >><br>
> >> * to tune the lifetime for persistent client
connections. That reduces<br>
> >> (but not fully) connections outliving DNS rotation
times and thus<br>
> >> causing requests to have different ORIGINAL_DST from
what DNS says.<br>
> >><br>
> >> * if wanting Google 8.8.8.8 service as your
resolver. Use a local DNS<br>
> >> recursive resolver shared by Squid and client which
points to that<br>
> >> service as its parent/forwarded resolver. That
removes the issue with<br>
> >> every 8.8.8.8 response having different reply IP
values (so client and<br>
> >> Squid doing near simultaneous lookups get different
IPs).<br>
> >><br>
> >> Amos<br>
> >><br>
> >> _______________________________________________<br>
> >> squid-users mailing list<br>
> >> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> >> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
> >><br>
> > _______________________________________________<br>
> > squid-users mailing list<br>
> > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
><br>
></span><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBCAAGBQJXxd3bAAoJENNXIZxhPexGUbgH/j4qcbQW7u/zktJpJLlqhed3
<br>
+J7Qsr6eXyeC3ryG8q8w5CGAdP/ESoeJO/aA02uW/DEf517oH5kHxMtKdtyl9VNw
<br>
suqNAcFsk6F8fYG+9h2+0Zip2IN3IC8u2ArtZcVcd5QO/rruEEFLK6HX3K9cvOBn
<br>
guRq9LNa5DvX83cYhxdQIdDJ8eeGGOxcwteyajkeMfwskfx4dLeoDO2B4F56VKLA
<br>
ugVA7NBskVe2TiuhgfpZ4fOWslWaiZATma1beM4sa0KOvRUqxKuf0BJlnX+Llyzp
<br>
YsD1cPRXs4YftF6t4d/iV4BT+oUYKq4UugHNHgy3PqgKu9VFWoeX/dBmHRMYHQY=
<br>
=Siw+
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>