DNSセキュリティ - CMブートキャンプ(社内勉強会)DNS 第3回 /20180214-dns-security-3

Transcript

1. CM ブー トキャンプ( 社内勉強会) DNS 第3 回 DNS セキュリティ
2. 自己紹介 渡辺聖剛 AWS 事業部オペレー ションG（ オペチー） 所属 インフラエンジニア歴 : 20+ 年（ 含む自称） 初めてさわった BIND のバー ジョン : 4.9.2 (1995 年) 好きなコンフィグファイル : mrtg.cfg 好きなプロトコル : CDP
3. agenda DNS セキュリティ # とは DNSSEC
4. DNS セキュリティ # とは
5. アンケー ト結果 : 「DNS セキュリティ」 とは
6. 「DNS セキュリティ」 DNS サー バそのものに対するセキュリティ 権威( コンテンツ)/ キャッシュ DNS クライアント（ リゾルバ） に対するセキュリティ DNS のドメインに対するセキュリティ DNS「 が」 利用されるセキュリティ事案
7. DNS サー バそのものに対するセキュリティ
8. BIND 脆弱性多くね問題 実は最近は DoS ばかり、 権限昇格系の脆弱性はない とはいえ、BIND 10.x は開発が凍結（'17/02） 他の実装に移ろう（ 提案 Unbound, NSD, dnsmasq, PowerDNS / PowerDNS recursor ... BIND にしかない特徴があってそれがネック 特に view 機能 BIND 互換をうたう国産商用実装あります -> XACK DNS
9. 水責め（Water Torture） 攻撃 権威サー バに対する DDoS 攻撃 長くてランダムなクエリを大量に実施 別名 : PRSD（ 擬似ランダムサブドメイン） 攻撃 bot やへぼい家庭用ルー タ、 オー プンリゾルバを使って薄く広く その過程でキャッシュ DNS も巻き添えを喰う asdykuadkncezqalksdljfal.www.example.com. lzkeiakngaldsicxlakdasfj.www.example.com. qsldkfjaoinaldfknaclsljx.www.example.com. : https://jprs.jp/related-info/guide/021.pdf
10. 災害 震災時に、 ある自治体のオンプレ NS がセカンダリごと動作不能に 熊本地震 NS レコー ドへのクエリ応答を継続できない TTL をどうするか悩ましい 権威サー バの全滅に備えるには長い方が良い でも短い方が復旧対応はしやすい（Web サー バなど） https://dnsops.jp/event/20170628/DnsSummerDay2017-JPRS+6ISPs-pub.pdf
11. （ クラウド DNS を使えばいいのでは。。。）
12. リゾルバに対するセキュリティ
13. 中間者（Man-In-The-Middle） 攻撃 クライアントとキャッシュサー バの間に入って通信内容を改ざん デフォルトルー トや DNS サー バの向け先を変える 方法はいくつかあるが L2・L3 レベルが多い マルウェアでネットワー ク設定変更 偽DHCP や偽SSID、ARP スプー フィング 通信内容の盗聴やフィッシング
14. キャッシュポイズニング（ 毒入れ） DNS サー バー への「 キャッシュポイズニング攻撃」 対策について | 法人向けOCN http://www.ocn.ne.jp/business/customer/set_up/poison.html
15. キャッシュポイズニング(cont.) カミンスキー 攻撃（'08/07） によって脅威が実証された DNS キャッシュサー バに、 意図的に誤情報をキャッシュさせる 権威サー バより早くクエリ元（ リゾルバ） に偽の返答を送りつける UDP なので セッションレス = 送信元が偽造可能 先に着いたパケットが正 TXID やクエリポー トが予測できれば攻撃可能になる TTL が短い = 予測のための情報が多い = 攻撃が成功しやすい！ DNSSEC はこの対策の為に生まれた（ 後述）
16. ドメインに対するセキュリティ
17. ドメインハイジャッキング ドメイン自体の乗っ取り 上位 DNS への申請を偽造 更新忘れのドメイン 破棄されたドメイン 現在の仕組み上どうしようもない
18. 似たドメインの取得 フィッシング目的、 元ドメインのイメー ジを拝借 「 ドメイン商法」「 ドメイントロー ル」 classmethod.xxx とか .xxx is a sponsored top-level domain (sTLD) intended as a voluntary option for pornographic sites on the Internet. “ “ https://en.wikipedia.org/wiki/.xxx
19. 他の攻撃に利用されるDNS
20. DNS Ampli cation Attack DNS アンプ攻撃、DNS リフレクター 攻撃 送信元を偽造しクエリをキャッシュ DNS に送信 キャッシュDNS から「 送信元」 に応答が送りつけられる（DDoS） キャッシュ DNS として、 へぼい家庭用ルー タがよく狙われる 対策すすんで最近は減った？
21. DNS プロトコルを使用した C&C C&C = コマンドアンドコントロー ル bot・ マルウェアのコントロー ルをクエリ・ 応答で実施 ファイアウォー ルの奥からでも大抵通信出来る 怪しまれにくい・ ブロックされにくい とはいえ水責め攻撃の PRSD に似てなくもない 一部のフィルタ・ セキュリティソフトが似た挙動をする 紛らわしい
22. DNS Zone Walking そのゾー ンに含まれる全 A/AAAA レコー ドを入手する手法 DNSSEC の仕様を使う（ 後述） AXFR が禁止されていても安心できない 次のアタックのための予備調査で使われる
23. (cont.) AWS への侵入テスト申請項目 DNS Zone Walking の項目がある DZW トラフィックは監視されている（ と思われる）
24. DNSSEC
25. アンケー ト結果 : DNSSEC の印象 Powered by: Free online Wordcloud generator https://www.wordclouds.com/
26. DNSSEC とは RFC 2535 "Domain Name System Security Extensions" 正式な権威サー バからの応答かどうかを検証できる仕組み リゾルバ、 特に（ 主に） キャッシュサー バが検証する 公開鍵暗号＋ 電子署名 クエリ・ 応答の盗聴防止の機能はない（ 誰でも復号可能だから） ゾー ン情報の改ざんにクライアント（ リゾルバ） が検知できる 毒入れされている -> アクセスしない ！ 権威サー バを攻撃から守るものではありません！
27. DNSSEC の仕組み ゾー ンごとに秘密鍵・ 公開鍵を用意 dnssec-keygen ゾー ン情報（ 各 RR） を秘密鍵で署名 dnssec-signzone 公開鍵のハッシュ値を親ゾー ンに登録（DS）
28. 信頼の連鎖 (chain of trust) RR の正しさ -> DNSKEY と RRSIG で検証 DNSKEY の正しさ -> 親ゾー ンの DS が保障
29. RR が「 存在しない」 ことの検証 無い RR を「 無い」 と返事することは大事 存在する RR は、 対になる RRSIG で検証可能 存在しない RR に対する署名 -> NSEC,NSEC3 前後の存在する RR を示すことで不存在を証明 NSEC > DNS Zone Walking に利用されてしまう NSEC3 > DNS Zone Walking には使えないが演算コスト高 R:「xxx っていうホストの A レコー ドは？」 A:「（www と yyy の間に A レコー ドはひとつも） 無いです」
30. 実際にみてみよう！ 正しく DNSSEC 署名されているドメイン jprs.jp. , whitehouse.gov. , verisign.com. etc. わざと間違った DNSSEC 署名になっているドメイン dnssec-failed.org. dig +dnssec ... DNSSEC で署名確認する 検証に成功 : status: NOERROR / ags: ad (Authentic Data) 検証に失敗 : status: SERVFAIL $ dig @8.8.8.8 +dnssec < ドメイン名> <RR>
31. 例 : jprs.jp $ dig @8.8.8.8 +dnssec jprs.jp. ; <<>> DiG 9.9.7-P3 <<>> @8.8.8.8 +dnssec jprs.jp. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64664 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 : ;; ANSWER SECTION: jprs.jp. 120 IN A 117.104.133.164 jprs.jp. 120 IN RRSIG A 8 2 300 20180307023003 2018020502300 :
32. ちょっとまって！
33. そのドメイン、 本当に署名されてる？ DS かDNSKEY RR をクエリする 応答が返ってきたら署名されている $ dig whitehouse.gov. ds : ;; ANSWER SECTION: whitehouse.gov. 3600 IN DS 24048 7 2 947BD...
34. そのキャッシュサー バ、 本当に検証してる？ 検証してない場合 -> 無条件成功 dnssec-failed.org. を引いてみる 検証以外の理由で失敗したわけではないことを確認 +cd ... チェックは行わない(Checking Disabled) -> 無条件成功 $ dig @8.8.8.8 +dnssec dnssec-failed.org. a $ dig @8.8.8.8 +dnssec +cd dnssec-failed.org. a
35. ハンズオン いろんなキャッシュサー バを指定して試してみて下さい パブリックDNS（Google,OpenDNS,Verisign,Quad9） ご自宅・ 職場のキャッシュDNS クラウドインフラのキャッシュDNS 等々
36. Route 53 と DNSSEC 権威サー バとしての Route 53 は未対応 でもドメイン購入時には DNSSEC サポー トあり 当然、Route 53 以外の NS が必要 http://www.cloudmonix.com/blog/delegate-dns-domain-from-aws-to-azure/
37. 参考 : DNSSEC と ALIAS A/AAAA レコー ドが変わるとその度に署名し直す必要がある RRSIG,NSEC,NSEC3 の再計算 ALIAS レコー ド : A/AAAA が動的に変化する 複数 PoPs をもつ Route 53 だと権威同士の同期が大変そう？ Google Cloud DNS, Azure DNS ... 類似の機能無し オンプレミスだと PowerDNS が ALIAS 独自実装 + DNSSEC 対応 ANAME RR が IETF でドラフト策定中、 ゾー ン転送への言及あり
38. 署名鍵 ZSK (Zone Signing Key / ゾー ン署名鍵) 1024bit KSK (Key SigningKey / 鍵署名鍵) 2048bit ZSK を署名する どちらも DNSKEY レコー ドで公開される フラグ : 256 (ZSK), 257 (KSK) whitehouse.gov. 7200 IN DNSKEY 257 3 7 AwEAAd8... whitehouse.gov. 7200 IN DNSKEY 256 3 7 AwEAAZU... whitehouse.gov. 7200 IN DNSKEY 256 3 7 AwEAAfY... ^^^ フラグ
39. 真・ 信頼の連鎖 KSK <- 親ゾー ンの DS が保障 ZSK <- KSK で署名（RRSIG DNSKEY） 各RR <- ZSK で署名（RRSIG <RR 名>） キャッシュサー バは予め root のKSK 公開鍵の情報を持つ トラストアンカー root-anchors.key (BIND), /etc/trusted-key.key (Linux) OS やブラウザがルー ト証明書を持ってるようなもの トラストアンカー の検証 -> PGP 鍵を別途入手することで可能
40. 真・ 信頼の連鎖 (cont.)
41. 鍵のロー ルオー バー 定期的な鍵の更新と再署名 ZSK ... 数ヶ月に1 回 KSK ... 年単位 RR の書き換えで実施される KSK の更新時には同時に DS も更新要 RFC5011（ トラストアンカー の自動更新） あくまで推奨、 システム的な期限はない ※ RRSIG には有効期限がある -> 忘れずに再署名！
42. KSK ロー ルオー バー で何が大変だったのか DNSSEC 運用開始して初めての root KSK ロー ルオー バー 交換中、 新旧の鍵の重複運用により一時的に応答パケットが太る 大きなパケットを通さない経路の先にあるリゾルバが名前解決不可 他にも、 トラストアンカー の更新をしないキャッシュとか。。。 進捗 新しい鍵(KSK-2017) の公開 -> 完了（'17/07） ZSK ロー ルオー バー -> 完了（'17/09） KSK ロー ルオー バー -> ...
43. あまりに大変だったので延期になりました ICANN 発表（'17/09/27） https://www.icann.org/news/announcement-2017-09-27-ja 日本のリゾルバは、 世界平均以上に影響あり（ らしい） https://blog.nic.ad.jp/blog/postponed-ksk-rollover/ KSK 鍵の変更（ ロー ルオー バー） は当初、10 月11 日を予定していま したが、 最近収集したデー タで、 非常に多くのインター ネットサー ビスプロバイダー（ISP） とネットワー ク事業者のリゾルバで変更 への対応が完了していないことが明らかになったため、 ロー ルオー バー の実施を延期することにしました。 “ “
44. 今後 再開に向けた実施計画案を発表 ('18/2/2) ICANN 発表 いまのところ '18/10/18 実施を計画 影響調査の方法・ 結果にも疑問が残っている
45. ハンズオン 2 : KSK ロー ルオー バの影響チェック CLI の場合 at least の次に出力される数値が 1424 以上であること $ dig +bufsize=4096 +short rs.dns-oarc.net txt rst.x4090.rs.dns-oarc.net. rst.x4058.x4090.rs.dns-oarc.net. rst.x4064.x4058.x4090.rs.dns-oarc.net. "219.104.27.149 DNS reply size limit is at least 4090" "219.104.27.149 sent EDNS buffer size 4096" KSK ロー ルオー バー について - JPNIC https://www.nic.ad.jp/ja/dns/ksk-rollover/
46. ハンズオン 2 : KSK ロー ルオー バの影響チェック Web ブラウザの場合 > DNSSEC Key Size Test http://keysizetest.verisignlabs.com 1～4 が PASS であること
47. Q&A / freetalk