IPv6セキュリティ

Transcription

1 version 1.2 T2 IPv6 テクニカル TIPS 安 したネットワーク運 をめざして IPv6 セキュリティ 沢 学総合メディア基盤センター 北 善明 November 29, 2016 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 1/46

2 IPv6 における脆弱性報告の傾向 35 IPv6 の脆弱性報告件数の推移 (National Vulnerability Database を集計 ) HIGH MIDIUM LOW IPv4 の件数 IPv6 の脆弱性報告が増加傾向 (2016 年度の件数は少ない ) Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 2/46

3 IPv6 対応時のキーワード IPv6 対応 IPv6 への移 IPv4 ネットワークがなくなるのではない IPv6 ネットワークの追加運 重のネットワーク運 三つの視点での考慮が必要 IPv4 ネットワーク IPv6 ネットワーク デュアルスタックネットワーク IPv4 だけのネットワーク運 との相違点の把握が重要 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 3/46

4 2016 年における IPv6 対応の現状 App Store アプリの IPv6 対応必須化 2016 年 6 1 より開始 (ios9, OSX ) DNS64/NAT64 による IPv4 通信を想定 Happy Eyeballs において IPv6 を優先 IPv6 の名前解決ができないことを 25ms 待機 モバイルキャリアの対応 Verizon Wireless では 70% 越え 1 本では携帯キャリア 3 社への IPv6 対応要請 2 ISP での IPv6 デフォルト化 JPNE v6 プラス利 ひかり電話ルータの 動接続対応エリア拡 (OCN) 年 6 に千葉県, 埼 県, 神奈川県が追加 ( 拡 中 ) Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 4/46

5 IPv6 対応時のセキュリティ観点の整理 IPv6 の仕様に因るセキュリティ課題 1 仕様が変更され解決した課題 2 実装面で注意が必要な課題 3 運用面での対策が必要な課題 デュアルスタック運 における観点 4 IPv4 仕様との違いの理解 5 IPv6 機能有効時の動作の理解 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 5/46

6 IPv6 対応時のセキュリティ観点の整理 IPv6 の仕様に因るセキュリティ課題 1 仕様が変更され解決した課題 2 実装面で注意が必要な課題 ソースルートオプション (RH0) 3 運用面での対策が必要な課題 IPv6アドレス短縮表記のゆれ 不正 RAとNDPフラグメント デュアルスタック運 における観点 4 IPv4 仕様との違いの理解 5 IPv6 機能有効時の動作の理解 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 6/46

7 1 ソースルートオプション (RH0) の課題 概要タイプ 0 ルーティングヘッダ (RH0) を利 した攻撃 ソースルートオプションは IPv4 においても問題ありそのままの機能を IPv4 から引き継いだもの 想定される問題 中継ノードを指定することによるフィルタリング回避 指定する 台のノード間でのパケット増幅攻撃 2007 年に指摘された問題 攻撃者 X 攻撃者 X DATA A X 1 DATA A X 1 インターネット DATA B X インターネット DATA B X 2 ノード A 2 パケットがピンポン ノード A DATA A X Internet Week 2016 ノード B Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. ノード B 7/46

8 1 RH0 問題の対策 RH0 は 推奨扱いに (RFC5095) 古い実装の場合注意が必要 2008 年 1 モバイル IP ではルーティングヘッダを いるが新たにタイプ 2 が 意された すべてのルーティングヘッダが禁 ではない 対外接続箇所におけるフィルタリング 利 禁 と合わせて転送も禁 FW 機器でのルーティングヘッダのタイプ識別が必要 ( 参考 ) 主な定義済みルーティングヘッダのタイプ Routing Type 説明 0 ソースルーティングで利 ( 推奨 ) [RFC2460][RFC5095] Internet Week 2016 Nimrod routing system ( 推奨 ) MIPv6 で利 ( 中継ノードは 1 つだけ指定可能 ) [RFC6275] RPL(Routing Protocol for Low-Power and Lossy Networks) で利 するソースルーティング [RFC6554] Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 8/46

