BCP38 tester?

Mailman List Mirror (Read Only)
21

So it may well be that a particular device, capable of doing NAT and
other things, of NATting some packets but not others, may permit

Yes. Many NAT devices of reasonable quality are fully capable of such things.

And skipping NAT or NAT'ing the source IP address on the outgoing
interface to the same as the source IP address the packet had on the
incoming interface, is the likely default, when NAT has been
configured based on source IP address range, on some devices.

spoofed-because-not-NATted outbound packets, but I remain unconvinced
that a spoofed packet can make it through a NAT process and head
outbound without getting its source address clamped to a configured
range of outside addresses.

Ah, but did you actually test your guess on a reasonably large variety
of NAT platforms?
It just takes 1 instance of the right platform to be in significant
use for something to be different than expected.

I remain unconvinced that all CPEs in all common configurations will
clamp the source address to a legitimate one in all cases.

It would just be way too much luck and convenience for that to happen
by coincidence.

Now I'm imagining a NAT process that translates only *destination*
addresses - hm, is there such a beast?

Of course there is... in some implementations you may need two NAT
rules to define a 1:1; a source NAT rule, and a destination NAT rule;
if you define only the Source NAT rule, you just translate the
source IP address ranges selected to the translation IP address
range(s) selected for outgoing connections, and new incoming
connections are not translated; if you define only the DNAT rule, you
translate only the WAN interface destination IP for incoming
connections, and outgoing connections are not translated.

In various implementations
you can have full-cone NAT, address-restricted cone NAT,
port-restricted cone NAT, symmetric NAT, and various combinations
and variations (even different kinds of NAT in different directions),
for each of source and destination address, with or without storage
of a mapping for return traffic.

Different source or destination IP ranges or TCP/UDP ports might be
NAT'ed differently or not at all.

Not all implementations allow all possible useful NAT configurations.

22

While I was reading this... thinking that a NAT is a NAT is a NAT...
    ( I spend "some" time writing/porting NAT code in my youth )

    I'm sad to confirm that my spoof test was successful with a:

        . SageMCom modem+router, which is used by a big TelCo around my
part, for both their residential and commercial ADSL2+, VDSL customers.

        . 4 well know Tier-2(?) provider :frowning: why I'm wasting time filling
up "paper" LoA if its only going to be used for BGP.

    But on the other hand... it failed on a:

        . Cisco (*cought* LinkSys) WRT54G loaded with DD-WRT v2.4-sp2
