Linux启动过程被篡改的检测与GRUB密码保护

当你发现服务器响应异常、系统中多了未知进程，或者/var/log目录下的日志出现离奇的空白时段，第一反应往往是应用层被入侵了。但你有没有想过，问题可能出现在更早的阶段——在操作系统内核加载之前？Linux启动过程的篡改，尤其是对GRUB（Grand Unified Bootloader）的恶意修改，是高级持续性威胁和rootkit常用的手法。攻击者一旦控制了启动引导器，就能在内核初始化时注入恶意代码、绕过安全审计、甚至直接修改initramfs来植入持久化后门。这种攻击的隐蔽性极高，因为传统的HIDS（主机入侵检测系统）在操作系统完全启动后才开始工作，对boot阶段的恶意行为几乎无感知。

GRUB的配置文件通常位于/boot/grub/grub.cfg或/boot/grub2/grub.cfg，这个文件定义了内核启动参数和引导菜单。攻击者如果获得了root权限，可以在这个文件中添加init=/bin/bash参数，让系统启动后直接进入root shell而无需任何认证。更隐蔽的做法是修改内核命令行中的console参数或添加systemd.unit=backdoor.service，让一个恶意服务在系统启动时自动运行。还有一种手法是替换initramfs镜像，将恶意内核模块打包进去，这样即使你重装了内核，后门依然存在。

物理接触服务器的人还可以通过Live CD或USB设备启动，直接挂载/boot分区进行修改。这意味着，如果你的服务器托管在不可控的机房，或者内部人员有物理访问权限，GRUB就暴露在裸奔状态。更糟糕的是，大多数Linux发行版默认安装时不会给GRUB设置密码，任何能在启动时按'e'键进入编辑模式的人，都可以临时修改启动参数进入单用户模式，从而重置root密码或提取敏感数据。

检测启动过程是否被篡改，不能只依赖运行时的工具，因为如果内核本身已经被污染，它报告的任何信息都不可信。你需要从多个维度交叉验证。首先，定期对/boot分区下的所有文件做哈希校验是最基础的手段。你可以在一台干净的系统上，或者在系统刚安装完成、确认安全后，立即生成一份基准哈希库：

find /boot -type f -exec sha256sum {} \; > /root/boot_sha256.baseline

之后通过比对当前哈希值与基准值，就能发现任何细微的改动。但要注意，内核升级和正常的grub更新也会导致哈希变化，所以这个基准库需要随系统维护同步更新，并且配合包管理器的验证机制一起使用。在基于RPM的系统上，你可以用rpm -V grub2-common来检查GRUB包本身的完整性；在Debian/Ubuntu上，则可以用debsums命令。

更深入的检测方法是检查GRUB的实际行为。攻击者可能会在MBR（主引导记录）或GPT的引导区域植入恶意代码，而不是仅仅修改文件。你可以用dd命令提取磁盘的前512字节或整个EFI系统分区，与已知的干净副本进行比对。对于使用UEFI的系统，efibootmgr -v命令可以列出所有的启动项，仔细检查是否有来历不明的条目。有些rootkit会注册一个伪造的启动项，指向恶意的EFI可执行文件。

日志分析同样关键，但前提是日志本身没有被篡改。检查/var/log/syslog或journalctl输出中与systemd启动序列相关的记录，看是否有异常的服务启动时间戳或未知单元。如果发现某个服务在系统启动后几秒内就开始运行，且其名称看起来像系统服务但你不认识，那就值得深挖。另外，定期审计/boot分区的挂载状态也很重要——正常情况下，/boot应该以只读方式挂载，或者至少不应该在系统运行时被频繁写入。你可以检查/etc/fstab中/boot的挂载选项，确保其包含ro或至少noexec、nosuid等限制。

