5分钟上手Subfinder：API密钥配置与自动化子域名发现实战

原创于 2026-06-16 09:09:02 发布 · 370 阅读

7 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#Subfinder #子域名发现 #API密钥配置

1. 项目概述：为什么我们需要批量抓取子域名？

在安全评估、渗透测试甚至是日常的IT资产管理中，摸清一个企业的网络资产边界是第一步，也是最关键的一步。而子域名，就是这张资产地图上最容易被忽视，却又往往藏着“宝藏”的角落。一个主域名背后，可能隐藏着几十上百个子域名，它们可能是开发测试环境、后台管理系统、API接口服务，甚至是由于历史遗留问题而暴露在公网上的内部系统。这些地方，常常因为疏于维护而成为安全短板。

手动去发现这些子域名，无异于大海捞针，效率极低。这时候，自动化工具就成了我们的“雷达”。 subfinder 正是这样一款在安全圈内备受推崇的子域名发现工具。它本身是一个强大的引擎，但它的真正威力，在于能够聚合数十个公开的、在线的数据源进行查询。这就像你同时派出了几十个侦察兵，去不同的情报站（如搜索引擎、证书透明度日志、DNS数据集等）搜集信息，然后将结果汇总给你，效率和覆盖面是手动无法比拟的。

今天要聊的，就是如何快速上手 subfinder ，在5分钟内搭建起你的自动化资产发现流水线。更重要的是，我会重点分享如何配置那些关键的API密钥。很多新手卡在这一步，觉得麻烦就放弃了，但其实这是解锁 subfinder 全部潜力的钥匙。配置得当，你的侦察兵就能拿到更高级别的通行证，获取到更全面、更精准的情报。下面，我们就从最核心的配置开始，一步步拆解。

2. 核心配置解析：API密钥——解锁高级情报的通行证

subfinder 的强大，源于它支持众多的数据源（我们称之为“解析器”或“源”）。这些数据源大致可以分为几类：基于证书透明度的（如Censys, CertSpotter）、基于DNS数据集和被动DNS的（如SecurityTrails, PassiveTotal）、基于搜索引擎的（如Google, Bing，但需谨慎使用）、以及一些社区或商业威胁情报平台。其中，绝大部分高质量、高频率的数据源都需要API密钥才能访问。

2.1 为什么必须配置API密钥？

你可以不配置任何API密钥直接运行 subfinder ，它依然能通过一些无需认证的公共源（如Virustotal的公共API、HackerTarget等）返回结果。但这样做的局限性非常大：

速率限制严格 ：公共API通常有非常严格的请求频率限制（Rate Limit），比如每分钟几次。扫描一个域名可能还没问题，但一旦你想批量扫描几十上百个目标，速度会慢如蜗牛，并且极易被临时封禁。
结果数量受限 ：免费层或公共接口返回的子域名数量通常有上限，可能只显示最“流行”或最近的一部分，很多深层次的、历史遗留的子域名无法被获取。
数据源严重不全 ： subfinder 内置的几十个数据源中，超过三分之二都需要密钥。不配置密钥，就等于你放弃了大部分侦察兵，只用了一小部分民兵，情报的广度和深度大打折扣。

因此，配置API密钥不是“可选的高级技巧”，而是“发挥工具效能的必由之路”。它直接决定了你的资产发现工作的效率和质量上限。

2.2 关键API密钥申请与配置指南

这里我挑选几个免费、易申请且效果显著的数据源，手把手教你配置。我们的目标是：用最小的成本，获得最大的收益。

1. SecurityTrails 这个源对于发现历史DNS记录、关联子域名特别有效。

申请：访问 SecurityTrails 官网，注册一个免费账户。免费账户有每月50次API调用的额度，对于个人学习和中小规模扫描完全足够。
获取密钥 ：登录后，在控制面板中找到「API」部分，你会看到你的「API Key」。
配置：这个密钥将用于 subfinder 的配置文件中。

2. PassiveTotal (RiskIQ) RiskIQ的PassiveTotal提供丰富的被动DNS和SSL证书数据，是另一个宝藏数据源。

