loader

Complete Guide: Installing and Securing Redis on Debian 10

Complete Guide: Installing and Securing Redis on Debian 10

Introduction:

This guide shows you how to set up Redis on a Debian 10 server. Redis is like a super-fast storage system that can handle lots of data and works with many different programming languages. We’ll cover installing Redis, setting it up just right, and making sure it’s secure.

Preparation: Before You Begin

Before we start, you’ll need a Debian 10 server. Make sure you have a user account with special permissions called “sudo.” Also, set up a basic firewall. If you haven’t done this yet, check out our Initial Server Setup guide.

Once you’re set up, log in to your server using your special user account with sudo privileges, and then you can get started.

Step 1: Installing Redis and Setting it Up

To make sure we have the newest version of Redis, we’ll use a tool called apt to get it from the official Debian sources.

Here’s what you need to do:

  1. First, update your system’s list of available software.
  2. Then, install Redis by running a command.
sudo apt update
sudo apt install redis-server
Copy

After you run the command, Redis and all the stuff it needs will be downloaded and installed onto your system. Next, there’s one important thing we need to change in a file that Redis created for us automatically.

Let’s open up that file using your favorite text editor.

sudo nano /etc/redis/redis.conf
Copy

In the file, look for something called “supervised”. This tells Redis how to manage itself like a service, giving you more control over it. By default, this setting is “no”. But because you’re using Debian, which uses systemd to manage services, you’ll want to change it to “systemd”.

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

. . .

Copy

That’s all you have to do in the Redis configuration file for now. Just save your changes and close the file. Then, make sure those changes take effect by reloading the Redis service file.

sudo systemctl restart redis
Copy

Now that you’ve installed and set up Redis, it’s up and running on your computer. But before you start using it, let’s make sure everything is working as it should.

Step 2 — Evaluating Redis

Before moving forward with any adjustments, it’s important to confirm that Redis is working properly after installation. We’ll explore a few simple methods to ensure Redis is up and running.

Begin by verifying that the Redis service is active:

sudo systemctl status redis
Copy

If Redis is running smoothly, running this command will show something like this:

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
. . .

Copy

Here, you’ll notice that Redis is up and running, and it’s set to start automatically whenever the server restarts.

(Note: This setup is great for most Redis uses. But if you want to start Redis yourself each time the server starts, you can do it like this:)

sudo systemctl disable redis
Copy

To check if Redis is working right, let’s connect to the server using the command-line tool:

redis-cli
Copy

In the window that appears, check if everything’s connected by typing “ping” and pressing Enter:

ping
Copy
Output
PONG
Copy

This message shows that the connection to the server is active. Now, let’s make sure you can add information by typing:

set test "It's working!"
Copy
Output
OK
Copy

Get the value back by typing:

get test
Copy

If everything is working fine, you should see the value you stored earlier:

Output
"It's working!"
Copy

Once you’ve checked that you can get the value, leave the Redis prompt to return to the regular shell:

exit
Copy

For the last test, let’s see if Redis can remember data even if it’s turned off and then back on. To start, restart the Redis instance:

sudo systemctl restart redis
Copy

Next, connect to Redis again using the command-line tool and make sure your test value is still there:

redis-cli
Copy
get test
Copy

You should still be able to retrieve the value you stored earlier:

Output
"It's working!"
Copy

Once you’re done, exit back to the regular shell:

exit
Copy

Now, your Redis setup is all set up and ready for action. But there are some default settings that might not be very safe. They could give bad guys a chance to mess with your server or data. The next steps in this guide will help make your Redis more secure, following suggestions from the official Redis website. These steps aren’t necessary, but it’s a good idea to do them to make sure your system stays safe.

Step 3 — Restricting Access to Localhost

By default, Redis can only be accessed from your own computer. But if you followed another guide and changed settings to allow connections from anywhere, it’s less safe.

To fix this, let’s open up the Redis settings file for editing:

sudo nano /etc/redis/redis.conf
Copy

