Tsunami后门家族防御指南：从僵尸网络检测到应急响应-平芜编程栈

这里需要直接给出博文内容，不能有任何前置或后置说明。我将严格以安全的防御视角展开分析，全程使用虚构案例与代称，把重点放在攻击链路的“为什么”、特征研判的落地方法以及防守侧的加固、检测、响应实操上。所有内容只讲防守、识别、溯源与恢复，不提供任何可用于实施攻击的步骤细节，也不涉及任何与合规相关的敏感信息。

## 1. Tsunami后门家族全景认知 ### 1.1 它到底是个什么东西 Tsunami（海啸）这个名字，最早是安全圈对一类Linux平台恶意程序的统称。它最核心的身份不是窃密木马，也不是勒索软件，而是一个**被用来拼凑DDoS僵尸网络的模块化后门**。通俗讲，攻击者把大量被攻陷的服务器、物联网设备、云主机变成"提线木偶"，Tsunami就是那根控制木偶的线。一旦设备被植入成功，攻击者就能远程下发指令，让这台机器对指定目标发起大流量攻击，也可以临时当成跳板执行其他恶意操作。 我经常跟人打一个比方：如果把僵尸网络比作一家外卖平台，Tsunami相当于骑手端App——它本身不生产"战斗力"，但它负责把每一台肉鸡接入调度系统。真正的攻击指令，通常是通过后门内置的下载执行功能，再去拉取专门的DDoS攻击模块来实现的。所以分析这类样本时，不能只盯着后门本身的代码量，还要看它预留了哪些"接口"给后续模块。 需要特别强调的是，这里讨论的所有内容，出发点只有一个：**让防守方认出它、拦住它、清理掉它**。我会刻意跳过那些可以直接照抄的利用细节，重点讲怎么识别、怎么防、怎么查。 ### 1.2 常见变体与命名混乱 Tsunami在公开报告里经常跟一堆名字混着出现，比如某些厂商叫它"Linux.Tsunami"、"IRC Bohdi"、"GayFgt"，还有一些报告把它归纳为"XOR.DDoS"家族的近亲。命名混乱的原因很简单：这类后门是开源的，任何人都能拿到源码改一版，加个新功能就换一次名字。但不管你管它叫什么，**核心骨架基本不变**，变的无非是加密算法、C2地址格式、攻击模块种类。 我在实际分析中见过的变体，大致能分成三个代际： | 代际 | 典型特征 | 主要变化 | | ---- | ---- | ---- | | 早期 | 基于IRC协议通信，功能单一 | 只有简单的UDP/TCP洪水指令 | | 中期 | 引入自定义C2协议 | 弱加密、内置多个攻击模块 | | 近期 | 多重混淆、内存加载 | 无文件落地、C2域前置 | 所以看到一个Tsunami样本，先别急着下结论它是"哪个版本"，而是按照"通信协议怎么走、持久化怎么落、攻击模块怎么拉取"三个维度去做画像。画像比命名重要得多，因为抓到一个新的未知样本时，靠名字去查情报库经常是会漏报的。 ### 1.3 为什么值得单独拿出来讲 有人可能会问，一个老牌后门而已，值得费这么大劲吗？我的回答是：**它是当前大量僵尸网络事件的地基**。你可能在追踪某次大流量DDoS时，溯源到最后发现那批肉鸡身上都有Tsunami的变体；你也可能在日常巡检时，突然发现一台内网服务器上跑着一个名字很怪的健康检查进程，一查就是它。 另外一个原因是它的**攻击门槛极低**。因为源码公开，一些初级攻击者拿过来编译就能用，这导致它的感染面非常大。防守方如果只知道应急响应流程、却不懂怎么从样本层面识别和遏制，很容易陷入"清了又中、中了再清"的循环。 我在后面的内容里会按照"链路拆解 → 特征研判 → 防御落地 → 问题排查"这条线走，这正好对应了安全运营里最常见的需求路径：看得懂攻击、认得清样本、防得住落地、处置得干净。 ## 2. 攻击链路深度拆解 ### 2.1 初始入侵阶段的典型路径 Tsunami不会自己长腿跑进服务器里，它必须依赖一个"入口"。根据我梳理过的多个事件复盘，入侵路径基本就那几条，没有太多花活。 第一类是**暴露面的弱口令爆破**。很多企业的Linux服务器把SSH端口直接暴露在公网，用的还是root账户加简单密码。攻击者用爆破工具挂着字典一跑，几小时甚至几十分钟就能拿下一台机器。拿到权限后，第一件事就是下载Tsunami样本并执行，完成"装机"。 第二类是**已知漏洞的批量利用**。某中间件、某Web框架、某开源组件暴露出远程代码执行漏洞后，攻击者不会手工一台台打，而是用扫描器全网扫，扫到一个打一个。Tsunami作为最成熟的僵尸网络植入物之一，经常出现在这类批量利用的载荷链末端。 第三类是**供应链或运维入口的失控**。比如某台跳板机被攻破、某个运维后台密码泄露、某条云厂商API密钥泄露，攻击者通过这些"间接入口"横向移动或批量下发指令。这种情况下，Tsunami往往不是第一个进来的东西，而是攻击者稳定控制环境后主动部署的"基础设施"。 > 给防守方一个明确信号：**防住入口比研究样本更重要**。样本分析做得再好，弱口令不封堵，第二天照样被重新打进来。 ### 2.2 载荷投放与持久化机制 入侵成功之后，攻击者的下一步是从C2服务器把Tsunami本体下载到目标机器上。常见做法是使用wget或者curl拉取一个可执行文件，然后立刻赋予执行权限并运行。有些变体会用一段简短的脚本完成"下载-改名-隐藏-执行-清理"的全流程，让原始文件的痕迹消失在磁盘上。 持久化这块，不同变体差别很大，但大致可以归成四类机制： - **计划任务（crontab）**：插入一条定时任务，每隔一段时间从C2拉取最新配置或重新下载样本，维持存在感。 - **init脚本与服务自启**：在/etc/init.d/或者systemd目录里放下一个伪装成系统服务的文件，开机自动拉起来。 - **SSH后门**：写入一个公钥，或者替换SSH配置文件，让攻击者随时能以特定密钥免密登录——这种情况尤其危险，样本清了但后门没清，等于白干。 - **内核级或LD_PRELOAD注入**：这类更高级，直接改运行库加载逻辑，普通查杀工具很难发现。 我见过最头疼的是"计划任务+SSH公钥"双持久化组合。光杀掉进程、删掉文件是没用的，下次重启后任务计划又把它拉起来了。所以做应急处置的时候，**永远要按"进程、文件、计划任务、自启动项、SSH信任关系"五层一起排查**，缺一层都容易留尾巴。 ### 2.3 控制通道与C2通讯逻辑 Tsunami与C2通讯的设计，直接影响防守方能不能快速发现它。早期变体走IRC协议，样本伪装成IRC客户端去连接某个聊天频道，攻击者在频道里发指令，所有肉鸡都听令。这个设计今天看来很简陋，但在当年确实好用——因为IRC流量在服务器上并不显眼。 中期变体转向自定义TCP或UDP协议，有的会加一层异或或者RC4加密。它们通常会在样本里内置一个IP或域名作为C2地址，但这个地址可以动态更新，比如通过DNS解析切换、或者从某个公开的Paste站点拉取最新地址列表。这样一来，即便防守方封掉了第一批C2域名，攻击者也能快速漂移到新地址。 **通讯逻辑的核心是"心跳+指令"。** 肉鸡每隔几秒或几十秒发起一次心跳，告诉C2"我还活着"。C2收到后如果有待执行的指令，就在心跳响应里带回去。有些变体不做加密或只做弱加密，这种情况对防守方特别有利——你只要在网关或主机上抓包，用肉眼都能看到心跳特征。 但近期的变体开始使用TLS加密通讯，域名也换成了动态域名甚至套了CDN。这让基于IP封禁的传统手段失效，必须转向"行为检测+基础设施关联"的思路来应对。 ### 2.4 攻击模块的拉取与执行 Tsunami本身不直接发起大流量攻击，它干得最多的事是"下载和执行"。当C2下发一条攻击指令，样本就会从指定URL把攻击模块拉下来，用某种方式（比如system(3)调用、动态加载、或者直接执行新的进程）把它运行起来。 攻击模块的种类五花八门，常见的有： - **UDP洪水**：向目标端口发送海量UDP数据包，耗尽带宽资源。 - **TCP SYN洪水**：发送大量握手请求但不完成握手，耗尽目标连接表。 - **HTTP应用层攻击**：模拟慢速请求或高频请求，打倒应用本身。 - **DNS查询放大攻击**：利用可递归解析的DNS服务器做反射，把流量放大几十倍。 这一步非常关键，因为**很多防守方的检测系统只盯着Tsunami本体做规则，却忽略了下发攻击模块这个动作。** 我建议做检测规则时，一定要覆盖"新进程创建行为"——一台原本很安静的Web服务器，突然出现一个从/tmp或/var/tmp目录启动的未知进程，这本身就是强烈的恶意信号。 > 实操中一个很有用的技巧：定期快照服务器上所有可执行文件的列表，尤其是/tmp、/dev/shm、/var/tmp这些临时目录的异常文件。Tsunami一系样本特别喜欢在这些位置落地。 ## 3. 特征研判与指纹提取 ### 3.1 静态文件特征 拿到一个可疑的Linux可执行文件，第一反应肯定是做静态分析。Tsunami的特征在静态维度其实非常鲜明，关键看你会不会找。 首先是**文件属性异常**。正常软件不会把自己藏在/tmp里，不会用"kworker"、"crond"这种伪装名，也不会随意修改时间戳。用`file`命令一看，能确认它是x86-64还是ARM架构的可执行文件，再查一下哈希，拿去威胁情报平台比对命中率。 其次是**字符串线索**。即使加了壳或者做了字符串混淆，很多变体仍然会残留一些特征，比如内置的C2地址、用于异或加密的固定密钥、内置的下载URL格式、以及"Tsunami"品牌本身（因为部分变体并不删掉源码里的原始字符串）。用`strings`命令加`-a`参数把可打印字符串全部拉出来，常常能直接看到攻击者的基础设施信息。 第三是**二进制结构特征**。比如用了什么编译器、是否经过upx加壳、入口点是否正常。如果样本是Go语言编译的，会非常庞大且有明显的Go build info；如果是C语言编译、用gcc静态链接的，体积小、字符串清晰。这些细节有助于判断攻击者的技术水平和可能使用的编译环境。 但静态分析也有失灵的时候。有些变体做了高度混淆，正常字符串全部加密，只有运行时才解密。这个时候就需要放到动态环境里跑，或者结合网络行为一起看。静态分析的价值在于"快速分类和提取基础IOC"，最终的定性还是要靠行为证据。 ### 3.2 进程与网络行为特征 动态行为特征是最可靠的检测依据。一个被Tsunami感染的系统，最典型的表现是出现一个**连接外部服务器的可疑进程**。它的命令行长什么样、从哪个目录启动、Syscall行为是否异常，全部是可量化的指标。 我自己在主机侧常用的排查命令如下： ```bash # 查看监听端口和对应进程 netstat -antlp | grep -v "127.0.0.1\|::1" # 查看所有TCP连接的外联IP ss -antlp | grep ESTAB # 找到CPU占用异常但名字很像系统进程的程序 top -c # 查看最近被修改的可疑文件 find /tmp /var/tmp /dev/shm -type f -mmin -600 -ls # 查看计划任务 crontab -l && cat /etc/crontab

