find-exposed-servers

查找暴露的服务

面向整个互联网的扫描器已经扫描过你的目标。查询它们的扫描结果是被动的——你不会向目标发送任何数据包，因此不会在目标日志中留下痕迹，也无法将操作归因于你。代价是，每条结果都只是对过去某个时刻的描述；新手常犯的错误，就是把横幅信息当成在线主机的当前状态。

先选哪个平台

你掌握的信息	可用平台	原因
一个 IP	Shodan 主机查询，或免费的 InternetDB 端点	一次请求即可获得端口、主机名和 CPE
一个网段或 ASN	使用 Shodan 的 net:/asn: 并按端口分面	在查看单个主机之前，先了解整个资产的分布情况
一个位于 CDN 后方的主机名	Censys 证书到主机的关联查询	Censys 会将证书与观测到的主机关联，从而找到源站
一个证书或有辨识度的页面	Favicon 哈希以及证书主题/序列号搜索	找出 DNS 从未关联起来的同源基础设施
一个组织名称	Shodan 的 org:，Censys 的 autonomous_system	两者都依据网络注册信息进行归属判断，因此都会受其错误影响
不确定覆盖范围	使用传感器不同的另一个平台	各平台经常出现分歧；分歧本身就是信号

Shodan 对设备和协议的覆盖范围最广，查询语言也最友好。Censys 的主机记录结构化程度更高，证书关联能力更强，但查询语法也更严格。FOFA、ZoomEye、Netlas、Onyphe、BinaryEdge 和 LeakIX 覆盖了互联网的不同部分；如果前两个平台没有结果，不妨再查一遍。非西方扫描器尤其值得一试，因为它们会收录两大平台遗漏的主机。

Shodan

shodan init <api-key>
shodan host 203.0.113.10                                 # everything known about one IP
shodan search --fields ip_str,port,org,hostnames 'ssl.cert.subject.CN:example.com'
shodan count 'net:203.0.113.0/24'                        # cheap: no result credits
shodan stats --facets port,org 'net:203.0.113.0/24'      # the shape of a netblock
shodan download results.json.gz 'asn:AS64500 port:3389'
shodan parse --fields ip_str,port,product results.json.gz

无需身份验证，免费查询单个 IP：

curl -s https://internetdb.shodan.io/203.0.113.10 | jq .   # ports, hostnames, cpes, vulns

值得了解的过滤器：net:、port:、hostname:、asn:、org:、isp:、country:、city:、product:、version:、os:、http.title:、http.html:、http.status:、http.favicon.hash:、ssl.cert.subject.CN:、ssl.cert.issuer.CN:、ssl.cert.expired:、ssl.jarm:、ssl:、tag:、vuln:、has_screenshot:，以及用于指定扫描日期的 before:/after:。vuln: 和其他一些过滤器需要付费套餐。

Censys 使用结构化字段路径语法查询主机文档，例如 services.port、services.service_name、services.http.response.html_title、services.tls.certificates.leaf_data.subject_dn、dns.names、autonomous_system.asn、location.country，并通过 and/or/not 组合条件。其 API v2 提供 https://search.censys.io/api/v2/hosts/search?q=… 和 https://search.censys.io/api/v2/hosts/{ip}，使用 API ID/密钥进行基本身份验证。

各平台之间的对应查询示例见 reference/query-cookbook.md。

解读返回结果

结果是横幅信息加元数据，而非结论。关于具体服务横幅的解读——版本字符串意味着什么、哪些字段是自行报告的、哪些是实际观测到的——请参阅 reference/banner-interpretation.md。一般应遵循以下原则：

