三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

当netstat失效时，如何用tcpdump揪出内核级Rootkit隐藏连接

发布时间：2026/8/9 6:48:04 三亩地 编程学习日记
当netstat失效时，如何用tcpdump揪出内核级Rootkit隐藏连接

1. 项目概述：当常规工具失效时的深度排查

在应急响应和系统安全排查的日常工作中，netstat、ss、lsof这类命令是我们的“瑞士军刀”，能快速列出系统上的网络连接、监听端口和关联进程。然而，当面对一个精心设计的内核级木马或Rootkit时，这些依赖操作系统/proc文件系统或特定系统调用的工具，往往会成为攻击者首要的欺骗和隐藏目标。它们返回的“干净”结果，恰恰是最大的陷阱，会让你误以为系统安然无恙，实则暗流涌动。

我最近处理的一起安全事件就完美复现了这种场景。告警显示服务器存在可疑外联，但登录后使用netstat -tulnp和ss -tulnp检查，所有连接看起来都正常，与已知业务端口匹配。用ps aux和top也找不到可疑进程。这种“一切正常”的假象，正是高级内核Rootkit的典型特征——它通过劫持系统调用或内核函数，在数据返回给用户空间之前，就过滤掉了与自身相关的所有信息。

这时，tcpdump的价值就凸显出来了。它工作在数据链路层，直接抓取流经网卡的原始数据包。无论上层应用、系统调用甚至内核模块如何伪装和隐藏，只要数据包要从网卡发出或接收，tcpdump就有机会捕获到它。这个项目，就是一次在netstat等工具集体“失明”的情况下，如何仅凭tcpdump这根“盲杖”，结合系统知识和分析技巧，一步步揪出隐藏极深的内核级木马连接链路的实战记录。这不仅是一次技术排查，更是一次对抗高级隐匿技术的思维演练。

2. 内核级木马的隐匿原理与netstat的局限性

要理解为什么netstat会失效，必须先明白它和内核级木马各自的工作层级。netstat本身并不主动探测网络，它只是一个信息展示工具，其数据源主要来自/proc/net/tcp、/proc/net/tcp6、/proc/net/udp等伪文件系统。当用户执行netstat时，它会读取这些文件，内核中的网络子系统会将这些文件的内容动态生成并返回。

2.1 内核Rootkit如何“欺骗”netstat

一个成熟的内核级Rootkit（如LKM - Loadable Kernel Module）会通过以下一种或多种方式实现隐匿：

  1. 挂钩系统调用（Syscall Hook）：修改sys_read、sys_getdents等系统调用的内核函数指针。当netstat尝试读取/proc/net/tcp或遍历/proc目录时，Rootkit的恶意代码会先于原始函数执行，过滤掉与木马相关的连接条目或文件信息，再将“净化”后的结果返回。
  2. 挂钩虚拟文件系统操作（VFS Hook）：/proc是一个虚拟文件系统，其文件操作（如open、read、iterate）在内核中有对应的函数。Rootkit可以直接挂钩这些VFS操作函数（如seq_operations中的show方法），在数据生成阶段就剔除恶意连接。
  3. 直接操纵内核数据结构：更底层的Rootkit可能会直接修改存储TCP/UDP连接信息的核心内核数据结构（如tcp_hashinfo表）。netstat读取/proc文件时，内核从这些已被篡改的数据结构中提取信息，自然无法看到被隐藏的连接。

从我们参考的威胁情报案例中可以看到，木马（rmgr.ko）明确注册了kprobe来挂钩seq_show函数，专门处理对/proc/net/tcp的读取操作，从而抹除木马网络连接。同时，它还挂钩了vfs_readdir来隐藏相关文件。这就是netstat和ls /proc失效的根本原因。

2.2 tcpdump为何能成为“照妖镜”

tcpdump的工作层面低得多。它利用libpcap库，直接与系统的数据包捕获机制（如Linux的PF_PACKET套接字）交互。其基本流程是：

  1. 将网卡设置为混杂模式（非必需，但某些情况需要），以便接收所有经过网卡的数据包。
  2. 通过系统调用，直接向内核注册一个过滤器，告诉内核：“把所有匹配过滤条件的数据包副本发给我”。
  3. 内核网络驱动在收到或发送数据包时，会将其副本传递给tcpdump进程。

关键在于，数据包的捕获发生在网络协议栈的底层，远在Rootkit可能挂钩的那些面向应用层的系统调用和文件操作之上。即使Rootkit隐藏了连接信息，只要它需要通过网络与外界（C2服务器）通信，就必须产生真实的网络流量。这些数据包在经由网卡驱动进入协议栈的瞬间，tcpdump就有能力将其捕获。

