Hacker News Reader

Comment by growse | Hacker News Reader

If NAT is an implicit firewall, then so is an unplugged network cable. I guess it's technically true, but isn't a particularly meaningful assertion - you might as well say that NAT is also 'not a donkey'. Again, technically true, but doesn't really help.

Firewalls are packet filters. Confusing routing and packet filtering doesn't help anybody solve any problems.

We're talking (I think) about how to mitigate threats from the public internet by dropping unwanted traffic with IPv6. The answer is a firewall (as it is with IPv4).

View on HN

I can hook grandma up with a $30 chinese NAT box, disable UPNP and she's mostly safe from all sorts of port knocking attempts - while still having internet that seems to work great for her.

What would be the ipv6 equivalent? You can call it a donkey all you want.

The equivalent is buying her a $30 Chinese router that supports IPv6 and comes with a firewall enabled by default (or is configurable).

Exactly. Rip out all of that logic that maintains the address translation table and performs address mangling and you have a simple stateful firewall that's obviously less complex. It's difficult to see how ripping out the address translation could be more exploitable or costly to maintain. Ideally, we'd start with things written from the beginning to be stateful firewalls, but if I worked for a home/small office router ventor, my first course of action would be to just ripp out that potentially buggy address translation part of our existing NAT implementation.

Great! Which one is that? Do I need to buy it and perform some extensive testing first to figure that out? Looking forward to it!

Pretty much all of them?

