ブルームフィルタを利用したランダムサブドメイン攻撃（dns水責め攻撃）の対策...

ブルームフィルタを利用した ランダムサブドメイン攻撃からのDNSキャッシュサーバの防御

東　大亮

1

（更新版）

ランダムサブドメイン攻撃 （に巻き込まれたキャッシュサーバ）

victim.com 権威サーバ

キャッシュ サーバ

正規ユーザ

攻撃者(踏み台)

www.victim.com?

mail.victim.com?

awfbh.victim.com?uscz8.victim.com?abqce.victim.com?qpdks.victim.com?

qpdks.victim.com?

abqce.victim.com?uscz8.victim.com?awfbh.victim.com?

www.victim.com?

mail.victim.com?

2

キャッシュサーバにおける 一般的な防御

victim.com 権威サーバ

キャッシュ サーバ

正規ユーザ

攻撃者(踏み台)

www.victim.com?

mail.victim.com?

awfbh.victim.com?uscz8.victim.com?abqce.victim.com?qpdks.victim.com?

❌❌

❌❌❌❌

victim.comゾーンへの問い合わせをすべてブロック or レートリミット

BIND9: ローカルゾーン、fetch-per-zone、fetch-per-server Unbound: ローカルゾーン、ratelimit (ver1.5.4～)

3

攻撃対象ゾーンへのクエリをブロックすると・・・

• 確かにキャッシュサーバは防御できるが、そのゾーンはキャッシュサーバで完全に解決不可(DoS)状態になる

• ある意味、攻撃者の思う壺！

• 有名ドメイン名への攻撃に巻き込まれたら？ “google.com”や“twitter.com”をブロックするのか？

• 自動的に攻撃対象ゾーンを検出する機構を運用していた場合、攻撃でないものを攻撃と誤検知し、ブロックすべきでないゾーンをブロック対象にしてしまったら？

• 攻撃クエリはブロックし、正規クエリは受けつけて名前解決したい！

4

防御の理想形victim.com 権威サーバ

キャッシュ サーバ

正規ユーザ

攻撃者(踏み台)

www.victim.com?

mail.victim.com?

awfbh.victim.com?uscz8.victim.com?abqce.victim.com?qpdks.victim.com?

❌❌❌❌

www.victim.com?

mail.victim.com?

victim.comゾーンへのクエリのうち、正規クエリのみ受け付けしたい！

5

正規クエリと攻撃クエリの 判定

www.victim.com?mail.victim.com?

awfbh.victim.com?uscz8.victim.com?abqce.victim.com?qpdks.victim.com?

正規クエリは存在するドメイン名へのクエリ: 結果はNOERROR

攻撃クエリは存在しないドメイン名へのクエリ: 結果はNXDOMAIN

6

正規クエリ

攻撃クエリ

キャッシュサーバ（リゾルバ）が、権威サーバに問い合わせる前に、NOERRORになりそうなクエリかどうか

判定できればよい（さもなくばブロック）

「NOERRORになりそうな クエリ」

• そのキャッシュサーバで、過去N時間までにNOERRORになったドメイン名(QNAME)へのクエリは、今度のクエリも「NOERRORになりそう」と仮定して受け付ける

• 逆に、過去N時間までにNXDOMAINになった／ユーザからのクエリが無かったQNAMEは、今回もNXDOMAINになる／正規ユーザも関心が無いドメイン名とし仮定し、攻撃中はブロックしても問題ないと仮定

• Nは比較的長時間 (N=24時間 or 48時間 etc)

7

過去24時間のNOERRORなQNAMEを どうやって覚えておくか？

• DNSのクエリは超大量にある

• (主に攻撃を受けやすい)ISP環境では、数千～数万クエリ/秒

• 記憶には大量のメモリが必要

• 防御時に高速検索が必要

8

NOERRORなドメイン名をブルームフィルタで記憶

• ブルームフィルタ(Bloom filter)とは

• 検索キーが、検索対象の集合に属しているか否かを、少ないメモリ量で記憶し、高速に判定可能な確率的データ構造

• Wikipediaの同名記事の解説がわかりやすい

9

ブルームフィルタの特徴• 使用メモリが少ない

• 1%の偽陽性率ならば、9.6ビット/要素のメモリ量でよい。

• 8.6億個 (≒毎秒1万個×24時間) の QNAMEなら1Gバイトでよい

• 記憶・検索が高速

• 記憶・検索いずれもO(1)

• 記憶済の要素数・メモリ量に応じ、偽陽性が発生する

• 偽陽性(false positive)とは、検索キーが検索対象の集合に存在しないのに「存在する」と誤って判定してしまうこと。

• なお、BFでは偽陰性（存在するのに「存在しない」と誤判定）は発生しない

10

※BF記憶・検索の時間計算量は記憶済の要素数や使用メモリ量には依存しない。厳密には偽陽性率を決めるパラメータkに比例はするが、偽陽性率1%で固定すればO(1)と見なせる

Unboundに実装してみた

• 通常時の動作

• ユーザからのクエリのうち、NOERRORとなったQNAMEを、ひたすらBFに入力

• 攻撃時の防御

• 攻撃対象ゾーンへのクエリのうち、BFにヒットするもの(過去にNOERRORになったもの)を受け付け。ヒットしないものはブロック。

• 攻撃対象ゾーンは、手動指定の他、自動判定＋BF自動適用が可能

11

Githubで公開してます: https://github.com/hdais/unbound-bloomfilter

Bloomfilterによる victim.comゾーン宛クエリの防御

victim.com 権威サーバ

キャッシュ サーバ

正規ユーザ

攻撃者(踏み台)

www.victim.com?

mail.victim.com?