9 1 IPv6アドレス表記法のおさらい IPv4のアドレス表記法 2 進数表記 (32ビット) ビットに区切り 10 進数で表現区切り 字はピリオド IPv6 のアドレス表記法 ( 省略法 ) 2 進数表記 (128 ビット ) ビットに区切り 16 進数で表現区切り 字はコロン : 2001:0db8:beef:cafe:0000:0000:0000:1234 省略表記 1: 各ブロックの先頭の連続する 0 は省略してもよい 2001:db8:beef:cafe:0:0:0:1234 省略表記 2: 連続した 0 は 1 回に限り :: に省略してもよい 2001:db8:beef:cafe::1234 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 9/46

10 1 IPv6 アドレス表記のゆれによる課題 柔軟な表記が可能な IPv6 アドレスに課題 省略形やアルファベットの 字 / 字など複数の表記が可能 < 同じアドレスの例 > :db8:0:0:1:0:0:1 :: による省略がなくてもよい :0db8:0:0:1:0:0:1 頭の0の省略があってもなくてもよい :db8::1:0:0:1 同じ さの0なのでどちらの表記も可 2001:db8:0:0:1:: :db8::0:1:0:0:1 1ブロックだけを :: に省略してもよい :DB8:0:0:1::1 アルファベットは 字 / 字が可 正規化しないとアドレスの差異を誤判定 RFC5952 にて省略表記ルールが明確に 2 と 4 は NG 3 は前半省略 5 は 字利 古い実装に注意が必要 運 からの要求 2010 年 8 省略表記と省略表記を設定で指定できる実装も必要 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 10/46

11 1 近隣探索プロトコル :NDP のおさらい Neighbor Discovery Protocol 処理 機能 説明 リンクレイヤアドレスの解決 (ARP 相当 ) 近隣キャッシュ 不到達検出機能 IP アドレスとリンクレイヤアドレス (MAC アドレス ) 対応を保持 近隣キャッシュ内のリストを最新に保つ機能 動アドレス 設定 (SLAAC) 重複アドレス検出機能 (DAD) デフォルトルートの設定 グローバルアドレスの 成 設定 IP アドレスの重複がないか検出する機能 (RFC5227 にて IPv4 の仕様に逆輸 された ) ルータ広告の送信元 IP アドレスを利 ルータ広告に含まれるプレフィックス情報を利 5 つのメッセージタイプ 機能 ルータ要請 (ICMPv6 type 133) RS:Router Solicitation ルータ広告 (ICMPv6 type 134) RA:router Advertisement 近隣要請 (ICMPv6 type 135) NS:Neighbor Solicitation 近隣広告 (ICMPv6 type 136) NA:Neighbor Advertisement リダイレクト (ICMPv6 type 137) 説明 セグメント内のルータ発 に利 ルータ広告を即座に取得する場合に送出 ルータによるデフォルト経路の通知 プレフィックス情報配布で 動アドレス設定が可能 重複アドレス検出や到達性 / 不到達性の確認 リンクレイヤアドレスの解決 近隣要請に対する応答 の IP アドレス変更の通知 最適なデフォルト経路を通知 (IPv4 のリダイレクトと同様 ) Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 11/46

12 1 NDP の動作概要 リンクローカルアドレス解決の流れ ノード A ノード B 1 MAC アドレス 取得完了 2 動アドレス設定 (SLAAC) の流れ 3 1 近隣要請 (NS) 通信相 の MAC アドレスを探索 ( 宛先はマルチキャスト ) 近隣広告がない場合はオンリンクでないと判断 2 近隣広告 (NA) ターゲットアドレスを持つノードが回答 ただし誰でもこの応答は可能 3 通信開始 ノード A 1 リンクローカルアドレス確定 DAD 2 デフルト経路を設定 3 ルータ 3ルータ広告 (RA) 4 近隣要請 (NS) 全ノードマルチキャスト (ff02::1) 宛に送信近隣広告がなければアドレスの利 が 取得プレフィックスからグローバルアドレス 可能 ( 応答があるとアドレスを再構成 ) を 成 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 12/46 4 グローバルアドレス確定 DAD 1 近隣要請 (NS) 近隣広告がなければアドレスの利 が可能 2 ルータ要請 (RS) 全ルータマルチキャスト (ff02::2) 宛に送信

