DDoS防护落地清单：服务器防火墙、日志联动与备份验证

先把防护目标说清楚

很多站长谈 DDoS防护 时，容易只盯着“有没有高防”。实际运维里，更常见的问题是端口长期暴露、SSH（安全外壳远程登录协议）被爆破、日志没人看、备份从没恢复过。本文给出一份可以直接照着执行的清单，帮助你把服务器安全拆成网络入口、系统登录、应用日志和数据恢复四个可验证环节。

这篇不是重复“买高防就完事”的老话题，而是把一台已经上线的业务服务器拿来做落地检查：哪些端口必须关，哪些规则要有日志证据，备份是否真的能恢复。对于正在使用海外服务器的站长，也可以把这份清单当作上线后一周内的基础巡检模板。

第一步：先收敛入口，不要让端口裸奔

DDoS（分布式拒绝服务攻击）中的大流量攻击通常要依赖上游清洗，但很多小规模攻击和扫描，往往先从暴露端口开始。建议先在服务器上列出监听端口，再决定哪些服务确实需要对公网开放。

sudo ss -tulpen
sudo ufw status verbose

一台普通 Web 服务器通常只需要 22、80、443 三类入口。22 端口如果必须保留，至少要限制来源 IP（互联网协议地址）或启用速率限制。下面这组规则适合 Ubuntu 系统的基础收敛场景：

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status numbered

如果服务器承载 WordPress 或论坛程序，还可以参考 WHT 上关于 WordPress 迁移后环境检查 的思路，把端口、目录权限、数据库连接一并列入上线检查。这样做的价值在于：防火墙不是写完规则就结束，而是要能通过 ufw status numbered 明确看到最终开放面。

第二步：把登录爆破交给规则处理

服务器上线后，SSH 登录日志里出现陌生 IP 尝试并不稀奇。真正需要处理的是“持续失败、来源集中、时间规律”的爆破行为。Fail2Ban 适合做第一层自动拦截，它读取系统日志并按规则封禁异常来源。

sudo apt update
sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

针对 SSH，可以先采用 10 分钟内失败 5 次、封禁 1 小时的保守策略。配置后要看状态，不要只看服务是否启动：

[sshd]
enabled = true
port = ssh
maxretry = 5
findtime = 600
bantime = 3600

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
sudo tail -n 50 /var/log/auth.log

如果你之前读过 美国/香港主机备案与合规常见问题汇总，会发现安全和合规有一个共同点：不要只写制度，要有可回查的日志。Fail2Ban 的封禁列表、auth.log 的失败记录，就是后续排障和复盘的证据。

第三步：应用层防护要控制误伤

Web 应用防火墙可以拦截常见注入、异常请求和恶意扫描，但规则过激会误伤正常用户。这里建议先从观察模式开始，统计 24 小时内的 403、404、500 状态码，再决定是否收紧规则。Nginx 环境可以先用下面的命令看异常请求占比：

sudo awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
sudo grep ' 404 ' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head
sudo grep ' 403 ' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

如果业务前面接了 CDN（内容分发网络），还要确认源站是否只接受代理节点回源，否则攻击者绕过 CDN（内容分发网络）直接打源站，前面的缓存和防护就失去意义。这个问题和 CDN 与高防服务协同 一文里的结论一致：边缘层负责吸收和过滤，源站层负责收口和校验，两层缺一不可。

这里还有一个容易漏掉的细节：如果反向代理或负载均衡没有正确传递真实访问 IP（互联网协议地址），日志里可能只剩代理节点地址，后续封禁会失去精度。上线前可以检查 X-Forwarded-For 或等价字段是否写入访问日志，并用一条测试请求确认日志记录的是客户端来源，而不是单一网关地址。

第四步：备份要按恢复结果验收

备份不是“有一个压缩包”就算完成。真正有用的备份至少要满足三个条件：文件可读、数据库可导入、恢复耗时可预估。建议把数据库和站点文件拆开备份，并保留 7 天每日备份加 4 周周备份。

mkdir -p /backup/db /backup/files
mysqldump --single-transaction --all-databases | gzip > /backup/db/all-$(date +%F).sql.gz
tar --exclude='/var/www/*/cache' -czf /backup/files/www-$(date +%F).tar.gz /var/www
find /backup -type f -mtime +30 -delete

恢复验证可以每月做一次抽样，不建议等事故发生后第一次尝试。最小验证流程是：在临时目录解压文件，抽取数据库前 20 行检查 SQL（结构化查询语言）头部，再记录本次恢复耗时。

gzip -t /backup/db/all-$(date +%F).sql.gz
tar -tzf /backup/files/www-$(date +%F).tar.gz | head
zcat /backup/db/all-$(date +%F).sql.gz | head -n 20

对于跨境站点或交易型网站，建议把备份与节点选择一起评估。比如 出海企业依赖海外服务器的原因 不只包括访问路径，也包括故障切换和恢复窗口。Hostease 用户如果已经有多节点部署需求，可以把备份恢复时间作为选型指标之一，而不是只看配置表。

如果备份文件保存在同一块系统盘里，还要额外准备异地副本。一个简单做法是每日本地快照、每周异地同步，并保留最近一次恢复演练记录。这样磁盘损坏、误删文件和应用被入侵时，恢复路径不会全部依赖同一台机器。

一份可执行的周巡检清单

检查项	建议频率	验收方式
公网端口	每周	ss -tulpen 与 ufw status numbered 输出一致
登录爆破	每日	fail2ban-client status sshd 有封禁统计或明确为 0
异常请求	每周	Nginx 403/404 来源 IP 前 10 名已复核
备份文件	每日	gzip -t 与 tar -tzf 均无报错
恢复演练	每月	记录恢复样本、耗时和失败原因

总结：安全防护要能被复查

这篇文章的核心建议很简单：先缩小暴露面，再让系统自动处理重复攻击，最后用日志和恢复演练证明配置有效。DDoS防护 不能只依赖某一个开关，防火墙、登录限制、应用日志、CDN（内容分发网络）回源控制和备份验证要组合起来看。

如果你需要给已经上线的服务器补一轮安全基线，可以考虑按本文顺序执行：当天完成端口和防火墙检查，第二天补齐 Fail2Ban 与日志统计，第三天验证备份恢复。这样即使后续遇到攻击或误删，也能更快判断问题发生在哪一层，并把恢复时间控制在可预期范围内。