Protecting Redis ​

This section discusses the security risks associated with using Redis and measures to prevent data leakage, loss, and unauthorized access.

Command Safety ​

Redis has several dangerous commands that can severely impact stability and data safety. For instance, the keys command can cause Redis to hang, while flushdb and flushall can wipe all data. To mitigate human error, Redis offers the rename-command directive in the configuration file. You can rename risky commands to obscure names:

rename-command keys abckeysabc

This means you must use abckeysabc instead of keys. To disable a command entirely, rename it to an empty string:

rename-command flushall ""

Port Security ​

By default, Redis listens on *:6379. If the server has a public IP, Redis becomes exposed to the internet, making it vulnerable to scanning and attacks. To prevent this, specify the listening IP address in the Redis configuration:

bind 10.100.20.13

Additionally, you can add password protection so that clients must authenticate before accessing Redis:

requirepass yoursecurepasswordhereplease

This password requirement also extends to replicas, which need the masterauth directive:

masterauth yoursecurepasswordhereplease

Lua Script Security ​

Developers should avoid allowing user-generated content (UGC) to form Lua scripts, as this can be exploited to execute malicious code. Running Redis as a non-root user can further mitigate risks from potential vulnerabilities.

SSL Proxy ​

Redis does not natively support SSL connections, meaning data transmitted over the internet can be intercepted. If Redis must operate over public networks, consider using an SSL proxy. While SSH is a common choice, Redis recommends using the spiped tool for its simplicity and effectiveness:

This proxy can also facilitate secure replication between master and slave instances across different networks.