作者简介：唐晓宁，拥有十余年架构设计开发、故障排除、性能优化经验。 曾任GCS高级中间件技术支持工程师。 主要处理亚太地区用户遇到的技术问题。 产品包括、、、、等，用户覆盖通信、金融、金融、税务、电力等大型企事业单位和政府机关。 目前就职于北京海天起点，负责中间件相关技术支持服务。
所谓序列化就是将对象转换为字节流，以便保存在内存、文件、数据库中，或者在网络上传输对象的字节序列； 而反序列化是序列化的逆过程，将字节序列转换为字节流。 油门恢复到物体。
当两个进程远程通信时，它们可以互相发送各种类型的数据。 但无论是什么数据，它都是以二进制序列的形式在网络上传输的。 发送方需要将Java对象转换为字节序列，然后才能通过网络传输（序列化）； 接收方需要将字节序列恢复为Java对象（反序列化）。 在许多应用程序中，特定的对象需要被序列化。 最常见的示例之一是集群。 为了实现复制，对象必须是可序列化的，否则我们会在日志中看到很多警告消息。 ，不能保证正常运行。
反序列化本身不是问题。 问题在于，Java 类在执行反序列化操作时不会检查自己的输入。 然后，恶意攻击者可以构造特定的输入，导致反序列化产生意外的对象。 ，从而远程执行任意代码。
许多主流序列化库中都存在相关漏洞，其中影响最大的是工具集。 广泛应用于JAVA技术平台，包括、IBM、JBoss、等。 即使应用程序代码中没有使用其中的类，只要其中包含的jar包就可能导致远程恶意代码的执行。 目前，不少Exp通过允许Java序列化协议的端口将攻击代码上传到服务器，然后远程调用上传类实现任意代码执行。
2. 简单测试
关于反序列化漏洞，网上已经有很多深入的分析和POC。 本文不会详细讨论它们。 只需使用最简单的小工具ols.jar，进行简单的测试即可。 在有漏洞的环境下，执行上述jar包可以在指定路径下生成一个文本文件，说明代码执行成功。
我们的测试环境是10.3.6，没有安装任何补丁。
执行完成后可以看到在指定路径d:\下生成了一个.txt。
同时在日志中可以看到一条，也验证了执行过程已经完成：
漏洞确实存在。
3. 堵塞漏洞的配置
官方针对该级别漏洞CVE-2015-4852发布了专门补丁，已在特定版本中修复。 今年，CVE-2017-3248 已修复在 10.3.6.0 上。 建议用户更新至最新版本。 这些补丁通过黑名单过滤掉危险类别，但仍然存在被绕过的风险。 同时，对于已经超过维护生命周期且仍有大量用户使用的版本，目前尚无官方修复版本可用。
回顾当年的官方文件：
以上，相关漏洞需要通过t3(s)协议，因此在没有补丁可用的情况下，过滤t3(s)协议可以有效避免出现问题。
上述配置表示允许任意地址（*）通过t3(s)协议访问192.168.1.107的7001端口，禁止t3(s)访问其他地址的7001端口。 如上所述，我们没有有限的监听地址，这意味着127.0.0.1、192.168.1.107等都可以用来访问同一个服务，这让我们可以直观地看到同一个服务上的协议过滤器是否可以做出不同之处。
可以看到指定路径下生成了文件，但是没有； 从输出信息也可以看出，尝试上传时连接被拒绝，过滤器设置成功。
4. 总结
打补丁绝对是最安全的方法，但在没有补丁的情况下使用其他方法来避免漏洞也很重要。 本文仅从配置阶段验证协议过滤的有效性。 其实类似的功能可以通过防火墙、代理服务等来实现。也就是说，严格的网络环境配置可以避免大部分问题。
5. 补充
另一位同事的文档对官方解决方案和非官方临时解决方案进行了更详细的解释，包括打补丁的过程，大家可以参考一下。
