网站定制安全加固：HTTPS、WAF与防DDoS部署方案

很多企业以为安全加固就是"买个SSL证书+开个防火墙"，结果依然被攻击打穿。原因很简单：单点防护各自为战，攻击者只需要找到一个绕过路径。

真正的安全加固是流量路径上的分层拦截——每一层解决不同类型的威胁，层层递进，形成纵深防御：

攻击者 → [DNS层：隐藏源站] → [网络层：DDoS清洗] → [应用层：WAF拦截]
       → [传输层：HTTPS加密] → [主机层：服务器加固] → 网站本体

本文以一个典型的企业定制网站（Nginx + 云主机）为例，给出完整的三层部署方案：

两套主流路线任选：

• 路线A：Cloudflare方案（全球业务/中小企业/低成本首选）
• 路线B：阿里云/腾讯云方案（纯国内业务/等保合规首选）

部署前：先画出你的"流量路径图"

动手前必须搞清楚三个问题，否则后面全是坑：

1. 域名DNS在哪里解析？（阿里云DNS/DNSPod/Cloudflare/其他）
2. 源站服务器在哪里？ IP是多少？这个IP还有谁知道？（历史邮件、子域名、旧备案记录都可能泄露）
3. 网站有没有API/小程序/App直连源站？（这些流量也要纳入防护方案）

关键认知：如果源站IP已经暴露过，仅接入WAF/CDN是不够的，攻击者可以绕过防护直接打源站。最彻底的做法是——接入防护后更换源站IP，新IP只允许防护平台回源。

第一层：HTTPS全站部署方案

步骤1：证书选型与申请

免费证书自动化签发示例（acme.sh + 阿里云DNS）：

# 安装 acme.sh
curl https://get.acme.sh | sh

# 配置DNS API密钥（在阿里云RAM中创建，仅授予AliyunDNSFullAccess）
export Ali_Key="你的AccessKeyId"
export Ali_Secret="你的AccessKeySecret"

# 签发通配符证书
acme.sh --issue --dns dns_ali -d example.com -d "*.example.com"

# 安装证书到Nginx目录，并配置自动reload
acme.sh --install-cert -d example.com \
  --key-file       /etc/nginx/ssl/example.com.key \
  --fullchain-file /etc/nginx/ssl/example.com.pem \
  --reloadcmd      "systemctl reload nginx"

# acme.sh默认已添加cron自动续期，验证：
crontab -l | grep acme

付费证书也要设置到期提醒（提前30/15/7天三级提醒），证书过期导致的网站"变红"是最常见也最不该发生的事故。

步骤2：Nginx全站HTTPS配置（生产级模板）

# ============ HTTP 强制跳转 HTTPS ============
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# ============ HTTPS 主站配置 ============
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com www.example.com;

    # ---- 证书 ----
    ssl_certificate     /etc/nginx/ssl/example.com.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    # ---- 协议与套件（禁用不安全协议）----
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;

    # ---- 会话优化（提升TLS握手性能）----
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # ---- OCSP Stapling ----
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 223.5.5.5 119.29.29.29 valid=300s;

    # ---- HSTS（上线HTTPS稳定2周后再开启）----
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # ---- 安全响应头（防劫持/防注入/防点击劫持）----
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

    # ---- 隐藏版本号 ----
    server_tokens off;

    # 网站根目录与常规配置...
    root /var/www/example;
    index index.html index.php;
}

步骤3：全站HTTPS改造（消除混合内容）

这是最容易被低估的工作量，逐项排查：

1. 站内资源协议统一： 图片/CSS/JS/字体全部改为 https:// 或协议相对路径 //example.com/...
2. 数据库中的硬编码URL： 批量替换内容库中的 http:// 链接（WordPress可用 Better Search Replace 插件）
3. 第三方资源检查： 统计代码、客服组件、地图SDK、字体库是否支持HTTPS
4. 表单提交地址： 所有 <form action> 改为HTTPS
5. 重定向链检查： 确认没有 https→http 的反向跳转