注意：这并不意味着tcpdump绝对无法被干扰。理论上，一个权限足够高、编写在更底层（如网络驱动层）的Rootkit也可以尝试过滤发给tcpdump的数据包。但这类Rootkit编写难度极大，且极易导致系统不稳定，在实际攻击中非常罕见。因此，在绝大多数情况下，tcpdump是比netstat可靠得多的网络状态取证工具。

3. 实战环境搭建与初步异常感知

在开始抓包破案之前，我们需要一个“案发现场”。假设我们接到告警，一台IP为192.168.1.100的Linux业务服务器疑似被入侵，存在异常外联。我们已通过加密通道（如跳板机）登录。

3.1 初步排查与“正常”假象

首先，进行常规检查，结果却显示一切“正常”：

# 检查所有TCP/UDP监听端口和已建立连接 $ netstat -tulnp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1234/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 567/cupsd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 789/nginx tcp 0 0 192.168.1.100:22 192.168.1.50:54322 ESTABLISHED 1234/sshd tcp 0 0 192.168.1.100:80 203.0.113.5:49215 TIME_WAIT - # 没有看到明显的异常端口或IP # 使用ss命令再次确认，结果一致 $ ss -tulnp # 检查进程列表，未发现明显异常进程 $ ps aux --sort=-%cpu | head -20 $ top -bn1 | head -20 # 检查计划任务、服务、最近修改的文件等 $ crontab -l $ systemctl list-units --type=service --state=running $ find /etc /var /tmp -type f -mtime -2 2>/dev/null | head -20

所有明面上的检查都指向一个结论：系统干净。但安全设备的告警不会空穴来风，这种“过于干净”反而加深了我们的怀疑。

3.2 启用tcpdump进行全流量捕获

既然用户层工具可能被欺骗，我们就直接诉诸最底层的流量。在怀疑存在恶意外联的情况下，我们需要对出站流量进行重点监控。

# 首先，确定服务器的业务网卡名称，通常是eth0、ens33等 $ ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever # 使用tcpdump在eth0网卡上抓包，重点监控出站连接 # -i eth0: 指定网卡 # -n: 不解析主机名和端口服务名（加快速度，避免DNS查询干扰） # -s 0: 抓取完整数据包（而非默认的96字节） # -w capture.pcap: 将原始数据包保存到文件，供后续详细分析 # 'dst host not 192.168.1.0/24': 过滤条件，只抓取目标地址不是本地局域网(192.168.1.0/24)的流量。这可以大幅减少数据量，聚焦可疑外联。 $ sudo tcpdump -i eth0 -n -s 0 -w capture.pcap 'dst host not 192.168.1.0/24' tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C

让tcpdump在后台运行一段时间（例如10-30分钟），以捕获可能的周期性心跳或指令通信。然后按Ctrl+C停止。

实操心得：在生产环境抓包，尤其是全流量或长时间抓包，务必注意：

  1. 磁盘空间：-s 0抓全包会迅速消耗磁盘空间。可以使用-C 100参数限制每个文件100MB，或使用-W 10限制最多10个文件循环写入。
  2. 性能影响：在高流量服务器上抓包可能增加CPU负担。如果条件允许，可以在业务低峰期进行，或者将抓包文件写入临时内存文件系统（如/dev/shm）。
  3. 过滤是关键：一开始可以使用宽泛的过滤条件（如port not 22 and port not 80排除已知业务流量），发现疑点后再逐步缩小范围。上述命令dst host not 192.168.1.0/24是一个很好的起点，它假设恶意连接是通向外部网络的。

4. 基于tcpdump流量的深度分析与线索挖掘

抓包完成后，我们得到了一个capture.pcap文件。直接打开看是二进制乱码，我们需要用tcpdump或更强大的Wireshark（如果服务器有GUI或可下载到本地分析）来解读。

4.1 初步流量概览与可疑连接发现

首先，我们对抓包文件做一个高层面的统计，看看有哪些外部IP和端口被访问。

