摘要：# HTTP方法里的“鬼探头”：从GET/POST统计里揪出CC攻击 我前两天帮朋友看一个电商站，他愁眉苦脸地说：“最近网站慢得跟老牛拉车似的，但监控上CPU、内存都正常，流量也没爆，邪了门了。” 我让他把最近一周的访问日志拉出来。一打眼，总请求量确实…

HTTP方法里的“鬼探头”：从GET/POST统计里揪出CC攻击

我前两天帮朋友看一个电商站，他愁眉苦脸地说：“最近网站慢得跟老牛拉车似的，但监控上CPU、内存都正常，流量也没爆，邪了门了。”

我让他把最近一周的访问日志拉出来。一打眼，总请求量确实没太大波动。但当我按HTTP方法拆开一看——好家伙，POST请求的比例高得离谱，几乎占了总请求量的四成。一个以商品浏览、搜索为主的电商站，正常用户行为里，九成以上都该是GET请求（点链接、看图片），哪来这么多“提交操作”？

问题就藏在这个比例失调里。 很多隐蔽的CC（Challenge Collapsar）攻击，早就不玩洪水漫灌了，它们就藏在看似正常的请求里，一点一点“磨”死你的服务器。

CC攻击“变异”了，你的排查思路也得变

早些年CC攻击简单粗暴，用一堆代理IP疯狂刷新你首页，那叫一个“光明正大”。现在稍微有点水平的攻击者，都学精了。

他们模拟的更像“真人”行为：不再只盯着一个URL猛刷，而是在你的网站里“爬”和“点”。比如，遍历商品ID（/product/1001， /product/1002…），或者用脚本自动提交搜索框。这类攻击有个共同点：为了获取数据，它们大量使用GET方法。

但还有更阴的——专门针对登录口、验证码接口、提交评论这些需要POST方法的地方进行高频攻击。比如，用成千上万个被盗的账号密码组合，轮番轰炸你的登录接口（/api/login）。这种攻击，目的不是刷页面，而是拖垮你的应用逻辑处理能力。登录验证涉及数据库查询、密码比对、会话生成，成本比返回一个静态页面高十倍不止。攻击者用很少的流量，就能让你的CPU在后台默默“燃烧”。

所以，光看总流量，你感觉不到疼。但服务器资源，尤其是数据库和CPU，已经在悄悄告急。

怎么从统计里看出“鬼”？三个关键指标

说白了，分析HTTP方法，就是给你的网站做一次“行为侧写”。正常用户和攻击脚本，留下的痕迹根本不一样。

1. 看比例：GET和POST的“生态位”失衡

这是我开头用的方法，最简单直接。你得先知道你的站点正常情况下该是什么样。

• 内容站/博客：GET请求占比可能超过95%。突然某天POST请求飙升，你就得去查是不是评论被刷、有异常登录尝试了。
• Web应用/后台系统：POST比例自然会高，但要看具体接口。如果/api/data/query（本该是GET）突然全是POST请求，或者/api/submit（一个低频接口）请求量翻了百倍，警报就该响了。

（我见过最离谱的，是一个企业官网，GET/POST比例居然五五开。一查，果然是被当成了练手的靶场，各种扫描工具在试它的后台登录和注入点。）

2. 看分布：哪个URL在“作妖”？

光看整体比例不够，得下钻。把GET和POST请求分开，分别看它们的URL路径分布。

• 对于异常的GET请求：用工具（比如AWStats、GoAccess，或者ELK套件）拉出TOP 20的GET请求路径。如果发现大量请求集中在：

  • 带参数的搜索URL（/search?q=…）
  • 分页URL（/news?page=…）
  • 规律性的API接口（/api/v1/user/） 而且这些请求的IP很集中，或者User-Agent很单一（比如一堆python-requests），那基本没跑。

• 对于异常的POST请求：重点盯防几个“高危区”：

  • 登录接口（/login, /api/auth）
  • 注册接口
  • 表单提交接口（下单、评论、留言）
  • 验证码刷新接口 统计这些接口的请求频率。正常用户登录，一天可能就几次。如果/login这个路径每分钟被请求上千次，那不是攻击是什么？难道全世界用户约好了一起输错密码？

3. 看“节奏”：请求的时序有问题

人是有操作节奏的，机器没有。通过日志分析工具，你可以画出每秒请求数（RPS） 的曲线图。

• 正常曲线：有高峰（如白天工作时间），有低谷（深夜），波动相对平滑。
• 攻击曲线：往往是一条平滑的直线，或者呈现极其规律的“锯齿波”（脚本定时触发）。RPS长期维持在一个高于日常平均的水平，雷打不动。这种“反人类”的稳定，就是铁证。

发现异常之后，别慌，按这三步走

1. 立刻确认：马上去服务器上，用top或htop命令看看，是不是php-fpm、java或者mysql这些进程的CPU占用率高得异常。再用netstat看看连接数。如果方法统计异常和资源消耗异常对上了，那就坐实了。

2. 临时封禁：如果攻击源IP不算太多，可以在防火墙（如iptables）或Web服务器层（Nginx的deny规则）先做紧急封禁。如果IP海量，赶紧上速率限制（Rate Limiting）。在Nginx里，给特定的敏感接口（比如/api/login）加上limit_req模块，规定单个IP每秒最多请求一次，超出的直接返回429。

   location = /api/login {
       limit_req zone=login burst=3 nodelay;
       # ... 你的代理配置
   }

   这招能立刻把大部分脚本攻击挡在外面，性价比极高。

3. 长期布防：临时措施救火，长远还得靠体系。

   • 上WAF（Web应用防火墙）：现在的云WAF或硬件WAF，基本都有基于HTTP方法、频率、会话的CC防护规则，能自动识别和拦截这类攻击。
   • 考虑高防或高防CDN：如果业务常被盯上，别犹豫。它们有更大的流量清洗能力和更智能的行为分析模型，能把攻击流量在边缘节点就化解掉，你的源站甚至感觉不到。
   • 最重要的：隐藏源站！通过CDN或高防IP来代理，别让真实服务器IP暴露在公网。攻击者打不到你真实地址，威胁就少了一大半。

说点大实话

很多中小站点的运维，对日志的分析还停留在“看个大概”的阶段。攻击手段进化了，咱们的排查手段也得跟上。CC攻击的本质，是消耗“处理成本”而非“带宽成本”。所以，那些需要你服务器“动脑子”（查数据库、跑逻辑）的地方，才是它的主攻方向。

下次感觉网站“莫名变卡”，别只盯着带宽图。打开你的访问日志，从HTTP方法这个最简单的维度切进去看看。说不定，那个正在一点点放干你服务器血的“吸血鬼”，就藏在GET和POST那串看似枯燥的数字里。

行了，方法就是这些。赶紧去看看你的日志吧，说不定有“惊喜”。