Censys 攻击面监控

它解决什么问题

资产一旦暴露在公网，管理成本就会快速上升：临时开的服务、忘记注销的证书、没人维护的边缘节点，都可能成为攻击入口。团队通常面临三个具体困难：

• 资产清单不完整：域名、IP、端口、证书分散在 whois、证书站点和扫描结果里，难以合并成一份可信的对外资产视图。
• 变化不可追溯：新增了哪些服务、TLS 配置是否被改动，往往要等扫描报告出来才知道。
• 告警无法落地：即使发现问题，也很难把「新出现的主机」自动推送到团队已有的工具里。

这个技能的目标是用 Censys 的扫描数据把这些重复劳动自动化。

技能如何工作

技能以 Censys Search API v2 为基础数据源，做两类核心操作：

• 主机发现：查询 Censys 全网扫描结果，定位面向互联网的主机与开放端口，替代手工遍历式扫描。
• 证书枚举：检索 TLS 证书中的组织名、域名与有效期，从证书侧反推未登记资产，同时拿到证书到期信息。

在此基础上，技能借助 Censys ASM（Attack Surface Management） 的查询能力：

• 参照 Censys 平台与 ASM 快速入门，构建、保存并自动化 ASM 查询，把资产过滤规则固化为可重复执行的查询。
• 官方提供的示例 ASM 查询可直接复用，作为监控规则的起点。
• 查询结果通过 webhook 触发增量告警，重点跟踪三类变化：新资产出现、暴露服务变化、TLS 配置调整。

整条链路是「固化 ASM 查询 → 取结果 → webhook 推送差异」，不需要自己维护独立扫描器。

适用边界与注意点

• 依赖扫描覆盖：数据来自 Censys 的互联网扫描，未被其扫描器触达的资产不会出现在结果中，不能替代内部网络发现。
• 需要上游凭证：API 调用与 ASM 查询都以 Censys 账号为前提，部署时需处理好凭证存放与轮转。
• 留意接口演进：Censys 存在旧版搜索和 ASM Python CLI，官方建议以 https://docs.censys.com/docs/internet-scanning 为准，旧接口行为可能与新 API 不一致。
• 告警质量取决于查询设计：webhook 只负责推送差异，误报率高低取决于 ASM 过滤条件写得有多准，过宽的条件会带来噪声。