Advanced Redis Security — Redis Roadmap

Photo by sebastiaan stam on Unsplash

Integrity, Cipher Suites and TLS Versioning

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:

Integrity

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).

Cipher Suites

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
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES256-GCM-SHA384
Session-ID: 4D393366B34716ACD82F93DB93609518D60C8BC151D4E264A1D042CC2279094F
Session-ID-ctx:
Master-Key: 1866AABD439A956B090F0DAD38DC34720D8CFA1D2CAEBAF58E1135D02279EFF231237A6B91A0714F6C1A0438C8FAAA6A
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.

TLS Versions

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

Security Maintenance

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.

Account Management

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.

Password Management

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:

  1. ACL user passwords
  2. AUTH passwords (required for backwards compatibility)

If Redis is deployed in cluster mode:

  1. 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
  1. AUTH passwords
a.  This may apply to sentinel, client to server, or replica to master interactions (MasterAUTH)

Software Maintenance

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:

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 port or tls-port directive in the redis.conf file.

Changing the default port is not supported at runtime using the CONFIG command.

Redis Production Security Checklist

Standalone and Cluster Mode

  1. Ensure Redis is always deployed inside a trusted network.
  2. Ensure protected mode is on unless ACLs or AUTH is enabled.
  3. Ensure the Redis Log file is configured.
  4. Ensure Redis is run as a non-privileged user.
  5. Ensure Redis files are given a non-privileged group
  6. Ensure Redis logs, files and configurations are not readable or writable by others on the operating system.
  7. Ensure the Redis Log file is rotated.
  8. Ensure Redis configuration files are not accessible by others, such as 740 permissions.
  9. Ensure you leverage the latest Redis client and server version.
  10. Consider IP restrictions through the network or operating system to ensure only trusted IPs can connect to Redis.
  11. Consider using client side encryption to encrypt sensitive data.
  12. Consider if TLS is right for your use case.
  13. Consider changing the default Redis port
  14. Consider backing up RDB and AOF files to a remote external location.
  15. Ensure you select the right persistence method for your use case.
  16. Consider sending Redis log files to syslog.

Cluster Mode Only

  1. Ensure that an odd number of at least 3 nodes are deployed in the cluster
  2. Ensure any reboot schedules do not reboot enough nodes at the same time to lose quorum.

Account Management

Standalone and Cluster Mode

  1. Ensure AUTH or ACLs are enabled.
  2. Ensure all users have a strong password.
  3. Ensure the default user is disabled, unless required for backwards compatibility.
  4. Ensure the @dangerous command category is excluded from all users and dangerous commands are given on a case by case basis.
  5. Ensure that an external ACL file is used to configure ACLs.
  6. Ensure that users configured in an external ACL file or the redis.conf file store passwords in hashed format.
  7. Ensure that the requirepass is only set if backwards compatibility is required.
  8. Consider if all ACL users are configured to least privilege.
  9. Consider renaming commands to disable them entirely

Cluster Mode Only

  1. Ensure that masteruser is used for authentication to masters.
  2. Ensure that sentinel auth-user is used if you are using sentinel.

Transport layer Security

Standalone & Cluster Mode

  1. Ensure non-TLS ports are disabled.
  2. Ensure strong cipher suites are used with Redis.
  3. Ensure appropriate modern TLS protocols are used.
  4. Ensure client authentication is used.
  5. Ensure server ciphers are prefered.
  6. Ensure TLS is configured for replication
  7. Ensure key files are given 400 permissions.
  8. Ensure key files are owned by the Redis user.

Cluster Mode Only

  1. Ensure TLS is enabled on the cluster bus

See you in next article…

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store