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