[Redis](https://redis.io/) is an in-memory key-value database known for its flexibility, performance, and wide language support. These tutorials demonstrate how to install, configure, and secure Redis on specific Linux distributions. Choose your distribution below to get started.

CentOS

###Introduction

[Redis](https://redis.io/) is an open-source, in-memory data structure store which excels at caching. A non-relational database, Redis is known for its flexibility, performance, scalability, and wide language support.

Redis was designed for use by trusted clients in a trusted environment, and has no robust security features of its own. Redis does, however, have [a few security features](https://redis.io/topics/security) that include a basic unencrypted password and command renaming and disabling. This tutorial provides instructions on how to configure these security features, and also covers a few other settings that can boost the security of a standalone Redis installation on CentOS 7.

Note that this guide does not address situations where the Redis server and the client applications are on different hosts or in different data centers. Installations where Redis traffic has to traverse an insecure or untrusted network will require a different set of configurations, such as setting up an SSL proxy or a [VPN](https://www.digitalocean.com/community/tutorials/how-to-setup-and-configure-an-openvpn-server-on-centos-7) between the Redis machines.


##Prerequisites

To follow along with this tutorial, you will need:

* One CentOS 7 Droplet configured using our [Initial Server Setup for CentOS 7](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-centos-7).
* Firewalld installed and configured using [this guide](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7), up to and including the “Turning on the Firewall” step. 

With those prerequisites in place, we are ready to install Redis and perform some initial configuration tasks.


##Step 1 — Installing Redis

Before we can install Redis, we must first add [Extra Packages for Enterprise Linux (EPEL) repository](https://fedoraproject.org/wiki/EPEL) to the server’s package lists. EPEL is a package repository containing a number of open-source add-on software packages, most of which are maintained by the Fedora Project. 

We can install EPEL using `yum`:

```command
sudo yum install epel-release
```

Once the EPEL installation has finished you can install Redis, again using `yum`:

```command
sudo yum install redis -y
```

This may take a few minutes to complete. After the installation finishes, start the Redis service:

```command
sudo systemctl start redis.service
```

If you’d like Redis to start on boot, you can enable it with the `enable` command:

```command
sudo systemctl enable redis
```

You can check Redis’s status by running the following:

```command
sudo systemctl status redis.service
```

```
[secondary_label Output]
● redis.service - Redis persistent key-value database
   Loaded: loaded (/usr/lib/systemd/system/redis.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/redis.service.d
           └─limit.conf
   Active: active (running) since Thu 2018-03-01 15:50:38 UTC; 7s ago
 Main PID: 3962 (redis-server)
   CGroup: /system.slice/redis.service
           └─3962 /usr/bin/redis-server 127.0.0.1:6379
```

Once you’ve confirmed that Redis is indeed running, test the setup with this command:

```command
redis-cli ping
```

This should print `PONG` as the response. If this is the case, it means you now have Redis running on your server and we can begin configuring it to enhance its security.


## Step 2 — Binding Redis and Securing it with a Firewall

An effective way to safeguard Redis is to secure the server it’s running on. You can do this by ensuring that Redis is bound only to either localhost or to a private IP address and that the server has a firewall up and running.

However, if you chose to set up a Redis cluster using [this tutorial](https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-centos-7), then you will have updated the configuration file to allow connections from anywhere, which is not as secure as binding to localhost or a private IP.

To remedy this, open the Redis configuration file for editing:

```command
sudo vi /etc/redis.conf
```

Locate the line beginning with `bind` and make sure it’s uncommented:

```
[label /etc/redis.conf]
bind 127.0.0.1
```

If you need to bind Redis to another IP address (as in cases where you will be accessing Redis from a separate host) we **strongly** encourage you to bind it to a private IP address. Binding to a public IP address increases the exposure of your Redis interface to outside parties.

```
[label /etc/redis.conf]
bind <^>your_private_ip<^>
```

If you’ve followed the prerequisites and installed firewalld on your server and you do not plan to connect to Redis from another host, then you do not need to add any extra firewall rules for Redis. After all, any incoming traffic will be dropped by default unless explicitly allowed by the firewall rules. Since a default standalone installation of Redis server is listening only on the loopback interface (`127.0.0.1` or localhost), there should be no concern for incoming traffic on its default port.

If, however, you do plan to access Redis from another host, you will need to make some changes to your firewalld configuration using the `firewall-cmd` command. Again, you should only allow access to your Redis server from your hosts by using their private IP addresses in order to limit the number of hosts your service is exposed to.

To begin, add a dedicated Redis zone to your firewalld policy:

```command
sudo firewall-cmd --permanent --new-zone=redis
```

Then, specify which port you’d like to have open. Redis uses port `6379` by default:

```command
sudo firewall-cmd --permanent --zone=redis --add-port=6379/tcp
```

Next, specify any private IP addresses which should be allowed to pass through the firewall and access Redis:

```command
sudo firewall-cmd --permanent --zone=redis --add-source=<^>client_server_private_IP<^>
```

After running those commands, reload the firewall to implement the new rules:

```command
sudo firewall-cmd --reload
```

Under this configuration, when the firewall sees a packet from your client's IP address, it will apply the rules in the dedicated Redis zone to that connection. All other connections will be processed by the default `public` zone. The services in the default zone apply to every connection, not just those that don't match explicitly, so you don't need to add other services (e.g. SSH) to the Redis zone because those rules will be applied to that connection automatically.

If you chose to [set up a firewall using Iptables](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-basic-iptables-firewall-on-centos-6), you will need to grant your secondary hosts access to the port Redis is using with the following commands:

```command
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp -s <^>client_servers_private_IP<^>/32 --dport 6379 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -P INPUT DROP
```

Make sure to save your Iptables firewall rules using the mechanism provided by your distribution. You can learn more about Iptables by taking a look at our [Iptables essentials guide](https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands).

Keep in mind that using either firewall tool will work. What’s important is that the firewall is up and running so that unknown individuals cannot access your server. In the next step, we will configure Redis to only be accessible with a strong password.


##Step 3 — Configuring a Redis Password

If you installed Redis using the [How To Configure a Redis Cluster on CentOS 7](https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-centos-7) tutorial, you should have configured a password for it. At your discretion, you can make a more secure password now by following this section. If you haven’t set up a password yet, instructions in this section show how to set the database server password.

Configuring a Redis password enables one of its built-in security features — the `auth` command — which requires clients to authenticate before being allowed access to the database. Like the `bind` setting, the password is configured directly in Redis's configuration file, `/etc/redis.conf`. Reopen that file:

```command
sudo vi /etc/redis.conf
```

Scroll to the `SECURITY` section and look for a commented directive that reads:

```
[label /etc/redis.conf]
# requirepass foobared
```

Uncomment it by removing the `#`, and change `foobared` to a very strong password of your choosing. Rather than make up a password yourself, you may use a tool like `apg` or `pwgen` to generate one. If you don't want to install an application just to generate a password, though, you may use the command below. 

Note that entering this command as written will generate the same password every time. To create a password different from the one that this would generate, change the word in quotes to any other word or phrase.

```command
echo "<^>digital-ocean<^>" | sha256sum
```

Though the generated password will not be pronounceable, it is a very strong and very long one, which is exactly the type of password required for Redis. After copying and pasting the output of that command as the new value for `requirepass`, it should read:


```
[label /etc/redis.conf]
requirepass <^>password_copied_from_output<^>
```

If you prefer a shorter password, use the output of the command below instead. Again, change the word in quotes so it will not generate the same password as this one:


```command
echo "<^>digital-ocean<^>" | sha1sum
```

After setting the password, save and close the file then restart Redis:

```command
sudo systemctl restart redis.service
```

To test that the password works, access the Redis command line:

```command
redis-cli
```

The following is a sequence of commands used to test whether the Redis password works. The first command tries to set a key to a value before authentication.

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

That won't work as we have not yet been authenticated, so Redis returns an error.

```
[secondary_label Output]
(error) NOAUTH Authentication required.
```

The following command authenticates with the password specified in the Redis configuration file.

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```


Redis will acknowledge that we have been authenticated:

```
[secondary_label Output]
OK
```

After that, running the previous command again should be successful:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

```
[secondary_label Output]
OK
```

The `get key1` command queries Redis for the value of the new key.

```custom_prefix(127.0.0.1:6379>)
get key1
```

```
[secondary_label Output]
"10"
```

This last command exits `redis-cli`. You may also use `exit`:

```custom_prefix(127.0.0.1:6379>)
quit
```

It should now be very difficult for unauthorized users to access your Redis installation. Please note, though, that without SSL or a VPN the unencrypted password will still be visible to outside parties if you’re connecting to Redis remotely.

Next, we'll look at renaming Redis commands to further protect Redis from malicious actors.


## Step 4 — Renaming Dangerous Commands

The other security feature built into Redis allows you to rename or completely disable certain commands that are considered dangerous. When run by unauthorized users, such commands can be used to reconfigure, destroy, or otherwise wipe your data. Some of the commands that are known to be dangerous include: 
* `FLUSHDB`
* `FLUSHALL` 
* `KEYS` 
* `PEXPIRE` 
* `DEL` 
* `CONFIG` 
* `SHUTDOWN` 
* `BGREWRITEAOF`
* `BGSAVE` 
* `SAVE` 
* `SPOP` 
* `SREM` 
`RENAME` 
`DEBUG` 

This is not a comprehensive list, but renaming or disabling all of the commands in that list is a good starting point.

Whether you disable or rename a command is site-specific. If you know you will never use a command that can be abused, then you may disable it. Otherwise, you should rename it instead.

Like the authentication password, renaming or disabling commands is configured in the `SECURITY` section of the `/etc/redis.conf` file. To enable or disable Redis commands, open the configuration file for editing one more time:

```command
sudo vi  /etc/redis.conf
```

<$>[note]
**NOTE**: These are examples. You should choose to disable or rename the commands that make sense for you. You can check the commands for yourself and determine how they might be misused at [redis.io/commands](http://redis.io/commands).
<$>

To disable or kill a command, simply rename it to an empty string, as shown below:


```
[label /etc/redis.conf]
# It is also possible to completely kill a command by renaming it into
# an empty string:
#
<^>rename-command FLUSHDB ""<^>
<^>rename-command FLUSHALL ""<^>
<^>rename-command DEBUG ""<^>
```

To rename a command, give it another name like in the examples below. Renamed commands should be difficult for others to guess, but easy for you to remember:

```
[label /etc/redis.conf]
rename-command CONFIG ""
<^>rename-command SHUTDOWN SHUTDOWN_MENOT<^>
<^>rename-command CONFIG ASC12_CONFIG<^>
```

Save your changes and close the file, and then apply the change by restarting Redis:


```command
sudo systemctl restart redis.service
```


To test the new command, enter the Redis command line:


```command
redis-cli
```
Authenticate yourself using the password you defined earlier:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```

```
[secondary_label Output]
OK
```

Assuming that you renamed the **CONFIG** command to **ASC12_CONFIG**, attempting to use the `config` command should fail.

```custom_prefix(127.0.0.1:6379>)
config get requirepass
```

```
[secondary_label Output]
(error) ERR unknown command 'config'
```

Calling the renamed command should be successful (it's case-insensitive):

```custom_prefix(127.0.0.1:6379>)
asc12_config get requirepass
```

```
[secondary_label Output]
1) "requirepass"
2) "your_redis_password"
```

Finally, you can exit from `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
exit
```

Note that if you're already using the Redis command line and then restart Redis, you'll need to re-authenticate. Otherwise, you'll get this error if you type a command:

```
[secondary_label Output]
NOAUTH Authentication required.
```

<$>[warning]
Regarding renaming commands, there's a cautionary statement at the end of the `SECURITY` section in the `/etc/redis.conf` file, which reads:

> 

```
[label /etc/redis.conf]
. . .

# Please note that changing the name of commands that are logged into the
# AOF file or transmitted to slaves may cause problems.

. . .
```

That means if the renamed command is not in the AOF file, or if it is but the AOF file has not been transmitted to slaves, then there should be no problem. Keep that in mind as you're renaming commands. The best time to rename a command is when you're not using AOF persistence or right after installation (that is, before your Redis-using application has been deployed).

When you're using AOF and dealing with a master-slave installation, consider this answer from the project's GitHub issue page. The following is a reply to the author's question:

> The commands are logged to the AOF and replicated to the slave the same way they are sent, so if you try to replay the AOF on an instance that doesn't have the same renaming, you may face inconsistencies as the command cannot be executed (same for slaves).

The best way to handle renaming in cases like that is to make sure that renamed commands are applied to all instances of master-slave installations. 
<$>

## Step 5 — Setting Data Directory Ownership and File Permissions

In this step, we'll consider a couple of ownership and permissions changes you can make to improve the security profile of your Redis installation. This involves making sure that only the user that needs to access Redis has permission to read its data. That user is, by default, the **redis** user.

You can verify this by `grep`-ing for the Redis data directory in a long listing of its parent directory. The command and its output are given below.


```command
ls -l /var/lib | grep redis
```

```
[secondary_label Output]
<^>drwxr-xr-x<^> 2 <^>redis   redis<^>   4096 Aug  6 09:32 redis
```

You can see that the Redis data directory is owned by the **redis** user, with secondary access granted to the **redis** group. This ownership setting is secure, but the folder’s permissions (which are set to 755) are not. To ensure that only the Redis user has access to the folder and its contents, change the permissions setting to 770:

```command
sudo chmod 770 /var/lib/redis
```

The other permission you should change is that of the Redis configuration file. By default, it has a file permission of 644 and is owned by **root**, with secondary ownership by the **root** group:

```command
ls -l /etc/redis.conf
```

```
[secondary_label Output]
<^>-rw-r--r--<^> 1 <^>root root<^> 30176 Jan 14  2014 /etc/redis.conf
```

That permission (644) is world-readable. This presents a security issue as the configuration file contains the unencrypted password you configured in Step 4, meaning we need to change the configuration file’s ownership and permissions. Ideally, it should be owned by the **redis** user, with secondary ownership by the **redis** group. To do that, run the following command:

```command
sudo chown redis:redis /etc/redis.conf
```

Then change the permissions so that only the owner of the file can read and/or write to it:

```command
sudo chmod 600 /etc/redis.conf
```


You may verify the new ownership and permissions using:


```command
ls -l /etc/redis.conf
```

```
[secondary_label Output]
total 40
<^>-rw-------<^> 1 <^>redis redis<^> 29716 Sep 22 18:32 /etc/redis.conf
```

Finally, restart Redis:

```command
sudo systemctl restart redis.service
```

Congratulations, your Redis installation should now be more secure!


## Conclusion

Keep in mind that once someone is logged in to your server, it's very easy to circumvent the Redis-specific security features we've put in place. This is why the most important security feature covered in this tutorial is the firewall, as that prevents unknown users from logging into your server in the first place.

If you're attempting to secure Redis communication across an untrusted network you'll have to employ an SSL proxy, as recommended by Redis developers in the [official Redis security guide](http://redis.io/topics/security).


This tutorial provides instructions for installing Redis on a CentOS 7 server and using its built-in security features, in coordination with some other security configurations, to keep it from being accessed by unauthorized users.

How To Install and Secure Redis on CentOS 7

How to Install and Secure Redis

Ubuntu

14.04

### Introduction

Redis is an in-memory, NoSQL, key-value cache and store that can also be persisted to disk.

This tutorial shows how to implement basic security for a Redis server.

However, keep in mind that Redis was designed for use by *trusted clients* in a *trusted environment*, with no robust security features of its own. To underscore that point, here's a quote from the [official Redis website](http://redis.io/topics/security):

> Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.

> . . .
 
> In general, Redis is not optimized for maximum security but for maximum performance and simplicity.

Performance and simplicity without security is a recipe for disaster. Even the few security features Redis has are really nothing to rave about. Those include: a basic unencrypted password, and command renaming and disabling. It lacks a true access control system.

However, configuring the existing security features is still a big step up from leaving your database unsecured.

In this tutorial, you'll read how to configure the few security features Redis has, and a few other system security features that will boost the security posture of a standalone Redis installation on Ubuntu 14.04.

Note that this guide does not address situations where the Redis server and the client applications are on different hosts or in different data centers. Installations where Redis traffic has to traverse an insecure or untrusted network require an entirely different set of configurations, such as setting up an SSL proxy or a [VPN](https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-14-04) between the Redis machines, in addition to the ones given here.

## Prerequisites

For this tutorial, you'll need:

- An Ubuntu 14.04 server with a sudo user added, from the [initial server setup](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04)

- iptables configured using [this iptables guide](https://www.digitalocean.com/community/tutorials/how-to-implement-a-basic-firewall-template-with-iptables-on-ubuntu-14-04), up through the **(Optional) Update Nameservers** step (if you don't do the nameserver configuration part, APT won't work). After configuring the nameservers, you're done

- Redis installed and working using instructions from the master-only installation from [this Redis guide](https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-ubuntu-14-04), up through the **Step 2 — Configure Redis Master** step

## Step 1 — Verifying that Redis is Running

First log in to your server using SSH:

```command
ssh <^>username<^>@<^>server-ip-address<^>
```

To check that Redis is working, use the Redis command line. The `redis-cli` command is used to access the Redis command line.

```command
redis-cli
```

<$>[note]
If you already set a password for Redis, you have to `auth` after connecting.

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```

```
[label Output]
OK
```
<$>

Test the database server:

```custom_prefix(127.0.0.1:6379>)
ping
```

Response:

```
[label Output]
PONG
```

Exit:

```custom_prefix(127.0.0.1:6379>)
quit
```

## Step 2 — Securing the Server with iptables

If you followed the prerequisites for iptables, feel free to skip this step. Or, you can do it now.

Redis is just an application that's running on your server, and because it has no real security features of its own, the first step to truly securing it is to first secure the server it is running on.

In the case of a public-facing server like your Ubuntu 14.04 server, configuring a firewall as given in [this iptables guide](https://www.digitalocean.com/community/tutorials/how-to-implement-a-basic-firewall-template-with-iptables-on-ubuntu-14-04) is that first step. **Follow that link and set up your firewall now.**

If you've implemented the firewall rules using that guide, then you do not need to add an extra rule for Redis, because by default, all incoming traffic is dropped unless explicitly allowed. Since a default standalone installation of Redis server is listening only on the loopback interface (127.0.0.1 or localhost), there should be no concern for incoming traffic on its default port.

If you need to specifically allow an IP address for Redis, you can check what IP address Redis is listening on, and what port it is bound to by `grep`-ing the output of the `netstat` command. The fourth column — **127.0.0.1:6379** here — indicates the IP address and port combination associated with Redis:


```command
sudo netstat -plunt | grep -i redis
```

```
[label Output]
tcp   0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      8562/redis-server 1
```

Make sure this IP address is allowed in your Firewall policy. For more information on how to add rules, please see this [iptables basics article](https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands).

## Step 3 — Binding to localhost

By default, Redis server is only accessible from localhost. However, if you followed the tutorial to set up a Redis master server, you updated the configuration file to allow connections from anywhere. This is not as secure as binding to localhost.

Open the Redis configuration file for editing:

```command
sudo nano /etc/redis/redis.conf
```

Locate this line and make sure it is uncommented (remove the `#` if it exists):

```
[label /etc/redis/redis.conf]
bind 127.0.0.1
```

We'll keep using this file, so keep it open for now.

## Step 4 — Configuring a Redis Password

If you installed Redis using the [How To Configure a Redis Cluster on Ubuntu 14.04](https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-ubuntu-14-04) article, you should have configured a password for it. At your discretion, you can make a more secure password now by following this section. If not, instructions in this section show how to set the database server password.

Configuring a Redis password enables one of its two built-in security feature - the `auth` command, which requires clients to authenticate to access the database. The password is configured directly in Redis's configuration file, `/etc/redis/redis.conf`, which you should still have open from the previous step.

Scroll to the `SECURITY` section and look for a commented directive that reads:

```
[label /etc/redis/redis.conf]
# requirepass foobared
```

Uncomment it by removing the `#`, and change `foobared` to a very strong and very long value.

Rather than make up a password yourself, you may use a tool like `apg` or `pwgen` to generate one. If you don't want to install an application just to generate a password, you may use the one-liner below. To generate a password different from the one that this would generate, change the word in quotes.

```command
echo "<^>digital-ocean<^>" | sha256sum
```

Your output should look something like:

```
[label Output]
960c3dac4fa81b4204779fd16ad7c954f95942876b9c4fb1a255667a9dbe389d
```

Though the generated password will not be pronounceable, it gives you a very strong and very long one, which is exactly the type of password required for Redis. After copying and pasting the output of that command as the new value for `requirepass`, it should read:


```
[label /etc/redis/redis.conf]
requirepass <^>960c3dac4fa81b4204779fd16ad7c954f95942876b9c4fb1a255667a9dbe389d<^>
```

If you prefer a shorter password, use the output of the command below instead. Again, change the word in quotes so it will not generate the same password as this one:


```command
echo "<^>digital-ocean<^>" | sha1sum
```

You'll get somewhat shorter output this time:

```
[label Output]
10d9a99851a411cdae8c3fa09d7290df192441a9
```

After setting the password, save the file, and restart Redis:

```command
sudo service redis-server restart
```

To test that the password works, access the Redis command line:

```command
redis-cli
```


The following output shows a sequence of commands used to test whether the Redis password works. The first command tries to set a key to a value before authentication.

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

That won't work, so Redis returns an error.

```
[label Output]
(error) NOAUTH Authentication required.
```

The second command authenticates with the password specified in the Redis configuration file.

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```


Redis acknowledges.

```
[label Output]
OK
```

After that, re-running the previous command succeeds.

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

```
[label Output]
OK
```

`get key1` queries Redis for the value of the new key.

```custom_prefix(127.0.0.1:6379>)
get key1
```

```
[label Output]
"10"
```

The last command exits `redis-cli`. You may also use `exit`:

```custom_prefix(127.0.0.1:6379>)
quit
```

Next, we'll look at renaming Redis commands.

## Step 5 — Renaming Dangerous Commands

The other security feature built into Redis allows you to rename or completely disable certain commands that are considered dangerous.

When run by unauthorized users, such commands can be used to reconfigure, destroy, or otherwise wipe your data. Like the authentication password, renaming or disabling commands is configured in the same `SECURITY` section of the `/etc/redis/redis.conf` file.

Some of the commands that are known to be dangerous include: **FLUSHDB**, **FLUSHALL**, **KEYS**, **PEXPIRE**, **DEL**, **CONFIG**, **SHUTDOWN**, **BGREWRITEAOF**, **BGSAVE**, **SAVE**, **SPOP**, **SREM**, **RENAME** and **DEBUG**. That's not a comprehensive list, but renaming or disabling all of the commands in that list is a good starting point.

Whether you disable or rename a command is site-specific. If you know you will never use a command that can be abused, then you may disable it. Otherwise, rename it.

To enable or disable Redis commands, open the configuration file for editing one more time:

```command
sudo nano  /etc/redis/redis.conf
```

**These are examples. You should choose to disable or rename the commands that make sense for you.** You can check the commands for yourself and determine how they might be misused at [redis.io/commands](http://redis.io/commands).

To disable or kill a command, simply rename it to an empty string, as shown below:


```
[label /etc/redis/redis.conf]
# It is also possible to completely kill a command by renaming it into
# an empty string:
#
<^>rename-command FLUSHDB ""<^>
<^>rename-command FLUSHALL ""<^>
<^>rename-command DEBUG ""<^>
```

And to rename a command, give it another name, as in the examples below. Renamed commands should be difficult for others to guess, but easy for you to remember. Don't make life difficult for yourself.


```
[label /etc/redis/redis.conf]
rename-command CONFIG ""
<^>rename-command SHUTDOWN SHUTDOWN_MENOT<^>
<^>rename-command CONFIG ASC12_CONFIG<^>
```

Save your changes.

After renaming a command, apply the change by restarting Redis:


```command
sudo service redis-server restart
```


To test the new command, enter the Redis command line:


```command
redis-cli
```


Then, assuming that you renamed the **CONFIG** command to **ASC12_CONFIG**, the following output shows how to test that the new command has been applied.

After authenticating:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```

```
[label Output]
OK
```

The first attempt to use the `config` command should fail, because it has been renamed.

```custom_prefix(127.0.0.1:6379>)
config get requirepass
```

```
[label Output]
(error) ERR unknown command 'config'
```

Calling the renamed command should be successful (it's case-insensitive):

```custom_prefix(127.0.0.1:6379>)
asc12_config get requirepass
```

```
[label Output]
1) "requirepass"
2) "your_redis_password"
```

Finally, you can exit from `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
exit
```

Note: If you're already using the Redis command line and then restart Redis, you'll need to re-authenticate. Otherwise, you'll get this error if you type a command:

```
[label Output]
NOAUTH Authentication required.
```

<$>[warning]
Regarding renaming commands, there's a cautionary statement at the end of the `SECURITY` section in `/etc/redis/redis.conf` which reads:

> `Please note that changing the name of commands that are logged into the AOF file or transmitted to slaves may cause problems.`

That means if the renamed command is not in the AOF file, or if it is but the AOF file has not beeen transmitted to slaves, then there should be no problem.

So, keep that in mind when you're trying to rename commands. The best time to rename a command is when you're not using AOF persistence, or right after installation, that is, before your Redis-using application has been deployed.

When you're using AOF and dealing with a master-slave installation, consider this answer from the project's GitHub issue page. The following is a reply to the author's question:

> The commands are logged to the AOF and replicated to the slave the same way they are sent, so if you try to replay the AOF on an instance that doesn't have the same renaming, you may face inconsistencies as the command cannot be executed (same for slaves).

So, the best way to handle renaming in cases like that is to make sure that renamed commands are applied to all instances in master-slave installations. 
<$>

## Step 6 — Setting Data Directory Ownership and File Permissions

In this step, we'll consider a couple of ownership and permissions changes you can make to improve the security profile of your Redis installation. This involves making sure that only the user that needs to access Redis has permission to read its data. That user is, by default, the **redis** user.

You can verify this by `grep`-ing for the Redis data directory in a long listing of its parent directory. The command and its output are given below.


```command
ls -l /var/lib | grep redis
```

```
[label Output]
<^>drwxr-xr-x<^> 2 <^>redis   redis<^>   4096 Aug  6 09:32 redis
```

You can see that the Redis data directory is owned by the **redis** user, with secondary access granted to the **redis** group. That part is good.

The part that's not is the folder's permissions, which is 755. To ensure that only the Redis user has access to the folder and its contents, change the permission to 700:

```command
sudo chmod 700 /var/lib/redis
```

The other permission you should change is that of the Redis configuration file. By default, it has a file permission of 644 and is owned by **root**, with secondary ownership by the **root** group:

```command
ls -l /etc/redis/redis.conf
```

```
[label Output]
<^>-rw-r--r--<^> 1 <^>root root<^> 30176 Jan 14  2014 /etc/redis/redis.conf
```

That permission (644) is world-readable, which is not a good idea, because it contains the unencrypted password configured in Step 4.

We need to change the ownership and permissions. Ideally, it should be owned by the **redis** user, with secondary ownership by the **root** user. To do that, run the following command:


```command
sudo chown redis:root /etc/redis/redis.conf
```

Then change the ownership so that only the owner of the file can read and/or write to it:

```command
sudo chmod 600 /etc/redis/redis.conf
```


You may verify the new ownership and permission using:


```command
ls -l /etc/redis/redis.conf
```

```
[label Output]
total 40
<^>-rw-------<^> 1 <^>redis root<^> 29716 Sep 22 18:32 /etc/redis/redis.conf
```

Finally, restart Redis:

```command
sudo service redis-server restart
```

## Conclusion

Keep in mind that once someone is logged in to your server, it's very easy to circumvent the Redis-specific security features we've put in place. So, the most important security feature is one that makes it extremely difficult to jump that fence.

That should be your firewall.

To take your server security to the next level, you could configure an intrusion detection system like OSSEC. To configure OSSEC on Ubuntu 14.04, see [this OSSEC guide](https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-ossec-security-notifications-on-ubuntu-14-04).

If you're attempting to secure Redis communication across an untrusted network you'll have to employ an SSL proxy, as recommeded by Redis developers in the [official Redis security guide](http://redis.io/topics/security). Setting up an SSL proxy to secure Redis commmunication is a separate topic.

We didn't include a full list of Redis commands in the renaming section.  However, you can check this for yourself and determine how they might be misused at [redis.io/commands](http://redis.io/commands).

This tutorial shows how to implement basic security for a Redis server.

In this tutorial, you'll read how to configure the few security features Redis has, and a few other system security features that will boost the security posture of a standalone Redis installation on Ubuntu 14.04. This includes configuring a Redis password and renaming destructive commands.

How To Secure Your Redis Installation on Ubuntu 14.04

18.04

### Introduction

[Redis](https://redis.io/) is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install, configure, and secure Redis on an Ubuntu 18.04 server.

## Prerequisites

To complete this guide, you will need access to an Ubuntu 18.04 server that has a non-root user with `sudo` privileges and a basic firewall configured. You can set this up by following our [Initial Server Setup guide](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04).

When you are ready to begin, log in to your Ubuntu 18.04 server as your `sudo` user and continue below.


## Step 1 — Installing and Configuring Redis

In order to get the latest version of Redis, we will use `apt` to install it from the official Ubuntu repositories.

First, update your local `apt` package cache if you haven't done so recently: 

```command
sudo apt update
```

Then, install Redis by typing:

```command
sudo apt install redis-server
```

This will download and install Redis and its dependencies. Following this, there is one important configuration change to make in the Redis configuration file, which was generated automatically during the installation.

Open this file with your preferred text editor:

```command
sudo nano /etc/redis/redis.conf
```

Inside the file, find the `supervised` directive. This directive allows you to declare an init system to manage Redis as a service, providing you with more control over its operation. The `supervised` directive is set to `no` by default. Since you are running Ubuntu, which uses the systemd init system, change this to `systemd`:

```
[label /etc/redis/redis.conf]
. . .

# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
#   supervised no      - no supervision interaction
#   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
#   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
#   supervised auto    - detect upstart or systemd method based on
#                        UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal "process is ready."
#       They do not enable continuous liveness pings back to your supervisor.
supervised <^>systemd<^>

. . .
```

That’s the only change you need to make to the Redis configuration file at this point, so save and close it when you are finished. Then, restart the Redis service to reflect the changes you made to the configuration file:

```command
sudo systemctl restart redis.service
```

With that, you’ve installed and configured Redis and it’s running on your machine. Before you begin using it, though, it’s prudent to first check whether Redis is functioning correctly.


## Step 2 — Testing Redis

As with any newly-installed software, it’s a good idea to ensure that Redis is functioning as expected before making any further changes to its configuration. We will go over a handful of ways to check that Redis is working correctly in this step.

Start by checking that the Redis service is running:

```command
sudo systemctl status redis
```

If it is running without any errors, this command will produce output similar to the following:

```
[secondary_label Output]
● redis-server.service - Advanced key-value store
   Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-06-27 18:48:52 UTC; 12s ago
     Docs: http://redis.io/documentation,
           man:redis-server(1)
  Process: 2421 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS)
  Process: 2424 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
 Main PID: 2445 (redis-server)
    Tasks: 4 (limit: 4704)
   CGroup: /system.slice/redis-server.service
           └─2445 /usr/bin/redis-server 127.0.0.1:6379
. . .
```

Here, you can see that Redis is running and is already enabled, meaning that it is set to start up every time the server boots.

<$>[note]
**Note:** This setting is desirable for many common use cases of Redis. If, however, you prefer to start up Redis manually every time your server boots, you can configure this with the following command:

```command
sudo systemctl disable redis
```
<$>

To test that Redis is functioning correctly, connect to the server using the command-line client:

```command
redis-cli
```

In the prompt that follows, test connectivity with the `ping` command:

```custom_prefix(127.0.0.1:6379>)
ping
```
```
[secondary_label Output]
PONG
```

This output confirms that the server connection is still alive. Next, check that you’re able to set keys by running:

```custom_prefix(127.0.0.1:6379>)
set test "It's working!"
```
```
[secondary_label Output]
OK
```

Retrieve the value by typing:

```custom_prefix(127.0.0.1:6379>)
get test
```

Assuming everything is working, you will be able to retrieve the value you stored:

```
[secondary_label Output]
"It's working!"
```

After confirming that you can fetch the value, exit the Redis prompt to get back to the shell:

```custom_prefix(127.0.0.1:6379>)
exit
```

As a final test, we will check whether Redis is able to persist data even after it’s been stopped or restarted. To do this, first restart the Redis instance:

```command
sudo systemctl restart redis
```

Then connect with the command-line client once again and confirm that your test value is still available:

```command
redis-cli
```
```custom_prefix(127.0.0.1:6379>)
get test
```

The value of your key should still be accessible:

```
[secondary_label Output]
"It's working!"
```

Exit out into the shell again when you are finished:

```custom_prefix(127.0.0.1:6379>)
exit
```

With that, your Redis installation is fully operational and ready for you to use. However, some of its default configuration settings are insecure and provide malicious actors with opportunities to attack and gain access to your server and its data. The remaining steps in this tutorial cover methods for mitigating these vulnerabilities, as prescribed by the [official Redis website](http://redis.io/topics/security). Although these steps are optional and Redis will still function if you choose not to follow them, it is *strongly* recommended that you complete them in order to harden your system’s security.


## Step 3 — Binding to localhost

By default, Redis is only accessible from **localhost**. However, if you installed and configured Redis by following a different tutorial than this one, you might have updated the configuration file to allow connections from anywhere. This is not as secure as binding to **localhost**.

To correct this, open the Redis configuration file for editing:

```command
sudo nano /etc/redis/redis.conf
```

Locate this line and make sure it is uncommented (remove the `#` if it exists):

```
[label /etc/redis/redis.conf]
bind 127.0.0.1 ::1
```

Save and close the file when finished (press `CTRL + X`, `Y`, then `ENTER`).

Then, restart the service to ensure that systemd reads your changes:

```command
sudo systemctl restart redis
```

To check that this change has gone into effect, run the following `netstat` command:

```command
sudo netstat -lnp | grep redis
```
```
[secondary_label Output]
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      14222/redis-server  
tcp6       0      0 ::1:6379                :::*                    LISTEN      14222/redis-server  
```

This output shows that the `redis-server` program is bound to **localhost** (`127.0.0.1`), reflecting the `bind` setting in the Redis configuration file. If you see another IP address in that column (`0.0.0.0`, for example), then you should double check that you uncommented the correct line and restart the Redis service again.

Now that your Redis installation is only listening in on **localhost**, it will be more difficult for malicious actors to make requests or gain access to your server. However, Redis isn’t currently set to require users to authenticate themselves before making changes to its configuration or the data it holds. To remedy this, Redis allows you to require users to authenticate with a password before making changes via the Redis client (`redis-cli`).


## Step 4 — Configuring a Redis Password

Configuring a Redis password enables one of its two built-in security features — the `auth` command, which requires clients to authenticate to access the database. The password is configured directly in Redis's configuration file, `/etc/redis/redis.conf`, so open that file again with your preferred editor:

```command
sudo nano /etc/redis/redis.conf
```

Scroll to the `SECURITY` section and look for a commented directive that reads:

```
[label /etc/redis/redis.conf]
# requirepass foobared
```

Uncomment it by removing the `#`, and change `foobared` to a secure password.

<$>[note]
**Note:** Above the `requirepass` directive in the `redis.conf` file, there is a commented warning:

```
# Warning: since Redis is pretty fast an outside user can try up to
# 150k passwords per second against a good box. This means that you should
# use a very strong password otherwise it will be very easy to break.
#
```

Thus, it’s important that you specify a very strong and very long value as your password. Rather than make up a password yourself, you can use the `openssl` command to generate a random one, as in the following example. By piping the output of the first command to the second `openssl` command, as shown here, it will remove any line breaks produced by that the first command:

```command
openssl rand 60 | openssl base64 -A
```

Your output should look something like:

```
[secondary_label Output]
RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE
```

After copying and pasting the output of that command as the new value for `requirepass`, it should read:

```
[secondary_label /etc/redis/redis.conf]
requirepass <^>RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE<^>
```
<$>

After setting the password, save and close the file, then restart Redis:

```command
sudo systemctl restart redis.service
```

To test that the password works, access the Redis command line:

```command
redis-cli
```

The following shows a sequence of commands used to test whether the Redis password works. The first command tries to set a key to a value before authentication:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

That won't work because you didn’t authenticate, so Redis returns an error:

```
[secondary_label Output]
(error) NOAUTH Authentication required.
```

The next command authenticates with the password specified in the Redis configuration file:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```

Redis acknowledges:

```
[secondary_label Output]
OK
```

After that, running the previous command again will succeed:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```
```
[secondary_label Output]
OK
```

`get key1` queries Redis for the value of the new key.

```custom_prefix(127.0.0.1:6379>)
get key1
```
```
[secondary_label Output]
"10"
```

After confirming that you’re able to run commands in the Redis client after authenticating, you can exit the `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
quit
```

Next, we'll look at renaming Redis commands which, if entered by mistake or by a malicious actor, could cause serious damage to your machine.


## Step 5 — Renaming Dangerous Commands

The other security feature built into Redis involves renaming or completely disabling certain commands that are considered dangerous.

When run by unauthorized users, such commands can be used to reconfigure, destroy, or otherwise wipe your data. Like the authentication password, renaming or disabling commands is configured in the same `SECURITY` section of the `/etc/redis/redis.conf` file.

Some of the commands that are considered dangerous include: **FLUSHDB**, **FLUSHALL**, **KEYS**, **PEXPIRE**, **DEL**, **CONFIG**, **SHUTDOWN**, **BGREWRITEAOF**, **BGSAVE**, **SAVE**, **SPOP**, **SREM**, **RENAME**, and **DEBUG**. This is not a comprehensive list, but renaming or disabling all of the commands in that list is a good starting point for enhancing your Redis server’s security.

Whether you should disable or rename a command depends on your specific needs or those of your site. If you know you will never use a command that could be abused, then you may disable it. Otherwise, it might be in your best interest to rename it.

To enable or disable Redis commands, open the configuration file once more:

```command
sudo nano  /etc/redis/redis.conf
```

<$>[warning]
**Warning:** The following steps showing how to disable and rename commands are examples. You should only choose to disable or rename the commands that make sense for you. You can review the full list of commands for yourself and determine how they might be misused at [redis.io/commands](http://redis.io/commands).
<$>

To disable a command, rename it to an empty string (signified by a pair of quotation marks with no characters between them), like this:

```
[label /etc/redis/redis.conf]
. . .
# It is also possible to completely kill a command by renaming it into
# an empty string:
#
<^>rename-command FLUSHDB ""<^>
<^>rename-command FLUSHALL ""<^>
<^>rename-command DEBUG ""<^>
. . .
```

By adding these `rename-command` directives and following them with empty strings, `FLUSHDB`, `FLUSHALL`, and `DEBUG` will be disabled on this Redis installation. 

To rename a command, give it another name like the following examples. Renamed commands should be difficult for others to guess, but easy for you to remember:

```
[label /etc/redis/redis.conf]
. . .
# rename-command CONFIG ""
<^>rename-command SHUTDOWN SHUTDOWN_MENOT<^>
<^>rename-command CONFIG ASC12_CONFIG<^>
. . .
```

These examples rename the `SHUTDOWN` and `CONFIG` commands to `SHUTDOWN_MENOT` and `ASC12_CONFIG`, respectively. 

Save your changes and close the file.

After renaming a command, apply the change by restarting Redis:

```command
sudo systemctl restart redis.service
```

To test whether these commands were updated successfully, open up the Redis client:

```command
redis-cli
```

Then, authenticate:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```
```
[secondary_label Output]
OK
```

Let’s assume that you renamed the `CONFIG` command to `ASC12_CONFIG`, as in the preceding example. First, try using the original `CONFIG` command. It should fail, because you’ve renamed it:

```custom_prefix(127.0.0.1:6379>)
config get requirepass
```
```
[secondary_label Output]
(error) ERR unknown command 'config'
```

Calling the renamed command, however, will be successful. It is not case-sensitive:

```custom_prefix(127.0.0.1:6379>)
asc12_config get requirepass
```

Redis's `config` command allows whoever runs it to interact with the installation's configuration file. When combined with `get` and followed by a directive from the configuration file, the command will return that directive and its current setting:

```
[secondary_label Output]
1) "requirepass"
2) "<^>your_redis_password<^>"
```

Finally, you can exit from `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
exit
```

Note that if you're already using the Redis command line and then restart Redis, you'll need to re-authenticate. Otherwise, you'll get this error if you type a command:

```
[secondary_label Output]
NOAUTH Authentication required.
```

<$>[warning]
**Warning**: Regarding the practice of renaming commands, there's a cautionary statement at the end of the `SECURITY` section in `/etc/redis/redis.conf` which reads:

```
[label /etc/redis/redis.conf]
. . .
# Please note that changing the name of commands that are logged into the
# AOF file or transmitted to slaves may cause problems.
. . .
```

This means if the renamed command is not in the AOF file, or if it is but the AOF file has not been transmitted to slaves, then there should be no problem.

So, keep that in mind when you're trying to rename commands. The best time to rename a command is when you're not using AOF persistence, or right after installation, that is, before your Redis-using application has been deployed.

When you're using AOF and dealing with a master-slave installation, consider [this answer from the project's GitHub issue page](https://github.com/antirez/redis/issues/2783). The following is a reply to the author's question:

> The commands are logged to the AOF and replicated to the slave the same way they are sent, so if you try to replay the AOF on an instance that doesn't have the same renaming, you may face inconsistencies as the command cannot be executed (same for slaves).

Thus, the best way to handle renaming in cases like that is to make sure that renamed commands are applied to all instances in master-slave installations.

***Note:*** *The Redis project chooses to use the terms “master” and “slave,” while DigitalOcean generally prefers the alternatives “primary” and “replica.” In order to avoid confusion we’ve chosen to use the terms used in the Redis documentation here.*
<$>


## Conclusion

In this tutorial, you installed and configured Redis, validated that your Redis installation is functioning correctly, and used its built-in security features to make it less vulnerable to attacks from malicious actors.

Keep in mind that once someone is logged in to your server, it's very easy to circumvent the Redis-specific security features we've put in place. Therefore, the most important security feature on your Redis server is your firewall (which you configured if you followed the prerequisite [Initial Server Setup](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04#step-four-%E2%80%94-setting-up-a-basic-firewall) tutorial), as this makes it extremely difficult for malicious actors to jump that fence.

Redis is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install and configure Redis on an Ubuntu 18.04 server.

How To Install and Secure Redis on Ubuntu 18.04

16.04

### Introduction

Redis is an in-memory key-value store known for its flexibility, performance, and wide language support.  In this guide, we will demonstrate how to install and configure Redis on an Ubuntu 16.04 server.

## Prerequisites

To complete this guide, you will need access to an Ubuntu 16.04 server.  You will need a non-root user with `sudo` privileges to perform the administrative functions required for this process.  You can learn how to set up an account with these privileges by following our [Ubuntu 16.04 initial server setup guide](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04).

When you are ready to begin, log in to your Ubuntu 16.04 server with your `sudo` user and continue below.

## Install the Build and Test Dependencies

In order to get the latest version of Redis, we will be compiling and installing the software from source.  Before we download the code, we need to satisfy the build dependencies so that we can compile the software.

To do this, we can install the `build-essential` meta-package from the Ubuntu repositories.  We will also be downloading the `tcl` package, which we can use to test our binaries.

We can update our local `apt` package cache and install the dependencies by typing:

```command
sudo apt-get update
sudo apt-get install build-essential tcl
```

## Download, Compile, and Install Redis

Next, we can begin to build Redis.

### Download and Extract the Source Code

Since we won't need to keep the source code that we'll compile long term (we can always re-download it), we will build in the `/tmp` directory.  Let's move there now:

```command
cd /tmp
```

Now, download the latest stable version of Redis.  This is always available at [a stable download URL](http://download.redis.io/redis-stable.tar.gz):

```command
curl -O http://download.redis.io/redis-stable.tar.gz
```

Unpack the tarball by typing:

```command
tar xzvf redis-stable.tar.gz
```

Move into the Redis source directory structure that was just extracted:

```command
cd redis-stable
```

### Build and Install Redis

Now, we can compile the Redis binaries by typing:

```command
make
```

After the binaries are compiled, run the test suite to make sure everything was built correctly.  You can do this by typing:

```command
make test
```

This will typically take a few minutes to run.  Once it is complete, you can install the binaries onto the system by typing:

```command
sudo make install
```

## Configure Redis

Now that Redis is installed, we can begin to configure it.

To start off, we need to create a configuration directory.  We will use the conventional `/etc/redis` directory, which can be created by typing:

```command
sudo mkdir /etc/redis
```

Now, copy over the sample Redis configuration file included in the Redis source archive:

```command
sudo cp /tmp/redis-stable/redis.conf /etc/redis
```

Next, we can open the file to adjust a few items in the configuration:

```command
sudo nano /etc/redis/redis.conf
```

In the file, find the `supervised` directive.  Currently, this is set to `no`.  Since we are running an operating system that uses the systemd init system, we can change this to `systemd`:

```
[label /etc/redis/redis.conf]
. . .

# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
#   supervised no      - no supervision interaction
#   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
#   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
#   supervised auto    - detect upstart or systemd method based on
#                        UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal "process is ready."
#       They do not enable continuous liveness pings back to your supervisor.
supervised <^>systemd<^>

. . .
```

Next, find the `dir` directory.  This option specifies the directory that Redis will use to dump persistent data.  We need to pick a location that Redis will have write permission and that isn't viewable by normal users.

We will use the `/var/lib/redis` directory for this, which we will create in a moment:

```
[label /etc/redis/redis.conf]
. . .

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir <^>/var/lib/redis<^>

. . .
```

Save and close the file when you are finished.

## Create a Redis systemd Unit File

Next, we can create a systemd unit file so that the init system can manage the Redis process.

Create and open the `/etc/systemd/system/redis.service` file to get started:

```command
sudo nano /etc/systemd/system/redis.service
```

Inside, we can begin the `[Unit]` section by adding a description and defining a requirement that networking be available before starting this service:

```
[label /etc/systemd/system/redis.service]
[Unit]
Description=Redis In-Memory Data Store
After=network.target
```

In the `[Service]` section, we need to specify the service's behavior.  For security purposes, we should not run our service as `root`.  We should use a dedicated user and group, which we will call `redis` for simplicity.  We will create these momentarily.

To start the service, we just need to call the `redis-server` binary, pointed at our configuration.  To stop it, we can use the Redis `shutdown` command, which can be executed with the `redis-cli` binary.  Also, since we want Redis to recover from failures when possible, we will set the `Restart` directive to "always":

```
[label /etc/systemd/system/redis.service]
[Unit]
Description=Redis In-Memory Data Store
After=network.target

<^>[Service]<^>
<^>User=redis<^>
<^>Group=redis<^>
<^>ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf<^>
<^>ExecStop=/usr/local/bin/redis-cli shutdown<^>
<^>Restart=always<^>
```

Finally, in the `[Install]` section, we can define the systemd target that the service should attach to if enabled (configured to start at boot):
```
[label /etc/systemd/system/redis.service]
[Unit]
Description=Redis In-Memory Data Store
After=network.target

[Service]
User=redis
Group=redis
ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf
ExecStop=/usr/local/bin/redis-cli shutdown
Restart=always

<^>[Install]<^>
<^>WantedBy=multi-user.target<^>
```

Save and close the file when you are finished.

## Create the Redis User, Group and Directories

Now, we just have to create the user, group, and directory that we referenced in the previous two files.

Begin by creating the `redis` user and group.  This can be done in a single command by typing:

```command
sudo adduser --system --group --no-create-home redis
```

Now, we can create the `/var/lib/redis` directory by typing:

```command
sudo mkdir /var/lib/redis
```

We should give the `redis` user and group ownership over this directory:

```command
sudo chown redis:redis /var/lib/redis
```

Adjust the permissions so that regular users cannot access this location:

```command
sudo chmod 770 /var/lib/redis
```

## Start and Test Redis

Now, we are ready to start the Redis server.

### Start the Redis Service

Start up the systemd service by typing:

```command
sudo systemctl start redis
```

Check that the service had no errors by running:

```command
sudo systemctl status redis
```

You should see something that looks like this:

```
[secondary_label Output]
● redis.service - Redis Server
   Loaded: loaded (/etc/systemd/system/redis.service; enabled; vendor preset: enabled)
   Active: <^>active (running)<^> since Wed 2016-05-11 14:38:08 EDT; 1min 43s ago
  Process: 3115 ExecStop=/usr/local/bin/redis-cli shutdown (code=exited, status=0/SUCCESS)
 Main PID: 3124 (redis-server)
    Tasks: 3 (limit: 512)
   Memory: 864.0K
      CPU: 179ms
   CGroup: /system.slice/redis.service
           └─3124 /usr/local/bin/redis-server 127.0.0.1:6379       

. . .
```

### Test the Redis Instance Functionality

To test that your service is functioning correctly, connect to the Redis server with the command-line client:

```command
redis-cli
```

In the prompt that follows, test connectivity by typing:

```custom_prefix(127.0.0.1:6379>)
ping
```

You should see:

```
[secondary_label Output]
PONG
```

Check that you can set keys by typing:

```custom_prefix(127.0.0.1:6379>)
set test "It's working!"
```
```
[secondary_label Output]
OK
```

Now, retrieve the value by typing:

```custom_prefix(127.0.0.1:6379>)
get test
```

You should be able to retrieve the value we stored:

```
[secondary_label Output]
"It's working!"
```

Exit the Redis prompt to get back to the shell:

```custom_prefix(127.0.0.1:6379>)
exit
```

As a final test, let's restart the Redis instance:

```command
sudo systemctl restart redis
```

Now, connect with the client again and confirm that your test value is still available:

```command
redis-cli
```
```custom_prefix(127.0.0.1:6379>)
get test
```

The value of your key should still be accessible:

```
[secondary_label Output]
"It's working!"
```

Back out into the shell again when you are finished:

```custom_prefix(127.0.0.1:6379>)
exit
```

### Enable Redis to Start at Boot

If all of your tests worked, and you would like to start Redis automatically when your server boots, you can enable the systemd service.

To do so, type:

```command
sudo systemctl enable redis
```
```
[secondary_label Output]
Created symlink from /etc/systemd/system/multi-user.target.wants/redis.service to /etc/systemd/system/redis.service.
```

## Conclusion

You should now have a Redis instance installed and configured on your Ubuntu 16.04 server.  To learn more about how to secure your Redis installation, take a look at our [How To Secure Your Redis Installation on Ubuntu 14.04](https://www.digitalocean.com/community/tutorials/how-to-secure-your-redis-installation-on-ubuntu-14-04) (from step 3 onward).  Although it was written with Ubuntu 14.04 in mind, it should mostly work for 16.04 as well.

Redis is an in-memory, key-value store known for its flexibility, performance, and wide language support. In this guide, we will demonstrate how to install and configure Redis on an Ubuntu 16.04 server. To complete this guide, you will need access to an...

How To Install and Configure Redis on Ubuntu 16.04

Debian

### Introduction

[Redis](https://redis.io/) is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install, configure, and secure Redis on a Debian 9 server.

## Prerequisites

To complete this guide, you will need access to a Debian 9 server that has a non-root user with `sudo` privileges and a basic firewall configured. You can set this up by following our [Initial Server Setup guide](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-debian-9).

When you are ready to begin, log in to your server as your sudo-enabled user and continue below.

## Step 1 — Installing and Configuring Redis

In order to get the latest version of Redis, we will use `apt` to install it from the official Debian repositories.

Update your local `apt` package cache and install Redis by typing:

```command
sudo apt update
sudo apt install redis-server
```

This will download and install Redis and its dependencies. Following this, there is one important configuration change to make in the Redis configuration file, which was generated automatically during the installation.

Open this file with your preferred text editor:

```command
sudo nano /etc/redis/redis.conf
```

Inside the file, find the `supervised` directive. This directive allows you to declare an init system to manage Redis as a service, providing you with more control over its operation. The `supervised` directive is set to `no` by default. Since you are running Debian, which uses the systemd init system, change this to `systemd`:

```
[label /etc/redis/redis.conf]
. . .

# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
#   supervised no      - no supervision interaction
#   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
#   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
#   supervised auto    - detect upstart or systemd method based on
#                        UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal "process is ready."
#       They do not enable continuous liveness pings back to your supervisor.
supervised <^>systemd<^>

. . .
```

That’s the only change you need to make to the Redis configuration file at this point, so save and close it when you are finished. Then, reload the Redis service file to reflect the changes you made to the configuration file:

```command
sudo systemctl restart redis
```

With that, you’ve installed and configured Redis and it’s running on your machine. Before you begin using it, though, it’s prudent to first check whether Redis is functioning correctly.

## Step 2 — Testing Redis

As with any newly-installed software, it’s a good idea to ensure that Redis is functioning as expected before making any further changes to its configuration. We will go over a handful of ways to check that Redis is working correctly in this step.

Start by checking that the Redis service is running:

```command
sudo systemctl status redis
```

If it is running without any errors, this command will produce output similar to the following:

```
[secondary_label Output]
● redis-server.service - Advanced key-value store
   Loaded: loaded (/lib/systemd/system/redis-server.service; <^>enabled<^>; vendor preset: enabled)
   Active: <^>active (running)<^> since Wed 2018-09-05 20:19:44 UTC; 41s ago
     Docs: http://redis.io/documentation,
           man:redis-server(1)
  Process: 10829 ExecStopPost=/bin/run-parts --verbose /etc/redis/redis-server.post-down.d (code=exited, status=0/SUCCESS)
  Process: 10825 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS)
  Process: 10823 ExecStop=/bin/run-parts --verbose /etc/redis/redis-server.pre-down.d (code=exited, status=0/SUCCESS)
  Process: 10842 ExecStartPost=/bin/run-parts --verbose /etc/redis/redis-server.post-up.d (code=exited, status=0/SUCCESS)
  Process: 10838 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
  Process: 10834 ExecStartPre=/bin/run-parts --verbose /etc/redis/redis-server.pre-up.d (code=exited, status=0/SUCCESS)
 Main PID: 10841 (redis-server)
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/redis-server.service
           └─10841 /usr/bin/redis-server 127.0.0.1:6379
. . .
```

Here, you can see that Redis is running and is already enabled, meaning that it is set to start up every time the server boots.

<$>[note]
**Note:** This setting is desirable for many common use cases of Redis. If, however, you prefer to start up Redis manually every time your server boots, you can configure this with the following command:

```command
sudo systemctl disable redis
```

<$>

To test that Redis is functioning correctly, connect to the server using the command-line client:

```command
redis-cli
```

In the prompt that follows, test connectivity with the `ping` command:

```custom_prefix(127.0.0.1:6379>)
ping
```

```
[secondary_label Output]
PONG
```

This output confirms that the server connection is still alive. Next, check that you’re able to set keys by running:

```custom_prefix(127.0.0.1:6379>)
set test "It's working!"
```

```
[secondary_label Output]
OK
```

Retrieve the value by typing:

```custom_prefix(127.0.0.1:6379>)
get test
```

Assuming everything is working, you will be able to retrieve the value you stored:

```
[secondary_label Output]
"It's working!"
```

After confirming that you can fetch the value, exit the Redis prompt to get back to the shell:

```custom_prefix(127.0.0.1:6379>)
exit
```

As a final test, we will check whether Redis is able to persist data even after it’s been stopped or restarted. To do this, first restart the Redis instance:

```command
sudo systemctl restart redis
```

Then connect with the command-line client once again and confirm that your test value is still available:

```command
redis-cli
```

```custom_prefix(127.0.0.1:6379>)
get test
```

The value of your key should still be accessible:

```
[secondary_label Output]
"It's working!"
```

Exit out into the shell again when you are finished:

```custom_prefix(127.0.0.1:6379>)
exit
```

With that, your Redis installation is fully operational and ready for you to use. However, some of its default configuration settings are insecure and provide malicious actors with opportunities to attack and gain access to your server and its data. The remaining steps in this tutorial cover methods for mitigating these vulnerabilities, as prescribed by the [official Redis website](http://redis.io/topics/security). Although these steps are optional and Redis will still function if you choose not to follow them, it is _strongly_ recommended that you complete them in order to harden your system’s security.

## Step 3 — Binding to localhost

By default, Redis is only accessible from **localhost**. However, if you installed and configured Redis by following a different tutorial than this one, you might have updated the configuration file to allow connections from anywhere. This is not as secure as binding to **localhost**.

To correct this, open the Redis configuration file for editing:

```command
sudo nano /etc/redis/redis.conf
```

Locate this line and make sure it is uncommented (remove the `#` if it exists):

```
[label /etc/redis/redis.conf]
bind 127.0.0.1
```

Save and close the file when finished (press `CTRL + X`, `Y`, then `ENTER`).

Then, restart the service to ensure that systemd reads your changes:

```command
sudo systemctl restart redis
```

To check that this change has gone into effect, run the following `netstat` command:

```command
sudo netstat -lnp | grep redis
```

```
[secondary_label Output]
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      10959/redis-server
```

This output shows that the `redis-server` program is bound to **localhost** (`127.0.0.1`), reflecting the change you just made to the configuration file. If you see another IP address in that column (`0.0.0.0`, for example), then you should double check that you uncommented the correct line and restart the Redis service again.

Now that your Redis installation is only listening in on **localhost**, it will be more difficult for malicious actors to make requests or gain access to your server. However, Redis isn’t currently set to require users to authenticate themselves before making changes to its configuration or the data it holds. To remedy this, Redis allows you to require users to authenticate with a password before making changes via the Redis client (`redis-cli`).

## Step 4 — Configuring a Redis Password

Configuring a Redis password enables one of its two built-in security features — the `auth` command, which requires clients to authenticate to access the database. The password is configured directly in Redis's configuration file, `/etc/redis/redis.conf`, so open that file again with your preferred editor:

```command
sudo nano /etc/redis/redis.conf
```

Scroll to the `SECURITY` section and look for a commented directive that reads:

```
[label /etc/redis/redis.conf]
# requirepass foobared
```

Uncomment it by removing the `#`, and change `foobared` to a secure password.

<$>[note]
**Note:** Above the `requirepass` directive in the `redis.conf` file, there is a commented warning:

```
# Warning: since Redis is pretty fast an outside user can try up to
# 150k passwords per second against a good box. This means that you should
# use a very strong password otherwise it will be very easy to break.
#
```

Thus, it’s important that you specify a very strong and very long value as your password. Rather than make up a password yourself, you can use the `openssl` command to generate a random one, as in the following example. By piping the output of the first command to the second `openssl` command, as shown here, it will remove any line breaks produced by that the first command:

```command
openssl rand 60 | openssl base64 -A
```

Your output should look something like:

```
[secondary_label Output]
RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE
```

After copying and pasting the output of that command as the new value for `requirepass`, it should read:

```
[secondary_label /etc/redis/redis.conf]
requirepass <^>RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE<^>
```

<$>

After setting the password, save and close the file, then restart Redis:

```command
sudo systemctl restart redis.service
```

To test that the password works, access the Redis command line:

```command
redis-cli
```

The following shows a sequence of commands used to test whether the Redis password works. The first command tries to set a key to a value before authentication:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

That won't work because you didn’t authenticate, so Redis returns an error:

```
[secondary_label Output]
(error) NOAUTH Authentication required.
```

The next command authenticates with the password specified in the Redis configuration file:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```

Redis acknowledges:

```
[secondary_label Output]
OK
```

After that, running the previous command again will succeed:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

```
[secondary_label Output]
OK
```

`get key1` queries Redis for the value of the new key.

```custom_prefix(127.0.0.1:6379>)
get key1
```

```
[secondary_label Output]
"10"
```

After confirming that you’re able to run commands in the Redis client after authenticating, you can exit the `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
quit
```

Next, we'll look at renaming Redis commands which, if entered by mistake or by a malicious actor, could cause serious damage to your machine.

## Step 5 — Renaming Dangerous Commands

The other security feature built into Redis involves renaming or completely disabling certain commands that are considered dangerous.

When run by unauthorized users, such commands can be used to reconfigure, destroy, or otherwise wipe your data. Like the authentication password, renaming or disabling commands is configured in the same `SECURITY` section of the `/etc/redis/redis.conf` file.

Some of the commands that are considered dangerous include: **FLUSHDB**, **FLUSHALL**, **KEYS**, **PEXPIRE**, **DEL**, **CONFIG**, **SHUTDOWN**, **BGREWRITEAOF**, **BGSAVE**, **SAVE**, **SPOP**, **SREM**, **RENAME**, and **DEBUG**. This is not a comprehensive list, but renaming or disabling all of the commands in that list is a good starting point for enhancing your Redis server’s security.

Whether you should disable or rename a command depends on your specific needs or those of your site. If you know you will never use a command that could be abused, then you may disable it. Otherwise, it might be in your best interest to rename it.

To enable or disable Redis commands, open the configuration file once more:

```command
sudo nano  /etc/redis/redis.conf
```

<$>[warning]
**Warning:** The following steps showing how to disable and rename commands are examples. You should only choose to disable or rename the commands that make sense for you. You can review the full list of commands for yourself and determine how they might be misused at [redis.io/commands](http://redis.io/commands).
<$>

To disable a command, simply rename it to an empty string (signified by a pair of quotation marks with no characters between them), as shown below:

```
[label /etc/redis/redis.conf]
. . .
# It is also possible to completely kill a command by renaming it into
# an empty string:
#
<^>rename-command FLUSHDB ""<^>
<^>rename-command FLUSHALL ""<^>
<^>rename-command DEBUG ""<^>
. . .
```

To rename a command, give it another name as shown in the examples below. Renamed commands should be difficult for others to guess, but easy for you to remember:

```
[label /etc/redis/redis.conf]
. . .
# rename-command CONFIG ""
<^>rename-command SHUTDOWN SHUTDOWN_MENOT<^>
<^>rename-command CONFIG ASC12_CONFIG<^>
. . .
```

Save your changes and close the file.

After renaming a command, apply the change by restarting Redis:

```command
sudo systemctl restart redis
```

To test the new command, enter the Redis command line:

```command
redis-cli
```

Then, authenticate:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```

```
[secondary_label Output]
OK
```

Let’s assume that you renamed the `CONFIG` command to `ASC12_CONFIG`, as in the preceding example. First, try using the original `CONFIG` command. It should fail, because you’ve renamed it:

```custom_prefix(127.0.0.1:6379>)
config get requirepass
```

```
[secondary_label Output]
(error) ERR unknown command 'config'
```

Calling the renamed command, however, will be successful. It is not case-sensitive:

```custom_prefix(127.0.0.1:6379>)
asc12_config get requirepass
```

```
[secondary_label Output]
1) "requirepass"
2) "<^>your_redis_password<^>"
```

Finally, you can exit from `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
exit
```

Note that if you're already using the Redis command line and then restart Redis, you'll need to re-authenticate. Otherwise, you'll get this error if you type a command:

```
[secondary_label Output]
NOAUTH Authentication required.
```

<$>[warning]
Regarding the practice of renaming commands, there's a cautionary statement at the end of the `SECURITY` section in `/etc/redis/redis.conf` which reads:

> `Please note that changing the name of commands that are logged into the AOF file or transmitted to slaves may cause problems.`

**_Note:_** _The Redis project chooses to use the terms “master” and “slave” while DigitalOcean generally prefers alternative descriptors. In order to avoid confusion we’ve chosen to use the terms used in the Redis documentation here._

That means if the renamed command is not in the AOF file, or if it is but the AOF file has not been transmitted to slaves, then there should be no problem.

So, keep that in mind when you're trying to rename commands. The best time to rename a command is when you're not using AOF persistence, or right after installation, that is, before your Redis-using application has been deployed.

When you're using AOF and dealing with a master-slave installation, consider [this answer from the project's GitHub issue page](https://github.com/antirez/redis/issues/2783). The following is a reply to the author's question:

> The commands are logged to the AOF and replicated to the slave the same way they are sent, so if you try to replay the AOF on an instance that doesn't have the same renaming, you may face inconsistencies as the command cannot be executed (same for slaves).

Thus, the best way to handle renaming in cases like that is to make sure that renamed commands are applied to all instances in master-slave installations.
<$>

## Conclusion

In this tutorial, you installed and configured Redis, validated that your Redis installation is functioning correctly, and used its built-in security features to make it less vulnerable to attacks from malicious actors.

Keep in mind that once someone is logged in to your server, it's very easy to circumvent the Redis-specific security features we've put in place. Therefore, the most important security feature on your Redis server is your firewall (which you configured if you followed the prerequisite [Initial Server Setup](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-debian-9#step-four-%E2%80%94-setting-up-a-basic-firewall) tutorial), as this makes it extremely difficult for malicious actors to jump that fence.


Redis is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install, configure, and secure Redis on a Debian 9 server.

How To Install and Secure Redis on Debian 9

### Introduction

[Redis](https://redis.io/) is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install, configure, and secure Redis on a Debian 10 server.

## Prerequisites

To complete this guide, you will need access to a Debian 10 server that has a non-root user with `sudo` privileges and a basic firewall configured. You can set this up by following our [Initial Server Setup guide](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-debian-10).

When you are ready to begin, log in to your server as your sudo-enabled user and continue below.

## Step 1 — Installing and Configuring Redis

In order to get the latest version of Redis, we will use `apt` to install it from the official Debian repositories.

Update your local `apt` package cache and install Redis by typing:

```command
sudo apt update
sudo apt install redis-server
```

This will download and install Redis and its dependencies. Following this, there is one important configuration change to make in the Redis configuration file, which was generated automatically during the installation.

Open this file with your preferred text editor:

```command
sudo nano /etc/redis/redis.conf
```

Inside the file, find the `supervised` directive. This directive allows you to declare an init system to manage Redis as a service, providing you with more control over its operation. The `supervised` directive is set to `no` by default. Since you are running Debian, which uses the systemd init system, change this to `systemd`:

```
[label /etc/redis/redis.conf]
. . .

# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
#   supervised no      - no supervision interaction
#   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
#   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
#   supervised auto    - detect upstart or systemd method based on
#                        UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal "process is ready."
#       They do not enable continuous liveness pings back to your supervisor.
supervised <^>systemd<^>

. . .
```

That’s the only change you need to make to the Redis configuration file at this point, so save and close it when you are finished. Then, reload the Redis service file to reflect the changes you made to the configuration file:

```command
sudo systemctl restart redis
```

With that, you’ve installed and configured Redis and it’s running on your machine. Before you begin using it, though, it’s prudent to first check whether Redis is functioning correctly.

## Step 2 — Testing Redis

As with any newly-installed software, it’s a good idea to ensure that Redis is functioning as expected before making any further changes to its configuration. We will go over a handful of ways to check that Redis is working correctly in this step.

Start by checking that the Redis service is running:

```command
sudo systemctl status redis
```

If it is running without any errors, this command will produce output similar to the following:

```
[secondary_label Output]
● redis-server.service - Advanced key-value store
   Loaded: loaded (/lib/systemd/system/redis-server.service; <^>enabled<^>; vendor preset: enabled)
   Active: <^>active (running)<^> since Wed 2018-09-05 20:19:44 UTC; 41s ago
     Docs: http://redis.io/documentation,
           man:redis-server(1)
  Process: 10829 ExecStopPost=/bin/run-parts --verbose /etc/redis/redis-server.post-down.d (code=exited, status=0/SUCCESS)
  Process: 10825 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS)
  Process: 10823 ExecStop=/bin/run-parts --verbose /etc/redis/redis-server.pre-down.d (code=exited, status=0/SUCCESS)
  Process: 10842 ExecStartPost=/bin/run-parts --verbose /etc/redis/redis-server.post-up.d (code=exited, status=0/SUCCESS)
  Process: 10838 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
  Process: 10834 ExecStartPre=/bin/run-parts --verbose /etc/redis/redis-server.pre-up.d (code=exited, status=0/SUCCESS)
 Main PID: 10841 (redis-server)
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/redis-server.service
           └─10841 /usr/bin/redis-server 127.0.0.1:6379
. . .
```

Here, you can see that Redis is running and is already enabled, meaning that it is set to start up every time the server boots.

<$>[note]
**Note:** This setting is desirable for many common use cases of Redis. If, however, you prefer to start up Redis manually every time your server boots, you can configure this with the following command:

```command
sudo systemctl disable redis
```

<$>

To test that Redis is functioning correctly, connect to the server using the command-line client:

```command
redis-cli
```

In the prompt that follows, test connectivity with the `ping` command:

```custom_prefix(127.0.0.1:6379>)
ping
```

```
[secondary_label Output]
PONG
```

This output confirms that the server connection is still alive. Next, check that you’re able to set keys by running:

```custom_prefix(127.0.0.1:6379>)
set test "It's working!"
```

```
[secondary_label Output]
OK
```

Retrieve the value by typing:

```custom_prefix(127.0.0.1:6379>)
get test
```

Assuming everything is working, you will be able to retrieve the value you stored:

```
[secondary_label Output]
"It's working!"
```

After confirming that you can fetch the value, exit the Redis prompt to get back to the shell:

```custom_prefix(127.0.0.1:6379>)
exit
```

As a final test, we will check whether Redis is able to persist data even after it’s been stopped or restarted. To do this, first restart the Redis instance:

```command
sudo systemctl restart redis
```

Then connect with the command-line client once again and confirm that your test value is still available:

```command
redis-cli
```

```custom_prefix(127.0.0.1:6379>)
get test
```

The value of your key should still be accessible:

```
[secondary_label Output]
"It's working!"
```

Exit out into the shell again when you are finished:

```custom_prefix(127.0.0.1:6379>)
exit
```

With that, your Redis installation is fully operational and ready for you to use. However, some of its default configuration settings are insecure and provide malicious actors with opportunities to attack and gain access to your server and its data. The remaining steps in this tutorial cover methods for mitigating these vulnerabilities, as prescribed by the [official Redis website](http://redis.io/topics/security). Although these steps are optional and Redis will still function if you choose not to follow them, it is _strongly_ recommended that you complete them in order to harden your system’s security.

## Step 3 — Binding to localhost

By default, Redis is only accessible from **localhost**. However, if you installed and configured Redis by following a different tutorial than this one, you might have updated the configuration file to allow connections from anywhere. This is not as secure as binding to **localhost**.

To correct this, open the Redis configuration file for editing:

```command
sudo nano /etc/redis/redis.conf
```

Locate this line and make sure it is uncommented (remove the `#` if it exists):

```
[label /etc/redis/redis.conf]
bind 127.0.0.1
```

Save and close the file when finished (press `CTRL + X`, `Y`, then `ENTER`).

Then, restart the service to ensure that systemd reads your changes:

```command
sudo systemctl restart redis
```

To check that this change has gone into effect, run the following `netstat` command:

```command
sudo netstat -lnp | grep redis
```

```
[secondary_label Output]
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      10959/redis-server
```

This output shows that the `redis-server` program is bound to **localhost** (`127.0.0.1`), reflecting the change you just made to the configuration file. If you see another IP address in that column (`0.0.0.0`, for example), then you should double check that you uncommented the correct line and restart the Redis service again.

Now that your Redis installation is only listening in on **localhost**, it will be more difficult for malicious actors to make requests or gain access to your server. However, Redis isn’t currently set to require users to authenticate themselves before making changes to its configuration or the data it holds. To remedy this, Redis allows you to require users to authenticate with a password before making changes via the Redis client (`redis-cli`).

## Step 4 — Configuring a Redis Password

Configuring a Redis password enables one of its two built-in security features — the `auth` command, which requires clients to authenticate to access the database. The password is configured directly in Redis's configuration file, `/etc/redis/redis.conf`, so open that file again with your preferred editor:

```command
sudo nano /etc/redis/redis.conf
```

Scroll to the `SECURITY` section and look for a commented directive that reads:

```
[label /etc/redis/redis.conf]
# requirepass foobared
```

Uncomment it by removing the `#`, and change `foobared` to a secure password.

<$>[note]
**Note:** Above the `requirepass` directive in the `redis.conf` file, there is a commented warning:

```
# Warning: since Redis is pretty fast an outside user can try up to
# 150k passwords per second against a good box. This means that you should
# use a very strong password otherwise it will be very easy to break.
#
```

Thus, it’s important that you specify a very strong and very long value as your password. Rather than make up a password yourself, you can use the `openssl` command to generate a random one, as in the following example. By piping the output of the first command to the second `openssl` command, as shown here, it will remove any line breaks produced by that the first command:

```command
openssl rand 60 | openssl base64 -A
```

Your output should look something like:

```
[secondary_label Output]
RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE
```

After copying and pasting the output of that command as the new value for `requirepass`, it should read:

```
[secondary_label /etc/redis/redis.conf]
requirepass <^>RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE<^>
```

<$>

After setting the password, save and close the file, then restart Redis:

```command
sudo systemctl restart redis.service
```

To test that the password works, access the Redis command line:

```command
redis-cli
```

The following shows a sequence of commands used to test whether the Redis password works. The first command tries to set a key to a value before authentication:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

That won't work because you didn’t authenticate, so Redis returns an error:

```
[secondary_label Output]
(error) NOAUTH Authentication required.
```

The next command authenticates with the password specified in the Redis configuration file:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```

Redis acknowledges:

```
[secondary_label Output]
OK
```

After that, running the previous command again will succeed:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

```
[secondary_label Output]
OK
```

`get key1` queries Redis for the value of the new key.

```custom_prefix(127.0.0.1:6379>)
get key1
```

```
[secondary_label Output]
"10"
```

After confirming that you’re able to run commands in the Redis client after authenticating, you can exit the `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
quit
```

Next, we'll look at renaming Redis commands which, if entered by mistake or by a malicious actor, could cause serious damage to your machine.

## Step 5 — Renaming Dangerous Commands

The other security feature built into Redis involves renaming or completely disabling certain commands that are considered dangerous.

When run by unauthorized users, such commands can be used to reconfigure, destroy, or otherwise wipe your data. Like the authentication password, renaming or disabling commands is configured in the same `SECURITY` section of the `/etc/redis/redis.conf` file.

Some of the commands that are considered dangerous include: **FLUSHDB**, **FLUSHALL**, **KEYS**, **PEXPIRE**, **DEL**, **CONFIG**, **SHUTDOWN**, **BGREWRITEAOF**, **BGSAVE**, **SAVE**, **SPOP**, **SREM**, **RENAME**, and **DEBUG**. This is not a comprehensive list, but renaming or disabling all of the commands in that list is a good starting point for enhancing your Redis server’s security.

Whether you should disable or rename a command depends on your specific needs or those of your site. If you know you will never use a command that could be abused, then you may disable it. Otherwise, it might be in your best interest to rename it.

To enable or disable Redis commands, open the configuration file once more:

```command
sudo nano  /etc/redis/redis.conf
```

<$>[warning]
**Warning:** The following steps showing how to disable and rename commands are examples. You should only choose to disable or rename the commands that make sense for you. You can review the full list of commands for yourself and determine how they might be misused at [redis.io/commands](http://redis.io/commands).
<$>

To disable a command, simply rename it to an empty string (signified by a pair of quotation marks with no characters between them), as shown below:

```
[label /etc/redis/redis.conf]
. . .
# It is also possible to completely kill a command by renaming it into
# an empty string:
#
<^>rename-command FLUSHDB ""<^>
<^>rename-command FLUSHALL ""<^>
<^>rename-command DEBUG ""<^>
. . .
```

To rename a command, give it another name as shown in the examples below. Renamed commands should be difficult for others to guess, but easy for you to remember:

```
[label /etc/redis/redis.conf]
. . .
# rename-command CONFIG ""
<^>rename-command SHUTDOWN SHUTDOWN_MENOT<^>
<^>rename-command CONFIG ASC12_CONFIG<^>
. . .
```

Save your changes and close the file.

After renaming a command, apply the change by restarting Redis:

```command
sudo systemctl restart redis
```

To test the new command, enter the Redis command line:

```command
redis-cli
```

Then, authenticate:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```

```
[secondary_label Output]
OK
```

Let’s assume that you renamed the `CONFIG` command to `ASC12_CONFIG`, as in the preceding example. First, try using the original `CONFIG` command. It should fail, because you’ve renamed it:

```custom_prefix(127.0.0.1:6379>)
config get requirepass
```

```
[secondary_label Output]
(error) ERR unknown command 'config'
```

Calling the renamed command, however, will be successful. It is not case-sensitive:

```custom_prefix(127.0.0.1:6379>)
asc12_config get requirepass
```

```
[secondary_label Output]
1) "requirepass"
2) "<^>your_redis_password<^>"
```

Finally, you can exit from `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
exit
```

Note that if you're already using the Redis command line and then restart Redis, you'll need to re-authenticate. Otherwise, you'll get this error if you type a command:

```
[secondary_label Output]
NOAUTH Authentication required.
```

<$>[warning]
Regarding the practice of renaming commands, there's a cautionary statement at the end of the `SECURITY` section in `/etc/redis/redis.conf` which reads:

> `Please note that changing the name of commands that are logged into the AOF file or transmitted to slaves may cause problems.`

**_Note:_** _The Redis project chooses to use the terms “master” and “slave” while DigitalOcean generally prefers alternative descriptors. In order to avoid confusion we’ve chosen to use the terms used in the Redis documentation here._

That means if the renamed command is not in the AOF file, or if it is but the AOF file has not been transmitted to slaves, then there should be no problem.

So, keep that in mind when you're trying to rename commands. The best time to rename a command is when you're not using AOF persistence, or right after installation, that is, before your Redis-using application has been deployed.

When you're using AOF and dealing with a master-slave installation, consider [this answer from the project's GitHub issue page](https://github.com/antirez/redis/issues/2783). The following is a reply to the author's question:

> The commands are logged to the AOF and replicated to the slave the same way they are sent, so if you try to replay the AOF on an instance that doesn't have the same renaming, you may face inconsistencies as the command cannot be executed (same for slaves).

Thus, the best way to handle renaming in cases like that is to make sure that renamed commands are applied to all instances in master-slave installations.
<$>

## Conclusion

In this tutorial, you installed and configured Redis, validated that your Redis installation is functioning correctly, and used its built-in security features to make it less vulnerable to attacks from malicious actors.

Keep in mind that once someone is logged in to your server, it's very easy to circumvent the Redis-specific security features we've put in place. Therefore, the most important security feature on your Redis server is your firewall (which you configured if you followed the prerequisite [Initial Server Setup](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-debian-10#step-4-%E2%80%94-setting-up-a-basic-firewall) tutorial), as this makes it extremely difficult for malicious actors to jump that fence.




Redis is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install, configure, and secure Redis on a Debian 10 server. 

How To Install and Secure Redis on Debian 10

20.04

### Introduction

[Redis](https://redis.io/) is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install, configure, and secure Redis on an Ubuntu 20.04 server.

## Prerequisites

To complete this guide, you will need access to an Ubuntu 20.04 server that has a non-root user with `sudo` privileges and a firewall configured with `ufw`. You can set this up by following our [Initial Server Setup guide for Ubuntu 20.04](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-20-04).


## Step 1 — Installing and Configuring Redis

We'll use the APT package manager to install redis from the official Ubuntu repositories. As of this writing, the version available in the default repositories is <^>5.0.7<^>.

Begin by updating your local `apt` package cache:

```command
sudo apt update
```

Then install Redis by typing:

```command
sudo apt install redis-server
```

This will download and install Redis and its dependencies. Following this, there is one important configuration change to make in the Redis configuration file, which was generated automatically during the installation.

Open this file with your preferred text editor:

```command
sudo nano /etc/redis/redis.conf
```

Inside the file, find the `supervised` directive. This directive allows you to declare an init system to manage Redis as a service, providing you with more control over its operation. The `supervised` directive is set to `no` by default. Since you are running Ubuntu, which uses the [systemd](https://en.wikipedia.org/wiki/Systemd) init system, change this to `systemd`:

```
[label /etc/redis/redis.conf]
. . .

# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
#   supervised no      - no supervision interaction
#   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
#   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
#   supervised auto    - detect upstart or systemd method based on
#                        UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal "process is ready."
#       They do not enable continuous liveness pings back to your supervisor.
supervised <^>systemd<^>

. . .
```

That’s the only change you need to make to the Redis configuration file at this point, so save and close it when you are finished. If you used `nano` to edit the file, do so by pressing `CTRL + X`, `Y`, then `ENTER`.

Then, restart the Redis service to reflect the changes you made to the configuration file:

```command
sudo systemctl restart redis.service
```

With that, you’ve installed and configured Redis and it’s running on your machine. Before you begin using it, though, it’s prudent to first check whether Redis is functioning correctly.


## Step 2 — Testing Redis

As with any newly-installed software, it’s a good idea to ensure that Redis is functioning as expected before making any further changes to its configuration. We will go over a handful of ways to check that Redis is working correctly in this step.

Start by checking that the Redis service is running:

```command
sudo systemctl status redis
```

If it is running without any errors, this command will produce output similar to the following:

```
[secondary_label Output]
● redis-server.service - Advanced key-value store
     Loaded: loaded (/lib/systemd/system/redis-server.service; <^>enabled<^>; vendor preset: enabled)
     Active: <^>active (running)<^> since Thu 2020-04-30 23:26:54 UTC; 4s ago
       Docs: http://redis.io/documentation,
             man:redis-server(1)
    Process: 36552 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
   Main PID: 36561 (redis-server)
      Tasks: 4 (limit: 2345)
     Memory: 1.8M
     CGroup: /system.slice/redis-server.service
             └─36561 /usr/bin/redis-server 127.0.0.1:6379
. . .
```

Here, you can see that Redis is running and is already enabled, meaning that it is set to start up every time the server boots. 

<$>[note]
**Note:** This setting is desirable for many common use cases of Redis. If, however, you prefer to start up Redis manually every time your server boots, you can configure this with the following command:

```command
sudo systemctl disable redis
```
<$>

To test that Redis is functioning correctly, connect to the server using `redis-cli`, Redis's command-line client:

```command
redis-cli
```

In the prompt that follows, test connectivity with the `ping` command:

```custom_prefix(127.0.0.1:6379>)
ping
```
```
[secondary_label Output]
PONG
```

This output confirms that the server connection is still alive. Next, check that you’re able to set keys by running:

```custom_prefix(127.0.0.1:6379>)
set test "It's working!"
```
```
[secondary_label Output]
OK
```

Retrieve the value by typing:

```custom_prefix(127.0.0.1:6379>)
get test
```

Assuming everything is working, you will be able to retrieve the value you stored:

```
[secondary_label Output]
"It's working!"
```

After confirming that you can fetch the value, exit the Redis prompt to get back to the shell:

```custom_prefix(127.0.0.1:6379>)
exit
```

As a final test, we will check whether Redis is able to persist data even after it’s been stopped or restarted. To do this, first restart the Redis instance:

```command
sudo systemctl restart redis
```

Then connect with the command-line client again:

```command
redis-cli
```

And confirm that your test value is still available

```custom_prefix(127.0.0.1:6379>)
get test
```

The value of your key should still be accessible:

```
[secondary_label Output]
"It's working!"
```

Exit out into the shell again when you are finished:

```custom_prefix(127.0.0.1:6379>)
exit
```

With that, your Redis installation is fully operational and ready for you to use. However, some of its default configuration settings are insecure and provide malicious actors with opportunities to attack and gain access to your server and its data. The remaining steps in this tutorial cover methods for mitigating these vulnerabilities, as prescribed by the [official Redis website](http://redis.io/topics/security). Although these steps are optional and Redis will still function if you choose not to follow them, it is *strongly* recommended that you complete them in order to harden your system’s security.


## Step 3 — Binding to localhost

By default, Redis is only accessible from **localhost**. However, if you installed and configured Redis by following a different tutorial than this one, you might have updated the configuration file to allow connections from anywhere. This is not as secure as binding to **localhost**.

To correct this, open the Redis configuration file for editing:

```command
sudo nano /etc/redis/redis.conf
```

Locate this line and make sure it is uncommented (remove the `#` if it exists):

```
[label /etc/redis/redis.conf]
bind 127.0.0.1 ::1
```

Save and close the file when finished (press `CTRL + X`, `Y`, then `ENTER`).

Then, restart the service to ensure that systemd reads your changes:

```command
sudo systemctl restart redis
```

To check that this change has gone into effect, run the following `netstat` command:

```command
sudo netstat -lnp | grep redis
```
```
[secondary_label Output]
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      14222/redis-server  
tcp6       0      0 ::1:6379                :::*                    LISTEN      14222/redis-server  
```

<$>[note]
**Note**: The `netstat` command may not be available on your system by default. If this is the case, you can install it (along with a number of other handy networking tools) with the following command:

```command
sudo apt install net-tools
```
<$>

This output shows that the `redis-server` program is bound to **localhost** (`127.0.0.1`), reflecting the change you just made to the configuration file. If you see another IP address in that column (`0.0.0.0`, for example), then you should double check that you uncommented the correct line and restart the Redis service again.

Now that your Redis installation is only listening in on **localhost**, it will be more difficult for malicious actors to make requests or gain access to your server. However, Redis isn’t currently set to require users to authenticate themselves before making changes to its configuration or the data it holds. To remedy this, Redis allows you to require users to authenticate with a password before making changes via the Redis client (`redis-cli`). 


## Step 4 — Configuring a Redis Password

Configuring a Redis password enables one of its two built-in security features — the `auth` command, which requires clients to authenticate to access the database. The password is configured directly in Redis's configuration file, `/etc/redis/redis.conf`, so open that file again with your preferred editor:

```command
sudo nano /etc/redis/redis.conf
```

Scroll to the `SECURITY` section and look for a commented directive that reads:

```
[label /etc/redis/redis.conf]
. . .
# requirepass foobared
. . .
```

Uncomment it by removing the `#`, and change `foobared` to a secure password. 

<$>[note]
**Note:** Above the `requirepass` directive in the `redis.conf` file, there is a commented warning:

```
[label /etc/redis/redis.conf]
. . .
# Warning: since Redis is pretty fast an outside user can try up to
# 150k passwords per second against a good box. This means that you should
# use a very strong password otherwise it will be very easy to break.
#
. . .
```

Thus, it’s important that you specify a very strong and very long value as your password. Rather than make up a password yourself, you can use the `openssl` command to generate a random one, as in the following example. By piping the output of the first command to the second `openssl` command, as shown here, it will remove any line breaks produced by that the first command:

```command
openssl rand 60 | openssl base64 -A
```

Your output should look something like:

```
[secondary_label Output]
RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE
```

After copying and pasting the output of that command as the new value for `requirepass`, it should read:

```
[secondary_label /etc/redis/redis.conf]
requirepass <^>RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE<^>
```
<$>

After setting the password, save and close the file, then restart Redis:

```command
sudo systemctl restart redis.service
```

To test that the password works, open up the Redis client:

```command
redis-cli
```

The following shows a sequence of commands used to test whether the Redis password works. The first command tries to set a key to a value before authentication:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

That won't work because you didn’t authenticate, so Redis returns an error:

```
[secondary_label Output]
(error) NOAUTH Authentication required.
```

The next command authenticates with the password specified in the Redis configuration file:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```

Redis acknowledges:

```
[secondary_label Output]
OK
```

After that, running the previous command again will succeed:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```
```
[secondary_label Output]
OK
```

`get key1` queries Redis for the value of the new key.

```custom_prefix(127.0.0.1:6379>)
get key1
```
```
[secondary_label Output]
"10"
```

After confirming that you’re able to run commands in the Redis client after authenticating, you can exit `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
quit
```

Next, we'll look at renaming Redis commands which, if entered by mistake or by a malicious actor, could cause serious damage to your machine.


## Step 5 — Renaming Dangerous Commands

The other security feature built into Redis involves renaming or completely disabling certain commands that are considered dangerous.

When run by unauthorized users, such commands can be used to reconfigure, destroy, or otherwise wipe your data. Like the authentication password, renaming or disabling commands is configured in the same `SECURITY` section of the `/etc/redis/redis.conf` file.

Some of the commands that are considered dangerous include: `FLUSHDB`, `FLUSHALL`, `KEYS`, `PEXPIRE`, `DEL`, `CONFIG`, `SHUTDOWN`, `BGREWRITEAOF`, `BGSAVE`, `SAVE`, `SPOP`, `SREM`, `RENAME`, and `DEBUG`. This is not a comprehensive list, but renaming or disabling all of the commands in that list is a good starting point for enhancing your Redis server’s security.

Whether you should disable or rename a command depends on your specific needs or those of your site. If you know you will never use a command that could be abused, then you may disable it. Otherwise, it might be in your best interest to rename it.

To rename or disable Redis commands, open the configuration file once more:

```command
sudo nano  /etc/redis/redis.conf
```

<$>[warning]
**Warning:** The following steps showing how to disable and rename commands are examples. You should only choose to disable or rename the commands that make sense for you. You can review the full list of commands for yourself and determine how they might be misused at [redis.io/commands](http://redis.io/commands).
<$>

To disable a command, simply rename it to an empty string (signified by a pair of quotation marks with no characters between them), as shown below:

```
[label /etc/redis/redis.conf]
. . .
# It is also possible to completely kill a command by renaming it into
# an empty string:
#
<^>rename-command FLUSHDB ""<^>
<^>rename-command FLUSHALL ""<^>
<^>rename-command DEBUG ""<^>
. . .
```

To rename a command, give it another name as shown in the examples below. Renamed commands should be difficult for others to guess, but easy for you to remember:

```
[label /etc/redis/redis.conf]
. . .
# rename-command CONFIG ""
<^>rename-command SHUTDOWN SHUTDOWN_MENOT<^>
<^>rename-command CONFIG ASC12_CONFIG<^>
. . .
```

Save your changes and close the file.

After renaming a command, apply the change by restarting Redis:

```command
sudo systemctl restart redis.service
```

To test the new command, enter the Redis command line:

```command
redis-cli
```

Then, authenticate:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```
```
[secondary_label Output]
OK
```

Let’s assume that you renamed the `CONFIG` command to `ASC12_CONFIG`, as in the preceding example. First, try using the original `CONFIG` command. It should fail, because you’ve renamed it:

```custom_prefix(127.0.0.1:6379>)
config get requirepass
```
```
[secondary_label Output]
(error) ERR unknown command `config`, with args beginning with: 
```

Calling the renamed command, however, will be successful. It is not case-sensitive:

```custom_prefix(127.0.0.1:6379>)
asc12_config get requirepass
```
```
[secondary_label Output]
1) "requirepass"
2) "<^>your_redis_password<^>"
```

Finally, you can exit from `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
exit
```

Note that if you're already using the Redis command line and then restart Redis, you'll need to re-authenticate. Otherwise, you'll get this error if you type a command:

```
[secondary_label Output]
NOAUTH Authentication required.
```

<$>[warning]
Regarding the practice of renaming commands, there's a cautionary statement at the end of the `SECURITY` section in `/etc/redis/redis.conf` which reads:

```
[label /etc/redis/redis.conf]
. . .
# Please note that changing the name of commands that are logged into the
# AOF file or transmitted to replicas may cause problems.
. . .
```

***Note:*** *The Redis project chooses to use the terms “master” and “slave,” while DigitalOcean generally prefers the alternatives “primary” and “secondary.” In order to avoid confusion we’ve chosen to use the terms used in the Redis documentation here.*

That means if the renamed command is not in the AOF file, or if it is but the AOF file has not been transmitted to slaves, then there should be no problem.

So, keep that in mind when you're trying to rename commands. The best time to rename a command is when you're not using AOF persistence, or right after installation, that is, before your Redis-using application has been deployed.

When you're using AOF and dealing with a master-slave installation, consider [this answer from the project's GitHub issue page](https://github.com/antirez/redis/issues/2783). The following is a reply to the author's question:

> The commands are logged to the AOF and replicated to the slave the same way they are sent, so if you try to replay the AOF on an instance that doesn't have the same renaming, you may face inconsistencies as the command cannot be executed (same for slaves).

Thus, the best way to handle renaming in cases like that is to make sure that renamed commands are applied to all instances in master-slave installations. 
<$>


## Conclusion

In this tutorial, you installed and configured Redis, validated that your Redis installation is functioning correctly, and used its built-in security features to make it less vulnerable to attacks from malicious actors.

Keep in mind that once someone is logged in to your server, it's very easy to circumvent the Redis-specific security features we've put in place. Therefore, the most important security feature on your Redis server is your firewall (which you configured if you followed the prerequisite [Initial Server Setup](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-20-04#step-4-%E2%80%94-setting-up-a-basic-firewall) tutorial), as this makes it extremely difficult for malicious actors to jump that fence.

Redis is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install and configure Redis on an Ubuntu 20.04 server.

How To Install and Secure Redis on Ubuntu 20.04

This tutorial provides instructions for installing Redis on a CentOS 8 server and using its built-in security features, in coordination with some other security configurations, to keep it from being accessed by unauthorized users.

How To Install and Secure Redis on CentOS 8

22.04

### Introduction

[Redis](https://redis.io/) is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install, configure, and secure Redis on an Ubuntu 22.04 server.

## Prerequisites

To complete this guide, you will need access to an Ubuntu 22.04 server that has a non-root user with `sudo` privileges and a firewall configured with `ufw`. You can set this up by following our [Initial Server Setup guide for Ubuntu 22.04](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-22-04).


## Step 1 — Installing and Configuring Redis

We'll use the APT package manager to install redis from the official Ubuntu repositories. As of this writing, the version available in the default repositories is <^>6.0.16<^>.

Begin by updating your local `apt` package cache:

```command
sudo apt update
```

Then install Redis by typing:

```command
sudo apt install redis-server
```

This will download and install Redis and its dependencies. Following this, there is one important configuration change to make in the Redis configuration file, which was generated automatically during the installation.

Open this file with your preferred text editor:

```command
sudo nano /etc/redis/redis.conf
```

Inside the file, find the `supervised` directive. This directive allows you to declare an init system to manage Redis as a service, providing you with more control over its operation. The `supervised` directive is set to `no` by default. Since you are running Ubuntu, which uses the [systemd](https://en.wikipedia.org/wiki/Systemd) init system, change this to `systemd`:

```
[label /etc/redis/redis.conf]
. . .

# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
#   supervised no      - no supervision interaction
#   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
#   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
#   supervised auto    - detect upstart or systemd method based on
#                        UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal "process is ready."
#       They do not enable continuous liveness pings back to your supervisor.
supervised <^>systemd<^>

. . .
```

That’s the only change you need to make to the Redis configuration file at this point, so save and close it when you are finished. If you used `nano` to edit the file, do so by pressing `CTRL + X`, `Y`, then `ENTER`.

Then, restart the Redis service to reflect the changes you made to the configuration file:

```command
sudo systemctl restart redis.service
```

With that, you’ve installed and configured Redis and it’s running on your machine. Before you begin using it, though, it’s prudent to first check whether Redis is functioning correctly.


## Step 2 — Testing Redis

As with any newly-installed software, it’s a good idea to ensure that Redis is functioning as expected before making any further changes to its configuration. We will go over a handful of ways to check that Redis is working correctly in this step.

Start by checking that the Redis service is running:

```command
sudo systemctl status redis
```

If it is running without any errors, this command will produce output similar to the following:

```
[secondary_label Output]
● redis-server.service - Advanced key-value store
     Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2022-04-20 20:40:52 UTC; 4s ago
       Docs: http://redis.io/documentation,
             man:redis-server(1)
   Main PID: 2899 (redis-server)
     Status: "Ready to accept connections"
      Tasks: 5 (limit: 2327)
     Memory: 2.5M
        CPU: 65ms
     CGroup: /system.slice/redis-server.service
             └─2899 "/usr/bin/redis-server 127.0.0.1:6379
. . .
```

This output indicates that Redis is running and is already enabled, meaning that it is set to start up every time the server boots.

<$>[note]
**Note:** This setting is desirable for many common use cases of Redis. If, however, you prefer to start up Redis manually every time your server boots, you can configure this with the following command:

```command
sudo systemctl disable redis
```
<$>

To test that Redis is functioning correctly, connect to the server using `redis-cli`, Redis's command-line client:

```command
redis-cli
```

In the prompt that follows, test connectivity with the `ping` command:

```custom_prefix(127.0.0.1:6379>)
ping
```
```
[secondary_label Output]
PONG
```

This output confirms that the server connection is still alive. Next, check that you’re able to set keys by running:

```custom_prefix(127.0.0.1:6379>)
set test "It's working!"
```
```
[secondary_label Output]
OK
```

Retrieve the value by typing:

```custom_prefix(127.0.0.1:6379>)
get test
```

Assuming everything is working, you will be able to retrieve the value you stored:

```
[secondary_label Output]
"It's working!"
```

After confirming that you can fetch the value, exit the Redis prompt to get back to the shell:

```custom_prefix(127.0.0.1:6379>)
exit
```

As a final test, we will check whether Redis is able to persist data even after it’s been stopped or restarted. To do this, first restart the Redis instance:

```command
sudo systemctl restart redis
```

Then connect with the command-line client again:

```command
redis-cli
```

And confirm that your test value is still available

```custom_prefix(127.0.0.1:6379>)
get test
```

The value of your key should still be accessible:

```
[secondary_label Output]
"It's working!"
```

Exit out into the shell again when you are finished:

```custom_prefix(127.0.0.1:6379>)
exit
```

With that, your Redis installation is fully operational and ready for you to use. However, some of its default configuration settings are insecure and provide malicious actors with opportunities to attack and gain access to your server and its data. The remaining steps in this tutorial cover methods for mitigating these vulnerabilities, as prescribed by the [official Redis website](http://redis.io/topics/security). Although these steps are optional and Redis will still function if you choose not to follow them, it is *strongly* recommended that you complete them in order to harden your system’s security.


## Step 3 — Binding to localhost

By default, Redis is only accessible from **localhost**. However, if you installed and configured Redis by following a different tutorial than this one, you might have updated the configuration file to allow connections from anywhere. This is not as secure as binding to **localhost**.

To correct this, open the Redis configuration file for editing:

```command
sudo nano /etc/redis/redis.conf
```

Locate this line and make sure it is uncommented (remove the `#` if it exists):

```
[label /etc/redis/redis.conf]
. . .
bind 127.0.0.1 ::1
. . .
```

Save and close the file when finished (press `CTRL + X`, `Y`, then `ENTER`).

Then, restart the service to ensure that systemd reads your changes:

```command
sudo systemctl restart redis
```

To check that this change has gone into effect, run the following `netstat` command:

```command
sudo netstat -lnp | grep redis
```
```
[secondary_label Output]
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      14222/redis-server  
tcp6       0      0 ::1:6379                :::*                    LISTEN      14222/redis-server  
```

<$>[note]
**Note**: The `netstat` command may not be available on your system by default. If this is the case, you can install it (along with a number of other handy networking tools) with the following command:

```command
sudo apt install net-tools
```
<$>

This output shows that the `redis-server` program is bound to **localhost** (`127.0.0.1`), reflecting the change you just made to the configuration file. If there is another IP address in that column (`0.0.0.0`, for example), then you should double check that you uncommented the correct line and restart the Redis service again.

Now that your Redis installation is only listening in on **localhost**, it will be more difficult for malicious actors to make requests or gain access to your server. However, Redis isn’t currently set to require users to authenticate themselves before making changes to its configuration or the data it holds. To remedy this, Redis allows you to require users to authenticate with a password before making changes via the Redis client (`redis-cli`).


## Step 4 — Configuring a Redis Password

Configuring a Redis password enables one of its two built-in security features — the `auth` command, which requires clients to authenticate to access the database. The password is configured directly in Redis's configuration file, `/etc/redis/redis.conf`, so open that file again with your preferred editor:

```command
sudo nano /etc/redis/redis.conf
```

Scroll to the `SECURITY` section and find a commented directive that reads:

```
[label /etc/redis/redis.conf]
. . .
# requirepass foobared
. . .
```

Uncomment it by removing the `#`, and change `foobared` to a secure password.

<$>[note]
**Note:** Above the `requirepass` directive in the `redis.conf` file, there is a commented warning:

```
[label /etc/redis/redis.conf]
. . .
# Warning: since Redis is pretty fast an outside user can try up to
# 150k passwords per second against a good box. This means that you should
# use a very strong password otherwise it will be very easy to break.
#
. . .
```

Thus, it’s important that you specify a very strong and very long value as your password. Rather than make up a password yourself, you can use the `openssl` command to generate a random one, as in the following example. By piping the output of the first command to the second `openssl` command, as shown here, it will remove any line breaks produced by that the first command:

```command
openssl rand 60 | openssl base64 -A
```

This command will return output like this:

```
[secondary_label Output]
RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE
```

After copying and pasting the output of that command as the new value for `requirepass`, it should read:

```
[secondary_label /etc/redis/redis.conf]
requirepass <^>RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE<^>
```
<$>

After setting the password, save and close the file. Then restart Redis:

```command
sudo systemctl restart redis.service
```

To test that the password works, open up the Redis client:

```command
redis-cli
```

The following shows a sequence of commands used to test whether the Redis password works. The first command tries to set a key to a value before authentication:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```

That won't work because you didn’t authenticate, so Redis returns an error:

```
[secondary_label Output]
(error) NOAUTH Authentication required.
```

The next command authenticates with the password specified in the Redis configuration file:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```

Redis acknowledges:

```
[secondary_label Output]
OK
```

After that, running the previous command again will succeed:

```custom_prefix(127.0.0.1:6379>)
set key1 10
```
```
[secondary_label Output]
OK
```

`get key1` queries Redis for the value of the new key.

```custom_prefix(127.0.0.1:6379>)
get key1
```
```
[secondary_label Output]
"10"
```

After confirming that you’re able to run commands in the Redis client after authenticating, you can exit `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
quit
```

Next, we'll go over renaming Redis commands which, if entered by mistake or by a malicious actor, could have serious impacts on your data.


## Step 5 — Renaming Dangerous Commands

The other security feature built into Redis involves renaming or completely disabling certain commands that are considered dangerous.

When run by unauthorized users, such commands can be used to reconfigure, destroy, or otherwise wipe your data. Like the authentication password, renaming or disabling commands is configured in the same `SECURITY` section of the `/etc/redis/redis.conf` file.

Some of the commands that are considered dangerous include: `FLUSHDB`, `FLUSHALL`, `KEYS`, `PEXPIRE`, `DEL`, `CONFIG`, `SHUTDOWN`, `BGREWRITEAOF`, `BGSAVE`, `SAVE`, `SPOP`, `SREM`, `RENAME`, and `DEBUG`. This is not a comprehensive list, but renaming or disabling all of the commands in that list is a good starting point for enhancing your Redis server’s security.

Whether you should disable or rename a command depends on your specific needs or those of your site. If you know you will never use a command that could be abused, then you may disable it. Otherwise, it might be in your best interest to rename it.

To rename or disable Redis commands, open the configuration file once more:

```command
sudo nano  /etc/redis/redis.conf
```

<$>[warning]
**Warning:** The following steps showing how to disable and rename commands are examples. You should only choose to disable or rename the commands that make sense for you. You can review the full list of commands for yourself and determine how they might be misused at [redis.io/commands](http://redis.io/commands).
<$>

To disable a command, rename it to an empty string (signified by a pair of quotation marks with no characters between them), as shown below:

```
[label /etc/redis/redis.conf]
. . .
# It is also possible to completely kill a command by renaming it into
# an empty string:
#
<^>rename-command FLUSHDB ""<^>
<^>rename-command FLUSHALL ""<^>
<^>rename-command DEBUG ""<^>
. . .
```

To rename a command, give it another name as shown in the examples below. Renamed commands should be difficult for others to guess, but easy for you to remember:

```
[label /etc/redis/redis.conf]
. . .
# rename-command CONFIG ""
<^>rename-command SHUTDOWN SHUTDOWN_MENOT<^>
<^>rename-command CONFIG ASC12_CONFIG<^>
. . .
```

Save your changes and close the file.

After renaming a command, apply the change by restarting Redis:

```command
sudo systemctl restart redis.service
```

To test the new command, enter the Redis command line:

```command
redis-cli
```

Then, authenticate:

```custom_prefix(127.0.0.1:6379>)
auth <^>your_redis_password<^>
```
```
[secondary_label Output]
OK
```

Let’s assume that you renamed the `CONFIG` command to `ASC12_CONFIG`, as in the preceding example. First, try using the original `CONFIG` command. It should fail, because you’ve renamed it:

```custom_prefix(127.0.0.1:6379>)
config get requirepass
```
```
[secondary_label Output]
(error) ERR unknown command `config`, with args beginning with:
```

Calling the renamed command, however, will be successful. It is not case-sensitive:

```custom_prefix(127.0.0.1:6379>)
asc12_config get requirepass
```
```
[secondary_label Output]
1) "requirepass"
2) "<^>your_redis_password<^>"
```

Finally, you can exit from `redis-cli`:

```custom_prefix(127.0.0.1:6379>)
exit
```

Note that if you're already using the Redis command line and then restart Redis, you'll need to re-authenticate. Otherwise, you'll get this error if you type a command:

```
[secondary_label Output]
NOAUTH Authentication required.
```

<$>[warning]
**Warning**: Regarding the practice of renaming commands, there's a cautionary statement at the end of the `SECURITY` section in `/etc/redis/redis.conf` which reads:

```
[label /etc/redis/redis.conf]
. . .
# Please note that changing the name of commands that are logged into the
# AOF file or transmitted to replicas may cause problems.
. . .
```
<$>
<$>[note]
**Note:** The Redis project chooses to use the terms “master” and “slave,” while DigitalOcean generally prefers the alternatives “primary” and “secondary.” In order to avoid confusion we’ve chosen to use the terms used in the Redis documentation here.
<$>
<$>[warning]
That means if the renamed command is not in the AOF file, or if it is but the AOF file has not been transmitted to slaves, then there should be no problem.

So, keep that in mind when you're trying to rename commands. The best time to rename a command is when you're not using AOF persistence, or right after installation, that is, before your Redis-using application has been deployed.

When you're using AOF and dealing with a master-slave installation, consider [this answer from the project's GitHub issue page](https://github.com/antirez/redis/issues/2783). The following is a reply to the author's question:

> The commands are logged to the AOF and replicated to the slave the same way they are sent, so if you try to replay the AOF on an instance that doesn't have the same renaming, you may face inconsistencies as the command cannot be executed (same for slaves).

Thus, the best way to handle renaming in cases like that is to make sure that renamed commands are applied to all instances in master-slave installations.
<$>


## Conclusion

In this tutorial, you installed and configured Redis, validated that your Redis installation is functioning correctly, and used its built-in security features to make it less vulnerable to attacks from malicious actors.

Keep in mind that once someone is logged in to your server, it's very easy to circumvent the Redis-specific security features we've put in place. Therefore, the most important security feature on your Redis server is your firewall (which you configured if you followed the prerequisite [Initial Server Setup](https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-22-04#step-4-setting-up-a-firewall) tutorial), as this makes it extremely difficult for malicious actors to jump that fence.

Redis is an in-memory key-value store known for its flexibility, performance, and wide language support. This tutorial demonstrates how to install, configure, and secure Redis on an Ubuntu 22.04 server.

How To Install and Secure Redis on Ubuntu 22.04

Manager, Developer Education

Developer Advocate

Sign up for Infrastructure as a Newsletter.

Working on improving health and education, reducing inequality, and spurring economic growth? DigitalOcean would like to help.

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

You get paid; we donate to tech nonprofits.

DigitalOcean makes it simple to launch in the cloud and scale up as you grow – whether you’re running one virtual machine or ten thousand.

Community

Company

Contact

Products

Solutions

DigitalOcean Kubernetes: new control plane is faster and free, enable HA for 99.95% uptime SLA