网络侧的行为特征也很有指向性。Tsunami的心跳通常具有固定的间隔和包长特征。如果你在网关设备上做流量镜像，把服务器外联流量抓下来看，你会发现某台主机每隔N秒就向同一个IP发送一个长度为特定字节的UDP包，这个节奏和正常业务流量完全不同。

对于加密通讯的变体，虽然看不到明文，但可以通过连接的行为模式判断：比如周期性连接、单次连接持续短、上下行流量比例严重失衡，都值得怀疑。如果有TLS解密能力最好，没有的话就靠元数据建模，也一样能发现问题。

3.3 IOC提取与威胁狩猎

威胁情报（IOC）是防守方打持久战的弹药库。分析一个Tsunami样本后，至少可以提取以下几类IOC：

文件哈希（MD5/SHA1/SHA256）
C2地址（IP和域名）
下载URL的路径特征
User-Agent特征（wget/curl默认UA）
进程名特征
持久化路径特征（计划任务内容、自启动项名称）

提取出来的IOC要立即落到检测体系里，而不是存在本地Excel里吃灰。有SIEM的就推到SIEM做关联查询，有EDR的就在EDR平台建自定义规则。我在实际工作中还会把IOC同时同步给防火墙和DNS解析设备，实现网络层的快速封禁和访问阻断。

