Redis Security
This post provides an introduction to security from a Redis perspective, covering topics such as access control, malicious attacks, and more.
For more security topics please open an issue in GitHub, or when you rely heavily on security, use GPG as described at the end of the article.
Redis general security mode
Redis is designed to allow access by trusted clients. This means exposing Redis to the internet, or an environment where an untrusted client can access Redis TCP or UNIX sockets is not good.
For example, in a common web application environment, Redis is used as a database, cache or message system, and the front end of the web application requests Redis data and generates pages or executes user requests. In this case, the web application becomes the bridge to access Redis without trusting the front-end profile. This is a special case, but large access to Redis by untrusted objects should always be directed by application layers that implement ACLs, validate user input, or determine actions to be performed on Redis. In general, Redis is optimized for performance rather than security.
cyber security
The Redis port should deny access to clients other than trusted clients in the network, so the Redis server should only communicate with the application deployment server developed based on Redis. Generally speaking, a single server is directly exposed to the Internet and should be protected by a firewall, and clients are accessed through the loopback interface.
Add the following line to redis.conf to bind Redis to a single interface.
bind 127.0.0.1
Failure to secure the Redis port will have a significant impact, which is determined by the nature of Redis. For example, a flushall can be used externally by an attacker to delete all data in a database.
protected mode
Unfortunately, most users are left unprotected so that Redis can be accessed externally. Too much Redis is simply exposed on the Internet. For this reason, starting from version 3.2.0, when Redis uses the default configuration and is not password protected, we call it protected mode.
In protected mode, Redis only responds to requests to bind ip clients, and other clients that connect externally will respond with errors, and explain why and guide customers to configure Redis correctly.
We expect that safe mode can be used to reduce security problems caused by unprotected Redis instances performing operations without administrator privileges, but system administrators can ignore these error prompts and disable safe mode or manually modify the configuration to bind all access ip .
Verified Features
Redis does not implement access control, it provides a small authentication layer that the user can optionally configure in redis.conf. Once secure authentication is turned on, Redis will reject any requests from unauthenticated clients. Client-side security authentication uses the auth command followed by a password. The password in it is configured in redis.conf and should be long enough to prevent brute force cracking for the following reasons:
1) Redis responds to requests very fast. Most passwords can be verified in one second.
2) The Redis password is stored in redis.conf or can be configured using the client side and does not need to be remembered by the system administrator, so it can be long enough.
Password authentication provides a redundant multiple authentication in case of firewall or protection failure, Redis can still be protected. The auth command is transmitted unencrypted, so it is not immune to network theft.
Data encryption support
Redis does not support encryption. In order to implement a setup where trusted clients can access the Internet or other untrusted networks, an additional layer of protection, such as the SSL protocol, needs to be implemented. Spided is recommended .
Disable special commands
A command in Redis can be disabled or renamed to something less guessable. For example, suppose a virtual machine provider needs to provide management services for Redis. In this case, ordinary users should not be able to use the config command to change the configuration of Redis on the virtual machine. But the system itself can use special fame and fortune to achieve these functions.
In this case, we can mask out the command in the command table or rename it. This feature can be declared in the redis.conf file as follows:
rename-command config b840fc02d524045429941cc15f59e41cb7be6c52
In the above example, the config command was renamed to a value that is unlikely to be guessed. If you want to block it, just rename it to an empty string:
rename-command config ""
external input attack
There is a class of attacks where an attacker does not need access to Redis but just chooses the appropriate input to achieve an external attack. These attacks can insert data into Redis and modify the complex logic of Redis internal data structures.
For example, an attacker can inject a large amount of data into the hash table in Redis in the form of a web, increasing its time complexity from O(1) to O(n), thereby exhausting the server's CPU and causing the service suspended animation. To solve this problem, Redis generates a random hash seed before each execution.
In Redis, the sort command uses the logic of quicksort. So far, the algorithm is not random, so in the worst case a quadratic level of performance is achieved by choosing suitable inputs.
String Overflow Nosql Injection
There is no concept of string overflow in the Redis protocol, so under normal circumstances, injection using normal client libraries is impossible, and the protocol is binary safe.
Lua scripts executed via the eval and evalsha commands follow the same rules, so these commands are also safe. But one thing to be aware of is that lua scripts need to avoid generating scripts for strings obtained from untrusted sources.
code security
In a typical Redis setup, clients allow access to all command sets, but access to Redis does not control the system Redis is on.
Internally, Redis is well known for keeping code safe from buffer overflows, formatting errors, or other memory issues. But using the command config gives the client the ability to change the working directory and the name of the dump file, which is a serious security issue, and it may change the location of the file dump at will.
Redis does not require root privileges to run. We recommend using normal privileged users for this purpose. The authors of Redis are working on securing config set/get dir and other runtime configuration parameters with a new configuration parameter.