基于WebRTC的CC攻击防御：利用浏览器真实IP识别技术
摘要：# 当攻击者“装”成用户：聊聊用WebRTC揪出CC攻击真身这件事 这事儿我琢磨了好一阵子。 说实话，做网站防护这行久了，最烦的不是那种“大力出奇迹”的DDoS攻击——那种流量洪水，砸钱上高防IP、上清洗中心，好歹能扛住。真正让人头疼的，是那些**伪装…
当攻击者“装”成用户：聊聊用WebRTC揪出CC攻击真身这件事
这事儿我琢磨了好一阵子。
说实话，做网站防护这行久了，最烦的不是那种“大力出奇迹”的DDoS攻击——那种流量洪水，砸钱上高防IP、上清洗中心，好歹能扛住。真正让人头疼的，是那些伪装得特别像正常用户的CC攻击。
它们用一堆代理IP、秒拨IP，甚至用云函数、手机集群，模拟真人去刷你的登录页、搜索接口、商品详情。你一看日志，每个IP访问频率“好像”都正常，但服务器CPU就是100%，数据库连接池直接爆掉，真用户根本打不开。
更气人的是，很多防护方案这时候就露馅了。光靠IP频率限制？人家IP池深不见底。上验证码？用户体验掉一地，而且高级点的攻击机现在连验证码都能自动打。
那咋办？
最近跟几个做游戏和电商的朋友聊，发现他们开始尝试一种有点“反套路”的思路——不跟攻击者在代理IP的迷宫里捉迷藏了，直接想办法看到他们浏览器后面的“真实IP”。而这里面的一个关键技术，就是WebRTC。
一、WebRTC不是用来视频通话的吗？怎么还能“抓”IP？
我第一反应跟你一样。
WebRTC（Web实时通信）这玩意儿，大家熟悉是因为在线会议、视频聊天这些场景。它为了让两个浏览器能点对点（P2P）直接传音视频流，需要知道彼此的真实公网IP地址来建立连接。所以，浏览器在支持WebRTC时，会提供一套JavaScript API，允许网站（在用户授权下）获取到用户设备的真实公网IP（以及内网IP）。
这个“真实IP”，通常比你用 REMOTE_ADDR 在服务器日志里看到的那个IP要“真”。因为后者很可能是CDN的IP、代理服务器的IP、或者NAT网关的IP。而WebRTC探测到的，往往是用户设备直接连接互联网时，运营商分配的那个最终出口IP。
攻击者用代理IP发起CC攻击，但他浏览器本身（如果是通过浏览器发起的攻击）在运行WebRTC时，依然会暴露出这个“真实出口IP”。
这就好比，一个骗子用虚拟号码给你打诈骗电话（代理IP），但他手机本身的IMEI串号（真实网络身份）在通信底层协议里可能还是能被追踪到。WebRTC在这里，就相当于一个能读到这个“串号”的机制。
二、具体怎么用它来防御？思路其实挺“贼”的
原理听起来不错，但直接用在生产环境，可不能简单粗暴。我看了几个落地案例，总结出几种比较靠谱的玩法：
玩法一：在关键前置页面“埋针”
比如，你有一个登录页面 login.php 是CC攻击的重灾区。你可以在 login.php 加载时，静默（或告知用户后）执行一段WebRTC探测脚本。
脚本拿到一组IP（包括公网IP、内网IP、IPv6地址）。这组IP里，那个公网IPv4地址，我们称之为“候选真实IP”。
同时，你的服务器（或WAF）肯定能拿到这次HTTP请求直接来源的IP，也就是代理IP或者CDN边缘节点IP。
把这两个IP 关联起来，存入一个临时名单或风控数据库。关键逻辑来了：
- 如果同一个“候选真实IP”背后，在短时间内关联了几十上百个不同的“直接来源IP”（代理IP），那这事儿就极其可疑了。一个正常用户，怎么可能在几秒钟内用几十个不同的代理服务器来访问你的登录页？
- 这就基本可以判定，这个“候选真实IP”所属的设备或网络，正在发起代理池CC攻击。
玩法二：作为验证码的“前置过滤器”
很多网站会在怀疑时弹出验证码。但无差别的验证码体验很糟。可以把WebRTC信息作为触发验证码的一个高级维度。
比如，规则可以设置成：
- 频率规则：单个直接来源IP，每秒请求超过10次，弹验证码。（基础规则）
- WebRTC增强规则：单个“候选真实IP”，在5分钟内关联超过5个不同的直接来源IP，对其后续的所有请求（无论换什么代理IP）都提级验证，比如出更复杂的验证码，甚至直接要求二次授权。
这样，攻击者即使有海量代理IP，只要他浏览器环境暴露的“真实IP”被我们盯上了，他换再多“马甲”（代理IP）也会被重点关照。而正常用户，几乎不会触发这个规则。
玩法三：辅助IP信誉库建设
这个角度更长期。通过WebRTC收集到的“真实IP”与代理IP的映射关系，可以慢慢积累成一个IP关系图谱和信誉库。
比如，某个数据中心IP段（作为“真实IP”）频繁关联大量秒拨代理IP出来作恶，那这个数据中心IP段本身就可以被标记为高危源头。以后这个段来的任何访问（即使当时没检测到代理），都可以给予更高的安全风险权重。
三、别高兴太早，这招的“坑”和限制你得门儿清
聊到这儿，可能有人觉得找到银弹了。打住，这行里最怕的就是觉得有银弹。 WebRTC这招，好用，但限制也不少：
- 它不是100%能拿到IP：防火墙设置、浏览器插件（如WebRTC屏蔽插件）、某些安全软件、甚至浏览器本身（Safari的某些版本默认设置）都可能阻止WebRTC获取IP。所以，它只能作为一种增强证据，不能作为唯一判决依据。拿不到的时候，就 fallback 到传统风控规则。
- 隐私与合规是条红线：未经用户明确同意和告知，静默收集IP信息可能触碰隐私法规（如GDPR、国内的个保法）。比较规范的做法，是在隐私政策中明确说明，并在可能触发探测的页面（如登录页、提交页）进行适当的用户提示，将其作为安全防护的一部分。纯粹为了攻击而设计的隐蔽探测，有法律风险。
- 攻击者也会升级：高级的攻击者，会用完全隔离的浏览器环境、禁用JavaScript（但这样很多CC攻击模拟不了）、或者使用完全不具备WebRTC能力的客户端（如自制HTTP发包工具）来攻击。所以，这招主要针对利用浏览器集群或模拟浏览器行为的CC攻击。
- 对移动端和App内嵌浏览器的支持：情况更复杂，需要具体测试。
说白了，WebRTC真实IP识别，是给你在传统的IP频率、行为分析、指纹校验等风控维度之外，又加了一个非常有力的“关联分析”维度。它帮你穿透代理IP这层“迷雾”，看到背后可能存在的攻击源网络，从而实现更精准的打击和更少的误伤。
四、所以，到底该不该上？
我的看法是：
- 如果你的业务（尤其是Web业务）长期受代理池CC攻击困扰，传统手段效果越来越差，强烈建议把它作为风控策略的一个新模块进行试点。可以从最关键的、最常被攻击的1-2个页面开始。
- 技术实现上并不复杂，前端一段JS，后端一个记录和关联分析的逻辑（可以整合到现有WAF或风控系统里）。关键是设计好关联规则和处置策略，别误伤。
- 千万别单吊这一棵树。它必须和你现有的防护体系（高防IP/WAF的CC规则、业务层限流、验证码、人机识别等）协同工作，形成一个立体的防御网。攻击者绕过A，还有B和C等着。
- 隐私告知一定要做，这是为了保护你自己。
防护这事，本质上就是攻防双方的成本博弈。WebRTC这招，相当于显著提高了攻击者伪装“正常用户”的成本和难度——他得想办法搞定大量浏览器的WebRTC泄露问题，或者干脆放弃用浏览器来攻击。
对我们防守方来说，多一个有效且成本不高的手段，何乐而不为呢？
最后说句大实话：安全没有一劳永逸，今天好用的招，明天可能就得升级。但能比对手多想一层，多看透一层，胜算就多一分。WebRTC防御CC，就是这种“多看透一层”的典型思路。
行了，如果你正在被CC攻击折腾得够呛，不妨找你们的开发和安全同学，聊聊这个“浏览器真实IP识别”的可能性。说不定，就有惊喜。