## 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:
```sh
sudo nano /etc/redis/redis.conf
```
> **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](https://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:
```plaintext
/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:
```plaintext
/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:
```sh
sudo systemctl restart redis.service
```
To test the new command, enter the Redis command line:
```sh
redis-cli
```
Then, authenticate:
```sh
auth your_redis_password
```
```plaintext
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:
```sh
config get requirepass
```
```plaintext
(error) ERR unknown command `config`, with args beginning with:
```
Calling the renamed command, however, will be successful. It is not case-sensitive:
```sh
asc12_config get requirepass
```
```plaintext
1) "requirepass"
2) "your_redis_password"
```
Finally, you can exit from `redis-cli`:
```sh
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:
```plaintext
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:
```plaintext
/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 EcoStack Cloud 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. 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 tutorial), as this makes it extremely difficult for malicious actors to jump that fence.
---
