中小企业谈DDoS和CC防护，最容易陷入两个极端：要么觉得攻击离自己很远，裸奔运行；要么被安全厂商话术吓住，以为必须采购几十万一套的硬件设备才能保平安。实际情况是，绝大多数针对中小企业的DDoS和CC攻击规模并不大，攻击者也不是什么高级APT组织，更多是竞争对手恶意打压、勒索团伙广撒网、或者脚本小子拿现成工具乱轰。这类攻击有个共同特点：流量峰值通常在5Gbps到20Gbps之间，CC请求量在几万QPS到几十万QPS之间，持续时间从几分钟到几小时不等。只要把基础架构和配置策略做对，用很低的成本就能扛住大部分真实攻击。

先明确一个核心逻辑：DDoS和CC是两种不同层面的攻击。DDoS打的是带宽和协议栈资源，目标是让你的网络入口拥塞、服务器无法响应正常连接；CC打的是应用层业务逻辑，目标是用大量看似正常的请求耗尽你的CPU、内存、数据库连接数。很多中小企业把两者混为一谈，导致防护策略错位。比如用防火墙封IP去对抗DDoS，结果带宽已经被塞满，封不封IP都没意义；又比如用带宽扩容去对抗CC，结果服务器先于带宽倒下。所以第一步是把网络层防护和应用层防护拆开看，分别用不同手段处理。

网络层DDoS的低成本防护思路

网络层DDoS最常见的形式是UDP Flood、SYN Flood、ICMP Flood、反射放大攻击。这些攻击的共同特征是伪造源IP、包速率高、单个请求内容简单。对于中小企业来说，指望自建机房或拉一条大带宽线路去硬抗是不现实的，最有效的做法是借助云服务商的基础设施清洗能力。现在国内主流云平台的基础DDoS防护都是默认赠送的，比如阿里云、腾讯云、华为云，免费额度通常在5Gbps到20Gbps之间。这个额度对绝大多数中小规模攻击已经够用。关键是要把业务入口全部收敛到云上，不要保留任何直连源站的公网IP暴露面。

具体操作上，有几条硬性要求。第一，源站IP绝对不能直接解析到域名上，所有业务域名必须通过CDN或高防IP接入。CDN节点本身具备一定的流量分散和清洗能力，而且节点数量多、带宽储备大，攻击流量打在CDN节点上不会直接冲击源站。第二，如果业务对延迟敏感、不适合走CDN，就使用云服务商的高防IP产品，把业务IP替换成高防IP，所有流量先经过高防机房清洗再回源。第三，源站安全组只允许CDN回源节点或高防回源IP段的访问，其他所有来源一律拒绝。这样即使攻击者通过历史解析记录或全网扫描找到源站真实IP，也无法直接发起有效攻击。

还有一个容易被忽略的点：DNS解析层面也要做冗余。很多中小企业只用一个DNS服务商，攻击者直接对DNS服务器发起查询洪水，域名解析就会中断。建议至少配置两家DNS解析服务商做主备切换，同时把域名的TTL适当调低，方便在遭受攻击时快速切换解析。另外，如果业务涉及UDP协议，比如游戏、语音、视频会议，一定要评估是否真的需要对外开放UDP端口。UDP反射放大攻击是目前DDoS中最难防的一种，因为攻击流量看起来像是来自合法的第三方服务器。减少UDP暴露面是最直接有效的缓解手段。

应用层CC攻击的识别与拦截

CC攻击的本质是模拟大量正常用户请求，让服务器忙于处理无效业务。攻击者通常会针对搜索接口、数据库查询接口、登录接口、验证码刷新接口、动态页面生成等消耗资源较大的URL发起请求。识别CC攻击不能只看请求量，还要看请求特征和业务逻辑的合理性。比如一个普通用户正常访问网站，不可能在1秒内请求同一个搜索接口50次；一个正常浏览器发起的请求，一定会携带完整的Cookie、Referer、User-Agent，并且会加载页面中的静态资源；而CC攻击工具往往只请求目标URL本身，不加载任何静态资源，请求头也可能缺失或固定不变。

在防护手段上，第一层是Web服务器层面的连接限制和请求速率限制。Nginx和Apache都有成熟的限速模块。以Nginx为例，可以通过limit_req模块对单个IP的请求频率做限制，通过limit_conn模块限制单个IP的并发连接数。下面是一个基础配置示例：

http {
    limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
    limit_req_zone $server_name zone=perserver:10m rate=1000r/s;
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        location /search/ {
            limit_req zone=perip burst=20 nodelay;
            limit_conn addr 10;
            proxy_pass http://backend;
        }
    }
}

这个配置的含义是：对/search/路径，每个IP每秒最多允许10个请求，突发最多20个，超过就直接返回503；同时每个IP对该路径的并发连接数不能超过10。对于搜索这类高消耗接口，这个限制已经足够宽松，正常用户根本不会触发。

第二层是应用层的行为分析。单纯靠IP限速会误伤企业出口NAT后面的正常用户，因为同一个公网IP下可能有几十个员工同时访问。更精准的做法是结合Cookie、会话、浏览器指纹来判断。比如给每个首次访问的用户下发一个JavaScript挑战Cookie，要求客户端执行一段简单的JS计算并回传结果。正常浏览器可以自动完成，而大部分CC攻击脚本不具备JS执行能力，直接被过滤掉。这个方案在Cloudflare等CDN服务商那里叫JS Challenge，国内一些WAF产品也有类似功能。如果不想依赖商业产品，可以自己实现一个轻量级的验证逻辑：首次请求返回一个页面，页面里包含一段生成特定Cookie的JS代码，后续请求必须携带这个Cookie才能访问真实内容。

