互联网资产梳理这件事很多团队第一次做的时候都以为是把域名列个表真干起来才发现完全不是这么回事。主域下面挂着一堆自己都忘了的子域云上还有几台临时开的机器外包做完项目留下的测试环境再加上历史并购带过来的老资产——台账上写着三百个实际扫出来两千多。标题里这个能做互联网资产梳理服务的浏览器插件切入的正是这个场景它不解决大规模全自动测绘而是解决我手里有一个目标怎么在几分钟内把它周边的资产线索摸清楚的问题。这篇内容面向三类人一是刚接手资产盘点、安全运营或运维台账的同行需要一套能落地的流程二是做安全评估、需要快速核验目标范围的从业者三是对这块完全陌生、想弄明白资产梳理到底在梳理什么的新手。下面我会讲清楚插件这种形态的取舍、它的核心能力该怎么用、完整跑一遍的实操流程、参数和字典的细节以及踩过的坑。1. 为什么用插件做资产梳理形态选择背后的逻辑1.1 传统资产盘点方式的三个痛点先说清楚痛点才能理解插件这个形态为什么有存在价值。我在几个不同规模的团队里都推进过资产台账几乎每一轮都卡在同样三个地方。第一是变更滞后。台账通常是季度或半年更新一次但业务侧开一个测试环境可能就一下午的事用完不关域名解析还留着。等你下一次盘点时台账和现实已经差了半年。台账的本质问题是它是一份快照而资产是流快照永远追不上流。第二是口径不统一。安全团队说资产指的是暴露在公网的域名和 IP运维团队说的资产是 CMDB 里的机器和应用业务团队理解的是我负责的那个系统。三套口径对不上最后汇总出来的表格谁都不认。我见过最典型的情况是同一个域名安全那边标了高风险运维那边查无此机一追查发现是外包团队注册的、业务方自己都不知道。第三是单点核验效率低。真正做梳理的时候大量时间不是花在批量扫描上而是花在这一个域名到底是个什么东西、归谁、还活着吗这种零碎的核验上。你打开浏览器查证书、看响应头、翻页面标题、对一下 IP 归属一个目标五分钟两百个目标就是一整天。这种活没有技术含量但省不掉。插件这个形态真正打的是第三个痛点同时也间接缓解前两个——因为它足够轻轻到你愿意在每次接触目标时顺手跑一下台账就有了持续更新的可能。1.2 浏览器插件形态的天然优势与边界把资产梳理能力做成浏览器插件思路其实很朴素资产梳理的第一现场就在浏览器里。你访问一个系统浏览器已经拿到了证书、响应头、页面标题、favicon、跳转链路、加载的第三方资源域名这些恰恰是判断资产归属和技术指纹最有价值的信息。插件只是把这些已经在眼前但没人看的信息抽出来再做一层扩展查询。这个形态的优势很明确。一是零部署装完就能用不需要你准备服务器、配置扫描器、维护依赖环境对临时接手项目的人特别友好。二是上下文完整插件知道你现在正在看哪个站所以能把当前页面的信息作为一个种子去做关联扩展而不是让你手工复制粘贴。三是门槛低不懂命令行的人也能上手这点在跨团队协作时很重要——你让运维同事装个插件他能接受你让他配一套扫描框架他直接不理你。但边界也必须讲清楚否则容易用错地方。浏览器的资源调度天然受限并发能力弱几百个目标的批量任务跑起来会明显卡顿没有分布式能力做不了大规模测绘网络出口单一高频率请求很容易触发目标侧的限制结果依赖前端呈现复杂的数据关联和长期存储能力不足。我的判断标准很直接目标数量在几十到几百这个量级、需要快速核验和交叉验证、要拿着结果去跟业务方对齐——用插件。目标数量上千、要做周期性全量测绘、需要留存历史快照做变更对比——上专业测绘平台加自建调度。两者不冲突插件更像是随身工具而不是作战平台。注意所有资产梳理动作都必须建立在明确授权的基础上。对自己负责的资产、或已获得书面授权范围内部署的资产做梳理是正常的运维和安全运营工作对范围外的目标做扫描无论用什么工具都不合适这一点没有讨论空间。2. 核心能力拆解一个资产梳理插件应该具备什么2.1 域名与子域名的发现链路资产梳理的骨架是域名。一个组织在公网上的面积很大程度上由它拥有的域名和子域数量决定。所以评价这类插件第一个要看的就是它的子域发现链路是否完整。完整的链路通常包含几个来源。被动来源优先因为它不打草惊蛇也不产生额外请求证书透明度日志里记录了每一张签发过的证书及其包含的域名这是目前性价比最高的子域来源之一公开的被动 DNS 数据集能反映历史解析记录搜索引擎和公开网页里散落的链接、JS 文件里硬编码的接口地址也常常能捞出内部域名。主动来源则是基于字典的枚举用常见前缀去拼接主域做解析探测。我特别看重的一点是证书关联能力。一张多域名证书的 SAN 字段里往往塞着同一批业务的好几个域名你从一个入口拿到证书就能顺着拖出一串相关资产。这是从一个点撬开一片最经典的路径插件如果能在你访问页面时自动解析当前站点的证书并列出 SAN 里的其他域名这一条就值回票价了。另一条容易被忽略的链路是页面资源的域名提取。你打开一个业务系统页面里往往加载了静态资源域、接口域、埋点域这些域名和主站同属一个组织但前缀完全不同靠字典是猜不出来的。插件能直接读当前页面的资源清单把这些域名抽出来这是人工做起来最费劲的一步。2.2 指纹、证书与IP归属的关联分析光有域名列表没用你得知道每个域名背后是什么。这就是指纹识别要解决的问题。指纹的本质是特征匹配。一个 Web 应用在响应头、Cookie 名、特定路径的返回内容、页面 title、favicon 的哈希值上都会留下相对稳定的特征。favicon 哈希是我个人最推荐的手段原因是成本极低、误报率也低——同一套系统部署在不同域名下favicon 往往是同一张图哈希一比对就能归堆。响应头里的 Server、X-Powered-By 这类字段信息量也很大虽然经常被改但改不干净的情况更多。IP 归属的关联则是另一条线。域名解析出来的 IP如果能判断出所属网段和归属特征就能反推出一批同网段资产。云环境里这个特征尤其明显同一批业务往往部署在同一片地址段内。反解域名也是个好线索很多云主机的反解记录里带着业务标识。这里要注意的是同 IP 不等于同归属共享托管环境下几百个站挤在一个 IP 上是常态不能简单按 IP 归堆必须结合证书、favicon、页面特征综合判断。提示指纹识别一定会有误判。同一套 CMS 建的站、同一家外包做的系统特征会高度相似。判断归属时至少要有两个独立维度互相印证单靠一个 title 相同就下结论后面核对阶段会返工。2.3 资产去重与归属判定这一节讲的是整个流程里最枯燥但最影响结果质量的部分去重和归属。去重的难点在于同一个资产有多种表示形式。https://a.example.com、http://a.example.com:80、a.example.com、解析到同一个 IP 的另一个别名域名在原始结果里是四条记录但业务上是一台机器。常见的归一化规则是统一协议和端口表示、去掉默认端口、URL 去掉查询参数和路径、域名统一小写并去掉末尾的点。做完这层归一化重复率通常能降下来一大截。更麻烦的是归属判定。一个域名解析在某个 IP 上不代表这个 IP 属于你一个页面长得像你们的系统也不代表它就是你们的资产。我一般用三级判定一级是直接证据比如域名的主域在授权清单内、证书主体信息匹配二级是间接证据比如页面出现组织名称、备案主体匹配、favicon 与已知资产一致三级是人工确认前两级都模棱两可的一律标记为待确认交给业务方核实绝不能凭感觉划进范围。这个待确认状态非常关键。我见过太多团队在做梳理时把疑似资产直接算进范围结果评估报告里出现了根本不属于自己的系统既浪费了人力也带来了不必要的麻烦。宁可少划十个不能错划一个这是我在实际项目里坚持的原则。3. 实操流程从零跑通一次完整的资产梳理3.1 准备阶段授权、范围与时间窗口正式动手之前有三件事必须先落地不然后面全是白干。授权文件。明确写清楚梳理的域名范围、IP 范围、时间窗口、允许的动作类型只做被动信息收集还是允许主动探测、紧急联系人。这不是走形式是出现问题时唯一的依据。范围清单。把已知的主域、已知 IP 段、已知的业务系统清单列出来作为种子。这份清单不需要完整它只是起点。我通常会把清单分成确定在范围内和疑似在范围内两栏后者在前面的归属判定环节会用到。时间窗口和速率约定。梳理动作会产生大量请求对业务系统是有压力的。如果目标是生产环境尽量安排在业务低峰期并且明确速率上限。我的经验值是单个目标每秒不超过 5 个请求对核心业务系统还要再降。这个约定要提前跟运维和业务方对齐不要自己拍脑袋。准备阶段还要做一件事确定台账字段。很多人上来就开扫扫完发现结果导出后字段乱七八糟没法入库也没法交付。字段设计应该在动手前定好后面所有动作都围绕字段来。我常用的最小字段集如下字段名说明是否必填资产名称业务方认可的名称便于沟通是域名归一化后的完整域名是解析 IP当前解析结果多个用分号分隔是端口/协议如 443/https是技术指纹识别出的组件与版本线索否归属部门业务或运维确认的责任方是状态在用 / 闲置 / 待确认 / 已下线是首次发现时间用于判断资产新旧是最后存活时间用于判断是否已下线是备注记录判定依据和疑点否3.2 第一步种子域名的组织维度扩展拿到种子之后第一步不是急着枚举子域而是先把组织维度的信息补齐。具体做法是以已知主域为起点通过公开的证书信息、页面上的组织标识、已知系统的页面底部信息找到这个组织的其他主域。很多组织不止一个主域尤其是历史较久的可能有三四个不同后缀的域名同时在用。这一步漏了后面枚举做得再细也是白费。插件形态在这里的优势是顺手。你打开一个业务系统插件读取当前证书和页面资源把关联的域名一次性列出来你只需要判断哪些是新的、哪些已经在清单里。这个过程不需要额外工具也不需要切换上下文。这一阶段还要做一件容易被跳过的事记录来源。每一条新增的种子域名都记下它是从哪个入口发现的。后面出现争议时来源信息就是判定依据。我吃过这个亏——一批域名进了清单两个月后没人记得它们是怎么来的最后只能全部标成待确认前面的工夫白搭。3.3 第二步子域名枚举与存活探测有了种子就可以做子域枚举了。我的建议是被动优先、主动补充、递归有限。被动方式先跑一遍证书透明度日志、公开被动 DNS 数据集、页面资源提取、搜索引擎结果。这一步几乎不产生直接请求风险最低产出通常能占到总量的六七成。主动字典枚举放在后面作为补充用来覆盖那些从没签发过证书、也没被公开记录过的内部子域。字典的选择直接影响产出效率。中文环境下高频前缀有明显的行业特征我把常用的整理成几类类别常见前缀说明业务门户portal、sso、oa、mail、home命中率高优先环境标识dev、test、uat、stage、pre、beta测试环境常暴露问题管理入口admin、manage、console、dashboard价值高但风险也高接口与文档api、open、gateway、doc、swagger常用于排查暴露面静态与资源static、cdn、img、file、upload辅助判断资产归属历史遗留old、bak、temp、v1、v2常常是无人认领的资产递归深度我建议控制在两到三层。比如api.dev.example.com这种从example.com枚举到dev.example.com是第一层再往下枚举dev下的子域是第二层。三层以上产出增长很快但有效率急剧下降而且请求量会成倍放大。实测下来两层的性价比最高。存活探测这一步插件的做法通常是发一个请求看响应。判断存活的依据不能只看状态码200 是活301/302 也是活401/403 同样是活只是需要认证甚至 500 也可能是个真实存在的有问题的系统。真正要排除的是 DNS 解析失败、连接超时、以及泛解析产生的假结果——这个坑后面单独讲。3.4 第三步端口与指纹识别存活确认之后进入信息提取阶段。这一步的目标是把这是一个域名变成这是一个什么系统。端口探测的范围要克制。全端口扫描在插件形态下既不现实也不合适通常是拿一份常见端口清单Web 类的 80/443/8080/8443数据库类的 3306/6379/27017远程管理类的 22/3389再结合页面特征做针对性补充。这里有个重要认知端口开放不等于服务可用很多云环境安全组配置了只放行特定来源你从外部探测看到的关闭不代表内部不可达反过来开放也不代表服务真的在跑可能只是一个负载均衡在前面挡着。指纹识别在插件里通常是自动完成的读取响应头、Cookie 名、页面 title、favicon 哈希跟内置的特征库做匹配。我要提醒的是版本号的处理。有些系统会在响应头或页面里暴露精确版本号这些信息对资产梳理的价值是判断资产新旧、是否需要重点关注但它同时是敏感信息台账里记录时要控制范围只在内部流转不要出现在任何对外交付物里。指纹结果的用法是聚类。把 favicon 哈希相同、响应头特征一致的资产归成一组组内选一个代表做深入核验比一个个看效率高得多。我在一个项目里用这个方法把两千多条原始记录压缩成了不到一百个技术栈分组后续核对的工作量直接降了一个数量级。3.5 第四步资产归集、台账落地与复核扫描做完真正的工作才开始。原始结果是一堆无序的记录必须经过归集才能变成可用的台账。归集的动作按顺序是归一化 → 去重 → 分组 → 标注 → 复核。归一化和去重前面讲过这里说分组和标注。分组有两条主线。一条是技术分组按指纹、favicon、响应特征聚类目的是找出同一批部署的资产。另一条是业务分组按域名前缀、页面内容、归属线索分组目的是把资产挂到业务方名下。两条线交叉才能形成这个业务用了这套技术栈、部署在这批 IP 上的完整图景。标注阶段要敢于写待确认。我一般把结果分成三类明确归属的有直接证据、疑似归属的有间接证据、无法判断的。第三类不要硬塞原样交给业务方让他们认领。实践中经常出现的情况是业务方一看就说这个我们早就不用了这种信息比你自己猜一百次都准。复核环节我建议做抽样回访。从每个分组里随机抽几个手工再核验一遍确认工具的判定逻辑没有系统性偏差。抽样比例不用高百分之五到十就够但一定要做。我遇到过指纹库把某类通用框架全部误判的情况因为当时没抽样最后整份台账的技术栈字段都是错的返工量极大。4. 实操心得与参数细节让结果可用而不是好看4.1 字典与递归深度怎么配才不浪费请求字典这件事我的观点是小字典精跑好过大字典乱跑。一个两万行的通用字典跑完可能产生几万次请求产出几百个有效结果有效率不到百分之一而且很容易触发目标侧的限制。用一份两三千行、经过业务特征筛选的字典有效率能提到百分之五以上整体效率反而更高。字典要按目标定制。做法是先从被动来源拿到一批已知子域分析它们的前缀规律——比如这个组织特别喜欢用xxx-prod、xxx-test这种命名那字典里就把-prod、-test这种后缀组合加进去。这种从已知推未知的方式产出质量远高于盲目堆字典。递归深度控制在两层前面说过。这里补充一个细节递归要有边界条件。比如某一层枚举出的结果全部解析到同一个泛解析 IP那就应该立即停止这一层的递归因为再往下都是无效产出。插件如果能自动识别这种情况并提示会省掉很多时间。还有一个经验把高价值前缀单独跑一轮。管理入口、接口文档、测试环境这几类命中率不高但价值极高值得单独用一份小字典跑跑完单独人工看。混在大批量结果里很容易被淹没。4.2 并发、超时与误报控制插件形态下并发不能开太大。我的经验配置是并发 20 到 50单请求超时 3 到 5 秒DNS 解析超时单独放到 5 到 8 秒。DNS 超时要比 HTTP 长因为很多解析失败其实是解析慢超时设短了会产生大量假阴性。误报控制的核心是泛解析检测。做法很简单随机生成几个不可能存在的前缀去解析主域如果这些随机前缀都能解析成功说明这个域配置了泛解析那么所有枚举结果都要打上问号必须靠响应内容进一步区分比如响应体长度是否一致、返回页面是否完全相同。这一步不做结果里可能有八成都是假的。另一个误报来源是默认页。很多服务器对任意子域都返回同一个默认页面状态码 200、内容一模一样。处理方式是对比响应体指纹如果一批结果的响应体完全一致就归为默认页单独标注。还有一个细节是重定向链。一个子域解析成功、返回 301 跳到主站这算不算有效资产我的判断是算但要标注重定向至主站因为它在 DNS 层面是独立存在的可能是遗留配置也可能是业务入口。区别对待不要一律剔除。提示所有速率和并发参数都不是固定的要根据目标系统的承载能力和授权约定动态调整。对核心生产系统宁可慢十倍不要出问题。4.3 结果导出与台账字段设计导出这一步很多人不当回事结果交付时被业务方退回重做。我的经验是导出前先想清楚谁来用这份表。给安全团队用的字段要偏技术IP、端口、指纹、暴露面判断。给运维用的字段要偏管理归属部门、责任人、状态、变更记录。给管理层看的只需要汇总数字和趋势。同一份原始数据导出三个视图比导出一份大而全的表更实用。字段设计上有几个具体的坑。一是多值字段的分隔符要统一多个 IP 用分号还是逗号必须全表一致否则后续做数据透视会出错。二是时间格式统一成同一时区同一格式不要一半是2024/1/5一半是2024-01-05 10:30。三是状态字段要有明确的取值枚举不能自由填写否则会出现在用使用中正常三种写法表达一个意思的情况。还有一点保留原始结果。归一化、去重之后的数据是用来交付的但原始数据一定要留档。后面出现争议、需要追溯某条记录是怎么来的只有原始数据能回答。我一般会把原始结果和加工结果分两个文件存文件名里带日期方便做历史对比。5. 常见问题与排查速查表5.1 高频问题实录做了这么多轮梳理问题其实高度集中。我把最常见的整理成一张速查表遇到问题先对一遍能省掉大半排查时间。现象最可能的原因排查与处理枚举出几千条结果绝大多数打不开域名配置了泛解析用随机前缀测试确认后改为按响应内容区分大量结果返回同一个页面服务器默认页比对响应体哈希相同的归为默认页单独标注同一个资产在表里出现多次未做归一化去重统一协议端口、去默认端口、去 URL 参数后重新去重指纹识别结果明显不对特征库匹配过于宽松抽样人工核验收紧匹配规则要求多特征同时命中扫描中途大量超时并发过高触发限速降并发到 20 以下加长超时分批执行插件结果与命令行工具不一致判定口径不同统一存活判定标准明确哪些状态码算存活部分子域能解析但访问无响应服务已下线但 DNS 未清理标注为疑似下线交业务方确认后清理证书里出现完全无关的域名共享托管或 CDN 共用证书不能直接纳入范围需结合其他证据判断导出表格打不开或乱码编码与分隔符问题统一用 UTF-8 带 BOM 导出 CSV结果无法挂到具体业务方缺少归属线索补充页面内容、备案信息等间接证据标记待确认5.2 避坑清单与合规红线除了技术问题还有几条是流程和合规层面的我觉得比技术问题更重要。第一条范围要写死在纸面上。我以为这个域名是我们的这种事在任何一次梳理里都不应该出现。范围清单要由业务方或资产归属方书面确认梳理过程中发现的新资产先标记、后确认、再纳入。第二条速率要克制。梳理不是压测大量请求打在生产系统上轻则影响体验重则造成故障。我见过因为扫描频率过高把一台老旧设备打挂的情况后续处理非常麻烦。低峰期、低速率、分批跑这是基本纪律。第三条敏感信息要控制流转。梳理结果里必然包含一些不该广泛传播的信息比如内部系统的地址、组件的版本、管理入口的位置。这些内容只在必要范围内流转交付物要做脱敏台账要控制访问权限。第四条结果要有人认领。一份没人认领的资产台账三个月后就会变成历史文件。每一轮梳理结束都要推动归属确认和责任人登记否则下一轮还得从头再来。第五条别把工具当答案。插件能帮你把信息收集的效率提高几倍但归属判断、风险定级、后续处置这些都得靠人。工具产出的是线索不是结论。最后分享一个我自己一直在用的小习惯每完成一轮梳理我会额外花半小时写一份变更说明记录这一轮相比上一轮新增了什么、下线了什么、哪些归属发生了变化。这份说明的篇幅通常不超过一页但它是整个台账真正产生价值的地方——资产管理的核心不是知道现在有什么而是知道什么在变。 
长河君 · 2026/11/6 4:16:22 · 阅读 1.2k 浏览器插件做互联网资产梳理：子域名枚举与指纹识别实操
互联网资产梳理这件事很多团队第一次做的时候都以为是把域名列个表真干起来才发现完全不是这么回事。主域下面挂着一堆自己都忘了的子域云上还有几台临时开的机器外包做完项目留下的测试环境再加上历史并购带过来的老资产——台账上写着三百个实际扫出来两千多。标题里这个能做互联网资产梳理服务的浏览器插件切入的正是这个场景它不解决大规模全自动测绘而是解决我手里有一个目标怎么在几分钟内把它周边的资产线索摸清楚的问题。这篇内容面向三类人一是刚接手资产盘点、安全运营或运维台账的同行需要一套能落地的流程二是做安全评估、需要快速核验目标范围的从业者三是对这块完全陌生、想弄明白资产梳理到底在梳理什么的新手。下面我会讲清楚插件这种形态的取舍、它的核心能力该怎么用、完整跑一遍的实操流程、参数和字典的细节以及踩过的坑。1. 为什么用插件做资产梳理形态选择背后的逻辑1.1 传统资产盘点方式的三个痛点先说清楚痛点才能理解插件这个形态为什么有存在价值。我在几个不同规模的团队里都推进过资产台账几乎每一轮都卡在同样三个地方。第一是变更滞后。台账通常是季度或半年更新一次但业务侧开一个测试环境可能就一下午的事用完不关域名解析还留着。等你下一次盘点时台账和现实已经差了半年。台账的本质问题是它是一份快照而资产是流快照永远追不上流。第二是口径不统一。安全团队说资产指的是暴露在公网的域名和 IP运维团队说的资产是 CMDB 里的机器和应用业务团队理解的是我负责的那个系统。三套口径对不上最后汇总出来的表格谁都不认。我见过最典型的情况是同一个域名安全那边标了高风险运维那边查无此机一追查发现是外包团队注册的、业务方自己都不知道。第三是单点核验效率低。真正做梳理的时候大量时间不是花在批量扫描上而是花在这一个域名到底是个什么东西、归谁、还活着吗这种零碎的核验上。你打开浏览器查证书、看响应头、翻页面标题、对一下 IP 归属一个目标五分钟两百个目标就是一整天。这种活没有技术含量但省不掉。插件这个形态真正打的是第三个痛点同时也间接缓解前两个——因为它足够轻轻到你愿意在每次接触目标时顺手跑一下台账就有了持续更新的可能。1.2 浏览器插件形态的天然优势与边界把资产梳理能力做成浏览器插件思路其实很朴素资产梳理的第一现场就在浏览器里。你访问一个系统浏览器已经拿到了证书、响应头、页面标题、favicon、跳转链路、加载的第三方资源域名这些恰恰是判断资产归属和技术指纹最有价值的信息。插件只是把这些已经在眼前但没人看的信息抽出来再做一层扩展查询。这个形态的优势很明确。一是零部署装完就能用不需要你准备服务器、配置扫描器、维护依赖环境对临时接手项目的人特别友好。二是上下文完整插件知道你现在正在看哪个站所以能把当前页面的信息作为一个种子去做关联扩展而不是让你手工复制粘贴。三是门槛低不懂命令行的人也能上手这点在跨团队协作时很重要——你让运维同事装个插件他能接受你让他配一套扫描框架他直接不理你。但边界也必须讲清楚否则容易用错地方。浏览器的资源调度天然受限并发能力弱几百个目标的批量任务跑起来会明显卡顿没有分布式能力做不了大规模测绘网络出口单一高频率请求很容易触发目标侧的限制结果依赖前端呈现复杂的数据关联和长期存储能力不足。我的判断标准很直接目标数量在几十到几百这个量级、需要快速核验和交叉验证、要拿着结果去跟业务方对齐——用插件。目标数量上千、要做周期性全量测绘、需要留存历史快照做变更对比——上专业测绘平台加自建调度。两者不冲突插件更像是随身工具而不是作战平台。注意所有资产梳理动作都必须建立在明确授权的基础上。对自己负责的资产、或已获得书面授权范围内部署的资产做梳理是正常的运维和安全运营工作对范围外的目标做扫描无论用什么工具都不合适这一点没有讨论空间。2. 核心能力拆解一个资产梳理插件应该具备什么2.1 域名与子域名的发现链路资产梳理的骨架是域名。一个组织在公网上的面积很大程度上由它拥有的域名和子域数量决定。所以评价这类插件第一个要看的就是它的子域发现链路是否完整。完整的链路通常包含几个来源。被动来源优先因为它不打草惊蛇也不产生额外请求证书透明度日志里记录了每一张签发过的证书及其包含的域名这是目前性价比最高的子域来源之一公开的被动 DNS 数据集能反映历史解析记录搜索引擎和公开网页里散落的链接、JS 文件里硬编码的接口地址也常常能捞出内部域名。主动来源则是基于字典的枚举用常见前缀去拼接主域做解析探测。我特别看重的一点是证书关联能力。一张多域名证书的 SAN 字段里往往塞着同一批业务的好几个域名你从一个入口拿到证书就能顺着拖出一串相关资产。这是从一个点撬开一片最经典的路径插件如果能在你访问页面时自动解析当前站点的证书并列出 SAN 里的其他域名这一条就值回票价了。另一条容易被忽略的链路是页面资源的域名提取。你打开一个业务系统页面里往往加载了静态资源域、接口域、埋点域这些域名和主站同属一个组织但前缀完全不同靠字典是猜不出来的。插件能直接读当前页面的资源清单把这些域名抽出来这是人工做起来最费劲的一步。2.2 指纹、证书与IP归属的关联分析光有域名列表没用你得知道每个域名背后是什么。这就是指纹识别要解决的问题。指纹的本质是特征匹配。一个 Web 应用在响应头、Cookie 名、特定路径的返回内容、页面 title、favicon 的哈希值上都会留下相对稳定的特征。favicon 哈希是我个人最推荐的手段原因是成本极低、误报率也低——同一套系统部署在不同域名下favicon 往往是同一张图哈希一比对就能归堆。响应头里的 Server、X-Powered-By 这类字段信息量也很大虽然经常被改但改不干净的情况更多。IP 归属的关联则是另一条线。域名解析出来的 IP如果能判断出所属网段和归属特征就能反推出一批同网段资产。云环境里这个特征尤其明显同一批业务往往部署在同一片地址段内。反解域名也是个好线索很多云主机的反解记录里带着业务标识。这里要注意的是同 IP 不等于同归属共享托管环境下几百个站挤在一个 IP 上是常态不能简单按 IP 归堆必须结合证书、favicon、页面特征综合判断。提示指纹识别一定会有误判。同一套 CMS 建的站、同一家外包做的系统特征会高度相似。判断归属时至少要有两个独立维度互相印证单靠一个 title 相同就下结论后面核对阶段会返工。2.3 资产去重与归属判定这一节讲的是整个流程里最枯燥但最影响结果质量的部分去重和归属。去重的难点在于同一个资产有多种表示形式。https://a.example.com、http://a.example.com:80、a.example.com、解析到同一个 IP 的另一个别名域名在原始结果里是四条记录但业务上是一台机器。常见的归一化规则是统一协议和端口表示、去掉默认端口、URL 去掉查询参数和路径、域名统一小写并去掉末尾的点。做完这层归一化重复率通常能降下来一大截。更麻烦的是归属判定。一个域名解析在某个 IP 上不代表这个 IP 属于你一个页面长得像你们的系统也不代表它就是你们的资产。我一般用三级判定一级是直接证据比如域名的主域在授权清单内、证书主体信息匹配二级是间接证据比如页面出现组织名称、备案主体匹配、favicon 与已知资产一致三级是人工确认前两级都模棱两可的一律标记为待确认交给业务方核实绝不能凭感觉划进范围。这个待确认状态非常关键。我见过太多团队在做梳理时把疑似资产直接算进范围结果评估报告里出现了根本不属于自己的系统既浪费了人力也带来了不必要的麻烦。宁可少划十个不能错划一个这是我在实际项目里坚持的原则。3. 实操流程从零跑通一次完整的资产梳理3.1 准备阶段授权、范围与时间窗口正式动手之前有三件事必须先落地不然后面全是白干。授权文件。明确写清楚梳理的域名范围、IP 范围、时间窗口、允许的动作类型只做被动信息收集还是允许主动探测、紧急联系人。这不是走形式是出现问题时唯一的依据。范围清单。把已知的主域、已知 IP 段、已知的业务系统清单列出来作为种子。这份清单不需要完整它只是起点。我通常会把清单分成确定在范围内和疑似在范围内两栏后者在前面的归属判定环节会用到。时间窗口和速率约定。梳理动作会产生大量请求对业务系统是有压力的。如果目标是生产环境尽量安排在业务低峰期并且明确速率上限。我的经验值是单个目标每秒不超过 5 个请求对核心业务系统还要再降。这个约定要提前跟运维和业务方对齐不要自己拍脑袋。准备阶段还要做一件事确定台账字段。很多人上来就开扫扫完发现结果导出后字段乱七八糟没法入库也没法交付。字段设计应该在动手前定好后面所有动作都围绕字段来。我常用的最小字段集如下字段名说明是否必填资产名称业务方认可的名称便于沟通是域名归一化后的完整域名是解析 IP当前解析结果多个用分号分隔是端口/协议如 443/https是技术指纹识别出的组件与版本线索否归属部门业务或运维确认的责任方是状态在用 / 闲置 / 待确认 / 已下线是首次发现时间用于判断资产新旧是最后存活时间用于判断是否已下线是备注记录判定依据和疑点否3.2 第一步种子域名的组织维度扩展拿到种子之后第一步不是急着枚举子域而是先把组织维度的信息补齐。具体做法是以已知主域为起点通过公开的证书信息、页面上的组织标识、已知系统的页面底部信息找到这个组织的其他主域。很多组织不止一个主域尤其是历史较久的可能有三四个不同后缀的域名同时在用。这一步漏了后面枚举做得再细也是白费。插件形态在这里的优势是顺手。你打开一个业务系统插件读取当前证书和页面资源把关联的域名一次性列出来你只需要判断哪些是新的、哪些已经在清单里。这个过程不需要额外工具也不需要切换上下文。这一阶段还要做一件容易被跳过的事记录来源。每一条新增的种子域名都记下它是从哪个入口发现的。后面出现争议时来源信息就是判定依据。我吃过这个亏——一批域名进了清单两个月后没人记得它们是怎么来的最后只能全部标成待确认前面的工夫白搭。3.3 第二步子域名枚举与存活探测有了种子就可以做子域枚举了。我的建议是被动优先、主动补充、递归有限。被动方式先跑一遍证书透明度日志、公开被动 DNS 数据集、页面资源提取、搜索引擎结果。这一步几乎不产生直接请求风险最低产出通常能占到总量的六七成。主动字典枚举放在后面作为补充用来覆盖那些从没签发过证书、也没被公开记录过的内部子域。字典的选择直接影响产出效率。中文环境下高频前缀有明显的行业特征我把常用的整理成几类类别常见前缀说明业务门户portal、sso、oa、mail、home命中率高优先环境标识dev、test、uat、stage、pre、beta测试环境常暴露问题管理入口admin、manage、console、dashboard价值高但风险也高接口与文档api、open、gateway、doc、swagger常用于排查暴露面静态与资源static、cdn、img、file、upload辅助判断资产归属历史遗留old、bak、temp、v1、v2常常是无人认领的资产递归深度我建议控制在两到三层。比如api.dev.example.com这种从example.com枚举到dev.example.com是第一层再往下枚举dev下的子域是第二层。三层以上产出增长很快但有效率急剧下降而且请求量会成倍放大。实测下来两层的性价比最高。存活探测这一步插件的做法通常是发一个请求看响应。判断存活的依据不能只看状态码200 是活301/302 也是活401/403 同样是活只是需要认证甚至 500 也可能是个真实存在的有问题的系统。真正要排除的是 DNS 解析失败、连接超时、以及泛解析产生的假结果——这个坑后面单独讲。3.4 第三步端口与指纹识别存活确认之后进入信息提取阶段。这一步的目标是把这是一个域名变成这是一个什么系统。端口探测的范围要克制。全端口扫描在插件形态下既不现实也不合适通常是拿一份常见端口清单Web 类的 80/443/8080/8443数据库类的 3306/6379/27017远程管理类的 22/3389再结合页面特征做针对性补充。这里有个重要认知端口开放不等于服务可用很多云环境安全组配置了只放行特定来源你从外部探测看到的关闭不代表内部不可达反过来开放也不代表服务真的在跑可能只是一个负载均衡在前面挡着。指纹识别在插件里通常是自动完成的读取响应头、Cookie 名、页面 title、favicon 哈希跟内置的特征库做匹配。我要提醒的是版本号的处理。有些系统会在响应头或页面里暴露精确版本号这些信息对资产梳理的价值是判断资产新旧、是否需要重点关注但它同时是敏感信息台账里记录时要控制范围只在内部流转不要出现在任何对外交付物里。指纹结果的用法是聚类。把 favicon 哈希相同、响应头特征一致的资产归成一组组内选一个代表做深入核验比一个个看效率高得多。我在一个项目里用这个方法把两千多条原始记录压缩成了不到一百个技术栈分组后续核对的工作量直接降了一个数量级。3.5 第四步资产归集、台账落地与复核扫描做完真正的工作才开始。原始结果是一堆无序的记录必须经过归集才能变成可用的台账。归集的动作按顺序是归一化 → 去重 → 分组 → 标注 → 复核。归一化和去重前面讲过这里说分组和标注。分组有两条主线。一条是技术分组按指纹、favicon、响应特征聚类目的是找出同一批部署的资产。另一条是业务分组按域名前缀、页面内容、归属线索分组目的是把资产挂到业务方名下。两条线交叉才能形成这个业务用了这套技术栈、部署在这批 IP 上的完整图景。标注阶段要敢于写待确认。我一般把结果分成三类明确归属的有直接证据、疑似归属的有间接证据、无法判断的。第三类不要硬塞原样交给业务方让他们认领。实践中经常出现的情况是业务方一看就说这个我们早就不用了这种信息比你自己猜一百次都准。复核环节我建议做抽样回访。从每个分组里随机抽几个手工再核验一遍确认工具的判定逻辑没有系统性偏差。抽样比例不用高百分之五到十就够但一定要做。我遇到过指纹库把某类通用框架全部误判的情况因为当时没抽样最后整份台账的技术栈字段都是错的返工量极大。4. 实操心得与参数细节让结果可用而不是好看4.1 字典与递归深度怎么配才不浪费请求字典这件事我的观点是小字典精跑好过大字典乱跑。一个两万行的通用字典跑完可能产生几万次请求产出几百个有效结果有效率不到百分之一而且很容易触发目标侧的限制。用一份两三千行、经过业务特征筛选的字典有效率能提到百分之五以上整体效率反而更高。字典要按目标定制。做法是先从被动来源拿到一批已知子域分析它们的前缀规律——比如这个组织特别喜欢用xxx-prod、xxx-test这种命名那字典里就把-prod、-test这种后缀组合加进去。这种从已知推未知的方式产出质量远高于盲目堆字典。递归深度控制在两层前面说过。这里补充一个细节递归要有边界条件。比如某一层枚举出的结果全部解析到同一个泛解析 IP那就应该立即停止这一层的递归因为再往下都是无效产出。插件如果能自动识别这种情况并提示会省掉很多时间。还有一个经验把高价值前缀单独跑一轮。管理入口、接口文档、测试环境这几类命中率不高但价值极高值得单独用一份小字典跑跑完单独人工看。混在大批量结果里很容易被淹没。4.2 并发、超时与误报控制插件形态下并发不能开太大。我的经验配置是并发 20 到 50单请求超时 3 到 5 秒DNS 解析超时单独放到 5 到 8 秒。DNS 超时要比 HTTP 长因为很多解析失败其实是解析慢超时设短了会产生大量假阴性。误报控制的核心是泛解析检测。做法很简单随机生成几个不可能存在的前缀去解析主域如果这些随机前缀都能解析成功说明这个域配置了泛解析那么所有枚举结果都要打上问号必须靠响应内容进一步区分比如响应体长度是否一致、返回页面是否完全相同。这一步不做结果里可能有八成都是假的。另一个误报来源是默认页。很多服务器对任意子域都返回同一个默认页面状态码 200、内容一模一样。处理方式是对比响应体指纹如果一批结果的响应体完全一致就归为默认页单独标注。还有一个细节是重定向链。一个子域解析成功、返回 301 跳到主站这算不算有效资产我的判断是算但要标注重定向至主站因为它在 DNS 层面是独立存在的可能是遗留配置也可能是业务入口。区别对待不要一律剔除。提示所有速率和并发参数都不是固定的要根据目标系统的承载能力和授权约定动态调整。对核心生产系统宁可慢十倍不要出问题。4.3 结果导出与台账字段设计导出这一步很多人不当回事结果交付时被业务方退回重做。我的经验是导出前先想清楚谁来用这份表。给安全团队用的字段要偏技术IP、端口、指纹、暴露面判断。给运维用的字段要偏管理归属部门、责任人、状态、变更记录。给管理层看的只需要汇总数字和趋势。同一份原始数据导出三个视图比导出一份大而全的表更实用。字段设计上有几个具体的坑。一是多值字段的分隔符要统一多个 IP 用分号还是逗号必须全表一致否则后续做数据透视会出错。二是时间格式统一成同一时区同一格式不要一半是2024/1/5一半是2024-01-05 10:30。三是状态字段要有明确的取值枚举不能自由填写否则会出现在用使用中正常三种写法表达一个意思的情况。还有一点保留原始结果。归一化、去重之后的数据是用来交付的但原始数据一定要留档。后面出现争议、需要追溯某条记录是怎么来的只有原始数据能回答。我一般会把原始结果和加工结果分两个文件存文件名里带日期方便做历史对比。5. 常见问题与排查速查表5.1 高频问题实录做了这么多轮梳理问题其实高度集中。我把最常见的整理成一张速查表遇到问题先对一遍能省掉大半排查时间。现象最可能的原因排查与处理枚举出几千条结果绝大多数打不开域名配置了泛解析用随机前缀测试确认后改为按响应内容区分大量结果返回同一个页面服务器默认页比对响应体哈希相同的归为默认页单独标注同一个资产在表里出现多次未做归一化去重统一协议端口、去默认端口、去 URL 参数后重新去重指纹识别结果明显不对特征库匹配过于宽松抽样人工核验收紧匹配规则要求多特征同时命中扫描中途大量超时并发过高触发限速降并发到 20 以下加长超时分批执行插件结果与命令行工具不一致判定口径不同统一存活判定标准明确哪些状态码算存活部分子域能解析但访问无响应服务已下线但 DNS 未清理标注为疑似下线交业务方确认后清理证书里出现完全无关的域名共享托管或 CDN 共用证书不能直接纳入范围需结合其他证据判断导出表格打不开或乱码编码与分隔符问题统一用 UTF-8 带 BOM 导出 CSV结果无法挂到具体业务方缺少归属线索补充页面内容、备案信息等间接证据标记待确认5.2 避坑清单与合规红线除了技术问题还有几条是流程和合规层面的我觉得比技术问题更重要。第一条范围要写死在纸面上。我以为这个域名是我们的这种事在任何一次梳理里都不应该出现。范围清单要由业务方或资产归属方书面确认梳理过程中发现的新资产先标记、后确认、再纳入。第二条速率要克制。梳理不是压测大量请求打在生产系统上轻则影响体验重则造成故障。我见过因为扫描频率过高把一台老旧设备打挂的情况后续处理非常麻烦。低峰期、低速率、分批跑这是基本纪律。第三条敏感信息要控制流转。梳理结果里必然包含一些不该广泛传播的信息比如内部系统的地址、组件的版本、管理入口的位置。这些内容只在必要范围内流转交付物要做脱敏台账要控制访问权限。第四条结果要有人认领。一份没人认领的资产台账三个月后就会变成历史文件。每一轮梳理结束都要推动归属确认和责任人登记否则下一轮还得从头再来。第五条别把工具当答案。插件能帮你把信息收集的效率提高几倍但归属判断、风险定级、后续处置这些都得靠人。工具产出的是线索不是结论。最后分享一个我自己一直在用的小习惯每完成一轮梳理我会额外花半小时写一份变更说明记录这一轮相比上一轮新增了什么、下线了什么、哪些归属发生了变化。这份说明的篇幅通常不超过一页但它是整个台账真正产生价值的地方——资产管理的核心不是知道现在有什么而是知道什么在变。