验证方法：

• 浏览器控制台无 "Mixed Content" 警告
• SSL Labs测试 达到 A级以上
• 全站爬取工具（Screaming Frog）检查无HTTP残留链接

HSTS开启注意事项： HSTS生效后浏览器将强制HTTPS访问，若证书出现问题网站将完全无法访问且无法回退。务必先稳定运行HTTPS 1~2周、确认无混合内容后再开启，初期 max-age 可设为300秒测试。

第二层：WAF部署方案

路线A：Cloudflare WAF（推荐中小企业/全球业务）

步骤1：域名接入Cloudflare

1. 注册Cloudflare账号 → Add Site → 输入域名
2. 选择套餐（Free已含基础WAF；Pro $20/月含完整WAF规则集，企业站建议Pro）
3. 到域名注册商处，将NS服务器改为Cloudflare分配的NS地址
4. 等待DNS生效（通常几分钟~24小时）

步骤2：核心开关配置

步骤3：自定义WAF规则（Pro版核心配置）

在 Security → WAF → Custom Rules 中创建以下规则：

规则1：后台路径IP白名单
  IF (http.request.uri.path contains "/admin" OR http.request.uri.path contains "/wp-login.php")
  AND (NOT ip.src in {公司出口IP/管理员IP列表})
  THEN Block

规则2：高危国家/地区封禁（如无海外业务）
  IF (NOT ip.geoip.country in {"CN"})
  AND (NOT http.request.uri.path contains "/api/")
  THEN Block  （或 Managed Challenge 柔性拦截）

规则3：敏感文件访问拦截
  IF (http.request.uri.path contains ".env" OR http.request.uri.path contains ".git"
      OR http.request.uri.path contains "wp-config" OR http.request.uri.path contains ".sql")
  THEN Block

规则4：可疑User-Agent拦截
  IF (lower(http.user_agent) contains "sqlmap" OR lower(http.user_agent) contains "nikto"
      OR lower(http.user_agent) contains "scanner" OR http.user_agent eq "")
  THEN Block

规则5：API接口限频（配合Rate Limiting规则）
  IF (http.request.uri.path contains "/api/")
  THEN 单IP每分钟限60次，超出Managed Challenge

步骤4：托管规则集（Managed Rules）

• Security → WAF → Managed rules → 开启 Cloudflare Managed Ruleset
• 模式选择：先 Log（观察） 运行3~7天 → 审查误报 → 切换 Block
• 敏感性设置：Medium起步，误报多则调Low

路线B：阿里云WAF（纯国内业务/等保合规）

步骤1：购买与接入

1. 阿里云控制台 → Web应用防火墙 → 购买（包年包月，按域名数/QPS选型）
2. 接入方式选择：
• CNAME接入（推荐）：网站配置 → 添加域名 → 填写源站IP → 获得WAF提供的CNAME地址 → 到DNS处将域名解析改为CNAME指向WAF
• 透明接入（仅限源站在阿里云ECS/SLB）：一键接入，无需改DNS
3. 上传证书（如使用HTTPS接入）

步骤2：防护策略配置

步骤3：验证接入成功

• ping 域名 返回的应是WAF的CNAME/IP，而非源站真实IP
• 构造测试攻击验证拦截：

  curl "https://example.com/?id=1 and 1=1 union select 1,2,3--"

  返回405/拦截页 = WAF正常工作 

自建方案补充：雷池SafeLine（预算为零+有运维能力）

• 开源免费，部署在源站前作为反向代理
• 中文规则库、Web管理界面、支持动态防护
• 适合：源站在自有机房/预算极有限/技术团队较强的企业
• 注意：自建WAF不防大流量DDoS，需与云清洗方案配合

第三层：防DDoS部署方案

3.1 防护架构设计

                    ┌─ 正常用户 ──→ Cloudflare/WAF/CDN ──→ 源站（仅接受回源IP）
互联网流量 ─────────┤
                    └─ 攻击流量 ──→ 云清洗中心自动过滤 ──→ 清洗后流量回注

