Redis居然用root权限启动了，这样做安全隐患有点大吧，得注意下

（用户）那天在检查服务器进程的时候，无意中输入了 ps aux | grep redis 命令，结果吓了一跳，我清楚地看到，Redis服务进程的USER那一栏，赫然显示着“root”这个词，我心里咯噔一下，心想：“坏了，这Redis怎么是用root权限在跑？这安全隐患可不是一般的大啊。”

（网络资料）后来我特意去查了查，发现我这种情况还真不是个例，在很多网络技术社区的讨论帖里，比如像V2EX、知乎上的一些运维话题下，经常能看到有朋友发帖求助，说发现自己公司测试环境甚至生产环境的Redis是以root身份运行的，询问有什么风险以及该如何处理，大家都普遍认为,这是一个非常危险的操作。

（用户）为什么说危险呢？这得从root权限说起，root在Linux系统里就像是拥有万能钥匙的“超级管理员”，它有权对系统做任何事，包括查看、修改、删除任何文件，启动或停止任何服务，甚至能把系统搞崩溃，让一个原本设计用来做缓存和消息队列的数据库服务，掌握着这么大的权力,这本身就极不合理。

（网络资料）我看到有篇技术文章打了个很形象的比方：这就好比你在家里请了个保姆，为了方便她打扫卫生，你直接把整个家，包括存放着存折、房产证的保险柜钥匙都交给了她，理论上她可以帮你打扫房间，但她同样可以随时打开保险柜，拿走你所有的贵重物品，Redis以root运行,就相当于这个掌握了所有钥匙的保姆。

（用户）隐患主要体现在几个方面，首先最直接的就是数据安全，Redis虽然能设置密码，但如果攻击者通过其他途径找到了服务器的漏洞，并且利用了这个高权限的Redis服务，他就能轻而易举地读写服务器上的任何文件，他可以把SSH的公钥直接写入到/root/.ssh/authorized_keys文件里，这样他下次就能直接用root身份免密登录我的服务器，整个服务器就完全暴露了，一想到这个可能性,我就觉得后背发凉。

（网络资料）根据一些安全研究报告的分析，历史上不少服务器被入侵的案例，最初的突破口就是一个以root权限运行的、配置不当的应用服务，攻击者往往不会直接去攻击坚固的堡垒主体，而是寻找这些被疏忽的“侧门”，配置错误的Redis服务，就常常成为这样一个完美的“侧门”。

（用户）这对Redis服务本身也不安全，任何软件都难免存在漏洞，Redis历史上也爆出过一些安全漏洞，如果Redis进程只是以一个普通用户权限运行，即便漏洞被利用，攻击者获得的权限也被限制在那个普通用户的范围内，造成的破坏相对可控，但如果是以root运行，那么任何一个Redis的远程代码执行漏洞，都意味着攻击者能立刻获得整个服务器的最高控制权,这相当于把漏洞的危险等级放大了无数倍。

（网络资料）在Redis的官方文档里，其实有明确的警告和建议，文档中强烈不建议以root身份运行Redis服务，官方建议的做法是，创建一个专用的、权限受到严格限制的系统用户和用户组（比如就叫redis），然后用这个用户来启动和运行Redis服务，这个用户应该只拥有运行Redis所必需的最小权限，比如读写Redis自己的数据文件和日志文件的权限，除此之外,不应该有任何其他特权。

（用户）意识到问题的严重性后，我立刻着手整改，整改过程其实并不复杂，我创建了一个新的系统用户和用户组：sudo groupadd redis 和 sudo useradd -r -g redis -s /bin/false redis，这里的-r参数表示创建系统用户，-s /bin/false确保这个用户不能直接登录系统,安全性更高。

我修改了Redis的数据目录（dir /var/lib/redis）和日志文件的属主和权限，让新创建的redis用户拥有所有权：sudo chown -R redis:redis /var/lib/redis 和 sudo chown redis:redis /var/log/redis.log。

我需要修改Redis的配置文件（通常是/etc/redis/redis.conf），找到配置项，将daemonize设置为yes（如果已经是守护进程模式则不用改），更重要的是，找到user配置项（新版本Redis支持），将其设置为redis，如果版本较旧没有这个配置项,则需要修改启动脚本。

（网络资料）对于使用systemd管理的系统，修改启动方式更规范，我需要编辑Redis的systemd服务单元文件（如/etc/systemd/system/redis.service），在[Service]部分，明确指定User=redis和Group=redis，修改完后，执行sudo systemctl daemon-reload重新加载配置。

（用户）重启Redis服务：sudo systemctl restart redis，重启后，我再次用ps aux | grep redis命令确认，看到USER那一栏已经变成了“redis”，心里的一块大石头总算落了地，我还特意做了一下功能测试，确认应用连接Redis、数据读写、持久化等都完全正常,没有因为降权而受到影响。

（网络资料）除了降权，安全专家们还建议了一系列加固措施，形成纵深防御，1）绑定内网IP：在配置文件中使用bind 127.0.0.1或内部网络IP，避免Redis服务暴露在公网上，2）设置强密码：通过requirepass指令设置一个复杂的密码，并确保客户端连接时使用AUTH命令认证，3）重命名危险命令：通过rename-command配置项，将像FLUSHALL、CONFIG、SHUTDOWN这类高风险命令重命名为一个复杂的、难以猜测的字符串，或者直接禁用（重命名为），4）使用防火墙：利用iptables或firewalld等防火墙工具,严格限制允许连接Redis服务器的源IP地址。

（用户）经过这次虚惊一场的经历，我深刻体会到运维工作中“安全无小事”这句话的分量，一个看似不起眼的配置疏忽，背后可能隐藏着巨大的风险，定期进行安全审计和配置检查，严格遵循“最小权限原则”，应该是每一个系统管理员必备的职业习惯，再也不能图一时省事，就让重要的服务运行在root权限之下了,这个教训非常深刻。