Ubuntu exploit修复后如何验证

Ubuntu 漏洞修复后的验证流程

一 本地版本与运行状态核验

• 更新索引并确认已安装软件为最新安全版本：执行sudo apt update，随后用apt list --upgradable查看是否仍有可升级项；对已安装包用dpkg -l | grep <包名>或dpkg-query -W -f ‘${Package} – ${Source}\n’ | grep <包名>核对版本与来源。内核修复需重启，重启后用uname -r确认正在运行的内核版本已高于受影响版本；同时可用dpkg -l | grep linux-image查看已安装内核包列表。若修复涉及Polkit/pkexec，执行pkexec --version确认版本不低于修复版本。以上步骤能直接证明“修复包已就位且生效”。

二 针对性 PoC 验证（仅限测试环境）

• 示例1 Shellshock（CVE-2014-6271）：执行env -i X='() { (a)=>' bash -c ‘echo date’; cat echo。修复后应仅输出date且不会创建文件，若仍出现命令执行或生成文件则说明未修复。
• 示例2 Polkit 提权（CVE-2021-4034）：在受控测试环境编译并执行公开 PoC，修复后应无法获取 root，通常返回帮助信息或报错而非 uid=0。
• 安全提示：PoC 仅用于受控验证，避免在生产环境运行；若 PoC 来自不可信来源，应先审计代码或在隔离环境测试。

三 配置与权限核验

• 内核与引导：若修复了内核，确认**/etc/default/grub及/boot/grub/grub.cfg已将新内核设为默认；必要时在修复前设置DEBIAN_FRONTEND=noninteractive以让系统自动选择新内核，或手动调整GRUB_DEFAULT**。重启后再次用uname -r核对。
• 关键文件与权限：核对**/etc/shadow权限应为600**、/root为700，防止敏感信息泄露与未授权访问。
• 服务与访问控制：如涉及SSH，检查**/etc/ssh/sshd_config中PermitRootLogin no**、自定义端口与AllowUsers等配置是否已生效，并重启sshd服务。
• 临时缓解残留：若曾为CVE-2021-4034做过“移除 SUID”的临时缓解，修复后应恢复**/usr/bin/pkexec的 SUID 位（如chmod 4755 /usr/bin/pkexec**），以免影响正常功能。

四 自动化扫描与日志复核

• 主机安全/云安全中心：在控制台对目标主机执行手动验证或等待定时全量检测复核结果；若修复的是内核漏洞或公告标注需要重启，务必重启后再验证。
• 系统审计：复核**/var/log/auth.log**等日志，排查异常登录与提权尝试，确认修复后无成功入侵迹象。
• 合规扫描：使用Lynis（如sudo lynis audit system）进行系统安全基线核查，确认高危项已消除或降级。

五 常见验证失败原因与处理

• 未重启或引导顺序错误：内核修复后未重启，或GRUB未将新内核设为默认，导致仍运行旧内核；按上文调整 GRUB 并重启，再用uname -r确认。
• 旧版本残留导致误报：系统已用新内核，但旧内核包未清理，安全产品仍按版本匹配报出漏洞；在确认业务稳定后清理旧内核包，或在控制台对该告警进行忽略处理。
• 源与订阅问题：Ubuntu 16.04–22.04若未配置Ubuntu Pro可能无免费补丁导致修复失败；企业环境需确认订阅与镜像源可用。
• 云侧验证时延：部分平台的全量检测为每日凌晨执行，修复后需等到下一次检测周期再看结果。