1. 通用搜索引擎在安全场景里总是差一口气做了几年安全相关的工作我最大的感受是大部分人缺的不是工具而是检索思维。你打开一个通用搜索引擎输入一个域名翻十页出来一堆新闻稿、招聘信息和过期页面真正想要的这台机器上跑着什么组件、这个域名历史上解析过哪些地址、这个组织名下到底有多少个暴露在公网的入口一条都查不到。这不是你的问题是通用搜索引擎的索引模型就不是为这个场景设计的。网络安全领域的专业搜索引擎本质上是一批把网络空间里的机器、证书、代码、样本、历史快照重新做了结构化索引的检索入口它们解决的正是通用引擎搜不到、搜不全、搜不准这三件事。这篇文章我想做的事情很明确把散落在各个角落的三十来个检索入口按你实际会遇到的问题重新串成六条主线而不是甩给你一个收藏夹就完事。每一条线我都会说清楚三件事——这类平台索引了什么、用什么字段去过滤、什么时候该用它而不是用另一类。适合刚入门、手上有一堆域名和告警却不知道怎么下手的朋友也适合已经做了几年、但检索还停留在复制粘贴到搜索框阶段的朋友。文中所有平台我都用功能代号指代不绑定具体品牌你按描述去搜基本都能找到对应的那一家这样也避免了看完只记住几个名字、换个环境就抓瞎。提前说明一点下面所有检索动作的前提都是你有明确授权的范围。对自家资产、对客户书面授权范围内的资产、对公开可查的注册信息随便查对别人的系统做主动探测无论工具多温和都是另一回事。这条线我在第4章会专门拆开讲。1.1 通用索引的三个结构性盲区先把为什么不行讲透你才知道该往哪找替代方案。第一个盲区是索引粒度。通用引擎索引的单位是页面专业检索索引的单位是资产——一个 IP、一个端口、一张证书、一次 DNS 解析记录。粒度不同能回答的问题就完全不同。你问这个 IP 上开了什么服务通用引擎根本没有这个概念。第二个盲区是时效与历史。通用引擎的缓存只保留很短一段时间而安全场景里恰恰经常需要三个月前这个域名解析到哪。这就必须依赖专门的被动 DNS 历史库和网页归档服务它们做的事情是长期留存、可回溯查询。第三个盲区是不可见内容。登录后的后台、非标准端口的服务、只对特定协议响应的设备通用爬虫压根不会去碰。资产测绘类平台则是主动做协议握手、抓 banner、提取证书把这些搜索引擎看不见的东西变成可检索字段。理解了这三点后面三十个入口你就不会觉得是零散清单而是一张有逻辑的地图。1.2 专业检索平台到底在索引什么说白了这一类平台把网络空间拆成了几种可被检索的实体然后围绕每种实体建索引。常见的有这么几类实体主机实体IP 端口 协议 banner 组件指纹、域名实体含子域名、历史解析、注册信息、证书实体证书透明度日志里的每一张证书含组织名、签发者、序列号、代码实体公开仓库里的文件内容与提交历史、样本实体文件哈希、行为报告、通信特征、快照实体某个 URL 在某个时间点的内容。关键在于这些实体之间是可以互相跳转的。你从一张证书里的组织名能反查到一批域名从一批域名能查到解析过的 IP从一个 IP能查到同 C 段或同 AS 号下的邻居从一个页面的快照能还原出它当年引用了哪些外部资源。这条跳转链才是专业检索真正的价值单一平台再强也只是链条上的一环。所以后面我在讲每一类平台时都会特意点出查完之后下一步该去哪。2. 把三十个入口压成六条检索主线清单类的文章最容易写成收藏即学会我不太想那样。这一章我按你手头的问题类型来分组每组里给出具体的入口编号和用法。总共三十个编号连续方便你对照着一个个试。2.1 资产测绘线从知道一个域名到摸清一片家底这是使用频率最高的一类。核心能力是给定一个筛选条件返回全网匹配的主机列表附带端口、协议、组件版本、响应头、证书等信息。全量设备指纹测绘引擎支持按协议、端口、组件名与版本、响应头特征组合过滤是资产盘点的第一入口。偏重 Web 侧特征的测绘引擎对 HTTP 响应体、标题、图标指纹的提取更细致适合找同类 Web 系统。面向物联网与工控协议的测绘引擎对非 HTTP 协议的识别率高做暴露面自查时必用。带历史快照的测绘引擎能看某个 IP 在过去某个时间点的开放端口做什么时候开始暴露的这类判断很有用。按 AS 号 / 网段聚合的视图工具把资产按归属网络聚合适合快速判断这个组织的资产大致分布在几个网段。具体怎么用举个我常用的套路拿到一个主域名后先不急着爆破子域名而是先去测绘引擎里用证书字段反查——很多组织给内部系统签的证书里会带上组织名用组织名一搜往往能捞出一批没在任何地方公开过的子域名。这一步的收益经常比字典爆破高得多。第二个高频技巧是图标哈希聚类。同一套系统部署在不同机器上favicon 往往完全一致。把图标的感知哈希或 MurmurHash 算出来作为检索条件能把散落在不同 IP、不同域名下的同一套系统一次性捞出来。做资产归属判断时这招比看页面标题靠谱得多因为标题可以改图标经常没人管。这类平台的共同限制是结果只代表某一时刻的快照。端口会关、服务会换、证书会续。任何结论都要标注采集时间别拿三个月前的快照去证明今天的状态。第三个技巧是组合收敛。单独用port:8443会返回海量结果加上country或org限定就收敛到可人工核实的量级。新手最容易犯的错就是条件给太少翻两页就放弃其实只要多加一个字段结果集能从几十万降到几百。2.2 情报核验线把一条 IOC 变成一条可追溯的证据链告警里甩给你一个 IP 或一个域名你要回答的是它是什么、谁在用、有没有历史劣迹。这条线的作用就是把孤立的指标变成有上下文的证据。多引擎信誉聚合查询一次查询同时看几十个引擎的判定结果重点不是看多少家标黑而是看判定分歧——分歧大的往往是最需要人工看的。被动 DNS 历史解析库查某个域名历史上解析过哪些 IP、某个 IP 历史上承载过哪些域名。做同一团伙复用基础设施的判断这是核心工具。域名注册信息查询RDAP 接口结构化程度比传统 WHOIS 高适合批量拉取。注册信息反查工具按注册邮箱、按注册人、按名称服务器反查域名做团伙归集时非常有效。IP 归属与路由信息查询查 AS 号、所属网段、路由宣告情况判断一个 IP 是家宽、IDC 还是移动网络。威胁情报共享平台的公开查询页查样本哈希、域名、URL 的社区标注注意看标注时间和标注者老标注参考价值会衰减。URL 与文件的多引擎扫描入口提交前先查哈希有没有现成报告能省掉大量重复劳动。这里有个经验值得单独说别只看是否恶意这个二元结论。真正有用的是时间线。一个域名如果三年前被标过、最近一年干净和一个域名上个月刚被标处置优先级完全不同。所以我在查被动 DNS 的时候习惯把解析记录按时间排序看它和哪些 IP 有过交集窗口这个窗口往往就是活动期。另一个细节是注册信息的指纹。同一批人注册域名即使换了邮箱也常在名称服务器、注册商、注册时间分布上留下痕迹。我做过一次归集最后靠的是同一组名称服务器 注册时间集中在同两天这个组合条件比单看邮箱命中率高不少。这类反查工具的字段支持程度不一用之前先看它文档里支持哪些反查维度。2.3 代码与配置线从公开仓库里捞出不该出现的东西这条线在自查场景里价值极高——很多泄露不是被攻击导致的是自己把配置提交上去了。主流代码托管平台的站内搜索支持按文件名、扩展名、语言过滤部分支持正则。跨平台的代码搜索引擎一次覆盖多个托管平台适合做广度排查。带提交历史检索的入口能搜到已被删除但仍在历史里的内容这一步最容易被忽略。依赖包与组件仓库的搜索入口查某个组件版本是否真实存在、发布时间、是否有已知问题。配置模板与基础设施代码的检索入口找同类部署方式的参考实现做配置比对。自查的正确姿势是这样先用filename:.env这类条件限定文件类型再叠加组织特有的关键词比如内部域名后缀、内部项目代号最后限定时间范围。为什么必须限定时间因为不加时间条件返回的往往是几年前的公开教学示例噪音极大。一个我踩过的坑搜索结果里显示匹配点进去可能是空文件或者示例占位符。不要看到文件名就下结论一定要打开看实际内容否则误报率能高到 70% 以上。还有一个容易被忽略的场景提交历史。有人发现提交错了直接把文件删掉再提交一次以为就没事了。实际上历史记录还在搜历史依然能搜到。所以自查清单里必须包含历史提交扫描这一项而不是只看当前 HEAD。这一条我建议写进任何一次代码仓库安全评审的固定项。2.4 证书与 DNS 线旁路验证资产的真实归属这条线是我个人最喜欢的因为它绕开了你得先知道域名这个前提。证书透明度日志是公开、只追加、不可篡改的只要一张证书被签发过它就在里面。证书透明度日志检索入口支持按域名、组织名、签发者、时间范围查询返回证书详情与关联域名。按组织名反查证书的工具给定一个组织名列出所有证书里含该名称的域名做资产发现极其高效。证书链与指纹查询工具给定证书指纹反查使用该证书的主机。子域名被动收集平台聚合多个被动数据源不主动发包安全且快。DNS 记录批量查询与比对工具查 A/AAAA/CNAME/MX/TXT 等多类记录TXT 记录里常有验证信息可反推第三方服务。区域传输与公开区文件查询入口少数配置不当的域名会暴露区文件属于被动可得信息。用证书反查组织名这一步我要多讲两句。很多组织的证书申请流程是集中管理的签发时会把组织名填进去。这意味着你只要知道组织名的准确写法就能一次性拿到它名下大量域名包括那些从没在任何页面上链接过的。写法上要注意中英文、全称简称、有无后缀通常要试几轮。我一般的做法是先从一个已知域名上查到证书里的组织名写法再拿这个写法去反查命中率会高很多。TXT 记录也是个金矿。很多第三方服务的域名验证是通过 TXT 记录做的记录值里会带服务商标识。所以查一个域名的 TXT 记录往往能推断出它用了哪些外部服务这在梳理影子资产时很有用。CNAME 同理指向的内部系统经常从命名上就能看出用途。2.5 漏洞与样本线从编号到影响面清单公开漏洞库检索入口按组件名、版本、编号查注意不同库的收录范围和评分口径不一样。组件版本与依赖关系的比对工具把资产清单里的组件版本和漏洞库做交叉生成影响面清单。多引擎样本分析平台提交文件或哈希看行为报告、通信特征、释放文件。样本行为规则检索入口按行为特征比如某个注册表路径、某个进程注入方式反查样本属于从行为找家族。公开的恶意基础设施跟踪列表社区维护的域名/IP 清单适合做规则补充但要定期核对时效。这条线最容易出的问题是版本号匹配失真。漏洞库里写的是某某组件 1.2.0 之前存在某问题而你的资产上抓到的 banner 可能只显示1.2甚至有厂商自己改过后缀。这时候直接匹配会漏报或者误报。我的做法是把 banner 里的版本串先做归一化再和漏洞库的版本区间做区间比较同时把无法确定版本的单独列一档人工复核别硬塞进安全或不安全。样本分析那边有个实用习惯先查哈希再决定要不要提交。同一个文件很可能已经被别人传过几十次了直接看已有报告能省时间也避免把自己的分析行为暴露成可观测信号。查不到再提交提交时注意别把敏感的业务文件名带上去。2.6 元数据与归档线找那些已经消失的页面网页归档与历史快照服务按 URL 查历史版本做内容被改过的取证非常有说服力。文档元数据检索入口部分搜索引擎支持按文档属性检索能看到创建工具、作者字段等信息。归档服务的用法不只是看旧版页面。我常用它做三件事一是确认某个页面在某个时间点是否存在这直接影响事件时间线的判定二是看页面引用了哪些外部资源旧版页面里的第三方脚本往往能揭示当时用的服务三是对比改版前后的差异找出被悄悄删掉的内容。元数据这块要提醒一句很多人在发布文档前只删正文忘了清属性。我见过最典型的情况是一份公开版报告里作者字段和修订记录还完整保留着。自查的时候文档属性、批注、隐藏工作表、修订历史这四项建议一起过一遍。3. 检索语法怎么练从关键词到结构化查询三十个入口如果只会往搜索框里贴一个域名那等于没用。这一章讲语法层面的东西这部分是能跨平台迁移的。3.1 一份可以直接抄的查询模板我自己的习惯是把查询拆成范围 特征 排除三段。范围决定搜哪特征决定搜什么排除决定去掉哪些噪音。写成模板大概是这样范围条件 site:目标域 或者 org:组织名 或者 asn:号码 特征条件 组件名/版本 或者 port:端口 或者 title:关键词 排除条件 -示例 -demo -test -转载举个实际的例子想找某个组织暴露在公网的运维类入口可以先限定组织或网段范围再用端口和标题特征收窄最后把明显是示例页面的词排掉。这样一轮下来通常只剩几十条人工看十分钟能过完。通用语法里site:、inurl:、intitle:、filetype:这几个是基本功。inurl:特别好用因为很多后台路径的命名是有规律的改不了。filetype:在找配置、日志、备份类文件时命中率高但同样要注意第2.3节说的搜到不等于有价值。语法层面最常被忽略的是否定条件。不会用减号你的结果集会被示例、教程、镜像站淹没。养成习惯第一轮搜完看一眼噪音来源立刻把高频噪音词加成否定条件再搜一次。3.2 收敛策略先广后窄还是先窄后广这两种顺序适用于完全不同的场景混用会浪费时间。先广后窄适用于你还不确定目标长什么样的探索式检索。比如刚接手一个不熟悉的组织先看它资产的大致分布再逐层收窄到具体系统。好处是不会因为一开始条件太苛刻而漏掉整个方向。先窄后广适用于应急响应你已经有一个明确的 IOC。这时候不要一上来就全量搜先用最精确的条件确认这个 IOC 的基本属性再逐步放宽到 C 段、到同 AS、到同证书一圈圈往外扩。这样每一步都能说清楚我为什么放宽到这一层证据链是清晰的。我见过最常见的浪费是应急场景下用探索式的思路一上来就大范围搜搜出海量结果不知道怎么筛或者探索场景下用应急思路死抠一个精确条件结果什么都找不到。判断标准很简单——你手头有没有一个可信的锚点。有锚点就先窄后广没锚点就先广后窄。3.3 时间维度最容易被浪费的过滤条件几乎所有专业检索平台都支持时间过滤但用得好的不多。时间条件至少有三个用途一是去掉陈年噪音。搜代码时限定最近一年能过滤掉大量早已修复的示例。二是锁定活动窗口。查被动 DNS 时把解析记录按时间排开找那个突然新增一批解析、又在某天集体消失的区间这个区间往往就是基础设施的活跃期。三是验证状态变化。想知道某个端口是什么时候开的用带快照的测绘引擎对比两个时间点就行。这个结论在做暴露面趋势分析时很有分量比当前开着这一句信息量大得多。需要提醒的是不同平台的时间字段含义不一样有的是采集时间有的是证书签发时间有的是首次发现时间。用之前一定看清楚它标的是哪个我用过一次把证书签发时间当成采集时间结论直接错了。4. 我踩过的坑误报、越界与判断失准这一章可能比前面三十个工具更值钱。工具用错顶多浪费时间判断用错是要出事的。4.1 把扫到了当成存在的三个后果第一个后果是误报入库。测绘引擎的指纹识别是基于规则的规则会误判。我遇到过一次某平台把一个普通 Web 服务识别成了某款管理面板原因是响应头里有个字段名撞上了。如果直接信了就会给客户报一个不存在的风险。第二个后果是归属判错。同一个 IP 上可能有几百个虚拟主机也可能这个 IP 属于云服务商而不是目标组织。只看 IP 归属就下结论这是目标的资产是最典型的错误。正确做法是至少要有两个独立证据指向同一归属比如证书里的组织名 页面上的一致性标识或者 CNAME 指向目标的域名体系。第三个后果是状态过期。三个月前的快照说端口开着今天可能早关了。任何对外输出的结论都必须带采集时间并且建议在关键节点做一次实时复核。我的固定做法是任何一个结论进报告前至少用两个不同数据源交叉验证一次。两个源说法不一致的单独列出来标注待确认绝不当成结论写。4.2 授权边界的自我检查清单这件事没法含糊。每次动手前我会在心里过一遍这几个问题这个资产是不是在书面授权清单里清单有没有过期我做的动作是被动查询查公开索引、查历史记录还是主动探测发包到目标两者门槛完全不同。探测的强度会不会影响业务有没有可能触发对方的防护或产生大量日志结果会存在哪、谁能看、多久后销毁被动查询的边界最清晰——查的都是别人已经公开索引过的信息不向目标发包。这也是我为什么在整篇文章里更推崇证书反查被动 DNS归档快照这类手段信息量够且不越界。主动探测只在明确授权且有必要时才做并且要控制频率。还有一个容易忽略的点别把别人的公开数据当成自己的成果。引用第三方平台的数据要标明来源和采集时间这不只是规范问题也是让结论可复现的前提。5. 把检索变成流程巡检与应急两条落地路径工具会用了语法也会了接下来是把它们固化下来。零散地用价值有限变成固定动作价值才稳。5.1 每周固定跑的几条查询我给自己的巡检清单大概四五条每周跑一次每次二十分钟左右巡检项检索方式关注点新增暴露面按组织名反查证书与上周结果做差集新出现的域名是否为计划内上线非标端口开放按网段范围 排除已知端口意外的端口暴露代码仓库泄露组织关键词 配置文件类型 近七天新增提交里是否有敏感信息证书到期按域名查证书有效期提前三十天预警关键在于做差集。单次检索的结果没有意义和上一次比才有意义。我一般会把结果落成一个简单表格按资产标识做主键每次覆盖写并保留历史版本这样新增消失变化三种状态一目了然。差集里消失的那部分经常被忽略其实很有价值——一个域名突然从证书日志里没了、一个端口突然关了可能是下线也可能是迁移值得问一句。5.2 拿到一个陌生域名的六十分钟排查链路应急场景下我会按这个顺序走每步控制在十分钟以内0-10 分钟查注册信息与被动 DNS确认归属、注册时间、历史解析。这一步决定后面往哪个方向查。10-25 分钟证书反查把关联域名拉出来判断资产规模。25-40 分钟取几个关键 IP 做测绘查询看开放端口和组件指纹标注异常项。40-50 分钟查情报平台的判定与时间线重点看最近三个月。50-60 分钟归档快照看页面历史内容确认是否有过改版或内容替换。这个顺序的设计逻辑是从低成本高确定性的信息开始。注册信息和被动 DNS 几乎必然有结果能快速建立基本认知证书反查是扩展主动测绘放中间因为耗时且需要授权确认情报和归档放最后作为补充证据。反过来做先扎进测绘里很可能查了半天才发现方向就错了。6. 几个让效率翻倍的细节习惯最后一章讲点零碎但实用的东西都是踩过坑之后形成的习惯。6.1 结果必须落库否则等于没查我早期的毛病是查完看一眼截图存到某个文件夹里过两周完全找不到。后来改成统一落表字段固定为资产标识、来源平台、采集时间、关键属性、判定结论、证据链接。看起来麻烦但真有价值——第二次遇到同一个资产时你能立刻看到上次是什么时候查的、当时是什么状态这个对比信息比重新查一遍有用得多。去重也很关键。多个平台的数据会大量重叠我一般用IP 端口 证书指纹作为联合主键去重因为这三个字段组合起来基本能唯一确定一台主机上的一套服务。只用 IP 去重会把多端口的情况合并掉只用域名去重则会漏掉 IP 直连的资产。6.2 翻页深度和语言参数里的隐藏限制这两点很少有人提但影响很大。翻页深度大部分专业检索平台对免费查询有结果数上限而且往往不是返回前 N 条而是总共只让你看 N 条。这意味着如果你的查询条件返回十万条你只能看到其中很小一部分而且不一定是按相关性排的。解决办法是把大查询拆成多个小查询按时间切片、按网段切片、按端口切片每个切片的结果都控制在上限以内。语言与地区参数同一个平台在不同地区节点上的索引覆盖可能不同尤其是 Web 类测绘抓取节点分布会影响你能看到什么。做覆盖率评估时如果只用一个节点结论会偏乐观。这一点在做我们的资产到底暴露了多少这类自查时特别重要因为漏掉的恰恰可能是最该发现的那部分。还有一个我吃过亏的细节结果里的时间字段可能是最后更新时间而不是首次发现时间。用错了你会把一台老资产判成新上线的。现在我养成习惯第一次用某个平台先拿一个自己完全了解的资产去试一遍看它的各个时间字段分别对应什么再正式用。这个验证步骤花十分钟能避免后面一堆返工。说到底这三十个入口本身没有哪个是不可替代的真正拉开差距的是你知道什么问题该找哪类索引、拿到结果之后知道下一步往哪跳、以及有能力判断这个结果到底靠不靠谱。我见过工具用得极熟但结论经常翻车的人也见过只用三四个平台但判断极准的人差别全在后面这两件事上。工具清单可以收藏但那张跳转地图得自己走几遍才长得出来。