Subfinder与Amass自动化资产测绘流水线搭建指南

1. 项目概述为什么我们需要自动化资产测绘流水线在渗透测试或者红队评估的初期最头疼也最基础的工作是什么没错就是资产发现。客户给了一个主域名或者一个IP段你总不能就盯着这一个点去测。真正的攻击面往往隐藏在那些被遗忘的子域名、关联的云服务、收购来的旧资产、甚至是开发人员随手搭建的测试环境里。手动去搜集这些信息效率低下不说还容易遗漏关键目标导致测试范围不完整评估结果自然也就打了折扣。我经历过太多次这样的场景项目时间紧前期信息搜集阶段却像个无头苍蝇各种工具轮番上阵结果导出一堆杂乱无章的文本文件去重、合并、验证又要花掉大半天。直到我把 Subfinder 和 Amass 这两款神器组合起来并搭建了一套自动化流水线整个前期侦察工作的效率和规范性才得到了质的飞跃。这套“组合拳”的核心思路就是利用 Subfinder 的快速、轻量和 Amass 的深度、全面形成互补再通过脚本将它们串联实现从目标输入到结构化资产列表输出的全自动化流程。简单来说这套流水线能帮你自动完成以下事情给定一个主域名或公司名称自动调用多个搜索引擎、证书透明度日志、DNS数据集等公开源穷尽性地发现其子域名对发现的域名进行解析获取IP地址对IP进行端口扫描和服务识别最终生成一份清晰、去重、可直接用于后续漏洞扫描或渗透测试的资产清单。整个过程无需人工干预你只需要喝杯咖啡等待结果报告即可。这对于需要频繁进行外部测试的安服团队、或是追求高效和可复现性的独立安全研究员来说价值巨大。2. 工具选型解析Subfinder与Amass的定位与互补为什么是 Subfinder 和 Amass而不是其他工具这源于它们各自鲜明的特点和完美的互补性。Subfinder更像是一个“闪电战”专家。它的设计哲学是快和专。专注于子域名枚举集成了数十个常用的公开数据源如 VirusTotal, Censys, SecurityTrails, PassiveTotal 等。它的优势在于速度极快并发请求设计优秀能在短时间内完成对大量数据源的查询。资源消耗低作为 Go 语言编写的单文件二进制程序它轻便不依赖复杂环境。结果干净默认输出就是去重后的子域名列表非常清爽。但是Subfinder 基本只做“发现”这一步。它告诉你存在api.target.com,dev.target.com但不会主动去解析这些域名对应的IP更不会进行后续的端口扫描。Amass则是一个“大兵团”作战的统帅。它不仅仅是一个子域名枚举工具更是一个完整的攻击面映射框架。除了包含比 Subfinder 更丰富的被动数据源甚至包括需要API密钥的商业源它的核心能力在于主动侦察可以进行 DNS 暴力破解、子域名爬取等主动信息收集能发现那些从未在公开记录中出现过的资产。关联图谱能够通过 WHOIS 信息、SSL 证书关联、搜索引擎抓取等方式发现与目标相关的其他域名和公司实体真正实现“顺藤摸瓜”。数据整合与可视化它内置数据库可以持续监控目标资产变化并生成交互式的网络图谱。然而Amass 的强大也带来了“重量”。一次完整的 Amass 扫描特别是开启主动模式耗时很长资源消耗CPU、内存、网络也大不适合作为第一轮快速筛查的工具。我的实操心得在实际流水线中我让 Subfinder 打头阵利用其速度优势快速从被动源拉取一份尽可能全的子域名清单。然后将这份清单作为 Amass 的输入让 Amass 专注于它擅长的事情解析IP、进行有限的主动验证、并利用其智能关联引擎去发现更多潜在资产。这样既保证了速度又兼顾了深度避免了直接用 Amass 全面扫描带来的时间成本问题。3. 自动化流水线核心架构设计一个健壮的自动化流水线不能只是把两个命令用管道符 (|) 连起来那么简单。我们需要考虑容错、去重、结果结构化以及任务调度。下面是我经过多次迭代后形成的核心架构。3.1 工作流分解整个流水线可以分解为以下几个顺序执行的模块输入与初始化接收目标如example.com或Example Corp创建本次扫描的任务目录用于存放所有中间文件和最终报告。Subfinder 被动枚举调用 Subfinder使用所有可用的被动数据源进行子域名发现。输出原始结果。初步处理与去重对 Subfinder 的结果进行初步清洗如去除泛解析域名*.example.com并与历史资产库进行比对去重。Amass 深度处理将清洗后的子域名列表交给 Amass。在此阶段Amass 主要执行DNS 解析获取每个子域名对应的 A/AAAA/CNAME 记录。IP 关联与聚合将域名解析到 IP并统计哪些域名共享同一 IP这有助于发现虚拟主机。有限主动枚举可配置是否对关键域名如api,dev,admin等进行短字典的暴力破解。资产丰富与验证可选但推荐此阶段可以集成其他工具例如httpx/httprobe验证域名是否存活HTTP/HTTPS服务并获取标题、状态码、技术栈如Nginx,WordPress等信息。naabu/masscan对发现的 IP 地址进行快速端口扫描识别开放的服务。结果生成与报告将所有数据域名、IP、开放端口、Web服务等整合生成结构化的报告如 JSON, CSV并同时输出一份便于人类阅读的 Markdown 或 HTML 摘要。3.2 目录结构设计清晰的目录结构是自动化脚本可维护的基础。我通常采用如下结构projects/ ├── target_company_20231027/ # 本次任务目录 │ ├── input.txt # 输入的目标列表 │ ├── subfinder_raw.txt # Subfinder 原始输出 │ ├── subfinder_clean.txt # 清洗后的子域名 │ ├── amass_results/ # Amass 数据库和原始数据 │ ├── alive_domains.txt # 存活的域名列表 │ ├── ips_unique.txt # 去重后的IP列表 │ ├── ports/ # 端口扫描结果 │ ├── final_report.json # 结构化最终报告 │ └── summary.md # 人类可读摘要 └── historical_assets.db # 历史资产数据库可选用于去重和监控变更3.3 关键技术点进程管理与资源控制当目标很多时并行处理是必须的。但直接无脑并发可能导致 API 限制或被封 IP。我的策略是对 Subfinder使用其内置的-t线程数控制。通常设置为 50-100 之间具体取决于网络环境和数据源稳定性。对 Amass它的并发控制更复杂。在命令行中可以用-max-dns-queries和-rate限制 DNS 查询速率。更好的方式是在配置文件中精细调整。流水线级控制使用 Shell 脚本的xargs -P或 Python 的concurrent.futures库来控制同时扫描的目标数量避免系统过载。注意事项很多被动数据源如 SecurityTrails, Censys都有免费的 API 调用频率限制。在脚本中务必为每个请求添加延迟sleep并妥善处理429 Too Many Requests等错误码实现简单的重试机制。将 API 密钥外置到配置文件或环境变量中不要硬编码在脚本里。4. 实操搭建从零构建你的自动化流水线下面我将以 Linux/macOS 环境为例展示如何一步步搭建这个流水线。假设我们的工具安装在~/tools/目录下。4.1 环境与工具准备首先安装核心工具# 安装 Go 语言环境Subfinder 和 Amass 都是 Go 编写的 # ... (Go 安装步骤略) # 安装 Subfinder go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinderlatest # 安装 Amass go install -v github.com/owasp-amass/amass/v3/...master # 安装辅助工具可选但推荐 # httpx - HTTP探测工具 go install -v github.com/projectdiscovery/httpx/cmd/httpxlatest # naabu - 快速端口扫描器 go install -v github.com/projectdiscovery/naabu/v2/cmd/naabulatest配置 API 密钥以解锁更多数据源。创建配置文件~/.config/subfinder/provider-config.yaml和~/.config/amass/config.ini将你从 VirusTotal, SecurityTrails, Shodan, GitHub 等平台申请的密钥填入。这是提升发现能力的关键一步。4.2 核心 Shell 脚本实现这是一个简化但功能完整的 Bash 脚本asset_pipeline.sh展示了核心逻辑#!/bin/bash # 配置变量 TARGET$1 # 从命令行参数接收目标如 example.com PROJECT_DIR$(date %Y%m%d)_${TARGET//./_} OUT_DIR./projects/$PROJECT_DIR mkdir -p $OUT_DIR echo $TARGET $OUT_DIR/input.txt # 定义工具路径假设已在PATH中否则需指定完整路径 SUBFINDERsubfinder AMASSamass HTTPXhttpx NAABUnaabu echo [*] 开始处理目标: $TARGET echo [*] 项目目录: $OUT_DIR # 阶段1: Subfinder 快速被动枚举 echo [1] 运行 Subfinder 进行被动枚举... $SUBFINDER -d $TARGET -all -silent -o $OUT_DIR/subfinder_raw.txt if [ ! -s $OUT_DIR/subfinder_raw.txt ]; then echo [-] Subfinder 未发现子域名流程终止。 exit 1 fi # 简单清洗去除空行和常见泛解析记录需根据实际情况调整 grep -v ^\*\.$TARGET$ $OUT_DIR/subfinder_raw.txt | sort -u $OUT_DIR/subfinder_clean.txt SUB_COUNT$(wc -l $OUT_DIR/subfinder_clean.txt) echo [] 发现 $SUB_COUNT 个子域名。 # 阶段2: Amass 深度解析与关联发现 echo [2] 运行 Amass 进行深度处理... # 使用 -passive 模式仅进行解析和关联避免耗时过长的主动爆破 # -nf 指定输入文件-dir 指定工作目录存放数据库 $AMASS enum -passive -norecursive -noalts -df $OUT_DIR/subfinder_clean.txt -dir $OUT_DIR/amass_data -o $OUT_DIR/amass_results.txt # 从 Amass 数据库中提取解析到的域名和IP $AMASS db -dir $OUT_DIR/amass_data -names -o $OUT_DIR/amass_final_domains.txt $AMASS db -dir $OUT_DIR/amass_data -ips -o $OUT_DIR/amass_ips.txt # 阶段3: HTTP服务存活验证 echo [3] 验证 HTTP/HTTPS 服务存活... $HTTPX -l $OUT_DIR/amass_final_domains.txt -title -status-code -tech-detect -follow-redirects -silent -o $OUT_DIR/alive_services.txt ALIVE_COUNT$(wc -l $OUT_DIR/alive_services.txt 2/dev/null || echo 0) echo [] 发现 $ALIVE_COUNT 个存活Web服务。 # 阶段4: 端口扫描针对去重后的IP echo [4] 对解析到的IP进行快速端口扫描... sort -u $OUT_DIR/amass_ips.txt $OUT_DIR/unique_ips.txt # 扫描常见Web端口和关键服务端口 $NAABU -list $OUT_DIR/unique_ips.txt -p 80,443,8080,8443,22,21,3306,3389 -silent -o $OUT_DIR/naabu_ports.txt PORT_SCAN_COUNT$(wc -l $OUT_DIR/naabu_ports.txt 2/dev/null || echo 0) echo [] 端口扫描完成发现 $PORT_SCAN_COUNT 个开放端口。 # 阶段5: 生成简易报告 echo [5] 生成最终报告... { echo # 资产测绘报告 - $TARGET echo **扫描时间:** $(date) echo echo ## 摘要 echo - 总发现子域名: $SUB_COUNT echo - 存活Web服务: $ALIVE_COUNT echo - 唯一IP地址: $(wc -l $OUT_DIR/unique_ips.txt) echo - 开放端口: $PORT_SCAN_COUNT echo echo ## 存活Web服务列表 cat $OUT_DIR/alive_services.txt 2/dev/null | head -20 | sed s/^/- / echo echo ## 详细数据文件 echo - 所有子域名: \subfinder_clean.txt\ echo - 存活服务: \alive_services.txt\ echo - 唯一IP: \unique_ips.txt\ echo - 开放端口: \naabu_ports.txt\ } $OUT_DIR/summary.md echo [] 流水线执行完毕报告位于: $OUT_DIR/summary.md4.3 使用与调度给脚本添加执行权限并运行chmod x asset_pipeline.sh ./asset_pipeline.sh example.com对于多个目标可以配合xargs或编写一个简单的循环脚本# 批量处理 targets.txt 中的每个目标 cat targets.txt | xargs -I {} -P 2 ./asset_pipeline.sh {} # -P 2 表示同时运行2个进程请根据机器性能调整更高级的调度可以使用cron定时任务用于周期性监控或者与 CI/CD 工具如 Jenkins, GitLab CI集成在每次代码更新时自动扫描对应的测试环境资产。5. 进阶优化与功能扩展基础流水线搭建完成后可以从以下几个方面进行强化使其更智能、更强大。5.1 集成更多数据源与工具GitHub 监控集成gitrob或truffleHog的扫描结果发现目标在代码仓库中泄露的 API 密钥、子域名等信息并自动加入资产库。云资产枚举如果目标大量使用 AWS、Azure、GCP可以集成cloud_enum、S3Scanner等工具发现配置错误的云存储桶、云函数等资产。SSL 证书监控使用ctfr或定期从 Censys 导出的证书数据发现通过证书透明度日志新增的子域名。5.2 结果去重与变更监控简单的sort -u去重不够智能。我们可以引入一个轻量级数据库如 SQLite来存储历史资产。首次扫描将结果存入数据库标记为“基线”。后续扫描将新结果与数据库比对自动识别出新增资产需要立即关注可能是新上线的服务或暴露点。消失资产可能已下线需确认。变更资产如 IP 地址变更、端口服务变更。 脚本可以自动生成一份“变更报告”让渗透测试人员快速聚焦于最新动态。5.3 与漏洞扫描器联动流水线的输出是完美的漏洞扫描输入。我们可以很容易地将其与 Nuclei、Xray、AWVS 等扫描器联动。将alive_services.txt中的 URL 直接喂给nuclei进行漏洞检测nuclei -l alive_services.txt -o nuclei_results.txt。将naabu_ports.txt中发现的非 Web 端口如 22, 3306交给专门的弱口令爆破或服务漏洞检测模块。5.4 可视化与告警使用 Amass 内置的amass viz命令可以将数据库内容生成力导向图直观展示资产间的关联。对于监控场景可以集成 Telegram、Slack 或钉钉的 Webhook当发现高危新增资产如admin,api,vpn等关键字或特定端口的开放时自动发送告警消息到指定群组。6. 常见问题、排错与性能调优在实际运行中你肯定会遇到各种问题。下面是一些典型场景及解决方案。6.1 工具执行报错或无结果问题Subfinder/Amass 运行后输出很少甚至没有结果。排查检查网络确保机器能正常访问外部网络特别是 GitHub、VirusTotal 等资源。有些数据源可能需要特定网络环境。检查 API 密钥这是最常见的原因。运行subfinder -list-sources和amass enum -list检查配置的数据源状态。确认provider-config.yaml和config.ini文件格式正确密钥有效且未过期。使用调试模式用-v参数运行工具查看详细的请求和错误信息。subfinder -d example.com -v。尝试单个数据源用-s参数指定单个源测试例如subfinder -d example.com -s crtsh以确定是某个源的问题还是普遍问题。6.2 扫描速度过慢问题扫描一个目标耗时过长尤其是 Amass 阶段。调优控制并发和速率这是最重要的调优点。在 Amass 配置文件中降低[dns].queries-per-second在命令行中为 Subfinder 设置-t 50降低线程数。分流处理对于超大型目标如*.google.com不要试图一次性枚举所有子域名。可以按业务模块拆分目标或者先使用非常规 TLD 进行过滤。禁用耗时模块在 Amass 中主动爆破 (-brute) 和递归枚举 (-recursive) 是最耗时的。在初步测绘阶段可以关闭-norecursive -noalts -passive。升级硬件和网络更多的 CPU 核心、更大的内存和更快的网络连接能显著提升并发性能。6.3 结果中存在大量噪声问题结果里包含大量不存在的域名NXDOMAIN、CDN 泛解析记录如*.cloudfront.net、或内部私有域名。处理DNS 解析验证这是关键步骤。在 Subfinder 后一定要用massdns或puredns等工具对结果进行批量解析验证快速过滤掉无法解析的域名。我的流水线中 Amass 的-passive模式包含了这一步。使用泛解析检测在暴力破解阶段工具如amass和gobuster可能有内置的泛解析检测。也可以手动检测随机生成一个不存在的子域名如random123456.target.com如果它能解析到某个 IP说明存在泛解析需要采用其他技术如过滤返回相同IP的域名。人工规则过滤编写正则表达式或关键字列表过滤掉明显无关的域名如*.s3.amazonaws.com、*.azurewebsites.net等云服务默认域名除非它们就是你的目标。6.4 被目标防火墙或 WAF 封禁问题频繁的 DNS 查询或端口扫描触发目标的防御机制导致后续请求被阻断。策略降低速率进一步降低扫描速率 (-rate)增加随机延迟。使用代理池为扫描流量配置多个代理 IP 进行轮询。一些工具支持-proxy参数。分散扫描源如果条件允许从多个不同的云服务器或 VPS 发起扫描。遵守规则始终在获得明确授权的范围内进行测试并提前与客户沟通扫描时间和频率避免对生产业务造成影响。6.5 数据管理与隐私考量问题扫描过程中可能意外发现不属于目标范围的资产相邻IP、其他公司服务或者收集到一些敏感信息。准则范围界定在脚本开始前明确输入目标的范围域名/IP段并在结果处理阶段进行二次过滤剔除明显超出范围的资产。数据加密存储扫描结果可能包含敏感信息。建议对存储结果的磁盘进行加密或至少对项目目录设置严格的访问权限chmod 700。及时清理根据项目要求在项目结束后的一定时间内安全地删除原始扫描数据。搭建这样一套自动化流水线初期需要一些投入来调试和优化但一旦稳定运行它将成为你渗透测试武器库中最具生产力的工具之一。它不仅能节省大量重复劳动时间更能通过持续和全面的资产发现帮助你构建起对目标攻击面的立体认知真正实现“知己知彼百战不殆”。