申请：访问 PassiveTotal 网站注册。它同样提供社区免费版，API调用次数比SecurityTrails更宽松一些。
获取密钥 ：在账户设置的「API Access」页面，你会看到「Username」和「API Key」。
配置：注意，这里需要同时填写用户名和密钥。

3. Censys 证书透明度（CT）日志是发现子域名最有效的途径之一，Censys是这方面的佼佼者。

申请：访问 Censys 官网注册。免费账户有每月250次查询的额度。
获取密钥 ：在「My Account」->「API」页面，你可以创建一组新的API凭证，得到「API ID」和「Secret」。
配置：这两个值都需要。

4. GitHub Token（非必须但推荐） subfinder 本身和一些数据源插件可能需要从GitHub拉取更新。如果你在代理环境或网络不佳的情况下使用，配置一个GitHub Token可以避免速率限制问题。

申请：在GitHub的「Settings」->「Developer settings」->「Personal access tokens」中，生成一个Token，只需勾选 public_repo 权限即可。
配置：这个Token可以设置到环境变量中。

注意：申请这些服务的免费账户时，请使用真实、专业的邮箱（如公司邮箱或个人常用邮箱），避免使用临时邮箱，有些服务会进行验证。同时，妥善保管你的API密钥，不要泄露到公开的代码仓库中。

2.3 配置文件编写实战

subfinder 的配置默认位于 ~/.config/subfinder/provider-config.yaml （Linux/macOS）或 C:\Users\<用户名>\.config\subfinder\provider-config.yaml （Windows）。如果文件不存在，运行一次 subfinder 会自动生成模板。

下面是一个配置了上述关键源的示例 provider-config.yaml 文件内容：

censys:
  - censys_api_id: your_censys_api_id_here
    censys_api_secret: your_censys_api_secret_here

certspotter:
  - []

github:
  - token: your_github_personal_access_token_here

passivetotal:
  - username: your_riskiq_username_here
    api_key: your_riskiq_api_key_here

securitytrails:
  - apikey: your_securitytrails_api_key_here

shodan:
  - apikey: your_shodan_api_key_here # Shodan也很有用，但免费额度较少，可选择性配置

urlscan:
  - apikey: your_urlscan_api_key_here # URLScan.io 免费且好用，推荐配置

virustotal:
  - apikey: your_virustotal_api_key_here # VirusTotal 公共API有限制，有密钥更好

配置步骤：

用文本编辑器（如VS Code, Notepad++）打开或创建上述路径的配置文件。
将上面示例中的 your_xxx_api_key_here 全部替换成你实际申请到的密钥。
保存文件。

验证配置是否生效： 运行一个简单的命令，并观察输出中启用的源（ [INF] 开头的行）：

subfinder -d example.com -silent

如果配置正确，你应该能看到类似 [INF] Enumerating subdomains for example.com 的信息，并且下面会列出很多使用的源，如 [censys] , [securitytrails] 等。如果某个源因为密钥错误未被启用，通常会有警告信息。

3. 基础与进阶使用：从单点侦察到批量作战

配置好API密钥，你的 subfinder 就装备上了精良的武器。接下来，我们看看如何运用它。

3.1 基础单域名扫描

这是最简单的使用场景，用于快速摸清一个目标。

subfinder -d taobao.com -o taobao_subs.txt

-d : 指定目标域名。
-o : 将结果输出到文件。
执行后，所有发现的子域名会保存到 taobao_subs.txt 中。

但这样跑，用的是所有可用源，速度可能不是最优。我们可以更精细地控制。

3.2 常用参数详解与组合技

