8 ms·
Secure your MongoDB, Redis, etc
- statictype 10y agoWhat about data in motion? Is it viable to use an SSH tunnel with each service listening on localhost alone and using an encrypted tunnel to send data?
- mikegioia 10y agoThat's what the firewall is for. I set up iptables rules on all machines that only allow fixed IPs on the local network access to specific ports. If you're running it over the public 'net, then I think Mongo and Redis allow for username/passwords and/or encrypted transit.
- tostaki 10y agoNo it's not. It's secure but not reliable, your ssh tunnel will disconnect at some point. Use firewall and/or native security.
- statictype 10y agoThanks! I read somewhere that this was a good way to secure redis for compliances. Good to know it may not always work.
- igama 10y agoHave a read of the Internet Security Exposure report by @binaryedgeio, there is a section regarding Data Storage, mentioning Mongo, Redis, ElasticSearch, and some other. In Summary, it was found 627.7 TB of Data Exposed. http://blog.binaryedge.io/2016/10/07/internet-security-exposure-2016/ http://blog.binaryedge.io/2016/10/07/internet-security-expos...
- mwpmaybe 10y agostunnel. It's an incredible piece of software.
- JTenerife 10y agoDo you have any thoughts / experience compared to spiped or ipsec? The author or Redis likes spiped: https://redis.io/topics/encryption https://redis.io/topics/encryption
- mwpmaybe 10y agoThat's an excellent question. I've only ever used stunnel and I was blown away by how many different things it can do / ways it can work. It does so much for such a simple tool. antirez probably likes spiped because it does fewer things. :)
- diafygi 10y agoIs using spiped viable for redis connections? Can all the servers that need to connect to the redis server all connect via spiped using the same secret key?
- joneholland 10y agoYour database should not run on a server that has a public ip. Forget authentication (it's plaintext on redis), or binding rules, or using a uncommon port. It's network isolation or you will be owned.
- agotterer 10y agoIn this day and age with breaches happening daily and publicly why hasn't mongo taken security seriously and enabled authentication by default?
- stefano 10y agoMaybe that would hurt their "get started easily" proposition, which was very imporant to get them where they are now.
- bryanrasmussen 10y agoyeah but now they're there, with a big built in base of people who don't want to stop selling their skills. So they can make a new get started securely proposition.
- dexterdog 10y agoBut it's always "grow or die"
- raverbashing 10y agoThis might be useful https://docs.mongodb.com/v3.2/administration/security-checklist/ https://docs.mongodb.com/v3.2/administration/security-checkl... (But let's say binding on 0.0.0.0 or not having a firewall in the system are not only their fault) In the same way people can trust local addresses in Pgsql
- deleted 10y ago[deleted]
- user5994461 10y agoOr why is it so hard to enable authentication at all? Or why enable flags that allow to loose data without warnings in many common circumstances? Don't expect anything from mongo. Don't trust mongo. Don't use mongo.
- 10y ago
- lukaslalinsky 10y agoIs this the result of the no-ops movement? Did people forget how to deploy software? I find it hard to believe somebody would run a database on publicly accessible ip/port.
- SCHiM 10y agoFor some reason redis thinks it's a good idea to listen on all interfaces by DEFAULT so you can perhaps understand why this happens. But I mean come on, what year is this. How often do we need to repeat that you need to use SECURE DEFAULTS! Short of that I find redis an nice piece of software, I only wish it was somewhat more sane in its default configuration.
- an_d_rew 10y agoIn theory I totally agree with the concept of using secure defaults. In practice, however, I have seen far too many developers spend hour after hour trying to unwind a byzantine labyrinth of iptables and strange network configurations, weird firewall rules and corporate policies, never mind mangled DNS, to think that the correct solution is merely "secure defaults". At the end of the day, developers get paid to "make it work" and unfortunately that strongly incentivizes the "open by default" configuration mindset.
- mtgx 10y agoMaybe developers should get paid "not to put us in the headlines with 1 billion accounts breached".
- user5994461 10y agoMaybe developers should care about not having their companies in the headlines instead of just pushing things out as quickly as possible.
- cookiecaper 10y agoMost developers past a certain seniority level know better than to run on a production database on a public interface without at least setting up good authentication. I think in many cases, it's just an issue of something slipping through the cracks. A few example scenarios where this can happen: one may open a port temporarily in testing before something goes live and forget to close it back up. Legacy applications may be dependent on certain services at certain ports and it may not be trivial to change those, or even add authentication to them. The whitelist rules allowing communication can get mangled or misconfigured, especially if the legacy application's IP jumps around; in frustration, an admin may set the rules too wide to try to encompass all potential IPs, assuming that no one in the same /16 is going to try to break in soon and they'll come back and fix this in like a week or something. One may spin up a test instance into a wide-open security group and assume that someone else is going to come through and sweep it up, and before you know it that test instance is hosting real data and no one has tried to clamp it down, or that firewall rules for that port are not necessary because the authentication/whitelisting will occur on the software side, and then fail to set that up correctly, or run an insecure version of the software. There's that old saying: "A person isn't stupid; people are". The constraints of the business often make it so that compromises have to be made and what we'd consider a "good solution" is politically intractable. No one likes that, but it's the environment many of us have to work in, like it or not. All we can do is scream at the wall until at least one exec goes through a traumatic security event. It usually takes a significant breach to scare the exec team straight.
- cannonpr 10y agoHaving been the first 'DevOps' guy to hit the ground in a few startups I have seen interesting deployment and access strategies to databases PHP exec("echo $mysql_query | mysql -uadmin -ppassword"); is probably my favourite. For a lot of frontend or fullstack teams, the business shouting, get it done, trumps any damage they might take by a compromise. Also often they are just not aware of how insecure the defaults are, I feel like a lot more can be done to provide secure out of the box stacks for 'full stack' developers.
- paulddraper 10y agoProbably. Feel free to provide concrete examples. --- FYI, there isn't a security vulnerability in that wretched example... just WTFibility. (I'm assuming shell escaping...else virtually every query wouldn't work.)
- technion 10y agoI'm staring down the barrel of a startup that "deploys" using an Internet accessible, passwordless Samba share to drag and drop PHP files from desktops to production. Nothing surprises me.
- nodesocket 10y agoThe main problem is DigitalOcean does not offer a centralized firewall, so they assume users will and can setup iptables. If they had a centralized firewall and default policy of all inbound traffic blocked and then you specifically open ports on droplets it would make a huge difference.
- ak2196 10y agoOk. Repeat after me, "I will not use Digital Ocean for production. They are not a real hosting company." The why is left as an exercise for the reader.
- user5994461 10y agoUse Digital Ocean for simple production use cases. They are a real hosting company, they are affordable and they are simple to use. Professional non-trivial usage should be on AWS/Google/Azure/SoftLayer.
- ak2196 10y agoBzzzt! Wrong answer, try again. They are not good for anything remotely resembling production. Since your production should try and closely resemble everything else I'd say they are not good for anything at all. The tag line is "Cloud computing, designed for developers." They should be even more careful about good practices and sound design keeping in mind the kind of customer they are trying to get. Over the years they have done anything but that.
- user5994461 10y agoThey are perfectly fine for anything production resembling a guy that wants to run 2 servers on the internet. And they're certainly better than trying to run that on someone's home DSL connection.
- ak2196 10y ago