> The main factor that prevents even more stuff being exposed to the internet than now (and there's a lot exposed already) is the prevalence of IPv4 NAT devices.
All of this is blocked by default-deny firewall rules.
I have IPv6 at home from my residential ISP, and I get a globally routable a 2000::/3 IPv6 address on my systems (via SLAAC), but they are not accessible from the public Internet by default.
The idea of publicly routable = publicaly accessible needs to die.
The thing is, you can turn that off. So if the user can turn it off, they will eventually turn it off, because that's just what people do if they have some problem somewhere: toggle random settings they have no clue what they mean, or asked their 14yo "computer wizard" nephew for advice, you name it.
With NAT it is impossible to disable the firewall. The worst you can do is put one machine into the DMZ, and people did do that of course because of what I just said, but at least it isn't the entire network at once with every shitty iot fridge smart bulb vibrator toaster the average Joe has today.
That's not what you think but some additional nonsense like turning off ICMP replies on the wan interface.
If you only get one public ipv4 assigned by your ISP, there is simply no way to set it up in a way that every device on your network is reachable from the internet on all ports with just one click.
NAT (particularly NAPT) actually has the potential to lower overall
security because it creates the illusion of a security barrier, but
does so without the managed intent of a firewall. Appropriate
security mechanisms are implemented in the end host, without reliance
on assumptions about routing hacks, firewall filters, or missing NAT
translations, which may change over time to enable a service to a
neighboring host. In general, defined security barriers assume that
any threats are external, leading to practices that make internal
breaches much easier.
The more likely scenario is your system (or phone) gets compromised, it lives behind the supposedly secure NAT "firewall", and since you had a false sense of security from NAT your entire internal network has all sorts of holes.
The era of network moats was over long ago, and NAT is simply perpetuating the illusion.
I'd rather take the risk of SPI IPv6 firewalls, have the alleged chaos of allegedly exposed IoT systems, and force everyone to up their security game: short-term pain is healthier IMHO.
But not on your own network or your parents/friends whoever. You want others to have that pain, as a policy decision, right? It's reasonable but worth clarifying.
> … does so without the managed intent of a firewall.
Most home networks have no management, or intent, at all. People just buy whatever boxes are sold to them and plug them in.
Now, yes, if you actually design a network, and properly set things up, then a firewall will give you better control. Will grampa Jim do that? Absolutely not.
Hole punching requires cooperation by the application that wants to be reached. That's not quite the same thing as turning off a firewall (or equivalently, port forwarding).
It is, and I guess many tech savvy people turn that off immediately, but it's still not as bad. You don't suddenly expose every Windows machine, every iot device's telnet port with guessable password etc to the internet.
As far as I see the only thing you're really suggesting here is that consumer routers should have firewalls that can't be disabled, and that NAT currently fulfills this function.
Much "We're from Silicon Valley and we're here to help" vibes.
For the ISP-provided one, absolutely a sensible move. Just like most ISPs here don't offer bridging mode anymore in their modem+router combos.
This still doesn't mean someone who has no clue will end up buying a device that allows them to do this, and ignore a warning message in big bold letters and still do it, but the vast majority of people will be saved from themselves.
>With NAT it is impossible to disable the firewall.
Nonsense. If we suppose a switch to turn the firewall off, we can suppose a switch to turn NAT off and convert the router into a bridge that connects LAN and WAN. Then a LAN device can speak DHCP to your ISP and get its own public address. It doesn't have to be limited to one LAN device either; my ISP allows two IPs per customer connection to make it easier for people power-cycling their routers / ONTs during troubleshooting.
That breaks, however, once there is more than 1 customer device on the network. Since "multiple devices" case is super common, I don't think this is something to be concerned about for general public.. "hey, you broke by ipad, whatever checkbox you unchecked, check it back"
Yes and you do this accidentally by plugging WAN cable into LAN port of the router, effectively bridging your interal devices with ISP, and if DHCP from ISP wins the race against your router, then your PC is on global address with no firewall.
True story!
Things like Homenet that tried to fix this did not go anywhere
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.
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.
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).
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.
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.
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.
All of this is blocked by default-deny firewall rules.
I have IPv6 at home from my residential ISP, and I get a globally routable a 2000::/3 IPv6 address on my systems (via SLAAC), but they are not accessible from the public Internet by default.
The idea of publicly routable = publicaly accessible needs to die.