Censys实战:5分钟教你用SSL证书追踪暴露的服务器(附真实案例)
在数字资产安全管理的日常工作中,我们常常面临一个挑战:如何快速、准确地发现那些本应隐藏在内部网络,却意外暴露在公网上的服务器?传统的端口扫描和IP段探测不仅效率低下,而且容易被防火墙和入侵检测系统拦截。今天,我想和你分享一种更为优雅、精准且常常被忽视的资产发现方法——利用SSL/TLS证书信息进行追踪。这种方法绕过了对IP和端口的直接探测,转而从公开的证书透明度日志中挖掘线索,往往能发现那些常规扫描工具难以触及的“影子资产”。
想象一下,你是一家大型企业的安全工程师,某天突然接到通知,需要紧急梳理公司所有对外暴露的服务器资产。时间紧迫,范围巨大,传统的扫描方式如同大海捞针。这时,如果你懂得如何利用Censys这类网络空间测绘引擎,结合SSL证书的独特属性,就能在几分钟内勾勒出资产轮廓,甚至发现一些连运维团队都未曾登记在册的“惊喜”。这不仅仅是技术操作,更是一种资产发现思维的转变:从主动“敲门”询问,变为被动“倾听”互联网上公开的“身份声明”。
SSL证书,作为服务器在互联网上的“数字身份证”,其包含的组织信息、域名信息都是公开可查的。尤其是证书透明度日志,它要求所有公开信任的证书颁发机构将其签发的证书记录到公共日志中。这意味着,任何一张为公网服务签发的证书,其信息都已悄然记录在案,成为我们进行资产测绘的宝贵数据源。接下来,我将通过几个真实场景,手把手带你掌握这套高效的工作流。
1. 理解SSL证书:你的资产在互联网上的“身份证”
在深入操作之前,我们有必要重新认识一下SSL/TLS证书。它远不止是浏览器地址栏里那个绿色的小锁。从技术角度看,一张标准的X.509证书包含了一系列结构化的字段,这些字段正是我们进行资产关联和追踪的关键。
证书的核心字段及其测绘价值:
- 主题(Subject): 包含了证书持有者的详细信息,最常见的是CN(通用名称)字段,通常就是域名。例如,CN = *.example.com 表示这张证书适用于example.com及其所有子域名。这是资产归属最直接的证据。
- 颁发者(Issuer): 签发证书的证书颁发机构。通过追踪同一家CA为同一组织签发的所有证书,可以间接发现关联资产。大型企业通常有固定的合作CA。
- 主题备用名称(Subject Alternative Name, SAN): 这是资产发现的“富矿”。一张证书可以绑定多个域名或IP地址。我见过不少企业的证书,其SAN字段里密密麻麻列出了数十个内部域名、测试环境域名甚至旧的域名,这些信息在内部资产清单里可能早已被遗忘。
- 序列号与指纹: 证书的唯一标识。即使服务器IP变更,只要证书没换,我们就能通过指纹持续追踪同一台服务。
- 有效期: 过期的证书往往意味着被遗忘的服务,这些服务的安全风险通常更高。
证书透明度(Certificate Transparency, CT)日志是这一切成为可能的基础。为了防范恶意或错误签发的证书,主流浏览器要求CA将签发的证书公开记录到CT日志中。这些日志是公开可查询的数据库,Censys等引擎会持续抓取并索引这些数据。因此,当你为api.internal.company.com申请了一张证书时,即便这个域名从未在公开DNS中解析,它的记录也已经留在了CT日志里。
提示: 不要只盯着CN字段。许多资产发现的最佳结果隐藏在SAN字段中。一张用于CDN或负载均衡器的证书,其SAN里可能包含了后端真实服务器的原始域名。
为了更直观地理解证书中各部分信息的作用,可以参考下表:
| CN (Common Name) | 证书的主要主机名 | 直接定位主要服务域名 | CN = www.github.com |
| SAN (Subject Alternative Name) | 证书支持的其他主机名列表 | 发现主域名关联的子域名、内部域名、测试域名 | DNS:api.github.com, DNS:*.github.io |
| O (Organization) | 组织名称 | 按组织归属聚合资产 | O = GitHub, Inc. |
| OU (Organizational Unit) | 组织部门 | 细化资产所属部门 | OU = IT Operations |
| Issuer | 证书颁发机构 | 通过CA关联同一批签发的证书 | C = US, O = Let's Encrypt, CN = R3 |
| Serial Number | 证书唯一序列号 | 精确标识特定证书 | 04:7B:BB:… |
| SHA-256 Fingerprint | 证书哈希指纹 | 唯一、不可变标识,用于精确追踪 | a1:b2:c3:… |
| Validity Period | 证书有效期 | 识别过期或即将过期的脆弱资产 | Not Before: 2023-01-01, Not After: 2024-01-01 |
理解这些字段后,我们就可以像侦探一样,利用Censys提供的强大搜索语法,在海量证书数据中筛选出目标。
2. Censys证书搜索语法精要:从入门到精准定位
Censys提供了专门用于搜索证书的索引(certificates)。其搜索语法直观而强大,核心在于理解如何组合不同的字段过滤器。我们从一个最简单的例子开始。
假设你想查找所有由“Let's Encrypt”颁发给“GitHub”的证书。在Censys的搜索框中,你可以这样构造查询:
parsed.issuer.organization: "Let's Encrypt" AND parsed.subject.organization: "GitHub"
这条查询会返回所有匹配的证书结果。但通常,我们更关心的是这些证书背后正在使用的服务。这时,就需要将证书搜索与主机搜索关联起来。Censys的妙处在于,证书的指纹(sha256或sha1)可以直接关联到services.tls.certificates.leaf_data字段。
一个更实用的组合查询是,先找到特定证书,再定位使用该证书的所有主机:
找到目标证书并获取其指纹。例如,搜索百度旗下的证书:
parsed.names: "baidu.com" AND tags: "trusted"
在结果中,点击一张证书,在详情页找到其SHA-256指纹,形如:a1b2c3d4…。
使用证书指纹搜索关联主机。切换到“主机”索引,输入:
services.tls.certificates.leaf_data.sha256: "a1b2c3d4…"
或者,更直接地,Censys支持在主机索引中直接使用证书字段进行搜索,这通常更高效:
services.tls.certificates.leaf_data.parsed.names: "baidu.com"
几个在实战中高频使用的证书搜索语法“组合拳”:
-
发现一证多用的资产群:大型企业常为多个服务使用同一张泛域名证书或包含大量SAN的证书。
services.tls.certificates.leaf_data.parsed.names: "*.company.com" AND services.tls.certificates.leaf_data.parsed.names_count: >5
这条语句查找使用了包含*.company.com且SAN数量大于5的证书的所有主机,能快速发现使用同一基础设施的批量服务。
-
追踪特定组织过期的脆弱证书:过期证书是严重的安全隐患。
services.tls.certificates.leaf_data.parsed.validity.not_after: <2024-01-01 AND services.tls.certificates.leaf_data.parsed.subject.organization: "Example Corp"
这能帮你快速梳理出“Example Corp”名下所有已过期证书对应的服务,便于推动整改。
-
通过内部域名发现暴露的测试/开发环境:许多内部域名(如internal、dev、staging)会意外出现在公网证书的SAN中。
services.tls.certificates.leaf_data.parsed.names: /.*\\.internal\\.|.*\\.dev\\.|.*\\.staging\\./ AND services.port: 443
使用正则表达式匹配,能有效抓取这类容易遗漏的非生产环境资产。
掌握这些语法后,你已经具备了在证书维度进行资产测绘的基本能力。但真正的价值在于将这种能力应用到具体、复杂的场景中。
3. 实战案例拆解:从一张证书挖出一个资产集群
理论说得再多,不如一个真实案例来得直观。去年在一次内部红队演练中,我们接到了对一家大型科技公司(代号“A公司”)进行外部资产发现的任务。除了已知的官网,我们对其网络边界知之甚少。
第一步:起点——已知主域
我们从其公开的官网 www.a-company.com 入手。在Censys中搜索该域名相关的证书:
services.tls.certificates.leaf_data.parsed.names: "a-company.com"
结果返回了数十张证书。我们注意到其中一张由“GlobalSign”签发的证书特别显眼,它的SAN字段异常丰富,包含了超过20个不同的子域名。
第二步:深挖——分析高价值证书
我们点开这张证书,将其SHA-256指纹复制下来。然后,在主机索引中搜索使用该指纹的所有服务:
services.tls.certificates.leaf_data.sha256: "证书指纹"
查询结果令人惊讶:有超过50个独立的IP地址在使用这张完全相同的证书。这些IP分布在全球不同的云服务商和数据中心。
第三步:关联分析——勾勒资产图谱
我们进一步分析这些主机:
第四步:发现“意外”——暴露的内部系统
在梳理SAN列表时,我们发现了几个非标准的域名:
- vpn.internal.a-company.com
- jenkins.build.a-company.com
- confluence.corp.a-company.com
这些明显是内部系统使用的域名。通过查询DNS记录,我们发现vpn.internal.a-company.com并未设置公网解析。然而,Censys显示有一个位于公有云上的IP(非公司宣称的VPN网关IP)在使用包含该域名的证书提供443端口服务。这极有可能是一个配置错误的测试或备份VPN节点,意外暴露在了公网。
我们将这个IP、对应的证书信息以及关联的其他资产整理成一份报告。后续的验证证实,这确实是一个被遗忘的测试环境VPN服务器,其上运行的软件版本存在已知高危漏洞。这个案例清晰地展示了,通过一张证书,我们不仅完成了资产普查,还精准定位到了一个高危暴露点。
4. 进阶技巧:绕过干扰,定位真实源头
在实际使用中,你会遇到很多干扰项,最常见的就是CDN和云WAF。它们会用自己的证书终止TLS连接,从而隐藏后端真实服务器的证书信息。这时,我们需要一些技巧来穿透这层“迷雾”。
技巧一:利用非标准端口和旧证书
CDN通常只覆盖标准的443端口。许多管理服务、API服务或遗留系统会运行在8443、9443等非标准HTTPS端口上,并且可能使用自签名或旧的商业证书,这些服务可能直接暴露了真实服务器。
services.tls.certificates.leaf_data.parsed.names: "target.com" AND services.port: !443 AND services.port: >8000 AND services.port: <10000
这条查询搜索target.com域名在8000-10000端口上(非443)的TLS服务,常能发现直连的服务器。
技巧二:关注证书有效期和序列号模式
大型企业为不同业务线签发的证书,其有效期和序列号可能呈现一定的规律或批次。通过分析这些模式,可以推断出未直接关联的证书是否属于同一组织。
services.tls.certificates.leaf_data.parsed.validity.not_after: 2024-12-31 AND services.tls.certificates.leaf_data.parsed.issuer.organization: "DigiCert" AND services.tls.certificates.leaf_data.parsed.serial_number: /^123456/
这个查询结合了过期时间、颁发机构和序列号前缀,用于定位一批可能同时签发、用于特定项目的证书。
技巧三:结合其他网络元数据
Censys的强大之处在于能交叉关联多种数据。不要孤立地看证书。
- 结合HTTP响应头: 搜索使用特定证书且HTTP Server头为Apache/2.4.6 (CentOS)的主机,可以进一步缩小范围。services.tls.certificates.leaf_data.parsed.names: "target.com" AND services.http.response.headers.server: "Apache/2.4.6 (CentOS)"
- 结合自治系统号(ASN): 如果你知道目标公司使用的云服务商或ISP的ASN,可以大幅过滤无关结果。autonomous_system.asn: AS16509 AND services.tls.certificates.leaf_data.parsed.subject.organization: "Target Company"
(AS16509是Google的AS号)
技巧四:自动化与持续监控
对于需要持续监控的资产,手动查询效率太低。你可以利用Censys的API(付费功能)或编写脚本定期执行关键查询。例如,一个简单的Python脚本可以定期检查是否有新的、包含你公司域名的证书出现在CT日志中,并及时告警。
import requests
import json
from datetime import datetime
# 示例:使用Censys API查询新证书(需替换为你的API ID和密钥)
API_URL = "https://search.censys.io/api/v2/hosts/search"
API_ID = "your-api-id"
API_SECRET = "your-api-secret"
QUERY = 'services.tls.certificates.leaf_data.parsed.names: "yourdomain.com" AND services.start_time: "last 24h"'
auth = (API_ID, API_SECRET)
response = requests.post(API_URL, json={"q": QUERY}, auth=auth)
if response.status_code == 200:
data = response.json()
new_hosts = data.get('result', {}).get('hits', [])
if new_hosts:
print(f"[{datetime.now()}] 发现 {len(new_hosts)} 个新主机使用目标域名证书:")
for host in new_hosts:
print(f" IP: {host.get('ip')}, 服务: {host.get('services', [{}])[0].get('service_name', 'N/A')}")
将这些技巧融入你的工作流,你就能从被动的数据查阅者,转变为主动的威胁猎手和资产管理员。
5. 构建你的自动化资产追踪工作流
将上述散落的技巧整合成一个系统化的、可重复的工作流,能极大提升效率。以下是我在多次项目中总结出的一套四步法:
第一步:初始种子收集
- 输入: 公司主域名、已知子公司域名、品牌/产品名称。
- 操作: 在Censys中,使用parsed.names和parsed.subject.organization进行宽泛搜索,收集第一批证书指纹和关联IP。
- 输出: 一个初始的证书指纹列表和IP地址列表。
第二步:关联扩展与去噪
- 输入: 上一步的证书指纹列表。
- 操作:
- 对每个指纹,搜索所有使用它的主机(services.tls.certificates.leaf_data.sha256)。
- 分析这些主机的其他服务(如services.service_name)、端口、横幅信息。
- 从这些主机的HTTP响应、TLS证书中提取新的域名、组织名,作为新的种子。
- 利用ASN、云提供商标签(tags: "aws")过滤掉明显无关的IP(如CDN节点)。
- 输出: 一个更丰富的、去噪后的资产列表(IP:端口:服务:证书指纹)。
第三步:风险评估与分类
- 输入: 资产列表。
- 操作:
- 暴露面分析: 识别直接面向公网的服务(如Web、VPN、RDP、数据库)。
- 脆弱性标识: 标记使用过期证书、自签名证书、低强度加密套件(通过services.tls详情判断)的服务。
- 关键性标记: 根据域名(如包含admin、api、vpn)、服务类型(如exchange、citrix)标记高价值资产。
- 生成报告: 按风险等级、业务部门、地理位置对资产进行分类汇总。
- 输出: 带有风险标签和分类的资产清单,以及需优先处理的高危资产列表。
第四步:持续监控与告警
- 输入: 关键证书指纹、核心域名、高价值IP段。
- 操作:
- 使用Censys API或计划任务,定期(如每天)执行监控查询。
- 监控是否有新的证书包含了你的核心域名(可能意味着新的子域名或服务上线)。
- 监控是否有新的主机开始使用你已知的关键证书指纹(可能意味着服务器扩容或迁移)。
- 监控是否有资产证书即将过期或已过期。
- 设置告警,当发现高风险变化(如在非公司ASN上出现包含内部域名的新证书)时立即通知。
- 输出: 持续的资产变化日志和实时告警。
这套工作流将一次性的资产发现,变成了一个持续的、闭环的安全管理过程。它不仅能用于外部攻击面管理,同样适用于内部红队评估和蓝队资产自查。
最后,我想强调的是,任何强大的工具都是一把双刃剑。本文所探讨的技术,旨在帮助安全从业者和运维人员更好地管理和保护自有资产。请务必在合法授权的前提下进行所有探测活动,并严格遵守相关的法律法规和职业道德。通过SSL证书进行资产测绘,其精髓在于利用公开信息进行逻辑关联和推理,这是一种更智能、更隐蔽的“看见”的方式。当你熟练运用后,你会发现互联网的“表面”之下,资产的脉络比你想象的更加清晰。
网硕互联帮助中心



评论前必须登录!
注册