-----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@xxxxxxxxxxxxxxxxxxxxx >> http://lists.squid-cache.org/listinfo/squid-users >> > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > 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-----
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
