服务器固件层级安全启动链路：从UEFI到GRUB的完整性验证实战

服务器安全启动为什么绕不开固件层

服务器安全加固的讨论往往聚焦在OS层面的防火墙、SELinux、审计日志，但在APT攻击面前，这些措施的前提是操作系统本身未被篡改。如果攻击者在固件层植入了rootkit，OS层的所有安全机制都在攻击者控制之下。安全启动（Secure Boot）链路从硬件固件延伸到操作系统引导程序，每一层通过数字签名验证下一层代码的完整性，构建从芯片到OS的信任链。这条链路任何一个环节的断裂，都会让后续所有安全措施形同虚设。

UEFI Secure Boot的工作机制与配置

UEFI固件在开机后首先执行，它负责验证引导程序签名。验证流程：固件内嵌的Platform Key（PK）和Key Exchange Key（KEK）构成信任根；KEK签名了Signature Database（db）中的公钥证书；引导程序的签名必须在db中有对应公钥能验证通过。

查看当前Secure Boot状态和签名数据库：

# 查看Secure Boot状态
mokutil --sb-state

# 列出已注册的签名密钥
ls /sys/firmware/efi/efivars/ | grep -E "PK|KEK|db"

# 使用mokutil查看MOK列表
mokutil --list-enrolled

生产环境中常见的问题是第三方硬件驱动的签名未被db收录，导致Secure Boot阻止加载。解决方案不是关闭Secure Boot，而是将供应商签名证书注册到MOK（Machine Owner Key）列表中：

# 注册自定义签名证书
mokutil --import /path/to/vendor-cert.der

# 重启后在MOK管理界面确认导入
# 或自动化脚本方式：
mokutil --import /path/to/vendor-cert.der --root-pw

GRUB2签名验证的部署实践

UEFI Secure Boot验证到GRUB为止，但GRUB自身的配置文件和内核镜像不在验证范围内。攻击者如果能修改grub.cfg，可以通过initrd /path/to/malicious.img加载恶意initramfs。部署GRUB2签名验证需要从源码编译启用签名的GRUB。

编译过程关键步骤：

# 获取GRUB源码
git clone https://savannah.gnu.org/git/grub.git
cd grub

# 生成签名密钥对
openssl genrsa -out grub-sign.key 2048
openssl rsa -in grub-sign.key -pubout -out grub-sign.pub

# 编译启用签名验证的GRUB
./autogen.sh
./configure --with-grub-mkimage-sign-key=grub-sign.pub \
  --enable-grub-mkimage-sign-check
make -j$(nproc)

签名后的GRUB镜像在加载内核和initramfs前会验证签名，未通过验证的模块不会被加载。这填补了UEFI Secure Boot和OS内核之间的信任间隙。

内核模块签名验证的完整性闭环

内核启动后，动态加载的内核模块（.ko文件）同样需要签名验证。内核配置中启用模块签名后，insmod/modprobe在加载模块时验证签名，未签名或签名不匹配的模块会被拒绝。

# 内核配置
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y  # 强制模式，未签名模块直接拒绝
CONFIG_MODULE_SIG_SHA256=y

# 生成内核模块签名密钥
openssl req -new -x509 -newkey rsa:2048 \
  -keyout certs/signing_key.pem \
  -out certs/signing_key.x509 \
  -days 3650 -nodes \
  -subj "/CN=Kernel Module Signing"

# 签名内核模块
scripts/sign-file sha256 certs/signing_key.pem \
  certs/signing_key.x509 path/to/module.ko

强制模式（SIG_FORCE）在生产服务器上必须开启，否则攻击者可以通过insmod加载内核级rootkit。

TPM2.0远程证明与度量日志

安全启动链路的最终验证需要TPM2.0芯片参与。TPM在引导每个阶段记录度量值（PCR寄存器），远程证明协议允许验证方比对当前PCR值与已知基准值，判断系统是否被篡改。

# 读取TPM PCR值
tpm2_pcrread sha256

# 生成证明引用（quote）
tpm2_quote -c 0x81010001 -l sha256:0,1,2,3,4,5,6,7 \
  -q nonce123 -o quote.sig -p quote.pcr

# 验证证明
tpm2_checkquote -q nonce123 -s quote.sig \
  -p quote.pcr -g sha256

将PCR基准值存放在只读存储或可信第三方，每次启动后自动执行远程证明脚本，PCR值不匹配时触发告警和自动隔离。这一机制构成了安全启动链路的最后一道防线——即使前面所有验证都通过，TPM度量仍然可以发现运行时被篡改的情况。