威胁狩猎的思路是"从已知找未知"。首先用已知的IOC去全网搜一遍，看看有没有海量主机中招；其次是用行为特征做放宽搜索，比如"所有连接过已知C2的网络请求来源IP"；最后再收敛到可疑主机上做深入取证。这套流程每做完一次，整个网络的可见性就会提升一截。

特别提醒：IOC提取一定要保存好"置信度"字段。文件哈希的置信度最高，进程名的置信度较低（容易被仿冒或误报），在自动化封禁时要分级执行，避免把业务进程一起误杀。

4. 实战防御方案落地

4.1 基线加固清单

防御Tsunami这类后门，最省钱也最有效的办法是做好基线加固。以下清单是我个人强烈建议每台Linux服务器都逐项检查的：

关闭不必要的公网端口：SSH尽量只允许内网或指定IP访问，或者改用密钥登录并禁用root远程登录。
强制复杂口令与多因素认证：这是老生常谈，但出事的服务器80%都栽在弱口令上。运维后台、云控制台、数据库一律开多因素。
及时修复高危漏洞：建立漏洞台账，高危漏洞的修复周期不要超过一周。
最小化安装与服务：不装没用的组件，不做没用的端口映射。
部署主机安全Agent：至少要有进程白名单、文件变更监控和基础防篡改能力。
日志集中化存储：所有主机的认证日志、命令记录、网络连接日志都集中到日志平台，保留至少90天。
配置网络ACL：服务器出方向默认拒绝，只放行业务必须的端口，这样就算样本落地，它想回连C2都很困难。

