跳到主要内容

9. Security Considerations (安全性考虑)

L2TP 协议本身并不提供加密或强认证服务。本章讨论 L2TP 部署中的安全性考虑以及可用的安全机制。

9.1 Tunnel Endpoint Security (隧道端点安全)​

隧道端点之间的信任关系是 L2TP 安全性的基础。

端点认证 (Endpoint Authentication):

LAC 和 LNS 必须能够验证对端的身份。L2TP 提供了一个可选的隧道认证机制：

  • Challenge AVP: 发起方在 SCCRQ（Start-Control-Connection-Request）中发送一个随机挑战值。
  • Challenge Response AVP: 响应方计算基于共享密钥的响应并在 SCCRP（Start-Control-Connection-Reply）中返回。
  • 响应计算: 使用 MD5 哈希函数：MD5(Message Type + shared_secret + Challenge + Session_ID)

共享密钥管理 (Shared Secret Management):

  • 共享密钥应该具有足够的熵（建议至少 128 位）。
  • 共享密钥应该安全存储（加密存储）。
  • 应该定期更换共享密钥。
  • 不同的隧道对应该使用不同的共享密钥。

隧道授权 (Tunnel Authorization):

除了认证之外，还应该实施授权机制：

  • 验证对端是否被允许建立隧道。
  • 检查对端是否有权限访问特定的资源或服务。
  • 使用访问控制列表（ACL）限制哪些对端可以建立隧道。

漏洞和缓解措施 (Vulnerabilities and Mitigations):

  1. 中间人攻击 (Man-in-the-Middle Attack):

    • 风险: L2TP 隧道认证基于共享密钥，容易受到中间人攻击。
    • 缓解: 使用 IPsec 提供端到端的加密和认证。

  2. 重放攻击 (Replay Attack):

    • 风险: 攻击者可能重放捕获的控制消息。
    • 缓解: 使用序列号和 ZLB ACK 机制来检测和防止重放攻击。

  3. 拒绝服务攻击 (Denial of Service Attack):

    • 风险: 攻击者可能发送大量的隧道建立请求。
    • 缓解:
      • 限制每个源地址的并发隧道数量。
      • 实施速率限制。
      • 使用 Cookie 机制（类似 TCP SYN Cookie）。

9.2 Packet Level Security (数据包级安全)​

L2TP 本身不提供数据包加密或完整性保护。

明文传输的风险 (Risks of Cleartext Transmission):

  • 窃听 (Eavesdropping): 攻击者可以拦截和读取 PPP 数据包内容，包括用户凭证和应用数据。
  • 篡改 (Tampering): 攻击者可以修改传输中的数据包。
  • 注入 (Injection): 攻击者可以向隧道注入恶意数据包。

AVP 隐藏机制 (AVP Hiding Mechanism):

L2TP 提供了一个 AVP 隐藏机制来保护敏感的控制信息：

  • 隐藏过程 (Hiding Process):

    1. 使用共享密钥和随机向量（Random Vector）生成 MD5 哈希。
    2. 将哈希值与 AVP 值进行 XOR 运算。
    3. 如果 AVP 值长度超过 16 字节，重复上述过程。

  • 限制 (Limitations):

    • AVP 隐藏只是混淆（obfuscation），不是真正的加密。
    • 不保护数据通道，只保护控制通道中的特定 AVP。
    • 容易受到字典攻击（如果共享密钥弱）。

建议 (Recommendations):

  • 不要依赖 AVP 隐藏作为唯一的安全机制。
  • 使用 IPsec 或其他隧道级加密技术。

9.3 End to End Security (端到端安全)​

即使 L2TP 隧道本身受到保护，端到端安全仍然很重要。

PPP 层认证 (PPP-Level Authentication):

远程系统和 LNS 之间应该进行独立的认证：

  • PAP (Password Authentication Protocol):

    • 简单的明文密码认证。
    • 不建议使用，因为密码以明文传输（即使在加密的 L2TP 隧道内也应避免）。

  • CHAP (Challenge Handshake Authentication Protocol):

    • 基于挑战-响应的认证机制。
    • 密码不以明文传输。
    • 定期重新认证以防止重放攻击。

  • EAP (Extensible Authentication Protocol):

    • 支持多种认证方法（EAP-TLS, EAP-TTLS, PEAP 等）。
    • 可以提供双向认证和密钥协商。
    • 推荐使用 EAP-TLS 提供最强的安全性。

端到端加密 (End-to-End Encryption):

应用层加密提供了额外的安全层：

  • TLS/SSL: 用于保护应用数据（如 HTTPS）。
  • VPN 客户端软件: 在 PPP 之上提供额外的加密层。

多层防御策略 (Defense in Depth):

远程系统 <--PPP认证/加密--> LNS
    |                           |
    +--<L2TP隧道>--LAC--------+
              |
         <IPsec保护>
  • 第1层: PPP 层认证（CHAP/EAP）
  • 第2层: L2TP 隧道认证
  • 第3层: IPsec 加密和认证
  • 第4层: 应用层加密（TLS/SSL）

9.4 L2TP and IPsec (L2TP 与 IPsec)​

强烈建议将 L2TP 与 IPsec 结合使用，这种组合通常称为 L2TP/IPsec。

IPsec 提供的安全服务 (Security Services Provided by IPsec):

  1. 机密性 (Confidentiality):

    • 通过 ESP（Encapsulating Security Payload）提供加密。
    • 支持多种加密算法：AES, 3DES, ChaCha20 等。

  2. 完整性 (Integrity):

    • 通过 AH（Authentication Header）或 ESP 认证提供。
    • 使用 HMAC（如 HMAC-SHA256）验证数据完整性。

  3. 源认证 (Source Authentication):

    • 验证数据包来源的真实性。
    • 防止 IP 欺骗攻击。

  4. 防重放 (Anti-Replay):

    • 使用序列号防止重放攻击。

