1. 识别WAF/CDN先把它当成防御动作而不是进攻前摇1.1 一次应急响应让我彻底改观上次帮一位做电商的老客户排查线上异常流量刚进后台就看到源站带宽被打满数据库连接池反复超时。运维负责人非常确定地告诉我域名前面挂了WAF攻击应该进不来。但我随手敲了一条curl -I返回头里根本没有出现预期中的WAF节点信息再往CDN控制台一看才发现缓存配置早已失效所有请求都直连了后端公网IP。那次之后我意识到很多团队的“老大难”问题不是WAF规则写得不够多而是他们根本不知道自己域名前面到底跑着哪家CDN、有没有成功接入WAF、回源链路长什么样。WAF/CDN识别与特征分析在我这里首先是一套防御体检手段确认防护真的在、确认暴露面没有超出预期、确认攻击者能看到的指纹和你能看到的完全一致。1.2 同一个指纹攻防两端的用法完全不同同样一条响应头、一个证书信息、一段TLS握手特征攻击者拿过去是找最佳突破路径防守方拿过去则是确认暴露面、验证防护是否有效。攻击者想绕过WAF/CDN通常要先搞清楚前面那层是什么设备、什么版本、回源规则怎么配而防守方如果连这些信息都掌握不了那等于把自己的防线交给别人的认知水平来掌控。所以我把话放在前面本文讲的是识别方法不是教你去做任何绕过尝试。识别能力之所以有价值是因为你能在攻击者进行第一步踩点之前就先看清自己的网络结构然后去封堵、去收敛、去观测。真实攻防中防守方一旦比扫描器更早掌握指纹很多所谓的“绕过思路”在第一层就会被掐死。2. 能直接判定的指纹点HTTP头、错误页、DNS与证书2.1 HTTP响应头里那些不太起眼的字段绝大多数WAF/CDN设备在响应头里会留下自己特有的痕迹。我日常排查时第一件事就是把响应头完整抓下来逐字段看异常。下面这张表是几种常见特征注意我只写通用特征不绑定具体厂商方便你对照自己的域名做体检特征维度具体表现可能的判断方向Server头出现不太常见的自定义值或带有waf、edge、gateway字样前面可能挂了WAF或者边缘网关Via头包含cdn、proxy、ecs、cache等节点标识经过多层转发或CDN缓存节点X-Cache / X-Cache-Lookup返回HIT/MISS/BYPASS或带节点编号存在CDN缓存层Set-Cookie字段出现带产品特征的Cookie名如cf、ali、tx、bd开头大概率接入了对应云厂商或CDN服务X-Request-Id / X-Amz-Cf-Id节点为每个请求生成的唯一ID边缘节点或云上WAF的痕迹响应头顺序异常某些头字段被统一重排或额外插入时间戳中间层设备对流量做了改写这里要提醒一句任何单点特征都不能直接结案。有的自建Nginx也会自己加一个server: edge-nginx有的云厂商WAF默认不修改Server头只是通过透明代理转发。所以这些响应头只是线索必须继续组合验证。2.2 默认错误页面和拦截页是最诚实的暴露识别WAF/CDN时错误页往往比正常页面更有信息量。访问禁用路径、伪造请求头、触发WAF规则时设备会返回403或405很多设备默认拦截页面里会带产品名称、版本号甚至还有厂商技术支持入口。把拦截页改成统一的静态页面、404页面覆盖成业务风格是隐藏这类指纹的基础操作。但真正的问题在于很多团队在接入WAF后完全没改默认拦截页扫描器只要随机触发几个请求就直接知道前面是什么设备了。还有一种情况是错误页来自CDN而不是源站。比如源站超时、回源失败时CDN会返回自己的502页面页面里可能带节点标识和后端错误码。这类信息会直接暴露回源链路结构是需要第一时间收敛的。2.3 DNS记录与TLS证书的辅助证据只看HTTP还不够。DNS解析记录是另一个判定点如果域名解析结果是指向某个云服务商泛域名或CNAME别名那基本能确定前面有一层CDN反之如果A记录直接指向机房公网IP那就说明当前请求完全没有走CDN。TLS证书也很有价值。边缘节点证书的颁发者、证书链、SAN字段在实践中经常能看出来是哪家服务商的边缘网络。还有证书的签发时间变化一个域名如果突然从自签名证书变成带CDN节点标识的证书很可能刚完成CDN接入。不过证书和DNS都不能单独作为最终判断因为很多企业会做CNAME拉平、私有CA、自定义证书上传边界并不是那么干净。3. 一套可落地的识别流程三条命令加四轮比对3.1 第一轮用curl把响应头和请求链路抓完整我建议不要只敲一条curl -I那样会漏掉不少信息。习惯做法是把请求头、响应头、TLS握手时间、DNS解析时间全部打出来curl -sIL --max-time 10 https://www.example.com如果要看更细的耗时分布可以加-w参数curl -sI -w dns: %{time_namelookup}s\ntcp: %{time_connect}s\ntls: %{time_appconnect}s\ntotal: %{time_total}s\n -o /dev/null https://www.example.com这条命令能帮你快速判断前面有没有边缘节点如果TLS握手时间极短、total时间稳定在几十毫秒大概率是CDN节点在响应如果total时间波动很大、且TCP握手后直接进入了源站TLS证书那可能就没走CDN。一定不要忘记看返回头的顺序。部分WAF设备会在网关层统一插入头字段导致响应顺序和Nginx原生返回顺序不一样。这种细节肉眼多看不出来但批量比对时非常明显。3.2 第二轮用DNS解析记录和历史数据做判断拿到响应头之后再看DNS解析dig short www.example.com A dig short www.example.com CNAME nslookup -typeNS www.example.com如果CNAME记录指向某个CDN服务商域名那说明入口在CDN如果A记录直接是源站公网IP那就得警惕。还要注意看历史DNS记录很多攻击者会翻域名解析历史找源站IP防守方自己更应该提前查一遍有没有历史解析记录直接暴露源站IP有没有子域名解析到源站而没有经过CDN有没有邮件服务器、API域名、二级域名单独指向源站这类问题比WAF规则更致命。因为一旦源站IP被翻出来攻击者可以直接绕过入口防护往源站打而你在前面配再多规则都拦不住。3.3 第三轮用边缘节点和回源特征做交叉验证如果上面两轮还分不清就用“多区域探测”来判断。从两地、三地分别请求同一个域名观察响应头和时间特征不同区域的响应头里出现不同的缓存节点编号说明有CDN。同一资源在不同区域请求时返回内容一致但响应头中X-Cache状态不同说明缓存层在工作。如果无论从哪个区域请求返回的IP归属和证书都不变且延迟很高大概率就是直连源站。TTL也是一个参考点CDN边缘节点上的DNS TTL通常比较短回源链路切换频繁时TTL会被压到很短。但这不是绝对标准有的自建DNS也会配短TTL做容灾切换所以只能作为辅助信号。3.4 第四轮结合IP归属和证书做最终收敛最后一步是把前面拿到的IP、ASN、证书信息丢到威胁情报平台里看归属。人工识别时我常看三个维度IP段是否属于云厂商或CDN服务商的自有网段证书链中是否出现边缘节点专用的中间证书端口扫描结果是否为常见的CDN回源策略比如443/80开放但SSH不可达整个流程下来基本能确定一个域名前面是不是有WAF/CDN、用了哪家、回源链路是什么样。这里要强调合规底线所有探测行为只允许针对自己有权限的资产或者参与攻防演练时在授权范围内的目标。没有授权的识别和图探测是完全错误的做法。4. 识别完成之后把加固动作落到具体配置4.1 治本先把源站IP藏好我见过大量案例是源站IP本身就在DNS解析记录里公开着却还天天调WAF规则。源站IP暴露时WAF/CDN只能拦截到绕过你入口的这部分请求攻击者完全可以绕过前端防护直接往源站打流量。正确的做法是把所有业务域名、API域名、管理后台域名全部接入CDN/WAF。在源站防火墙、安全组、负载均衡访问控制里只放行CDN服务商的回源IP段。关闭源站公网入方向的非业务端口尤其是SSH、数据库、管理口。检查历史DNS记录和公开证书日志删除或下线曾经暴露源站IP的记录和资产。对源站IP做定期自检用外部探测确认它不再响应业务域名的请求。这不是一次性能做完的事。域名多、历史杂的团队最好用脚本定期扫一遍推送告警。4.2 治标把设备指纹从响应头和错误页上抹掉很多WAF/CDN设备默认会把产品特征留在响应头或拦截页中。攻击者识别出厂商和设备型号后至少能少走一大半弯路所以作为防守方你要让自己的入口看起来“没有特征”。实际操作时可以考虑这几类配置在Nginx/CDN边缘节点覆盖自定义Server头或者去掉不必要的响应头字段。把WAF拦截页、404页、502页改成和业务风格一致的自定义页面。关闭Debug模式和错误详情透传避免把后端的报错堆栈直接暴露给客户端。对静态资源URL中的业务签名、版本号做重写或做缓存计划。注意隐藏指纹不是为了“骗过所有人”而是为了提高攻击者的踩点成本。真实攻防中攻击者花在识别上的时间越长触发告警的可能性就越大你的溯源窗口就越长。4.3 把识别信号变成告警规则而不是事后补救识别能力真正的价值在于“攻击者刚踩点你就已经知道了”。所以在完成资产梳理之后最后一步是把它变成监控和告警。可以按这个思路配置对核心域名记录正常的响应头基线、TLS证书指纹、DNS TTL基线。对检测到指纹尝试行为时做频率统计比如短时间内连续触发多条不同路径的403、404或者请求头带着明显的探测工具特征。把边缘日志里源IP、UA、证书验证失败频次关联起来命中阈值就直接走工单告警。我见过很多团队做安全巡检只看WAF拦截日志却忽视了前端的“探测信号”。攻击者只要把请求伪装成正常访问WAF规则不一定触发但反常的频率和路径模式是藏不住的。这就是识别能力的延展价值。5. 实战中我踩过的误判和边界情况5.1 把对象存储当成CDN节点有一段时间我发现某个静态资源域名的Server头返回的像是对象存储产品特征配合响应头里的某些参数几乎可以确定前面挂的是CDN。但后来排查发现那个域名直接解析到了对象存储的全局加速域名本质上只是存储桶的默认域名根本没经过WAF。当时我把回源IP封了导致业务图片全挂整改花了一下午。这个误判的教训是单看一个响应头只能说明“这个域名存在某种中间层”不能说明“这个中间层就是CDN/WAF”。必须要结合DNS解析、证书、IP归属、回源逻辑综合判断。5.2 多层CDN嵌套带来的判断混乱另一个容易翻车的情况是域名前面不止一层CDN。比如A省流量走了边缘节点边缘节点再回源到另一家CDN最后才到源站。从客户端看只能看到第一层的节点标识如果只看一层就判断“已经接入WAF”很容易忽略源站前面的第二层防护根本没做好。现在一些大型业务喜欢做多云容灾或是在CDN之上再套一层负载均衡排查时一定要顺着CNAME链路逐层查下去直到确认最终回源目标。必要的时候直接看CDN控制台的回源配置比靠外部探测猜要快得多。5.3 关于“绕过”的认知误区与合规底线必须强调一点识别WAF/CDN本身是安全能力的一部分但只要试图利用这些特征去绕过防护性质就完全变了。在真实攻防、红蓝对抗中所有针对业务的绕过测试都必须有明确的授权和演练边界。没有授权任何探测、指纹识别、绕过尝试都可能是违规行为。我自己在带团队时给新人的要求是先学会把识别结果用在做防御加固上再谈攻防对抗。绝大多数人不需要掌握“怎么绕过”但每个人都需要搞清楚“自己有哪些防线、防线是否生效”。这条思路能帮你少走很多弯路。说实话识别这件事干得久了最大的感受是它很像换眼镜。戴上之后你能看清自己网站的流量是怎么走的、哪一层在挡、哪一层是空的。把基线保存下来重保前对比一次每次都能提前发现不少问题。如果你还没给自己的核心域名做过一次WAF/CDN完整体检建议现在就用上面的方法跑一遍结果大概率会出乎你的意料。