micro (2010/10/09);

        . SonicWall 2040 with 4.2.1.3;

        . Thompson SpeedTouch 516;

        ( I'm looking around for more CPE I could "use", for testing =D )

    PS: I'm not promoting the listed vendor, products. Its only a quick
test with what I had on my hand during breakfast.

23

Hi,

    http://spoofer.csail.mit.edu/ is really the best place to certify
for BCP38.

24

You might want to check more carefully exactly what the failure mode
was. I'm willing to bet that the router has been configured to assign
addresses inside a specific RFC 1918 /24, and will do Something Terrible
to spoofed packets in that range, but will figure you know what you're
doing and pass them if you source a packet from outside that /24.

25

My test script is very very very basic... but passes.

    And as per spoofer.csail, which is way more comprehensive in its
testing.

CPE tested with spoofer this morning.

    For the SageMCom 2864 with FAST2864_v6740S firmware:

        Received (at MIT AS3):

            1.2.3.4 | x.x.x.x | The IANA unalloced source was
successfully received.
            6.1.2.3 | x,x,x,x | The spoofed packets were successfully
received. There is no ingress or egress source filtering on your network
for this IP address.

        Your host can spoof 16777215 neighboring addresses (within your
/8 prefix)

    For the SpeedTouch 516:

        Received (at MIT AS3):

            1.2.3.4 | x.x.x.x | Source address rewrite. The source
address of the probe packets we received differs from the original
address. It appears that a Network Address Translation (NAT) device is
rewriting your packet headers.
            6.1.2.3 | x.x.x.x | <same>
            172.16.1.100 | x.x.x.x | <same>

        Your host can spoof 0 neighboring addresses (within your /32 prefix)

        ^ the /32 is a bit confusing.

    PS: This was just a few empirical tests and is in no way, shape, or
form, a judgement about the quality of the devices tested.

26

D'oh. Of course.

Hmmm. That says things about the penetration of NAT routers at consumer
eyeball connections vs. directly connected PCs that surprise me.

Cheers,
-- jra

27

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.

I have never found anything for which that's *not* the default config.

Upscale things like Snapgears, and routers running -WRT or Tomato, etc,
can be configured to do other things, but even on those, that's the
default config for outbound NAT.

It just takes 1 instance of the right platform to be in significant
use for something to be different than expected.

Sure, but the question here is "is it reasonable to think that the
*magnitude* of the problem is substantially reduced because consumer
NAT routers are doing much of the work for us" and that answer is
decidedly "yes, it is".

Sure, it's egress filtering, and a bad actor can get around it, if only
by *not using a router*. But a *trojan* likely cannot, and that helps
us a lot too; 4-6 orders of magnitude, depending on your opinion of
the penetration of consumer edge routers.

I remain unconvinced that all CPEs in all common configurations will
clamp the source address to a legitimate one in all cases.

"All"? Yeah, probably not. But I think we're getting 99%, and you know
what? I'll take that.

It would just be way too much luck and convenience for that to happen
by coincidence.

Once in a while, you win.

> Now I'm imagining a NAT process that translates only *destination*
> addresses - hm, is there such a beast?

Of course there is... in some implementations you may need two NAT
rules to define a 1:1; a source NAT rule, and a destination NAT rule;
if you define only the Source NAT rule, you just translate the
source IP address ranges selected to the translation IP address
range(s) selected for outgoing connections, and new incoming
connections are not translated; if you define only the DNAT rule, you
translate only the WAN interface destination IP for incoming
connections, and outgoing connections are not translated.

In various implementations
you can have full-cone NAT, address-restricted cone NAT,
port-restricted cone NAT, symmetric NAT, and various combinations
and variations (even different kinds of NAT in different directions),
for each of source and destination address, with or without storage
of a mapping for return traffic.

Different source or destination IP ranges or TCP/UDP ports might be
NAT'ed differently or not at all.

Not all implementations allow all possible useful NAT configurations.

And the majority, by implementation count, don't allow *any* of those.

They allow outbound-SNAT, and configurable inbound-DNAT, maybe.

Cheers,
-- jra

28

The good news is that source address spoofing does seem to fail with most CPE's NAT.

At the end of the day, just turn on uRPF and/or use ACLs. It's amazing how much destination 192.168.0.0/24 and 192.168.1.0/24 our ACLs also block.

Frank

29

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

30

The trouble with winning by coincidence or winning as a side-effect...
Do you keep winning?

What happens with IPv6 CPE devices, when there is no NAT?
No translation occurs, so possibly rogue source IP packets get
through, unless the device specifically applies uRPF or clamping
source addresses to the LAN interface subnet.

It would be nice if the RFCs specified Ingress filtering by default in
router requirements for IPv4 and IPv6, as a MUST requirement; instead
of some 2nd class citizen, optional best practices document.

By specifying ingress as the default, it then becomes an implementor
responsibility to understand when and where in their network they have
to override the default for things to work properly, when it is safe
to, and where the filtering is required.

31

From: "Jimmy Hess" <mysidia@gmail.com>

>> It would just be way too much luck and convenience for that to
>> happen
>> by coincidence.
>
> Once in a while, you win.

The trouble with winning by coincidence or winning as a side-effect...
Do you keep winning?

Depends on how you won.

What happens with IPv6 CPE devices, when there is no NAT?

Well, that's going to be an interesting question in general:
will v6 edge routers a) exist, b) handle the addressing, c) handle
DHCP, d) actually not do NAT, or e) NAT a v4 home network to a v6
address/network?

No translation occurs, so possibly rogue source IP packets get
through, unless the device specifically applies uRPF or clamping
source addresses to the LAN interface subnet.

It would be nice if the RFCs specified Ingress filtering by default in
router requirements for IPv4 and IPv6, as a MUST requirement; instead
of some 2nd class citizen, optional best practices document.

Nah. That's *not* ingress filtering, for all practical purposes; it's
*egress* filtering -- filtering that's under control of the network
operating entity, and thus semi-useless for the purposes at hand.

(On re-reading that, I see I'm not entirely clear: any filtering has to
be done on the upsptream end of the link, so that it is *not* in control
of the entity which might be originating the bad packets; John Carmack
illustrated why in his piece about Quake cheating. What; you haven't
read that piece? And you run networks? :slight_smile:

Cheers,
-- jra

Cheers,
-- jra