Comment by deng

1 month ago

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

11 comments

deng

Dagger2 1 month ago

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.

tsimionescu 1 month ago
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?
- benlivengood 1 month ago
  
  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
  
  2 replies →
- Dagger2 1 month ago
  
  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.
  
  4 replies →
deng 1 month ago

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.