2017年，那场差点让我改行的CC攻击
摘要：# 2017年，那场差点让我改行的CC攻击 说起来你可能不信，2017年那会儿，我差点就因为这破事转行去卖茶叶蛋了。 不是开玩笑。那年的CC攻击，跟现在的完全不是一个路数。现在大家聊防护，动不动就是“智能”、“AI”、“弹性”，听着挺唬人。但回到201…
说起来你可能不信，2017年那会儿，我差点就因为这破事转行去卖茶叶蛋了。
不是开玩笑。那年的CC攻击，跟现在的完全不是一个路数。现在大家聊防护，动不动就是“智能”、“AI”、“弹性”，听着挺唬人。但回到2017年，很多方案说白了，就是PPT上画得猛，真被打的时候，该跪还是得跪。
我自己当时手头维护着几个电商站，其中一个做特卖的，平时流量也就那样。结果双十一前一周，出事了。
一、2017年的CC攻击，到底“野”在哪？
先说个直观的感受：那年的攻击，特别“不讲武德”。
现在的攻击很多是冲着钱来的——勒索。打到你服，然后谈价钱。2017年那波，很多攻击者纯粹是为了“练手”，或者就是看你不顺眼。攻击逻辑简单粗暴：用海量的低速、长连接，活活耗死你的服务器。
不像现在有各种花样，什么模拟真人滑动、伪造搜索引擎爬虫。那时候的CC，很多就是开着工具，设定好目标URL（尤其是动态搜索页、商品列表页这种耗资源的），然后发动一堆“肉鸡”不停地访问。
关键点在这儿： 当时很多中小公司的防护思路，还停留在防DDoS（大流量洪水攻击）的阶段。觉得上了个高防IP，流量能扛住几百G，就万事大吉了。
结果呢？CC攻击流量不大，可能就几十兆，但连接数爆表。你的防火墙连接数表瞬间打满，新的正常用户连都连不上。服务器CPU直接100%，不是因为计算复杂，而是光处理TCP握手和HTTP请求解析就累吐了。数据库连接池被这些“慢查询”占得满满的，正常订单根本进不来。
我那特卖站就这死相。监控图上，带宽稳如老狗，CPU曲线却像坐了火箭，直冲云霄。最憋屈的是，你明知是攻击，却感觉一拳打在棉花上——流量清洗设备在那闲得发慌，因为它主要看流量大小，而这“毛毛雨”一样的流量，根本触发不了清洗阈值。
说白了，当时的很多防护体系，是“睁眼瞎”。 它防得住明火执仗的抢劫，防不住慢性中毒。
二、我们当时是怎么“土法炼钢”的？
报警电话打给机房和高防服务商，那边的技术支持小哥也很无奈：“老板，你这流量没超啊，我们这边策略没触发。”
等他们层层上报，调整策略，黄花菜都凉了。业务停一分钟，都是真金白银的损失。
没办法，只能自己上手，搞点“野路子”。现在回头看，这些方法很土，甚至有点自损八百，但在当时真是救命稻草。
- 人肉封IP段： 这是第一反应。看访问日志，找出那些高频访问的IP，发现很多是来自某些IDC机房的特定段。心一横，直接在防火墙（当时用的还是iptables居多）里写规则，把整个C段甚至B段都封了。这招狠，也容易误伤。 万一那个机房里有正常用户用了代理呢？但没办法，保命要紧。
- 限制单IP连接数和频率： 在Web服务器层面（Nginx），赶紧加配置。
limit_conn和limit_req模块成了香饽饽。一个IP同时只能开几个连接，每秒只能请求几次。超过的就直接返回503或者444（直接关闭连接）。这招立竿见影，CPU立马从100%降到七八十。但副作用是，如果攻击IP足够多，每个IP都卡着你的限制线来请求，还是能造成压力。而且，一些公司内网出口IP少的用户，可能会被误伤，访问体验变卡。 - 静态化，能静态的全静态： 把商品详情页、文章页，能生成静态HTML的全部生成。攻击者最爱打的就是带参数查询的动态页面（比如
?search=xxx），因为这类请求需要查数据库，最耗资源。我们把核心页面全静态化，相当于把“软肋”藏起来。攻击打在静态文件上，Nginx直接吐文件，消耗几乎为零。 - 启用验证码“核武器”： 对搜索、登录、提交订单这些关键接口，一旦检测到某个IP短时间请求过于频繁，立刻弹出验证码。这是最后的大招。效果最好，但用户体验也最差。你想想，用户正急着下单呢，突然要输一串歪歪扭扭的字母，可能直接就走了。
那几天，我和运维兄弟就盯着监控，手动加规则，跟打地鼠一样。这边刚封完一个段，攻击流量又从另一个地方冒出来。身心俱疲。
三、2017年，给我们上了怎样的一课？
经过那一役，我算是彻底明白了几个道理，这些道理到现在都不过时：
- 别迷信“高防”二字。 高防IP、高防服务器，主要防的是DDoS流量攻击。对于CC这种“连接攻击”，它可能只是个“门神”，防不住“内鬼”。你必须问清楚，它的防护策略里，有没有针对HTTP/HTTPS请求频率、连接数的精细规则。
- 源站隐藏不是“可选项”，是“必选项”。 2017年很多公司图省事，或者为了某些第三方服务（比如CDN统计不准），直接把源站IP暴露在外。攻击者一扒，直接打到源站IP，你前面套一百层CDN都没用。用高防IP或CDN，一定要确保回源IP段是独享的、隐藏的，并且源站防火墙只放行这些回源IP。这是保命的底线。
- WAF（Web应用防火墙）的价值凸显出来了。 如果说高防是防“冲击”的，那WAF就是防“点穴”的。好的WAF能基于行为分析，识别出哪些是恶意爬虫、哪些是CC工具发起的会话，然后自动拦截。2017年后，WAF从“奢侈品”变成了很多公司的“标配”。
- 监控不能只看带宽。 必须把服务器并发连接数、CPU使用率、数据库连接数、关键接口响应时间这些指标放在最醒目的位置。CC攻击的警报，往往是从这些指标里最先拉响的。
四、如果穿越回2017，我会怎么做？
现在想想，如果带着现在的认知回去，处理起来会从容很多：
- 第一时间，不是封IP，而是“切”。 如果有条件，立刻把DNS解析切换到带有智能CC防护功能的高防CDN或云WAF服务上。让专业的人（机器）去干专业的活，用它们的全局IP库和行为模型去过滤。
- 在源站前，坚决套一层“代理”。 绝不把源站IP暴露给公网。哪怕是用免费的Cloudflare，也能挡掉大部分简单的CC攻击。
- 架构上做好“分层防御”。 静态资源扔到对象存储，用CDN加速；动态API做好限流和熔断（当时还没那么流行，但现在看是必须的）；数据库前面加缓存，能扛住大量重复查询。
- 预案，预案，还是预案。 提前和防护服务商沟通好CC攻击的应急流程，知道电话打给谁，怎么快速升级策略。自己内部也要演练，知道关键时候该按哪个“开关”。
2017年的那场CC攻击，就像一次高烧，虽然难受，但也让我和很多同行的“免疫系统”强了不少。它告诉我们，安全防护不是买个盒子放在机房就完了，它是一个动态的、持续对抗的过程。
现在的攻击手段当然更高级了，但核心原理没变——找到你的成本弱点（服务器计算资源、数据库资源），然后用更低的成本去消耗它。
所以，别觉得2017年的事过去了就无关紧要。了解那段“草莽时期”的攻击与防御，你才能更深刻地理解现在这些“智能防护”到底在解决什么问题。
毕竟，太阳底下没有新鲜事。攻击者换汤不换药，而我们，也不能总在同一个坑里摔倒两次。
行了，就聊到这。如果你的业务现在还在裸奔，或者只靠一个“高防”就高枕无忧……嗯，你心里其实已经有答案了。