1. 从一条告警说起这个漏洞为什么让运维团队彻夜难眠凌晨两点手机响了。监控平台推来一条告警某台负载均衡设备的管理接口出现了异常进程创建行为。我打开终端连上去发现/var/log/下多了一个从未见过的日志文件里面记录着几条来自陌生IP的HTTP请求路径指向/mgmt/tm/util/bash。那一刻我就知道出事了。这个场景对应的就是CVE-2021-22986一个影响 F5 BIG-IP 系列设备的远程代码执行漏洞。它的 CVSS 评分高达 9.8属于严重级别。攻击者不需要任何账号密码只要能访问到设备的管理界面就能直接以 root 权限执行任意命令。换句话说这台设备在攻击者面前等同于一台完全敞开的机器。我写这篇东西不是要复述官方公告而是想把我在实际排查和加固过程中积累的东西整理出来。包括这个漏洞的底层原理到底是什么、为什么它这么容易被利用、iControl REST 接口的设计缺陷在哪里、怎么判断自己的设备是否已经被入侵、以及在没有官方补丁的情况下如何做临时缓解。适合正在管理 F5 设备的运维工程师、安全应急响应人员以及对 Web 应用防火墙和负载均衡设备安全感兴趣的读者。需要提前说明的是本文所有操作均在隔离的实验环境中完成涉及的 IP 地址、主机名、日志内容均为虚构代称不涉及任何真实生产环境。2. iControl REST 的设计初衷与它埋下的隐患2.1 为什么 BIG-IP 要暴露一个 REST 管理接口要理解这个漏洞得先搞清楚 iControl REST 是干什么的。F5 BIG-IP 作为一款应用交付控制器它的核心价值在于流量调度、SSL 卸载、应用安全防护。但设备本身需要被管理——管理员要配置虚拟服务器、调整负载均衡策略、查看连接池状态。早期这些操作通过 SOAP 接口或者命令行完成后来 F5 推出了 iControl REST用标准的 HTTP 方法和 JSON 格式来暴露管理能力。这个设计本身没有问题。问题在于iControl REST 的接口权限模型和它的认证机制之间存在一个致命的错位。正常情况下你访问/mgmt/tm/ltm/virtual这样的接口需要先通过/mgmt/shared/authn/login获取一个 token然后带着这个 token 去请求具体资源。但某些特定的端点在设计时被赋予了过高的默认权限而认证检查又没有覆盖到它们。2.2/mgmt/tm/util/bash这个端点到底做了什么/mgmt/tm/util/bash是 iControl REST 提供的一个工具类端点。它的设计目的是让管理员能够通过 REST 接口执行一些系统级的诊断命令比如查看磁盘使用率、检查网络连通性、读取系统日志。你可以把它理解成一个远程 shell 的 HTTP 封装。请求体大概长这样{ command: run, utilCmdArgs: -c id }正常情况下这个请求需要管理员权限的 token 才能通过。但在 CVE-2021-22986 影响的版本中这个端点的认证逻辑存在缺陷——具体来说当请求经过特定的路径重写或头部构造后认证中间件会被绕过请求直接到达后端执行引擎。我用一个生活化的类比来解释想象一栋大楼正门有保安查证件。但侧门虽然挂着员工通道的牌子实际上门锁是坏的而且从侧门进去之后可以直接走到所有楼层。iControl REST 的认证机制就是那个正门保安而/mgmt/tm/util/bash就是那扇没锁好的侧门。2.3 漏洞的触发条件比想象中更宽松很多人看到远程代码执行会觉得需要很复杂的利用链。但 CVE-2021-22986 的触发条件相当简单目标设备的 iControl REST 接口对攻击者可达通常是管理口或带外管理网络设备版本在受影响范围内攻击者构造一个特定的 HTTP 请求不需要用户交互不需要钓鱼不需要社工。只要网络可达就能打。这也是为什么这个漏洞在披露后迅速被纳入多个威胁情报平台的活跃利用列表。3. 影响面到底有多大版本矩阵与暴露面排查3.1 受影响的版本范围根据公开的安全公告CVE-2021-22986 影响以下版本分支产品线受影响版本修复版本BIG-IP (LTM/ASM/APM等)16.x16.0.1.1BIG-IP15.x15.1.2.1BIG-IP14.x14.1.4BIG-IP13.x13.1.3.6BIG-IP12.x12.1.5.3BIG-IQ7.x7.1.0.3BIG-IQ6.x6.1.0.6这里有个容易踩的坑很多人只看 BIG-IP 的版本忽略了 BIG-IQ。BIG-IQ 是 F5 的集中管理平台它同样暴露了 iControl REST 接口而且往往部署在管理网段的核心位置。一旦 BIG-IQ 被拿下攻击者可以通过它横向管理所有纳管的 BIG-IP 设备后果比单台设备沦陷严重得多。3.2 如何快速判断自己的设备是否暴露第一步确认设备的管理接口是否可以从非信任网络访问。我见过太多环境管理口和业务口在同一个 VLAN 里甚至管理口直接映射到了公网。你可以登录设备后执行tmsh list sys management-ip tmsh list sys management-route这两条命令会显示管理 IP 和路由配置。如果管理 IP 所在的网段没有经过防火墙隔离那就是高风险。第二步检查 iControl REST 的访问控制列表。BIG-IP 允许你通过/mgmt/shared/authz/相关的配置来限制访问来源。执行tmsh list auth partition tmsh list sys httpd重点关注allow和deny字段。如果看到allow all或者没有明确的来源限制说明任何能路由到管理口的 IP 都可以尝试访问。第三步在边界防火墙上确认是否有针对管理口的放行规则。很多团队在部署时为了方便会临时开一条any to management的规则然后忘了关。这种临时规则往往就是攻击者的入口。3.3 一个真实的排查案例某次应急响应中我遇到一个环境BIG-IP 的管理口配置在 10.0.0.0/24 网段理论上只有跳板机可以访问。但检查防火墙策略时发现有一条规则允许办公网段 172.16.0.0/16 访问管理口的 443 端口。办公网段里有大量终端其中一台被植入了扫描工具攻击者就是通过这台终端扫描到了 BIG-IP 的管理界面然后利用 CVE-2021-22986 拿到了 root shell。这个案例的教训是管理平面的网络隔离不能只看设计文档必须实际验证防火墙规则和路由表。设计上隔离了不等于实际隔离了。4. 攻击链还原从请求构造到命令执行4.1 请求层面的细节在隔离环境中我复现了完整的攻击链。核心请求如下POST /mgmt/tm/util/bash HTTP/1.1 Host: target Authorization: Basic base64 Content-Type: application/json Content-Length: length { command: run, utilCmdArgs: -c id; uname -a; cat /etc/passwd }关键点在于Authorization头部的处理。在受影响版本中当请求路径经过特定的规范化处理后认证中间件会错误地认为这是一个不需要认证的内部请求。具体的技术细节涉及路径解析和中间件顺序的问题这里不展开但核心逻辑是认证检查发生在路径重写之前而实际路由发生在路径重写之后两者看到的路径不一致。4.2 命令执行后的持久化行为拿到命令执行能力后攻击者通常会做几件事写入 SSH 公钥到/root/.ssh/authorized_keys建立持久化后门创建隐藏的管理员账号比如support或admin2修改 iControl REST 的认证配置添加自己的 token 白名单在/config/目录下植入定时任务脚本我在实验环境中模拟了这些行为然后检查了设备的审计日志。发现一个有意思的现象BIG-IP 的默认审计日志只记录管理操作不记录通过/mgmt/tm/util/bash执行的命令。也就是说如果攻击者只做命令执行而不修改配置默认日志里几乎看不到痕迹。4.3 如何从日志中发现入侵痕迹虽然默认审计不记录命令但有几个地方可以找到线索第一/var/log/httpd/下的访问日志。iControl REST 的请求会记录在这里。搜索包含/mgmt/tm/util/bash的条目grep util/bash /var/log/httpd/*.log第二/var/log/audit/下的系统审计日志。如果攻击者执行了敏感操作比如修改/etc/passwd这里会有记录。第三检查/root/.ssh/目录下的文件修改时间。如果authorized_keys的修改时间与设备正常运维时间不符高度可疑。第四查看/config/目录下是否有非预期的脚本文件。攻击者常用的文件名包括update.sh、check.sh、.hidden等。注意在排查时不要直接在设备上执行可能被攻击者监控的命令。如果怀疑设备已被入侵优先做的是隔离网络然后通过带外管理或控制台取证。5. 临时缓解方案在没有补丁的窗口期怎么办5.1 最直接的做法限制管理接口访问如果暂时无法升级第一优先级是限制 iControl REST 的访问来源。在 BIG-IP 上可以通过配置管理 IP 的访问控制来实现tmsh modify sys httpd allow replace-all-with { 10.0.0.0/24 }这条命令的意思是只允许 10.0.0.0/24 网段访问 HTTP/HTTPS 管理接口。执行后需要确认配置生效tmsh list sys httpd allow但这里有个坑如果你把自己所在的网段也排除了会直接失去管理连接。所以执行前务必确认当前管理终端的 IP 在允许范围内或者准备好控制台访问方式。5.2 关闭不必要的 iControl REST 端点如果业务上不需要通过 REST 接口执行系统命令可以考虑禁用/mgmt/tm/util/下的相关端点。F5 没有提供直接的开关但可以通过 iRules 或者前端反向代理来做请求过滤。在 BIG-IP 自身上可以创建一个 iRule 绑定到管理虚拟服务器when HTTP_REQUEST { if { [HTTP::uri] starts_with /mgmt/tm/util/bash } { reject } }这个 iRule 的作用是当请求路径以/mgmt/tm/util/bash开头时直接拒绝连接。实测下来这种方式可以有效阻断已知的利用请求但需要注意 iRule 的性能开销和可能的绕过方式比如 URL 编码变形。5.3 网络层的隔离与监控在防火墙层面确保管理口只对特定的跳板机或运维网段开放。同时在 IDS/IPS 上添加针对/mgmt/tm/util/bash的检测规则。Snort 规则示例alert tcp $EXTERNAL_NET any - $HOME_NET 443 (msg:F5 iControl REST bash endpoint access; flow:to_server,established; content:/mgmt/tm/util/bash; http_uri; sid:1000001; rev:1;)这条规则会在检测到对/mgmt/tm/util/bash的访问时告警。即使攻击者使用了加密流量如果 TLS 终止在 IDS 之前也能检测到。5.4 临时缓解的局限性必须说清楚以上所有临时方案都不能从根本上修复漏洞。它们只是提高了攻击门槛或者增加了检测能力。如果攻击者已经获得了其他入口或者能够绕过网络限制这些措施的效果有限。真正的修复只有升级到官方修复版本。6. 升级操作中的坑与验证清单6.1 升级前的准备工作升级 BIG-IP 不是一件可以随便做的事。生产环境中的设备往往承载着关键业务流量升级过程中的重启会导致服务中断。我的建议是确认当前版本的已知问题列表避免升级到有严重回归的版本备份当前配置tmsh save sys config然后通过/var/local/ucs/导出 UCS 文件确认升级路径。F5 不支持跨大版本直接升级比如从 12.x 直接到 16.x需要经过中间版本在实验环境中先验证升级流程和业务兼容性6.2 升级后的验证清单升级完成后不要只看版本号就认为万事大吉。我整理了一份验证清单检查项命令/方法预期结果版本确认tmsh show sys version显示修复版本号管理接口访问从非授权网段尝试访问连接被拒绝iControl REST 认证无 token 请求/mgmt/tm/util/bash返回 401业务虚拟服务器状态tmsh show ltm virtual所有 VS 状态正常连接池健康tmsh show ltm pool成员状态正常SSL 证书有效期tmsh show sys crypto cert无过期证书日志无异常grep -i error /var/log/ltm无新增错误6.3 一个容易忽略的细节HA 对组的升级顺序如果设备是 HA 对组升级顺序很重要。正确的做法是先升级备机重启后确认备机状态正常手动切换流量到备机确认业务无感知升级原主机重启后确认状态正常根据需要对组状态做一次强制同步我见过有人同时重启两台设备结果业务中断了十几分钟。HA 对组的意义就是提供冗余升级时应该利用这个冗余而不是同时操作。7. 从这次漏洞事件中沉淀下来的运维习惯7.1 管理平面必须独立且最小化暴露这次漏洞给我最大的教训是管理平面的安全不能依赖设备自身的认证机制。BIG-IP 的 iControl REST 设计上是为了方便管理但方便和安全往往是一对矛盾。我的做法是管理口单独划分 VLAN与业务流量物理或逻辑隔离管理口的访问控制列表只允许必要的运维终端所有管理操作通过跳板机进行跳板机启用多因素认证定期审计管理口的访问日志关注非工作时间的异常请求7.2 建立设备版本的持续跟踪机制F5 的安全公告发布频率不低如果靠人工定期检查很容易遗漏。我现在的做法是订阅 F5 的安全公告 RSS在 CMDB 中记录每台设备的当前版本和最后升级时间每月做一次版本比对标记出落后于修复版本的设备对于无法及时升级的设备记录临时缓解措施和到期时间7.3 应急响应预案要覆盖设备被控场景大多数团队的应急响应预案是针对服务器和终端的很少考虑网络设备被控的情况。但 BIG-IP 被控的后果可能更严重攻击者可以篡改流量、窃取 SSL 私钥、植入持久化后门。我建议在预案中增加以下内容设备被控后的隔离流程如何在不影响业务的前提下切断管理访问取证数据的采集清单日志、配置备份、进程列表、网络连接恢复流程从干净的备份恢复配置还是重装系统通知流程哪些业务方需要知会是否需要临时切换流量路径7.4 一个实用的小技巧用外部监控做补偿控制如果设备本身的日志不可信因为攻击者可能已经清除了日志可以依赖外部监控。比如在管理口的交换机上配置端口镜像把流量镜像到独立的监控设备。这样即使设备上的日志被篡改外部镜像的流量记录仍然可以作为取证依据。我在实验环境中用这种方式成功捕获了一次模拟攻击的完整流量。虽然增加了硬件成本但对于核心管理设备来说这个投入是值得的。8. 写在最后设备安全没有一劳永逸搞了这么多年运维我越来越觉得安全不是一个可以完成的任务。CVE-2021-22986 只是 BIG-IP 历史上众多漏洞中的一个未来还会有新的漏洞出现。真正重要的是建立一套可持续的运维习惯保持版本更新、限制暴露面、持续监控、定期演练。这次漏洞的修复过程中我最大的收获不是学会了怎么打补丁而是重新审视了管理平面的安全架构。以前觉得管理口在内网就安全了现在知道内网也有被渗透的风险。以前觉得设备日志会记录一切现在知道关键操作可能根本不进日志。如果你正在管理 F5 设备我的建议是今天就去看一眼你的管理口访问控制列表确认它没有对非信任网段开放。这个动作只需要五分钟但可能避免一次严重的安全事件。