摘要：# 慢刀子割肉：Web日志里那些不起眼的CC攻击痕迹 先说句大实话：现在搞攻击的人，早就不是只会蛮力冲锋的“莽夫”了。那种一上来就流量拉满、恨不得把你服务器直接冲垮的DDoS，反而好防——高防IP一上，流量一清洗，肉眼可见的异常，报警器响得震天。 真正…

慢刀子割肉：Web日志里那些不起眼的CC攻击痕迹

先说句大实话：现在搞攻击的人，早就不是只会蛮力冲锋的“莽夫”了。那种一上来就流量拉满、恨不得把你服务器直接冲垮的DDoS，反而好防——高防IP一上，流量一清洗，肉眼可见的异常，报警器响得震天。

真正让人头疼的，是那种“慢攻击”。就像温水煮青蛙，或者更形象点，像一群人有组织地、慢悠悠地在你店门口排队，每人只问一个问题，占着柜台不走，让后面真正的顾客干着急。服务器资源（尤其是数据库连接、线程池）被一点一点地磨光，监控大盘上流量曲线可能还挺平稳，但业务就是越来越卡，直到彻底瘫掉。

这种攻击，很多所谓的“智能防护”方案，PPT上吹得天花乱坠，真遇到了，可能连个响屁都放不出来——因为它们压根没识别出这是攻击。

那怎么办？源头在日志里。 你的Web访问日志（比如Nginx的access.log）不是摆设，它是服务器最诚实的“行车记录仪”。今天，我就带你像老侦探看案发现场一样，翻翻日志，揪出那些“慢攻击”的蛛丝马迹。

一、先别急着看“大数”，盯住这几个“反常细节”

很多运维兄弟一上来就盯着总请求量、总带宽看。没用的，CC慢攻击的精髓就是“化整为零”，让你在宏观数据上看不出异常。

你得换个思路，看微观，看分布。这几个地方，是攻击者最容易露出马脚的地方：

1. URL的“专注度”反常得可怕 正常用户的行为是发散的：浏览首页，点击A产品页，看看B文章，提交个评论。就算再专注，也会在几个核心页面间跳转。 而CC攻击为了最大化消耗你某个特定短板（比如一个复杂的搜索接口、一个登录验证逻辑、一个商品下单API），会极其“专一”。

• 怎么查？ 在日志里，用awk或日志分析工具，统计一下单个IP（或某个小IP段）在短时间内访问的URL路径。如果你发现某个IP，在5分钟里，对着同一个API接口（比如/api/v1/product/search?q=xxx），以固定的频率（比如每秒1次）请求了几百次，而对网站其他任何页面毫无兴趣——这嫌疑就极大了。
• 一个生活化的比喻： 这就像有个人进了超市，不去货架，也不结账，就站在服务台前，每隔10秒问一次“请问厕所在哪？”问完就走，过10秒又来问。他是真不知道吗？不，他就是在占用服务台资源。

2. User-Agent的“整齐划一”或“刻意伪装” 低级的攻击脚本，User-Agent（浏览器标识）要么是空的，要么是Python的Requests库、Go的默认Agent，一眼假。 但高级一点的，会伪造一批看起来正常的User-Agent，比如Chrome、Firefox的各个版本。这里的关键破绽在于 “整齐” 和 “老旧”。

• 怎么查？ 把日志里那些可疑请求（比如访问特定慢接口的）的User-Agent单独拎出来看。如果一大批不同IP的请求，用的是完全一模一样的User-Agent字符串（连小版本号都一致），这几乎就是批量化攻击的铁证。更隐蔽的是，用的都是一些早已过时、市场份额极低的浏览器版本——正常用户群不会这么整齐地“怀旧”。

3. 请求间隔的“机械心跳” 人类操作是有随机性的：快速点几下，停下来看会儿，再点。机器脚本则往往带有精确的“心跳”。 CC慢攻击为了尽可能低调，不会用最大并发把你冲垮，而是会控制节奏，比如严格每2秒发起一次请求，持续不断。

• 怎么查？ 这需要你把日志按IP和时间排序，计算同一个IP连续请求之间的时间差。如果一大批IP，它们的时间差都稳定在某个值附近（比如1.8-2.2秒），呈现出一种可怕的规律性，那这就是机器人军团在行军。手动操作绝无可能如此精准。

