Log4j漏洞攻击如何防御？

Log4j漏洞（核心为CVE - 2021 - 44228等相关漏洞）的防御可从版本升级、临时配置调整、网络防护、代码管控等多个维度开展，兼顾紧急缓解与长期防护，具体措施如下：

1.  版本升级，彻底根除漏洞

    这是最根本的防御手段。Apache后续发布的版本逐步修复了该漏洞，建议直接将Log4j升级至2.17.1及以上稳定版本（如2.19.0等更新版本）。这些版本要么默认禁用了存在风险的JNDI功能，要么对其添加了严格的安全管控，从根源上阻断漏洞触发路径。需注意，升级前要排查版本兼容性，避免与项目其他依赖组件产生冲突。若实在无法适配新版，也可考虑替换为logback等更安全的日志框架，但替换后需完成全面测试，防止影响业务正常运行。

2.  临时配置调整，快速缓解风险

    对于无法立即升级的场景，可通过配置修改快速阻断漏洞利用：

    - 设置参数禁用查找功能：若Log4j版本在2.10及以上，可添加JVM参数 <代码开始>-Dlog4j2.formatMsgNoLookups=true<代码结束> ，或设置环境变量 <代码开始>LOG4J_FORMAT_MSG_NO_LOOKUPS=true<代码结束> ，以此禁用日志消息中的查找替换功能，避免触发JNDI注入；若版本为2.16.0及以上，还能通过参数 <代码开始>-Dlog4j2.enableJndi=false<代码结束> 完全禁用JNDI。

    -  删除危险类文件：针对2.0 - beta9至2.10.0之间的旧版本，可通过命令 <代码开始>zip -q -d log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class<代码结束> ，从log4j的核心jar包中删除JndiLookup类，切断漏洞利用的关键环节，操作后需重启相关服务使其生效。

3.  网络层防护，拦截攻击流量

    借助网络安全设备和策略阻挡恶意请求与连接：

    -  配置WAF规则：在Web应用防火墙中添加防护规则，拦截包含 <代码开始>{jndi:<代码结束> <代码开始>{ctx:<代码结束> 等恶意特征的请求，同时过滤HTTP请求头、表单提交等场景中的可疑字符串，阻止攻击者注入恶意代码。

    -  限制网络流量：实施网络隔离，限制服务器的出站流量，尤其禁止与外部未知的LDAP（端口389/636）、RMI（端口1099）等服务的连接，避免服务器向攻击者控制的恶意服务器发送请求并加载恶意代码；同时管控入站流量，只开放业务必需的端口。

    -  部署IDS/IPS监控：通过入侵检测与防御系统监控网络流量，识别JNDI注入相关的异常数据包和非常规协议通信，一旦发现可疑行为立即告警并阻断。

4.  代码与日志管控，减少攻击入口

    从应用开发层面减少漏洞被利用的可能性：

    -  过滤不可信输入：永远不要直接记录未经处理的用户输入，使用OWASP Encoder等工具对用户输入的字符串进行转义处理，将恶意字符转换为安全字符，避免恶意JNDI字符串进入日志系统。

    -  规范日志内容：梳理日志记录逻辑，避免在日志中记录用户提交的账号、请求参数等可能被篡改的不可信数据，从源头减少攻击者注入恶意代码的机会。

5.  常态化监控与依赖管理，长效防护

    漏洞防御并非一次性操作，需建立长效机制：

    -  定期扫描依赖：使用SCA（软件成分分析）工具如OWASP Dependency - Check，定期排查项目中隐藏的Log4j相关依赖（如第三方组件间接引入的旧版本Log4j），避免遗漏漏洞风险点。

    -  监控异常行为：持续审计系统日志，重点排查包含 <代码开始>jndi:<代码结束> 关键字的记录；同时监控服务器的异常出站连接，若发现向未知IP发起的LDAP、RMI连接，需及时核查是否遭受攻击。

    -  建立物料清单：梳理项目的软件物料清单（SBOM），清晰掌握所有第三方依赖的版本信息，后续可快速响应依赖组件的安全漏洞预警。