我能理解"全公司几百台机器，哪有时间逐台加固"的抱怨，所以我建议优先对公网暴露的、核心业务所在的、有最高权限的三批机器做第一批加固。僵尸网络最喜欢挑软柿子捏，先把自己最硬的几台保护好，损失就不会失控。

4.2 检测规则示例

再好的基线也防不住零日漏洞，所以检测规则不能缺。这里给一组可以直接改改就用的YARA规则思路和IDEAS建模思路。

基于文件内容的检测示例，YARA规则的关键逻辑是匹配Tsunami家族常见的ELF特征和字符串组合：

rule Tsunami_ELF_Malware_Family { meta: author = "某安全团队" description = "Tsunami后门家族文件特征检测" strings: $elf_header = {7F 45 4C 46} $c2_marker = "Tsunami" ascii nocase $download_cmd = "wget" ascii nocase $dirty_url = "http://" ascii nocase condition: $elf_header at 0 and 1 of ($c2_marker, $download_cmd, $dirty_url) and filesize < 2MB }

这份规则的核心逻辑很朴素：检测所有小于2MB的ELF文件，并且里面同时出现了"Tsunami"字符串至少一个、下载命令关键词至少一个。实际使用时要调低误报率，可以把$c2_marker改成更独特的字符串。

基于行为的检测思路，在EDR平台上可以做一条简单的行为关联规则：

