缓存服务的两类风险
Memcached 默认没有认证机制（除非另外启用 SASL），且默认监听所有地址，任何能连上 11211 的人都能读走缓存里的会话数据、令牌与业务对象。它还有第二重身份：UDP 无握手，攻击者伪造源地址发一个小请求，服务会返回大得多的响应，构成放大攻击，历史上曾出现数万倍放大倍数并造成大规模拒绝服务。因此加固要求是绑定回环或管理地址、关闭 UDP、必要时启用 SASL。
基本信息
| 加固项 | 缓存服务暴露面收敛 |
|---|---|
| 适用平台 | Linux（memcached） |
| 权限要求 | root 或服务配置权限 |
| 达标判据 | 未监听 UDP 11211，绑定回环或内网，有访问控制 |
| 关键启动参数 | -l 绑定地址、-U 0 关闭 UDP、-m 限制内存、-S 启用 SASL |
典型使用场景
- 公网或大内网主机的暴露面巡检
- 发现缓存中存放会话数据后做访问收敛
- 等保与行业检查中“多余服务关闭”条款整改
- 云安全组与主机侧双层确认 UDP 是否已关
- 多个应用共用缓存实例时按来源与实例做隔离
核查与加固
核查与加固
ss -tulnp | grep ':11211 ' # 必须同时看 TCP 与 UDP
ps -ef | grep [m]emcached # 查看实际启动参数
# 加固后的启动参数示意：
# -l 127.0.0.1 只监听回环地址
# -U 0 关闭 UDP 监听，切断放大攻击路径
# -m 512 限制内存，避免被当成放大资源池
# -S 启用 SASL 认证，需客户端同步改造复核与验证
复核与验证
systemctl restart memcached
ss -tulnp | grep ':11211 ' # 复核：不应再出现 udp 行
memcached-tool 127.0.0.1:11211 stats | head -5 # 本地自测服务仍可用
ss -tulnp | grep -E ':11211|:11212'
firewall-cmd --list-ports # 边界与主机侧交叉确认风险与对策对照
| 风险 | 成因 | 对策 |
|---|---|---|
| 数据泄露 | 无认证且监听所有地址 | 绑回环或内网，启用 SASL |
| UDP 放大 | UDP 无握手且响应远大于请求 | -U 0 关闭 UDP，边界封 udp/11211 |
| 内存被吃满 | 未限制内存使用量 | -m 设定上限并纳入监控 |
| 横向探测 | 同网段任意主机可连接 | 主机防火墙限制来源网段 |
UDP 与 TCP 是两个独立监听项：只把 TCP 绑到回环或只封 TCP 端口时，UDP 11211 仍然对外可用，放大攻击照样成立。处置完成后要用 ss 同时确认两种协议都不再对外监听，并在边界设备与云安全组两侧复核。
启用 SASL（-S）需要客户端同步支持并配置，有改造成本。若应用侧短期无法改造，至少先做到绑定回环、关闭 UDP 与来源限制三点，消除最直接的泄露与放大风险，再把认证改造排入计划，避免因等待改造而长期停在裸奔状态。