如果你负责过一批 Ubuntu 服务器的安全维护一定经历过这种尴尬厂商邮件通告来了才知道某个高危 CVE 已经在线上环境躺了半个月或者安全群刷屏了运维才慌慌张张去查哪些机器受影响。这背后的核心痛点就是缺乏一个自动化的漏洞情报聚合入口。这篇文章我打算用 Python 爬虫从零手把手搭一个 Ubuntu 安全漏洞情报中心把分散在公告页、漏洞库、发行版升级通知里的信息捞出来统一入库、去重、告警让漏洞情报从“被动等人通知”变成“主动实时感知”。先说结论这套情报中心不要求你有多高深的安全功底Python 基础语法会写、requests 和 BeautifulSoup 能跑通再加点 SQLite 基础一天之内就能搭完。搭完之后它能自动跟踪 Ubuntu 官方安全通告解析出 CVE 编号、影响软件包、受影响的 Ubuntu 版本、严重等级、修复版本入库后按需生成告警。适合的场景包括个人维护的一批 VPS、小团队内部的基础设施、或者作为你们安全运营平台的一个数据补充源。我知道很多人一听到“漏洞情报”就头大觉得这是安全团队才干的事。但实际上这事没那么玄乎。这篇文章的核心思路是把爬虫当作“粘合剂”把散落在不同页面的结构化信息汇拢到本地让后续的查询和通知变成一条 SQL 的事情。下面我从设计到实现把每一步的“为什么”也讲清楚。1. 为什么自建漏洞情报中心1.1 被动运维的代价多数人的漏洞管理流程是这样的每周手动去翻公告页看到新通告就复制标题然后回服务器逐个检查软件包版本。这个流程里有两个致命问题。第一个是时效性差。公告发布和你看到公告之间存在明显的时间差。在高危漏洞被公开利用的黄金窗口期晚一天处理风险等级完全不一样。第二个问题是易遗漏。Ubuntu 的软件包成千上万每个包都可能涉及独立的安全通告靠人工翻页根本盯不过来。如果是多台服务器还得逐台去跑 apt 更新检查效率极低。我自己的经历是有一段时间负责维护一组跑着 Web 服务的 Ubuntu 22.04 实例因为没有自动化的漏洞跟踪某次数据库相关的安全更新发布了两周我才注意到。虽然最后没出事故但那种“裸奔”的感觉非常糟糕。从那之后我就决定必须有一个自动采集、自动分析、自动通知的机制。1.2 方案选型API 优先爬虫兜底动手之前先明确一个原则能拿到官方 API 和结构化数据源就绝不先写爬虫。爬虫是最后的兜底方案不是首选方案。Ubuntu 官方维护了一套安全通告体系每条通告都有一个独立的 URL同时也提供了元数据接口返回 JSON 格式的数据。如果只是为了拿数据直接请求这个元数据接口是最稳的做法。那为什么还要聊爬虫因为我们会遇到一些场景官方接口覆盖不到。比如你想同时采集第三方镜像站上的包版本信息或者想从一些安全资讯聚合站点提取讨论上下文再比如官方接口偶尔变更字段结构你仍然需要一个 HTML 解析模块来替补。另外理解爬虫解析公告页面的过程本身就能帮你深入理解通告的结构这对于后续的数据关联很有帮助。所以这个项目的技术路线我定为“双通道”主通道优先走官方元数据 JSON备份通道走 HTML 解析。两条通道采集到的数据统一格式后写入同一个数据库。这样既有 API 的稳定高效又有爬虫的灵活兜底。2. 情报中心整体设计在动笔写代码之前我做了两件事画数据流图和定表结构。这个习惯帮我省了很多返工的时间。2.1 数据流与模块划分整个情报中心分成四个模块采集模块、解析模块、存储模块、告警模块。采集模块负责从目标源拉取原始内容。这里我用 Python 的 requests 库配合重试机制和超时控制。解析模块是核心负责把 HTML 或 JSON 变成统一的通告数据结构。存储模块用 SQLite表结构简单单机查询快对于这种个人级别的情报库完全够用。告警模块则通过内部通用的通知接口把新增漏洞推送出去。数据流向是单向的采集器定时触发 → 原始数据进入解析器 → 解析出结构化字段 → 写入 SQLite → 查询新增记录 → 触发告警。整个过程我用一个调度脚本串起来配合操作系统的定时任务来实现周期运行。这个模块化设计的好处是任何一个环节出了问题都不影响其他环节。比如采集模块被封了我可以手工导入数据文件解析和存储照常工作。2.2 技术选型与理由很多新手一上来就想用 Scrapy。我的建议是这个场景不需要。Scrapy 适合大规模、多域名、需并发抓取的场景而我们的情报中心数据源相对单一请求频率不高用 requests BeautifulSoup 就非常清爽依赖少、易调试、出错时堆栈也直观。具体选型如下Python 3.10主流版本类型注解和语法糖都成熟。requests发送 HTTP 请求配合重试和超时。BeautifulSoup4 lxml解析 HTML提取字段。SQLite3Python 内置库零部署成本。schedule 或系统 crontab定时调度。有人会问为什么不用 pandas 来存数据因为 pandas 适合做分析不适合做增量更新和去重。我们这里需要频繁地执行“查询已有记录、插入新记录”的操作SQL 是更自然的表达。3. 核心实现采集与解析实战这一节是全文的重点我会把采集和解析过程拆开讲并提供可以直接改用的代码。注意下面的代码不是玩具是我的项目里实际在用的精简版。3.1 数据源结构与目标分析Ubuntu 官方安全通告页面的结构经过分析可以归纳出几个固定的特征每条通告有独立的标题、唯一标识符编号、对应的 CVE 列表、受影响的发行版本列表、修复版本号以及严重程度标记。HTML 层面通告列表页里的每条通告是一个条目区块包含链接和摘要。进入详情页后字段分布在不同的表格和列表中。我们的爬虫要做的就是从这些非结构化标签里抽取出我们关心的字段。拿一条实际的通告来说它可能长这样编号USN-1234-1CVECVE-2024-5678优先级High影响包openssl受影响版本Ubuntu 22.04 LTS修复版本1.1.1n-0ubuntu1.10爬虫要做的就是把这个结构稳定地解析出来。如果你也想抓其他发行版的公告思路完全一样先人工分析两三条页面找到标签规律再写代码。3.2 采集模块请求与重试采集模块的代码不难但要注意两个细节设置合理的超时时间以及对连接错误做指数退避重试。有些公告页偶尔响应慢如果不设置超时爬虫线程会长时间挂着浪费资源。import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry def create_session() - requests.Session: session requests.Session() retry Retry( total3, read3, connect3, backoff_factor0.5, status_forcelist(500, 502, 504), ) adapter HTTPAdapter(max_retriesretry) session.mount(https://, adapter) session.mount(http://, adapter) session.headers.update({ User-Agent: Mozilla/5.0 (X11; Linux x86_64) VulnerabilityMonitor/1.0 }) return session我用了 urllib3 的 Retry 机制connect3 表示连接失败重试 3 次backoff_factor0.5 表示每次重试间隔逐渐变长。很多人喜欢无限重试但这在高频定时任务里是个坑——如果目标站挂了你的任务会被拖死。设置合理的重试次数失败就跳过留待下一轮采集。3.3 解析模块从 HTML 中提取字段解析模块是整个系统里最容易写崩的地方。因为 HTML 结构会变类的命名也可能变。我的做法是先抓一个真实页面存到本地用 BeautifulSoup 解析写抽取逻辑跑通之后再把本地的脚本切到线上。from bs4 import BeautifulSoup import re def parse_notice_detail(html: str) - dict: soup BeautifulSoup(html, lxml) title soup.select_one(h1).get_text(stripTrue) notice_id re.search(rUSN-\d-\d, title) cve_section soup.find(dt, stringre.compile(CVE)) cve_items [] if cve_section: dd cve_section.find_next_sibling(dd) if dd: cve_items [a.get_text(stripTrue) for a in dd.select(a)] severity sev_section soup.find(dt, stringre.compile(Priority)) if sev_section: severity sev_section.find_next_sibling(dd).get_text(stripTrue) packages [] pkg_table soup.select_one(table.packages) if pkg_table: for row in pkg_table.select(tbody tr): cells row.find_all(td) if len(cells) 2: pkg_name cells[0].get_text(stripTrue) version_info cells[1].get_text(stripTrue) packages.append({name: pkg_name, version: version_info}) return { notice_id: notice_id.group(0) if notice_id else , title: title, cve_list: cve_items, severity: severity, packages: packages, }这个函数里的 select_one、find、find_next_sibling 都是基于 BeautifulSoup 的常见操作。需要特别注意的是我用了多个空列表做初始默认值而不是 None因为后续入库时列表为空比 None 好处理。解析的坑主要在包的提取上。有时候一个包名对应多行有时候版本区域里还包含仓库名。我的建议是先解析出最完整的包名和版本字符串入库之后再人工抽查几条逐步优化正则。4. 数据落地与告警通知采集和解析只是前戏让数据流动起来才能产生价值。这一部分我详细说存储和告警。4.1 存储设计SQLite 表结构我用两张表一张存通告主表一张存通告对应的 CVE 明细表。主表的核心字段是通告编号、标题、严重级别、披露时间、公告链接。CREATE TABLE notices ( id INTEGER PRIMARY KEY AUTOINCREMENT, notice_id TEXT UNIQUE, title TEXT, severity TEXT, published_at TEXT, url TEXT, raw_html TEXT, created_at TEXT DEFAULT (datetime(now)) ); CREATE TABLE cves ( id INTEGER PRIMARY KEY AUTOINCREMENT, notice_id TEXT, cve_id TEXT, package_name TEXT, fixed_version TEXT, UNIQUE(notice_id, cve_id, package_name) );UNIQUE 约束在这里非常重要。它可以防止重复插入处理并发插入时也安全。每次采集完成我只需要执行一条 INSERT OR IGNORE就能自动完成增量更新。查询时用 JOIN 表关联就能按 CVE 编号查通告或者按包名查历史漏洞。4.2 增量更新与去重策略增量更新的核心逻辑是这样的每次解析出一条新通告先按 notice_id 查数据库存在就跳过不存在就插入。这样无论跑多少轮数据都不会膨胀。但还有一个容易忽略的问题同一个通告里的 CVE 列表可能会更新。比如某个漏洞最初只影响两个版本后来确认第三个版本也受影响。这种情况下如果简单跳过已有通告就会漏掉新增的影响信息。我的处理方式是在主表上增加一个“内容指纹”字段把 CVE 列表排序后做哈希每次解析后比对指纹不一致就更新明细表。一个简单可靠的插入函数def insert_notice_if_new(conn, notice: dict) - bool: cur conn.cursor() cur.execute(SELECT notice_id FROM notices WHERE notice_id ?, (notice[notice_id],)) if cur.fetchone(): return False cur.execute( INSERT INTO notices (notice_id, title, severity, url) VALUES (?, ?, ?, ?), (notice[notice_id], notice[title], notice[severity], notice[url]) ) for cve in notice[cve_list]: cur.execute( INSERT OR IGNORE INTO cves (notice_id, cve_id) VALUES (?, ?), (notice[notice_id], cve) ) conn.commit() return True注意这里我用了 commit 放在函数末尾而不是每插入一条就提交。批量提交对比逐条提交性能差距在高量级下非常大。我们这里是低量级但养成批量提交的习惯总是好的。4.3 告警通知邮件与 Webhook数据入库后的最后一步是告警。我实现了两种通知方式邮件和企业微信/钉钉机器人类似的 Webhook。Webhook 的好处是实时性高适合推送到手机邮件适合留存和事后审计。Webhook 的通知代码很简单核心就是构造一个 JSON 消息体然后 POST 到指定地址。我这里用了一个抽象的方法方便你替换成自己的通知渠道。def send_alert(notice: dict): severity notice.get(severity, ) cve_count len(notice.get(cve_list, [])) text f新增通告 {notice[notice_id]} | 严重级: {severity} | 涉及CVE数量: {cve_count} payload {msgtype: text, text: {content: text[:200]}} webhook_url https://your-webhook-url requests.post(webhook_url, jsonpayload, timeout5)这里有一个非常实用的细节告警文案不要写成长篇大论最好控制在手机通知栏能一屏看完的长度。详细内容放到数据库里需要的人自己查。因为每秒都会被安全信息轰炸的工程师真的没时间看一封长邮件。5. 实际运行中的坑与排查记录你以为代码写完就结束了太天真了。真正常年运行一个爬虫项目八成的时间都在处理各种异常。我把自己踩过的主要坑整理成了一份问题速查表。5.1 常见问题速查表问题现象直接原因解决方案请求偶尔超时目标站点响应慢增加超时时间重试机制留足间隔解析不到 CVE 列表HTML 结构改版保存页面快照更新选择器重复告警多次推送指纹对比逻辑有漏洞确认入库事务提交后再发告警数据库增长很快每次全量采集都新建记录排查 UNIQUE 约束是否生效定时任务没有触发crontab 环境变量缺失使用绝对路径日志输出到文件其中重复告警这个问题我记得调试了最久。明明表里已经有 notice_id 了但每次运行都提示新增。后来发现是数据库的事务没有正确提交查询端在同一连接里查不到其他连接写入的数据。这个教训是写完写入逻辑务必检查事务提交的上下文。5.2 反爬与频率控制虽然我们爬的是公开公告页理论上压力不大但反爬意识还是要有的。我的原则是控制频率按业务需要设置采集间隔一小时一次足够严格设置请求头 User-Agent表明自己是个正常的客户端绝不从头到尾高频扫站。如果你遇到 403 或者被拒绝访问先不要慌检查是不是 User-Agent 被识别了再检查是不是需要带 Cookie。这个项目里我用的是无状态请求没有登录需求理论上不存在身份验证问题。如果碰上 IP 被封的情况最简单的方法是降低频率或者等一段时间再跑而不是立刻去换 IP 继续怼。5.3 关于自动化监控的拓展思路情报中心搭好之后不要停在这里。你可以接着做几个高价值的拓展。第一个拓展是“关联本地资产”。也就是把你手上的服务器列表和软件包清单导入 SQLite每次拿到新的安全通告就自动去匹配哪些机器安装了受影响版本。这个简单但极其实用能让你的告警从“某某包有漏洞”变成“你的 10.0.0.8 这台机器需要升级”。第二个拓展是“镜像源对比”。定期拉取软件源里的最新版本和公告里的修复版本对比自动算出哪些机器“应该升级还没有升级”。这一步做完整个漏洞生命周期管理就闭环了。第三是“历史数据报表”。基于库里长期积累的数据你可以按月统计漏洞趋势、修复耗时时长这些数据在复盘和向团队汇报时特别有说服力。我个人在实际运行中的体会是爬虫代码本身不难难的是让它稳定地跑上几个月。稳定的关键不是技术多高级而是流程设计得干净——状态可查、异常可感知、数据可追溯。你把这个情报中心当成一个长期运行的小服务来对待别当成一次性脚本它就会越用越顺手。最后再分享一个小技巧每次解析逻辑改完先跑一次历史页面的回归测试看看有没有把之前解析正常的页面解析崩。我为此准备了一个固定样本文件夹把历次保存的 HTML 样本放进去每次改完代码就跑一遍全量样本保证不破坏旧的解析能力。这个习惯让我的情报中心在信息源改版时总能平稳过渡。