L2TP/IPsec 架构 (L2TP/IPsec Architecture):

+-------------------+
|   PPP Payload     |
+-------------------+
|   L2TP Header     |
+-------------------+
|   UDP Header      |
+-------------------+
|   ESP Header      | <-- IPsec 加密和认证
+-------------------+
|   IP Header       |
+-------------------+

IPsec 配置选项 (IPsec Configuration Options):

  • 传输模式 (Transport Mode):

    • 只加密和认证 IP 载荷。
    • 适用于端到端通信。
    • 推荐用于 L2TP/IPsec。

  • 隧道模式 (Tunnel Mode):

    • 加密和认证整个 IP 数据包。
    • 添加新的外部 IP 头部。
    • 适用于网关到网关通信。

密钥管理 (Key Management):

  • IKE (Internet Key Exchange):

    • IKEv1: 原始版本，两阶段协商。
    • IKEv2: 改进版本，更简洁和高效。
    • 推荐使用 IKEv2 进行密钥协商。

  • 预共享密钥 vs 证书:

    • 预共享密钥 (PSK): 配置简单，但密钥分发困难。
    • 证书 (Certificates): 更安全，支持大规模部署，强烈推荐。

NAT 穿越 (NAT Traversal - NAT-T):

当 L2TP/IPsec 需要穿越 NAT 设备时：

  • 使用 UDP 封装 ESP（UDP port 4500）。
  • 定期发送 NAT keepalive 数据包。
  • IKEv2 内置 NAT-T 支持。

性能考虑 (Performance Considerations):

  • IPsec 加密会增加 CPU 开销。
  • 考虑使用硬件加速（AES-NI 等）。
  • MTU 减少需要考虑（ESP 头部 + ESP 尾部 + 认证数据）。

9.5 Proxy PPP Authentication (代理 PPP 认证)​

L2TP 允许 LAC 代表 LNS 进行初始的 PPP 认证。

代理认证机制 (Proxy Authentication Mechanism):

LAC 可以在转发呼叫到 LNS 之前与远程系统协商 LCP 和进行认证：

  1. LAC 执行 PPP 认证:

    • LAC 与远程系统协商 LCP。
    • LAC 执行 PAP 或 CHAP 认证。
    • LAC 收集认证信息（用户名、密码哈希等）。

  2. LAC 转发认证信息到 LNS:

    • 使用代理 AVP 传递认证信息：
      • Proxy Authen Type AVP (29): 认证类型（PAP, CHAP, etc.）
      • Proxy Authen Name AVP (30): 用户名
      • Proxy Authen Challenge AVP (31): CHAP 挑战值
      • Proxy Authen Response AVP (33): 认证响应

  3. LNS 验证认证信息:

    • LNS 根据 LAC 提供的信息验证用户。
    • LNS 可以接受或拒绝会话。

安全风险 (Security Risks):

  1. LAC 妥协 (LAC Compromise):

    • 如果 LAC 被攻破，攻击者可以获取用户凭证。
    • 缓解: 使用 IPsec 保护 LAC 和 LNS 之间的通信。

  2. 密码明文传输 (Cleartext Password Transmission):

    • PAP 密码以明文形式从 LAC 传到 LNS（在 AVP 中）。
    • 缓解: 使用 AVP 隐藏机制或 IPsec 加密。

  3. 信任边界 (Trust Boundary):

    • LNS 必须完全信任 LAC 提供的认证信息。
    • 恶意的 LAC 可以伪造认证信息。
    • 缓解:
      • 只在受信任的管理域之间使用代理认证。
      • 考虑要求端到端的重新认证。

最佳实践 (Best Practices):

  1. 避免代理 PAP 认证:

    • PAP 密码即使被隐藏也容易受到攻击。
    • 如果必须使用，确保使用 IPsec 保护。

  2. 优先使用端到端认证:

    • 让远程系统直接与 LNS 进行认证（不通过代理）。
    • 使用 EAP 方法提供更强的安全性。

  3. 限制代理认证的使用场景:

    • 仅在必要时使用（如快速呼叫建立）。
    • 在受信任的网络环境中使用。

  4. 结合使用多种认证方法:

    • LAC 进行初步认证（用于快速筛选）。
    • LNS 进行二次认证（端到端验证）。

代理认证与 RADIUS 集成 (Proxy Authentication with RADIUS):

远程系统 <--PAP/CHAP--> LAC <--RADIUS--> RADIUS服务器
                         |
                         |
                         v
                   (转发认证信息)
                         |
                         v
                        LNS <--RADIUS--> RADIUS服务器
  • LAC 可以使用 RADIUS 验证用户凭证。
  • LNS 也可以独立地使用 RADIUS 验证。
  • 双重验证提供了额外的安全层。

安全配置检查清单 (Security Configuration Checklist):

  • 在 LAC 和 LNS 之间使用 IPsec
  • 使用强共享密钥或证书进行隧道认证
  • 为每个隧道对使用唯一的共享密钥
  • 启用 PPP 层认证（CHAP 或 EAP）
  • 避免使用 PAP 认证
  • 定期轮换共享密钥
  • 实施访问控制列表限制隧道建立
  • 启用日志记录和监控
  • 部署入侵检测系统（IDS）
  • 定期进行安全审计和渗透测试
最后于 更新