Easy guide for Securing Redis Server

Shujat Husain
3 min readJul 20, 2021

--

Like any other application or server, Redis installations might also be susceptible to unauthorized access or intrusions, if we have not secured it properly. In this tutorial, we will focus on securing Redis server to avoid any unauthorized access or intrusions.

Redis is an open source, in-memory data structure store or a key-value store that can be used as a cache for application, as a database server or even as a message broker. In our previous tutorials, we have already discussed the installation & also setting up a master-slave like architecture for the Redis server.

Recommended Read: SysAdmin’s guide to REDIS CLI Commands

Also Read: How to install CouchDB (& GUI manager) on CentOS & Ubuntu

So let’s start this tutorial on securing Redis server,

1- Securing redis server installation with a password

This should be like the first thing you should do with your redis installation. To assign a password, open your configuration file,

Note:- This is the configuration file path for my installation, yours can be ‘/etc/redis/redis.conf’ or if you have a custom installation like mine, then go to that location.

# vim /usr/local/redis/6379.conf

And look for the parameter ‘requirepass’, we need to uncomment it & then assign a password,

requirepass test@9879

Once the changes have been made, restart the redis service to implement the changes made. Now to connect to redis-cli, you will have to enter the password. First, connect to redis-cli,

# redis-cli

Now provide the password,

127.0.0.1:6379> auth test#9897

That’s it. You will now be connected to redis-cli.

2- Securing redis server access to localhost only

So if you have not tinkered with your redis conf, this might be already done for you. Basically, by default, redis server is & should only accessible from the localhost. But if you have allowed access from other servers or public access, then you are in serious danger of breach.

To avoid that, open your redis configuration file,

# vim /usr/local/redis/6379.conf

Once you have opened the file, look for ‘bind’ parameter & change it to,

bind 127.0.0.1 ::1

Now save the file & exit. Now restart the redis service to implement the changes made.

3- Securing Redis server by renaming dangerous commands

Using this method, we can avoid any serious repercussions even if someone gains access to our redis server. Redis provides us a way to rename some of the dangerous commands like LUSHDB, FLUSHALL, KEYS, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, RENAME, and DEBUG. There are other commands as well that can be renamed but these are some of the dangerous ones. We can also disable any of these commands altogether if we don’t have use for them in our application.

So disabling a command is a similar process to renaming a command, for renaming, we will provide an alternate name for the command but for disabling it we will rename it to empty name or string.

To rename a command, open the configuration file,

# vim /usr/local/redis/6379.conf

Now under the ‘Security’ section, we can rename or disable a command. To disable a command, use the following example as reference,

rename-command FLUSHALL “”

For renaming a command, use the following example as reference,

rename-command FLUSHALL DELETEITALL

Here, we have renamed FLUSHALL command to DELETEITALL (Delete It All). Once changes have been made, save the file & restart the redis service to implement the changes. Now login to redis-cli & check the renamed commands.

So this was our guide on securing redis server. Please feel free to send in any questions, queries using the comment box below.

We are giving you exclusive deals to try Linux Servers for free with 100$ credit, check these links to claim your 100$,

DigitalOcean — 100$ free credit & Linode — 100$ free credit

Check some Exclusive Deals, HERE.

Also, check out DevOps Book You should read section.

--

--

Shujat Husain
Shujat Husain

Written by Shujat Husain

A TechEenthusiat who likes all new technologies & Gaming. Most of all love to write about Cloud & DevOPs & have my own blog as well (https://linuxtechlab.com).

No responses yet