搞安全评估这些年我一直觉得“信息收集”这个词被说小了。很多人以为它就是把端口扫一遍、目录跑一遍然后拿着报告去交差。实际上在我经历过的授权测试里八成的突破口都不是靠某个攻击工具打出来的而是靠“多收集到的那一层信息”自然生长出来的——多到的那个子域名可能带出一套旧测试系统多到的那个指纹可能直接告诉你后台用的什么框架多到的那份源码泄露可能把数据库口令摊在你面前。所以这篇东西我不打算罗列工具清单而是把子域名、端口、指纹、目录、源码泄露、人员信息这六个维度串成一条完整的行动线讲清楚每一步为什么做、怎么做、最容易在哪里翻车。这篇内容适合正准备做一次系统性的授权安全评估的朋友也适合运维侧想把自己业务“摸清楚”的同行。我不多说理论尽量给可以直接复用的命令、参数和踩坑记录。1. 先说思路信息收集到底在收什么1.1 六个维度是“漏斗”不是一份清单网上很多文章会把信息收集拆成十几个并列模块看着很全但真正做项目时你会发现这六个维度其实是一条漏斗链路先从域名打开拿到一批子域名子域名解析出IPIP上扫出一堆端口端口背后跑着不同服务服务的特征形成指纹有了指纹就能判断接下来该挖目录还是看源码源码泄露能直接带出配置和人员信息。层层收窄一步一步靠近核心资产。我个人的习惯是把这个漏斗画在笔记里哪怕不画图也要在脑子里过一遍。比如你拿到了一个域名第一步不是急着用扫描器而是先问它有哪些子域名子域名里哪些解析到云资产、哪些解析到内网映射这些IP上开了哪些端口端口上的服务版本是什么只有顺着这个顺序往下走后面每一步才不会被噪声干扰。还有一个容易忽略的点目标范围会直接影响你该收集到哪一层。如果授权范围写的是单个IP那子域名收集意义就不大直接进入端口和服务识别。如果范围是一整个域名那子域名就必须做全。很多人一上来就把甲方给的域名丢进字典爆破结果客户主域名做了CDN扫到的全是CDN节点报告写得再厚也没有实际参考价值。1.2 必须放在开始前的边界问题这一段我必须先写因为信息收集本身是一把双刃剑。任何一个扫描器、目录枚举工具、源码下载脚本都有可能对目标造成不可逆的影响无论是产生大量请求把业务打挂还是把不该下载的敏感文件拉下来。所以无论你是什么身份动手之前一定要确认三件事一是有没有拿到书面授权二是授权范围是不是覆盖你即将扫描的IP和域名三是测试时间窗口是否允许高强度扫描。没有授权的信息收集就叫非法入侵这一点没有商量余地。后面我写的所有命令和方法默认都只用于你拥有合法测试权限的资产或者你自己搭建的靶机环境。做安全评估和搞破坏的区别往往就在这条边界上。2. 子域名从入口到更多入口2.1 子域名的三种来源子域名收集不是靠单一手段就能做全的我通常会分成三类来源交叉验证。第一类是证书透明度日志。这是最稳定、最省力的来源几乎所有HTTPS站点都会给域名签发证书而证书签发记录会公开保存在日志服务器里。只要查一下某个根域名下的证书记录就能看到历史上所有申请过证书的子域名。这个方法的优点是覆盖面广很多年代久远、已经下线但仍解析到资产的子域名都能翻出来非常适合用来找“被遗忘的入口”。第二类是DNS主动枚举也就是大家常说的爆破。通过字典生成一批可能的子域名前缀然后逐个查DNS解析记录。这个办法的覆盖率完全取决于字典质量所以我会把通用字典和从目标官网、招聘信息、代码托管平台里提取的关键词结合起来效果会比单跑一个通用字典好很多。第三类是被动搜索包括通过搜索引擎、代码搜索平台、网盘、历史快照等渠道收集已经被公开记录过的子域名。这类来源经常能捡到一些人已经提交在公开页面上的内部地址价值往往比爆破来的更高。2.2 用证书透明度日志批量捞子域名这里给一个最直接的查询方法我平时几乎不打开浏览器去翻证书平台页面都是用命令行拉下来处理。以目标域名target.test为例curl -s https://crt.sh/?q%25.target.testoutputjson | jq -r .[].name_value | sort -u注意这个命令里%25是URL编码后的通配符%含义是匹配所有*.target.test的证书记录。输出结果会包含形如a.target.test、b.target.test的记录也可能带上一些重复或带通配符的记录需要再清理一下。我一般会配合sed把*.target.test这类通配符记录里的星号去掉只保留实际子域。拿到这批结果之后最重要的不是整理成表格而是立刻做一次“存活确认”。很多证书记录对应的子域名早就删除了解析记录直接扫会浪费大量时间。确认存活最快速的办法是用批量解析工具也可以写一个简单的循环调digwhile read sub; do if dig short $sub.target.test | grep -q [0-9]; then echo $sub.target.test fi done sub_list.txt2.3 子域名防误报的几个细节关于“ip子域名大全”这类检索词网上确实有很多整理好的大字典但我的体会是字典可以当概率参考不能直接当结论用。实际环境中泛解析是最大的误报来源。有些DNS服务商为了防盗爬虫会把所有不存在的域名统一解析到一个相同IP上比如不管输入xxx.target.test还是yyy.target.test返回的IP都是同一个。这时候如果你不做IP去重扫报告里会混进一大片根本不存在的“子域名”。所以我在子域名确认阶段会做两步过滤第一步看解析出来的IP是否完全相同如果一批域名指向的是同一个IP就得怀疑泛解析第二步对解析结果做历史对比如果某个子域名在证书日志里出现过但现在已经不再解析到任何IP那大概率已被下线。另外一个容易被忽略的点是子域名接管漏洞。当你发现一个子域名解析到了某个第三方服务商比如对象存储、代码托管页、CDN服务但对应的存储桶或资源已经被释放那么攻击者可以直接重新注册这个资源从而获得这个子域名的控制权。收集阶段如果发现这类解析记录我会单独标记出来这比直接写进“子域名列表”重要得多。3. 端口与服务把“门牌号”扫明白3.1 为什么要做全端口很多刚开始接触扫描的朋友喜欢只扫个默认前1000个端口结果报告里就只见80、443、22这几个常见口看起来干干净净。但真实业务环境里真正有意思的服务往往藏在高位端口。比如某些公司把测试环境的Web页面挂在8080或8888把内部代码仓库挂在8443把数据库运维面板挂在随机高位端口。如果只扫常用端口这些全部会漏掉。我平时做端口扫描会分成两轮。第一轮只做全端口开放探测目的是搞清楚目标IP上一共开了哪些端口这个阶段不做服务识别保证速度。第二轮再针对第一轮发现的端口做详细的版本探测和脚本扫描。这样做的好处是第一轮压力小、速度快、不容易被误判为高频攻击第二轮有了明确的端口清单可以慢慢地、细致地识别服务不容易漏报。3.2 高效且稳妥的 Nmap 扫描命令Nmap 是端口扫描绕不开的工具但很多人只是习惯性地用nmap target这还远远不够。给你一套我实测下来比较顺手的组合# 第一轮全端口发现只探测开放状态不做版本识别 nmap -sS -Pn -n -p- --min-rate 1200 -T4 192.0.2.10 -oA full_port # 第二轮对已发现端口做服务识别和默认脚本 nmap -sS -Pn -n -sV -sC --version-light -p 22,80,443,8080,8443,9090 192.0.2.10 -oA service_scan这里每个参数都有它的意义逐个说明一下。-sS表示SYN半开扫描速度快、相对不容易在目标系统上留下完整连接记录但在没有root权限的某些环境会失败那就得换成-sT全连接扫描。-Pn表示跳过主机存活探测因为很多服务器会屏蔽ICMP报文你不加这个参数明明端口开着也会被判断成主机“不可达”。-p-表示1到65535全端口--min-rate控制发包速率不能一味求快否则容易触发目标机房的风控。第二轮里的--version-light是让Nmap在版本探测阶段适度降低耗时的选项适合端口数比较多的时候用。我自己在实战里很少一上来就加-A因为-A会把操作系统指纹、版本探测、默认脚本全部打开单个目标还行一旦端口多就会慢到怀疑人生。第二轮已经知道端口范围了再针对性地带上脚本才是效率最优解。3.3 常见服务的默认端口要心里有数不管扫描器多智能你要是不知道目标服务常用的默认端口扫出来一堆数字也看不出重点。这里列一个我经常对照的表都是实际环境里非常容易踩到的高频服务服务类型默认端口备注Web HTTP/HTTPS80 / 443也可能藏在任意高位端口SSH / RDP22 / 3389常见远程管理入口MySQL / PostgreSQL3306 / 5432数据库服务一般不对外Redis6379未授权访问高发端口Elasticsearch9200 / 93009200为HTTP接口Kibana5601可视化面板Jenkins8080很多构建系统会暴露Nacos8848注册中心配置文件易泄露Docker2375未加密的Docker远程API端口HBase16010 / 9090 / 909516010是HMaster Web UI9090为客户端接口MLflow5000机器学习平台实验管理界面有些服务还会把端口写成参数比如常见授权管理软件的SNL服务默认端口是25734这类业务端口通常不会出现在标准的“常用端口”表里但只要你在目标的主机名或证书信息里看到相关软件名称就可以反查对应的默认端口。端口和服务永远要配套着看单独记端口意义不大。3.4 端口被占用怎么查才是真需求这个点本来跟信息收集关系不大但我发现很多运维朋友搜“端口被占”“端口被占用”是卡在了部署这一步。当你往一台机器上部署新服务时如果报错提示端口被占用就要先找出占用进程。Linux下的命令很直接ss -ltnp | grep :8080 lsof -i :8080Windows上则是用netstat -ano | findstr :8080拿到进程PID再去任务管理器里确认是什么程序。还有一种更隐蔽的情况是端口看起来没有被占用但进程始终起不来这时候大概率是SELinux或系统防火墙拦截了监听动作需要去确认TCP端口的策略配置。做信息收集的时候偶尔也会遇到目标机上防火墙不响应、端口扫不出来的情况排查思路同样要从“服务是否真的在监听”“防火墙是否放行”“云安全组是否允许来源IP访问”这三层去查。4. 指纹识别让服务现出原形4.1 指纹信息从这些地方来端口扫出服务之后下一步就是搞清楚服务到底是什么、什么版本、有没有已知的历史漏洞。这个过程叫指纹识别。最基本的指纹来源是HTTP响应头。比如Server: nginx/1.20.1直接就告诉你Web服务器类型和版本X-Powered-By: PHP/7.4.33又给你一层应用语言信息。这些头字段不一定每个站点都有也不是每个管理员都会清理所以只要响应头里泄露了版本就必须记进笔记。然后是页面内容和路径特征。不同框架有自己独特的登录页面结构、Cookie名称、静态资源目录名。比如某些Java框架的管理后台默认会带有特定框架的版本号和启动横幅某些CMS系统在登录页HTML注释里会留下生成工具的标记。这些特征不需要把服务跑一遍只要用浏览器或curl看一眼源代码就能发现。4.2 favicon 哈希一个隐蔽的指纹特征很多工具和文章已经响应了“指纹”这个热词但我想重点讲一个不太起眼却很稳定的特征网站小图标也就是favicon.ico。很多站点会直接用框架自带的图标或者只是改了名称没改图标导致图标文件的哈希值和大量同类站点完全一样。只要算一次哈希就能用在线指纹库反查它属于哪套系统。计算favicon哈希最经典的办法是用Python代码很短import requests import codecs import mmh3 url http://target.test/favicon.ico r requests.get(url, timeout5) data codecs.encode(r.content, base64) hash_value mmh3.hash(data) print(hash_value)这里用到的mmh3是MurmurHash算法的Python库安装一下就能用。算出来的数字可以直接在网上的指纹聚合平台里搜索很多开源Web框架、中间件、物联网设备的默认图标都在数据库里。我实测下来这个方法对识别那些“隐藏了后台入口”的默认系统特别好用因为普通目录爆破可能爆破不到根路径但favicon.ico很多系统都懒得改。4.3 指纹识别常见的两个坑第一个坑是版本误判。响应头里的版本号不一定安全很多系统会故意把版本信息抹掉或者反向伪造一个假版本试图误导扫描者。不能只看一个特征就下结论至少要有两个以上的特征互相印证比如响应头关联路径特征、页面关键字关联Cookie名称才能把版本确定下来。第二个坑是概念混淆。有人说“指纹浏览器”这和Web应用指纹识别完全是两回事。浏览器指纹是通过读取浏览器的UA、屏幕分辨率、Canvas绘制特征、时区、字体列表等参数来唯一标识一台设备的技术通常用在反欺诈和防止批量注册场景中跟安全测试里的“指纹识别”不是一个维度。遇到术语的时候要先分清语境否则一讨论就容易鸡同鸭讲。5. 目录与源码泄露把隐藏路径和泄漏点一起找出来5.1 目录爆破怎么爆才高效目录爆破本质上就是拿着字典去“猜”站点上有哪些隐藏路径。它的速度不慢但效率差别很大。核心变量有两个字典质量、响应分析方式。字典质量直接决定你猜中的概率。我会把字典按场景拆成几类通用路径字典、备份文件字典、API路径字典、技术栈专属路径字典。比如目标是常见的PHP站点你就会需要在字典里带上/admin、/backup、/uploads、/config、/.git这些高频路径如果技术栈是某个特定框架就要补充对应框架的路由风格很多时候框架自带的/actuator、/console、/panel这类路径比通用字典里的路径更有效。响应分析是很多人容易忽略的地方。我见过有人爆破目录只看HTTP状态码200就留着404就丢结果把大量有实际价值的302跳转、403权限目录、405方法不允许全丢了。正确做法是先看全部的响应状态再把明确的404过滤掉对剩下所有状态码都做人工确认。推荐用这个思路的命令ffuf -u http://target.test/FUZZ -w paths.txt -mc all -fc 404 -rate 30 -t 10-mc all是要求显示所有状态码-fc 404是过滤掉确定的404后面的-rate和-t用来控制并发避免打爆目标。5.2 响应码语义与403细节别被假目录骗了目录爆破结果里有几类状态码特别值得琢磨。301和302代表目标路径存在跳转要顺着跳转地址继续跟进因为有些后台入口会从/admin跳到/admin/login也可能跳到另一个域名。403代表路径存在但被禁止访问这类路径很多人直接忽略但它恰恰可能是真正的敏感文件或管理目录只是当前访问方式不对。500和405也不该直接丢前者可能代表参数触发了逻辑错误后者说明路径存在但方法不允许往往需要换POST或PUT再试。关于“目录深度”我多说一句。爆破的时候字典覆盖深度很重要但盲目追求深层目录没有意义。实际业务里三层以内的目录概率远大于更深层目录。我会把字典分成普通深度和深层两部分先跑浅层如果发现某个路径下出现了动态参数再针对该目录做更深一层的爆破这样比一次性跑一个超级大字典更稳妥也更高效。5.3 .git 源码泄露的原理与下载方式“git目录泄露如何下载”是个非常经典的问题。原理其实很简单如果开发者在部署时把整个.git目录原封不动传到了Web根目录而Web服务又允许直接访问以点开头目录里的文件那么任何人都可以直接访问http://target.test/.git/HEAD查看Git仓库的核心结构。看到这里返回ref: refs/heads/master或者类似内容就说明源码仓库暴露了。仅仅确认还不行真正要做的是把整个仓库拉下来。推荐的工具是git-dumper它是一个专门把暴露的.git目录里的对象文件分批下载并重建仓库的脚本。git-dumper http://target.test/.git/ ./dump执行之后./dump目录下会生成一个完整的Git仓库你可以在里面执行git log查看提交记录git status查看当前状态甚至切到某个历史提交恢复已经被删除过的文件。很多开发环境里数据库密码、API密钥、云服务密钥都曾经被提交过后来又因为泄露被删除但只要仓库完整历史记录里依然能翻出来。需要特别强调的是这个操作会真实下载目标服务器上的敏感文件所以它的使用边界非常严格只能在你拥有授权的测试环境中做。不是你的目标不要碰。除了.git还有几种同类泄露也值得检查.svn/entries暴露SVN仓库结构、.DS_Store泄露当前目录的文件列表、web.config.bak、test.sql、db.sqlite3这类常见备份文件。目录爆破时把这些路径加进字典会提升不少命中率。5.4 从泄露信息到加固建议源码泄露的真正危险点在于“凭据复用”。我在实际项目里见过很多次业务系统本身防护做得挺严但源码仓库里却写着测试环境数据库地址、Redis口令、OSS密钥运维同学图省事直接写了明文。对于安全测试来说拿到这些信息不应该是终点而是要把它们写进整改报告。修复方法也要同步给出一是Web服务器配置里显式禁止访问所有以点开头的文件或目录二是构建部署流程里不要把.git目录包含进最终发布产物三是对生产环境做一次密钥轮换特别是有任何被历史提交记录的密钥全部作废重发。只有把漏洞、证据、修复建议三样一起交出去这份信息收集报告才算是有价值的。6. 人员信息与社交工程防范6.1 人员维度的常见公开来源人员信息收集也可以叫人员侧的开源情报是所有信息收集维度里最需要克制的一项。它的价值在于能帮助判断一个企业对信息的暴露程度以及员工在用什么样的真实信息注册公司的系统。常见的公开来源有这么几个一是公司官网和招聘页上面往往有公司统一邮箱格式、组织架构、关键岗位人员姓名和联系方式二是GitHub等代码托管平台员工如果在上面关联了自己的企业邮箱或提交过包含公司内部路径的代码就能找出企业技术栈线索这类信息完全公开但价值极高三是社交平台很多人会在公开简介里写公司名和职位形成一条清晰的人员关系链。在授权评估场景里人员信息的作用是辅助验证比如确认某个账号是否属于离职员工遗留、确认统一邮件命名规则是否能够被预测。它不应该被用来针对个人发起骚扰或威胁这不是安全测试的范畴而是违法犯罪。6.2 信息使用的边界信息收集到了一定程度最难的不是收集而是判断哪些信息可以用、哪些绝对不能用。我给自己定的标准是只记录和使用与资产直接相关、确实公开可获取的信息不收集身份证号、手机号等公民敏感信息收集到的个人信息不落库、不对外发布、不传播。报告里如果需要体现人员侧风险我一般只描述“企业邮箱命名规则是否可被猜测”“员工是否在公开平台暴露了内部系统关键词”而不是把某个真实员工的社交主页截图贴进报告。客观说人员信息收集这块最容易被误解和滥用。所以我始终建议安全团队把重心放在“如何防范钓鱼和社交工程”上而不是花力气去挖掘谁的个人信息。给员工的建议永远优先级更高企业邮箱和企业密码不要用于任何私人网站注册、不要随意公开GitHub账号关联企业信息、收到疑似内部邮件先电话确认。合规永远比技术能力值钱。7. 常见问题与避坑速查7.1 容易翻车的几个环节操作多了翻车点基本都是重复的那几个我随手列一下做信息收集之前先看一遍能少走很多弯路。场景常见问题原因与对策子域名大批量误报泛解析导致大量无效子域名对解析结果做IP去重确认是否存在统一IP返回端口扫不到主机在线但端口无响应检查是否启用-Pn确认云安全组和防火墙是否拦截来源IP服务版本识别慢Nmap版本探测时间过长先用全端口快扫后用--version-light扫描已知端口目录爆破结果惊数量巨大对302/403/405未处理用-mc all -fc 404先看全部状态再逐类人工确认指纹识别结果矛盾不同工具识别出不同框架至少取两个特征交叉验证不只看响应头.git 目录打不开服务器返回403确认是否有限制点目录的配置或换其它泄露入口.svn、备份文件防火墙规则开放无效端口规则已加但外部不通检查Linux防火墙和云控制台安全组两处规则是否都放行7.2 我自己的巡检清单收尾之前分享一份我每次做信息收集都会过的巡检清单基本就是一张白纸按步骤打勾。第一步域名侧是否收集了证书透明度、被动搜索、主动枚举三类来源是否确认过没有泛解析误报是否标记了可能接管的子域名第二步IP和端口侧是否做了全端口快扫是否对开放端口做了服务版本确认是否查看了常见业务组件的默认端口是否记录过访问控制规则第三步服务侧是否提取了响应头和页面特征的指纹是否算了favicon哈希是否确认了框架版本和已知漏洞的关联第四步目录侧是否做了合理的字典覆盖是否对所有状态码做了人工确认是否检查了.git、.svn、备份文件等源码泄露路径第五步人员侧是否仅使用了公开信息是否对敏感信息做了脱敏是否把结论落在了加固建议而不是个人身上这套清单不复杂但能保证你每一步都有据可查、不遗漏关键路径。信息收集这活儿靠的从来不是某个神器工具而是对每一步“为什么要这么做”想得足够清楚。我自己的体会是工具可以换、命令可以改但这套从域名到人员、从公开到深入、从收集到加固的思路才是真正值钱的东西。