awfbh.victim.com?uscz8.victim.com?abqce.victim.com?qpdks.victim.com?

❌❌❌❌

www.victim.com?

mail.victim.com?

12

veryrarename.victim.com?❌

ugjks.victim.com?

BFにマッチしないQNAMEは正規・不正クエリに関わらずブロック

BFの偽陽性のため、攻撃クエリもわずかに「漏洩」する

BFにマッチするQNAMEは受け付け・再帰検索処理を行う

unbound-bloomfilterの 使用法

• BF有効化・使用するメモリ量・BFのリセット時間間隔の設定 (unbound.conf)

server: bloomfilter-size: 1024m bloomfilter-interval: 86400

→BF学習が有効になる。使用するメモリは1GBx2=2GB。86400秒毎にBFをリセット

• 手動指定：ランダムサブドメイン攻撃時に、BF適用対象ゾーンを手動指定 (CLI)

$ unbound-control local_zone victim.com bloomfilter→victim.comゾーンへのクエリにBF適用

13

$ unbound-control local_zone_remove victim.com→victim.comゾーンへのBF解除

unbound-bloomfilterの 攻撃ゾーン自動判定①

14

• ゾーン毎に、requestlist (BIND9のrecursive clientsに相当) に長時間居座るクエリ数を制限

server: bloomfilter-size: 1024m bloomfilter-interval: 86400 bloomfilter-threshold: 100

→ requestlistに長時間(2秒以上)居座るクエリが 　100個を超えたゾーンにBF適用 （一定時間後、自動解除） 　ゾーンの分類にはpublicsuffixlistを使用。

QNAME クライアントから受信してからの経過時間

nwdw.victim.com 3.2msdfw.victim.com 0.1sdjef.victim.com 2.3dmsfg.victim.com 2.4www.example.com 1.3mail.example.com 0.2

ゾーン 2.0秒以上「居座っている」 クエリ数

victim.com 3example.com 0

クエリ数がbloomfilter-threshold指定値を超えているゾーンを自動的にブルームフィルタ

requestlistの内容 名前解決に時間がかかっているクエリ数をゾーン毎に集計

saywc.victim.com

unbound-bloomfilterの 攻撃ゾーン自動判定②

• ゾーン毎に、BFマッチしないキャッシュミスクエリをレートリミット

server: bloomfilter-size: 1024m bloomfilter-interval: 86400 bloomfilter-ratelimit: 1000

→ ゾーン毎にキャッシュミスは1000qpsに制限。超えたものはBF適用。ゾーンの分類にはpublicsuffixlistを使用

キャッシュ サーバ

❌❌❌

1000qps

BFにマッチするクエリは ratelimit非適用

victim.com 権威サーバ

mail.victim.comwww.victim.comnsjkf.victim.comkjsvd.victim.com

ujekc.victim.comejsdv.victim.comijkac.victim.com

正規ユーザ

攻撃者

正規ユーザ example.com 権威サーバ

BFにマッチせず、 キャッシュミスしたクエリはゾーン毎にratelimit

www.example.com

ratelimit値に達しないゾーンへのクエリには影響なし

2000qps

課題• そもそも「過去N時間にNOERRORになったクエリのみ受け付ける」が正規クエリのみ受付けるために有効なのか？

• まったく未検証！

• 有効だとしても、どのようなチューニングをすべきか？ 特に、過去どれだけの期間・個数のNOERRORなドメイン名を集めればよいか

• ワイルドカードなゾーン (tumblr.comとかblogspot.jp)が攻撃された時は無力かもしれない

• 通信の秘密！攻撃時はともかく、平常時でもユーザクエリを分析してBFに漬け込むのはどうなのよ etc

16

現状• unbound-users MLでbloomfilterを紹介したら、海外某ISPの方から色々問い合わせ。使ってくれてるらしい。

• Unbound本家も、unbound-bloomfilterやBIND9を意識したのか、実験的なランダムサブドメイン攻撃対策が入った (ver 1.5.4～)

• ゾーン毎にキャッシュミス数をratelimit

• ratelimit超えたキャッシュミスクエリはブロックするが、1/10 (設定変更可能)の確率で受付ける。正規ユーザから人気があるQNAMEなら、いずれブロックをすり抜けて受付けられキャッシュに乗るだろうとの仮定。

• 「ゾーン毎」を分類するのにPublic Suffix Listは使用していない（これはGood）

17

END

backup slides

unbound-bloomfiter 名前解決速度への影響

• 通常時 (キャッシュミス 100%の最悪時）

• BFに学習なし: 15,863 qps

• BFに学習あり: 14,810 qps ▲6.64%

• victim.com防御時 (victim.comへのクエリ100%の最悪時)

• victim.com refuse: 135,617 qps

• victim.com bloomfilter: 113,953 qps ▲16.0%

• (参考) victim.com キャッシュヒット: 95,371 qps

通常時のBF学習のペナルティは、100%キャッシュミスの最悪時でも6～7%程度。 bloomfilter防御時のペナルティは、REFUSEよりも16%悪いが、キャッシュヒットよりは高速

テストマシン: Core2Duo 1.6GHz(2core) / Mem 2GB BFサイズ: 1GB / キャッシュサイズ1GB

20

攻撃対象ドメインへのクエリをブロックすると・・・

21

cloudflare.comへの水責め攻撃に巻き込まれた某ISPのキャッシュサーバ

そのISPはcloudflare.comへのクエリをすべてブロックした

clouldflare.comへの正規クエリと攻撃クエリを、キャッシュサーバが機械的に識別することは、普通は困難のため、全クエリをブロックせざるを得ない （そうしなければ、サーバが過負荷で停止してしまう）