The reports about MongoDB security issues which we recently mentioned also caught the attention of Redis creator Salvatore Sanfilippo who posted a friendly reminder about securing your Redis installs and how, out-of-the-box, Redis has the same issues as a freshly installed MongoDB.
After the latest MongoDB drama about being exposed to the internet, I want to kindly remember our use base that it's the same for Redis, and:
- By default it listens to all the interfaces.
- By default authentication is turned off at all.
So, please, check right now if you have exposed Redis instances in the wild, and take appropriate actions.
Sanfilippo explains that Redis' out-of-the-box behavior was a conscious decision.
This was a design choice, since not doing this will not result in the resolution of the problem. Imagine for example by default we bind 127.0.0.1. This is what happens:
- People that use it the proper way, not accessible, have to figure how why the instance is not reachable from other hosts. Annoying.
- People not caring at all will eventually find, replace it with bind *, and expose on the internet for error like they do currently.
So at best it can reduce a bit the % of exposed instances but making good users paying for it in terms of "first experience" with the system. Not a good tradeoff IMHO.
The Compose View
These incidents do remind us that there is a tension between development and deployment when it comes to security. The reason that these, and other databases and applications, are quite so open when they are run out-of-the-box is so developers can get up and running with them quickly.
Anything that gets in the way of that, like a convoluted initial password configuration or selecting ports, gets in the way of the developer being sold on whatever technology is behind that setup process. If they can just "Sit in the seat, turn the key and go" all the better from a rapid development point of view. You have to remember that before you go to deploy your application, to make sure you aren't leaving any routes into your data. That includes making sure your database server is secure as well as the database on it and that you know what traffic should be arriving.
The danger lurking in the background though is that the "easy to start" process becomes embedded as "how to do it" and with the wall between development and operations becoming ever thinner, those "easy" practices seep through to operations and deployment. You don't want to be that company that left its customer data or live statistic visible on the internet because it had forgotten to check the database was locked down or, worse still, didn't have a process to carry out that kind of check.
It's one of the reasons why, when you deploy a Compose database for the first time, you'll already find it is locked down and isolated from the internet. Like that, it's up to you how you open your database's doors through explicit actions to enable access.
For example, Compose Redis users aren't using Redis out-of-the-box though. We have a TCP enabled proxy to encrypt communications between their client apps and their Redis server. To communicate requires a Redis password be passed over that encrypted channel to the server. For added control, you can use a whitelist to block connections from any IP address other than those you have specifically authorised.
There's enough things to worry about when you are launching your application; this is just one of the ways Compose tries to makes it a little bit easier.