13 1 不正 RA による課題 概要意図しないアドレス / デフォルト経路の 成 RA は 1 つのパケットでセグメント内全体に影響を与える DHCP と異なりアドレスの追加設定が可能 想定される問題 IPv4 の偽 DHCP サーバ設置と同様の脅威 通信断 盗聴 機器のリソース消費 意図せぬ通信 正規ルータ 不正 RA 攻撃対象 デフォルト経路 攻撃者 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 13/46

14 1 不正 RA からサブネットを守る 法 (1) 認証技術による防御 SEND(SEcure Neighbor Discovery) の導 NDP が認証機能を持つので詐称が困難に証明書 DoS 攻撃の危険性は残る 証明書検証はノードに取って重い処理 実装が少ない点や全てのノードに設定が必要な点も課題 IEEE802.1X 認証の利 攻撃者をサブネットに接続させない発想 運 ミスでルータ広告が流れる可能性あり Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 14/46

15 1 不正 RA からサブネットを守る 法 (2) 運 における対策 NDP のモニタリング (NDPMon など ) 攻撃の早期確認が可能 Router Preference(RFC4191) の利 正規ルータの優先度を high に設定 意図的なもの ( 攻撃 ) は排除不能 パーソナルファイアウォールの利 正規ルータのアドレスからのみルータ広告を許可 全てのノードに設定が必要な点が課題 不正 RA の浄化 (rafixd など ) 不正 RA と同じ RA を Router Lifetime=0 で広告 不正 RA によるノードの学習をリセット 最低限必要な対策 最低限必要な対策 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 15/46

16 1 不正 RA からサブネットを守る 法 (3) L2 スイッチによる防御 2011 年 2 RA-Guard(RFC6105) 機能の利 対応機器は現状ハイエンド機器が主流フラグメント利 による RA-Guard 回避問題 L2 スイッチにてパケット再構成が必要で問題 完全抑制可能な対策 フラグメント化されたNDPパケットの破棄が必要に 2013 年 8 RFC6980にて仕様化 RFC6980 実装の機器 +RA-Guard 機能で防御可能 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 16/46

17 IPv6 対応時のセキュリティ観点の整理 IPv6 の仕様に因るセキュリティ課題 1 仕様が変更され解決した課題 2 実装面で注意が必要な課題 3 運用面での対策が必要な課題 拡張ヘッダDoS 攻撃 量アドレスDoS 攻撃 フラグメント処理 デュアルスタック運 における観点 4 IPv4 仕様との違いの理解 5 IPv6 機能有効時の動作の理解 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 17/46

18 2 IPv6 拡張ヘッダのおさらい 数珠つなぎで拡張機能を付加 IPv6 ヘッダが固定 化されたために導 された機能 IPv6 ヘッダ Next Header = TCP TCP ヘッダ + データ IPv6 ヘッダ Next Header = Fragment Fragment ヘッダ Next Header = Dst. Opt. Dst. Opt. ヘッダ Next Header = TCP フラグメント化された TCP ヘッダ + データ 拡張ヘッダの種類 Protocol 番号 拡張ヘッダ名称 説明 0 Hop-by-Hop Options header 中継ノードの処理を記述する 43 Routing header 送信元がルーティング経路を指定する Type 0 は廃 [RFC 5095] 44 Fragment header パケット分割時に利 する 51 Authentication header エンドツーエンドにて完全性と認証を提供する 50 Encapsrational Security Payload header IPsec にてペイロードを暗号化する際に利 する 60 Destination Options header エンドノードにて実 する内容を記述する 135 Mobility header [RFC 6275] MIPv6 におけるモバイルノードの情報交換で利 140 Shim6 Protocol [RFC 5533] Shim6 で利 される Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 18/46

