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

Yuri Voinov yvoinov at gmail.com
Tue Aug 30 19:27:59 UTC 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
And this one:

http://wiki.squid-cache.org/ConfigExamples/Intercept/CiscoIOSv15Wccp2

of course.


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?
>
> 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?
>
> 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.
>
> 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
 
iQEcBAEBCAAGBQJXxd4/AAoJENNXIZxhPexGwjwH+QHrd7xRMHLr1kTxd7cMoVtS
bMXLslGgtdno0T8hueLY68pCybfFSU/aO3HDg3V8SNvH8cx84ZSndqvUtbro3/Ze
Uzt+JQtvp8R7vyTgrfJFy02UJvxk6jtd88H/FSO0bp4vLNOxDg3H/OvxjyXuHU5C
fACXayHvZbf/IZzpEjyVWt2pKH9TBNK2eB2omqIQupFCGboIk70S2kpeA8L8+YKx
1hWq0QWY9esyi7b8OZwX2QnEU2M+eBYCn+KZHp6BorLfxOTcctpxM37Up3ieOON5
asyOC4MMmOAvqs4NSHgqfGB2Pybd6I0+wZ0yz576rZqscE/zfRxkbaZ3MqKT53s=
=ernf
-----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/6aec6f83/attachment-0001.key>


More information about the squid-users mailing list