Microsoft PowerPoint - DNSSEC技術と運用.ppt [互換モード]

Transcription

1 JAIPA セキュリティ部会 DNSSEC 勉強会 DNSSEC 技術と運用 株式会社ブロードバンドタワー事業開発グループ大本貴

2 DNSSEC その前に 2

3 DNS(Domain Name System) について簡潔な用語定義 Zone ゾーン 名前解決を行うデータの集まり RR リソースレコード ゾーンファイルに登録されたデータ資源 Query クエリ owner( ホスト名やIP address) を keyにして RRを索くということ Authority 権威 コンテンツ ( 名前空間 ) について管理 Delegation 権限委譲 コンテンツ ( 名前空間 ) の一部の管理を下位ゾーンに委譲すること Recursive query 再帰検索 ( 後ほど説明 ) 3

4 DNS サーバ色々 authoritative server 権威サーバ ( コンテンツサーバ ) ゾーン管理している root servers.jp ゾーン担当 example.jp ゾーン担当 recursive server リクエストに応じて再帰問い合わせを行うリゾルバサーバ ( キャッシュサーバも兼務する ) stub resolver リカーシブサーバに再帰問い合わせを行うリゾルバプログラム 基本的にはリカーシブサーバから得た回答内容を表示するだけ Stub からの要求に応じて答えを求めて問い合わせを行う dig コマンドや nslookup 4

5 DNSSEC(DNS Security Extensions) の技術概要 5

6 そもそもなんで DNSSEC が必要? 毒入れアタック ( ポイゾニング ) 問い合わせ情報に対して第三者が偽装パケットにより偽のレコードをユーザに送りつける 結果 ウィルス仕込み済み web サイトへ誘導 メールを正しい相手に送信できない ( しかもエンドユーザは気が付きにくい ) 個人情報搾取 インターネットの基盤である DNS の信頼性が揺らいでいる 何を信じればよいのか 6

7 何が主たる原因か? クエリの送受信をUDPでやりとりしているから UDPでこぼれたらTCP fallbackで対応 そもそも最初からTCPで良いのでは? ルートゾーンなどで膨大なリクエストを短時間で処理するためには UDP で処理を軽くしていく必要がある 7

8 DNS の名前解決の流れ ってどこ? Recursive Server ってどこ? ユーザ root servers は向こうだってさ おいらもメモっとくわ は知らんが.jp なら知ってる.jp の権威 DNS サーバはあそこ に置いてあるデータが欲しいんだけど.jp の権威 DNS サーバ は知らんが example.jp なら知ってる example.jp の権威 DNS サーバはそっち example.jp の権威 DNS サーバ かい? は向こうだよ 10 このデータね はいどうぞ 8

9 キャッシュポイゾニングの概要 って どこ? は だよ パケット偽装して は と送信 3 って どこ? 4 は だってさ おいらもメモっとくわ カモがきた 改ざん済みデータを送ってやろう 今日もアクセスはないなー 9

10 カミンスキーアタックの概要 そんなサーバ知らんがな 1 dokudoku.example.jp ってどこ? dokudoku.example.jp って どこ? Recursive Server って どこ? は か おいらメモっとくわ パケット偽装して dokudoku.example.jp は知らんが dokudoku のことは が知っている は と送信 カモがきた 改ざん済みデータを送ってやろう 最近アクセスないなー 10

11 DNSSEC 簡単にするとこんなイメージ? DNSSEC なし 頼んでいたタラバガニが届いた ~ 自分が要求したものだし 送られてきたものは正しいと信じよう ( でも実はアブラタラバかも ) DNSSEC あり 送付元からの署名がついてきているな 頼んだものだけど本物かどうか確認するか RRSIG DNSKEY RRSIG 検証の結果 整合 んじゃ このカニは本物のタラバガニと信じよう 11

12 DNSSEC 誰に負担があるの? ドメイン名登録者 ( 独自ドメイン取得している したい人 ) DNSSEC 化への判断 ( 自分の管理しているドメインの信頼性 上位ゾーンが対応していないなら DLV 使うか ) DNS サーバ管理者 (ISP ホスティング事業者 etc. ) 権威 DNS サーバ 管理しているゾーンの DNSSEC 対応 鍵の定期的なロールオーバなどが業務に追加 リゾルバサーバ ( キャッシュ DNS サーバ ) キャッシュサーバへトラストアンカーの導入 レジストラ 鍵を上位ゾーンへ登録する仲介処理 レジストリ 下位ゾーンからの登録申請に対して DS 登録処理 DS 申請を受け付けるシステムの構築 ユーザサポート担当者 障害時の切り分けのためのノウハウ習得 12

