网站安全加固方案

做网站的人最容易踩的坑，是把安全当成“上线前装个 WAF”就算完。但 WAF 只是最外面的一层，真正的安全问题往往藏在配置、权限和代码习惯里。下面这套方案从提示词、系统配置到响应流程，给你一条能直接落地的加固路径。

AI 提示词模板

拿不准该从哪里入手时，可以让 AI 先给一份方案，再逐条核对：

请帮我制定网站安全加固方案。
- 网站类型：[企业展示/电商/博客/应用]
- 技术栈：[PHP/Node.js/Python] | OS：[Ubuntu/CentOS]

输出：SSH/防火墙配置、SSL/TLS 最佳实践、WAF 配置、自动备份策略、XSS/CSRF/SQL注入防护。

服务器初始化安全清单

新服务器第一次开机，先过一遍这张清单：

  • 禁用 root 的 SSH 登录
  • 修改默认 SSH 端口
  • 启用 UFW，只放行 80、443、22
  • 安装 fail2ban
  • 开启自动 安全更新

Nginx 安全头部

隐藏版本号、限制请求体大小，是最低成本的加固：

server_tokens off;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
client_max_body_size 50M;

更完整的一套响应头还包括来源策略和内容安全策略：

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:;" always;

自动备份脚本

备份是安全兜底的最后一环。下面这个脚本可以放进 cron 里每天执行：

#!/bin/bash
WEBSITE_DIR=${1:-/var/www/html}
BACKUP_DIR=${2:-/backups/web}
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p "$BACKUP_DIR"
tar -czf "${BACKUP_DIR}/backup_${DATE}.tar.gz" "$WEBSITE_DIR"
echo "备份完成"

注意两点：备份要放到公网访问不到的目录，并且异地再存一份，防止服务器被入侵后连备份一起被删。

安全是设计出来的，不是装出来的

很多人以为网站安全等于“装个 WAF”。但安全没办法事后贴上去，它必须渗透到每个设计决策里。

最朴素的两条原则：永远不信任用户输入，永远使用最小权限。

三层防线

第一层：网络边界。大多数人从这里起步，能挡掉约 80% 的自动化攻击：

  • 只开放必要端口（80、443、SSH）
  • 用 SSH 密钥而不是密码
  • 装 fail2ban 防暴力破解
  • 启用 UFW 或 iptables

第二层：应用层。真正的伤害发生在这里：

  • SQL 注入：用参数化查询或 ORM，永远不要拼接 SQL 字符串；
  • XSS：所有渲染到 HTML 的输出都要转义。前端框架一般会处理，但要小心直接操作 DOM 的地方；
  • CSRF：每个表单生成唯一 token，提交时校验；
  • 文件上传：上传目录禁用脚本执行，限制文件类型和大小，必要时用独立域名或云存储。

第三层：数据层：

  • 数据库用强随机密码，一个服务一个密码
  • 备份先加密再存放
  • 备份绝不放公网可访问的目录

HTTPS 配置

server {
    listen 443 ssl http2;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:...;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
}

配置完去 ssllabs.com 测一遍，目标拿到 A 或更高评分。

事件响应：出事之后怎么办

做了再多防护，也可能出事。关键看你怎么响应：

  1. 发现：监控或用户反馈发现异常
  2. 隔离：把受影响的服务从集群中摘掉
  3. 分析：翻日志，确定入侵路径和数据影响范围
  4. 修复：打补丁，重置所有受影响凭据
  5. 恢复：从干净的 备份恢复
  6. 复盘：写事后报告，更新安全策略

每半年做一次桌面演练——花两小时把每个步骤过一遍，能发现很多你以为没有的漏洞。

一个实操场景：上线前 15 分钟

假设你刚把新站部署到一台腾讯云服务器，域名解析也生效了。上线前 15 分钟，值得做三件快事：跑一次 nmap -p- 你的IP 看有没有意外的开放端口；检查数据库默认账号和弱口令；给后台登录加一个二次验证。很多“上线三天就被挂马”的案例，根因就是这三个里漏了一个。

常见问题

免费证书和付费证书差别大吗？ 对绝大多数网站来说，Let's Encrypt 的免费证书已经足够，关键是把自动续期配置好。付费证书多出来的通常是更长的有效期和商业保障，并不影响加密强度。

被 CC 攻击了怎么办？ 先确认攻击流量特征：如果是单一 IP 反复刷接口，直接封 IP 加限流；如果是分布式打带宽，单台服务器很难扛住，建议启用高防或 CDN 清洗。平时把日志和监控做好，出问题时才能快速判断攻击类型。

WAF 能替代代码层面的防护吗？ 不能。WAF 拦截的是已知的、特征明显的攻击；代码里的注入点、越权、敏感信息泄露，WAF 往往看不出来。两者是叠加关系，不是二选一。

密码策略和二次验证，先做哪个？ 建议先做两件免费的事：改掉默认密码、给管理员账号开启二次验证。这两件事成本最低，但能挡住绝大多数撞库和弱口令攻击。

今天就做一件事

安全不是买来的产品，是一种习惯。从一件小事开始：登录你的服务器，查一下有没有没改过的默认密码，或者还开着的测试端口。

参考：OWASP 十大 Web 应用安全风险 https://owasp.org/www-project-top-ten/ ，Mozilla 安全响应头指南 https://infosec.mozilla.org/guidelines/web_security ，Let's Encrypt 证书文档 https://letsencrypt.org/docs/