-silent : 只输出结果，不显示进度、信息、错误等任何冗余信息。这在将结果管道（pipe）传递给其他工具（如 httpx , nuclei ）时非常有用。
```
subfinder -d example.com -silent
```
-all : 使用所有配置的源进行查找，包括那些通常因为速度慢或不稳定而被默认排除的源。追求最大覆盖率时使用，但耗时会更长。
```
subfinder -d example.com -all
```
-recursive : 递归枚举。当发现像 dev.example.com 这样的子域名后，会继续尝试发现 api.dev.example.com 等更深层次的子域名。这能极大地扩展发现范围，但也会显著增加时间和请求数量，需谨慎使用。
```
subfinder -d example.com -recursive
```
-t : 设置并发线程数。默认值通常够用，但在网络好、API限额充足的情况下，适当提高（如 -t 50 ）可以加快速度。但注意不要过高，以免触发源的速率限制。
```
subfinder -d example.com -t 30
```
-timeout : 设置每个源的超时时间（秒）。对于某些响应慢的源，可以适当调高（如 -timeout 30 ）。
-max-time : 设置整个扫描任务的最大执行时间（秒）。防止因个别源卡住而导致任务无限制挂起。

一个高效的组合命令示例：

subfinder -d example.com -all -t 20 -timeout 15 -silent -o subs.txt

这个命令的意思是：对 example.com 使用所有源，以20个线程并发，每个源等待15秒，只静默输出结果，并保存到文件。

3.3 批量扫描与结果处理实战

真正的企业资产发现，目标是成百上千个域名。 subfinder 完美支持这一点。

方法一：使用域名列表文件 ( -dL ) 这是最常用的方式。假设你有一个 domains.txt 文件，里面每行一个域名。

subfinder -dL domains.txt -o all_subs.txt

subfinder 会依次扫描列表中的每个域名，并将所有结果汇总到 all_subs.txt 。这里有个问题：结果混在一起，难以区分哪个子域名属于哪个主域。为了解决这个问题，可以使用 -oJ 或 -oJL 输出JSON格式。

方法二：输出JSON格式，便于处理

subfinder -dL domains.txt -oJ all_subs.json

-oJ 输出的JSON是一个包含所有结果的数组，每个结果是一个对象，其中 host 字段是子域名， source 字段是发现它的源。但更推荐使用 -oJL （JSON Lines），它每行一个独立的JSON对象，非常适合用 jq 等工具进行流式处理。

subfinder -dL domains.txt -oJL all_subs.jsonl

然后，你可以用 jq 轻松地按主域名进行筛选：

# 提取所有属于 example.com 的子域名
jq -r 'select(.host | endswith(".example.com")) | .host' all_subs.jsonl | sort -u

方法三：集成到自动化流水线中 这才是 subfinder 的终极用法。一个典型的资产发现与初步探测流水线如下：

# 1. 批量发现子域名
subfinder -dL domains.txt -silent > all_subs_raw.txt
# 2. 去重
sort -u all_subs_raw.txt -o all_subs_unique.txt
# 3. 解析出HTTP/S服务（使用httpx工具）
httpx -l all_subs_unique.txt -silent -title -status-code -tech-detect -o live_hosts.txt
# 4. 对存活主机进行漏洞扫描（使用nuclei工具）
nuclei -l live_hosts.txt -severity low,medium,high,critical -o nuclei_results.txt

这条命令链实现了从域名列表到漏洞初步筛查的全自动化。 -silent 参数在这里至关重要，它确保了 subfinder 的输出是纯净的子域名列表，可以直接被 httpx 读取。

4. 性能调优与错误排查

在实际操作中，尤其是批量扫描时，你会遇到各种问题。掌握调优和排查技巧，能让你的扫描任务稳定、高效。

4.1 性能调优策略

线程控制 ( -t ) : 不是越多越好。起始值可以设为 20-30 。观察任务执行时的网络和CPU占用。如果发现大量超时或错误，可能是触发了速率限制，应降低线程数。如果资源闲置，可以适当增加。
超时设置 ( -timeout , -max-time ) : 对于国外源，网络延迟较高，建议将 -timeout 设为 20-30 秒。 -max-time 可以设置为一个合理的值（如 300 秒，即5分钟），防止单个域名扫描卡死整个队列。
选择性使用源 ( -provider ) : 如果你知道某些源对当前目标效果不好（比如某些源对国内域名收录差），或者某些源速度特别慢，可以在配置文件中临时禁用它们，或者使用 -provider 参数指定只使用某几个高效的源。你可以先测试不同源的产出比。
```
# 只使用 securitytrails 和 censys 这两个高效源
subfinder -d example.com -provider securitytrails,censys
```
结果缓存 : subfinder 默认会缓存结果。对于频繁扫描的固定目标，这能节省大量时间。缓存位置通常在 ~/.cache/subfinder 。如果遇到结果陈旧的问题，可以清空缓存目录。