My expectation is far far lower. And those that are might not still be decent after an upgrade (and you won't know if the hardware or software you buy will be of another revision).

Hardware that happens to be popular are often updated to a cheaper variant where the manufacturer rides on the fame and good reviews of the original version.

So you can't even do the research once and expect it to hold for future purchases/replacements.

Well, instead having "expectations", how about just checking it yourself before spreading FUD?

No amount of FUD comes close to the reality when it comes to home routers.

usrusr explained it nicely. It will likely take years before anyone will realize that the firewall doesn't work at all. Whereas a similarly broken NAT router will be declared DOA.

The problem is that you can perfectly fail at implementing a firewall without breaking access to google.com, whereas broken NAT will mean no google for you. A bridge is not NAT with some features switched off, it's an entirely different topology. A v6 router without the firewall will still be a router. When setting up, people just want "the internet" to appear in their browser, that's their definition of done and NAT made it extremely unlikely to get there with universally open ports.

> The problem is that you can perfectly fail at implementing a firewall without breaking access to google.com, whereas broken NAT will mean no google for you.

Broken NAT:

  iptables -t nat -A POSTROUTING -o outside0 -j MASQUERADE
  iptables -P FORWARD ACCEPT

Google works fine, but when somebody sends the external interface of my router a packet with destination address 192.168.1.42 (as can often be done from any compromised router on the same cable segment), it gets forwarded to 192.168.1.42 on the internal network.

NAT is not a firewall.

Hook grandma up with a $30 chinese firewall box, and disable UPNP? Plug modem into WAN, computer into LAN, turn it on, done.

True, it will be called a "router" in consumer speak, but all consumer IPv6 routers should actually be firewalls.

A connection-based NAT does filter! Any source not in the database gets the packet discarded.

And this is the confusion most people have!

NAT isn't doing that filtering, the stateful firewall is.. Every NAT device sold in a very long time has both features..

Some early DSL modems for example had only NAT, and they were horribly insecure.

NAT is not a firewall, and provides near zero security. And, in combination with a stateful firewall, it provides exactly zero additional security.

But how so? If my public address gets a random packet and there are 5 devices on the lan side, which local address did those devices send unsolicited inbound traffic to? Where's the insecure part?

Yes, because there is no firewall state. There is both firewall and NAT state for every established connection.

Exactly. Remove the firewall state, and you're wide open for all the NAT'd ports. And if someone thinks they don't have any NAT ports, they would be wrong. You likely have 10's or 100's ports NATd for every device activity being used on your network.

To the various remote management ports listening on the DSL modem itself. Between RCE vulnerabilities, accidentally unauthenticated management features or even just upnp listening on the WAN port, there are infinite means for owning the network behind the device.

But that's more of a general problem that still happens on modern devices, even with ipv6. ISP wants some port open on the device for remote management but is so incompetent that it's actually reachable worldwide.

Yes. I was just responding to the claim that with IPv4, thanks to NAT a malicious packet would not be able to be routed anywhere unsafe.

A NAT router without any kind of firewall functionality is incredibly unsafe too so even the cheapest ones have some of it these days.

Which follows that the cheapest IPv6 routers would also have a firewall and thus would not be inherently worse at protecting the internal network than a v4 router doing NAT would.

If one of those 5 tries to connect e.g. to a remote windows file server .. you now have an open port on your public IP which will accept packets from any IP on the internet and will forward them to the windows file share service on your desktop.

Add a stateful firewall with connection tracking, and that port is only open to the 1 server you tried to connect to.

Yes that's true, but not a problem for TCP since the attacker had to know the outgoing port from the ephemeral port range your PC or router picked, and then had to take over the running TCP session by additionally knowing the connections state (sequence number etc). For UDP you indeed have higher chances of talking to that device in an unsolicited manner, and this has been exploited by games and later Skype in the past. So yes, indeed more insecure, I stand corrected. I'm still more worried for actual exploits or security holes even in modern devices that can do proper firewalling the ISPs provide due to incompetence or laziness. Like the TR069 port being open on many devices two years ago.

Yes, the modem/router is likely buggy as hell, most "consumer grade" CPEs are. The best defence for that IMO is to remove as much code as possible - like the unnecessary for IPv6 NAT stack..

If your public address gets a random packet then the packet is addressed to your router, not one of your local devices. This is insecure if the router is providing some insecure service on that port, but otherwise it's irrelevant to this discussion.

The problem comes when your router receives a packet addressed to one of your local devices. Many people in this thread believe that if the router is NATing outbound connections, it'll drop this inbound packet, but that's not what happens -- the packet will actually be routed to whichever local device it was addressed to, just like any other packet would be.

This should be fairly obvious, because the only thing NAT does is change the apparent source address on outbound connections. It does nothing at all to inbound ones (and you can demonstrate this to yourself by setting up a test network in some VMs and NATing traffic between them with Linux and iptables).

(You can configure a NAT to do things to inbound connections using port forwarding rules and/or a DMZ, but those rules only apply to specific inbound connections. Connections not covered by those rules are treated as normal, and "as normal" for a router means normal routing.)

NAT isn't a firewall, because it doesn't drop connections. All it does is rewrite addresses on connections, not decide which connections can and can't be made.

> This should be fairly obvious, because the only thing NAT does is change the apparent source address on outbound connections. It does nothing at all to inbound ones (and you can demonstrate this to yourself by setting up a test network in some VMs and NATing traffic between them with Linux and iptables).

Absolutely. It's trivial to demonstrate how utterly useless a router configured with NAT, with routing, but without a firewall is. (Useless in the context of a home CPE device for the average home internet subscriber..)

As a side note, yes, packets arriving towards your router with a destination address on your LAN will be forwarded by the router piece of your router.. the firewall piece would prevent this. This is independent of the use of/absence of NAT though..

You can't just separate it out like that. It's impossible to do a connection-based NAT without state.

But it's not trying to drop anything. You can set a default device to throw all incoming connections at.

And with a pure NAT you can't set any rules about what to allow or drop. It only acts like a firewall from one very narrow angle.

This seems to be agreeing with me and many of the others? A stateful firewall is a useful thing on its own, but it's also a fundamental requirement for modern NAT implementations.

NAT on the other hand is not a fundamental requirement for a firewall.

NAT bolts onto a firewall, and it's the firewall that provides the security. Remove NAT, and you haven't lost anything in terms of security.

I'm saying that such a NAT can exist by itself without a true firewall.

A stateful firewall isn't a fundamental requirement for NAT though, even modern NAT ("or actually PAT", as other posters seem to like saying...). State tracking is certainly a requirement, but tracking state is separate from firewalling based on that state.

This is why firewalling is separate from NAT, and why NAT isn't a firewall. Yes, it's true that both NATing and firewalling rely on tracking state, and typically both NAT and firewalling are implemented together in the same software and hardware, but they're two separate behaviors and you can do one without doing the other.

Reply on news.ycombinator.com