Ubuntu ESM作用常见问题：如何验证ESM补丁是否生效？

Question

如何验证Ubuntu ESM补丁是否已成功应用？系统虽启用了ESM服务并执行了`apt update && apt upgrade`，但不确定关键安全补丁是否实际安装。使用`apt list --upgradable`未显示更新，但CVE报告仍提示存在漏洞。应通过哪些命令或日志确认ESM源提供的补丁已生效？例如，如何检查特定CVE补丁对应的软件包版本是否已升级？此外，`ua status`显示ESM服务已启用，但如何关联APT日志与ubuntu-security-updates中的ESM条目以确认补丁来源？

Answer 1

1. 初步确认：Ubuntu ESM服务状态与APT更新基础检查

在验证ESM补丁是否已成功应用前，首先应确认系统已正确启用Ubuntu Advantage（UA）的扩展安全维护（ESM）服务。执行以下命令查看当前UA状态：

ua status --verbose

输出中若显示 esm-infra: enabled 或 esm-apps: enabled，则表示ESM服务已激活。接下来，确保APT包管理器已同步ESM源：

sudo apt update

可通过检查本地APT缓存中的可用源来确认ESM是否被纳入：

grep -r "security" /etc/apt/sources.list.d/*

典型输出应包含类似如下条目：

deb https://esm.ubuntu.com/ubuntu/ jammy-infra-security main

这表明系统已配置从ESM源获取安全更新。此时再运行 apt upgrade 才可能实际安装ESM提供的补丁。

2. 深层验证：检查特定CVE对应软件包版本升级情况

当外部漏洞扫描工具报告某CVE仍存在时，需手动比对当前安装的软件包版本与官方修复版本。以CVE-2023-2086为例，假设其影响libssl库，可使用以下命令查询已安装版本：

dpkg -l | grep libssl

然后访问 Ubuntu CVE Tracker 查看该漏洞的“Releases”表格，确认jammy版本下修复所需的最低软件包版本号。

例如，若报告显示修复版本为 1.1.1f-1ubuntu2.18+esm1，而本地版本为 1.1.1f-1ubuntu2.17，则说明尚未升级。

注意带有 +esm 后缀的版本通常为ESM专有补丁包，仅通过ESM源提供。

CVE编号	受影响包	修复版本	来源类型
CVE-2023-2086	libssl1.1	1.1.1f-1ubuntu2.18+esm1	ESM-Infra
CVE-2022-42898	libnss3	2:3.80-1ubuntu1~esm1	ESM-Apps

3. 日志溯源：关联APT操作日志与ESM补丁来源

APT的日志文件位于 /var/log/apt/history.log 和 /var/log/apt/term.log，可用于追溯具体升级行为。执行以下命令筛选最近的升级记录：

zcat -f /var/log/apt/history.log* | grep -E "(Upgrade|Commandline)"

查找包含 ua refresh 或 apt-get upgrade 的条目，并关注升级的包名及其版本变化。例如：

Upgrade: libssl1.1:amd64 (1.1.1f-1ubuntu2.17, 1.1.1f-1ubuntu2.18+esm1)

其中版本后缀 +esm1 明确标识该更新来自ESM渠道。此外，可通过解析APT获取的元数据确认源地址：

apt policy libssl1.1

输出示例：

Installed: 1.1.1f-1ubuntu2.18+esm1
Candidate: 1.1.1f-1ubuntu2.18+esm1
Version table:
 *** 1.1.1f-1ubuntu2.18+esm1 500
        500 https://esm.ubuntu.com/ubuntu jammy-infra-security/main amd64 Packages
        100 /var/lib/dpkg/status

此处可见候选版本来自 esm.ubuntu.com 域名下的安全更新路径。

4. 自动化检测：构建CVE到包版本映射分析流程

为实现规模化验证，建议建立自动化脚本将CVE列表与本地包版本进行交叉比对。以下是基于Python和Ubuntu Security Notice（USN）API的简化流程图：

graph TD A[输入CVE列表] --> B{查询Ubuntu CVE Tracker API} B --> C[获取受影响包及修复版本] C --> D[调用dpkg -l获取本地版本] D --> E[版本比较逻辑] E --> F[CVE是否已修复?] F -->|是| G[标记为已缓解] F -->|否| H[生成告警并记录ESM状态] H --> I[输出报告至SIEM或工单系统]

该流程可集成进CI/CD流水线或合规审计平台，提升补丁验证效率。

5. 高级排查：处理“无更新但存在漏洞”的矛盾场景

常见原因包括：

• 未刷新APT缓存：即使启用了ESM，也需重新执行 apt update 触发源同步；
• 模块未启用：ua enable esm-infra 或 ua enable esm-apps 必须显式启用；
• 架构不匹配：某些ESM补丁仅适用于特定CPU架构；
• 第三方仓库干扰：其他PPA可能锁定旧版本；
• CVE误报：静态扫描工具未识别+esm补丁版本的实际修复能力。

建议定期执行完整诊断链：

ua refresh
sudo apt update
apt list --upgradable
ua status --verbose

同时结合 canonical-cve-tracker 工具集进行离线比对。