Amazon Web Services (AWS) sponsored this post.
Trend Micro recently reported that “8,000 Redis instances […] are running unsecured in different parts of the world, even ones deployed in public clouds.” But that’s not the real story. Trend Micro is careful to point to official Redis documentation which stresses that “Redis is designed to be accessed by trusted clients inside trusted environments.” So it’s not a good idea to leave such servers directly connected to the Internet, nor to “an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.”
Yet clearly these best practices sometimes go unheeded. Across the broad array of open source software, stories routinely surface about security breaches caused by unsecured software — usually caused by misconfigured permissions. This isn’t because the software itself is inherently insecure, nor is it because associated vendors aren’t smart with security. It’s because we humans are not always very good about applying correct configurations or investing the effort to secure our software, open source or otherwise.
But that’s OK, because there’s an incredibly easy solution to TCP port-compromised Redis servers and countless other security issues in open source software: run a fully managed service.
Push the Easy Button
But first, let’s be clear: Redis has never been more secure. Commenting on the Trend Micro report, Redis Labs’ Itamar Haber pointed out that the “[8,000] number is substantial, but it demonstrates a constant, if not declining, number of exposed servers overall.” Each Redis release has resulted in a dwindling number of unsecured Redis servers, with the 4.0 release introducing protected mode — which has dramatically improved the default Redis security.
This is fantastic but it’s arguably not even the most significant set of security improvements for Redis. As Haber goes on to suggest, “managed service provided by Redis Labs is secure out of the box and eliminates the need for users to figure out their own security practices.”
Yes, that’s right. The easiest answer to Redis security issues, such as TLS not being on by default or no password being set, is just two words long: managed service. The Redis Labs service, for example, fixes these problems out of the box.
If you’re Redis-inclined (and you probably are — the official Redis Docker Hub image has registered more than 1 billion downloads to date), you’re spoiled for choice. Redis Labs offers a fully managed Redis service. So do Aiven, DigitalOcean, and others — including Amazon Web Services (AWS). Does this mean I’m biased? Of course. After all, I work for AWS and we offer managed services for Redis (Amazon Elasticache), Apache Kafka (Amazon MSK), and other open source projects. Would I love for you to use them? Yep.
But I’m actually more concerned that you use something — anything — that keeps your data secure.
As mentioned, this isn’t just a Redis thing. Perhaps you’ve read about MongoDB security issues, like those reported in Naked Security. MongoDB has offered the ability to close off remote access since version 2.6, and has turned this on by default since version 3.6. Does this mean MongoDB will not get hacked? No, because the company (correctly, in my view) tries to balance user freedom with security. As a MongoDB spokesperson told Naked Security, “we believe setting localhost by default puts users in a mode where they have to make a conscious decision about their own appropriate path to network safety.”
Or, you know, developers could run Atlas, MongoDB’s managed service. Problem: solved.
Open Source Doesn’t (Have to) Mean ‘Open Door’
Freedom is the bedrock foundation of open source software. From the earliest days of (free and) open source software, the most basic rights have been: “First, the freedom to copy a program and redistribute it to your neighbors, so that they can use it as well as you. Second, the freedom to change a program, so that you can control it instead of it controlling you…”. Later this was articulated by Richard Stallman as “the Four Freedoms,” and a separate group of developers articulated the Open Source Definition (OSD), which outlined its own essential set of freedoms.
While neither the Four Freedoms nor the OSD established a “right to misconfigure open source to make it insecure,” that “freedom” has been inadvertently embraced by far too many developers.
Within open source — and, yes, also within AWS — a core tenet is to allow developers the flexibility to change our default configurations to suit whatever style of application they’re constructing. As is the case with running software on-premises or anywhere else, when a new access control configuration is set, developers should ensure that it protects access the way that they intended. Clearly, however, many developers don’t do this, unwittingly opening the door to security breaches.
So let’s make this simple: run open source as a managed service and stop worrying about patching, configuration errors, etc. Whatever the open source software — be it Apache Kafka, Redis, MySQL, or many, many others — odds are good that you can get it as a managed service. Odds are also good that, when you do, you won’t have to worry about headlines like “More Than 8,000 Unsecured Redis Instances Found in the Cloud,” because yours won’t be among them.
MongoDB and Redis are sponsors of InApps.
Feature image via Pixabay.
InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