# 读取pcap文件，统计所有目标IP和端口（即服务器发起的连接） $ tcpdump -n -r capture.pcap 'ip' | awk '{print $5}' | cut -d. -f1-4 | sort | uniq -c | sort -nr | head -20 150 203.0.113.5.80 # 大量到80端口的流量，可能是正常业务或爬虫 45 93.184.216.34.443 # 到某个IP的443端口，可能是正常HTTPS业务 8 8.8.8.8.53 # DNS查询，正常 5 198.51.100.23.443 # 又一个HTTPS连接 3 192.0.2.100.26657 # 可疑！目标端口26657，非标准端口 # 进一步查看与这个可疑IP:Port的所有通信 $ tcpdump -n -r capture.pcap 'host 192.0.2.100 and port 26657' -A reading from file capture.pcap, link-type EN10MB (Ethernet) 18:30:15.123456 IP 192.168.1.100.45678 > 192.0.2.100.26657: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 1000 ecr 0,nop,wscale 7], length 0 18:30:15.234567 IP 192.0.2.100.26657 > 192.168.1.100.45678: Flags [S.], seq 987654321, ack 123456790, win 65535, options [mss 1460], length 0 18:30:15.234568 IP 192.168.1.100.45678 > 192.0.2.100.26657: Flags [.], ack 1, win 502, length 0 18:30:20.345679 IP 192.168.1.100.45678 > 192.0.2.100.26657: Flags [P.], seq 1:10, ack 1, win 502, length 9 0x0000: 4500 003d 0000 4000 4006 0000 c0a8 0164 E..=..@.@......d 0x0010: c000 0264 4567 6829 1234 5678 9876 5432 ...dEgh).4Vx.vT2 0x0020: 8018 01f6 fe31 0000 0101 080a 0000 03e8 .....1.......... 0x0030: 0000 0000 6865 6172 7462 6561 74 ....heartbeat 18:30:20.456780 IP 192.0.2.100.26657 > 192.168.1.100.45678: Flags [P.], seq 1:15, ack 10, win 65535, length 14 0x0000: 4500 0036 0000 4000 4006 0000 c000 0264 E..6..@.@......d 0x0010: c0a8 0164 6829 4567 9876 5433 1234 5682 ...dh)Eg.vT3.4V. 0x0020: 8018 0100 fe2a 0000 0101 080a 0000 03e9 .....*.......... 0x0030: 0000 0000 636f 6d6d 616e 643a 7069 6e67 ....command:ping

分析结果令人震惊！我们的服务器（192.168.1.100）正在使用一个随机高端口（45678）与外部IP 192.0.2.100 的 26657 端口通信。通信内容以明文传输，可见到heartbeat和command:ping等字样。这极像是一个木马的心跳包和指令通道！

然而，回想我们之前用netstat检查时，根本没有看到到192.0.2.100:26657的ESTABLISHED连接。这证实了我们的猜想：有一个内核级组件隐藏了这个连接。

4.2 关联进程信息的缺失与突破

在常规排查中，netstat -tulnp或ss -tulnp的优势在于能直接关联PID和进程名。现在这条路被堵死了。我们需要从其他角度关联这个隐藏连接。

思路一：通过连接四元组反查可能的进程虽然连接被隐藏，但TCP连接在内核中必然由某个文件描述符（socket）持有。我们可以尝试检查所有进程打开的文件描述符，看是否有匹配的socket。

# 方法1：使用lsof检查所有网络连接（但lsof也可能被Rootkit欺骗） $ sudo lsof -i @192.0.2.100:26657 # 很可能没有输出 # 方法2：更底层地检查/proc/net/tcp_raw（如果存在）或直接遍历/proc/[pid]/fd # 这是一个笨办法但可能有效：遍历所有进程的fd目录，查看socket inode $ for pid in $(ls /proc | grep '^[0-9]\+$'); do if [ -d /proc/$pid/fd ]; then for fd in /proc/$pid/fd/*; do # 读取fd指向的socket inode ls -l $fd 2>/dev/null | grep -q 'socket:\[' if [ $? -eq 0 ]; then inode=$(ls -l $fd | awk -F'[\\[\\]]' '{print $2}') # 在/proc/net/tcp中查找这个inode（尽管被篡改，但可以尝试） # 更直接的是用ss -aep | grep "ino:$inode" echo "PID: $pid, FD: $(basename $fd), Inode: $inode" fi done fi done

这个脚本运行起来很慢，且由于/proc/net/tcp被篡改，通过inode关联可能失败。但有时Rootkit只隐藏特定连接，而ss -aep命令可能从其他未被挂钩的路径获取信息，可以尝试：

$ ss -aepn | grep 192.0.2.100:26657 # 如果ss也失效，则无输出

思路二：利用tcpdump的时间戳关联系统日志如果木马进程在执行命令或访问文件时留下了系统日志（如auditd、syslog），我们可以将tcpdump捕获到指令的时间点与系统日志进行关联。

