DNS Amp攻撃に関する現状と対策のまとめ
-
OrangeMorishita
- 12220
- 0
- 23
- 13
-
- いいね！13
Yasuhiro Morishita
@OrangeMorishita
前にもツイートした気がするけど、DNS Amp攻撃を考える場合、2つのケースを分けて考えるべきと思う。一つはオープンリゾルバーを使ったDNS Amp攻撃で、もう一つは権威DNSサーバーを使ったDNS Amp攻撃。
2013-03-28 19:37:07
Yasuhiro Morishita
@OrangeMorishita
.@OrangeMorishita （承前）そのうち、オープンリゾルバーによるDNS Amp攻撃はJPRSでも既に解説している。例えばこのへん。// DDoSにあなたのDNSが使われる〜DNS Ampの脅威と対策〜 http://t.co/MMpoVbLost
2013-03-28 19:52:26
Yasuhiro Morishita
@OrangeMorishita
.@OrangeMorishita （承前）オープンリゾルバーによるDNS Ampの対策についてはこのトピックス＆コラムを作った頃（初版作成は2007年）とあまり変わっていない。せいぜいresponse rate limiting（後述）が増えたぐらい。
2013-03-28 20:34:42
Yasuhiro Morishita
@OrangeMorishita
.@OrangeMorishita （承前）そして、JANOG MLなどで話題になっている件や、昨日あたりから報道が出てきているSpamhaus/CloudFlareの件などは、どうも前者（オープンリゾルバ使用）だったらしい（資料まだ読んでないので未確認）。
2013-03-28 20:48:27
Yasuhiro Morishita
@OrangeMorishita
.@OrangeMorishita （承前）最近、権威DNSサーバーを踏み台に使ったDNS Amp攻撃が報告されるようになった。実はこの問題は新しいものではない。JPRS民田の2006年の発表資料 // 実はコンテンツサーバもヤヴァい http://t.co/A4HeTIHnzH
2013-03-28 21:04:16
Yasuhiro Morishita
@OrangeMorishita
.@OrangeMorishita （承前）この資料の4ページ目から。// 1) すでに大きなレコードが登録してあるかも 2) その性格上サービス対象を絞ることはできない → どこからの問い合わせに対しても応答を返さないといけない
2013-03-28 21:07:14
Yasuhiro Morishita
@OrangeMorishita
@OrangeMorishita （承前）ということで権威DNSサーバーの場合「どこからの問い合わせに対しても応答を返さないといけない」というのがポイントで、オープンリゾルバーに対する対策と最も異なっている点。
2013-03-28 21:08:53
Yasuhiro Morishita
@OrangeMorishita
@OrangeMorishita で、以前からこの問題はあった（DNSはそもそも応答が問い合わせより必ず大きくなる）のが、DNSSEC、SPF/DKIM、IPv6などの普及により応答サイズ（＝増幅率）が大きくなり、問題が顕在化してきた。
2013-03-28 21:11:19
Yasuhiro Morishita
@OrangeMorishita
@OrangeMorishita で、この問題の影響をするために最近「DNS RRL（DNS Response Rate Limiting）」という技術が提唱・実装されはじめた。
2013-03-28 21:15:00
Yasuhiro Morishita
@OrangeMorishita
@OrangeMorishita DNS RRL（以下、RRL）はとても簡単に言うと「DNSサーバーにおいて、単位時間当たりの同一内容の応答レートを制限する」もの。つまり「短時間の間に同じ応答を返すのを制限する」ためのしくみ。
2013-03-28 21:18:50
Yasuhiro Morishita
@OrangeMorishita
@OrangeMorishita ということでRRLは、特に権威DNSサーバーに対して有効な対応手段となる。というよりキャッシュDNSサーバーに対してうかつに導入すると、副作用が生じる場合がある（なんでかは考えてちょ）。
2013-03-28 21:21:48
Yasuhiro Morishita
@OrangeMorishita
@OrangeMorishita で、「問い合わせは基本的にキャッシュDNSサーバーからのものである（はず）」「キャッシュDNSサーバーはキャッシュ機能を備えており、同じ問い合わせを短時間の間に繰り返すことはない（はず）」ということが前提になっている。
2013-03-28 21:23:57
Yasuhiro Morishita
@OrangeMorishita
@OrangeMorishita ただ、これは（はず）というぐらいで、RRLをちゃんとやろうとすると実は割と難しくて（false positiveとか）、現状では運用ノウハウの蓄積がまだまだ必要なかんじ（と少なくとも私は思っている）。
2013-03-28 21:26:24
Yasuhiro Morishita
@OrangeMorishita
@OrangeMorishita …そんなわけで最近、有効な手段の一つとしてRRLが実装されはじめている。BIND 9（今は追加パッチ、9.10で標準サポート予定）、NSD、Knot DNSなど、実装対象が権威DNSサーバーなのは、さっきツイートした理由による。
2013-03-28 21:29:11
Yasuhiro Morishita
@OrangeMorishita
@OrangeMorishita …ということで、DNS Ampに関する現状のまとめはこんなところでしょうか。下書きせずにその場で脳内からタイプしたので、ツッコミどころ多いかもです。そのへんは遠慮なくメンションなどいただければと。
2013-03-28 21:30:34
Yasuhiro Morishita
@OrangeMorishita
http://t.co/sCthXH5y05 の「問題の影響をするために」は「問題の影響を軽減（mitigate）させるために」ですね。
2013-03-28 21:44:12
Yasuhiro Morishita
@OrangeMorishita
（これからこの問題はいろいろと対応が必要そうなので、まずは自分の脳内を整理しつつ、状況を書き連ねてみたということで）
2013-03-28 21:48:54
Yasuhiro Morishita
@OrangeMorishita
参考リンク1（提唱者のPaul Vixie氏によるページ）：Response Rate Limiting in the Domain Name System (DNS RRL) | Red Barn http://t.co/EAmBYg3qYL
2013-03-28 21:53:46
Yasuhiro Morishita
@OrangeMorishita
参考リンク2（DNS RRLの現在のドラフト版仕様：ISC Technical Noteフォーマット）：DNS Response Rate Limiting (DNS RRL) http://t.co/phnlPVowAK
2013-03-28 21:54:54
Yasuhiro Morishita
@OrangeMorishita
参考リンク3：NLnet LabsのMatthijs Mekking氏（NSDにRRL実装した人）の発表資料。49ページに「DNS RRLはいたちごっこ（a cat-and-mouse game.）」という記述あり。 http://t.co/GTqKprlTp2
2013-03-28 22:01:28
Yasuhiro Morishita
@OrangeMorishita
というわけでキャッシュDNSサーバーと権威DNSサーバーを兼用していると、DNS RRLを入れにくくなるケースが生じると考えられます。権威／キャッシュの兼用はどこまでいっても悪で、センス悪いということで。
2013-03-28 22:12:04