-----Original Message----- From: Phil Regnauld [mailto:regna...@nsrc.org]
> PAT (overload) will have ports open listening for return traffic, > on the external IP that's being "overloaded". > What happens if you initiate traffic directed at the RFC1918 > network itself, and send that to the MAC address of the NAT device ? > In many cases, it just works. That's how IP forwarding works, after > all :) > > inside net ----------[NAT]-----------{ext net}----[attacker] > 192.168.0.0/24 .254 1.2.3.4 1.2.3.5 > S:1.2.3.5 D:192.168.0.1 next hop: 1.2.3.4 > > Now, on the way back *out* from the inside net, traffic from > 192.168.0.1 back to 1.2.3.4 might get translated - it depends if > what the NAT is programmed to do if it sees, say, a S/A packet > with no corresponding SYN, on its way out. It might just get > dropped. UDP would in some cases get natted, but since you > know your destination port on 1.2.3.5, you know what to expect, > and you can build an asymmetric connection since you control the > attacking host. > > Either way, you've still injected traffic into the inside net. > That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host. Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue. Chuck