事件源：进程创建事件
条件：父进程为crond或systemd，且子进程路径在/tmp或/dev/shm下
附加条件：子进程存在外联网络连接行为
动作：自动隔离主机并告警

这类规则失灵的情况很少，因为正常业务进程几乎不会从临时目录启动并主动外联。类似的规则还可以加在"文件落盘+修改计划任务"的组合上。

4.3 应急处置流程

实战中最容易翻车的不是"发现不了"，而是"处置不完整"。我建议把Tsunami应急流程固化成标准操作手册，步骤越细越好。

第一步是隔离。发现中招主机后，第一时间断开其外网连接，但不直接关机——你还要取证。

第二步是取证。把进程列表、网络连接、计划任务、开机启动项、SSH信任文件全部拷贝出来，压缩加密后保存到专门的取证目录。

第三步是清理。杀掉恶意进程，删除恶意文件，移除计划任务，清理SSH公钥，检查LD_PRELOAD等环境变量。每一步都要记录下来，并且清理后立刻重新检查一遍，确认没有残留。

第四步是溯源。看日志找初始入侵入口，查是弱口令爆破还是漏洞利用，然后把这个入口堵死。这一步不做，后面必然复现。

第五步是恢复与持续监控。清理干净并堵住入口后，把主机重新接入网络，但必须将其加入到高监控名单里，连续观察至少一周，确认心跳消失、外联正常才算是彻底结束。

另外强烈建议：所有处置动作都保留截图和命令记录。一方面是为了复盘，另一方面也是安全合规工作的基础材料。

5. 常见问题与排查实录

5.1 问题速查表

现象	可能原因	排查建议
CPU异常飙高，但找不到高占用的业务进程	恶意进程伪装成系统线程，或使用了线程注入	用`top -c`按CPU排序，用`ps auxf`看进程树
服务器流量持续外发，带宽打满	已变成DDoS肉鸡，正在参与攻击	立即断网，使用`iftop`或`nethogs`定位流量进程
多次清除后仍然复发	持久化未清理干净，或SSH后门仍在	按"五层排查法"逐项复查
外联IP频繁变化，封不胜封	C2地址做了动态解析或域名前置	从DNS日志入手，找域名解析的关联记录，封域名而非只封IP
主机上找不到可疑文件	无文件落地，或已自删除，只在内存中运行	采集内存镜像分析，重点查进程链

5.2 两个典型排查案例

第一个案例，某公司的内网文件服务器出现卡顿，管理员在top里看到有个名为mysql-serve的进程占用了大量CPU。仔细一看，路径不对，正常mysql跑在/usr/sbin/，这个进程却从/tmp/.x/下启动。用ss -antlp追到外联IP是一个境外地址，按照我们前面说的流程，先断网、再取证、后清理，最终在计划任务里找到了第两行恶意条目。这就是很典型的Tsunami系样本特征。

第二个案例更有意思。某单位的业务服务器并没有明显的卡顿，但安全设备反复告警"连接可疑IP"。我上机手动排查，ps和netstat都没有异常，最后是靠auditd文件变更审计发现有人在/etc/rc.local里加了一行下载命令，聪明的攻击者把恶意进程命了名、随机化了路径，做得非常隐蔽。那一次要不是靠文件完整性监控兜底，单靠人工根本发现不了。

这两个案例放一起是想说明：没有一套单一工具能保证发现所有变体，纵深防御的价值就在于总有一层能兜住。

5.3 几个必须了解的免责声明

这里反复提到的所有分析、命令和思路，都只面向已经取得合法授权的安全测试、内部防御和应急响应场景。读到这里的朋友，如果你准备在自己的网络里做验证，请先确认这个设备是不是你自己的、有没有得到管理层的书面授权。把防御技巧用错了方向，后果是完全不一样的。合法合规是安全从业者的底线，也是整个行业能够健康运转的前提。