apache dubbo反序列化漏洞怎么排查

我见过太多团队栽在dubbo反序列化漏洞上，序列排查时像无头苍蝇一样乱撞。化漏其实思路就一条：先确认版本，洞排再查攻击面，序列最后看流量。化漏

第一步，洞排翻pom文件或者lib目录，序列直接看dubbo版本号。化漏低于2.7.15的洞排，基本都有反序列化风险。序列别信什么“我们升级过”的化漏鬼话，要亲眼看到版本号才作数。洞排我有次去客户现场，序列对方拍胸脯说肯定升过级，化漏结果一查，洞排2.6.8，连CVE-2020-1948的修复补丁都没打。

版本确认有问题，下一步就是找暴露面。dubbo默认走20880端口，但很多公司图省事，把provider和consumer都挂在公网网关下。用nmap扫一下全端口，重点看有没有非标准端口开着dubbo协议。有个案例挺典型——某公司把dubbo服务混在tomcat里，端口改成8081，扫描器根本没识别出来，直到后面被入侵了才想起来查。

光查端口还不够，得看注册中心。dubbo依赖zookeeper或nacos做服务发现，如果这些注册中心没做鉴权，攻击者完全可以自己注册一个恶意consumer，直接拉取服务列表。排查时用zkCli连上去，执行ls /dubbo，看看有没有陌生服务名。我见过最离谱的一次，注册中心里躺着几十个根本没部署过的服务，全是黑客挂的探针。

如果以上都没问题，那就得看流量了。tcpdump抓20880端口的包，重点看反序列化特征——dubbo协议头是魔数0xdabb，抓到之后检查body部分有没有java序列化流的标志（aced0005开头）。别指望人工翻包，直接上规则：凡是body里出现java.lang.Runtime或者com.sun.org.apache.xalan的，基本实锤了。

我自己的排查习惯是：先拿dubbo自带的telnet命令测一下，连上20880，执行invoke看响应。如果返回的是异常堆栈而不是正常结果，十有八九是被人打了。有一次就是这么发现的——对方用ysoserial的CommonsCollections5链打过来，dubbo直接报了ClassNotFoundException，日志里躺着一长串gadget类名。

还有个容易漏的地方，dubbo的hessian2序列化也危险。很多人只盯着java原生序列化，忘了hessian2同样能触发反序列化。排查时别只看Serializable接口，凡是实现了com.alibaba.dubbo.common.serialize.support.hessian.Hessian2ObjectInput的类，都得过一遍。

最后说句实在话——如果确认被打了，别急着重启服务。先dump内存，用jmap把堆导出来，找找有没有被注入的class。我有次帮人排查，重启后攻击痕迹全没了，连入侵时间点都确定不了。留证据比修复重要，毕竟你得知道对方进来干了什么。