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: giles_at_coochey.net Skype: gilescoochey
This archive was generated by hypermail 2.2.0 : Wed Feb 02 2011 - 12:00:03 MST