ActiveMQ RCE 这个关键词这几年一直是消息中间件运维和安全管理领域绕不开的话题。如果你的系统里恰好部署了 ActiveMQ又开放过默认的 61616 端口那这篇必须认认真真看完。这里不讨论攻击者怎么构造最终的攻击载荷而是完全站在防御和治理的视角把这个漏洞的成因、波及范围、排查手段、修复路径全部摊开说清楚。无论你是刚接手消息队列的新人还是已经在生产环境踩过坑的运维这篇文章都值得收藏。文章里提到的所有版本号、配置和排查命令都来自我在实际项目中的验证可以直接拿来用。拿我前段时间帮某项目组处理的一台队列节点为例。那套系统上线时间比较早当初为了图省事用的是 ActiveMQ 默认配置端口直接监听所有网卡管理端也没有强制开启认证。结果安全扫描一进来第一个亮红灯的就是消息中间件。当时要做的事情很明确搞清楚这个漏洞为什么存在、影响哪些业务、日志里有没有被扫描的痕迹、以及怎么在不停掉核心链路的前提下完成封堵。整个过程走完用了不到两天但其中很多判断和操作细节我觉得非常值得整理成一篇完整的实操笔记。1. 漏洞到底出在哪为什么影响这么大1.1 一句话说清漏洞本质ActiveMQ 在默认安装时会开启基于 OpenWire 协议的传输连接器。这个协议是 Java 序列化风格的二进制协议服务端收到消息后本来应该只负责把字节流解析成消息对象再按照路由规则投递出去。问题恰恰出在解析环节当某些异常对象被触发时协议帧中携带的类描述信息会被服务端拿去执行类加载而这个加载过程缺少严格的过滤和身份校验。攻击者只要能把网络请求送到 OpenWire 端口就可以通过精心构造的协议数据诱导服务端加载并初始化特定类最终在服务器上以 ActiveMQ 运行用户的身份执行系统命令。听起来有点绕我打个比方你就明白了。正常情况下快递站只负责收包裹、贴标签、分派给对应片区。但如果快递站在录入包裹时直接打开包裹里的说明书还照着说明书上的指令操作电脑那出事只是早晚的问题。OpenWire 协议里的类描述信息本质上就是快递包裹里的“说明书”ActiveMQ 在解析异常信息时错误地信任了这份说明书还替攻击者执行了里面的动作。1.2 攻击成本极低网络可达即可这个问题之所以被评为高危最核心的原因是攻击门槛低。它不需要你在管理控制台登录不需要发送鉴权票据甚至不需要知道队列名称。只要 ActiveMQ 的 OpenWire 端口对攻击者可达攻击者就有机会在一两次握手之内触发异常处理逻辑从而尝试远程代码执行。默认情况下ActiveMQ 的传输连接器监听 0.0.0.0:61616也就是所有网卡接口。很多内网部署甚至不设防火墙规则认为内网一定是安全的这给了攻击者很大的便利。如果 ActiveMQ 进程是以 root 或系统高权限用户运行那漏洞被利用后的后果更加严重相当于直接把一台服务器的控制权交了出去。退一步说即使运行用户权限受限攻击者也能通过这个漏洞读取配置、探测内网、安装持久化后门。消息中间件一旦被突破往往成为内网横向移动的重要跳板因为它的网络位置往往同时连接着多个业务系统。1.3 为什么 Java 体系里的中间件尤其容易踩这个坑Java 序列化反序列化漏洞并不是 ActiveMQ 独有的但 ActiveMQ 这类中间件特别容易成为目标。原因在于中间件天然需要接收外部数据并把这些数据转换成内部对象。如果中间件在协议解析层面对类加载不加限制任何一个暴露的端口都可能变成漏洞入口。相比之下纯文本协议比如 HTTP对数据格式有严格约定恶意数据不太容易跨过解析层而二进制序列化协议因为接口灵活、传输高效在安全性上要付出更多成本。很多团队在选择中间件时优先考虑的是性能和功能对安全设计关注不足。等到漏洞曝光才发现自己用的版本停留在两三年甚至更早的状态。消息队列这类基础组件往往不在业务迭代的核心路径上很容易被忽视但它们一旦出问题影响范围是整个调用链。2. 影响范围面与前置条件梳理2.1 哪些版本在射程之内这个漏洞影响 ActiveMQ 5.x 系列的多个版本具体可以按分支来看。如果你们使用的是 5.15 分支那么低于对应修复版本的版本都受影响5.16 分支和 5.17 分支也一样只有升级到修复版本之后才算安全。5.18 分支同样存在类似问题补丁发布后迅速成为官方推荐版本。我在实际排查中遇到的情况是很多生产集群还在跑 5.15.x 甚至更早的版本这些版本距离修复版本相差了好几个迭代升级时不仅要注意版本号变化还要注意配置文件的兼容性。我建议你第一时间检查手头所有 ActiveMQ 实例的版本号把低于修复版本的全部列入整改清单。不要只查线上环境测试环境、灾备环境、以及那些半废弃的临时集群同样可能成为被利用的入口。攻击者不会因为你没写进资产台账就仁慈。2.2 容易被忽略的前置条件虽然有网络可达就能利用但实际部署中有几个前置条件会显著提高被利用的概率。第一OpenWire 连接器公开监听且没有在网络层做来源限制。这种情况下任何能访问 61616 端口的来源都具备完整的攻击条件。第二ActiveMQ 未开启认证或使用弱口令。默认配置中的 guest 用户和 guest 密码如果没被修改等于把最后一道门也打开了。第三Java 进程运行权限过高。很多安装脚本默认以 root 执行启动命令导致漏洞利用后权限直接拉满。反过来说如果部署做得比较规范比如 61616 端口只绑定内网 IP、防火墙只允许应用服务器网段访问、认证插件已启用那么漏洞可利用性会大幅下降。但这些措施并不能替代升级补丁。攻击者一旦进入内网这些“软隔离”就可能形同虚设。我在安全评估中反复强调一句话网络隔离是缓解手段升级补丁才是根治方案。2.3 和同类消息中间件漏洞的横向对比如果拿 RabbitMQ 或 Redis 等常用中间件来对比会发现一个共同规律凡是默认配置过于宽松、又支持复杂协议解析的中间件都是安全重灾区。ActiveMQ 的特殊之处在于 OpenWire 协议的复杂度较高协议本身携带的对象类型信息太多给了攻击者更大的发挥空间。这也提醒我们在选型阶段就要把安全维护成本算进去不能只看吞吐量和消息可靠性。3. 分析验证过程与检测思路3.1 先定位版本和暴露面排查的第一步是把所有 ActiveMQ 的安装目录找出来然后确认版本号。ActiveMQ 一般在安装目录的 lib 子目录里会有一个核心 jar 包文件名中包含版本号。例如 activemq-core-5.17.5.jar 或 activemq-all-5.18.2.jar。也可以用命令行工具直接查看/opt/activemq/bin/activemq version如果这条命令没法执行可以直接搜索 jar 包文件名find /opt -name activemq-core-*.jar -o -name activemq-all-*.jar 2/dev/null | sed -E s/.*([0-9]\.[0-9]\.[0-9]).*/\1/ | sort -u拿到版本号之后和修复版本做对照。这里我不直接罗列全部编号但只要你手头版本低于各分支最新修复点就应该进入整改流程。只差一个补丁版本但一直没升级的情况恰恰是实际排查中遇到最多的。接着查监听端口和网络暴露情况ss -lntp | grep -E 61616|61617看到类似0.0.0.0:61616这样的输出意味着端口监听在所有网卡上。如果 ActiveMQ 部署在 DMZ 区或者云安全组里放行了公网来源那优先级立刻调高属于紧急高危项。即使绑定的是内网 IP也要确认防火墙和安全组规则是否限制了来源 IP。很多时候安全组规则里写着“允许内部访问”但实际上把整个大网段都放行了起不到隔离效果。3.2 日志中哪些迹象值得注意ActiveMQ 的运行日志在 conf 和 data 目录下常见的日志文件包括 activemq.log 和 audit.log。漏洞利用过程中服务端可能在短时间内收到大量格式异常的连接请求日志里会出现异常类型的描述信息或者是某个类名被反复加载的痕迹。如果你看到日志中存在以下特征就要提高警惕了大量来自同一来源 IP 的异常连接请求。日志中频繁出现非业务相关的类名或奇怪的异常描述。连接建立后没有正常的消息收发行为只有零星的数据包。日志中出现本不该出现的系统命令执行痕迹或目录被扫描的特征。需要注意的是很多 ActiveMQ 默认配置下日志精度不足以记录每个连接的全部二进制内容。所以日志分析只能作为辅助手段不能因为日志里“没发现异常”就判定安全。更可靠的方式是看网络流量层面的特征。3.3 流量层面的异常特征正常情况下业务方与 ActiveMQ 之间交换的是内容相对固定的消息数据数据包结构和大小都有规律。如果你在交换机或安全网关旁路部署了镜像流量可以重点过滤目标端口为 61616 的 TCP 流量。攻击尝试往往包含以下特征连接生命周期很短多次重连。单个连接内只发送少量字节就断开。连接间隔很规则类似脚本扫描。数据帧中出现了远大于正常消息体的二进制内容。当然大部分团队没有能力做全量流量审计那也没关系。我们可以用系统层面监控例如通过 systemtap 或 auditd 监控 Java 进程的 execve 行为看是否有非授权进程启动。不过这些手段需要提前配置临时部署效果有限更适合作为长期安全建设的组成部分。3.4 最小验证脚本的编写有时候你想快速遍历一批机器确认哪些 ActiveMQ 实例低于安全版本可以写一个最简单的检查和报告脚本。下面这个思路我实测过不用引入复杂工具适合批量执行#!/bin/bash for host in $(cat host_list.txt); do echo $host ssh ${host} find /opt /usr/local -name activemq-core-*.jar -o -name activemq-all-*.jar 2/dev/null | head -3 done这个脚本的意义是建立资产清单。先把资产摸清楚再谈修复。很多运维被漏洞通告追着跑最后却发现连自己管了多少个 ActiveMQ 节点都说不清这种情况才是最要命的。4. 应急处置与长期修复方案4.1 应急场景下的三件事如果确认线上环境存在该漏洞且暂时没有条件立即升级我建议按照优先级做三件事。第一立即收紧网络访问。在防火墙或安全组上把 61616 端口设置为只允许业务应用服务器网段访问。如果没有办法在安全组上配置那就直接在系统层操作例如iptables -A INPUT -p tcp --dport 61616 -s 192.168.10.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 61616 -j DROP注意这只是一个应急例子实际规则要插入到现有策略链中合适的位置并且要测试对业务的影响不能直接全部拒绝。更稳妥的做法是先开放白名单网段再在晚上业务低峰期切断其他来源。第二关停不必要的 OpenWire 连接器。如果没有业务依赖 OpenWire 协议可以在 conf/activemq.xml 中注释掉对应的 transportConnector然后重启 ActiveMQ。有些系统走了 AMQP 或 MQTT 协议唯独不需要 OpenWire关闭后不仅能减少攻击面还能减少不必要的线程消耗。第三修改默认账号密码。如果使用的是 5.x默认可能启用了 guest 账号。在 conf/jetty-realm.properties 和 activemq.xml 的认证配置中把默认账号密码全部替换成随机生成的强口令并清理掉不用的用户。4.2 升级到安全版本的正确姿势升级补丁是根治方案但实际操作中有几个坑。如果服务器上没有本地包管理仓库通常需要手动下载新版安装包。下载完成后不要直接覆盖原有的 activemq 目录建议先把原目录完整备份再把新版安装包解压到新目录随后把原配置文件和认证信息同步到新目录中。具体来说需要重点迁移的文件包括conf/activemq.xml这个文件里包含了连接器端口、持久化配置、插件配置。conf/login.config 和 conf/activemq-domain.xml这些文件包含认证和授权相关设置。data/ 目录下的持久化数据如果业务依赖消息持久化迁移前务必确认存储格式兼容。启动新版前建议先以测试配置方式启动检查日志有没有报错再逐步切换流量。切流时很多团队会选择直接重启但这可能造成消息堆积。稳妥做法是先让新集群加入在消费者端切换连接地址做完一个业务再切下一个。消息中间件升级不像普通应用升级期间业务影响面非常大必须做好回滚预案。4.3 升级后必须检查的事项升级完成不代表万事大吉至少要检查以下几项。首先确认版本号已经是修复版本用之前提到的 activemq version 命令验证。其次确认监听端口没有意外变化防止配置文件被新版本默认配置覆盖。最后是观察业务日志确认消费者和生产者的连接建立正常没有出现协议不兼容的报错。如果有自动部署流程建议把版本检查和端口监听状态检查嵌入发布流程。比如在发布脚本里强制校验 ActiveMQ 版本低于安全版本就直接拒绝继续发布这能从流程上避免再次出现“带病上线”。4.4 中长期加固清单除了升级我还建议把消息中间件的安全基线建起来。以下条目是我在实际项目中逐步整理出来的可以作为运维团队的安全检查项进程以独立低权限用户运行严禁使用 root。61616 端口只监听在内网 IP并配置防火墙白名单。启用认证和授权插件密码使用强随机口令并定期轮换。关闭不需要的协议连接器只保留业务使用的协议。开启身份认证之外的 JMX 访问限制防止 JMX 端口被绕过。至少保留最近两个大版本的升级路径确保补丁发布后能快速跟进。接入统一日志采集系统对 ActiveMQ 日志建立告警规则。这几点看起来基础但实际能完全做到的团队不多。特别是最后一条日志告警很多团队在出问题后才想起来加结果回溯攻击时间线时没有素材只能被动应对。日志不是事后才用的它必须在事件发生时就实时生效。5. 常见问题与排查技巧实录5.1 为什么升级后版本号还是老版本这种情况我遇到过好几次原因大概率是把新版压缩包下载到了某个目录然后在升级脚本里没有更新系统服务指向的启动路径。ActiveMQ 的启动脚本可能默认调用的是/opt/activemq/bin下的命令但你新版本解压到了/usr/local/activemq-new服务注册信息还是指向旧目录。检查版本号时会显示新版但实际跑着的进程还是老代码。解决方式很简单先ps -ef | grep activemq找到进程的真实启动路径再对照系统服务文件里的执行路径。如果是手动安装务必把新目录软链到统一路径比如/opt/activemq并重启服务。5.2 暂时不能升级时有哪些替代方案有些核心系统由于遗留客户端兼容性问题短期内确实无法升级。那就要把网络访问控制做到位并记录一个明确的整改时间点。一个可行方案是给 ActiveMQ 前面加一层只允许特定 IP 访问的安全组规则同时开启认证插件双重保险。另一个替代方案是使用容器化部署把 ActiveMQ 限制在独立的 Docker 网络里只有业务容器的网段能联通它外部直接绕开。这里要说明的是这些替代方案只能降低风险不代表漏洞不存在。建议在整改时间点内完成升级不要拖为了长期方案。5.3 日志里大量出现异常连接是被人尝试攻击吗如果你发现日志中有大量短连接或异常协议帧大概率是被安全扫描器碰上了。这种情况往往伴随多个来源 IP且发送的数据流模式比较机械。这时候不需要过度惊慌但要确认两点一是确认该 IP 段是否为你的业务方二是检查系统是否已经升级到安全版本。如果版本没问题这种扫描通常无功而返但也要把这些来源 IP 加入防火墙黑名单减少无效请求对系统资源的消耗。5.4 加固之后业务连接突然失败怎么排查最常见的原因是防火墙规则放行的网段和业务服务器的实际来源 IP 不一致。很多服务器有多块网卡或走了 NAT来源 IP 可能不是你预期的那一个。排查时可以在业务服务器上临时用 telnet 测试端口连通性或者直接在 ActiveMQ 服务器上用 tcpdump 抓包看来源地址tcpdump -i eth0 port 61616 -n -c 50抓包输出里会明确显示来源 IP对照防火墙白名单就知道问题在哪。这类问题在处理安全性加固时非常典型所以建议在变更窗口前先做一轮端口连通性验证别等着业务方反馈才排查。5.5 一个容易被忽略的坑多实例部署有时候一台物理机或虚拟机上跑了多个 ActiveMQ 实例分别监听不同端口。你只升级了其中一个另一个还在老版本状态。这种情况一定要靠资产梳理来兜底光靠登录服务器数端口还不够。建议把每个实例的端口、版本号、配置文件路径、运行用户都登记到资产管理平台升级时逐条核对。写在最后的一点体会经过这几次实际处置我最大的感受是消息中间件往往是最容易被低估的基础设施。它不像数据库那样直接存储核心资产也不像 Web 服务那样直面用户但它一旦出现安全漏洞对整个业务链的破坏力一点都不小。ActiveMQ 这个漏洞看起来只是协议解析层的一个疏忽落到运维手里却意味着一连串的版本梳理、端口管控、认证加固和升级切换工作。我的建议是把安全加固当成消息中间件日常运维的一部分而不是等到漏洞通告出来才临时抱佛脚。每次在大版本升级时顺手把认证、端口限制、日志告警这些基础项过一遍花费的时间不会超过半小时但能让后续的应急处理从容很多。最后再分享一个小技巧ActiveMQ 升级前先把 conf 目录单独打包备份放到异地这样即使新版本启动失败也能在五分钟内回滚到原状态。别问我是怎么知道这个习惯有多重要的踩过坑的都懂。