4.2 常见错误与解决方案实录

问题1：运行后没有任何输出，或者输出极少。

排查：首先，检查你的网络连接，特别是能否正常访问国外那些数据源网站（如 securitytrails.com）。其次，运行 subfinder -d example.com -v （verbose模式），查看详细的运行日志。关注是否有大片的 [ERR] 错误信息。
可能原因与解决 ：
- API密钥失效或未配置 ：这是最常见的原因。仔细检查 provider-config.yaml 文件，确保格式正确（YAML对缩进敏感），密钥准确无误。可以通过临时只配置一个源（如SecurityTrails）来测试。
- 速率限制 ：免费API有调用限制。如果短时间内扫描了大量目标，可能会被临时限制。解决方案是降低线程数 -t ，或在批量扫描的脚本中增加延迟（ sleep ）。
- 源失效 ：互联网上的公开数据源有时会关闭或更改接口。 subfinder 项目更新频繁，建议定期使用 subfinder -up 命令更新工具和源的定义。

问题2：扫描速度非常慢。

排查：观察 -v 模式下的输出，看卡在哪个具体的源上。
解决：
- 使用 -provider 排除已知慢速的源。
- 减少线程数 -t ，有时并发过高导致网络拥堵或触发惩罚。
- 适当增加 -timeout ，给慢速源更多响应时间，避免因单个超时而重试。

问题3：输出结果中包含大量无效或垃圾域名（如泛解析记录 *.example.com ）。

说明：这不是错误，是某些数据源（特别是被动DNS）的特性。它们会记录下所有出现过的解析记录。

解决：这是后处理的工作。在将结果传递给


   httpx

进行存活探测时，


   httpx

会自动尝试解析和连接，无效的域名自然会超时或被过滤掉。你也可以在扫描后用一些简单的命令预处理：

# 过滤掉明显是泛解析的记录（假设你的主域是 example.com）
grep -v '^\*\.' all_subs.txt | grep '\.example\.com$' > filtered_subs.txt
# 或者使用更强大的工具如 dnsx 进行批量解析验证
cat all_subs.txt | dnsx -silent -resp-only -o valid_subs.txt

问题4：在Windows PowerShell中运行，配置文件路径不对。

解决： subfinder 在Windows上默认的配置路径是 C:\Users\<你的用户名>\.config\subfinder\provider-config.yaml 。确保文件夹和文件存在。你也可以使用 -config 参数指定配置文件的绝对路径。
```
subfinder -d example.com -config "C:\path\to\your\config.yaml"
```

实操心得 ：我建议建立一个自己的“扫描配置模板”。针对不同的场景（如快速侦察、深度普查、对特定区域目标），准备不同的命令行参数组合或配置文件片段。例如，一个“快速模板”可能只用 securitytrails, censys, passivetotal 这三个核心源，线程数设高一些；而一个“深度模板”则启用 -all 和 -recursive ，但设置较长的超时和较低的线程数。这样能极大提升日常工作的效率。

5. 企业级应用场景与扩展思路

掌握了单个工具的使用，我们把它放到更大的企业安全运营上下文里看，它能扮演什么角色？

5.1 核心应用场景

外部攻击面管理（EASM）的基石 ：定期（如每周、每月）对企业的所有主域名进行子域名发现，并与历史结果进行比对，可以快速发现：
- 影子资产 ：未经报备上线的新服务、新测试环境。
- 僵尸资产 ：已下线业务遗留的、忘记关闭解析的域名。
- 收购合并资产 ：在并购过程中，快速梳理被收购方的外部资产。将这些发现的资产纳入统一的CMDB（配置管理数据库）或资产平台，是收敛攻击面的第一步。
红队演练的侦察阶段 ：在授权渗透测试中，子域名枚举是信息收集阶段的重中之重。发现的子域名经过存活探测、端口扫描、目录爆破、指纹识别后，往往能找到薄弱点，例如：
- 开发环境（ dev. , test. , staging. ）暴露了未授权访问的管理后台。
- 遗忘的旧版应用（ old. , v1. ）存在已知漏洞。
- 第三方服务（ s3. , assets. ）配置错误导致数据泄露。
漏洞赏金猎人的“撒网”工具 ：对于跑众测（Bug Bounty）的研究员来说，目标是尽可能多的资产。用 subfinder 对目标项目范围（如 *.company.com ）进行递归枚举，是扩大测试范围、寻找“低垂果实”的标准操作流程。

