Redis database vulnerability protection

Redis is a high-performance database, and Redis Redis Crackit on security vulnerabilities due to the nature of Redis own lack of security protection mechanism , while users of Redis and have not followed the official safety regulations caused.

Redis security vulnerabilities

For the protection of security vulnerabilities, many large data-oriented application architecture (NOSQL, Caching) there are similar problems. These architectures early in the design did not take into account the relevant security issues, or set the application environment architecture does not allow exposure to the public scene. However, most users during the deployment and use of these application architecture, it seems to ignore these problems, then the order with the use of continuous improvement, the attacker eyeing them one day.

so, the key event of security breaches Redis Redis is not in itself, but rather the use of skills, and this method is to exploit Redis Redis of Antirez own father released. Later, the use of methods and PoC, the attackers used, so Redis Crackit event occurred.

Redis security exploits

In the event of Redis security vulnerability, the attacker uses the following way exploit:

By ssh- to generate a pair of keygen key pair, the public key is then written to a temporary file, data redis emptied, the contents of the temporary file is written redis, 
then redis config command provided by storage file to the authorized_keys, this will linux system to cover the whole authorized_keys, 
and finally through the key registration.

Redis vulnerability affects

Once the invasion success, Redis data is lost, the attacker can be added directly account for ssh remote login control server, Redis will give users run Linux host environment and pose a security risk, causing significant data loss.

Redis safety testing

First, let's look at some common configuration redis through a few simple commands. The first step in detecting redis monitoring address, can be detected by the following command:

root@kali:~# netstat -anp|grep 6379
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      12377/redis-server`   

As can be seen from the above example redis listening on any port address of 6379, while the process is running a number 12377, then we look at the user redis run, can be achieved by the ps command.

`root@kali:~# ps -elf|grep 12377
5 S root     12377     1  0  80   0 -  8979 -      03:39 ?        00:00:00 redis-server     /etc/redis/redis.conf`  

It can be seen as the root user redis running. After reading the user to run, and then we see redis whether a corresponding password, can be achieved through the following command:

root@kali:~# redis-cli -h 192.168.10.212
redis 192.168.10.212:6379> keys *
1) "1"`        

From the keys *output perspective, there is no reported not permit errors, indicating not set a user name, password, of course, these configurations can also be viewed from redis configuration file, the default configuration file /etc/redis/redis.conf.

If your configuration substantially as, root users to run, listening on any address, has not yet set a complex password, then you have to quickly reinforced, not only in this way can even outside the shell, and even get ssh connection.

Redis reinforcement

Mentioned in redis common safety testing methods common to see several security configuration, and then explains how to construct and use redis to implement ssh login, which redis involved crackit Do not experiment, one will clear redis data, the second It is covered by the original authorized_keys, resulting in failure of previous key. So the most important thing is how to harden your redis, he went on to describe the following redis reinforcement, mainly related to the network, authentication, privilege separation, renaming important commands.

Network Reinforcement

Bind 127.0.0.1

redis default is listening on 127.0.0.1, if only local communication, be sure to monitor locally. In this way ease the risk redis, of course, does not guarantee absolute safety, and if the attacker has a webshell, and redis run as the root user, you can bounce shell through the redis, to achieve privilege escalation. In /etc/redis/redis.confthe configuration is as follows:

`bind 127.0.0.1` 

Set up a firewall

If you need to access other machines, or set the slave mode, then remember to add the corresponding firewall settings, the command is as follows:

`iptables -A INPUT -s x.x.x.x -p tcp --dport 6379 -j ACCEPT`

If it's even easier Ubuntu, ufw get directly.

Authenticate

redis not enabled by default password authentication, plus redis run fast, one second can run tens of thousands of passwords, password use is not generally large. How to open it? Or open /etc/redis/redis.conf configuration file, write requirepass @nsF0cus!@#

Such authentication password will be provided for @nsF0cus!@#, must ensure adequate password complexity, Redis do not limit the number and frequency. After doing a password authentication, save redis.conf, restart redis (/etc/init.d/redis-server restart), you need to perform auth @nsF0cus!@#, for example:

root@kali:~# redis-cli -h 192.168.10.212
redis 192.168.10.212:6379> keys *
(error) ERR operation not permitted
redis 192.168.10.212:6379> auth @nsF0cus!@#
OK` 

Highly recommended to construct a password, the password difficult to guess basically by sha256sum, after all, we do not need to remember this password, you can simply configure in the configuration file.

root@kali:~# echo -e "xxlegend"|sha256sum
b59869cac63a67e7ee97e6923a75811ff58bd4936ed3be3480b46145d43ae335`

Low-privilege account

A separate set of accounts redis necessary, redis crackit on the use of the characteristics of the root user to reset authorized_keys. First create a redis account, and then start through the account.

setsid sudo -u redis /usr/bin/redis-server /etc/redis/redis.conf

After the start should be as follows:

root@kali:~# ps -elf|grep redis
1 S redis    14720     1  0  80   0 -  8979 -      08:40 ?        00:00:00 /usr/bin/redis-server /etc/re

Renaming a number of important command

Since redis did not do the basic privilege separation, no management accounts, sub-accounts of the ordinary, so go after logging what actions can be done, it is an outrage. So you need to hide some dangerous operation, commands involved include

`FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME, DEBUG, EVAL` 

And wherein redis2.8.1 Redis Redis 3.x (<3.0.2) have eval sandbox escape vulnerabilities, lua any executable code. Set as follows, or edit the file redis.conf

rename-command CONFIG ""
rename-command flushall ""
rename-command flushdb ""
rename-command shutdown shutdown_dvwa

The above configuration config, flushdb, flushall set to null, which disables this command, we can also named some of the attackers is difficult to guess but easy to remember our own names. After saving, execution /etc/init.d/redis-server restart restart to take effect.

Remarks:

June 12, the Green League Remote Security Assessment System (NSFOCUS RSAS) After the upgrade, the Redis already detected vulnerabilities.

references:

(1)http://antirez.com/news/96

Reproduced please specify: "Transfer from NSFOCUS blog":  the original link .

Guess you like

Origin www.cnblogs.com/rinack/p/11099854.html
Recommended