19 2 拡張ヘッダ DoS 攻撃の課題 概要ホップバイホップ オプション (HBH) ヘッダの悪 中継ノード ( ルータ ) にて唯 処理が必須な拡張ヘッダ Jambo Payload オプションで巨 な値を指定 多数の拡張ヘッダ利 による負荷 ファイアウォール機器など 査を必要とする機器が影響 想定される問題 ルータやファイアウォールの過負荷による動作不良 中継ノード ( ルータ ) 攻撃者 IPv6 インターネット 多数のホプバイホップ オプションヘッダを付加したパケット IPv6 ヘッダ HBHヘッダ HBHヘッダ HBHヘッダ データ Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 19/46

20 2 量アドレス DoS 攻撃の課題 概要アドレスの異なる 量の通信 ( 近隣キャッシュの肥 ) セグメント内のノード許容数は /64 だと 2 64 個 量のリンクレイヤアドレス解決におけるリソース消費 想定される問題 機器のリソース消費による動作不良 サービス不能 攻撃者 1 量のアドレスの異なる通信 2 量の設定の異なるルータ広告 IPv6 インターネット 正規ルータ ルータ 量の ND パケット 2001:db8:0:1::1 攻撃対象 1 近隣キャッシュの肥 化 2 多数のアドレス / デフォルト経路 Internet Week 2016 攻撃者 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. IPv6 内部ネットワーク 2001:db8:0:1::/64 20/46

21 2 拡張ヘッダ / 量アドレス DoS 攻撃への対策 実装 での対策仕様上明確でない上限値を実装で設ける利 可能な拡張ヘッダ数 オプション値 近隣キャッシュ数 利 プレフィックス数 デフォルト経路数スキャンには SYN フラッド攻撃対策同様の処理を実装 DDoS 攻撃となると難しい 多くのルータは HBH ヘッダを無視 / 破棄 (RFC7872) インターネット事業者の 4 割が HBH ヘッダ付パケットを破棄同意したルータのみ処理する仕様とする提案あり現時点の端末 OS の実装では利 プレフィックス数の上限があるものは限定的 Linux Mac OS X など同 サブネット上の攻撃なので改修しない実装もある運 での対策サブネットサイズを さくした運 (/120 など ) SLAAC は利 できなくなる 2016 年 6 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 21/46

22 2 拡張ヘッダに関する議論 未知の拡張ヘッダ フォーマットが規定 (RFC6564) TLV 形式に 拡張ヘッダ仕様の更新 2012 年 4 拡張ヘッダ処理に関する整理 :RFC7045 中間転送ノード (FW 機器など ) での制限事項を明記 デフォルト設定で標準拡張ヘッダは許可するべき 実験的な拡張ヘッダを扱える必要あり 2013 年 12 ルーティングヘッダも Type により許可されるべき ただし多くの場合破棄されている現状がある 拡張ヘッダチェーンのフラグメント禁 :RFC7112 第 フラグメントが全ての拡張ヘッダを持つことが必須に再構成不要でパケット検査が可能 2014 年 1 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 22/46

23 2 パケットフラグメント処理の違い Path MTU Discovery(PMTUD) が必須に通信経路の最 MTU サイズを求める 順 中継ノードでのフラグメントをしない IPv6 では必須 IPv4 では中継ノードで適宜フラグメントしている ICMPv6 を利 して調整 転送先リンクの MTU サイズを超えるパケットが来た場合ルータは送信元に ICMPv6 Packet Too Big を送信 送信元はメッセージ内の MTU サイズにフラグメントして再送信 IPv4 分割 IPv4 IPv4 結合 IPv4 MTU 1500 MTU 1454 MTU 1500 IPv6 ICMPv6 Packet Too Big (MTU = 1454) ただし DF ビットが設定されている IPv4 は IPv6 と同じく PMUTD が必要 分割 IPv6 IPv6 IPv6 IPv6 IPv6 IPv6 結合 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 23/46

