On 01/02/2011 11:13, Amos Jeffries wrote:
The CVE is applicable to all proxies doing interception. They generate their URL from the Host: header instead of the TCP link details from the client. Neither being a reliable source of information. The one saving grace so far is that the client TCP IP gets logged and countermeasures can be placed to block nasties.In the case of remote NAT the TCP link details are themselves wrong. Indicating that the router IP is the client origin. So there is zero traceability for a network-wide poisoning attack with zero ways to protect against it.The problem has apparently been known since around the time NAT interception was created. 2009 is merely the year infections were identified that use it. There is no reliable fix. All we can do is stress "avoid NAT" and take the (slightly) more difficult road of configuring the network to use so called "zero-conf" auto-detection of the proxy. It is worth it in both medium and long term.
Thanks for elaborating.So the case being, and I think that this is true for all NAT operations, that NAT at least obfuscates connections and in the case of Squid that can cause real problems. I agree that policy routing is a better implementation, although a lot more complex for some to set up and, I'm guessing, would probably require a custom kernel recompile for many distributions.
-- Best Regards, Giles Coochey NetSecSpec Ltd NL T-Systems Mobile: +31 681 265 086 NL Mobile: +31 626 508 131 GIB Mobile: +350 5401 6693 Email/MSN/Live Messenger: gi...@coochey.net Skype: gilescoochey
smime.p7s
Description: S/MIME Cryptographic Signature