13 DNSSEC 導入するとどうなるの? 勝ち得るもの DNS の信頼性を高めることができる 真正性を担保できる 試練 めんどくさい ロールオーバーとか鍵の管理とか再署名とか 信頼の連鎖を形成するための第三者との連携 管理コストの増加 作業自体の単純増加 チェックするポイントの増加 ハイスペックなハードの必要性 ( 特にキャッシュサーバの ) 署名の検証処理が加わることで必要スペックも増加 SERVFAIL によるトラブルへの懸念 設定ミスなどで 検証に失敗する状況になると 該当ドメインの名前解決しない 障害に繋がる 顧客へのサポートに分岐が発生 (ISP など ) 問題が DNSSEC か DNS なのかの切り分けが生じる Windows の nslookup では dig のように SERVFAIL 判定を判断できない Windows 用の dig プログラム導入してもらうことに? 13

14 DNSSEC に対応できる環境にするには? DNSSEC 対応 DNS サーバ BIND のバージョン 9.3 以降 ( 権威サーバ キャッシュサーバ ) ただし 最近だと p1 に DNSSEC にバグがあるので使わないように DNSSEC だけではなく DNS のバグもあるので p2 以降推奨 9.7 からは Smart Signing という DNSSEC 用の仕組みが機能追加 NSD 3.x( 権威サーバ ) Unbound 1.x( キャッシュサーバ ) Windows2008server はまだ実装不十分 (NSEC3 未実装 ) この資料内の例では BIND9.7.x を設定事例として紹介します EDNS0 対応と TCP fallback への対応 キャッシュサーバが対応してても qmail は 512byte 問題が存在 Christopher K. Davis 氏が作成した patch1.03 (oversize DNS packets patch) を導入することが必須 IPv6 で既に問題が顕在化しているので対応済みかも 14

15 DNSSEC のために新規に定義されたレコード DNSKEY DNSSEC の公開鍵情報レコード ZSK(Zone Signing Key) RR(Resource Records)Set を署名する鍵 KSK(Key Signing Key) TYPE が DNSKEY の RRSet を署名する鍵 RRSIG(Resource Record Signature) ゾーンファイル内の各レコードの署名を表現するレコード (RRSIG 自身には署名しない ) DS(Delegation Signer) 子ゾーンの KSK を元に生成されたハッシュ 上位 DNS 権威サーバ ( 親 ) のゾーンに登録してもらい 親ゾーンの ZSK により署名してもらう NSEC & NSEC3& NSEC3PARAM( 後ほど説明 ) 15

16 DNSSEC の真正性担保の仕組み 信頼の連鎖 により レコードの信頼性を担保 root zone KSK 秘密鍵 KSK 公開鍵 トラストアンカーの KSK 公開鍵をコピー 検証 署名 署名 ZSK 公開鍵 署名 キャッシュサーバ 署名データ DS 申請 DNSKEY RR ZSK 秘密鍵 DS 承認 KSK 公開鍵 ZSK 公開鍵 署名 クエリ要求.jp 権威 DNS サーバ 署名 KSK 秘密鍵 ZSK 秘密鍵署名 DS 承認 署名 署名 DS 申請 KSK 公開鍵 ZSK 公開鍵 クエリ応答 example.jp 権威 DNS サーバ KSK 秘密鍵 ZSK 秘密鍵 署名 16

17 鍵生成 なんで鍵は二種類あるの? 鍵を ZSK と KSK を分けて管理することによって 鍵サイズや暗号強度を 役割に合わせたパラメータで運用できるメリットがある KSK は親ゾーンとの連携が必須になるため 鍵交換する頻度は少なくしたい 鍵の諸パラメータは ふつうどーする? 鍵の暗号化アルゴリズムは RFC4641 的には RSA/SHA-256 が推奨されている 鍵サイズは 1024bit 以上を推奨 (KSK ZSK) ( ルートゾーンの KSK では 2048bit が適用されている ) ZSK は KSK よりも暗号強度が弱くとも良いが更新頻度でカバーしていく 17