24 2 ルータにおける ICMPv6 処理の必須化と課題 概要 PMTUD で IPv6 ルータは ICMPv6 処理が必須 MTU より きなパケットに対して Packet too big を返答 パラメータ異常となるパケットをルータ宛てに多数送信することで正常な通信を阻害する DoS 攻撃が可能 想定される問題 ルータの ICMPv6 処理不能による通信障害 ルータの動作不良 エラーとなる大量の通信 MTU: 1500 MTU: 1454 MTU: 1500 ルータ ルータ ( 犠牲 ) too big 正常な ICMPv6 応答が不能 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 24/46

25 2 不完全なフラグメントパケットによる問題 概要 第 フラグメントパケットのみを 量に送信 パケットの再構成処理に必要なリソースを無駄に消費 原 フラグメント (atomic fragment) 処理が未定義で実装依存 実装によってはパケット再構成ができない 原 フラグメント : fragment offset 値と M フラグの値が共に 0 となる単 のフラグメントパケット 想定される問題 フラグメント再構成における動作不良 機器のリソース消費による動作不良 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 25/46

26 2 フラグメント関連の課題における対策 実装 における対策パラメータ異常処理と PMTUD 処理を分離する実装 有効な対策は存在しないため実装での 夫が必要 フラグメントパケットを再構成するまでに保持する時間の調整が機器のリソースに合わせて必要 DoS 攻撃の判断ができるかが鍵 原 フラグメントを受け取った場合にも再構成処理を RFC6946 で明確に定義された 2013 年 5 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 26/46

27 IPv6 対応時のセキュリティ観点の整理 IPv6 の仕様に因るセキュリティ課題 1 仕様が変更され解決した課題 2 実装面で注意が必要な課題 3 運用面での対策が必要な課題 NA 詐称 マルチキャストと VLAN グローバルアドレスの利 デュアルスタック運 における観点 4 IPv4 仕様との違いの理解 5 IPv6 機能有効時の動作の理解 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 27/46

28 3 NDP の動作概要 ( 再掲 ) リンクローカルアドレス解決の流れ ノード A ノード B 1 MAC アドレス 取得完了 2 動アドレス設定 (SLAAC) の流れ 3 1 近隣要請 (NS) 通信相 の MAC アドレスを探索 ( 宛先はマルチキャスト ) 近隣広告がない場合はオンリンクでないと判断 2 近隣広告 (NA) ターゲットアドレスを持つノードが回答 ただし誰でもこの応答は可能 3 通信開始 ノード A 1 リンクローカルアドレス確定 DAD 2 デフルト経路を設定 3 ルータ 3ルータ広告 (RA) 4 近隣要請 (NS) 全ノードマルチキャス (ff02::1) 宛に送信近隣広告がなければアドレスの利 が 取得プレフィックスからグローバルアドレス 可能 ( 応答があるとアドレスを再構成 ) を 成 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 28/46 4 グローバルアドレス確定 DAD 1 近隣要請 (NS) 近隣広告がなければアドレスの利 が可能 2 ルータ要請 (RS) 全ルータマルチキャスト (ff02::2) 宛に送信

29 3 NA 詐称による課題 概要近隣広告 (NA) の詐称により近隣キャッシュを汚染 ARP と異なり override flag の設定で強制的な変更可攻撃対象の IP アドレスへの通信を誘導可能 DAD における応答を返すことで IP アドレス設定を妨害 想定される問題 IPv4 の ARP における問題と同様の脅威通信断 盗聴 サービス妨害 意図せぬ通信 攻撃対象の詐称した NA DAD DAD に対する応答 NA 攻撃対象 への通信 DAD が完了せず アドレス設定が完了しない 攻撃対象 攻撃者 攻撃対象 攻撃者 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 29/46

