Because you're completely wrong; what you're advocating is nothing more than security by obscurity. An address is just an address; it tells you where something is. If you don't have a firewall in place, then any attacker who cares enough to actually route a packet to your internal servers can access them. If you do have a firewall in place, then an attacker gains nothing from knowing the address of a server they can't send any packets to. Private networks add a huge amount of complexity with its own security holes (they're easy to scan once you're inside them, a lot of operating systems treat them as somehow "safer" than the public internet...). They do more harm than good.
> You realize you can’t get to a private IP address over the Internet right?
Of course you can - most end users have private IP addresses these days, yet they somehow manage to communicate with people on the internet.
A private IP address is of course not routable directly on the Internet. But routers route, and can certainly route a packet from the public internet to an RFC 1918 private address. If the routers on the edge of your RFC1918 network do not have firewalls in place, then they will happily route packets to your internal servers and you're no better off (against a serious attacker; a script kiddie might ignore you as too much effort, sure) than if you used public addresses. If those routers do have firewalls in place, then you're also no better off than if you used public addresses.
In the case of the attack in question - how would they have initiated a command to erase the ElasticSearch cluster from the Internet?
Any NAT would be stateful and the communication would have had to be initiated from the cluster.
Not having a public IP address is not about “obscuring” the IP address. It’s not like so said why didn’t they have ES listening on a non standard port.
> Any NAT would be stateful and the communication would have had to be initiated from the cluster.
Only if the router is configured that way - and you don't need NAT to configure it like that. If the router is open then you just set the destination address to the address of the server you want it to go to. (As for getting it to the router you either find a way onto the same segment, explicitly specify it as a routing hop, use ip-in-ip...).
NAT is not a security mechanism. Often the same device does both, but they are separate functions.
> Not having a public IP address is not about “obscuring” the IP address. It’s not like so said why didn’t they have ES listening on a non standard port.
Only if the router is configured that way - and you don't need NAT to configure it like that. If the router is open then you just set the destination address to the address of the server you want it to go to. (As for getting it to the router you either find a way onto the same segment, explicitly specify it as a routing hop, use ip-in-ip...).
So if someone purposefully for some reason goes in and configures their router to map a port to a specific internal IP address to allow internet traffic to their ES cluster it isn’t secure? Isn’t that kind of stretch? If I posted the root credentials to my AWS account and turned off MFA that would be insecure also. Does that also mean I’m depending on “security through obscurity”?
It's exactly like that!
So am I also “obscuring” my IP address when I am testing an API locally and I configure it to only listen on 127.0.0.1:3000? Oh no, I just told you my IP address!
Everything you mentioned could only be done if an inside malicious actor purposefully made it insecure.
> So if someone purposefully for some reason goes in and configures their router to map a port to a specific internal IP address to allow internet traffic to their ES cluster it isn’t secure?
That's not what I'm talking about. Suppose your router receives a packet whose destination is that internal IP address. Then it's going to send it there, unless it's configured to block that traffic.
> So am I also “obscuring” my IP address when I am testing an API locally and I configure it to only listen on 127.0.0.1:3000?
No, quite the opposite. Listening only on the loopback interface is a real security mechanism. Binding to 127.0.0.1 achieves that (though there have been bugs in the past; binding explicitly to the loopback device is better).
> Oh no, I just told you my IP address!
That's exactly my point! The address doesn't matter, the actual network routing is what matters. Same thing if you're running an actual airgapped network: what makes it safe is the fact that it's physically disconnected, not that you used particular addresses on it.
Real-life example: the UK military's internal servers have real IP addresses in the 25.0.0.0 range. Probably some of them are insecure. But it doesn't matter because, even though they have public IP addresses, you have no way to send packets to those IP addresses, because they've got proper firewalling in place. It's no different from if they were running a private network - except that it means they don't have to mess around with NAT, if someone connects from a VPN they don't have to worry about address collisions.... IPv6 works the same way.
That's not what I'm talking about. Suppose your router receives a packet whose destination is that internal IP address. Then it's going to send it there, unless it's configured to block that traffic.
What router is set up by default to route traffic from the internet to a private IP address unless the traffic initiated from the private IP address? Someone would have to purposefully configure their router to do it.
Of course someone can purposefully configure an insecure system.
Any router designed for professional environments won't second-guess your networking setup. Either it will route everything by default or it will deny everything by default and route only those routes you've specifically added, but either way it's not going to do anything differently just because one side or the other is an RFC1918 private address.
I understand that. But, we are talking about defaults. The reason the exploits that this submission is talking about took place is because too many people didn’t change the defaults.
Assuming people took the sensible leap that private resources equal private IP address, they are not going to then go out of their way to configure their router to route their private resources.
As far as “route everything” how is it going to know how to route from a public IP address to your ES server unless you specifically tell it?
I’m sure no one who got hacked went out of their way to configure their router to make their ES cluster publicly accessible.
> Assuming people took the sensible leap that private resources equal private IP address, they are not going to then go out of their way to configure their router to route their private resources.
That works until you have a legitimate need to expose a few of those private IP addresses publicly (which is bound to happen sooner or later). It's a bad idea to rely on the same thing to carry two subtly different meanings - especially when one of them is security-critical.
> As far as “route everything” how is it going to know how to route from a public IP address to your ES server unless you specifically tell it?
The router knows how to reach the ES server (it has to be able to send packets to that server if it's providing that server's connection to the internet). So if someone on the outside does `route add <ES server> via <router>` (or, these days, slightly more sophisticated alternatives) then they have access to the ES server same as if it was just on the internet. A few years back this was a big source of vulnerabilities - organisations assumed that their servers were safe because they didn't have public addresses, but nothing was actually stopping people sending packets to those servers if they figured out (or guessed) what the addresses were.
I don't agree with the GP about "routers route" (at least in the context of a cloud VPC), but a more serious problem that IS seen all the time in the wild is SSRF, and as I understand it elastisearch presents an HTTP REST interface, which makes it a fine target for such attacks (where as, say, Postgres, will not accept HTTP connections).
Relying solely on routability for authorization means that you're authorizing everything that can route to it in any context. Maybe that's fine.
