-----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
