母盘镜像被篡改导致所有派生虚机共性故障，须立即停用并用原始ISO重建；确认依据包括共性异常、boot_id一致、关键文件哈希相同且偏离官方值、创建时间集中；修复禁用直接修改，应废弃母盘、重装干净系统并导入可信配置；预防需设母盘只读、强制backing file机制、CI/CD自动化校验与离线指纹存档。

母盘镜像被改，所有基于它的虚机启动失败或行为异常，不是虚机的问题，是源头坏了。必须立刻停用该母盘，从可信备份或原始ISO重建，不能在污染源上修。

怎么确认问题出在母盘而非单台虚机

增量虚机共性故障（比如全部无法获取IP、内核panic、/etc/passwd被清空、systemd启动卡死）是母盘被改的强信号。关键要排除“只是碰巧同时坏”：

• 检查各虚机的/proc/sys/kernel/random/boot_id——若完全一致，说明它们都从同一母盘快照启动，而非独立安装
• 比对任意两台虚机的sha256sum /bin/bash，若哈希值相同且与官方不匹配，基本锁定母盘级篡改
• 查看虚机创建时间戳：stat -c "%y" /var/lib/libvirt/images/*.qcow2 | head -n3，若创建时间集中在某次“维护窗口”后，高度可疑
• 不要依赖虚机内运行的rpm -Vf或debsums，母盘若被改，这些命令本身可能已失效

如何安全提取母盘原始状态做比对

母盘通常是qcow2格式，直接挂载风险高。应离线、只读、隔离分析：

• 用qemu-img info base.qcow2确认是否为base镜像（backing file字段为空）
• 创建只读快照用于分析：qemu-img create -f qcow2 -b base.qcow2 -F qcow2 snapshot.qcow2
• 挂载快照并提取关键文件：guestmount -r -a snapshot.qcow2 -m /dev/sda1 /mnt/tmp，然后校验/bin/ls、/usr/bin/sha256sum等基础二进制
• 对比必须用外部可信哈希：从同版本官方ISO中解包提取原始/bin/ls，本地计算sha256sum比对，不能信母盘自带的校验工具

修复时为什么不能直接修改母盘

母盘一旦写入，所有后续新建虚机都会继承污染。更危险的是：攻击者可能已在母盘中植入持久化后门（如修改过的systemd-logind或伪装成udev的rootkit），表面修复几个配置文件毫无意义。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 真正安全的做法是：废弃当前母盘，用原始ISO重装一个干净系统，再按需打补丁、配环境
• 若必须保留定制配置，应从干净母盘导出rsync -aHAX --exclude='/proc/*' --exclude='/sys/*' --exclude='/dev/*' / /backup/，再导入到新母盘，而不是复制被污染的整个镜像
• 严禁在生产环境直接qemu-img commit base.qcow2或virt-sysprep清理——这些操作会覆盖元数据，破坏取证链，且无法清除内核级rootkit

怎么避免下次再踩同样坑

母盘管理失控是运维最隐蔽的单点故障。核心不是“怎么修”，而是“怎么让改母盘这件事本身不可行”：

• 母盘文件设为只读：chown root:root base.qcow2 && chmod 444 base.qcow2，连root都无法直接写入
• 所有虚机必须通过qcow2的backing file机制创建，禁止cp base.qcow2 vm1.qcow2这种裸复制
• 母盘变更走CI/CD流水线：每次更新都触发自动化校验（如sersi工具检测+基础命令哈希比对），通过才允许发布
• 记录母盘指纹：每次生成新母盘后，立即保存sha256sum base.qcow2和guestfish -a base.qcow2 -i 'checksum sha256 /bin/bash'到离线介质

母盘被改不是技术问题，是流程断点。修复动作本身几条命令就能完成，但真正难的是让“谁都能改母盘”这件事，在权限、审计、自动化三层面彻底消失。