Hacker News Reader

Comment by iforgotpassword | Hacker News Reader

That's an outlier. Almost every ISP hands out 0 to 1 ipv4 addresses. And even if it's two, the user will quickly realize that "internet is broken" on some of their devices, as two random ones picked up the addresses and the rest don't get any, and reverse the config change.

View on HN

My argument is about LAN devices ending up with publicly reachable IPs. It's not contingent on the ISP allowing more than one IP address per customer connection.

BTW, since you think you can turn your router's firewall off and rely on just the NAT to protect you, please tell me what you think will happen when a packet with destination IP 192.168.1.2 appears on your router's WAN interface. What component of the router do you think prevented those packets from crossing to LAN? Hint: its name starts with "f" and ends with "irewall".

Sorry but your argument is moot. Yes NAT is not firewall.

No my devices are not receiving random packets with internal IP addresses often enough for me to worry about it.

Even better not single of my devices living behind only nat in 20+ years was taken over or ransomed.

If it would be real problem I would hear about it daily and - if it would be so easy - all kinds of APT groups would take over devices behind NAT en mass. I don’t believe that any residential router has firewall enabled by default and only devices that are taken over are ones really having public IP.

Anyone can prove me wrong sharing links to articles and instances where there was occurrence of mass takeovers using NAT traversals.

>Even better not single of my devices living behind only nat in 20+ years was taken over or ransomed.

Yeah, because you didn't turn off the firewall. And/or because your ISP was being nice / competent and not routing packets to you that didn't make sense for your assigned route.

Still my point is right, NAT traversal hacking is not an issue and is complicated enough to not be practical.

Residential off the shelf routers don’t have firewall for incoming traffic. For business use you always put hardware firewall behind ISP router, I don’t have firewall at home.

> Residential off the shelf routers don’t have firewall for incoming traffic

[citation needed]

This is 100% wrong.. all consumer routers have firewall functionality built in.

I think the component that prevents that packet from crossing from WAN to LAN is, precisely, the NAT. Or more specifically, that no dynamic NAT mapping has been established previosuly, from an outbound transmission from 192.168.1.2 towards the remote source of the packet.

Given how NAT works, if there hadn't been any outbound connection, there is no mapping of transport addresses in the NAT table, and thus an incoming packet is rejected. The firewall would be _behind_ the NAT, on the internal side, applying _additional_ rules to packets that did match some of the NAT mapping rules and were able to cross that boundary.

So to all effects, if the NAT discards an incoming packet, the firewall doesn't even get to process it.

Which is not to say that some vendors confuse this distinction, and call "firewall" to the NAT behavior.

That is only one specific, limited type of NAT, i.e. an "address dependent filtering" NAT.

The recommended (and common) form is EIM (Endpoint Independent Mapping), where one a private host+port (say 192.168.1.1:4567) has formed a connection to some public location (e.g. 1.1.1.1:53), and acquired a mapping on the WAN of (WAN-IP:pppp) then anywhere on the whole public Internet can form a connection to 192.168.1.1:4567 by sending packets to WAN-IP:pppp.

That is one of the ways in which NAT-Traversal ("hole punching") works. It has the nice property that P2P applications (e.g. online games) can form direct connections between devices behind NATs.

That same property generally applies for both TCP and UDP, and for all ports.

The thing which would prevent that in some NAT is the filtering behaviour, i.e. the session table which people are conflating with a firewall. If that filtering is also "Endpoint Independent" (which it often will be for consumer devices), then the above description applies.

If the filtering is "Address Dependent", or "Address and Port Dependent" then the more restrictive cases of other public internet devices not being able to use the mapping applies. However this is usually only seen with various forms of enterprise deployed NAT (since they often have firewalls also explicitly installed).

NAT will map an incoming packet with destination WAN_IP:port to LAN_IP:port. It is irrelevant for incoming packets with destination LAN_IP:port.

I have been trying to figure this out thank you for this response

192.168.1.2 should be dropped because it doesn't match the WAN subnet. If your router is set up wrong at the factory to forward any traffic through the WAN port I wouldn't trust the firewall, let alone NAT, save me...

The whole conceit of this conversation is that iforgotpassword has (a thought experiment of) a router where they've managed to "turn off the firewall" but still expect safety due to the use of NAT. My comment was about how that is not true. ie a) if it's easy to turn off the firewall then it's also equivalently easy to turn the router into a bridge, and b) if there is no firewall then bogons on the WAN will not be filtered and will instead be forwarded to the LAN.

You are technically right, which is the best kind of right, but then again, what would pose a greater risk: ipv4 with NAT where you turned the firewall of, as you described, or ipv6 with no nat where the firewall gets turned off? In your example with a packet coming in on the wan side with a destination address in my lan segment, how exactly did that packet get there? Spoofing the source address is easy, but for a spoofed destination you'd have to be my ISP, or have hacked my ISP.

IPv6 might still be more secure; granted, with IPv6 you would have direct access to devices you know, but blind enumeration of other LAN devices would take more time that literally scanning the entire IPv4 internet.

How would such a packet get routed to you in the first place?

Your ISP could be incompetent or malicious and not filter bogons out. Or you could be sharing a subnet with another tenant that has a misconfiguration on their end or is just plain malicious.

I see. But wouldn't your router simply then drop the packet, since there would be no WAN-side entry for that address in the translation table?

You don't need a translation table to cross interfaces.

Any router has forwarding enabled (because otherwise it's not a router and would discard packet not addressed to it), so if the packet hits WAN with an address in LAN subnet - it's just get routed if there is no explicit 'deny all from all' on WAN, on the FORWARD table, to be precise.

Surely, you can't forward the packet with dst_address in RFC1918 over the Internet, but you can do that if you are close enough.

This is the reason the NAT is not a security boundary or firewall: NAT apologists are saying what 'NAT drops anything on WAN', except it:

is not even involved if the attacker is close enough to forward the packets with your LAN subnet at your router WAN interface

doesn't help if there some established session or misconfiguration[1] which explicitly allows to access the host on the LAN subnet

Take a look at the table at [0]:

And to the chain traversal order:

    Incoming packets destined for the local system: PREROUTING -> INPUT
    Incoming packets destined to another host: PREROUTING -> FORWARD -> POSTROUTING

If there is no NAT rules in PREROUTING then the packet goes to the FORWARD table. And not surprisingly most systems with enabled routing (ie forwarding) would have 'allow any from any to any' there, aka ':FORWARD ACCEPT' in iptables parlance, because nobody does explicit forwarding rules by default.

[0] https://www.digitalocean.com/community/tutorials/a-deep-dive...

EDIT:

[1] or a helpful autoconfiguration tech:

  NAT fanboi: I am secure because NAT, har har
  Helpful media player with UPnP: hold my beer
  Torrent client: hold /my/ beer

https://news.ycombinator.com/item?id=36993546

https://news.ycombinator.com/item?id=36996704

Reply on news.ycombinator.com