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