-----Original Message----- From: Phil Regnauld [mailto:regnauld@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