30 3 NA 詐称からサブネットを守る 法 認証技術による防御 SEND(SEcure Neighbor Discovery) の導 IEEE802.1X 認証の利 運 における対策 NDP のモニタリング (NDPMon など ) L2 スイッチにおけるノード間通信を禁 する運 ルータが全てのリンクレイヤ内通信を中継 L2 スイッチのポートに複数ノードを接続しない運 MAC アドレスが頻繁に異なるポートを遮断 不正 RA ほど深刻な問題ではない L2 スイッチでの対策は費 対効果が 合わない Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 30/46

31 3 マルチキャストと VLAN 概要 IPv6 は RA などで積極的にマルチキャストを利 マルチキャストを全ポートに流す実装で問題ノードは複数の IPv6 アドレスを持つ点が IPv4 と異なる IPv4 で問題が出なかった構成でも IPv6 で問題の可能性 IPv4 では IP アドレスは 1 つであったから顕在化しなかった IPv6 では 1 ノード 1IP アドレスが成り たない認識が重要 想定される問題 異なる VLAN のアドレスを取得することに因る意図しない通信の発 異なる VLAN 間の短絡通信など 情報漏えい ルータ A の RA が 端末 B にも流れる ルータ A インテリジェント SW ダム HUB ルータ B Internet Week 2016 端末 A Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 端末 B 31/46

32 3 マルチキャストと VLAN への対策 機器や構成による対策 L2 スイッチも IPv6 利 で問題が出ないものを選択 MAC アドレス学習時に VLAN ポートにのみフラッドする実装 MAC アドレス VLAN( ダイナミック VLAN) も同様 単に全ポートにフラッドするのはそもそも正しい実装ではない 実装上の課題と える ネットワーク構成をユニキャストのみにする IPv6 over IPv4 による PtoP 接続構成など 運 負荷が きい課題 IPv6 の仕様の理解 IPv6 では 1 ノード 1IP アドレスが成り たない IP アドレスによる端末制御も IPv4 と同様にはできない Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 32/46

33 3 グローバルアドレス利 における課題 (1) プライバシーとセキュリティ 下位 64 ビット (IID: Interface ID) における課題 MAC アドレスから 成する仕様 プレフィックスが変化しても 意に特定可能 ( プライバシ ) MAC アドレスによる特定機器を狙った攻撃 ( セキュリティ ) 次アドレス (RFC4941) による IID ランダム化仕様同じネットワークにて定期的に変化するため管理が難しい 追加仕様なので MAC アドレスによる固定 IID も残る 新しい仕様の策定 プライバシを保護した固定 IID 成 :RFC7217 プレフィックスが変化する度に IID を 成 同じプレフィックスでは変化しない ( 管理が容易 ) IPv6 アドレスにおけるセキュリティ 2014 年 年 3 IID 成メカニズム毎のセキュリティ懸念事項の調査 (RFC7721) リンク層の固定的なアドレスを埋め込まず RFC7217 の利 へ Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 33/46

34 3 グローバルアドレス利 における課題 (2) グローバルアドレスと NAT(NAPT) NAT なしでセキュリティが低下するか? 適切なフィルタリングでセキュリティは確保可能そもそも NAT の通信中は外部からの到達性がある NAT でセキュリティ担保されている判断は誤り IPv6 で NAT は不要か? マルチプレフィックス環境などで有 性ありとの意 も NPTv6(RFC6296) によるステートレス変換 仮想化環境におけるアドレス共有 ただし NAT でなくとも解決策があるため推奨しない意 が強い Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 34/46

35 IPv6 対応時のセキュリティ観点の整理 IPv6 の仕様に因るセキュリティ課題 1 仕様が変更され解決した課題 2 実装面で注意が必要な課題 3 運用面での対策が必要な課題 デュアルスタック運 における観点 4 IPv4 仕様との違いの理解 5 IPv6 全て落とせなくなった機能有効時の動作の理解 ICMPv6 複雑な 動アドレス設定 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 35/46