# 假设我们在tcpdump中看到指令下发时间为 18:30:20 $ grep "18:30:2[0-5]" /var/log/syslog /var/log/auth.log /var/log/secure 2>/dev/null # 或者查看audit日志（如果启用） $ ausearch -ts 18:30:20 -te 18:30:25

思路三：检查异常的内核模块既然怀疑是内核级木马，检查已加载的内核模块是必须的。

$ lsmod Module Size Used by xt_CHECKSUM 16384 1 ipt_MASQUERADE 16384 1 ... (其他标准模块) ... ati_remote3 24576 0 # 可疑！一个远程控制模块？但服务器并无ATI遥控器硬件。 $ modinfo ati_remote3 filename: /lib/modules/$(uname -r)/kernel/drivers/input/misc/ati_remote3.ko description: ATI Remote Wonder III license: GPL ...

发现一个可疑模块ati_remote3，其描述是“ATI遥控器”，这与服务器硬件环境严重不符。参考威胁情报案例，攻击者正是将恶意内核模块伪装成ati_remote3.ko并放置在标准驱动路径下。这几乎就是铁证！

4.3 网络行为模式分析与C2特征提取

回到tcpdump分析，我们需要更深入地分析这个隐藏连接的行为模式，以确定其危害和后续处置方向。

  1. 通信频率：使用tcpdump -r capture.pcap 'host 192.0.2.100' | awk '{print $1}' | uniq -c分析数据包的时间间隔。规律性的心跳（如每30秒一个heartbeat包）是木马的典型特征。
  2. 数据包大小和内容：使用-A（ASCII）或-X（十六进制）查看载荷。除了心跳，可能还有文件传输、命令执行结果回传等。例如，看到command:download http://evil.com/tool或result:uid=0(root)等内容。
  3. 协议模仿：高级木马会模仿合法协议（如HTTP、DNS、SSH）进行通信以绕过网络IDS。在我们的案例中，端口26657并非标准HTTP/HTTPS端口，但通信内容却是明文指令。参考威胁情报，该端口被一个伪造的sshd（rmgr_fake_sshd）监听，用于转发C2指令，这解释了为什么流量看起来不像加密的SSH。

我们可以编写一个简单的脚本，从pcap文件中提取与C2通信的所有有效载荷：

# 使用tshark（Wireshark的命令行版本）提取TCP流内容 $ tshark -r capture.pcap -Y "ip.src==192.168.1.100 and ip.dst==192.0.2.100 and tcp.dstport==26657" -T fields -e tcp.payload 2>/dev/null | xxd -r -p heartbeat command:whoami command:download http://x.x.x.x/malware.sh ...

5. 根除与加固：从发现到处置

发现内核级木马后，处置必须格外小心，避免打草惊蛇或导致系统崩溃。

5.1 谨慎取证与影响评估

在采取任何清除动作前，尽可能完成以下取证工作：

  1. 内存转储：如果条件允许，使用LiME或AVML等工具对系统内存进行完整转储，供后续深度分析。
  2. 恶意文件提取：根据发现的线索（如ati_remote3.ko模块路径），将相关的恶意文件复制到安全位置。注意使用dd或cat命令直接读取磁盘块，避免通过可能被挂钩的系统调用。
    $ sudo dd if=/lib/modules/$(uname -r)/kernel/drivers/input/misc/ati_remote3.ko of=/tmp/malicious_module.ko bs=4096 $ sudo cp -a /tmp/.tmp_* /tmp/rmgr_* /evidence/ 2>/dev/null # 尝试复制临时文件
  3. 网络连接快照：虽然netstat不可信，但可以记录下tcpdump发现的活跃恶意连接四元组（源IP:Port -> 目标IP:Port）。
  4. 评估影响范围：检查系统关键文件（如/etc/passwd、/etc/shadow、~/.ssh/authorized_keys）是否被篡改。检查计划任务、系统服务、启动项等持久化位置。

5.2 清除恶意组件

