Looking for a way to install Redis on Centos 7? We will help you.

Installation of Redis o Centos 7 does not merely consist of its installation, yet adjusting some server settings like firewall and file permissions to ensure security.

As a part of our Server Management Services, we help our Customers to perform Redis installations regularly.

Let us today discuss the steps to perform this task.

 

How to install Redis on Centos7?

We can easily install Redis using the yum command after adding the EPEL ( Extra Packages for Enterprise Linux) repository server’s package list.

We can install EPEL using yum:

$ sudo yum install epel-release

$ sudo yum install redis -y

This may take a few minutes to complete. After the installation finishes, start the Redis service and to make Redis start on boot, we can enable it with the enable command:

$ sudo systemctl start redis.service
$ sudo systemctl enable redis

Then confirm the status of redis with the command below:

$ sudo systemctl status redis.service

After confirming that the Redis is running, test the setup with this command:

$ redis-cli ping

This should print PONG as the response. If this is the case, it means we now have Redis running on your server and we can begin configuring it to enhance its security.

Binding Redis and Securing it with a Firewall

Redis does not have a robust security feature of its own. An effective way to safeguard Redis is to secure the server it is running on. This can be done by restricting the binding of Redis to localhost or to a private IP address.  Also, the server should have a firewall up and running.

To do this, open the Redis configuration file for editing and locate the line beginning with bind and make sure to uncomment it:

$ sudo vi /etc/redis.conf
bind 127.0.0.1

We recommend avoiding binding Redis to a public IP address as it increases the exposure of your Redis interface to outside parties. Instead, we could choose a private IP address.

To access Redis from another host, we will need to make some changes to your firewalld configuration using the firewall-cmd command. To begin, add a dedicated Redis zone to the firewalld policy:

$ sudo firewall-cmd –permanent –new-zone=redis

Then, specify which port we like to have open. Redis uses port 6379 by default:

$ sudo firewall-cmd –permanent –zone=redis –add-port=6379/tcp

Next, specify any private IP addresses to pass through the firewall and access Redis:

$ sudo firewall-cmd –permanent –zone=redis –add-source=client_server_private_IP

After running those commands, reload the firewall to implement the new rules:

$ sudo firewall-cmd –reload

Configuring a Password after Redis install on Centos 7

Configuring a Redis password requires clients to authenticate before being allowed access to the database. Similar to the bind setting, the configuration of password is in Redis’s configuration file, /etc/redis.conf. Now, we need to open that file:

$ sudo vi /etc/redis.conf

Then, scroll to the SECURITY section and look for a commented directive that reads:

# requirepass foobared

Now, uncomment it by removing the #, and change foobared to a very strong password of your choosing.

After setting the password, save and close the file then restart Redis. To test that the password works, access the Redis command line:

$ redis-cli

The following command authenticates with the password specified in the Redis configuration file.

127.0.0.1:6379> auth your_redis_password

After that, run the key1 command.

127.0.0.1:6379> set key1 10

Renaming Dangerous Commands after Redis install on Centos 7

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.

To enable or disable Redis commands, open the configuration file for editing:

$ sudo vi /etc/redis.conf

To disable or kill a command, simply rename it to an empty string,  for instance, to rename FLUSHDB, use the following format:

rename-command FLUSHDB “”

Save your changes and close the file, and then apply the change by restarting Redis:

$ sudo systemctl restart redis.service

The best way to handle renaming in cases of master-slave is to make sure that renamed commands are applied to all instances of master-slave installations.

Setting Data Directory Ownership and File Permissions

A couple of ownership and permissions changes can be made to improve the security profile of your Redis installation. We need to make 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 searching for the Redis data directory in a long listing of its parent directory with the commands below.

$ ls -l /var/lib | grep redis

You will 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:

$ 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:

$ ls -l /etc/redis.conf

This presents a security issue as the configuration file contains the unencrypted password, 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:

$ 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:

$ sudo chmod 600 /etc/redis.conf

Finally, restart Redis.

[Need any further assistance in Redis installation? – We’re available 24*7]

Conclusion

In short, Redis does not have a robust security feature of its own. Thus, it is important to adjust the security settings in the server during its installation to prevent attacks. Today, we saw how our Support Engineers perform this task.