Hacker News Reader

Comment by fsh | Hacker News Reader

If you really don't have a stateful v4 firewall, your ISP can happily connect to all of your devices.

I don’t think you understand symmetric NAT. Requiring an entry in the port address translation table to propagate a packet is not the same thing as a stateful firewall.

You absolutely can have a port address translation implementation without a stateful v4 firewall that wouldn’t forward packets destined for inner IPs on the outer interface. Just put an ACL on the external interface to not allow traffic to the inner IP block.

How do they manage that?

Send packets to the device? A NAT is in it's most basic form a mapping from one IP/port set to another IP/port set describable by some function "f" and its inverse "g". The common home user case has the firewall detect a flow from inside the network and modify "f" and "g" to allow this flow. Without the firewall, and assuming you want your devices to talk to the internet in some way, the NAT would forward (with modifications) traffic based on "f" and "g" to all your devices.

If your public IP from your ISP is 12.13.14.15, and your internal block is 192.168.0.0/24, then your ISP can send a packet to 12.13.14.15 destined for 192.168.0.7, and without a firewall your router will happily forward it. An attacker who can convince intervening routers to send traffic destined for 192.168.0.7 to 12.13.14.15 (and these attacks do exist, particularly over UDP) can also do that.

Okay, so not only do you have to create a bogus packet, you have to convince every piece of equipment in between you and the end user to collude with it, in the hopes that the final router is so woefully misconfigured as to act upon it?

The ISP is the primary threat vector here (do you trust yours? Along with their contractors and anyone who might have compromised them?). But like I said route-poisoning attacks do exist.

Yes, I trust everyone who works at it, mostly because I know where they live.

Do you trust the state actors who have compromised it?

Or more likely, network engineers who’ve been subpoenaed to collect the information?

Your scenario is plausible for high value targets. Like, what country wouldn’t want to have a friendly tech working at the ISP most politicians use in DC? That doesn’t seem improbable.

For the regular Joe Schmoe, I’d be more concerned with court-ordered monitoring.

Ah, that sounds like an American problem. If you're in the US, you're living in a hostile surveillance state that makes North Korea look like a hippy commune.

Oh yes, subpoenas are a uniquely American problem. eyeroll.png

I know all the people that work at it.

yeah but the likelihood of this is incredibly remote. It would shock me if ISPs didn't have alarms going off if RFC1918 space was suddenly routable within their BGP table.

Not to mention the return packet would be NAT'd so the attacker would have to deal with that complication.

You're missing the part where the ISP is the one doing it

Mm. Can you give an example of that happening in real life?

Google "Eagerbee"

Not finding anything saying that ISPs have anything to do with Eagerbee.

ISPs were the vector for Eagerbee. Don't trust your next-hop router.

There's nothing on Google about that.

The return packet wouldn't be NATed, because stateful NAT tracks connections and only applies NAT to packets that belong to outbound connections.

Arguing over how likely this is is missing the point. If it can happen at all when you're running NAT, then it should be clear that NAT isn't providing security.

“if it protects 99.999% of attackers from reaching you but not this one specific attacker in this one case of misconfiguration, it’s not providing security”…

Dude, that’s a really shitty take and this is why people that do care about security end up ignoring advice from anyone who thinks this way.

You’re in the camp of “don’t use condoms because they can break”.

NAT doesn't protect you from 99.999% of attackers though. It doesn't do anything to incoming connections, so it actually protects you from 0% of attackers.

Okay, but unless you've poked a hole through NAT (and if you have, presumably you know what you're doing), what are those incoming connections going to connect to?

If there's nothing to connect to, is there really an incoming connection?

They connect to whatever IP is specified in the packet's "destination IP" header field. It's exactly the same behavior as if there was no NAT going on.

The destination IP header from the internet belongs to the router. There is nothing internal to connect to without NAT.

No, it might belong to the router. If it does then the connection goes to the router, but if it's set to a LAN machine's IP then the packet gets routed to the LAN machine.

