先讲个让我印象深的案例。一个朋友的论坛，平时好好的，有天半夜突然卡成PPT，早上起来一看，服务器CPU跑满了一整夜，日志里全是一个页面的访问记录，来源IP换了一茬又一茬。他一开始还以为是流量上来了，高兴了半宿，后来才反应过来是被CC了。CC攻击这东西吧，不像DDoS那样把带宽打满那么声势浩大，它更像是派一群人去你家店里光试不买，把服务员全耗住，真顾客来了没人接待。今天就把识别和防御的办法都给你说道说道。
先分清CC和DDoS，别搞混
DDoS是流量型攻击，用海量垃圾流量把带宽或者服务器打瘫，特征是一看带宽监控就爆表。CC是应用层攻击，模拟真实用户去请求你的页面、接口，特别是那些耗资源的动态页面，把服务器的处理能力耗尽。CC的攻击流量看起来很正常，跟真实用户请求长得一模一样，所以更难防，这也是它让人头疼的地方——你不能把正常用户也一起挡了。
怎么判断自己是不是被CC了
被CC有几个典型特征：第一，网站突然变慢或者频繁超时，但带宽监控却不高，说明不是流量型攻击；第二，CPU和内存占用飙升，因为服务器在拼命处理请求；第三，看访问日志，会发现大量请求集中在某一个或几个页面，尤其是查询、搜索、登录这种动态接口，来源IP分散但频率极高，而且很多IP的User-Agent一样或者请求规律特别整齐，一看就是程序在跑。
应急三步走，先把网站救回来
确认被CC之后，第一步先止血：在防火墙或者云盾里，把攻击最猛的那批IP封掉，观察日志找规律，能封一批是一批。第二步，上CDN或者高防：CC攻击最怕CDN，因为流量先打到CDN节点，源站IP被隐藏了，攻击者找不到你家大门，攻击效果大打折扣。第三步，把网站开启验证码或者频率限制：对可疑的高频访问弹验证码，或者限制单个IP的请求频率，程序化的攻击遇到验证码基本就歇菜了。
如果你的服务器已经扛不住了，最快的办法是临时把网站设置成静态页面或者开启整站缓存，让攻击请求直接命中缓存，不消耗多少资源，先保住网站能访问，再慢慢收拾攻击者。
防御的长期方案，别只靠临时封IP
临时手段治标，长期防御得靠体系：接入高防CDN或者云WAF，把应用层防护交给专业设备，它能在攻击到达源站之前就把恶意流量识别并清洗掉，这是对付CC最有效的办法；源站做好隐藏，别让攻击者拿到你的真实IP，不然人家绕过CDN直打源站，CDN就白接了；动态页面能缓存就缓存，该做静态化的做静态化，把服务器能被消耗的资源降到最低。
再说说那些扛不住的配置层面优化
就算被攻击，服务器也得能多扛一会儿，所以平时就做好这些：Web服务器的连接数和超时参数调合理，别让一堆慢连接把进程占满；PHP-FPM或者后端服务的进程数、队列长度设上限，超了直接拒绝新请求而不是硬扛；数据库连接池设好，防止攻击请求把数据库连接也打满。这些配置平时看着不起眼，真被攻击的时候，每一秒的喘息时间都可能决定网站是活着还是挂掉。
平时咋防患于未然
顺便提醒一句：万一被CC的同时还收到勒索邮件，说什么交钱就停手，别理他。多数就是广撒网吓唬人，你越当真他越来劲。正经做法是做好上面说的防护，该报警报警、该上报平台上报，按流程走，别把希望寄托在交钱上。
CC攻击的预防核心就两条：一是隐藏源站，二是把防护前置。别在服务器日志里直接暴露真实IP，别让源站端口对公网全开，能用CDN就用CDN。再就是给网站接上监控告警，CPU、内存、请求量异常飙高的时候第一时间通知你，攻击刚开始就能发现，处理起来从容得多。别等网站已经瘫了才去看日志，那时候服务器能不能登录都成问题了。
最后说句实在话：小网站被CC盯上的概率不高，但真遇上了也别慌，按应急、加固、预防这套流程走。真要长期运营，高防CDN那点钱，就当给网站买保险了，比被攻击时的手忙脚乱值多了。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
