Now it is more and more common to use redis to cache hot data, and even some configurations, switches, etc. are also written in redis. The reason is that redis is simple and efficient. The data in redis is becoming more and more important. For example, some business intermediate data will be temporarily stored in redis, so it is still necessary to restrict access to redis.
This article uses several means to talk about the access control of redis in the production environment.
1. Bind the network card bind
There is such a paragraph in the redis configuration file redis.conf for the network security part
################################## NETWORK ##################################### # By default, if no "bind" configuration directive is specified, Redis listens # for connections from all the network interfaces available on the server. # It is possible to listen to just one or multiple selected interfaces using # the "bind" configuration directive, followed by one or more IP addresses. # # ~~~ WARNING ~~~ If the computer running Redis is directly exposed to the # internet, binding to all the interfaces is dangerous and will expose the # instance to everybody on the internet. So by default we uncomment the # following bind directive, that will force Redis to listen only into # the IPv4 lookback interface address (this means Redis will be able to # accept connections only from clients running into the same computer it # is running).
The meaning of this passage reveals the deep meaning of bind: bind means which interface your redis instance is bound to, which can be understood as which network card it is bound to. So how many network cards do we have? You can take a look.
$ ifconfig
eth0 Link encap:Ethernet HWaddr 6C:92:BF:22:D7:FC
inet addr:10.93.84.53 Bcast:10.93.84.127 Mask:255.255.255.128
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
Here are two, one is the eth0 Ethernet card (10.93.84.53), and the other is the local loop lo (127.0.0.1).
Then there are two situations:
1) bind 10.93.84.53 #All hosts on the same network segment can connect to redis
2) bind 127.0.0.1 #local loop, then only the host where your redis instance is located can access redis
You can use according to your needs:
1) If your machine is directly exposed to the Internet, then you should carefully set the bind to 127.0.0.1, otherwise you are equivalent to exposing your redis to all external attacks.
2) If you are in a production environment, then you generally need to tie it to the network card so that other hosts can also access redis, then we will have some other ways to ensure the security of redis data.
2. Set password requirepass
There is such a configuration in redis.conf, after setting the password.
#requirepass <yourpassword>
requirepass mypass
After restarting the redis service, your client needs to access redis through a password
# The password is correct $ redis-cli -h 10.93.84.53 -p 6379 -a mypass ping PONG
# Password error $ redis-cli -h 10.93.84.53 -p 6379 -a hehe ping (error) NOAUTH Authentication required.
3. nologin reduces account privileges
Run the Redis service with a low-privilege account, and disable the login permission of the account. In addition, attackers can be restricted from writing sensitive files, but Redis data can still be accessed by hackers, or maliciously deleted by hackers.
The way to prohibit Linux users from logging in is generally to modify the user's shell type to /sbin/nologin.
This method will be more humane, because not only can the user be prohibited from logging in, but also a prompt can be given to tell it the reason for doing so when the login is disabled.
Modify /etc/nologin.txt, if there is no one, create a new one manually, and add a reminder to the banned user in it (the locking information of all users in this way is in this file, and a reminder is given when logging in).
In fact, it is to change /bin/bash in the /etc/passwd file to /sbin/nologin
[root@host-192-168-1-117 ~]# useradd wangshibo [root@host-192-168-1-117 ~]# echo "123456"|passwd --stdin wangshibo Changing password for user wangshibo. passwd: all authentication tokens updated successfully. [root@host-192-168-1-117 ~]# cat /etc/passwd|grep wangshibo wangshibo:x:500:500::/home/wangshibo:/bin/bash [root@host-192-168-1-117 ~]# sed -i 's#/home/wangshibo:/bin/bash#/home/wangshibo:/sbin/nologin#g' /etc/passwd [root@host-192-168-1-117 ~]# cat /etc/passwd|grep wangshibo wangshibo:x:500:500::/home/wangshibo:/sbin/nologin [root@host-192-168-1-117 ~]# touch /etc/nologin.txt [root@host-192-168-1-117 ~]# cat /etc/nologin.txt In order to protect the system security, this type of user is locked!
4. iptables set firewall
It is still necessary to set up a firewall in a production environment. If the Redis service needs to be accessed by other servers in normal business, you can set the iptables policy to allow only specified IPs to access the Redis service.
On the host where your redis instance is located, execute the following command.
# View the rules configured by iptables rules $ iptables -nL --line-number # Prohibit all hosts from accessing port 6379 of this machine $ iptables -I INPUT -p TCP --dport 6379 -j DROP # Open the following machine -s specification, These machines can access the local port 6379 $ iptables -I INPUT -s 10.93.21.21 -p tcp --dport 6379 -j ACCEPT $ iptables -I INPUT -s 10.93.18.34 -p tcp --dport 6379 -j ACCEPT $ iptables -I INPUT -s 10.93.18.35 -p tcp --dport 6379 -j ACCEPT $ iptables -I INPUT -s 10.93.84.53 -p tcp --dport 6379 -j ACCEPT # Save iptables configuration $ service iptables save iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ] # Restart the firewall $ service iptables restart iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Flushing firewall rules: [ OK ] iptables: Unloading modules: [ OK ] iptables: Applying firewall rules: [ OK ]
After the setting is successful, only the configured four machines can access the redis instance.