Find this line and make sure it’s active (remove the # if there is one):

/etc/redis/redis.conf
bind 127.0.0.1
Copy

Once you’re done, save the changes and close the file by pressing CTRL + X, then Y, and finally hitting ENTER.

After that, restart the service so that your changes are applied:

sudo systemctl restart redis
Copy

To confirm if the change has taken effect, use the following netstat command:

sudo netstat -lnp | grep redis
Copy
Output
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      10959/redis-server
Copy

This result confirms that the Redis program is now tied to localhost (127.0.0.1), which means it’s only accessible from your own computer. If you see a different IP address there (like 0.0.0.0), it means the change might not have been applied correctly. Check if you removed the comment from the right line in the settings file and restarted Redis.

With Redis now only listening to localhost, it’s harder for bad actors to sneak in and mess with your server. But right now, Redis doesn’t ask users to prove who they are before making changes to its settings or data. To fix this, Redis lets you set up a password. Users will have to enter this password before they can make any changes using the Redis command-line tool (redis-cli).

Step 4 — Setting Up a Password for Redis

Setting up a password for Redis adds a layer of security called the “auth command.” This makes sure that clients have to prove who they are before they can use the database. To do this, you need to go back to the Redis settings file, which is usually found at /etc/redis/redis.conf. Let’s open that file again using your favorite text editor:

sudo nano /etc/redis/redis.conf
Copy

Go to the part of the file labeled “SECURITY.” Look for a line that starts with a hashtag (#) and mentions the directive we need:

etc/redis/redis.conf
# requirepass foobared
Copy

Find the line in that section that begins with a “#” and has “foobared” written after it. Remove the “#” to activate the line. Then, replace “foobared” with a password that you’ll remember and is hard for others to guess.

(Note: Before the “requirepass” line in the redis.conf file, you’ll see a comment with a 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.
#

Copy

It’s crucial to pick a super strong and really long password. Instead of creating one yourself, you can use a command called openssl to generate a random one. Here’s an example of how to do it. By using the first command and then piping its output to the second openssl command, any line breaks produced by the first command will be removed.

openssl rand 60 | openssl base64 -A
Copy

The result you see should be similar to this:

Output
RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE
Copy

Once you’ve copied and pasted the output of that command as the new value for “requirepass,” it should look like this:

/etc/redis/redis.conf
requirepass RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE
Copy

Once you’ve set the password, save and close the file. After that, restart Redis:

sudo systemctl restart redis.service
Copy

To check if the password works, open the Redis command line:

redis-cli
Copy

Here’s a series of steps to test if the Redis password works. The first command tries to set a key to a value without authenticating:

set key1 10
Copy

If you try to set a key without logging in first, Redis will give you an error.

Output
(error) NOAUTH Authentication required.
Copy

Next, you’ll use a command to log in with the password you set in the Redis configuration file:

auth your_redis_password
Copy

Redis will acknowledge your authentication:

Output
OK
Copy

Then, if you try the previous command again, it should work this time:

set key1 10
Copy
Output
OK
Copy

Use the command “get key1” to ask Redis for the value of the new key.

get key1
Copy
Output
"10"
Copy

Once you’ve made sure that you can run commands in the Redis client after logging in, you can leave the redis-cli:

quit
Copy

Now, we’ll discuss renaming Redis commands. This helps prevent accidental or malicious use of commands that could harm your system.

Step 5 — Changing Risky Commands

Redis also has another security feature. It involves changing the names or even turning off certain commands that could be dangerous.

If unauthorized users run these commands, they could mess up or delete your data. Just like setting the authentication password, you can change or disable commands in the same part of the Redis settings file (/etc/redis/redis.conf).

There are certain commands in Redis that are risky to use, like FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME, and DEBUG. This list isn’t exhaustive, but changing or disabling these commands is a good way to make your Redis server more secure.

Deciding whether to disable or rename a command depends on what you need or what your website needs. If you’re sure you’ll never use a command that might cause trouble, you can turn it off. Otherwise, it’s usually safer to rename it.

To change or disable Redis commands, open the settings file again:

sudo nano  /etc/redis/redis.conf
Copy

(Warning: The steps below, explaining how to disable and rename commands, are just examples. You should only decide to disable or rename the commands that are suitable for your needs. You can check the complete list of commands on redis.io/commands and figure out how they could be misused.)

To turn off a command, you just need to rename it to an empty string. Here’s how you do it:

/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 ""
. . .

Copy

To rename a command, simply choose a new name for it. Make sure it’s something that others would have a hard time guessing but easy for you to remember. Here are a few examples:

/etc/redis/redis.conf
. . .
# rename-command CONFIG ""
rename-command SHUTDOWN SHUTDOWN_MENOT
rename-command CONFIG ASC12_CONFIG
. . .

Copy

Once you’ve made the changes, save and close the file.

After renaming a command, make sure to restart Redis to apply the changes:

sudo systemctl restart redis
Copy

To check if the new command works, open the Redis command line:

redis-cli
Copy

Next, log in:

auth your_redis_password
Copy
Output
OK
Copy

Let’s say you renamed the CONFIG command to ASC12_CONFIG, as shown before. Try using the original CONFIG command first. It should not work because you changed its name:

config get requirepass
Copy
Output
(error) ERR unknown command 'config'
Copy

Using the renamed command, however, will work. Remember, it’s not case-sensitive:

asc12_config get requirepass
Copy
Output
1) "requirepass"
2) "your_redis_password"
Copy

Lastly, you can exit the redis-cli by typing:

exit
Copy

If you’re already using the Redis command line and you restart Redis, you’ll need to log in again. Otherwise, if you try to use a command, you’ll get an error like this:

Output
NOAUTH Authentication required.
Copy

At the end of the SECURITY section in /etc/redis/redis.conf, there’s a warning that says:

Be careful when renaming commands that are logged into the AOF file or sent to slaves. Changing their names might cause issues.

The Redis project uses terms like “master” and “slave,” while DigitalOcean tends to use different terms. To avoid confusion, we’re using the terms used in the Redis documentation here.

So, if the renamed command isn’t in the AOF file, or if it is but hasn’t been sent to slaves yet, then everything should be fine.

Remember this when you’re renaming commands: It’s safest to do it when you’re not using AOF persistence or right after you install Redis, before you start using it for your application.

If you’re using AOF and dealing with a master-slave setup, consider this advice from the Redis project’s GitHub issue page. Here’s a reply to a similar question:

If you rename commands, remember that they’re logged in the AOF and sent to the slave exactly as they’re used. So, if you try to replay the AOF on a system where the command has a different name, you might run into problems because the renamed command won’t work (same goes for slaves).

To avoid issues, it’s best to ensure that any renamed commands are applied to all instances in master-slave setups.

Conclusion:

In this guide, you’ve set up and secured Redis, ensuring it’s less susceptible to attacks from bad actors. Remember, if someone gains access to your server, they could easily bypass Redis-specific security measures we’ve applied.

The most crucial security measure is your firewall (which you hopefully configured using the Initial Server Setup tutorial). It acts like a strong fence, making it very hard for bad actors to get in.

To stay safe, always keep your firewall up and monitor your server’s activity regularly.

If you haven’t set up your firewall yet, follow our Initial Server Setup tutorial now!

image

A cloud for entire journey

Bring your team together. No contracts, no commitments.

image

Copyright ©2023 Design & Developed by Cloudtopiaa