> 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.
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.