Advanced Redis Security — Redis Roadmap
Integrity, Cipher Suites and TLS Versioning
openssl-ciphers, ciphers - SSL cipher display and cipher list tool. The ciphers command converts textual OpenSSL cipher…
Command Line Utilities
The openssl program provides a rich variety of commands, each of which often has a wealth of options and arguments…
We’ll briefly discuss integrity, and we’ll round out this overview of TLS by talking about cipher suites and TLS versions. Recall that TLS provide three assurances:
First, TLS provides privacy through the use of encryption.
Second, TLS provides authentication through the use of encryption, digital certificates, and certificate authorities.
Lastly, TLS provides message integrity. Let’s define this here. Message integrity means two things:
1. That the message has not been tampered with.
2. That the message was produced by a given sender.
To understand integrity, we need to remember how TLS establishes an encrypted connection.
First, TLS uses an asymmetric-key cipher to securely establish a shared encryption key. The client and server then switch to a symmetric-key cipher, which uses that shared encryption key to securely encrypt and decrypt data.
In addition to the symmetrically encrypted data, each party also attaches a cryptographic signature known as a message authentication code, or MAC for short. You can think of a message authentication code as a secure checksum for encrypted data.
The party receiving the data can use this message authentication code to cryptographically verify two things:
First: that the data has not been tampered with during transmission
And second: that the data has been encrypted by someone who possesses the shared encryption key (and not, we hope, by an attacker).
If we take a step back now, we’ll see that TLS actually relies on several cryptographic algorithms:
First, there’s the asymmetric-key cipher and its associated key exchange protocol.
Next, there’s the digital signature algorithm that’s used to authenticate a certificate.
After that, you have a symmetric-key cipher.
And finally, there’s a message authentication code, which is used to check the integrity of messages.
As you might expect, there are many different implementations of each of these cryptographic algorithms. For example, with symmetric-key ciphers, there’s the Advanced Encryption Standard (which is commonly known as AES), the Triple-DES, and Camellia, among others.
What this all means is that when you initiate a TLS connection, your client and server need to agree on which implementations they’re going to use.
The set of specific cryptographic implementations used for a given TLS connection is called a cipher suite.
When you connect to a server using TLS, your client and server will agree on a specific cipher suite. You can use the openssl command-line utility to see which cipher suite is used when you connect to <>wikipedia.org. Here is what you would run:
openssl s_client -connect wikipedia.org:443
And here is part of the output you might see if you run this command:
Server public key is 256 bit
Secure Renegotiation IS supported
No ALPN negotiated
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES256-GCM-SHA384
TLS session ticket lifetime hint: 86400 (seconds)
Under SSL-Session/Cipher, you’ll see a series of acronyms (ECDHE-ECDSA-AES256-GCM-SHA384). This is the cipher suite, and again, what’s specified here are the algorithms used in the asymmetric key and symmetric key ciphers, digital signature algorithms, and message authentication codes for this TLS session.
Another thing you’ll notice here is the TLS version. In the sample output, you can see what we’re connected using TLS version 1.2. The TLS version is also negotiated when we make a TLS connection.
TLS 1.0 and TLS 1.1 are legacy and generally not used.
TLS 1.2 is the most widely used of the TLS protocols, and TLS 1.3 is the current modern standard.
TLS 1.3 improves upon TLS 1.2 in a couple of ways: First, it’s slightly faster initially because it requires fewer network round trips when negotiating the connection.
Second, TLS 1.3 requires more sophisticated cipher suites that TLS 1.2.
So by now you should know the different building blocks of TLS. Obviously, we’ve just scratched the surface here. But if you’ve managed to grasp these basic ideas, then you’ll be in a much better position to understand what you’re doing when you configure TLS for Redis.
Security Maintenance and Advanced Hardening
The code we base modern applications on is always changing, and this introduces new problems frequently. In the case of open-source projects like Redis, this code may be reviewed at any time, by anyone in the world. Security researchers frequently find new ways to attack old code.
The security maintenance tasks you need to worry about when running Redis include account management and security patching for both clients and servers.
As your Redis deployment ages, permissions and accounts are bound to become irrelevant. Part of account management is the continuous review of ACL users to ensure they have appropriate permissions and still require access to Redis.
If these accounts are no longer needed or the permissions are no longer appropriate, then the accounts should be removed or their permissions should be modified. Implementing a process to continuously review your Redis ACL users will help you to meet compliance standards as you use Redis. Many organizations conduct reviews quarterly or bi-annually; however, it’s best to follow your organization’s policy.
You should use the
ACL LIST command to review your Redis ACL users and permissions as well as review your
redis.conf file and external ACL file.
If your organization requires regular password rotation, then there are several Redis passwords you should keep in mind.
If Redis is deployed in standalone mode, consider:
- ACL user passwords
- AUTH passwords (required for backwards compatibility)
If Redis is deployed in cluster mode:
- ACL user passwords
a. This applies to the master user for replica to master interactions
b. This applies to the sentinel user
c. This applies to all ACL users
- AUTH passwords
a. This may apply to sentinel, client to server, or replica to master interactions (MasterAUTH)
Redis continuously receives code modifications, some of which may contain security updates. Because the impact to your deployment may vary depending on the update, it’s best to ensure that you are always on the latest stable version of Redis.
You can check what Redis version you are on using the
INFO command. At the top of the output will be the Redis version that you are on. You can compare this to the latest stable version that you can find on the Redis downloads website at:
Stable releases liberally follow the usual major.minor.patch semantic versioning schema. Unstable This is where all the…
The Redis client of your choice should be kept up to date for the same reasons, and how to upgrade and check your client will be different depending on the client that you use. There is one other important consideration for your client. Because Redis clients are maintained by a broad community of open-source maintainers, it’s important that when selecting a client you ensure that the client is actively maintained.
Changing the Redis Port
The default Redis port is
6379. This well-known port is frequently the target of automated attacks. Unless you are targeted by a motivated attacker directly, modifying the Redis port can be a way to ensure that scripts run against systems searching for vulnerabilities do not target you.
Changing the Redis port is as simple as modifying the
tls-port directive in the
Changing the default port is not supported at runtime using the
Redis Production Security Checklist
Standalone and Cluster Mode
- Ensure Redis is always deployed inside a trusted network.
- Ensure protected mode is on unless ACLs or AUTH is enabled.
- Ensure the Redis Log file is configured.
- Ensure Redis is run as a non-privileged user.
- Ensure Redis files are given a non-privileged group
- Ensure Redis logs, files and configurations are not readable or writable by others on the operating system.
- Ensure the Redis Log file is rotated.
- Ensure Redis configuration files are not accessible by others, such as
- Ensure you leverage the latest Redis client and server version.
- Consider IP restrictions through the network or operating system to ensure only trusted IPs can connect to Redis.
- Consider using client side encryption to encrypt sensitive data.
- Consider if TLS is right for your use case.
- Consider changing the default Redis port
- Consider backing up RDB and AOF files to a remote external location.
- Ensure you select the right persistence method for your use case.
- Consider sending Redis log files to syslog.
Cluster Mode Only
- Ensure that an odd number of at least 3 nodes are deployed in the cluster
- Ensure any reboot schedules do not reboot enough nodes at the same time to lose quorum.
Standalone and Cluster Mode
- Ensure AUTH or ACLs are enabled.
- Ensure all users have a strong password.
- Ensure the default user is disabled, unless required for backwards compatibility.
- Ensure the
@dangerouscommand category is excluded from all users and dangerous commands are given on a case by case basis.
- Ensure that an external ACL file is used to configure ACLs.
- Ensure that users configured in an external ACL file or the
redis.conffile store passwords in hashed format.
- Ensure that the
requirepassis only set if backwards compatibility is required.
- Consider if all ACL users are configured to least privilege.
- Consider renaming commands to disable them entirely
Cluster Mode Only
- Ensure that
masteruseris used for authentication to masters.
- Ensure that sentinel
auth-useris used if you are using sentinel.
Transport layer Security
Standalone & Cluster Mode
- Ensure non-TLS ports are disabled.
- Ensure strong cipher suites are used with Redis.
- Ensure appropriate modern TLS protocols are used.
- Ensure client authentication is used.
- Ensure server ciphers are prefered.
- Ensure TLS is configured for replication
- Ensure key files are given
- Ensure key files are owned by the Redis user.
Cluster Mode Only
- Ensure TLS is enabled on the cluster bus
Learn Redis with Free Online Courses
Learn about Redis for free from the experts at Redis. Engaging courses covering data structures, streams, search…
See you in next article…