You aren't in control of the contents of inbound packets, and NAT won't filter them to enforce anything about the destination IPs in them either.

Nobody on the Internet can send a packet to an internal IP on your network except for immediate L2 neighbors (I.e. your ISP).

Symmetric NAT 100% stops inbound unsolicited connections to the public IP. And using the public IP is the only way 99.999% can address you.

I implore you to write down (even if just for yourself) what the packet headers would be for you to get a packet from Starbucks WiFi to the device at your home at 192.168.0.5 that has made no egress connections.

You’ll quickly find what you’re suggesting is nonsense. port address translation requires an entry to function. It’s not some optional security feature. It’s required information to get the packet header rewritten to reach private devices.

You can't get a packet from a random store wifi network to your home network when your home network is using 192.168.* (barring something like routing headers, which most routers wouldn't process). You said that yourself in the first part of your post, and I don't think I ever argued otherwise.

> Symmetric NAT 100% stops inbound unsolicited connections to the public IP

No, it doesn't. If it did it wouldn't be possible for routers to accidentally make their web admin or UPnP interfaces available to the Internet.

It doesn't stop connections to your router, and it doesn't stop connections through your router either. It just plain doesn't stop connections, which is why it protects you from 0% of attackers.

You're using somewhat sloppy terminology that will confuse things. An IP packet can't be addressed both to 12.13.14.15 AND to 192.168.0.7.

The realistic attack here is that your ISP sends a packet with destination address 192.168.0.7 to the MAC of your router (the MAC that corresponds to 12.13.14.15). This is a realistic attack scenario if the device that your router connects directly to gets compromised (either by an attacker or by the ISP itself).

Getting a public route that would take packets destined for 192.168.0.7 to reach your router over the Internet is far more unlikely.

True, the frame is addressed to the router's hw interface but I'm talking to people who think NAT drops traffic so I figured keep it simple

But, yes, the ISP (or whoever has compromised/suborned/social engineered the ISP) is absolutely the main worry here and I don't understand how people are dismissing that so easily

> I don't understand how people are dismissing that so easily

Because that’s not where 99.9999% of attacks come from

Fire up a web server on a public ipv4 address and you’ll get hundreds of requests per day from bots probing endpoints for vulnerabilities. Same thing goes for weak passwords on an SSH endpoint.

No, the router will only forward it with specific implementations that don’t isolate routing tables between the external and internal. Or an easier approach is just a stateless ACL on the external interface. Neither are a stateful firewall.

First they will have to change their policy of only providing one IPv4 address per ONT connection. Then they will have to convince me to disable NAT on my router, disable the DHCP server on my router, and bridge the WAN port with the LAN block.

Meanwhile in IPv6 land the ISP provided router that my relative has came configured by default to hand out globally routable addresses from the ISP provided /64. Thankfully it also had a stateful firewall enabled by default so there was no difference in practice.

> First they will have to change their policy of only providing one IPv4 address per ONT connection. Then they will have to convince me to disable NAT on my router, disable the DHCP server on my router, and bridge the WAN port with the LAN block.

No. They may be able to directly reach your internal addresses with source addresses that are outside your internal ranges through the WAN interface. For example: if you use 10.0.0.0/24 internally, and your special secret webserver is at 10.0.0.2, I might be able to reach it from 10.1.0.1 through your router's WAN interface.

It doesn't matter what the public IP is: the WAN interface is the default route, Linux will forward the traffic unless something is explicitly configured to block it.

Even if outbound traffic on the WAN interface is unconditionally SNAT'd to the public IP, and the replies have the wrong source address/port, I can still use a promiscuous mode AF_PACKET socket to receive them and interact with the internal server (the destination address will be correct, so the L2 frame will be addressed to the attacker's MAC). Or even just install my own SNAT rule to rewrite them again for me, I suppose.

Some ISPs have multiple subscribers on the same L2 segment, it's possible they can do this to each other.

Of course, I'd imagine many consumer grade routers out there do block this, but I've personally seen some that don't.

Reply on news.ycombinator.com