On Tuesday, December 07, 2010 12:26:30 pm David Sommerseth wrote:
> You mean something along the way ... "Oh, this Bob uses 172.16.10.72 ...
> let's run some traceroutes towards his gateway. That could be
> 64.57.176.18, right? Then we can just setup a direct route from us to
> his 172.16.10.0/24 network. Wait! Lets add 172.16.0.0/12, just to be
> sure we hit the right path"
And if his or your or any ISP between you and him implements BCP38 properly the packets with a destination of the RFC1918 address will be blackholed and will never get there, even if you put a static source route to them. You don't have a direct path to his router, at least not for routing purposes, since your packets are going to be inspected and routed by routers in between. It does depend on some best current practices being implemented, though. Like RFC1918 bogon filtering at the AS boundary as part of the BGP session between AS routers. And unless you are operating your own BGP border (I am at one site), you can't influence the AS path the packet will follow on the DFZ.
The basis for 'NAT security' is relying on the best practice of blackholing RFC1918 addresses on the DFZ router mesh. Not all AS's implement the policy properly, but enough do that trying to route (using essentially source routing) to an RFC1918 address will fail when it hits the DFZ, and virtually all inter-AS packets hit the DFZ at some point. Source routing is blocked by most AS borders, so you can't 'hint' the routers in between that you have to pass traffic to 172.16.0.0/12 through that particular router; the DFZ is going to tell your hint to shove it. But it does depend on the specific policies of each AS between you and the RFC1918-using target.
The security for RFC1918, or for IPv6 ULA RFC4193 addresses relies not on NAT per se, but on the basic non-global-routability of the addresses in question on the default-free-zone. NAT just allows you to use non-globally-routable addresses by translating to globally-routable ones.
About the only thing you could really do to gain direct access to his RFC1918-using network behind the NAT is to compromise his router and set up GRE (or similar) tunnels into it.
Further, what's to say his MUA isn't set to poison the mail headers this 172.160.0.0/12 address came from? That's relying on the mail headers; if I were to ssh to your server from behind a NAT I challenge you to determine the RFC1918 address I'm using.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
