网站安全防护实战：从Cloudflare配置到源站隐藏的完整思路

很多站长把域名NS切到Cloudflare就以为万事大吉，结果某天收到账单发现流量跑了几百G，或者网站直接被CC打到502。问题通常不在Cloudflare本身，而在于回源配置和源站暴露面没处理干净。我自己经手过不少站点，防护做了但源站IP还能被扫到的情况太常见了，攻击者根本不走你的域名，直接打IP，Cloudflare再强也拦不住。

Cloudflare是入口，不是全部

Cloudflare的免费套餐确实够用：DNS解析、CDN加速、基础的DDoS清洗、SSL证书，这些对中小站点来说已经解决了大半问题。但它有个前提——流量必须经过它。一旦源站IP泄露，攻击者绕过Cloudflare直接打你的服务器，那层防护就等于没有。

判断源站有没有暴露，最简单的办法是查一下历史DNS记录。很多站长在接入Cloudflare之前，域名已经解析到源站IP跑了一段时间，这些记录会被第三方平台存档。换我我会先做这一步排查，确认没有旧记录残留，再去配防火墙。

另一个常见泄露渠道是邮件服务。如果服务器自己发信，邮件头里会带上源站IP。要么用第三方SMTP，要么在服务器上把发信走单独通道，别让邮件把源站卖出去。

防火墙规则怎么配才不误伤

Cloudflare的WAF和Rate Limiting是核心工具，但规则配太严会把自己的用户也挡在外面。我的做法是分三层：

• 第一层用托管规则集，拦掉已知的恶意请求特征，这层基本不用手动维护
• 第二层针对登录页和API接口做速率限制，比如同一IP每分钟超过20次请求就挑战
• 第三层用防火墙规则封掉明显异常的User-Agent和空Referer的POST请求

5秒盾（Under Attack模式）不要长期开着。它对真实用户的体验影响很大，尤其是电商和内容站，用户等5秒可能直接关页面走人。只有在确认正在被攻击时才临时开启，攻击过去就关掉。

速率限制的阈值需要根据自己站点的实际流量调整。新站一天没几个请求，设每分钟10次就够；有一定流量的站可以放到30到60次。设太紧会误伤正常用户，设太松又拦不住CC。这个没有标准答案，得看日志慢慢调。

源站端的最后一道防线

Cloudflare再好，源站自己也得有防护意识。我一般会做这几件事：

服务器防火墙只放行Cloudflare的回源IP段，其他IP一律拒绝。Cloudflare官方会公布回源IP列表，用iptables或者ufw配一下就行。这样即使有人知道你的源站IP，直接访问也会被服务器自己挡掉。

SSH端口不要用默认的22。改成高位端口，配合密钥登录，禁用密码认证。这两步做完，暴力破解基本就跟你没关系了。我见过太多服务器被扫22端口扫到密码爆破成功的案例，改个端口加个密钥，五分钟的事。

如果业务对防御要求高，比如游戏站或者经常被盯上的行业站，源站可以考虑用高防服务器兜底。像秀米云的美国洛杉矶高防服务器11，E5 2620配32G内存，100M带宽，月付239美元，自带防御能力，即使Cloudflare那层被绕过，源站还能扛一阵。这个价位的独立服务器比云主机贵一些，但防御和带宽是实打实的。

数据库和后台管理面板不要暴露在公网。phpMyAdmin、宝塔面板这些，要么限制访问IP，要么走内网或者SSH隧道。面板被扫到弱密码，整台服务器就没了。

日常维护比一次性配置更重要

安全防护不是配完就完事。Cloudflare的规则要定期看日志，发现新的攻击模式就补规则。服务器系统要及时打补丁，尤其是Web中间件和CMS的漏洞，攻击者最喜欢盯这些。

备份策略也得跟上。就算防护做得再好，万一被突破，有备份就能快速恢复。数据库每天备份，网站文件每周备份，备份文件存到另一台机器或者对象存储，别跟网站放同一台服务器上。

最后说一个容易被忽略的点：子域名。很多站长只保护了主站，忘了dev、test、admin这些子域名。这些子域名往往防护更弱，甚至直接解析到源站。攻击者从子域名入手，一样能摸到你的服务器。所有子域名都要过Cloudflare，一个都不能漏。

整套做下来，中小站点的安全防护成本其实很低。Cloudflare免费版加上源站防火墙配置，基本能挡住90%以上的自动化攻击。剩下的就是保持关注，别让服务器裸奔太久。