实战记录：Oracle ARM 实例深度瘦身、灾备闭环与隐蔽木马绝杀指南

日常维护一台 2 核 12G 的 Oracle Cloud ARM 实例时，偶然发现 CPU 居高不下且历史备份包异常臃肿。经过一番系统排查，不仅将核心备份体积从近 10GB 压缩到 800MB，还连根铲除了一起利用”零宽隐形字符”潜伏的 DDoS 木马。本文完整记录排查、瘦身与安全加固的全过程。

一、背景与排查痛点

• 主机环境：Oracle Cloud ARM 实例（2 OCPU, 12GB RAM, 100GB 引导卷，Ubuntu 22.04 LTS）。
• 核心业务：个人独立博客、Hermes AI Agent 环境、日常运维组件。
• 异常现象：
• 过去偶尔备份时，压缩包动辄上 10GB，远端 AMD 小鸡（50GB 盘）根本放不下。
• 机器偶发 SSH 假死断连，面板监控显示 CPU 长期处于 99% 甚至 100% 满载。

二、灾备优化：彻底瘦身与全自动化闭环

1. 揪出膨胀元凶

最初尝试全量打包时，压缩包体积巨大。排查后发现两大空间黑洞：

• 影视/媒体网站历史缓存：单是海报与附件就占了 7.3GB。
• AI Agent 依赖环境：Hermes 目录中下载的独立 Node/Python/FFmpeg 二进制运行库及 Git 版本历史包累计占了近 2GB。

2. 精准排除规则配置

创建 /root/backup_scripts/exclude.txt，精准拦截无需重复备份的工具链与版本库：

*hermes-data/tools*
*hermes-data/lazy-packages*
*hermes-data/installs*
*hermes-data/cache*
*.git*
*node_modules*
*.sock
*.log
*.tmp

3. 一键自动化灾备脚本

编写自动化脚本 /root/backup_scripts/daily_backup.sh，仅提取全量数据库、博客站点与 Hermes 核心记忆数据，并配置 7 天滚动清理：

#!/bin/bash
set -e

BACKUP_DIR="/backup"
DUMP_DIR="/backup/dumps"
EXCLUDE_FILE="/root/backup_scripts/exclude.txt"
DATE_STR=$(date +%Y%m%d_%H%M%S)
TARGET_FILE="${BACKUP_DIR}/oracle_arm_core_${DATE_STR}.tar.gz"

mkdir -p "$DUMP_DIR"

# 1. 导出 MySQL 数据库
BT_MYSQL_PASS=$(python3 -c "import sqlite3; conn=sqlite3.connect('/www/server/panel/data/default.db'); c=conn.cursor(); c.execute('select mysql_root from config limit 1;'); print(c.fetchone()[0])" 2>/dev/null || cat /etc/my.cnf | grep -i 'password' | head -n 1 | awk -F'=' '{print $2}' | tr -d ' "')

/www/server/mysql/bin/mysqldump -u root -p"$BT_MYSQL_PASS" --socket=/tmp/mysql.sock --all-databases > "${DUMP_DIR}/all_databases.sql" 2>/dev/null || \
mysqldump -u root --all-databases > "${DUMP_DIR}/all_databases.sql"

# 2. 精准压缩打包
tar -czf "$TARGET_FILE" \
  --exclude-from="$EXCLUDE_FILE" \
  "$DUMP_DIR" \
  /www/wwwroot/boke.xunda.nyc.mn \
  /root/hermes-data

# 3. 清理临时导出文件与旧版本
rm -f "${DUMP_DIR}/all_databases.sql"
find "$BACKUP_DIR" -maxdepth 1 -name "oracle_arm_core_*.tar.gz" -mtime +7 -exec rm -f {} \;

成果：最终备份包从最初包含媒体的近 10GB、到全量依赖的 1.7GB，直接缩减至 860MB，每天凌晨 03:00 自动执行，7 天历史备份仅占约 6GB 磁盘，极为轻量稳定。

三、安全惊魂：DDoS 肉鸡与”零宽隐形字符”木马排查

在部署定时任务时，通过 crontab -l 发现系统负载异常的真正原因——机器被植入了高危外发发包木马。

1. 伪装极深的暗门：零宽字符欺骗

查看计划任务时，发现了以下看似普通的异常行：

- * * * pgrep -x .rcuop_0 > /dev/null || /dev/shm/.rcuop_0 > /dev/null 2>&1 &

• 隐蔽手法：黑客在 rcuop 字母之间插入了 Unicode 零宽字符（Zero-Width Space）。肉眼看起来是英文字母，但直接用 grep -v "rcuop" 进行过滤时会被完全绕过，导致常规清理命令失效。
• 物理机制：利用 Linux 的共享内存目录 /dev/shm 存放挖矿木马，并定时轮询自启。

2. DDoS 发包与 CPU 100% 满载

通过系统进程进一步追踪，捕获到了真正的算力黑洞：

nohup timeout 10800 hping3 --udp --flood --faster -p 30001 70.39.181.33 ...
nohup timeout 10800 hping3 -S --flood --faster -p 30001 70.39.181.33 ...
nohup timeout 10800 hping3 --icmp --flood --faster 70.39.181.33 ...

攻击者利用系统内安装的 hping3 工具，疯狂向外网目标发起 UDP、ICMP、SYN 洪水攻击，直接吃死 CPU（单进程占 63%），这也是 VPS 经常在外部 SSH 访问时超时的根源所在。

四、彻底清剿与系统加固操作

为了不给木马任何复活的机会，实施了全链路剿灭：

1. 强杀进程与卸载发包工具

# 强杀攻击进程
pkill -9 -f "hping3" 2>/dev/null || true
pkill -9 -f "timeout.*30001" 2>/dev/null || true
pkill -9 -f "/dev/shm/\." 2>/dev/null || true

# 物理卸载并清除发包工具
apt-get remove -y --purge hping3 2>/dev/null || true
rm -f $(which hping3 2>/dev/null) /usr/sbin/hping3 /usr/bin/hping3

2. 正则剥离零宽隐形定时任务

绕过关键字搜索，直接针对异常前缀和路径进行清洗：

crontab -l | grep -v '^- \*' | grep -v 'dev/shm' | crontab -

3. 抹除异常残留用户与配置

检查 /var/spool/cron/crontabs/ 底层目录，发现攻击脚本创建的历史用户残留，统一注销并抹掉空配置文件：

rm -f /var/spool/cron/crontabs/custom /var/spool/cron/crontabs/dev /var/spool/cron/crontabs/testnezha

五、总结与成效

• 负载回归：清理完成后，CPU 占用从长期的 99% 骤降至 1% ~ 3%，系统温度与资源大幅缓解，彻底告别假死断连。
• 存储健康：甲骨文免费 200GB 引导卷配额中，本台 ARM 分配的 100GB 磁盘剩余高达 70GB+，860MB 的每日核心灾备滚动保留毫无压力。
• 运维反思：对于云主机，不能仅看进程名，定期的定时任务审查（crontab -l 以及 /var/spool/cron/crontabs/）与出站带宽监控是发现”暗门”的关键。