Basic Redis Security

Introduction

In this article we’ll be going over the basics of Redis security. We’ll discuss the recommended model that Redis recommends as well as a few measures you can take to implement them.

Only Access with Trusted Clients

Redis was designed to be only be accessed by trusted clients. Only your servers running Redis should be able to access it. It should not be accessible to the internet at large.

What this means for a typical web app?

If you have a web application and the front-end needs some data that is stored in Redis, a request won’t be made directly to Redis, but to the application’s back-end which will in turn get the data from Redis. This prevents the browser from having direct access to Redis. In this type of implementation your backend can take some precautions such as validating the user input before making a request to Redis.

Protection by Authentication

You can setup authentication in the configuration file redis.conf so that Redis only responds to queries from authorized users. Once you set this up a AUTH command with the password will be used to verify your credentials before your query is processed. The password that it must match is also stored in the redis.conf file.

No Encryption

Redis itself does not support data encryption. If you’re using Redis correctly your Redis is being accessed locally and is not being sent over the wire and so you shouldn’t need encryption.

Renaming Commands

A common security measure in Redis is to rename commands that can do be used to do major damage. For example you could rename the CONFIG command to something obscure like this:

File: redis.conf

Now even if any hackers somehow gained access to Redis they still would not be able to use the CONFIG command without knowing it. You might want to protect the FLUSHALL command also because it deletes your entire data set.

Disabling Commands

Similarly to renaming you can disable a command by using the rename-command and providing an empty string as the name. For example you could disable the CONFIG command like this:

File: redis.conf

Binding to Localhost

As we stated before the only servers accessing Redis should be the clients that are running Redis. So by default Redis is only accessible via localhose (127.0.0.1) but if you have changed this than you could have opened up a way for unauthorized users to gain access to your Redis instance.

To make sure your instance is bound to localhost you can find your redis.conf file which is typicall in /etc/redis/redis.conf and make sure that the following line is uncommented:

Attacks to Watch Out For

Watch out for DoS Attacks

Hackers can also use the system the way it’s intended to be used and still cause problems. If they know some form is putting all it’s data into Redis and there is no limit on the text put into the form, they can put large amounts of data into the form and overwork Redis which could eventually result in a slow service or a complete disruption.

Worst Case Attacks

There is a type of attacks that again tries to overwork Redis by giving it some worst case scenario data.

NoSQL Injection

Redis doesn’t do string escaping so NoSQL injection is possible, although hopefully your backend is taking some precautions before sending requests to Redis.

Does it Lack Security?

Redis was built for speed, not safety. But if you have it setup up properly and you only have trusted clients accessing it then your data should be safe.

Conclusion

In this article we discussed the security model that Redis recommends. Remember that it should only accessed by trusted clients. We also discussed some types of attacks that Redis is susceptible to and some safety precautions you can take.

If you’re concerned about the security of your database please don’t hesitate to ask us. We’re experts at setting up and managing production data and we love it when people ask us about it.