18 鍵生成の実際 ZSK. dnssec-keygen -a RSASHA256 -b 1024 ゾーン名 KSK. dnssec-keygen -a RSASHA256 -b f ksk ゾーン名 # cat Kohmo.to key ; This is a key-signing key, keyid 60799, for ohmo.to. ; Created: (Mon Sep 13 23:18: ) ; Publish: (Mon Sep 13 23:18: ) ; Activate: (Mon Sep 13 23:18: ) ohmo.to. IN DNSKEY AwEAAdLEIOzWiWrHtOEdc60BH4v4Qh6O8JHCO6cNwi5LsF nltjasc4av CFV5YG131CIHPAfM1hGnBe4qRnjGj+uA7hIDPD/CsKOd9zaFk8LFYiLb #cat Kohmo.to key ; This is a zone-signing key, keyid 48543, for ohmo.to. ; Created: (Mon Sep 13 23:18: ) ; Publish: (Mon Sep 13 23:18: ) ; Activate: (Mon Sep 13 23:18: ) ohmo.to. IN DNSKEY AwEAAcPn4Oj7xRAYMRZ2IkFQmRi5S9wNy7lNkDxMijyB2f d3anzw5i1g l3ysg3fhbpgcvbmj3pmkpciyvi/l74xt2mlf5jaeqktydvp2hujwisel. #cat Kohmo.to private Private-key-format: v1.3 Algorithm: 8 (RSASHA256) Modulus: w+fg6pvfebgxfnyiqvczglll3a3luu2qpeykpihz93do3pdmluaxdiwbcucgmak 実際の処理は後半に 18

19 上位ゾーンへの DS レコード登録 KSK を上位ゾーンに署名してもらうことで信頼の連鎖を形成させる root 申請を承認 DS 登録 example3 DS 登録申請 jp example to example2 ohmo org net example subdom 19

20 署名と 信頼の連鎖 構築の実際 DS ゾーン申請前提 named.confに署名したいゾーンが設定されていること KSKの鍵生成とZSKの鍵を生成済み 署名してみる dnssec-signzone S example3.jp. ( 対象ゾーン名 ) 処理が正常終了すると dsset-example3.jp( 対象ゾーン名 ) という DSSet ファイルと 署名済みゾーンファイル example3.jp.signed( 対象ゾーン名 +.signed) が生成される DSSet ファイル内に記載された 2 行のうち いずれかを上位ゾーンに登録申請する example3.jp. IN DS D736F20FB259279A4A5FFCEB45536C5CAD33EC78 example3.jp. IN DS EBC75A18FAEDA255DCD BFCDCF95D6BD6E367EB469EA7BA83A 713CF50F 1=SHA1 2=SHA256 20

21 署名の運用 ( 有効期限 ) 署名には有効期限が設けられている 有効期限が切れると署名が有効ではない 名前の検証に失敗する SERVFAIL の反応 名前解決できない メールは届けられない web も見れない かといって有効期限を長くしすぎていると期間内に鍵がクラックされる可能性も 有効期限が決められているからサーバ内の時計がずれていると KSK の有効期限は長く 鍵の暗号強度を高く ZSK の有効期限は短く 暗号強度は多少緩め というのが推奨されている RFC4641 的には KSK は 13 ヶ月に 1 度のタイミングでの交換を提案している ZSK は 1 ヶ月に 1 度程度を目安 (dnssec-signzone はオプションなしだと 30 日で設定される ) 21

22 鍵のロールオーバー new ロールオーバ手法としては下記の手法がある ZSK Double signatures ( 二重署名方式 ) Pre-publication ( 事前公開方式 ) KSK Double signatures ( 二重署名方式 ) Double-DS ( 二重 DS 方式 ) Double-RRSet ( 二重 RRSet 方式 ) 22

23 ZSK / Double signatures ( 二重署名方式 ) 既存 ZSK(A) と新規 ZSK(B) 両方でゾーン署名 新規 ZSK(B) のみで署名 既存 ZSK(A) 削除 既存 ZSK (A) 署名二重期間 署名二重期間 新規 ZSK (B) バリデータに伝播しているキャッシュ 新規 ZSK(B) 作成 新規 ZSK(C) 新規 ZSK(C) 作成 (A) のみ伝播 (A) と (B) が伝播 (B) のみ伝播 (B) と (C) が伝播 時間軸 active rolled 既存と次期 DNSKEY と両方で署名し 伝播を待つ 充分に伝播が行き渡っているならば DNSKEY をいつ切り替えても問題が出ないように考慮した方式 23