核心原理： 攻击流量在到达源站之前，被分布式的防护节点吸收和清洗。源站IP保密是整个体系的生命线。

3.2 分场景方案选择

3.3 源站IP隐藏与加固（最关键的一步）

无论用哪家防护，源站加固必须做到：

步骤1：更换源站IP（如旧IP已暴露）

• 云主机新购弹性IP或迁移至新实例
• 新IP仅告知运维负责人，禁止出现在邮件签名、旧文档、公开仓库中

步骤2：安全组/防火墙仅放行防护平台回源IP段

# 阿里云安全组示例：仅放行WAF回源网段 + 办公网IP的SSH
# 入方向规则：
#   443/tcp  ← WAF回源IP段（阿里云官方公布的网段列表）
#   80/tcp   ← WAF回源IP段
#   22/tcp   ← 公司固定出口IP
#   其余全部拒绝

# 自建服务器 iptables 等效配置：
iptables -A INPUT -p tcp --dport 80  -s <WAF回源网段1> -j ACCEPT
iptables -A INPUT -p tcp --dport 80  -s <WAF回源网段2> -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s <WAF回源网段1> -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s <WAF回源网段2> -j ACCEPT
iptables -A INPUT -p tcp --dport 22  -s <公司出口IP>   -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j DROP

步骤3：堵住IP泄露渠道

• 子域名（如 mail.example.com、test.example.com）不要直接A记录到源站IP，否则攻击者通过子域名扫描即可反查源站
• 邮件服务器发信头会带源站IP → 使用独立邮件服务（阿里企业邮/腾讯企业邮）
• 网站程序主动外连的接口（如短信回调）不要暴露真实IP
• 历史DNS解析记录会被第三方数据库（如SecurityTrails）存档 → 这也是必须换IP的原因

步骤4：CC攻击专项防护

CC（应用层DDoS）是最常见的企业站攻击形式，重点配置：

静态化：首页/产品页HTML缓存（Cloudflare Cache Rule：缓存1小时）
   → 攻击打到缓存节点，源站零压力
限频：单IP访问首页 ≤30次/分钟，搜索页 ≤10次/分钟，登录 ≤5次/分钟
质询：超过阈值先出JS Challenge/验证码，而非直接封禁（减少误杀）
UA+行为过滤：拦截无UA、无Referer、不加载JS/CSS的裸请求特征
弹性预案：与云厂商确认攻击时快速升级高防的通道（分钟级生效）

第四层：验证与演练——部署完≠防护住

4.1 部署验收清单

4.2 攻击应急预案（贴到运维手册里）

遭受攻击时的标准动作

【发现异常】流量激增 / 网站变慢 / 收到云厂商攻击告警

确认攻击类型（5分钟内）
   - 带宽被打满（L3/L4）→ 检查是否直打源站IP
   - 请求数暴增但带宽正常（CC/L7）→ 查看WAF攻击日志

若攻击绕过防护直打源站：
   → 说明源站IP泄露！立即：
   ① 云厂商一键切换DDoS高防/黑洞解除
   ② 更换源站IP + 更新防护平台回源配置
   ③ 排查泄露渠道（子域名/邮件/DNS历史）

若为CC攻击：
   → WAF限频阈值临时调低（如30次/分→10次/分）
   → 对攻击特征（UA/地区/ASN）加临时封禁规则
   → 提高静态缓存覆盖率，降低源站负载

全程记录时间线，攻击结束后48小时内复盘：
   → 更新防护规则 / 修订预案 / 必要时升级防护套餐

成本测算：三档方案年度投入参考

决策建议： 从标准版起步，遭遇实际攻击后再按需升级增强版。安全投入的原则是"匹配风险"，而非"越贵越好"。

总结：一周部署时间表

安全加固的本质是把攻击成本抬高到超过攻击收益。完成这套三层部署后，你的网站将免疫绝大多数自动化扫描、注入攻击和普通DDoS——这已经超过了90%的企业网站防护水平。

相关标签：