清除内核Rootkit风险很高，可能导致系统蓝屏。理想情况是隔离系统后离线分析。如果必须在线清除：

  1. 卸载恶意内核模块：

    $ sudo rmmod ati_remote3

    警告：如果模块卸载时触发了自毁代码或导致内核崩溃，系统可能立即宕机。务必在业务可接受中断的时间窗口进行，或优先选择隔离而非卸载。

  2. 终止用户态进程：找到与恶意模块关联的用户态进程（如rmgr_daemon、rmgr_fake_sshd）。由于它们被隐藏，可能需要通过排查/proc下异常进程的exe软链接或maps文件来定位。

    # 暴力但有效的方法：检查所有进程的内存映射，查找包含可疑路径的so文件 $ for pid in $(ls /proc | grep '^[0-9]\+$'); do if grep -l "rmgr_fake_libc" /proc/$pid/maps 2>/dev/null; then echo "Found suspicious PID: $pid" cat /proc/$pid/cmdline 2>/dev/null | xargs -0 echo fi done # 找到后强制终止 $ sudo kill -9 <PID>

  3. 删除恶意文件：删除所有已识别的恶意文件。注意，某些文件可能在运行时被锁定，需要先终止进程再删除。

    $ sudo rm -f /lib/modules/$(uname -r)/kernel/drivers/input/misc/ati_remote3.ko $ sudo rm -f /etc/sysconfig/modules/ati_remote3.modules $ sudo find /tmp -name “.tmp_*” -o -name “rmgr_*” -exec rm -f {} \;

5.3 系统加固与恢复

清除后，系统可能仍处于不安全状态，需进行加固：

  1. 修复入口点：排查并修复导致入侵的漏洞（如弱口令、未授权服务、应用漏洞）。
  2. 检查持久化：全面扫描所有启动项（/etc/rc.local、/etc/systemd/system/、cron、profile文件等），确保没有残留的恶意启动脚本。
  3. 恢复文件完整性：如果系统有文件完整性监控（如AIDE、Tripwire）的基线，进行比对。对于关键系统二进制文件（如netstat、ps、ls、sshd），可以从干净的系统或安装介质中恢复。
  4. 启用安全模块：考虑启用内核安全特性，如 SELinux 或 AppArmor，并配置为 enforcing 模式。启用内核模块签名验证，防止未签名模块加载。
    # 在GRUB配置中启用模块签名验证（需重启） $ echo "module.sig_enforce=1" >> /etc/default/grub $ update-grub
  5. 部署HIDS：安装基于行为监控的主机入侵检测系统（HIDS），如Osquery、Wazuh等，它们通过直接读取内核内存或使用eBPF等技术，能够更好地对抗Rootkit的隐藏。
  6. 最彻底的方案——重装系统：对于已被内核级入侵的系统，最安全、最推荐的做法是备份必要数据后，彻底重装操作系统。因为无法保证Rootkit没有对内核或其他核心组件进行不可逆的修改。

6. 构建持续监控与防御体系

单次应急响应解决的是“点”的问题，要应对“面”的威胁，需要构建体系化的监控。

  1. 网络层监控：在网络边界或核心交换机部署IDS/IPS，设置规则检测非常规端口的出站连接（如本例中的26657端口）、与已知恶意IP（IoC）的通信、以及不符合业务模型的协议流量。
  2. 主机层监控：
    • 基线监控：建立系统进程、端口、账号、内核模块的合法基线，定期对比。
    • 行为监控：监控异常进程创建、特权操作、敏感文件访问等行为。
    • 完整性校验：对系统关键文件和目录进行定期哈希校验。
  3. 采用不可篡改的审计机制：将系统日志（syslog、auditd）实时发送到远程的、受保护的日志服务器。即使主机被完全控制，攻击者也无法抹除已发送的日志。
  4. 定期进行威胁狩猎：不依赖告警，主动使用tcpdump、auditctl、eBPF工具（如bpftrace）在关键服务器上进行深度流量和系统调用分析，寻找失陷指标（IoC）和攻击战术（TTP）。

7. 总结与反思：工具思维与对抗升级

这次实战的核心教训是：永远不要完全信任单一工具或单一数据源。netstat的失效不是工具的错，而是攻击者针对其依赖的抽象层（/proc文件系统）进行了降维打击。

tcpdump之所以能成为最后的防线，是因为它工作在更底层、更接近硬件的网络数据流层面。这给我们应急响应人员提了个醒：当高层抽象（系统调用、文件系统）可能被污染时，要善于利用底层的、原始的数据源（原始网络包、内存镜像、磁盘扇区）进行交叉验证。

同时，内核级Rootkit的对抗是一场“道高一尺，魔高一丈”的持续战争。攻击技术在进化，防御技术也在发展。eBPF技术的出现为安全监控提供了新的可能，它允许在内核中安全、高效地运行沙盒化程序，能够以更难以被传统Rootkit干扰的方式观测系统行为，或许是未来对抗此类高级威胁的有力武器。

最后，保持系统最小化权限、及时更新补丁、部署多层次防御体系，永远是成本最低、效果最好的安全策略。应急响应是亡羊补牢，而坚固的防御体系才能让我们不必总是忙于补牢。

编程学习 学习日记 实战经验
← 返回列表