最直接信号是PUBSUB NUMSUB返回异常高订阅数或INFO clients显示大量短连接反复建立断开；隐蔽信号是MONITOR持续刷出非业务PUBLISH命令，频道名规律性强或含脚本特征。
如何识别Redis Pub/Sub频道被垃圾消息攻击
最直接的信号是 PUBSUB NUMSUB 返回异常高的订阅数，或 INFO clients 显示大量短连接反复建立又断开；更隐蔽的是 MONITOR 中持续刷出非业务来源的 PUBLISH 命令，尤其目标频道名规律性强（如 channel:1、test:* ）或携带明显脚本特征（如含 eval、system( 字样）。注意：Redis 本身不校验频道名合法性，攻击者可任意构造频道名并狂发消息，压垮消费者或触发下游解析漏洞。
禁止未授权客户端执行PUBLISH的硬性配置
Redis 的 PUBSUB 机制默认无权限隔离，关键在于切断攻击入口。不能只靠应用层过滤——攻击者可绕过业务代码直连 Redis 执行 PUBLISH。
- 在
redis.conf中启用命令重命名：rename-command PUBLISH ""（彻底禁用）或rename-command PUBLISH "safe_publish"（仅允许白名单应用使用别名） - 配合
requirepass强制认证，且绝不把密码写在前端或公开配置里 - 若必须开放
PUBLISH，用bind严格限制监听地址，例如只绑127.0.0.1或内网特定 IP 段，绝不可留bind 0.0.0.0
用SCAN + PUBSUB CHANNELS做实时频道治理
攻击者常批量创建临时频道（如 tmp_123456、log_20260313），靠人工监控根本来不及清理。要用自动化手段识别并冻结异常频道。
- 定期执行
PUBSUB CHANNELS "tmp_*"或PUBSUB CHANNELS "log_*"查匹配频道 - 对返回的频道列表，用
SCAN 0 MATCH "tmp_*" COUNT 1000确认是否真有数据堆积（空频道不会被PUBSUB CHANNELS列出，但可能已被注入） - 确认为垃圾频道后，用
CONFIG SET notify-keyspace-events ""临时关闭事件通知，再通过外部脚本向该频道发一条带终止标识的消息，由消费者主动退订并清理本地状态
注意：UNSUBSCRIBE 只影响当前连接，无法清除频道本身；Redis 不提供删除频道的命令，频道随最后一条消息过期或无人订阅自动消失——但前提是没人持续 PUBLISH 维持它存活。
消费者端防爆仓的关键保护点
频道攻击最终伤害的是消费者进程。哪怕 Redis 层做了防护，恶意消息仍可能穿透进来，导致反序列化崩溃、正则栈溢出或无限循环。
- 所有
SUBSCRIBE客户端必须设置超时和重试上限，避免因单条坏消息卡死整个连接 - 对收到的
messagepayload 做长度截断（如 >1MB 直接丢弃），禁止原样传给JSON.parse或eval - 用独立子进程或沙箱运行消息处理器，主进程只负责收发，子进程崩溃不影响订阅关系
最容易被忽略的是：很多 SDK 默认开启 reconnect，攻击期间频繁断连重连会加剧连接风暴——应改为指数退避重连，并在重连前先 PING 确认服务可用性。