24 ZSK / Pre-publication( 事前公開方式 ) 署名鍵を ZSK(B) に変更 新規 ZSK(C) を公開 有効期限終了 既存 ZSK(A) 削除 既存 ZSK (A) 新規 ZSK (B) 新規 ZSK(B) をゾーンに含んだ形で (A) で署名し運用 新規 ZSK(C) 公開開始 新規 ZSK(C) 署名を新規 ZSK(C) に変更 バリデータに伝播しているキャッシュ (A) と (B) が伝播 (B) のみが伝播 (B) と (C) が伝播 (C) のみが伝播 時間軸 published active rolled 事前公開することで次期 DNSKEY をキャッシュに撒いておける これにより署名を切り替えても問題ないよう考慮した方式 24

25 KSK / Double signatures( 二重署名方式 ) 親ゾーン 既存 DS (A) 新規 DS (B) 上位ゾーンに DS(B) へ置き換えを依頼 登録作業 新規 DS(B) を署名 DS(B) のキャッシュへの伝播を確認 DS(B) を登録したら DS(A) 削除してもらう 子ゾーン 既存 KSK (A) 新規 KSK (B) バリデータに伝播しているキャッシュ 時間軸 published active rolled DS(A)KSK(A) KSK(B) が伝播 KSK(A) と (B) 両方で ZSK に署名 KSK(A) と DS(B)KSK(B) が伝播 DS(B)KSK(B) が伝播 署名を KSK(B) のみにし (A) は削除もしくは rolled とする 子ゾーン側鍵を二重にしておくことで親ゾーンは処理を一度で済ませられる 25

26 KSK / Double-DS( 二重 DS 方式 ) 親ゾーン 上位ゾーンが DS(B) を公開 新規 KSK(B) で署名し交換 KSK(B) がキャッシュに行き渡ったら既存 DS(A) 削除してもらう 既存 DS (A) 新規 DS (B) 登録作業 子ゾーン 既存 KSK (A) 新規 KSK (B) バリデータに伝播しているキャッシュ 時間軸 DS(A) と KSK(A) が伝播 published active rolled DS(A)KSK(A) DS(B)KSK(B) が伝播 新規 KSK の DS(B) を上位ゾーンに申請 DS(A) と DS(B)KSK(B) が伝播 DS(B) と KSK(B) が伝播 署名を新規 KSK に交換し削除もしくは rolled とする 事前公開することで次期 DNSKEY をキャッシュに撒いておく 26

27 KSK / Double RRSet ( 二重 RRSet 方式 ) 親ゾーン 既存 DS (A) 新規 DS (B) 子ゾーン 既存 KSK (A) 登録作業 上位ゾーンが DS(B) を署名 既存 DS(A) 削除してもらう 新規 KSK (B) バリデータに伝播しているキャッシュ 時間軸 DS(A) と KSK(A) が伝播 published active rolled DS(B) と KSK(B) が伝播 新規 KSK の DS(B) を上位ゾーンに申請 KSK(A) を削除 作業タイミングを親子で合わせることで作業工数を減らして交換できる 27

28 鍵のロールオーバーポリシー 危殆化して初めて交換するのか定期的に交換するのかの考え方が二種類ある 特に KSK の場合は親ゾーン管理者との連携作業になるのでロールオーバーのポリシーは良く考えなくてはならない 危殆化して初めての場合 定期的作業の頻度軽減 作業フローを手が忘れてしまう 定期的に交換する場合 人的作業コストの発生 KSK の場合 親ゾーン管理者と都度やりとりする必要が出てくる ( 親ゾーン管理者の作業タイミングの調整や待ち時間等も発生 ) 定期的に行うので作業をルーチン化できる 28

29 トラストアンカー [Secure Entry Point(SEP)] の設定 バリデート ( 検証を行う ) サーバに トラストアンカーとなっている KSK をコピーしてきて設定する KSK は DNSSEC に対応しているゾーンは公開している # dig ドメイン名 DNSKEY 対象 DNS 権威サーバで表示される ( 実際は dig. DNSKEY 推奨 ) ohmo.to IN DNSKEY AwEAAcOSWzyHSLylvhuKGHn38BMYhK9E6l1yzIerWB+Kt2goS1GasMFq yjkyswpaorwcszhi3n871kaqgodubingruekqmcxisljli/hm+.. ohmo.to IN DNSKEY AwEAAb+lrnM0/xl1WnxFCpg4uAOmyhjNvUT+Dx2564w8RK0gmRQmMkuC 3UndYy5K71XZHbZizA5MwKbwx89h6Z/4IERo0LFkBYEVOin5oxxX.. named.conf に以下を設定すると トラストアンカーが署名している下位ゾーンについては検証を行う # trusted-keys { }; でトラストアンカーの KSK を登録 (bind9.7 から RFC5011 に準拠した managed-keys ステートメントが実装された ) managed-keys{. initial-key hoge1234hoge5678..hogehoge ; }; options{ dnssec-enable yes; dnssec-validation yes; } # bind9.5 以降ではdefaultでyesなので必要ない # バリデータとして動作させるか 29

