How to Secure Redis: Prevent Common Attacks and Harden Your Deployment

Redis is a high‑performance key‑value database that has become extremely popular in recent years, and its widespread use has introduced a range of security concerns, with attackers often leveraging Redis to launch attacks.

Redis General Security Modules

Redis is designed to be accessed only by trusted machines in trusted environments. Exposing it directly to the Internet or to any untrusted host via TCP or Unix socket is unsafe.

For example, many web applications use Redis as a database, cache, or message system. In such cases the web client can trigger Redis queries, meaning an untrusted client indirectly accesses Redis.

In general, untrusted Redis connections should be monitored, user input validated, and operations limited, because Redis prioritises simplicity and speed over strong security.

Network Security

Redis should only be reachable by trusted clients. The server running Redis should be accessed only from machines that run the Redis‑using application. For instances directly exposed to the Internet (e.g., virtual Linux VMs on Linode, EC2, etc.), the Redis port must be blocked by a firewall, while allowing local‑loopback access.

Adding the following line to redis.conf binds Redis to the loopback interface and prevents external access: bind 127.0.0.1 Because Redis is designed for speed, leaving it open to the Internet is a serious risk; a simple FLUSHALL command could delete all data.

Authentication Mechanism

If you do not want to rely on network restrictions, Redis provides an authentication feature that can be enabled in the redis.conf file.

When authentication is enabled, Redis rejects all commands from unauthenticated clients. Clients must issue the AUTH command with a password.

The password is stored in plain text in the configuration file and should be long enough to resist brute‑force attacks for two reasons:

Redis processes millions of password attempts per second.
The password is stored in the configuration file and in client memory, so a long password does not impose a usability burden.

Authentication provides a second layer of protection in case firewall rules fail; an external device still cannot access Redis without the password.

Note that the AUTH command is transmitted in clear text, so it does not protect against eavesdropping on the internal network.

Data Encryption Support

Redis does not provide built‑in encryption. Trusted clients that need encrypted communication over the Internet must use an external encryption layer such as SSL/TLS.

Disabling Specific Commands

It is possible to disable or rename certain Redis commands, limiting what clients can execute.

For hosted Redis services, ordinary users should not be able to run configuration commands, while the provider’s management system retains that capability.

Commands can be renamed or disabled in redis.conf. Examples:

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

Or to completely disable a command:

rename-command CONFIG ""

Attacks Triggered by Precise Input

Even without direct access, attackers can exploit Redis by inserting crafted data via internal functions. For instance, a web form can submit a set of strings to the same hash stack, turning an O(1) operation into O(n), consuming CPU and causing a DoS.

Redis assigns a random hash seed per request to mitigate this.

The SORT command uses a quick‑sort algorithm that is not randomized; carefully crafted input can cause secondary execution of commands.

String Escaping and NoSQL Injection

Redis protocol does not include string‑escaping mechanisms, so traditional injection attacks are not applicable. The protocol uses length‑prefixed binary strings, and Lua scripts executed via EVAL or EVALSHA follow the same rules, making them safe.

However, applications should avoid feeding untrusted data into Lua scripts.

Code Security

In a typical Redis setup, clients can execute any command, but they should never gain the ability to control the host system. Redis follows secure coding practices to prevent buffer overflows and memory corruption.

Nevertheless, the CONFIG command allows clients to change the working directory and dump file name, potentially enabling arbitrary file writes and code execution.

Redis does not need to run as root and should not be started with root privileges. The developers are investigating a new configuration option to restrict CONFIG SET/GET for directories and other runtime settings, which would block arbitrary dump file writes.

GPG Key

Security researchers can submit issues on GitHub and, if the issue is critical, add a GPG signature at the end of the document.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.13 (Darwin)

mQINBFJ7ouABEAC5HwiDmE+tRCsWyTaPLBFEGDHcWOLWzph5HdrRtB//UUlSVt9P
... (key content omitted for brevity) ...
-----END PGP PUBLIC KEY BLOCK-----

Key fingerprint:

pub   4096R/0E5C88D6 2013-11-07 [expires: 2063-10-26]
      Key fingerprint = E5F3 DA80 35F0 2EC1 47F9  020F 3181 3728 0E5C 88D6
      uid                  Salvatore Sanfilippo <[email protected]>
      sub   4096R/3B34D15F 2013-11-07 [expires: 2063-10-26]