That is why you configure your security groups properly.
I discovered thousands of open databases on AWS
31–40 of 75 posts
Re: I discovered thousands of open databases on AWS
#32> DevOps, Developers, and IT practitioners often misconfigure some of the following: Binding the socket on the wrong network interfaces. For example, listening to connections from 0.0.0.0/* — So it is visible to all network interfaces, instead of only the inner-network interface IP address (172.x.x.x) Binding to 0.0.0.0 is unfortunately the default for Docker. I wish it would have been different.
Even if you've firewalled you machine, Docker will happily open up the ports to the world, you have to run it with "--iptables=false" to stop it. I accidentally opened up a Redis test-instance to the world like this.
Is there any additional information on this?
Assuming I add a rule via
`iptables -I INPUT -s 123.123.123.123 -p tcp --dport 8080 -j DROP`
and on interface:port 0.0.0.0:8080 of the host is a container listening which got run as
`docker run -d -p 0.0.0.0:8080:8080 some/server:latest`
Will that container still be accessible to 123.123.123.132?
Re: I discovered thousands of open databases on AWS
#33> DevOps, Developers, and IT practitioners often misconfigure some of the following: Binding the socket on the wrong network interfaces. For example, listening to connections from 0.0.0.0/* — So it is visible to all network interfaces, instead of only the inner-network interface IP address (172.x.x.x) Binding to 0.0.0.0 is unfortunately the default for Docker. I wish it would have been different.
Even if you've firewalled you machine, Docker will happily open up the ports to the world, you have to run it with "--iptables=false" to stop it. I accidentally opened up a Redis test-instance to the world like this.
Even better, docker-compose doesn't do IPV6 (well). But if you have an IPV6 address, it will NAT all the incoming IPV6 traffic on the open ports to IPV4 using the internal network gateway address.
So, if you're doing any filtering for internal network addresses == internal traffic, congratulations, now your inbound external IPV6 traffic is recognized as internal.
Re: I discovered thousands of open databases on AWS
#34Earlier quoted context omitted.
Even if you've firewalled you machine, Docker will happily open up the ports to the world, you have to run it with "--iptables=false" to stop it. I accidentally opened up a Redis test-instance to the world like this.
Is there any additional information on this? Assuming I add a rule via `iptables -I INPUT -s 123.123.123.123 -p tcp --dport 8080 -j DROP` and on interface:port 0.0.0.0:8080 of the host is a container listening which got run as `docker run -d -p 0.0.0.0:8080:8080 some/server:latest` Will that container still be accessible to 123.123.123.132?
I think so, this has been discussed in many HN threads and it always surprises a lot of people how big of a hole this is. I was certainly not aware of it the first time I read about it. Docker inserts its own iptables rules before your drop rule I think to handle its virtual interfaces.
Re: I discovered thousands of open databases on AWS
#35I used to think you have to be pretty good af your job to get trusted to deploy stuff to the cloud for even medium sized companies. As these articles keep reminding me, you only need to fake competence to management to get the green light. Even if you forget that the cloud is the internet and that the entire internet can reach you over the internet, it doesn't take a genius to set up a password for a cloud service. I…
"I suppose it's kind of liberating to know that you can be dumb enough to fling patient data into an unprotected cloud server and still get a job in IT. The bar is really set that low."
On the other hand, I would argue that there are way too many footguns hidden everywhere, like the default binding of docker mentioned here. So yes, a highly skilled IT security professional knows them all, but they are rare. And I think it should be possible to set things up securely in a straight forward way, for people with their speciality in other areas, of which there are plenty.
Re: I discovered thousands of open databases on AWS
#36From the article its main focus vulnerability seems to be setups that don't use VPCs, which is default on AWS since long. It discusses human oversights like a server that needs to accept connections from other servers and where they then have opened a too large IP block. But this only makes sense if they were using internet IPs.. within a VPC this wouldn't matter.
With some even rudimentary knowledge of how IPV4 works this wouldn't be an issue on AWS, there are good defaults and tools to help avoiding this, no matter if you run Dockerized databases or bare metal dbs or use RDS.. you really have to explicitly open up your servers to end up open on the net..
Re: I discovered thousands of open databases on AWS
#37> DevOps, Developers, and IT practitioners often misconfigure some of the following: Binding the socket on the wrong network interfaces. For example, listening to connections from 0.0.0.0/* — So it is visible to all network interfaces, instead of only the inner-network interface IP address (172.x.x.x) Binding to 0.0.0.0 is unfortunately the default for Docker. I wish it would have been different.
> Binding to 0.0.0.0 is unfortunately the default for Docker.
That isn't just a docker thing, though a few notable accidents with docker have shone a light on the issue in recent times, and is one of the reasons I much prefer to keep my firewall away from where things are running, between them and the unwashed masses on the public network.
Even at home I have a separate small firewall box between the server that hosts things (and the rest of my network) instead of trusting that host to manage its own security in that way. If I run a service via docker or anything else on there, the outside world doesn't see it unless I open a way in elsewhere. For extra paranoia, the network leg that others can connect to (wireless AP & wired network ports in the guest room) is also separate and only sees parts of the server(s) I explicitly want it to (you can do this with vlans and such depending on your kit, I've actually just got an extra NIC on the router).
Never assume a process/service/container/etc is at all locked down, unless you have checked it out yourself or have it sufficiently wrapped in things you have locked off.
Re: I discovered thousands of open databases on AWS
#38It's like the days of sa/no password all over again. Made easier because of the published CIDR blocks.
Re: I discovered thousands of open databases on AWS
#39> DevOps, Developers, and IT practitioners often misconfigure some of the following: Binding the socket on the wrong network interfaces. For example, listening to connections from 0.0.0.0/* — So it is visible to all network interfaces, instead of only the inner-network interface IP address (172.x.x.x) Binding to 0.0.0.0 is unfortunately the default for Docker. I wish it would have been different.
Even if you've firewalled you machine, Docker will happily open up the ports to the world, you have to run it with "--iptables=false" to stop it. I accidentally opened up a Redis test-instance to the world like this.
Strange, I've never seen this before. I've been running Docker for years on one of my pet project machines, but while Docker is exposing the ports on 0.0.0.0 my iptables firewall blocks all of them.
I'm not using --iptables=false but I'm not discounting the possibility that maybe I've configured this on a more global level somewhere.
Re: I discovered thousands of open databases on AWS
#40From the article its main focus vulnerability seems to be setups that don't use VPCs, which is default on AWS since long. It discusses human oversights like a server that needs to accept connections from other servers and where they then have opened a too large IP block. But this only makes sense if they were using internet IPs.. within a VPC this wouldn't matter. With some even rudimentary knowledge of how IPV4 work…
I think in a lot of cases folks still make certain things public instead of using a VPC out of convenience.
For example if a developer needs to access a resource within a VPC then this sky rockets complexity. You can't just connect to something running in a VPC from the outside world. You'd have to install and configure a VPN and it becomes a whole ceremony for both the person setting all of this up and the person connecting.
Using a VPC/VPN and keeping your important things internal (like a database or staging environment, etc.) is a really good idea but unless you have someone who has a really solid understanding of this it's a whole lot easier to make something public, restrict a security group by IP and keep a whitelist of IPs up to date for developer access.