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

Yuri Voinov yvoinov at gmail.com
Tue Aug 30 19:24:38 UTC 2016


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


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

>
> 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
 
iQEcBAEBCAAGBQJXxd12AAoJENNXIZxhPexGatAIAMvXwPnEHw5PR+fg+8KdxCQ3
h0fYEFKZHOI2P0b+kk7DRd/RG1mBdM23Hlr6EflqXGSigkuYF8fLGfx4iyo6BaXt
gOO4Z/CEoUCtjF8PPG8WWNaRz5kz4eZcMJM10gGJ0wke8ojDUJ11Z0TXorj7n9Ou
JRG2XuyP4RF2fHxOPsCvQRD1I7yiynMVXa8vsc6PHvlOru56rs/VTd86NX2jBFJf
TpM6UWrJzmZbUAIlrzhgllEPpgfUPzTdJX8eIFKQeVnOyq0i6o5pjc8wdg4CZUkw
naaYNTp/xsx/zfhW75xjKV4UuxCGiZy9zroiKpyu/EjnSUvtnQHVFrWyhvxCJrM=
=mPgV
-----END PGP SIGNATURE-----

-------------- 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/ee89839a/attachment.key>


More information about the squid-users mailing list