30 トラストアンカーの注意点 1. Validator( バリデータ ) は誰がやるの? リゾルバ ( キャッシュ ) サーバ 仕様としてはエンドのクライアント側でもバリデータとして設定可能 ただし 現段階ではエンド側で対応できるのはこれからというところ 2. トラストアンカーとなる KSK をコピーしてくる手法の信頼性 前頁で紹介した方法だと KSK のキャッシュがすでに汚染していたら 取得した KSK から DS レコードを生成し (dnssec-dsfromkey) 一方で HTTPS で取得した WEB 上の DS レコードを PGP 鍵を利用して真正性を検証 2 つを突き合わせてみる 3. 親ドメインと子ドメイン間の DNSSEC 対応非対応の選択 署名する単位はゾーン単位だから必要なら別ゾーンに小分けする必要がある ( 権威サーバ ) 下位ドメインで先に DNSSEC に対応したいドメインがあればゾーンを分ければよい 4. トラストアンカー設定上での注意点 BIND では trusted-keys に DS を設定するのは DNSKEY じゃないとだめ unbound では DS でも DNSKEY でも両方 OK 30

31 NSEC & NSEC3 NSEC ってなに? 登録していないホスト名についての不在証明レコード 検証した際に そのホスト名のレコードは存在しない ということを証明する zonewalk による露出の危険性 (NSEC) NSEC の場合 zonewalk をすることで登録しているホスト名が意図せずに露出してしまう そのゾーンで管理しているホスト名を問い合わせた際に アルファベット順に次に登録されているレコードが表示される ohmori.example.jp の次の登録レコードは ohmoto.example.jp と表示 それって ohmo(ri~to の ) 間には登録ホストがない事の証明でもある zonewalk 対策となる NSEC3 が登場 NSEC3 では FQDN を一方向にハッシュ化して ハッシュ値をてがかりに不在証明 ただし NSEC に較べても キャッシュサーバの処理に結構な負荷がかかる Janog26 の報告参照 31

32 DLV(DNSSEC Lookaside Validation)( 参考 ) 通常のドメインツリーとは別にDNSSEC 専用の問い合わせ先を用意し root zoneや上位 TLDが対応していなくとも署名の検証を可能とする仕組み DNSSEC 対応 Root servers DNSSEC 未対応.to 権威 DNS サーバ 上位サーバが対応していない DS 登録 ohmo.to の権威 DNS サーバ DLV サーバ DLV サーバに登録してないレコードは通常通り問い合わせ RootZone が DNSSEC 対応したのでほぼ役目は終息 リカーシブサーバ 署名検証 DLV サーバの SEP 鍵を登録している 32

33 OpenDNSSEC( 参考 ) 覚えることも多くて運用するにもかなりの慣れが必要そう 海外のレポートでも DNSSEC に対しての知識がまだエンジニアに浸透していない ( 対応できるエンジニアが少ない ) のが悩みの一つとされている ということで OpenDNSSEC というツールがあります (2010 年 9 月現在 ver1.12 が公開中 ) 鍵更新とゾーン署名の自動化や ゾーンの完全性チェック ソフトウェア HSM も含んだツール 33

34 各 TLD 年 現在と来年春以降のステータス変化 Paul Wouters 氏資料 より 34

35 各 TLD の対応状況 2010 年現在 Paul Wouters 氏の web 公開資料 より 35

36 各 TLD 対応 2011 年初 ( 現在告知分からの想定 ) 詳しいステータスは JPNIC の是枝さんがまとめた資料が参考になります 36

37 技術概要編まとめ 今現在も危険性は潜在しており 国内外問わず 日々 DNSSEC 対応が進んでいる 本格的な DNSSEC 運用に向けて 負荷を軽減するために色んな機能が開発されてきているので敷居は少しずつ低くなってきている DNSSEC の導入には負担や課題も多いが インターネットの基盤を維持するため 導入は進めるべき 37