• 检查每条记录的扫描时间戳。 Shodan 记录带有时间戳；Censys 记录带有最后观测时间。不同端口和地址空间的重新扫描频率各不相同，因此记录可能已过时数天甚至数月。报告发现时应写成“于 观测到”，而不是“当前是”。
• 区分观测结果和声明信息。 开放端口和 TLS 证书是观测到的事实。产品名称和版本是从主机选择发送的横幅信息中解析出来的；主机可能会撒谎——有意为之，或者因为某个发行版回移植了补丁，却没有更改版本字符串。
• CVE 标签是推断结果。 它们通过将版本字符串与漏洞数据库匹配得出。它们可以作为报告线索，但不能确认漏洞是否可利用；回移植的修复也经常会导致判断出现偏差，两个方向都有可能。
• 记录中的主机名来自反向 DNS 和证书，这意味着它们可能属于该 IP 以前的租户。

关键关联点

这些特征让扫描平台不止是端口列表。

网站图标哈希。 Shodan 会为网站图标建立索引，使用其哈希值（对经过 base64 编码的图标字节计算 MurmurHash3；FOFA 的 icon_hash 使用相同的构造方式）。由于网站图标通常随应用一起发布，而不是按主机配置，搜索哈希值就能找到运行相同设备、框架或目标自有品牌门户的所有主机，涵盖互不相关的 IP、ASN 和域名。这是查找某个组织分散部署的同一产品实例的最佳方式。

TLS 证书。 搜索证书的主题 CN、主题组织名称或序列号，即可找到所有提供该证书的主机。证书序列号在同一颁发者下唯一，因此匹配序列号几乎可以精确识别身份。Shodan 还提供证书指纹过滤器；请查看其文档，确认需要的哈希类型，不要靠猜测。结合 find-hidden-subdomains 使用——CT 可提供证书，扫描数据则能找到提供该证书的所有主机。

JARM 和 TLS 栈指纹。 JARM 对服务器响应一组 TLS 握手的方式进行哈希，因此识别的是 TLS 栈，而非证书。它可以聚类设备、负载均衡器和命令与控制框架。它并非组织专属，因此应将其视为缩小搜索范围的过滤条件，而非身份标识。

响应正文指纹。 从目标页面提取独特字符串——例如跟踪 ID、罕见的版权声明、自定义标头或构建哈希——再通过 http.html: 搜索，就能找到提供相同应用的其他主机，包括预发布副本和 CDN 后方的源站。

查找 CDN 后方的源站

当某个主机名解析到 Cloudflare 或其他代理时，源站仍然存在，而且通常可以通过 IP 访问。按可靠性从高到低排列，可通过被动方式查找源站的途径如下：

1. 在扫描数据中搜索位于 CDN ASN 之外的 IP 上的目标 TLS 证书。源站通常会直接提供真实证书。
2. 搜索独特的 HTTP 正文字符串或网站图标哈希，并过滤掉 CDN ASN。
3. 查看采用 CDN 之前的历史 DNS 记录（who-owns-this-domain）。源站变动的频率往往没有人们想象的那么高。
4. 检查按设计绕过代理的服务：MX 主机、ftp、cpanel、direct、origin，以及同一网段上的非 HTTP 端口。
5. 查看 SPF 的 ip4: 机制——组织会授权自己的发信主机，该主机有时就是 Web 源站。

候选源站只是一种假设。通过发送带有目标 Host 标头的请求来确认它，属于针对目标的主动操作，需要获得授权。另请注意，配置妥当的源站会拒绝来自 CDN 以外的流量，因此无法确认并不能否定该候选源站。

容易出错的地方

• 过时信息会产生双向影响。 扫描时关闭的端口可能当时是开放的；开放的端口也可能后来已关闭。没有结果不代表没有服务——扫描器不会覆盖每个地址上的每个端口。
• 蜜罐会污染所有结果。 故意暴露的诱饵会夸大有趣服务的结果。识别迹象包括：同一主机上的服务组合不合常理、开放端口数量异常庞大、许多互不相关的产品都显示默认横幅，以及托管在面向研究的网段中。Shodan 会在 https://api.shodan.io/labs/honeyscore/{ip}?key= 提供蜜罐评分估算——把它当作提示，而不是定论。
• 目标可以欺骗扫描器。 扫描器的源地址可以公开，因此防御方可以专门向这些地址提供伪造的横幅。高价值目标有时会这么做。
• org: 和 isp: 表示网络注册信息，而非所有权。 在云网段中，它们指的是云服务提供商；在转售的地址空间中，它们指的是转售商。仅凭 org: 归属，正是人们最终把邻居暴露的数据库报告成目标资产的原因。
• 共享托管和共享 IP。 一个 IP 可以托管数百个互不相关的网站。在此发现的端口和漏洞属于主机，不一定属于你的目标。
• 截图和横幅中可能包含个人数据。 被暴露的控制面板和摄像头会收录真实人物的信息。你一旦保存这些内容，就会涉及数据保护问题。
• 各平台的结果并不一致，而且每个平台的免费版都会截断结果。 在单个平台上搜索一无所获，只能说明一个传感器网络没有发现结果。

