[162061] in North American Network Operators' Group
Re: BCP38 tester?
daemon@ATHENA.MIT.EDU (Matt Palmer)
Mon Apr 1 19:03:33 2013
Date: Tue, 2 Apr 2013 07:33:45 +1100
From: Matt Palmer <mpalmer@hezmatt.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <27877536.446.1364833865691.JavaMail.root@benjamin.baylink.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mon, Apr 01, 2013 at 12:31:05PM -0400, Jay Ashworth wrote:
> From: "Jimmy Hess" <mysidia@gmail.com>
>
> > Ah, but did you actually test your guess on a reasonably large variety
> > of NAT platforms?
>
> He may not have, but now that I'm thinking (caffeine is a wonder drug),
> I have: I've worked on, for customers, nearly every brand of consumer
> router on the market, and all of them do outbound NAT the same way:
>
> Pick up a DHCP address from the carrier, and use that as the source IP
> on all translated outbound packets.
The key issue at hand (I believe; please correct me if I'm wrong) is that
"all translated outbound packets" may not equal "all outbound packets".
Depending on how a NAT device is configured, it may pass some packets
*untranslated*, and that allows a malicious actor behind the NAT device to
still get their spoofed traffic out.
To relate it back to something concrete, imagine this iptables rule in an
otherwise "fully open" configuration:
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o wan -j MASQUERADE
Now, spoof a packet from behind this NAT box as coming from 192.0.2.12...
what happens? It gets passed through the NAT box, *without* being NATed.
Oops.
Of course, it isn't hard to stop this sort of thing...
iptables -A INPUT ! -s 192.168.1.0/24 -i lan -j DROP
(or any number of other equivalent rules) The question is, how many
in-common-use CPEs have considered this attack vector and are actually doing
something functionally equivalent to the DROP rule above?
I don't know, because I haven't tried it, but I'd only be surprised if the
answer was "none" or "all of them".
- Matt