36 4 フィルタリング設定時の注意点 IPv6 では ICMPv6 の扱いが重要 IPv4 と異なり ICMP を全て落とすと通信不能に ICMPv6 タイプ Type 1 (Destination Unreachable) Type 2 (Packet Too Big) Type 3 (Time Exceed) Type 4 (Parameter Probrem) 説明 IPv4 から IPv6 への迅速な TCP フォールバックのためにはエラー通知が必要 ルータでのフラグメントができないため通信経路の MTU サイズを調べる Path MTU Discovery(PMTUD) で必要となるため必須 Code0 がホップ数超過時に送られるものでエラー処理が必要 ネクストヘッダタイプ異常 (Code1) と IPv6 オプション異常 (Code2) を受け取れないと障害解析ができない Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 36/46

37 4 動アドレス設定 法の差異 設定項 の差異の認識が必要 種類の 式で設定できる項 に違いがある SLAAC DHCPv6 ( 参考 )DHCP デフォルト経路 (1) アドレス (2) プレフィックス (1) サーバ情報 (DNS など ) (3) ルータ優先度 (1) ー (1) IETF にて過去に議論があったが標準化の見通しなし (draft-ietf-mif-dhcpv6-route-option (expired)) (2) プレフィックス情報からアドレスを生成 (3) RDNSS オプション (RFC6106) ( 参考 )OS 毎の対応 SLAAC(StateLess Address Auto Configuration) OS DHCPv6 RDNSS OS DHCPv6 RDNSS Windows Vista 以降 addon Android Mac OS X 10.7 以降 Android 5.0 RHEL 6 ios 4.1 以降 Ubuntu 以降 Windows Phone 8 より Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 37/46

38 4 SLAAC と DHCPv6 の関係 ルータ広告中のフラグにより挙動を制御 A (autonomous address-configuration) flag プレフィックス情報オプション中のフラグ =1 でプレフィックス情報を利 した SLAAC を促す O (Other configuration) flag アドレス以外の設定情報 (DNS サーバなど ) を すフラグ =1 でステートレス DHCPv6 を促す M (Managed address configuration) flag ルータ広告以外のアドレス設定を すフラグ =1 でステートフル DHCPv6 を促す ステートフル / ステートレス DHCPv6 ステートレス :DNS サーバなどの情報配布のみステートフル :IPv6 アドレスの配布と状態管理 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 38/46

39 4 複雑な仕様ゆえ異なる実装 共通の動作 A flag O flag M flag 備考 SLAAC RDNSSオプションでDNSサーバ (Windowsは 対応) SLAAC+ ステートレスDHCPv ほとんどのOSで利 可能 (Androidは 対応) ステートフル DHCPv 割当アドレス管理を実施する形態 SLAAC+ ステートフル DHCPv 異なる動作 課題の整理を IETF で実施中 SLAAC によるアドレスと DHCPv6 による双 のアドレスが付く dtaft-ietf-v6ops-dhcpv6-slaac-problem Windows 7 は忠実な動作 A=0, O=1, M=0 でステートレス DHCPv6 の動作状態変化で設定をリリース Windows 8.1, 10 は勝 に DHCPv6 を利 A=0, O=0, M=0 でも DHCPv6 クライアントが動作 Linux/Mac OSX/iOS は状態変化に弱い M=1 から M=0 になっても DHCPv6 のアドレスを解放しない A=1, M=0 から A=0, M=1 になっても SLAAC のみのままなど Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 39/46

40 IPv6 対応時のセキュリティ観点の整理 IPv6 の仕様に因るセキュリティ課題 1 仕様が変更され解決した課題 2 実装面で注意が必要な課題 3 運用面での対策が必要な課題 デュアルスタック運 における観点 4 IPv4 仕様との違いの理解 5 IPv6 機能有効時の動作の理解 意図しないトンネル通信 IPv6 通信優先の理解 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 40/46

