中小站点做DDoS防护,最尴尬的地方在于:买高防机房动辄几千上万一月,用CDN套一层又怕配置复杂影响访问,自己写iptables规则又扛不住四层流量。实际上现在轻量云防护方案已经非常成熟,只要把DNS解析、源站隐藏、四层清洗和七层限速这几件事串起来,几百元一年的成本就能获得相当可观的抗D能力。下面直接讲部署逻辑和具体操作。

先理解中小站点防护的核心矛盾

中小站点通常没有独立AS号,也没有BGP宣告能力,源站IP一旦暴露,攻击者可以直接绕过所有云防护打到服务器网卡上。所以轻量防护的第一原则不是“扛住多少G”,而是“让攻击流量永远到不了源站”。这意味着源站IP必须完全隐藏,所有公网流量只经过云防护节点。很多人以为套个CDN就完事了,但CDN的回源地址仍然会暴露源站真实IP,攻击者只要对回源地址发起四层SYN Flood,CDN节点一样会把压力转回源站。

第一步:源站IP彻底更换并锁定

在配置任何云防护之前,先给服务器换一个新IP。如果是云主机,直接在控制台解绑当前公网IP,重新分配一个弹性IP。换IP之后,立刻在安全组里删除所有入方向的公网允许规则,只保留云防护厂商的回源IP段访问22、80、443端口。这一步做完,源站对外界来说就是一个黑洞,任何扫描器都探测不到开放端口。注意,如果你的站点之前解析过A记录,攻击者可能已经通过历史DNS记录拿到了旧IP,所以换IP是必须的,不是可选项。

第二步:选择轻量云防护并配置回源

轻量云防护通常指那些按流量或带宽计费的抗DDoS IP服务,国内主流云厂商都有类似产品,比如阿里云的DDoS高防IP基础版、腾讯云的轻量级高防包,或者一些第三方专业抗D服务商的入门套餐。这类服务会给你一个高防IP,你只需要把域名解析到这个IP,高防节点清洗后再回源到你的真实服务器。关键配置在于回源方式:一定要选择“源站IP+自定义端口”模式,而不是让高防节点通过公网探测你的源站。回源端口只开放80和443,其他端口全部关闭。

第三步:DNS解析切换与TTL调整

把域名的A记录从源站IP改为高防IP。如果你的域名服务商支持分线路解析,建议默认线路全部指向高防IP,海外线路可以单独指向另一个低防护节点或者直接也指向高防。TTL先调到60秒,方便切换后快速生效和回滚。切换完成后,用dig命令确认解析已经全部更新,再通过curl指定解析IP测试高防节点到源站的回源链路是否通畅。这里有个细节:高防节点回源时Host头必须保持原域名,否则源站Nginx可能返回默认站点或者404。

第四步:源站Web服务器加固

即使源站IP已经隐藏,Web服务器本身也要做限制。Nginx层面配置只允许高防回源IP段访问,其他IP一律返回444。配置示例:

# 在server块外层添加
allow 高防回源IP段1;
allow 高防回源IP段2;
deny all;

同时开启Nginx的limit_req模块做七层限速,对单个IP的请求频率做限制,防止CC攻击穿透高防节点后打满源站CPU。PHP应用层面开启opcache,数据库只监听内网地址,这些基础加固能显著降低源站被直接打挂的概率。

第五步:四层防护与七层策略分开配置

高防IP产品通常默认开启四层清洗,SYN Flood、UDP Flood、ACK Flood这类流量攻击在进入高防节点时就被过滤了。但七层CC攻击需要单独配置策略。轻量套餐一般提供基础的CC防护规则,你需要根据站点类型设置:静态站点可以把“请求频率阈值”调低,比如单IP每秒超过50次请求就触发验证码;动态站点则要结合URI特征,对登录、搜索、提交接口单独设置更严格的频率限制。不要用默认策略,默认策略通常比较宽松,攻击者很容易绕过。

第六步:监控与告警联动

部署完成后,一定要配置流量监控和告警。高防控制台里能看到实时入流量和清洗流量,把告警阈值设置在套餐带宽的60%左右,超过就发短信或邮件。同时源站服务器上用iftop或者nload监控网卡流量,如果源站入流量突然升高而高防节点流量正常,说明回源IP可能泄露了,需要立即更换源站IP并更新高防回源配置。这种联动监控是很多人忽略的,但恰恰是轻量防护能否长期有效的关键。

常见问题与误区

很多人以为买了高防IP就万事大吉,结果攻击者通过邮件头、网站报错信息、子域名解析等方式拿到了源站真实IP,直接绕过防护。所以部署完成后,要用在线工具扫描全站,检查是否有任何地方泄露了源站IP,包括HTTP响应头里的Server信息、PHP报错里的路径、以及网站引用的外部资源。另外,不要在高防IP和源站之间使用HTTP明文回源,尽量配置HTTPS回源,否则中间链路可能被劫持。

轻量DDoS云防护的核心思路就一句话:源站藏死,流量全走高防,策略按需收紧,监控随时联动。把这四件事做到位,中小站点用几百元一年的成本,就能扛住绝大多数脚本小子和中小规模攻击。真正的大流量攻击不是这个方案能解决的,但那种攻击也不会盯着中小站点打。