Shulou(Shulou.com)06/01 Report--

Background

Among the many open source caching technologies, Redis is undoubtedly one of the most powerful and widely used caching technologies. Refer to the 2018 foreign database technology authoritative website DB-Engines on key-value database popularity ranking, Redis temporarily ranked first, but the native Redis version is very weak in security, many places do not meet security requirements, if exposed on the public network, it is extremely vulnerable to malicious × ×, resulting in data leakage and loss.

This paper mainly enhances the security features of the system on the basis of the native open source software Redis3.0, and many enhancements involve the modification of open source code. The security specification of Redis cache database described in the following chapters is theoretically applicable to all products that apply Redis.

This series consists of three parts and is divided into nine chapters. This paper expounds the strengthening measures of Redis cache database from three chapters: legal monitoring interface, undisclosed interface and access channel control.

1. Lawful listening interface 1.1 port uses a non-default port

Security problem: the default port for Redis Server listening is 6379, which is easy to be scanned.

Solution: modify to a non-default port and describe it in the port matrix.

1.2 listening addresses are not allowed to include *

Security issue: Redis supports snooping 0.0.0.0.

Solution: because if you have multiple network cards, you should set the listening address to the address of the network card that only the database client needs to connect to. If only local access is allowed, only 127.0.0.1 should be monitored.

1.3 hidden RedisCluster port

Security issues: the official RedisCluster solution adds a cluster port by default, and the client port is offset by 10000, which is a very hidden problem.

Solution: the additional cluster ports are described in the port matrix. Modify the source code to add a redis.conf offset configuration item cluster-port-increment, the default configuration + 1, so that the port range can be controlled to avoid conflicts.

2. Undisclosed interface 2.1 account management (important)

Security problem: there is only one oversubscriber in Redis and the permission is too large.

The solution: the principle of minimizing permissions, adding configuration items, distinguishing roles from oversubscribers, ordinary users and read-only users.

The actions that cannot be performed by ordinary users are:

2.2 Redis-cli Hidden password

Security issues: by specifying the-a parameter in redis-cli, the password will be ps, which belongs to sensitive information.

Solution: modify the Redis source code and hide the password immediately after main entry to avoid being ps. (refer to open source Mysql code)

2.3 instructions for the use of Redis-cli tools

The access methods such as commands / parameters and ports that need to be used in the maintenance phase of the existing network (including but not limited to the production, testing and maintenance purposes of the products) should be disclosed or restricted to customers or regulatory agencies through product data, etc.

2.4 it is forbidden to switch users to execute redis-cli through sudo in scripts.

Security issues: redis-cli access parameters with password-sensitive information will be ps, but also easy to be recorded by the system operation log.

Solution: secure access via API (Python can use redis-py) instead, and switching to dbuser account using redis-cli via sudo is prohibited.

Reproduction condition: the reproduction can be simulated by disabling the redis port through iptables.

3. Access channel control 3.1 pre-shared key authentication (important)

Security issues: Redis native authentication exists replay * ×: it's just a simple interaction with auth xxx

Solution: using pre-shared secret key (symmetric encryption algorithm + random number two-way authentication), while achieving maximum compatibility in the scheme design, so that the client transformation cost is minimum. At present, the platform supports clients: Java,Python,C,Lua.

The design of the scheme is as follows:

Redis authentication protocol changes, in which the auth command distinguishes two functions, which are distinguished by the first letter:

Pre-shared key authentication sequence diagram

Description: Redis is a text protocol, safe random number length is fixed to 32 bytes of displayable string, the delimiter that connects 2 random numbers is "@".

Main certification process:

1. The client executes the command to the server: authRAND_C

1) initials 1) get RAND_C and generate RAND_S

2) generate TokenBA=AES128 (RAND_S@RAND_C)

Description: the error is described as a secure random number generated by the server.

3. Client verification 1) verify whether TokenBA is legal

Decrypt the RAND_S@RAND_C to see if RAND_C is a self-generated random number br/ > 1) verify whether TokenBA is legal

Decrypt the RAND_S@RAND_C to see if RAND_C is a random number generated by itself.

3) call the authentication API: auth > TokenAB

4. Server authentication

1) verify whether TokenAB decrypts RAND_C@RAND_S, see if RAND_S is a self-generated random number br/ > decrypt RAND_C@RAND_S, and see if RAND_S is a self-generated random number.

3.2 add the library name to the authentication

Security problem: Redis does not have a library name. If the system only uses the user name and password, it is easy to guess and × ×.

Solution: bring the library name when passing the authentication, because the library name of each service is configured differently, and the complexity is increased. The authentication format is distinguished by dbname@dbuser@pwd.

3.3 Port Matrix

Security issues: Redis is also a database service, usually a process occupies one port, and the cluster will occupy an extra port.

Solution: write down the Redis port range applied by the system in the port matrix.

3.4 client authentication timeout

Security problem: native Redis does not limit the client authentication timeout, which is slow.

Solution: modify the source code to limit the success of authentication within 60 seconds, otherwise the server will actively disconnect.

Description: controls the upper limit of time to complete client authentication. This prevents invalid clients from occupying the connection channel for a long time.

3.5 support for SSL communication

Security problem: increasing SSL communication can improve the security of data transmission.

Solution:

1. Do not change the official source code, but deploy SSL Proxy on the client and server, similar to stunnel.

2. Support SSL configurability, which involves open source code modification.

Note: because Redis is interaction-intensive and processes tens of thousands of requests per second, there will be a great loss of performance after supporting SSL.

3.6 support for ACL control

Security issues: there is currently no ACL control for Redis.

Solution:

1. Currently, the secret key is shared based on the platform, in which the secret key is randomly generated, and each system is different, which indirectly achieves IP range control.

2. Further limit the range of access to IP through iptables control.

3. If you want to specifically control to the user + IP level, it is similar to Mysql authentication. Author antirez is aware of this problem and is expected to provide it in a future version, with the following link: Multi users AUTH and ACLs for Redis

3.7 Jedis client related

Security issues: officially recommended that the latest version of Java client Jedis cluster does not support authentication.

Solution: add authentication parameters, which are consistent with the shared secret key authentication of the server.

Security problem: the password of Jedis authentication API is parameter string.

Solution: add a set of char [] interfaces for Jedis client authentication.

3.8 RedisCluster related to cluster authentication is multi-master, multi-slave, and highly self-made internally, so the authentication masterauth of Redis needs to be encrypted and saved to the configuration file.

two。 When configuring cluster relationships, based on the Gossip protocol, Cluster meet needs to be protected by authentication.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.