41 5 動トンネリングのおさらい 6to4(RFC3056) RFC7526 にて歴史的扱いに トンネル接続と IPv6 アドレス割り当てを同時に実現 IPv4 グローバルアドレスを利 した IPv6 アドレス 6to4 のアドレス形式 6to4 TLA to4 端末の IPv4 アドレス /48 のアドレス空間が割り当てられる Teredo(RFC4380) サブネット ID NAT トラバーサルを IPv6 で実現する技術 NAT の内側から IPv6 トンネル接続が可能 インターフェイス ID 16ビット 32ビット 16ビット 64ビット Teredo のアドレス形式 Teredo プレフィックス 2001:0000 Teredo サーバの IPv4 アドレス /128 のアドレスが つ割り当てられる フラグ 隠蔽したポート番号 2015 年 5 隠蔽した NAT IPv4 アドレス 32ビット 32ビット 16ビット 16ビット 32ビット Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 41/46

42 5 意図しない IPv6 通信 概要 IPv4 しかないネットワークからの IPv6 通信 デフォルトで IPv6 機能が有効 Windows Vista 以降では 動トンネル機能が有効 想定される問題 アクセス制御を回避した通信が IPv6 で可能 バックドアの危険 通信傍受不正 RA による影響も受ける HTTP, SMTP 以外禁 ファイアウォール機器 Teredo トンネル IPv4 ネットワーク IPv6 により通信可能 Teredo リレー デュアルスタックノード Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 42/46

43 5 意図しない IPv6 通信への対策 運 での対策 Teredo を禁 するルールを追加 3544/udp のフィルタ IPv6 通信のモニタリング認識と理解が重要 IPv4 のみでもデュアルスタック端末の存在認識が重要正しい動作の理解が肝要 6to4 トンネル : インターフェイスに IPv4 グローバルアドレスが付与されると設定されるが IPv6 のみの通信相 でない限り IPv4 通信が優先される Windows 10 ではデフォルト無効 Teredo トンネル : インターフェイスに IPv4 アドレスが付与されると設定されるが 利 優先度は 番低く からの発信がない限りパケットを受信しない Microsoft は Windows Vista/7 の Teredo サーバを停 し Xbox One と Windows10 向けサービスに集中化 (2015 年 5 ) Windows 8, 8.1, 10 ではデフォルト有効 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 43/46

44 5 IPv4 ネットワークのデュアルスタック端末 IPv6 優先利 の理解基本的にデュアルスタックでは IPv6 を優先 OS により挙動が少々異なるため動作の理解が必要 Windows 8 などは定期的な通信で優先を決定 IPv6 が有効になっている認識が重要 対策 デフォルトで IPv6 機能が有効になっている! RA などで IPv6 アドレスが付与されれば通信を実施 IPv6 通信が優先されると問題が きい IPv6 対策のない IPv4 ネットワークが最も危険 IPv4 のみのネットワークでも IPv6 通信の監視を実施 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 44/46

45 IPv6 仕様の Internet Standard 化の動き RFC2460(Draft Standard) が現 仕様多くの更新 (Update) を組み込み再整理 対象となる中 的な RFC RFC2460: IPv6 の仕様 RFC4291: IPv6 アドレス体系 RFC1981: IPv6 のパス MTU 探索 RFC3596: IPv6 サポートのための DNS 拡張 RFC4443: ICMPv6 の仕様 検討事項 RFC7045 との 盾の整理 site-local の削除 PMTUD の再検討 など Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 45/46

46 まとめ 仕様 課題があるものは改善されている 新しい RFC に準拠しているか実装の確認が必要最近も改変の議論が盛ん 実装 基本仕様における曖昧さの解消が中 仕様上明確でない上限値の実装が求められる拡張ヘッダや PMTUD などルータ処理が難しい点も 運 IPv6 対応機器が多く存在してることの認識が重要 デュアルスタックにおける挙動の理解が必要 IPv4 ネットワークでの IPv6 通信監視が必須 Internet Week 2016 Copyright 2016 Yoshiaki Kitaguchi, All rights reserved. 46/46