Skip to main content

9. Security Considerations (安全性考虑)

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

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

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

端点认证:

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

  • Challenge AVP: 发起方在 SCCRQ (启动控制连接请求) 中发送一个随机挑战值。
  • Challenge Response AVP: 响应方计算基于共享密钥的响应并在 SCCRP (启动控制连接回复) 中返回。
  • 响应计算: 使用 MD5 哈希函数：MD5(消息类型 + 共享密钥 + 挑战值 + 会话ID)

共享密钥管理:

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

隧道授权:

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

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

漏洞和缓解措施:

  1. 中间人攻击:

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

  2. 重放攻击:

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

  3. 拒绝服务攻击:

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

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

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

明文传输的风险:

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

AVP 隐藏机制:

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

  • 隐藏过程:

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

  • 限制:

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

建议:

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

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

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

PPP 层认证:

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

  • PAP (密码认证协议):

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

  • CHAP (挑战握手认证协议):

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

  • EAP (可扩展认证协议):

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

端到端加密:

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

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

多层防御策略:

远程系统 <--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 提供的安全服务:

  1. 机密性:

    • 通过 ESP (封装安全载荷) 提供加密。
    • 支持多种加密算法: AES, 3DES, ChaCha20 等。

  2. 完整性:

    • 通过 AH (认证头部) 或 ESP 认证提供。
    • 使用 HMAC (如 HMAC-SHA256) 验证数据完整性。

  3. 源认证:

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

  4. 防重放:

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

L2TP/IPsec 架构:

+-------------------+
|   PPP 载荷        |
+-------------------+
|   L2TP 头部       |
+-------------------+
|   UDP 头部        |
+-------------------+
|   ESP 头部        | <-- IPsec 加密和认证
+-------------------+
|   IP 头部         |
+-------------------+

IPsec 配置选项:

  • 传输模式:

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

  • 隧道模式:

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

密钥管理:

  • IKE (互联网密钥交换):

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

  • 预共享密钥 vs 证书:

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

NAT 穿越 (NAT-T):

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

  • 使用 UDP 封装 ESP (UDP 端口 4500)。
  • 定期发送 NAT keepalive 数据包。
  • IKEv2 内置 NAT-T 支持。

性能考虑:

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

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

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

代理认证机制:

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 可以接受或拒绝会话。

安全风险:

  1. LAC 妥协:

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

  2. 密码明文传输:

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

  3. 信任边界:

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

最佳实践:

  1. 避免代理 PAP 认证:

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

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

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

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

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

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

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

代理认证与 RADIUS 集成:

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

安全配置检查清单:

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