Stop testing, start deploying your AI apps. See how with MIT Technology Review’s latest research.
Download now
share
Over the recent weeks there’s been an increase in the number of reports about NoSQL breaches in general, but also specifically in those relating to Redis. The latter is, in all likelihood, the aftermath of Salvatore Sanfilippo’s blog post “A few things about Redis security.” That particular post was only the spark that lit the fire – I’d argue that the seeds for the breaches were laid in the ground long ago. And they’re still there unless you do something about it. But before continuing with the story, there are 3 critical points and 1 important note that I want you to take away from this:
A note: if you’re using the Redis Enterprise Cluster or Redis Cloud, then you can rest assured that the servers have not been breached by this attack. While it is possible to create an unprotected Redis database with our solutions, the overwhelming majority of our users’ databases, direct and from PaaS partners alike, are using at least one of the security measures we provide (such as password protection, source IP/Subnet whitelists and SSL). Furthermore, because our solutions provide separate operational and functional interfaces, even an unprotected database is not vulnerable to the full extent of this type of attack. That said, if your database is unprotected then your data is still at risk and you really should do something about it (hint: set a password).
Back to the origins of the breaches. In his blog post, Salvatore summarizes Redis’ security model with his typically brutal honesty: “it’s totally insecure to let untrusted clients access the system, please protect it from the outside world yourself.” To demonstrate how insecure “totally insecure” actually is, Salvatore shows how an unprotected Redis database can be used to gain access to the server running it.
The important thing here is that if you’re using Redis you must not ignore security. Once Redis isn’t run in a sandboxed environment, it is up to you (or your Redis provider) to take the steps needed to secure it properly. Redis databases can be made appropriately secure – here is a documentation page to get you started on doing just that. The first step to securing your Redis is reading the documentation. Redis has great official docs (it’s not just me saying that – check around) and tons of other materials online.
Redis’ default password is set to none. Make sure to set it and set it to something non-trivial. Your security is only as good as the precautions you take.
The second step is really paying attention to the defaults. Trusting default values to work for you is like driving your car with your eyes closed and trusting the road to bend to your will. Unless the road is one that you fully control and have memorized, there’s little chance that you’ll get where you wanted to go. You would be wiser to keep your eyes open. When it comes to defaults, the only safe way to use them is know about them, which means – you guessed it – opening your eyes and reading their documentation or hiring a chauffeur.
Salvatore’s blog post was received only too well by the internets, initially inspiring “script kiddies” to crack unprotected servers for fun but eventually also being used for profit by professional cyber criminals. There also appears to be a white hacker (artist’s rendition) who sets passwords for unprotected servers. It is a shame that so much damage has been done but unless made public, this “vulnerability” would have stayed unnoticed by most and its consequences unknown. It wasn’t meant as a lesson, but we should learn from it not to take security for granted.
Future versions of Redis will include safer defaults (the release candidate for v3.2 that was released earlier today binds to 127.0.0.1 instead of 0.0.0.0 and RC2 will have a new protected-mode enabled by default) and perhaps even improved security mechanisms, but the responsibility for protecting the database will always be with the operator. If you’re operating your own Redis database in an environment that’s open to the outside world, you should review the security measures that you have in place and ensure that you’re protected. If you were using none, I recommended that you treat your server as suspect at the very least (nuke it and start from scratch if possible) – it is not unlikely that it was already breached.