第三层是WAF层面的规则过滤。CC攻击的请求头往往带有明显的工具特征，比如固定的User-Agent字符串、缺失Referer、请求频率异常均匀、请求参数完全一致等。可以在WAF中配置自定义规则，对满足这些特征的请求直接拦截。比如针对User-Agent为空的请求、User-Agent为已知攻击工具名的请求、请求间隔时间标准差极小的IP，都可以直接封禁。这里需要注意的是，规则不能太宽泛，否则会误伤搜索引擎爬虫或部分API客户端。

低成本架构设计的核心原则

中小企业做防护，最忌讳的是把所有鸡蛋放在一个篮子里。很多企业的架构是单台云服务器既跑Web又跑数据库，一旦被打，业务全部瘫痪。正确的做法是把静态资源和动态请求分离。静态资源全部放到对象存储或CDN上，源站只处理动态业务逻辑。这样即使源站被打，静态页面和图片依然可以正常访问，用户体验不会完全中断。同时，数据库要做读写分离，至少保证主库有一个从库可以切换。如果预算允许，把Web层和数据库层部署在不同的可用区，避免单点故障。

另一个核心原则是做好监控和自动化响应。很多中小企业被打了半天才发现，等反应过来业务已经中断很久。建议配置基础监控告警，比如服务器CPU使用率、内存使用率、网络入流量、Nginx请求量、5xx错误率。当这些指标在短时间内异常飙升时，自动触发告警通知。更进一步，可以写一个简单的脚本，当检测到某个IP的请求量超过阈值时，自动调用云服务商的安全组API封禁该IP。这个脚本不需要很复杂，几十行Python就能实现，但能在攻击初期就自动压制攻击源，为人工介入争取时间。

还有一个经常被忽视的点：业务接口本身的设计是否合理。很多CC攻击之所以有效，是因为业务接口本身存在性能瓶颈。比如一个列表查询接口没有做分页，攻击者请求一次就能让数据库全表扫描；一个搜索接口没有做缓存，每次请求都直接打到数据库；一个验证码接口没有做有效期限制，攻击者可以无限刷新消耗短信费用。这些问题在平时流量小的时候不明显，一旦被CC攻击放大，就会成为致命弱点。所以在做防护之前，先把业务接口的性能和资源消耗优化一遍，往往比上任何防护设备都更有效。

具体预算分配建议

对于年营收在几百万到几千万的中小企业，安全预算通常有限。按照实际优先级，建议这样分配：第一优先级是CDN和高防IP，这是对抗DDoS的基础，年成本从几千到几万不等，取决于带宽和防护峰值。第二优先级是WAF，可以选择云WAF或开源WAF自建。云WAF按流量计费，基础版一年几千块；开源方案如ModSecurity配合Nginx使用，成本几乎为零，但需要有人维护规则。第三优先级是日志分析和监控告警，这部分可以用开源工具搭建，比如ELK或Grafana配合Prometheus，成本主要是服务器资源。第四优先级才是商业安全服务，比如应急响应、渗透测试，这些按需购买即可，不必长期签约。

如果预算极度紧张，甚至为零，那么至少要完成以下几件事：把域名接入免费CDN，隐藏源站IP；在Nginx上配置好limit_req和limit_conn；把静态资源分离到对象存储；配置基础监控告警；关闭所有不必要的端口和服务。这几件事做完，已经能挡住相当一部分低强度攻击。不要觉得免费方案就一定没用，实际上很多攻击者看到目标有基本的防护措施，就会转向更软的目标。

攻击发生时的应急处理流程

即使做了充分准备，也不能保证百分百不被打穿。攻击发生时，最重要的是保持冷静，按照既定流程处理。第一步是确认攻击类型，看监控数据是带宽被打满还是CPU被打满。带宽打满说明是DDoS，需要联系云服务商确认是否已经触发清洗，如果攻击流量超过免费额度，临时购买高防包或升级防护规格。CPU打满说明是CC，先看Nginx日志找出被攻击的URL和攻击源特征，紧急情况下可以直接在Nginx配置里对该URL返回静态页面或503，先保住其他业务不受影响。

第二步是封禁攻击源。如果攻击源IP比较集中，直接在安全组或防火墙层面封禁整个IP段。如果攻击源分散，就启用更严格的限速策略，把limit_req的rate值调低，burst调小。第三步是切换备用方案。如果源站已经无法响应，可以考虑临时把整站切换到静态化页面，或者把核心业务切换到备用服务器。第四步是保留证据，提取攻击流量样本、日志记录，后续向云服务商或公安机关报案时使用。

最后要强调的是，安全防护是一个持续迭代的过程，不是一次性配置完就万事大吉。攻击者的手法在不断变化，防护策略也要定期复盘和调整。每个月花半小时看一下Nginx日志和监控数据，分析是否有新的攻击特征出现，是否有误伤正常用户的情况，是否有接口性能下降的趋势。这些看似琐碎的日常工作，才是中小企业用最低成本维持安全防护水平的关键。