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) を使用して、どのピアがトンネルを確立できるかを制限します。
脆弱性と緩和策:
-
中間者攻撃:
- リスク: L2TP トンネル認証は共有秘密に基づいており、中間者攻撃に対して脆弱です。
- 緩和策: IPsec を使用してエンドツーエンドの暗号化と認証を提供します。
-
リプレイ攻撃:
- リスク: 攻撃者はキャプチャした制御メッセージをリプレイする可能性があります。
- 緩和策: シーケンス番号と ZLB ACK メカニズムを使用してリプレイ攻撃を検出および防止します。
-
サービス拒否攻撃:
- リスク: 攻撃者は大量のトンネル確立リクエストを送信する可能性があります。
- 緩和策:
- 送信元アドレスあたりの同時トンネル数を制限します。
- レート制限を実装します。
- Cookie メカニズム (TCP SYN Cookie に類似) を使用します。
9.2 Packet Level Security (パケットレベルのセキュリティ)
L2TP 自体はパケット暗号化や完全性保護を提供しません。
平文送信のリスク:
- 盗聴: 攻撃者は PPP パケットの内容 (ユーザー資格情報やアプリケーションデータを含む) を傍受して読み取ることができます。
- 改ざん: 攻撃者は送信中のパケットを変更できます。
- 注入: 攻撃者はトンネルに悪意のあるパケットを注入できます。
AVP 隠蔽メカニズム:
L2TP は、機密性の高い制御情報を保護するための AVP 隠蔽メカニズムを提供します:
-
隠蔽プロセス:
- 共有秘密とランダムベクトルを使用して MD5 ハッシュを生成します。
- ハッシュ値と AVP 値を XOR 演算します。
- 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 が提供するセキュリティサービス:
-
機密性:
- ESP (カプセル化セキュリティペイロード) 暗号化によって提供されます。
- 複数の暗号化アルゴリズムをサポート: AES, 3DES, ChaCha20 など。
-
完全性:
- AH (認証ヘッダー) または ESP 認証によって提供されます。
- HMAC (例: HMAC-SHA256) を使用してデータの完全性を検証します。
-
送信元認証:
- パケットソースの真正性を検証します。
- IP スプーフィング攻撃を防ぎます。
-
アンチリプレイ:
- シーケンス番号を使用してリプレイ攻撃を防ぎます。
L2TP/IPsec アーキテクチャ:
+-------------------+
| PPP ペイロード |
+-------------------+
| L2TP ヘッダー |
+-------------------+
| UDP ヘッダー |
+-------------------+
| ESP ヘッダー | <-- IPsec 暗号化と認証
+-------------------+
| IP ヘッダー |
+-------------------+
IPsec 設定オプション:
-
トランスポートモード:
- IP ペイロードのみを暗号化および認証します。
- エンドツーエンド通信に適しています。
- L2TP/IPsec に推奨されます。
-
トンネルモード:
- IP パケット全体を暗号化および認証します。
- 新しい外部 IP ヘッダーを追加します。
- ゲートウェイ間通信に適しています。
鍵管理:
-
IKE (インターネット鍵交換):
- IKEv1: 元のバージョン、2 段階交渉。
- IKEv2: 改良版、より効率的で簡潔。
- IKEv2 の使用を推奨します 鍵交渉用。
-
事前共有鍵 vs 証明書:
- 事前共有鍵 (PSK): 設定が簡単ですが、鍵の配布が困難。
- 証明書: より安全で、大規模な展開をサポート、強く推奨されます。
NAT トラバーサル (NAT-T):
L2TP/IPsec が NAT デバイスを通過する必要がある場合:
- ESP の UDP カプセル化を使用 (UDP ポート 4500)。
- 定期的に NAT キープアライブパケットを送信します。
- IKEv2 には NAT-T サポートが組み込まれています。
パフォーマンスに関する考慮事項:
- IPsec 暗号化は CPU オーバーヘッドを増加させます。
- ハードウェアアクセラレーション (AES-NI など) の使用を検討してください。
- MTU の減少を考慮する必要があります (ESP ヘッダー + ESP トレーラー + 認証データ)。
9.5 Proxy PPP Authentication (プロキシ PPP 認証)
L2TP は、LAC が LNS に代わって初期 PPP 認証を実行することを許可します。
プロキシ認証メカニズム:
LAC は、LNS に呼び出しを転送する前に、リモートシステムと LCP を交渉し、認証を実行できます:
-
LAC が PPP 認証を実行:
- LAC がリモートシステムと LCP を交渉します。
- LAC が PAP または CHAP 認証を実行します。
- LAC が認証情報 (ユーザー名、パスワードハッシュなど) を収集します。
-
LAC が認証情報を LNS に転送:
- プロキシ AVP を使用して認証情報を渡します:
- Proxy Authen Type AVP (29): 認証タイプ (PAP, CHAP など)
- Proxy Authen Name AVP (30): ユーザー名
- Proxy Authen Challenge AVP (31): CHAP チャレンジ値
- Proxy Authen Response AVP (33): 認証応答
- プロキシ AVP を使用して認証情報を渡します:
-
LNS が認証情報を検証:
- LNS は LAC が提供した情報に基づいてユーザーを検証します。
- LNS はセッションを受け入れるか拒否できます。
セキュリティリスク:
-
LAC の侵害:
- LAC が侵害されると、攻撃者はユーザー資格情報を取得できます。
- 緩和策: IPsec を使用して LAC と LNS 間の通信を保護します。
-
平文パスワード送信:
- PAP パスワードは LAC から LNS へ平文で送信されます (AVP 内)。
- 緩和策: AVP 隠蔽メカニズムまたは IPsec 暗号化を使用します。
-
信頼境界:
- LNS は LAC が提供する認証情報を完全に信頼する必要があります。
- 悪意のある LAC は認証情報を偽造できます。
- 緩和策:
- 信頼できる管理ドメイン間でのみプロキシ認証を使用します。
- エンドツーエンドの再認証を要求することを検討してください。
ベストプラクティス:
-
プロキシ PAP 認証を避ける:
- PAP パスワードは隠蔽されていても攻撃に対して脆弱です。
- 使用する必要がある場合は、IPsec 保護を確保してください。
-
エンドツーエンド認証を優先する:
- リモートシステムが LNS と直接認証できるようにします (プロキシなし)。
- より強力なセキュリティのために EAP メソッドを使用します。
-
プロキシ認証の使用シナリオを制限する:
- 必要な場合にのみ使用します (例: 高速呼び出し確立)。
- 信頼できるネットワーク環境で使用します。
-
複数の認証方法を組み合わせて使用する:
- 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) を展開する
- 定期的なセキュリティ監査と侵入テストを実施する