[squid-users] More host header forgery pain with peek/splice

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXxd3bAAoJENNXIZxhPexGUbgH/j4qcbQW7u/zktJpJLlqhed3
+J7Qsr6eXyeC3ryG8q8w5CGAdP/ESoeJO/aA02uW/DEf517oH5kHxMtKdtyl9VNw
suqNAcFsk6F8fYG+9h2+0Zip2IN3IC8u2ArtZcVcd5QO/rruEEFLK6HX3K9cvOBn
guRq9LNa5DvX83cYhxdQIdDJ8eeGGOxcwteyajkeMfwskfx4dLeoDO2B4F56VKLA
ugVA7NBskVe2TiuhgfpZ4fOWslWaiZATma1beM4sa0KOvRUqxKuf0BJlnX+Llyzp
YsD1cPRXs4YftF6t4d/iV4BT+oUYKq4UugHNHgy3PqgKu9VFWoeX/dBmHRMYHQY=
=Siw+
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160831/0b1241a8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160831/0b1241a8/attachment.key>