置信度分级

• 确认暴露——同一服务在同一 IP 和端口上出现在两个独立扫描平台，或在一个平台的多个扫描日期中出现；并且有证据表明，该 IP 通过目标确实控制的证书或重新分配给目标名称的网段与目标相关联。
• 很可能——在与目标相关联的 IP 上，单次近期观察通过 favicon 哈希、正文字符串匹配或反向 DNS 建立关联。或者，跨平台匹配出现在你尚未独立确认所有权的 IP 上。
• 未确认——归属仅依据 org:/isp:、共享托管 IP、单条过时记录、没有其他证据佐证的 CVE 标签，或具有蜜罐特征的主机。

切勿通过连接到服务来提高置信度等级。对每项发现，都要记录平台、查询、扫描时间戳和记录标识符。

示例

目标：example-fintech.test，经授权的外部攻击面审查，仅进行被动收集。

根域名解析到 Cloudflare，因此扫描解析出的 IP 只会描述 Cloudflare。改为从 find-hidden-subdomains 获取证书主题 CN，并在扫描数据中搜索提供该证书的主机。找到三条结果：两个 Cloudflare 地址，以及一个欧洲托管服务提供商 ASN 中开放了 443 和 22 端口的主机。第三台主机很可能是源站。

反向搜索其 favicon 哈希，又找到六台主机。其中四台是目标的区域门户。另两台属于无关公司——这个 favicon 是框架自带的通用图标，并非目标专用。这就是调查的死胡同，也说明了一个教训：将哈希匹配视为归属证据之前，先确认 favicon 是否确实具有独特性。

对源站的 /29 使用 net: 查询，发现第二台主机开放了 3306 端口，并显示 MySQL 横幅，扫描时间是四个月前。记录已过时，因此该服务可能已经消失，但仍可作为观测结果报告。网段的 RIR 记录显示，它已重新分配给目标的法定名称；正是这一点，才把“证书正确的某个 IP”变成了归属证据。

到此为止。不要连接到 3306 端口，也不要向源站发送 Host 标头。报告两项发现，并附上日期和查询，然后将重新分配的网段交给 who-owns-this-domain。

枢纽

新选择器	前往
已发现主机上的证书主题和 SAN	find-hidden-subdomains
网段、ASN、反向 DNS 主机名	who-owns-this-domain
来自证书主题和 RIR 记录的组织名称	x-ray-a-company、who-really-owns-it
暴露的代码仓库、CI 或注册表服务	secrets-in-git-history
已发现主机上的历史内容	read-deleted-pages
已发现服务上的索引路径	google-like-a-spy
要绘制的主机／证书／ASN 集群	graph-the-network

法律与服务条款说明

查询扫描平台属于合法的被动研究。界限在于如何处理查询结果：连接到暴露的数据库、打开管理面板、查看暴露的摄像头画面，或从开放共享中获取文件，在大多数司法管辖区都可能构成计算机滥用法所禁止的未授权访问；没有密码并不能作为辩护理由。发现问题后，你有权做的只有报告——向网段的 RIR 记录中列出的滥用联系点或相关 CERT 报告，除此之外别无其他。扫描平台的条款也限制其数据的再分发，因此应在报告中引用发现结果，而不是重新发布数据集。包含个人数据的屏幕截图和横幅受 ../../ETHICS.md 中的数据最小化规则约束。