给GRUB设置密码是防止未授权修改的第一道防线。GRUB支持两种密码保护机制：一种是针对特定启动菜单项的密码，另一种是全局的超级用户密码。后者更严格，任何对启动参数的修改都需要先通过认证。实施步骤如下：首先，生成加密后的密码哈希。千万不要在配置文件中使用明文密码，GRUB提供了grub-mkpasswd-pbkdf2工具来生成基于PBKDF2的强哈希：

grub-mkpasswd-pbkdf2

输入两次密码后，工具会输出类似grub.pbkdf2.sha512.10000.xxxxx的字符串，这就是加密后的凭证。接下来，编辑/etc/grub.d/40_custom文件（这个文件是GRUB配置生成框架的一部分，专门用于自定义设置），添加以下内容：

set superusers="admin"
password_pbkdf2 admin grub.pbkdf2.sha512.10000.xxxxx

这里的admin是超级用户名，你可以自定义。如果你想对特定的启动项设置密码，而允许普通用户正常启动默认内核，可以在/etc/grub.d/10_linux等脚本中调整，但通常直接设置超级用户是最安全的做法。配置完成后，运行grub-mkconfig -o /boot/grub/grub.cfg（或update-grub）重新生成主配置文件。重启系统后，任何尝试在GRUB菜单中按'e'编辑启动参数或按'c'进入命令行模式的操作，都会要求输入用户名和密码。

对于UEFI系统，你还需要考虑一个额外的攻击面：UEFI固件本身的启动顺序。攻击者可能通过efibootmgr添加一个新的启动项，绕过GRUB直接加载恶意内核。因此，建议进入UEFI/BIOS设置界面，设置管理员密码，并关闭从USB、光盘等外部介质启动的选项。同时，启用Secure Boot（安全启动）功能，它只允许执行经过签名的EFI二进制文件，能有效阻止未签名的恶意引导程序运行。但要注意，启用Secure Boot后，一些第三方内核模块可能需要额外签名才能加载。

密码保护只是起点，真正的安全需要建立完整的信任链。在x86平台上，Intel的TXT（Trusted Execution Technology）和AMD的SME（Secure Memory Encryption）等硬件安全特性可以与tboot这样的可信启动工具配合，构建从固件到bootloader再到内核的度量链条。TPM（可信平台模块）芯片可以存储这些度量值，并在启动后通过远程证明向监控系统报告。即使攻击者修改了GRUB配置文件，TPM中的PCR（平台配置寄存器）值也会发生变化，从而被检测到。

对于没有TPM硬件的普通服务器，你可以使用Linux内核自带的IMA（Integrity Measurement Architecture）子系统。IMA能够在文件被访问或执行时进行完整性校验，并将度量结果记录在/sys/kernel/security/ima/ascii_runtime_measurements中。结合EVM（Extended Verification Module），还可以保护文件的扩展属性不被篡改。虽然IMA/EVM的初始配置比较复杂，但它提供了运行时的完整性保护，与GRUB密码的静态保护形成互补。

另一个容易被忽视的细节是/boot分区本身的文件系统选择。ext4和XFS等通用文件系统在性能上没问题，但它们缺乏内置的完整性校验。如果你对安全性有更高要求，可以考虑使用支持透明完整性校验的文件系统，或者在/boot上叠加dm-verity（设备映射器验证目标）。dm-verity是一个内核模块，它以块设备为单位进行哈希树验证，任何对底层数据的修改都会导致IO错误。将/boot分区设置为dm-verity只读卷，配合GRUB的密码保护，攻击者即使获得了root权限，也无法在系统运行时修改内核镜像或initramfs。

最后，监控和告警体系必须覆盖启动阶段。配置auditd审计子系统，监控/boot目录下所有文件的写操作和属性变更。将审计日志实时发送到远程日志服务器，防止攻击者在入侵后清理本地日志。你还可以设置一个简单的cron任务，每天比对/boot分区的哈希值，并在发现异常时通过邮件或即时通讯工具告警。这些措施虽然看似繁琐，但在面对能够修改bootloader的高级威胁时，它们是你最后的技术防线。