Day-013-负载均衡器安全配置

# Day 12: 负载均衡器安全配置

> 网络安全系列第 12 天 | 预计阅读时间：35 分钟 | 难度：★★★★☆

---

## 清单 目录

1. [引言](#引言)
2. [负载均衡基础](#负载均衡基础)
3. [L4 vs L7 负载均衡](#l4-vs-l7负载均衡)
4. [SSL/TLS 卸载安全](#ssltls卸载安全)
5. [健康检查安全](#健康检查安全)
6. [DDoS 防护集成](#ddos防护集成)
7. [会话保持安全](#会话保持安全)
8. [WAF 集成](#waf集成)
9. [实验环境搭建](#实验环境搭建)
10. [实战演练](#实战演练)
11. [防护策略与最佳实践](#防护策略与最佳实践)
12. [总结与思考](#总结与思考)
13. [参考资料](#参考资料)

---

## 引言

### 负载均衡器的安全价值

负载均衡器（Load Balancer，LB）不仅是流量分发设备，更是网络安全架构的关键组件。在现代 Web 架构中，LB 通常位于 DMZ 区域，是用户流量的第一道关口。

**核心安全价值**：
-  **隐藏后端架构**：外部无法直接访问后端服务器
-  **DDoS 第一道防线**：吸收和清洗攻击流量
-  **集中安全策略**：SSL 卸载、WAF、访问控制
- 统计 **流量可视化**：集中日志和监控
-  **认证卸载**：处理 TLS 握手，减轻后端压力

**真实案例**：
- **2020 年 AWS ELB 配置错误**：某公司因 ELB 日志未启用，无法追踪 DDoS 攻击来源
- **2019 年 F5 BIG-IP 漏洞**：CVE-2019-4491 允许远程代码执行，影响数万设备
- **2021 年 Nginx 缓冲区溢出**：CVE-2021-23017 可能导致 DNS 解析器崩溃

### 负载均衡器类型对比

| 类型 | 代表产品 | 优势 | 安全特性 |
|------|----------|------|----------|
| **硬件 LB** | F5 BIG-IP, Citrix ADC | 高性能、专用硬件 | DDoS 防护、WAF、高级 SSL |
| **软件 LB** | Nginx, HAProxy | 灵活、成本低 | 基础 SSL、限流、ACL |
| **云 LB** | AWS ELB, Azure LB | 弹性、免运维 | 集成云安全、自动扩展 |
| **服务网格** | Istio, Linkerd | 微服务原生 | mTLS、细粒度策略 |

---

## 负载均衡基础

### 负载均衡工作原理

```
用户请求流程：

1. 用户发起请求
   client → www.example.com

2. DNS 解析到 LB
   DNS → LB 公网 IP (203.0.113.1)

3. LB 选择后端服务器
   算法：轮询、最少连接、IP 哈希等

4. 转发请求到后端
   LB → backend-1 (192.168.1.10)

5. 后端响应通过 LB 返回
   backend-1 → LB → client
```

### 常见负载均衡算法

#### 1. 轮询（Round Robin）

```
请求 1 → Backend-1
请求 2 → Backend-2
请求 3 → Backend-3
请求 4 → Backend-1
...

优点：简单、公平
缺点：不考虑服务器负载
适用：服务器性能相近
```

#### 2. 最少连接（Least Connections）

```
Backend-1: 10 个连接
Backend-2: 5 个连接
Backend-3: 20 个连接

新请求 → Backend-2（连接数最少）

优点：动态适应负载
缺点：需要维护连接状态
适用：长连接场景
```

#### 3. IP 哈希（IP Hash）

```
client_ip = 192.168.1.100
hash = hash(client_ip) % 3  # 3 台后端
hash = 1 → Backend-2

优点：会话保持
缺点：负载可能不均衡
适用：需要会话粘性
```

#### 4. 加权轮询（Weighted Round Robin）

```
Backend-1 (权重 3): ★★★
Backend-2 (权重 2): ★★
Backend-3 (权重 1): ★

请求分配：
1→B1, 2→B1, 3→B1, 4→B2, 5→B2, 6→B3

优点：考虑服务器性能差异
缺点：配置复杂
适用：异构服务器环境
```

---

## L4 vs L7 负载均衡

### L4 负载均衡（传输层）

**工作层次**：OSI 第 4 层（TCP/UDP）

**决策依据**：
- 源/目标 IP 地址
- 源/目标端口
- 协议类型（TCP/UDP）

**优点**：
```
✓ 高性能：不解析应用层数据
✓ 低延迟：简单转发
✓ 协议无关：支持任意 TCP/UDP 应用
✓ 配置简单：无需了解应用协议
```

**缺点**：
```
✗ 无法基于内容路由
✗ 无法检查 HTTP 头
✗ SSL 卸载困难
✗ DDoS 防护有限
```

**典型场景**：
- 数据库负载均衡
- 邮件服务器（SMTP/IMAP）
- 游戏服务器
- VoIP 服务

### L7 负载均衡（应用层）

**工作层次**：OSI 第 7 层（HTTP/HTTPS 等）

**决策依据**：
- URL 路径
- HTTP 头
- Cookie
- 请求方法
- 用户代理
- 认证信息

**优点**：
```
✓ 内容感知路由
✓ SSL 卸载集中管理
✓ WAF 集成
✓ 细粒度访问控制
✓ 压缩和缓存
```

**缺点**：
```
✗ 性能开销（10-30%）
✗ 配置复杂
✗ 需要解析应用协议
✗ 隐私合规考虑
```

**典型场景**：
- Web 应用
- API 网关
- 微服务路由
- 多租户 SaaS

### 性能对比测试

```bash
# 测试环境
- 客户端：10 个并发连接
- 后端：3 台 Nginx 服务器
- 请求：HTTP GET /index.html (1KB)

# L4 负载均衡（HAProxy TCP 模式）
ab -n 10000 -c 10 http://lb-l4/
# 结果：15000 req/s, 平均延迟 0.6ms

# L7 负载均衡（HAProxy HTTP 模式）
ab -n 10000 -c 10 http://lb-l7/
# 结果：12000 req/s, 平均延迟 0.8ms

# L7 + SSL 卸载
ab -n 10000 -c 10 https://lb-l7-ssl/
# 结果：8000 req/s, 平均延迟 1.2ms

结论：
- L4 比 L7 性能高 25%
- SSL 卸载额外开销 33%
- 根据需求选择合适层级
```

---

## SSL/TLS 卸载安全

### 卸载架构详解

```
传统架构（后端 SSL）：
client ──HTTPS──→ LB ──HTTPS──→ Backend
        (加密)       (加密)
优点：端到端加密
缺点：后端 CPU 开销大，证书管理复杂

SSL 卸载架构：
client ──HTTPS──→ LB ──HTTP──→ Backend
        (加密)       (明文)
优点：后端性能释放，集中证书管理
缺点：LB 到后端明文（需内网保护）

SSL 桥接架构：
client ──HTTPS──→ LB ──HTTPS──→ Backend
        (TLS 1.3)     (TLS 1.2)
优点：全程加密，灵活控制
缺点：两次 SSL 握手开销
```

### Nginx SSL 卸载配置

```nginx
# /etc/nginx/nginx.conf
events {
    worker_connections 4096;
    multi_accept on;
}

http {
    # SSL 全局配置
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;  # 禁用会话票据（安全）
    
    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
    
    # HSTS（强制 HTTPS）
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    
    # 安全头部
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    
    # 后端服务器组
    upstream backend {
        least_conn;  # 最少连接算法
        server 192.168.1.10:80 weight=3 max_fails=3 fail_timeout=30s;
        server 192.168.1.11:80 weight=3 max_fails=3 fail_timeout=30s;
        server 192.168.1.12:80 weight=2 max_fails=3 fail_timeout=30s backup;
        
        # 保持连接
        keepalive 32;
    }
    
    # HTTP 重定向到 HTTPS
    server {
        listen 80;
        server_name example.com;
        return 301 https://$server_name$request_uri;
    }
    
    # HTTPS 服务器
    server {
        listen 443 ssl http2;
        server_name example.com;
        
        # 证书配置
        ssl_certificate /etc/nginx/ssl/example.com.crt;
        ssl_certificate_key /etc/nginx/ssl/example.com.key;
        ssl_trusted_certificate /etc/nginx/ssl/chain.pem;
        
        # DH 参数（防止 Logjam 攻击）
        ssl_dhparam /etc/nginx/ssl/dhparam.pem;
        
        location / {
            proxy_pass http://backend;
            
            # 传递真实客户端信息
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-Port $server_port;
            
            # 超时配置
            proxy_connect_timeout 5s;
            proxy_send_timeout 10s;
            proxy_read_timeout 10s;
            
            # 缓冲配置
            proxy_buffering on;
            proxy_buffer_size 4k;
            proxy_buffers 8 4k;
        }
        
        # 健康检查端点
        location /health {
            access_log off;
            return 200 "healthy\n";
            add_header Content-Type text/plain;
        }
    }
}
```

### 证书管理最佳实践

```bash
# 1. 生成强密钥（RSA 2048+ 或 ECDSA P-256+）
# RSA
openssl genrsa -out server.key 2048

# ECDSA（推荐，性能更好）
openssl ecparam -genkey -name prime256v1 -out server.key

# 2. 生成 CSR
openssl req -new -key server.key -out server.csr \
  -subj "/C=CN/ST=Beijing/L=Beijing/O=Company/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

# 3. 使用 Let's Encrypt（免费证书）
apt install certbot
certbot certonly --nginx -d example.com -d www.example.com

# 4. 证书轮换脚本
#!/bin/bash
# /etc/cron.monthly/cert-renew.sh
certbot renew --quiet --post-hook "systemctl reload nginx"

# 5. 监控证书过期
# /etc/cron.daily/cert-check
#!/bin/bash
EXPIRY=$(echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ $DAYS_LEFT -lt 30 ]; then
  echo "警告：证书将在 $DAYS_LEFT 天后过期" | mail -s "证书过期警告" admin@example.com
fi
```

### 后端加密（mTLS）

```nginx
# LB 到后端也使用 HTTPS（推荐）
upstream backend {
    server 192.168.1.10:443;
    server 192.168.1.11:443;
}

server {
    listen 443 ssl http2;
    
    location / {
        proxy_pass https://backend;
        
        # 客户端证书（mTLS）
        proxy_ssl_certificate /etc/nginx/ssl/client.crt;
        proxy_ssl_certificate_key /etc/nginx/ssl/client.key;
        proxy_ssl_trusted_certificate /etc/nginx/ssl/ca.crt;
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 2;
        proxy_ssl_session_reuse on;
    }
}
```

---

## 健康检查安全

### 健康检查类型

#### 1. 被动健康检查

```
原理：监控后端响应
- 检测连接失败
- 检测 HTTP 状态码
- 检测响应时间

配置（Nginx）：
upstream backend {
    server 192.168.1.10 max_fails=3 fail_timeout=30s;
    server 192.168.1.11 max_fails=3 fail_timeout=30s;
}

优点：无需额外配置
缺点：发现问题较慢
```

#### 2. 主动健康检查

```
原理：定期发送探测请求
- HTTP GET /health
- TCP 连接测试
- 自定义脚本

配置（Nginx Plus）：
upstream backend {
    zone backend_zone 64k;
    server 192.168.1.10;
    server 192.168.1.11;
    
    health_check interval=10s fails=3 passes=2 uri=/health match=status_ok;
}

match status_ok {
    status 200;
}

优点：快速发现问题
缺点：增加后端负载
```

### 健康检查端点安全

```bash
# 1. 限制访问来源
# Nginx 配置
location /health {
    allow 10.0.1.0/24;  # 仅允许 LB IP
    allow 127.0.0.1;
    deny all;
    
    return 200 "OK\n";
    add_header Content-Type text/plain;
}

# 2. 简化响应内容
# 不返回敏感信息（版本号、主机名、路径等）
# 错误：return 200 "Backend-1 v1.2.3 healthy"
# 正确：return 200 "OK"

# 3. 限制请求速率
location /health {
    limit_req zone=health_limit burst=5 nodelay;
    return 200 "OK\n";
}

# 在 http 块定义限流区域
limit_req_zone $binary_remote_addr zone=health_limit:10m rate=10r/s;

# 4. 记录健康检查日志
location /health {
    access_log /var/log/nginx/health.log health_format;
    return 200 "OK\n";
}

log_format health_format '$remote_addr - $request - $status';
```

### 健康检查攻击防护

```
攻击场景：
1. 健康检查洪水
   - 攻击者伪装成 LB
   - 大量健康检查请求
   - 后端资源耗尽

2. 健康检查注入
   - 利用健康检查端点
   - 执行未授权操作
   - 信息泄露

3. 健康检查绕过
   - 应用层健康但业务异常
   - 数据库连接池耗尽
   - 依赖服务不可用

防护措施：
✓ 限制健康检查来源 IP
✓ 限制请求速率
✓ 简化响应内容
✓ 记录所有访问
✓ 实现深度健康检查
```

---

## DDoS 防护集成

### 多层防护架构

```
┌─────────────────────────────────────────────────────┐
│              云端防护（Cloudflare/AWS Shield）        │
│         Tbps 级别防护，地理分布清洗                   │
└─────────────────────┬───────────────────────────────┘
                      │
         ┌────────────▼────────────┐
         │      边界防火墙          │
         │   SYN Cookie, 速率限制    │
         └────────────┬────────────┘
                      │
         ┌────────────▼────────────┐
         │    负载均衡器            │
         │   连接限制，HTTP Flood   │
         └────────────┬────────────┘
                      │
         ┌────────────▼────────────┐
         │      WAF                 │
         │   应用层攻击防护          │
         └────────────┬────────────┘
                      │
         ┌────────────▼────────────┐
         │      后端服务器          │
         │   应用层限流              │
         └─────────────────────────┘
```

### Nginx 限流配置

```nginx
http {
    # 1. 连接数限制（防连接耗尽）
    limit_conn_zone $binary_remote_addr zone=addr:10m;
    limit_conn addr 10;  # 每 IP 最多 10 个并发连接
    limit_conn_status 429;
    
    # 2. 请求速率限制（防 HTTP Flood）
    limit_req_zone $binary_remote_addr zone=req:10m rate=10r/s;
    limit_req zone=req burst=20 nodelay;
    limit_req_status 429;
    
    # 3. 按地理位置限流
    geo $limit_zone {
        default $binary_remote_addr;
        192.168.1.0/24 "";  # 内网不限流
    }
    limit_req_zone $limit_zone zone=geo:10m rate=5r/s;
    
    # 4. URI 特定限流（保护敏感接口）
    limit_req_zone $binary_remote_addr zone=login:10m rate=1r/s;
    
    server {
        # 应用限流
        location / {
            limit_conn addr 10;
            limit_req zone=req burst=20;
        }
        
        # 登录接口严格限流
        location /api/login {
            limit_req zone=login burst=5 nodelay;
            
            # 失败延迟（增加攻击成本）
            limit_req_dry_run off;
        }
        
        # 静态资源宽松限流
        location /static/ {
            limit_req zone=req burst=50;
            limit_conn addr 20;
        }
        
        # API 限流
        location /api/ {
            limit_req zone=req burst=30;
            
            # 白名单（合作伙伴 API）
            geo $whitelist {
                default 0;
                203.0.113.0/24 1;  # 合作伙伴 IP
            }
            if ($whitelist) {
                set $limit_rate 0;
            }
        }
    }
}
```

### SYN Flood 防护

```bash
# Linux 内核参数优化
# /etc/sysctl.d/99-syn-flood.conf

# 启用 SYN Cookies
net.ipv4.tcp_syncookies = 1

# 增加 SYN 队列大小
net.ipv4.tcp_max_syn_backlog = 8192

# 减少 SYN-ACK 重试次数
net.ipv4.tcp_synack_retries = 2

# 启用时间戳（帮助识别伪造包）
net.ipv4.tcp_timestamps = 1

# 应用配置
sysctl -p /etc/sysctl.d/99-syn-flood.conf

# iptables SYN 防护
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
```

### 应用层 DDoS 防护

```nginx
# 1. 识别恶意 User-Agent
map $http_user_agent $bad_bot {
    default 0;
    ~*curl 1;
    ~*wget 1;
    ~*python 1;
    ~*scanner 1;
    ~*nikto 1;
    ~*sqlmap 1;
    "" 1;  # 空 User-Agent
}

server {
    if ($bad_bot) {
        return 403;
    }
    
    # 2. 挑战 - 响应（JavaScript 验证）
    # 使用 lua-nginx-module 或第三方模块
    # 对可疑请求返回 JavaScript 挑战
    
    # 3. 慢速攻击防护
    client_body_timeout 10s;
    client_header_timeout 10s;
    send_timeout 10s;
    
    # 4. 请求大小限制
    client_max_body_size 10m;
    client_body_buffer_size 128k;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
}
```

---

## 会话保持安全

### 会话保持方法对比

| 方法 | 原理 | 优点 | 缺点 | 安全考虑 |
|------|------|------|------|----------|
| **Cookie 注入** | LB 插入 Cookie | 精确控制 | 增加响应大小 | Cookie 泄露风险 |
| **Cookie 学习** | 学习应用 Cookie | 无需修改应用 | 依赖应用 | Cookie 加密 |
| **IP 粘性** | 源 IP 哈希 | 简单 | NAT 问题 | IP 欺骗 |
| **SSL Session ID** | SSL 会话复用 | 安全 | 仅 HTTPS | 会话票据风险 |

### Cookie 注入配置

```nginx
upstream backend {
    ip_hash;  # IP 哈希保持
    server 192.168.1.10;
    server 192.168.1.11;
}

server {
    location / {
        proxy_pass http://backend;
        
        # 插入会话 Cookie（Nginx Plus）
        # stickiness cookie name=SERVERID expires=1h;
        
        # 开源替代方案：使用 lua 模块
        # lua_need_request_body off;
        # access_by_lua_block {
        #     if not ngx.var.cookie_SERVERID then
        #         ngx.header["Set-Cookie"] = "SERVERID=" .. ngx.var.upstream_addr .. "; Path=/; HttpOnly; Secure"
        #     end
        # }
    }
}
```

### 会话安全最佳实践

```
1. Cookie 安全属性
   Set-Cookie: SERVERID=backend1;
     Path=/;
     HttpOnly;        # 禁止 JavaScript 访问
     Secure;          # 仅 HTTPS
     SameSite=Strict; # 防 CSRF
     Max-Age=3600     # 1 小时过期

2. 会话超时
   - 绝对超时：24 小时
   - 空闲超时：30 分钟
   - 滑动超时：每次访问重置

3. 会话轮换
   - 登录后更换会话 ID
   - 权限变更时更换
   - 定期轮换

4. 会话监控
   - 记录会话创建/销毁
   - 检测异常会话活动
   - 并发会话限制
```

---

## WAF 集成

### ModSecurity 配置

```nginx
# 安装 ModSecurity
apt install libnginx-mod-modsecurity modsecurity

# 启用 ModSecurity
# /etc/nginx/modsec/modsecurity.conf
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

# 日志配置
SecAuditLog /var/log/modsec_audit.log
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial

# OWASP CRS 规则集
# /etc/nginx/modsec/crs-setup.conf
Include /etc/nginx/modsec/coreruleset/crs-setup.conf
Include /etc/nginx/modsec/coreruleset/rules/*.conf

# 自定义规则
# /etc/nginx/modsec/custom-rules.conf
SecRule REQUEST_URI "@streq /admin" \
  "id:1001,\
   phase:1,\
   deny,\
   status:403,\
   msg:'Admin access blocked'"

SecRule ARGS "@detectSQLi" \
  "id:1002,\
   phase:2,\
   deny,\
   status:403,\
   msg:'SQL Injection detected'"

SecRule ARGS "@detectXSS" \
  "id:1003,\
   phase:2,\
   deny,\
   status:403,\
   msg:'XSS detected'"
```

### WAF 规则调优

```
误报处理流程：

1. 识别误报
   - 检查审计日志
   - 分析触发规则
   - 确认正常请求

2. 创建例外
   SecRule REQUEST_URI "@streq /api/special" \
     "id:10000,\
      phase:1,\
      pass,\
      nolog,\
      ctl:ruleRemoveById=942100"

3. 调整规则
   # 降低规则严重性
   SecRuleUpdateActionById 942100 "severity:WARNING"

4. 测试验证
   # 使用真实流量测试
   # 监控误报率

5. 持续监控
   # 定期审查日志
   # 更新规则集
```

---

## 实验环境搭建

### Docker Compose 环境

```yaml
version: '3.8'

services:
  # Nginx 负载均衡器
  nginx-lb:
    image: nginx:alpine
    container_name: nginx-lb
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./ssl:/etc/nginx/ssl:ro
      - ./logs:/var/log/nginx
    networks:
      - frontend
      - backend
    depends_on:
      - web1
      - web2
      - web3

# 后端 Web 服务器 1
  web1:
    image: httpd:alpine
    container_name: web1
    volumes:
      - ./web1/htdocs:/usr/local/apache2/htdocs:ro
    networks:
      - backend
    labels:
      - "app.name=web"
      - "app.id=1"

# 后端 Web 服务器 2
  web2:
    image: httpd:alpine
    container_name: web2
    volumes:
      - ./web2/htdocs:/usr/local/apache2/htdocs:ro
    networks:
      - backend
    labels:
      - "app.name=web"
      - "app.id=2"

# 后端 Web 服务器 3（备份）
  web3:
    image: httpd:alpine
    container_name: web3
    volumes:
      - ./web3/htdocs:/usr/local/apache2/htdocs:ro
    networks:
      - backend
    labels:
      - "app.name=web"
      - "app.id=3"

# 攻击测试工具
  attacker:
    image: kalilinux/kali-rolling
    container_name: attacker
    command: sleep infinity
    networks:
      - frontend

networks:
  frontend:
    driver: bridge
    ipam:
      config:
        - subnet: 10.0.1.0/24
  backend:
    driver: bridge
    internal: true  # 内部网络，无外网访问
    ipam:
      config:
        - subnet: 192.168.1.0/24
```

### SSL 证书生成

```bash
# 创建自签名证书（测试用）
mkdir -p ssl
cd ssl

# 生成私钥
openssl genrsa -out server.key 2048

# 生成证书
openssl req -x509 -new -nodes -key server.key \
  -sha256 -days 365 \
  -out server.crt \
  -subj "/C=CN/ST=Beijing/L=Beijing/O=Test/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

# 生成 DH 参数（防止 Logjam 攻击）
openssl dhparam -out dhparam.pem 2048

# 设置权限
chmod 600 server.key
chmod 644 server.crt dhparam.pem
```

---

## 实战演练

### 实验 1: 基础负载均衡配置

**目标**：验证负载均衡功能

**步骤**：

```bash
# 1. 启动环境
cd /path/to/lab
docker-compose up -d

# 2. 验证后端服务
curl http://web1
curl http://web2
curl http://web3

# 3. 测试负载均衡
for i in {1..10}; do
  curl -s http://localhost | grep "Hostname"
done

# 预期输出（轮询）：
# Hostname: web1
# Hostname: web2
# Hostname: web3
# Hostname: web1
# ...

# 4. 检查 Nginx 状态
docker exec nginx-lb nginx -t
docker exec nginx-lb nginx -s reload

# 5. 查看访问日志
docker exec nginx-lb tail -f /var/log/nginx/access.log
```

### 实验 2: SSL 卸载配置

**目标**：配置 HTTPS 并验证卸载

**步骤**：

```bash
# 1. 配置 SSL（见前文 Nginx 配置）

# 2. 测试 HTTP 重定向
curl -I http://localhost
# 应返回 301 到 HTTPS

# 3. 测试 HTTPS
curl -kI https://localhost
# 应返回 200 OK

# 4. 验证 SSL 配置
openssl s_client -connect localhost:443 -tls1_2
openssl s_client -connect localhost:443 -tls1_3

# 5. 检查 SSL  Labs 评级（公网）
# https://www.ssllabs.com/ssltest/

# 6. 验证后端收到的是 HTTP
docker exec web1 tail -f /usr/local/apache2/logs/access_log
# 应看到 HTTP 请求，非 HTTPS
```

### 实验 3: DDoS 防护测试

**目标**：验证限流效果

**步骤**：

```bash
# 1. 正常请求测试
for i in {1..5}; do
  curl -s -o /dev/null -w "%{http_code}\n" http://localhost
done
# 应全部返回 200

# 2. 压力测试（ab）
ab -n 1000 -c 50 http://localhost/
# 观察响应时间和错误率

# 3. 限流测试
# 快速发送大量请求
for i in {1..100}; do
  curl -s -o /dev/null -w "%{http_code} " http://localhost &
done
wait
# 应看到部分 429 Too Many Requests

# 4. 检查日志
docker exec nginx-lb tail -f /var/log/nginx/error.log
# 应看到限流相关日志

# 5. SYN Flood 模拟（谨慎使用）
# 在隔离环境测试
docker exec attacker hping3 -S -p 80 --flood localhost
# 观察服务器响应
```

### 实验 4: 健康检查测试

**目标**：验证故障转移

**步骤**：

```bash
# 1. 初始状态检查
for i in {1..5}; do
  curl -s http://localhost | grep "Hostname"
done

# 2. 停止一个后端
docker stop web1

# 3. 再次测试
for i in {1..5}; do
  curl -s http://localhost | grep "Hostname"
done
# 应只看到 web2 和 web3

# 4. 检查 Nginx 日志
docker exec nginx-lb tail -100 /var/log/nginx/error.log
# 应看到 web1 被标记为不可用

# 5. 恢复后端
docker start web1

# 6. 等待恢复（fail_timeout）
sleep 35

# 7. 验证恢复
for i in {1..5}; do
  curl -s http://localhost | grep "Hostname"
done
# 应重新看到 web1
```

### 实验 5: WAF 规则测试

**目标**：验证 ModSecurity 防护

**步骤**：

```bash
# 1. 测试 SQL 注入防护
curl -I "http://localhost/search?q=1' OR '1'='1"
# 应返回 403 Forbidden

# 2. 测试 XSS 防护
curl -I "http://localhost/search?q=<script>alert(1)</script>"
# 应返回 403 Forbidden

# 3. 测试正常请求
curl -I "http://localhost/search?q=hello+world"
# 应返回 200 OK

# 4. 检查 ModSecurity 日志
docker exec nginx-lb tail -f /var/log/modsec_audit.log
# 应看到攻击被拦截的记录

# 5. 测试误报（调整规则）
# 如果正常请求被拦截，创建例外规则
```

---

## 防护策略与最佳实践

### 安全配置清单

```
□ SSL/TLS 配置
  ✓ TLS 1.2+ 仅
  ✓ 强密码套件
  ✓ HSTS 启用
  ✓ OCSP Stapling
  ✓ 会话票据禁用

□ 访问控制
  ✓ IP 白名单（管理接口）
  ✓ 速率限制
  ✓ 连接限制
  ✓ 请求大小限制

□ 健康检查
  ✓ 限制来源 IP
  ✓ 简化响应
  ✓ 记录日志
  ✓ 速率限制

□ 日志审计
  ✓ 访问日志
  ✓ 错误日志
  ✓ 性能指标
  ✓ 安全事件

□ 监控告警
  ✓ 健康状态
  ✓ 响应时间
  ✓ 错误率
  ✓ 攻击检测
```

### 高可用部署

```yaml
# Keepalived + Nginx 高可用
# /etc/keepalived/keepalived.conf

vrrp_script check_nginx {
    script "/usr/bin/killall -0 nginx"
    interval 2
    fall 3
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    
    authentication {
        auth_type PASS
        auth_pass MySecretPassword
    }
    
    virtual_ipaddress {
        192.168.1.100/24 dev eth0
    }
    
    track_script {
        check_nginx
    }
    
    notify_master "/etc/keepalived/notify_master.sh"
    notify_backup "/etc/keepalived/notify_backup.sh"
    notify_fault "/etc/keepalived/notify_fault.sh"
}
```

### 性能优化

```nginx
# 1. 工作进程优化
worker_processes auto;  # 自动匹配 CPU 核心
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;
    multi_accept on;
    use epoll;
}

# 2. TCP 优化
http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    
    keepalive_timeout 65;
    keepalive_requests 100;
    
    # 开放文件缓存
    open_file_cache max=10000 inactive=30s;
    open_file_cache_valid 60s;
    open_file_cache_min_uses 2;
}

# 3. 缓冲优化
proxy_buffering on;
proxy_buffer_size 4k;
proxy_buffers 8 4k;
proxy_busy_buffers_size 8k;
proxy_temp_file_write_size 64k;
```

---

## 总结与思考

### 核心要点回顾

1. **负载均衡选择**
   - L4：高性能，简单场景
   - L7：功能丰富，Web 应用
   - 根据需求权衡

2. **SSL 卸载安全**
   - 强 TLS 配置
   - 证书管理自动化
   - 考虑后端加密

3. **DDoS 防护**
   - 多层防护架构
   - 速率限制
   - 挑战 - 响应机制

4. **健康检查**
   - 主动 + 被动结合
   - 端点安全保护
   - 快速故障转移

### 深入思考问题

1. **服务网格对 LB 的影响**
   - Istio/Linkerd 提供 L7 负载均衡
   - mTLS 自动注入
   - 细粒度流量控制
   - 传统 LB 如何演进？

2. **边缘计算 LB 架构**
   - CDN 边缘节点负载均衡
   - 低延迟要求
   - 地域感知路由
   - 如何保证一致性？

3. **QUIC/HTTP3 支持**
   - UDP 基础上的可靠传输
   - 0-RTT 握手
   - 多路复用
   - LB 如何适配？

### 实战建议

**中小企业**：
1. 使用云 LB（免运维）
2. 启用基础 WAF
3. 配置 SSL 卸载
4. 监控关键指标

**大型企业**：
1. 自建 LB 集群
2. 高可用部署
3. 深度 WAF 集成
4. 自动化运维

**云原生环境**：
1. 使用 Ingress Controller
2. 服务网格集成
3. mTLS 自动注入
4. GitOps 配置管理

### 下一步学习建议

- **深入 WAF**：ModSecurity 规则编写
- **性能调优**：Nginx 高级配置
- **云 LB**：AWS ALB/NLB 最佳实践
- **服务网格**：Istio 流量管理

---

## 参考资料

### 标准文档
- RFC 8446 (TLS 1.3)
- RFC 7540 (HTTP/2)
- OWASP WAF Cheat Sheet

### 工具资源
- [Nginx 官方文档](https://nginx.org/en/docs/)
- [HAProxy 文档](http://www.haproxy.org/)
- [ModSecurity 手册](https://github.com/owasp-modsecurity/ModSecurity)
- [OWASP CRS](https://coreruleset.org/)

### 在线资源
- [SSL Labs 测试](https://www.ssllabs.com/ssltest/)
- [Mozilla SSL 配置生成器](https://ssl-config.mozilla.org/)
- [Nginx 性能优化指南](https://www.nginx.com/resources/admin-guide/nginx-performance-optimization/)

### 书籍推荐
- 《Nginx 完全指南》
- 《HAProxy 权威指南》
- 《Web 应用防火墙实战》

---

**标记 明日预告**：Day 13 - CDN 安全与防护

> 本文内容仅供学习和研究使用，请勿用于非法目的。所有实验请在隔离环境中进行。

---

*本文是 365 天信息安全技术系列的第 12 篇，精编版本*