Live data from Hacker News

I discovered thousands of open databases on AWS

infosecwriteups.com

21–30 of 75 posts

Re: I discovered thousands of open databases on AWS

#21

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

Re: I discovered thousands of open databases on AWS

#23
post #3

This same article was posted previously, so I will post the same response I posted on the other thread: Elasticsearch until recently did not nudge you to set up a username or password by default. I noticed the last time I installed it on a fresh instance that on completion of the install it gives you a warning about this and tells you what to do to set a password. That is a small improvement. Most people would not ha…

Secure defaults are super important, especially on complex systems as people will not want to mess with the out of the box configuration too much when setting things up.

One additional consideration is that the secure defaults should be usable, otherwise the tendency will be to just disable them entirely (think SELinux and how commonly that's turned off as the first action on server setup)

Re: I discovered thousands of open databases on AWS

#24

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

It's the kind of example that would make me uncomfortable to work with Docker / cloud things; I'm sure I could set up stuff within a day, but there's a lot of Things That You Should Happen To Know like this example that are easily missed - especially when you're in an environment where there's pressure on you to deliver, instead of a focus on doing things right.

Re: I discovered thousands of open databases on AWS

#25

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

isn't it a standard practice to keep databases in private subnet or behind security groups?

I even follow this standard rule for pet projects

Re: I discovered thousands of open databases on AWS

#26

I 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…

> As these articles keep reminding me, you only need to fake competence to management to get the green light.

Well, managers aren't scientists looking for truth. They are people running businesses that need to stay afloat and get stuff done. There's a lot of wiggle room there, mostly due to time pressure (from a charitable perspective, less charitable: also because of company politics).

Re: I discovered thousands of open databases on AWS

#27
post #10

Earlier quoted context omitted.

This same article was posted previously, so I will post the same response Don't repaste your own comments just because there's been a dupe.

Why not? I’m not saying people should do it, but what are the arguments against it?

(not gp) I would prefer having a link to the other post (as someone above provided) so the comments there can be read. Duplicating the comments means I see the same thing twice, or it means the previous replies to that comment are now obscured to me. Which of the two it is depends on whether I find the other post. Not a desirable situation imho.

Re: I discovered thousands of open databases on AWS

#28
post #6
post #2

Another great example why I love to use managed services / serverless services and not take care of security groups and NACLs

Interesting. The conclusion you draw from this differs wildly from my conclusion. Whenever I read stories like these, it seems clear to me that someone moved to the cloud in order to not have to care about security. The 'cloud does everything for you!'. Just like you imply in your answer that PaaS, the next level of abstraction, will solve all your security problems. This move, however, will inevitably lead to a situ…

It depends which kind of security and which provider.

I would trust Microsoft more on patches/configurations for an email system than something which is managed on premises. You need to have really good people to maintain a good level of security. Not only technically good, but also with a string cold management that will force updates even if it means the CEO will not get his maol for 15 minutes - and say that this is life and that the discussion i sover.

On top of that, MS would (I hope) install patches on their customer-facing systems in advance of an official patch release.

The above applies to the majority of large SaaS services.

Now when you have a "Platform", a hoster that requires you to bring in knowledge and not only data then it gets dangerous. You need to maintain the security of what you bring in. This can be an OS (your "Platform" provides VMs), or code (your "Platform" provides code runners). Unfortunately, when a company moves to the cloud, they sometimes forget to do this assessment and end up with monstrosities they installed themselves (which is not different, security wise, from having it on premises - augmente nu the 7B population that potentially has now access)

Re: I discovered thousands of open databases on AWS

#29

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

isn't it a standard practice to keep databases in private subnet or behind security groups? I even follow this standard rule for pet projects

I'm pretty sure that if you have no security group attached to an instance no traffic is allowed. And a new security group doesn't allow traffic from "everywhere" by default. You have to actively allow that.

Re: I discovered thousands of open databases on AWS

#30

I 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…

> you only need to fake competence to management

With so many 10x full-stack developers who're just looking to get sh done and clock out, it can't be otherwise. If managing a server becomes just another bullet point in a developer job, this is exactly what we get.

Sure I can deploy stuff, but you shouldn't trust me. Unfortunately many are not so honest or even aware of the complexity (unknown unknowns).

Post reply on HN