做资产测绘或者授权攻防评估的时候子域名收集永远是最先动手的一步。很多人来问过我Amass和Subfinder到底应该选哪个。我的答案很直接别选两个都装。Amass擅长把攻击面完整铺开内置数据源多能做主动枚举和字典爆破Subfinder赢在速度快、被动收集干净配置文件也简单。两个工具搭在一起既能明显缩短一轮收集的耗时又能把单工具的遗漏率降下来。这篇文章主要给做资产梳理、SRC测试、攻防演练准备的人看我会从分工逻辑、安装配置、集成模式、实战流程、脚本自动化到高频踩坑完整讲一遍这两个工具怎么深度配合。1. 两个工具的分工Amass管面Subfinder管快1.1 为什么不是二选一而是互补先说结论Amass和Subfinder在功能上有大量交集但设计目标完全不同。Subfinder是ProjectDiscovery社区的作品定位非常纯粹——通过被动数据源快速发现子域名不主动向目标发送查询流量跑起来轻盈、输出干净。Amass则是OWASP旗下的攻击面测绘工具它的定位不是子域发现这一件事而是把整个外部资产关系网铺开DNS记录、TLS证书、历史关联域名、API数据源、主动爆破全部揉在一起输出结构化的测绘结果。很多新手会陷入一个误区觉得只要Amass就够了或者Subfinder更快没必要用大而全的工具。实际跑过一轮就会明白Subfinder分钟级出结果Amass可能跑了十几分钟还在扫但Subfinder漏掉的子域Amass往往能通过更多数据源和主动探测补回来。反过来如果每次只跑Amass节奏会慢到拖垮整个项目。还有一层容易被忽略两个工具的API数据源并不完全重叠。同一个域名Subfinder可能从某个被动源拿到一条记录而Amass从另一个数据源拿到完全不同的记录。所以叠加使用不是重复劳动而是互相查漏补缺。1.2 数据源与输出粒度的差异具体拆开看两者的差异主要体现在三块数据源接入方式不同。Subfinder通过YAML配置文件provider-config.yaml接入VirusTotal、Shodan、Censys、Fofa等几十个数据源每个源只需要填入API密钥Amass则通过INI格式的config.ini管理数据源同样可以填VirusTotal、Shodan这些但它还会结合主动采集能力比如从DNS服务器差异、证书透明度日志、搜索引擎快照等维度做关联分析。输出格式不一样。Subfinder默认只输出纯域名列表适合直接进入下一步工具做存活校验Amass默认支持CSV、JSON输出除了域名还会附带发现来源、关联记录、首次发现时间等字段。做攻击面测绘时Amass的CSV很有用能追溯某条子域是从哪个数据源挖出来的做快速筛选时Subfinder的纯文本更友好。主动与被动模式的分工。Subfinder基本只做被动收集不主动向目标基础设施发包所以不容易触发告警。Amass的-active模式会主动解析域名、尝试区域传送、抓取TLS证书信息信息更全但也意味着会产生真实流量。两者配合的典型策略就是先用Subfinder做快速被动摸底再让Amass针对已发现的子域做更重的主动测绘。这里顺便强调一句所有枚举、爆破、主动探测都必须在目标所有方授权的范围内进行。资产测绘和渗透测试一样边界不清的操作本身就有风险。2. 环境准备和配置文件最容易卡住人的地方2.1 安装方式与版本陷阱Amass和Subfinder的安装都不复杂但版本坑不少。Subfinder是Go语言写的老教程喜欢让你go get现在更推荐直接去GitHub Releases页面下载对应平台的二进制或者用包管理器macOS上可以用HomebrewLinux发行版如果有官方仓库也可以直接装。Amass同理建议直接用release二进制免去GOPATH、依赖版本等一堆环境问题。如果用go install方式装有个经典坑安装完成后shell找不到命令。原因基本是GOPATH/bin不在PATH环境变量里。我一般在~/.bashrc里加上export GOPATH$HOME/go export PATH$PATH:$GOPATH/bin装完先跑一下版本号确认amass -version subfinder -version注意Amass v4.x的早期版本和v3.x参数差异很大网上很多旧教程还在写-whois、-brute这类老参数的位置并不完全通用。我的建议是装完先看amass -h和subfinder -h以帮助文档为准别照着两三年前的博客盲操作。2.2 Amass数据源配置config.ini的格式与常见错误Amass默认读取~/.config/amass/config.ini也可以随时用-config参数指定自定义路径。配置文件是INI格式结构大概这样[data_sources] [data_sources.VirusTotal] apikey你的密钥 [data_sources.Shodan] apikey你的密钥 [data_sources.Censys] id你的ID secret你的Secret这个文件本身不难但我在帮人排查时发现几个高频错误复制粘贴密钥时带上了多余空格或引号导致API认证失败。把多个密钥写在同一行改成分行后忘了调整语法。更新了密钥但没重启终端或者没指定-config路径实际还是走了默认空配置。验证配置是否生效有个笨办法跑一次被动枚举打开verbose日志看数据源有没有被加载。比如amass enum -passive -d example.com -config config.ini -v日志里会显示当前启用了多少个数据源。如果数字少得可怜基本就是配置解析出了问题。2.3 Subfinder数据源配置YAML缩进本身就是坑Subfinder的配置文件默认路径是~/.config/subfinder/provider-config.yaml内容大概是shodan: - 你的密钥 virustotal: - 你的密钥 censys: - 你的ID - 你的SecretYAML对缩进极度敏感必须用两个空格作为层级缩进不能用Tab。很多人在这一步卡住最后发现是-列表项前面多了一个空格或者某个key和后面的值没对齐。我建议最稳妥的做法是不要手动从零写先运行一次subfinder -provider-config生成默认模板然后在模板基础上改。改完再跑subfinder -d example.com -pc provider-config.yaml -v确认日志里没有红色报错并且有x active sources这样的加载提示就说明配置生效了。2.4 两套配置放在一个工作目录里管理因为两个工具的配置格式完全不同我在实际项目中习惯建一个subdomain_toolkit工作目录里面单独放一套配置避免污染全局subdomain_toolkit/ ├── configs/ │ ├── amass_config.ini │ └── provider_config.yaml ├── wordlists/ ├── outputs/ └── scripts/每次工作就固定用一套命令参数指定到工作目录下的文件。这样换机器、换项目、交给同事接手都很方便不会出现跑起来用的还是系统旧配置这种问题。3. 三种可落地的集成模式3.1 快速预筛加深度测绘先Subfinder后Amass这是我最常用的模式也是逻辑最顺的一种。第一轮Subfinder做被动预筛把子域列表在几十秒内拉出来。subfinder -d example.com -all -silent -o outputs/round1_subfinder.txt-all表示使用所有已配置的数据源-silent让输出干净到只有域名列表。这一步得到的是基础资产面。第二轮把第一轮的结果作为Amass的根域列表做深度枚举。注意这里不是让Amass去爆破第一轮的每个子域而是把发现的子域交给Amass做关联分析Amass会基于这些子域继续挖关联域名、证书信息和历史记录。amass enum -passive -active -df outputs/round1_subfinder.txt -config configs/amass_config.ini -timeout 20 -o outputs/round2_amass.txt-df指定根域名文件一个域名一行-timeout是分钟级的超时控制。为什么要把Subfinder的结果喂给Amass而不是让Amass从头跑核心原因是Amass通过子域之间的关联关系比如相同证书、相同解析记录、相同所有者信息能挖出更多同源资产只给根域名的话它会错过不少隐藏在已知子域背后的线索。3.2 直接合并去重最粗暴但最有效的模式如果不想搞那么重的二级联动直接把两个工具的输出合并去重也能立刻提升覆盖度。cat outputs/round1_subfinder.txt outputs/round2_amass.txt | sort -u outputs/all_subdomains.txtsort -u能顺便处理大小写问题严格来说大小写敏感但DNS域名通常会被降级处理。如果还想更严谨一点可以做一次小写统一cat outputs/round1_subfinder.txt outputs/round2_amass.txt | tr A-Z a-z | sort -u outputs/all_subdomains.txt这一步看似简单但效果立竿见影。我之前在一个授权资产项目里单独跑Subfinder得到约900条子域单独跑Amass得到约1100条合并去重后是1500多条说明两个工具的交集只有一半左右。不合并等于丢掉三成资产。3.3 用Amass子命令做长期追踪intel/track的补充价值Amass不只是enum一个命令intel和track在集成工作流里也有位置。intel负责查关联数据比如用whois、反向DNS等做前期侦察amass intel -d example.comtrack则适合做周期性对比记录同一域名在某个时间段内新增或移除的子域前提是Amass的数据库开启状态。平时做项目报告时track能给出这个月新增了哪些子域、下线了哪些资产的直观差异配合Subfinder的快速摸底整个资产变化链路就很清晰。当然日常快速场景里用到intel和track的频率不高但它们和Subfinder之间并不冲突属于锦上添花的进阶能力。集成方案不必做得很复杂先把最基本的先跑通后面再按需加。4. 从零开始的一轮实战example.com全流程记录4.1 第一轮Subfinder被动收集我用example.com做演示实际项目中替换成你的授权目标即可。进入工作目录先跑Subfindercd subdomain_toolkit subfinder -d example.com -all -silent -pc configs/provider_config.yaml -o outputs/example_subfinder.txt命令跑完后看下结果数量wc -l outputs/example_subfinder.txt我实测下来一个中等规模的站点Subfinder大概能给出几百到上千条结果耗时通常在一分钟以内。如果数据量太大可以再加-recursive做递归查询但要注意API配额消耗会明显增加。4.2 第二轮Amass主动枚举与爆破接着用Amass做主动模式和爆破。爆破不可避免要一个好的词表如果你没有现成的可以先用Amass自带字典跑一遍后续再换大字典补漏。amass enum -active -brute -d example.com -w wordlists/dns_subdomains.txt -config configs/amass_config.ini -dns-qps 50 -timeout 30 -o outputs/example_amass.txt这里-brute会基于字典生成可能的子域名并尝试解析-dns-qps限制每秒DNS查询数默认值有时候太激进容易触发解析商的限流-timeout是最大运行分钟数防止任务卡死在某个数据源上。跑Amass时不要干等我一般会同时把上一轮Subfinder的结果拿去做基础存活探测把时间利用起来。4.3 合并去重与基础校验两轮都跑完后统一合并cat outputs/example_subfinder.txt outputs/example_amass.txt | tr A-Z a-z | sort -u outputs/example_all.txt合并后我习惯再和已知资产表做一次比对。比如你手头有一份官方资产清单official_assets.txt用-Fx按整行精确匹配就能找出不在这份清单里的未知资产grep -Fxf official_assets.txt outputs/example_all.txt | wc -l也可以反过来找出不在白名单里的grep -vFxf official_assets.txt outputs/example_all.txt这一步能快速帮你定位哪些子域需要优先人工确认。4.4 从域名列表到资产指纹接上httpx桥接Amass和Subfinder做完后如果这是一次完整的web资产测绘下一步通常是做存活探测和指纹识别。ProjectDiscovery生态里httpx正好和Subfinder无缝衔接cat outputs/example_all.txt | httpx -silent -status-code -title -tech-detect -follow-redirects这条命令会对每个子域发起HTTP请求输出状态码、页面标题和技术栈指纹。走到这一步子域枚举的收集阶段才算真正闭环后面就可以继续接nuclei漏洞扫描或者手工测试。一次跑完后的结果大概长这样示意子域状态码标题技术栈来源www.example.com200Example HomeCloudflare, ReactSubfinderapi.example.com403-Nginx, Node.jsAmassstaging.example.com200Staging AppNginx, PHPAmassSubfinder来源列可以帮你分析哪个工具发现了哪些资产后续优化配置时很有用。5. 把流程脚本化批量域名的自动化方案5.1 一个最小可用的工作流脚本跑了几次全流程后手动敲命令就有点烦了。我写了个简单的bash脚本参数传入域名自动完成Subfinder收集、Amass枚举、合并去重顺便把关键结果打日志#!/bin/bash # usage: ./run_recon.sh example.com DOMAIN$1 TS$(date %Y%m%d_%H%M%S) OUToutputs/${DOMAIN}_${TS} mkdir -p $OUT echo [*] Running Subfinder subfinder -d $DOMAIN -all -silent -pc configs/provider_config.yaml -o $OUT/subfinder.txt echo [*] Running Amass amass enum -passive -active -d $DOMAIN -config configs/amass_config.ini -timeout 20 -o $OUT/amass.txt echo [*] Merging results cat $OUT/subfinder.txt $OUT/amass.txt | tr A-Z a-z | sort -u $OUT/final.txt wc -l $OUT/final.txt这个脚本没什么高深技术但它把命令重复执行变成了固定流程执行降低了每天切换多个工具的认知负担。如果还想更省事可以再套一层循环批量处理多个域名。5.2 批量域名的输入与任务分批批量场景下Subfinder用-dL指定域名列表文件Amass用-df指定根域名文件subfinder -dL domains.txt -all -silent -o outputs/batch_subfinder.txt amass enum -passive -active -df domains.txt -config configs/amass_config.ini -timeout 60 -o outputs/batch_amass.txt我个人的经验是批量任务不要一次丢上百个域名给Amass尤其开启了-active和-brute之后整个任务可能几个小时跑不完。更稳妥的方式是先按优先级给域名分组每个批次控制在10到20个逐个检查进度。同时在脚本里记录每个域名的开始和结束时间方便估算整个资产测绘项目的排期。5.3 定时任务的注意事项如果你要做周期性资产监控可以用crontab定时拉取0 2 * * * /path/to/run_recon.sh example.com logs/recon.log 21但我强烈建议定时任务里优先用被动模式把-active和-brute关掉。原因很简单被动模式对目标产生的影响极小适合高频执行主动模式会产生大量DNS查询属于实质性的流量行为每周甚至每月跑一次就够了。API配额也要提前规划VirusTotal这类免费额度有每日调用上限高频定时任务很容易把配额刷爆第二天直接报错。6. 实测中容易翻车的几个细节6.1 API限速与调用配额这是我最先要提醒的坑。Amass和Subfinder的价值很大一部分来自商业数据源API但API都有配额和速率限制。Amass跑的时候有时日志里会刷出一堆rate limit exceeded这时候结果会明显变少甚至某些源直接失效。我的处理方式是在Amass命令里显式设置-dns-qps别用默认的激进值一般30到50比较稳。Subfinder的-all参数会把所有源全部启用某些慢的源会拖长整个任务如果只是日常快速排查不加-all反而更快。免费配额用完时适当错峰执行把大任务放到凌晨批次。6.2 字典选择与爆破时间Amass的-brute一旦开启任务时长会从分钟级跳到小时级。默认字典很小覆盖有限但如果直接上超大字典比如几万条前缀对一个有很多CNAME的站点来说可能会产生大量无效请求。我的建议是第一次探测先用中小型字典跑完看命中率如果命中率比较高再换大字典补一轮。爆破不用追求一次全中资产测绘是个持续优化的过程。所谓泛解析问题就是某些DNS服务器会对任意不存在的子域返回一个默认IP导致爆破结果里出现大量假资产。遇到这种情况必须对爆破结果做二次确认比如把解析到同一IP且标题都是默认页的子域单独拉出来审一遍。Amass的CSV输出里可以看来源标签我会直接筛选出brute来源的条目做重点核查。6.3 主动、被动结果的差异要心里有数被动收集和主动枚举的结果特性完全不同。被动收集干净、误报少因为每条记录都来自真实存在过的数据源主动枚举信息更全但噪音也更多尤其是在泛解析的域名上。所以合并结果时不要觉得数量越多越好。我见过有人拿Amass主动模式下扫出来的几千条结果直接进漏洞扫描结果一半都是泛解析假资产白白浪费时间和扫描流量。正确的姿势是合并后先做一轮存活和去伪再进入下一步。6.4 配置文件泄露风险最后提一个容易被忽略的安全习惯amass_config.ini和provider_config.yaml里都是明文API密钥千万不能提交到Git仓库。我见过不止一次开发者把配置目录整个推到GitHub导致密钥被别人拿走刷爆配额、产生账单。建议在所有相关目录下加.gitignore或者至少把configs目录忽略掉。本地文件权限也顺手改一下chmod 600 configs/amass_config.ini configs/provider_config.yaml这串操作十秒钟但能省掉后面一大堆麻烦。跑过几轮完整的AmassSubfinder流程后我最深的体会是这两个工具本身都不难学真正的价值在于把它们放进一条清晰的资产测绘流水线里让每一步的输出自然成为下一步的输入。你不需要在刚开始就把所有参数吃透只需要先跑通我上面写的快速预筛加深度测绘这套流程然后根据实际结果不断调整字典、数据源和任务节奏。等配好了后续每次拿到域名半小时内就能产出一份像样的资产清单这份效率提升才是最值得投入时间的地方。