（私货时间：我见过最离谱的一个案例，攻击者把间隔设成了与目标服务器某个缓存机制的失效时间完全同步，每次请求都“恰好”打在缓存失效、需要重新计算的点上，伤害最大化。这种“懂行”的攻击，真让人后背发凉。）

二、别只看成功请求，那些“失败”和“超时”才是重灾区

攻击的目的不是拿到正确响应，而是让你“处理”这个请求。所以，很多慢攻击会故意访问一些需要复杂查询但可能不存在的数据，或者触发一些特别消耗CPU/数据库资源的逻辑。

1. 关注4xx状态码，特别是404和400 攻击脚本在遍历参数、测试接口时，会产生大量4xx错误。比如，不断变换?id=后面的参数，尝试撞库。如果短时间内，来自一批IP的、针对同一类URL的404请求暴增，这很可能是在进行攻击前期的路径探测。

2. 更要命的是“慢速”的200 OK 这是CC慢攻击最核心的伪装。请求是成功的（返回200），但服务器为了处理它，花了异常长的时间（比如一个普通API接口平时响应50ms，现在却要3秒）。 这通常意味着，攻击命中了你的业务逻辑漏洞：一个没有缓存的全表搜索、一个复杂的循环计算、一个同步锁住的资源。

• 怎么查？ 这是最关键的一步。在你的日志中，必须包含每个请求的响应时间（$request_time或$upstream_response_time）。设置一个合理的阈值（比如超过2秒），把所有这些“慢请求”过滤出来。然后重点分析：
  • 它们集中在哪些URL？
  • 它们的参数有什么共同特征？（比如?search=aaaaaaaa这种试图引发模糊查询全表扫描的）
  • 来源IP是否集中？

当你发现，一批IP在持续地、以固定节奏“制造”着慢请求，你的数据库连接池指标（Threads_running）也同步飙升——恭喜你，抓到了现行。

三、组合起来看：给攻击者画个像

单一线索可能误判（万一真有用户在疯狂测试搜索呢？），但多个线索叠加，概率就极高了。

一个典型的CC慢攻击画像，在日志里是这样的：

• IP群体： 可能来自某个或某几个ASN（自治系统），IP地址连续或分布有规律。
• 行为模式： 以近乎固定的时间间隔（如2秒一次），持续请求同一个或少数几个消耗性API接口。
• 请求特征： User-Agent要么高度一致，要么是过时版本；可能携带一些特意构造的、旨在拖慢处理速度的参数（超长字符串、深度分页等）。
• 结果特征： 大量请求的响应时间远高于该接口的正常水平，但同时伴随着服务器中间件（如MySQL）的慢查询日志激增。
• 目标明确： 对网站的静态资源（图片、CSS、JS）几乎无请求，火力全集中在动态业务接口上。

最后说点落地的

如果你的日志分析能力跟上了，发现了这些痕迹，接下来怎么办？

1. 第一时间，手动封禁。 根据分析出的恶意IP段，在防火墙或WAF上先拉黑。别犹豫，这是止损最快的方法。
2. 优化短板。 攻击者帮你做了次免费的“压力测试”，精准地找到了你系统的性能瓶颈。那个被频繁攻击的慢接口，赶紧看看能不能加缓存、优化SQL索引、限制单IP频率。
3. 配置规则化防护。 在WAF或网关层，针对性地配置规则：比如，对特定URI，限制单个IP的请求频率（比如每秒不超过1次）；或者对响应时间超过阈值的请求，自动触发对该IP的进一步监控或限流。
4. 源站隐藏是基础。 别让你的真实服务器IP暴露在外。用高防CDN或高防IP在前面扛着，让攻击流量先打到清洗中心，把这种“慢攻击”的特征识别出来并拦截掉，干净的流量再回源。

说白了，防御CC慢攻击，核心思路就一个：从“看流量大小”的粗放模式，切换到“看行为模式”的精细模式。 你的日志里，藏着所有答案的起点。

别再只盯着监控大盘上那条平静的流量曲线自我安慰了。现在就去翻翻你的Web日志，看看有没有那些“彬彬有礼”却正在拖垮你的“慢刀子”。你的业务卡顿，说不定答案就在里面。