Security in Redis

Security model

Redis is intended for use by trusted clients in trusted environments. This means that exposing the Redis instance to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket is usually not a smart idea.

In the case of a web application that uses Redis as a database, cache, or messaging system, the clients in the front-end (web side) of the program would query Redis to generate pages or perform activities that the web application user has requested or triggered.

The web application mediates access between Redis and untrusted clients in this situation (the user browsers accessing the web application).

Untrusted access to Redis should, in general, be mediated by a layer that implements ACLs, validates user input, and decides what actions to do on the Redis instance.

Now let's talk about the network security

Network security

Access to the Redis port should be restricted to trusted clients on the network so that the servers hosting Redis are only accessible directly by the computers that are implementing the Redis-based application.

The Redis port should be firewalled to restrict access from the outside in the common case of a single computer directly exposed to the internet, such as a virtualized Linux instance (Linode, EC2,...) Clients will still be able to use the loopback interface to connect to Redis.

It's worth noting that you can bind Redis to a single interface by adding the following line to the redis.conf file:

bind 127.0.0.1

Because of the nature of Redis, failing to protect the Redis port from the outside can have a significant security impact. An external attacker might, for example, destroy the entire data set with a single FLUSHALL command.

Protected mode

Unfortunately, many users do not secure Redis instances from external network access. With public IPs, many instances are just left accessible on the internet. When Redis is run with the default configuration (binding all interfaces) and no password, it enters a special mode known as a protected mode. Redis only responds to queries from loopback interfaces in this mode, and clients connecting from other addresses receive an error message explaining the problem and how to correctly configure Redis.

We anticipate that the protected mode will significantly reduce the security risks associated with unprotected Redis instances that are run without proper administration.

The system administrator can, however, ignore Redis' error and disable protected mode, or manually bind all interfaces.

Authentication

While Redis does not attempt to provide Access Control, it does offer an optional layer of authentication that can be enabled by modifying the redis.conf file.

When the authorization layer is enabled, unauthenticated clients will be denied access to Redis. The AUTH command, followed by the password, can be used by a client to authenticate themselves.

The password is set in clear text in the redis.conf file by the system administrator. For two reasons, it should be long enough to prevent brute force attacks:

• Redis is extremely fast at responding to requests. An external client can test a large number of passwords per second.
• The password for Redis is saved in the redis.conf file as well as the client configuration. The password can be very long because the system administrator does not need to remember it.

The authentication layer's objective is to provide a layer of redundancy that may be turned on or off. An external client will still be unable to access the Redis instance without knowing the authentication password if firewalling or any other method established to protect Redis from external attackers fails.

Because the AUTH command, like all other Redis commands, is sent unencrypted, it is vulnerable to eavesdropping by an attacker with sufficient network access.

TLS support

TLS support is available for all communication channels in Redis, including client connections, replication links, and the Redis Cluster bus protocol.

Disallowing specific commands 

It is possible to disable commands in Redis or rename them with an unguessable name, limiting typical clients to a limited number of instructions.

A managed Redis instance service, for example, could be offered by a virtualized server provider. In this case, normal users should generally not be able to change the settings of the instance using the Redis CONFIG command, but systems that give and remove instances should be able to.

It is possible to rename or totally shadow commands from the command table in this circumstance. This feature can be accessed by a statement in the redis.conf configuration file. Consider the following scenario:

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

The CONFIG command was renamed to an unguessable name in the preceding example. It's also possible to make it (or any other command) utterly unusable by renaming it to the empty string, as in the following example:

rename-command CONFIG ""

Attacks triggered by malicious inputs from external clients

An attacker can launch a certain type of attack from the outside, even if they don't have access to the instance. An attacker could, for example, inject data into Redis that causes pathological (worst-case) algorithm complexity on data structures defined within Redis internals.

An attacker might use a web form to send a set of strings that are known to hash to the same bucket in a hash table, effectively turning the O(1) expected time (average time) into an O(N) worst-case scenario. This may require more CPU than anticipated, resulting in a Denial of Service.

Redis applies a per-execution, pseudo-random seed, to the hash function to prevent this specific attack. The qsort algorithm is used by Redis to implement the SORT command. Because the algorithm is currently not randomized, a quadratic worst-case behavior can be induced by carefully picking the proper set of inputs.

String escaping and NoSQL injection 

Because the Redis protocol has no concept of string escaping, injection using a standard client library is difficult in most cases. The protocol is binary-safe and uses prefixed-length strings.

The EVAL and EVALSHA commands are also safe because the Lua scripts they execute obey the same rules.

While it may seem unusual, the application should avoid assembling the Lua script's body with strings obtained from untrustworthy sources.

Code security

Clients have complete access to the command set in a traditional Redis configuration, but accessing the instance should never result in the ability to influence the system where Redis is executing. To prevent buffer overflows, format problems, and other memory corruption issues, Redis employs all of the well-known techniques for building secure code. The ability to manage the server settings using the CONFIG command, on the other hand, allows the client to change the program's working directory and the name of the dump file. Clients can now write RDB Redis files to whatever directory they choose. This is a security vulnerability that could allow an attacker to compromise the system and/or run untrusted programs as the same user as Redis. To run Redis, you don't need to be a root user. It's best to run it as a non-privileged Redis user that'll just be used for this.

Also Read - Cardinality In DBMS

Frequently asked questions

1. What is a Redis?
   Redis is an in-memory data structure store that can be used as a distributed, in-memory key-value database, cache, and message broker. Strings, lists, maps, sets, sorted sets, HyperLogLogs, bitmaps, streams, and spatial indices are among the abstract data structures supported by Redis.
    
2. Is Redis a cache or database?
   Although Redis was originally designed as a caching database, it has since developed into a primary database. Many modern applications use Redis as their primary database. Most Redis service providers, however, only provide Redis as a cache, not as a core database.
    
3. What are the disadvantages of Redis? 
   Clients connecting to the Redis cluster should be aware of the cluster topology, causing overhead configuration on Clients because data is sharded based on the hash slots allotted to each Master. If the master does not have at least one slave, failover does not occur.
    
4. How is data stored in Redis?
   Since Redis is an in-memory database, data is stored in memory (or RAM). If a server crashes, all the data stored is lost. Redis has backup mechanisms in place for the data on the disk. This way, the data is loaded from the disk to the memory when the server reboots
    
5. Is there any other Data Structures and Algorithms content in Coding Ninjas Studio?
   Yes, Coding Ninjas Studio allows you to practice coding as well as answer frequently asked interview questions. The more we practice, the more likely we are to acquire a job at our dream company.

Conclusion

In this article, we have extensively discussed the security in redis. We hope that this blog has helped you enhance your knowledge of ‘Redis’ and if you would like to learn more, check out our articles on Library where you can find everything about Databases, SQL Probelms, Interview Experiences and other guided paths. Do upvote our blog to help other ninjas grow. Happy Coding!”