The beauty of Redis is its simplicity, but that can be a problem where security is concerned. There is no strong password requirements, authentication backoff, encryption or alternatives to password authentication. That makes it critical to take some steps to secure your Redis instance. While Redis 6.0 will include TLS and some additional authentication enhancements, much of the below will still apply.
- Use a strong random password
- Secure access to your Redis endpoint
- VPN/Tunnel/Secure Proxy
- IP Whitelist/Blacklist
- Use IP reputation lists or honeypots
- Monitor and block failed auth attempts
- Use TLSv1.2
- Client certs
- Use magic packets for zero trust
- Use canary or rolling deployments
- Encrypt RDB/AOF
- Rotate passwords
Use a strong random password
We recommend at least 12 characters (mix upper, lower, digit). While special characters can add more security, having a random sequence will be just as effective and less likely to cause issues in your code, key vaults, etc.
Secure access to your Redis endpoint
Redis by default has no encryption on its endpoint, we always recommend security it in some way.
a. VPN/Tunnel/Secure Proxy
Using a VPN is a traditional means to secure P2P communication. Alternatively you can also use tunneling or even secure proxies. Any of the mechanisms work and usually it is best to use what your team is familiar with.
b. IP Whitelist/Blacklist
A whitelist says what IPs are allowed, while a blacklist identifies IPs that are not allowed. Blacklists are usually used with honeypots or known bad actor IPs. The main downside of IP lists are that IPs can be forged, it is a good layer to have, but should not be the only defense
c. Use IP reputation lists or honeypots
We use reputation lists to block known bad actors at our ingress point. This will block a good portion of known bad actors at a slight risk of blocking customers. Since most Redis access is from servers you control, the risk is very low of blocking valid access. Alternatively you can setup your own honeypot and maintain your own reputation database, but most people are fine with public lists.
d. Monitor and block failed auth attempts
This is a little more complicated as you have to either do a custom Redis build to capture auth failed events or do it at the proxy level. Most proxies have the ability to add a module, but will require custom code to monitor for the failed attempts.
e. Use TLSv1.2
For the vast majority of clients we recommend adding TLS to Redis and not allowing non-TLS connections. The overhead of TLS is very small on modern processors. The only exceptions usually are if the client encrypts data before sending it to Redis, or requires very high performance on a private network.
For even more security you can authenticate client certificates to only allow approved clients to gain access. Similar in effect to a VPN,
f. Use magic packets for zero trust
A magic packet is a specially formulated encrypted packet that identifies the source IP as trusted. The main advantage of a magic packet system is that to an attacker the system doesn’t even have any ports open. A port is only opened when the system receives a specially crafted UDP packet, and then it is generally only opened for a period of time for that IP address.
Use canary or rolling deployments
See our canary or rolling deployments blog post for more about how deployment can increase security
RDB an d AOF files are not encrypted by Redis, it is vital to store on encrypted drives, file-systems or use other encryption means
Unfortunately, Redis doesn’t have a robust password rotation mechanism. Generally you have to do something similar to the password backoff and do a custom build of Redis, manage password rotation in the client or handle it in a custom proxy implementation. Password recommendations are changing, and with other security mechanisms in this list you might be able to change passwords less frequently, but most SOC/PCI/NIST and other controls will require frequent password changes
Most clients use Redis to cache or store some kind of valuable information that needs to be secured. While Redis wouldn’t be considered secure without some work, implementing most of the recommendations above are fairly straightforward. As with many systems, the number one key is to limit network access and so using TLS plus one of; VPN/Tunnel/Certifications/Proxy/Magic Packet, should be considered best practice for the majority of Redis users.