5.2 构建自动化资产监控系统

单纯的一次性扫描价值有限。我们可以用简单的脚本，将其升级为持续监控系统。

思路：定期执行扫描 -> 与上次结果对比 -> 发送差异告警。

#!/bin/bash
# 示例脚本：简易子域名监控

TARGET_DOMAIN="yourcompany.com"
LAST_RESULT_FILE="last_scan_$TARGET_DOMAIN.txt"
CURRENT_RESULT_FILE="current_scan_$TARGET_DOMAIN.txt"
DIFF_FILE="diff_$TARGET_DOMAIN.txt"

# 1. 执行本次扫描
subfinder -d $TARGET_DOMAIN -silent | sort -u > $CURRENT_RESULT_FILE

# 2. 检查是否存在上一次的结果
if [ -f "$LAST_RESULT_FILE" ]; then
    # 3. 对比差异
    diff -u "$LAST_RESULT_FILE" "$CURRENT_RESULT_FILE" | grep -E "^\+[^+]" > $DIFF_FILE
    # 4. 如果有新增子域名，发送告警（这里用邮件示例）
    if [ -s "$DIFF_FILE" ]; then
        echo "发现新的子域名！" | mail -s "【资产监控】$TARGET_DOMAIN 有新增资产" -A $DIFF_FILE your-email@example.com
        echo "$(date): 发现新资产，已发送告警。"
    else
        echo "$(date): 扫描完成，未发现新资产。"
    fi
else
    echo "$(date): 首次扫描，建立基线。"
fi

# 5. 将本次结果存档，作为下一次的“上一次结果”
mv $CURRENT_RESULT_FILE $LAST_RESULT_FILE

将这个脚本加入 crontab ，每天或每周自动运行，你就拥有了一个初级的资产变化监控器。

5.3 与其他工具的协同生态

subfinder 在开源安全工具链中定位清晰，它专注于“发现”。它的输出是其他工具的完美输入：

httpx / katana : 用于探测存活和Web服务，获取标题、状态码、技术指纹。
nuclei **: 对存活主机进行快速、大规模的漏洞检测。
naabu / masscan **: 对发现的域名进行端口扫描。
waybackurls / gau **: 针对子域名，获取其历史URL，用于寻找参数、端点。
dnsx **: 对子域名列表进行批量DNS解析、记录查询（A, CNAME, MX等），验证有效性。

一个强大的组合命令示例，实现从发现到初步分析的闭环：

# 发现 -> 解析验证 -> 存活探测 -> 基础信息获取
subfinder -d example.com -silent | \
dnsx -silent -a -resp | \
httpx -silent -title -status-code -tech-detect -json | \
tee results.json | jq .

这条管道命令一气呵成：先发现子域名，然后进行DNS A记录解析并只保留有响应的，接着对能解析的域名进行HTTP/S探测并获取详细信息，最后以JSON格式输出并漂亮地打印在终端上。所有无效的、无法解析的、无法访问的域名都在流程中被自动过滤掉了，最终 results.json 里只剩下有价值的、存活的Web资产信息。

最后，再分享一个我自己的小技巧：对于非常重要的核心资产，我会配置两套 subfinder 的API密钥集。一套是“深度扫描”集，包含所有我能申请到的免费和商业源密钥，用于每周一次的低频深度普查。另一套是“快速扫描”集，只包含响应最快、最稳定的几个源（如SecurityTrails, Censys），用于日常的变更监控或快速侦察。这样既能保证深度，又能兼顾效率。工具是死的，人是活的，根据场景灵活组合运用，才是提升效率的关键。