I'm working on a personal project and not at all related to my work. I accidentally kept ports open :facepalm, sorting things out now :)
It's a lot more work when doing it in the cloud and spinning up these things from docker containers in K8S...but you're entirely to blame if you don't know what you're deploying and don't understand any of the potential threats.
What the parent post said is pretty much it in a nutshell, but I use that GitHub for basic Ubuntu server setup.
For reference, the standard practice in a company is to have a (third) separate subnet for databases, with zero internet access (no NAT gateway). Connection must be explicitly opened from/to database clients. It's a nightmare to manage on premise but it works really well in the cloud with firewalls allowing traffic based on instance tags.
This is very good advice. We recently had a uni project where we had to use a MongoDB database. Somebody just apt-get installed a mongodb onto a DO droplet called it a day. Two days later the only remaining records prompted us to transfer x amount of BTC to a adress that was store in our DB. It just contained dummy data, but it is worrying that something like this apparently happens to lots of companies as well.
The only thing I find weird is that ElasticSearch itself does not offer a way to handle authentication, it was just enabled by a plugin that was paid (it seems like its free now).
Just block access to it on your firewall to the public ports and require people SSH or VPN for access if needed.
It’s not
"Wierd" is an interesting euphemism for "irresponsible." Defaults are very important. Insecure by default is insecure for 90+% of deployments.
I have a bunch of fairly important personal documents in a filing cabinet with no lock. And I'm perfectly fine with that. I wouldn't keep it in my front yard, because that's obviously stupid, but keeping it inside behind my locked door and upstairs in my office? A perfectly acceptable risk (for me and my files).
I do agree that ElasticSearch do a quite poor/irresponsible job of pointing out their cabinet has no lock. I think Redis do a better job, but are seriously let down by all the internet tutorials that just say "sudo yum install redis" as a minor intermediate step in getting example-todo-list-de-jour working - without even a footnote explaining that anybody who actually visited the redis site now has instructions on how to p0wn your box. ( http://antirez.com/news/96 ) I do think the "Securing Redis" section of this page - https://redis.io/topics/quickstart - deserves to be much closer to the top - I'd have put it before the how to download/install/start instructions myself (though I _think_ recent versions of redis only bind to localhost in the default config, maybe?)
Change them.
Cave ne recipiens donum...
The vendor / developer has both awareness and capability to ensure this.
If the default install does this, then I'd blame the package /distro maintainers. It should definitely at least only listen on localhost by default, with stern warnings what is going to happen if you change that without setting up proper security.
Most of our services were created like a POC & deployed to production, & I joined my company fairly recently.
We had a planned release this week to secure ES. And Saturday, we got "meow"ed
note: the DO tutorial will hold your hand a little; the hardening doc expects a (minor) degree of familiarity
I don't see anything about subnets in there though. Did I miss something?
It's not though. Subnetting and firewalling are like the foundation of any corporate network.