Comment by zajio1am | Hacker News Reader

Comment by zajio1am | Hacker News Reader

Parent Full thread

RFC 4787 does not really describe how real world implementations behave. As almost all SOHO routers are Linux-based, i prefer to discuss Linux netfilter-based NAT behavior than some hypothetical RFC 4787 NAT. There are clear differences. For example, RFC 4787 says:

> REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior

While Linux netfilter behavior is "Address and Port-Dependent Mapping".

As Linux netfilter implements both NAT and firewall behavior, it is relevant for the discussion which parts of overall netfilter behavior falls into 'NAT part' and which into 'firewall part'. There is clear distinction - DNAT/SNAT rules in nat table represent NAT behavior, while REJECT/DROP rules in filter table represent firewall behavior.

As Linux-based SOHO routers are usually configured with both NAT and firewall netfilter rules to implement both NAT and firewall behavior, one cannot answer question 'Does NAT filter traffic?' based on external behavior of such SOHO routers, but has to analyze which part of the network stack is responsible for such behavior, or how the same network stack configured with just NAT rules and no firewall rules would behave. And here the answer is no, it would pass traffic (that do not match existing connections) unmodified.

The problem is: what is an implementation detail, and what is NAT as a concept? This line is very blurry. The RFC does not really distinguish this and also doesn't want to. As it says, it tries to document behavior and explicitly uses the term "NAT filtering". When we say "This box here does NAT", then we implicitly assume this behavior. You might argue that implicit is not good, and I would agree (this is the advantage of ipv6 with firewall: filtering is explicit rather than implicit). However, if someone tells me "Well actually, NAT does not do filtering, the firewall does", then to me this is similar to arguing with staff in a supermarket that the tomato belongs in the berries section.

I also want to make clear that I fully agree with the article's main point: NAT's primary purpose was and still is address conservation, and that ipv6 is no less secure than ipv4. I do disagree though with the notion that "NAT does not do filtering" or that "NAT does not provide any security".

NAT:

    iptables -A POSTROUTING -o wan0 -j MASQUERADE

Firewall:

    iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -A FORWARD -m state --state INVALID -j DROP
    iptables -A FORWARD -i lan0 -j ACCEPT
    iptables -A FORWARD -j REJECT --reject-with icmp-admin-prohibited

If you omit the first line, you get firewalling without NAT. If you omit the second set of lines, you get NAT without firewalling. This should make it pretty clear that they're orthogonal features.

If NAT functioned as an inbound firewall, the second set of lines wouldn't be necessary and removing them wouldn't let you make inbound connections. But you can just test it yourself, and you'll see that NATing your outbound connections doesn't block new inbound ones.

I can only repeat myself: you are talking about the NAT module in the Linux netfilter. I, and the RFC, are talking about NAT as a concept: what behavior do you expect when you say "this device does NAT". Of course you can still have "pure NAT", but if someone tells you "set up a device that does NAT" and you omit that first line and later explain that this is historically and technically accurate, well, good luck with that.

And if you have only the first line, what will happen if someone sends a request to the NAT's external IP on some random port?

Whichever machine has the NAT's external IP assigned to it will accept or refuse the connection, depending on whether they have a server running on that port or not.

The machine that has the NAT's external IP to it is, well, the NAT, by definition. So you admit that the NAT box will act almost exactly like a connection tracking firewall, even if only NAT is enabled.

No, I'm not going to "admit" that, because I know full well that it won't.

It's not like I'm sat here thinking "I know it does block traffic, but I'm going to lie to everyone that it won't". NAT in fact, actually, really and honestly, doesn't block traffic, and I think I've been pretty consistent in saying as much.

You've been consistently wrong, yes. A NAT router box will NOT translate a packet coming from the Internet (so, a packet with a globally routable IPv4 address) arriving on its WAN to the RFC1918 IPv4 address of any box sitting behind it on the LAN side, unless it is arriving on a previously open connection, or on a port the user explicitly asked to be allowed and forwarded - exactly the same behavior of a regular stateful firewall.

Of course it won't do that -- when did I ever claim it would? But that's not the same behavior as a stateful firewall at all.

A stateful firewall would block packets addressed to the router, or to machines behind it. NAT not translating a packet won't do either of those things.

Without at least some filtering a Gateway NAT appliance is vulnerable to:

* LAN IP address spoofing from the WAN

* Potential for misconfigured "internal" daemons to accept WAN traffic (listening on 0.0.0.0 instead of the LAN or localhost)

* Reflection amplification attacks

LAN IP address spoofing is indeed a valid attack vector, if the ISP is compromised.

Internal daemons on machines other than the router itself in the LAN network listening on 0.0.0.0 are not insecure (unless you have the problem from point 1, malicious/compromised ISP). The router won't route packets with IPs that are not in its LAN to them. Of course, the router itself could be compromised if it accidentally listens on 0.0.0.0 and accepts malicious packets.

Not sure what you mean by reflection amplification attacks, but unless they are attacking the router itself, or they are arriving on WAN with LAN IPs (again, compromised/malicious ISP), I don't see how they would reach LAN machines.

You do not need compromised ISP for spoofed LAN IP traffic, the attack could came from other clients on the same WAN segment.

All the Linux routers I've used utilize Endpoint-Independent mapping with Address- and Port-Dependent _filtering_.

This means you can still establish direct P2P connectivity behind a Linux-based NAT device with users behind other Linux-based NAT devices. The only time it becomes an issue is when attempting to communicate with users behind NAT devices that do Address-Dependent _mapping_ or Address and Port-Dependent _mapping_. Some *BSD-based NAT implementations are this way.

Endpoint-independent _filtering_ is only a good idea for CGNAT implementations. Having an EIM/EIF NAT/firewall setup without additional firewalling makes it possible and easy for devices to run public-facing UDP-based servers without anyone's knowledge. With EIM/EIF, once you create a NAT mapping, so long as you send out periodic keepalives, _any_ IP address with _any_ source port can make unsolicited connections to a server that the NAT mapping points to. The best compromise is Endpoint-independent mapping with Address- (but not port-) dependent filtering.

Reply on news.ycombinator.com