Redis公网部署避坑指南:从裸奔到穿盔甲的实战记录
上周帮朋友公司排查一个诡异的Redis性能问题,发现他们直接把6379端口裸暴露在公网上,连个防火墙规则都没配。这让我想起刚工作那会儿自己部署Redis时踩过的坑,今天就把这些年总结的公网环境部署Redis的正确姿势分享给大家。
1. 为什么Redis默认配置很危险?
Redis的默认配置redis.conf
里有几个”要命”的设定:
- 默认监听所有网卡(0.0.0.0)
- 默认无密码保护
- 默认允许危险命令(比如
FLUSHALL
)
我第一次部署时就中招了——某天发现数据库莫名其妙被清空,查日志才发现是被人用redis-cli -h 我的IP
连上来执行了FLUSHALL
…
2. 基础安全三板斧
# 修改redis.conf关键配置
bind 127.0.0.1 # 只允许本地访问
requirepass yourStrongPassword123!
rename-command FLUSHALL "" # 禁用危险命令
但现实情况往往是:必须开放公网访问(比如跨机房同步)。这时候就需要进阶方案:
3. 公网环境下的生存法则
我的实战经验是分三步走:
- 改端口:不用默认6379,改成随机高位端口(比如16379)
- 加白名单:用iptables/IPset限制可访问IP
- 上TLS:Redis 6.0+支持加密传输,配置示例:
# 生成证书(生产环境建议用正规CA)
openssl req -x509 -newkey rsa:4096 -nodes -keyout redis.key -out redis.crt -days 365
# redis.conf配置
tls-port 16379
tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key
4. 那些年我踩过的坑
说几个真实案例:
- 密码复杂度不够:某次用
redis123
当密码,3天后被暴力破解 - 忘记限制内存:公网Redis被注入超大key导致OOM
- ACL配置失误:给子账号开放了
CONFIG
权限导致被提权
现在我的检查清单一定会包含:
# 内存限制+保护模式
maxmemory 2gb
maxmemory-policy volatile-lru
protected-mode yes
# 使用ACL精细化控制
acl setuser workeruser on >workerpass ~cache:* +get +set
5. 终极方案:VPN/跳板机
对于特别敏感的环境,我的建议是:不要让Redis直接暴露在公网。通过WireGuard组网,或者用SSH隧道访问:
# SSH端口转发示例
ssh -L 6379:localhost:6379 user@redis-server
最近帮客户做安全审计时发现,90%的Redis安全问题其实都可以通过禁止公网直连来避免。
最后提醒:改完配置一定要redis-cli auth yourpassword
测试下,别像我当年那样改完conf文件就自信满满下班,结果半夜被报警短信吵醒…
看到直接暴露6379端口那段真的惊了,这简直是裸奔上网啊 😨
FLUSHALL那个案例太真实了,我之前也遇到过类似问题,数据库莫名其妙被清空
作者写得很实用,特别是ACL精细化控制那段,学到新知识了
改端口+加白名单真的是基本操作了,但很多人就是懒得做
Redis 6.0才支持的TLS功能真的很关键,加密传输太有必要了