Redis Research (13)-security and communication protocols, redis research communication protocols

Redis Research (13)-security and communication protocols, redis research communication protocols

I. Security

Salvatore Sanfilippo, author of Redis, once published the Redis declaration, which mentions Redis to be concise and beautiful. Redis does not do much work at the security level.

1. trusted environment
The Redis security design is based on the premise that "Redis runs in a trusted environment". During the production environment, the external parties cannot be directly connected to the Redis server, the application should be used for transit. Running in a trusted environment is the most important way to ensure Redis security.

Redis's default configuration will accept requests sent from any address, that is, starting the Redis server on any server with a public IP address can be directly accessed by the outside world. To change this setting, modify the bind parameter in the configuration file. To allow only local applications to connect to Redis, you can change the bind parameter:

bind 127.0.0.1

The bind parameter can be bound to only one address. To set access rules more freely, you must use the firewall.
Note: Redis 2.8 may support binding multiple addresses. For more information, see https://github.com/antirez/redis/issues/274.

2. Database Password
In addition, you can set a password for Redis by using the requirepass parameter in the configuration file. For example:

requirepass TAFK(@~!ji^XALQ(sYh5xIwTn5Ds7JF

The client sends a password every time it connects to Redis. Otherwise, Redis rejects the Command sent from the client. For example:

redis＞GET foo(error)ERR operation not permitted

Use the AUTH command to send the password, as shown in the following code:

AUTH TAFK(@~!ji^XALQ(sYh5xIwTn5Ds7JFOK

Then you can execute any command:

redis＞GET foo"1"

Because Redis has extremely high performance and Redis does not perform active latency after incorrect password is entered (considering Redis's single-thread model ), therefore, attackers can crack Redis passwords (tens of thousands of passwords can be tried within one second). Therefore, they must select a complicated password.
When configuring Redis replication, if a password is set for the primary database, you need to set the password for the primary database through the masterauth parameter in the configuration file of the database, in this way, the AUTH command is automatically used when the slave database is connected to the master database.

3. Naming commands
Redis supports renaming commands in the configuration file. For example, you can rename the FLUSHALL command into a complicated name to ensure that only your applications can use this command. Like this:

rename-command  FLUSHALL oyfekmjvmwxq5a9c8usofuo369x0it2k

If you want to directly disable a command, you can rename it as a Null String:

rename-command  FLUSHALL ""

Note: Whether you set a password or rename a command, you must ensure the security of the configuration file. Otherwise, it makes no sense.

Ii. Communication Protocol

Redis communication protocol is the language for communication between Redis clients and Redis. The communication protocol specifies the format of commands and return values. After understanding the Redis communication protocol, you can understand not only the AOF file format, but also the content sent from the master database to the slave database during master-slave replication, you can also develop your own Redis client (but there are not many opportunities to directly deal with Redis using communication protocols because almost all common languages have corresponding Redis clients ).

Redis supports two communication protocols, one is the binary secure unified request protocol (uniied request protocol), and the other is a simple protocol that is easy to input in the telnet program. These two protocols only have different command formats, and the format of command return values is the same.

1. Simple Protocol
The simple protocol is suitable for communicating with Redis In the telnet program. The Command Format of the simple protocol is to separate the command from each parameter using spaces, such as "EXISTS foo" and "SET foo bar. Because Redis parses simple protocols by simply separating parameters with spaces, binary characters cannot be entered. We can test through the telnet program:

telnet 127.0.0.1 6379Trying 127.0.0.1...Connected  to localhost.Escape character is '^]' .SET foo bar+OKGET foo$3barLPUSH plist 1 2 3:3LRANGE plist 0 -1*3$13$12$11ERRORCOMMAND-ERR unknown command  'ERRORCOMMAND'

For some commands earlier than Redis 2.4, you can use a special method similar to the simple protocol to enter binary security parameters, for example:

C:SET foo 3C:barS:+OK

C: indicates the content sent by the client, and S: indicates the content sent by the server. The last parameter in the first line indicates the length of the string, and the second line indicates the actual content of the string. Because the length is specified, the string in the second line can contain binary characters. However, this protocol has been abandoned and replaced by the new unified request protocol. The word "unified" means that all commands use the same request method instead of using special methods for some commands. If you need to include binary characters in a parameter, you should use the unified request protocol.

The Five Commands we entered in the telnet program exactly show the format of the Five return value types of Redis. The previous display format was encapsulated by redis-cli, the above content is the format actually returned by Redis. The following sections describe each other.

(1) Error Response
Error reply starts with-, followed by the error message, and ends with \ r \ n:

-ERR unknown command 'ERRORCOMMAND'\r\n

(2) Status reply
Status reply starts with +, follows the status information, and ends with \ r \ n:

+OK\r\n

(3) integer reply
Integer reply (integer reply) starts with:, followed by a number, and ends with \ r \ n:

:3\r\n

(4) string reply
String reply (bulk reply) starts with $, followed by the length of the string, separated by \ r \ n, followed by the content of the string and \ r \ n:

$3\r\nbar\r\n

If the returned value is null, the returned value $-1 is different from the Null String.

(5) multiline string reply
Multi-bulk reply starts with "*" and follows the number of groups replied to by the string, and is separated by \ r \ n. Then the specific content of the string reply is followed:

*3\r\n1\r\n3\r\n1\r\n2\r\n1\r\n1\r\n

2. Unified request protocol
The unified request protocol is added from Redis 1.2. Its Command Format and Multiline string reply format are similar, for example, the unified request protocol for SET foo bar is written as "* 3 \ r \ n3 \ r \ nSET \ r \ n3 \ r \ nfoo \ r \ n3 \ r \ nbar \ r \ n ". Or use telnet for Demonstration:

telnet 127.0.0.1 6379Trying 127.0.0.1...Connected to localhost.Escape character is '^]' .*3$3SET$3foo$3bar+OK

Similarly, the length of the subsequent string is specified when the command is sent. Therefore, each parameter of the command can contain binary characters. The format of the returned values of the unified request protocol is the same as that of the simple protocol.

The AOF file of Redis and the content sent from the master database to the slave database during master-slave replication both use the unified request protocol. If you want to develop a client that communicates directly with Redis, we recommend that you use this protocol. If you only want to send commands to the Redis server via telnet, you can use the simple protocol.