オープンリゾルバ問題、立ちふさがるはデフォルト設定？：JANOG 31.5 Interim Meetingレポート

4月19日に開催されたJANOG 31.5 Interim Meetingの「DNS Open Resolverについて考える」では、ネットワーク管理者はもちろん、ネットワークサービス提供者や機器ベンダなど、インターネットにさまざまな立場から携わるメンバーが、それぞれの立場で取ることができるオープンリゾルバ対策について議論が交わされた。

[高橋睦美，＠IT]

　「自分が管理しているネットワークには、オープンリゾルバ状態のDNSサーバは存在しない」、そう断言できるネットワーク管理者やユーザーはどれだけいるだろう。3月に発生した史上最大規模のDDoS攻撃をはじめ、他者への攻撃に荷担していないと言い切れるだろうか？

　実は、CloudFlare（3月18日ごろから発生した「Spamhaus」に対する大規模なDDoS攻撃でも対応に当たったセキュリティ企業）が、2月19日から3月1日にかけて行われたAPRICOT 2013で発表したレポート、「The curse of the Open Recursor」によると、同社が観測した攻撃に利用されていたオープンリゾルバのうち、日本国内に存在するものの数は、中国（3123件）や台湾（3074件）よりも多い4625件で、アジアの中で最多だった。

　4月19日に開催されたJANOG 31.5 Interim Meetingの「DNS Open Resolverについて考える」では、この衝撃的な事実を踏まえ、ネットワーク管理者はもちろん、ネットワークサービス提供者や機器ベンダなど、インターネットにさまざまな立場から携わるメンバーが、それぞれの立場で取ることができる対策は何かについて議論が交わされた。

オープンリゾルバとは何か、何が問題か

　「オープンリゾルバ」とは、不適切な設定のために、誰からの問い合わせにも答えてしまうキャッシュDNSサーバのことだ。本来ならば、適切なアクセスコントロールが施されるべきキャッシュDNSサーバにそれが設定されておらず、外部からの問い合わせにも応答を返してしまう状態を指す。

　なぜこれが問題かというと、DNSの特徴が関連してくる。DNSでは、問い合わせのパケットに比べ、応答パケットのサイズが非常に大きなものとなり得る。この特徴を悪用し、送信元IPアドレスを、ターゲットとなる犠牲者に詐称（＝IPスプーフィング）した問い合わせパケットをオープンリゾルバに投げつけることで、1つ1つのサイズが大きな応答パケットが大量に被害対象に送りつけられ、DDoS状態に陥ってしまう。この特徴から、オープンリゾルバを悪用したDDoS攻撃は、「DNSリフレクション攻撃」や「DNS Amplification Attacks」（DNS増幅攻撃、DNS amp）などと呼ばれている。

「DNS Open Resolverについて考える」の進行役を務めた高田美紀氏

　「DNS Open Resolverについて考える」の進行役を務めた高田美紀氏が示した1つのデータは、その増幅率の高さを示していた。とある地方ISPで、オープンリゾルバがポート53のトラフィックに与える影響を調べたところ、インバウンドトラフィックは平均で約27.5Kbps、最大67.3Kbps程度だったのに対し、アウトバウンドトラフィックは平均2.3Mbps、最大で5.9Mbpsに達した。たった1つのオープンリゾルバによる増幅率は90倍に上り、「K」から「M」へと、文字通り桁違いのトラフィックが生成されてしまうことが明らかとなった。

　高田氏は、オープンリゾルバの最大の問題点は「それと知らずに攻撃者になってしまう可能性があること」だと指摘する。例えば、1台のサーバで権威DNSサーバとキャッシュDNSサーバの両方をまかなおうとして、適切にアクセスコントロールを行わないままだと、オープンリゾルバを作り出してしまうことになる。また、ソフトウェアやそのバージョンによっては、明示的にキャッシュDNSサーバ機能をオフにしないと、権威DNSサーバだけを設置するつもりだったのに、意図せずオープンリゾルバを生み出すことになる。

　その上で同氏は、オープンリゾルバ対策と、BCP38によるIPスプーフィング対策という両輪の対策が必要だと述べた。

IPスプーフィング対策の有効性

BCP 38の効果について説明した松崎吉伸氏

　BCP 38は、RFC 2827で規定されている、送信元IPアドレスの詐称を防ぐための技術だ。送信元IPアドレスを偽装した不正なパケットをはじき、オープンリゾルバへのDNS問い合わせパケットを受け付けないようにするとともに、「送信元（＝攻撃元）をちゃんと追跡できることもメリット」（インターネットイニシアティブ（IIJ）の松崎吉伸氏）という。

　実装方法には「パケットフィルタ」と「uRPF strictモード」の2種類ある。できるだけパケットの送信元に近い場所で実装する方が、絞り込みが容易で、よりきめ細かく送信元アドレスの検証が行えるため、ベターだという。

　松崎氏によると、確かにBCP 38は一定の効果があるという。実際、IIJでも2006年ごろからBCP 38を導入しており「うまく動いている」（同氏）という。

　実際、先日、IPスプーフィングで送信元を詐称したSYN FloodによるDoS攻撃を受けた際、uRPF（looseモード）によってかなり影響を軽減できたということだ。「uRPF strictモードならば、ほぼ無視できる程度の影響しか受けなかっただろう。DNS amp攻撃に限らず、いろいろな攻撃に有効な手段だ」（松崎氏）。

対策の前に立ちふさがる「強い」デフォルト設定

　もう1つの対策は、キャッシュDNSサーバの設定を適切に変更し、オープンリゾルバ状態のサーバをなくしていくことだ。ただここで、「デフォルトの設定が強すぎる」（高田氏）、つまり、デフォルト設定のまま利用し続け、セキュリティ対策などを理由にわざわざ設定を変えるユーザーが少ないという課題が立ちふさがるという。

　古いVPSサービスなどでは、テンプレートに、外部からの再帰的問い合わせを拒否するための「recursion=no; 」の設定が書かれておらず、キャッシュDNSサーバが動いてしまう状態だった。CloudFlareのオープンリゾルバのリストには、こうしたサービスの名前が多かったという。こうした状況から類推して、「古いLinuxディストリビューションなどでも、デフォルト設定は同じ状況ではないか」と高田氏は指摘した。

ホスティングサービスのデフォルト設定が影響を及ぼしているのではないかと指摘した久保啓司氏

　このことは、JPCERT/CCの久保啓司氏の発表でも指摘された。JPCERT/CCでは、CloudFlareとの情報共有に基づいて、オープンリゾルバ状態になっている数千のIPアドレスの管理者に対応を依頼してきた。これまでに40％程度で対応が進んでいるという。

　日本国内のオープンリゾルバ状態のIPアドレスを、JPCERT/CCで分類したところ、42％は「ホスティング」、21％が「回線サービスを利用しているユーザー宅」で、企業が利用しているDNSサーバはわずか7％という。

　しかも、「ホスティングサービスのDNSサーバについて調査したところ、DNSサーバが動作していること自体が不自然なホストが非常に多い。中には、間違えて動作させてしまっているものもあるだろうが、本来DNSが動作する必然性がないのにオープンリゾルバになっているものが非常にたくさんある」（久保氏）。やはり、何からかのデフォルト設定が影響し、いまの状態を生み出しているのではないかと述べた。

　さらに、回線サービスについては、ブロードバンドルータの中に、WAN側からの問い合わせに答えてしまう設定となっている機器が存在しているという。

管理者以外も巻き込んだ対策を

　こうした状況の中、オープンリゾルバ問題を解決すべき理由とは何か。

　1つはもちろん、DDoS攻撃にわずらわされない、「明るいインターネットの未来」を作り出すためだ。高田氏は、「皆さん、自社ネットワーク内のオープンリゾルバの数を把握していますか？」と問いかけ、まずはOpenResolverProjectのサイトで、自分の管理下にあるオープンリゾルバを把握してほしいと呼び掛けた。

　同時に、経営層など会社の上層部に向けては、「本来不要なDDoSが生み出すトラフィックに要するコストを削減できるという理由も有効かもしれない」（高田氏）という。

　その上で、ネットワーク事業者がまず取り組める対策として、自組織のDNSサーバやルータなのか、それとも顧客の責任下にあるものかという「設備」、すでに提供済みであり、デフォルト設定を変更する前に利用している顧客を特定し、説明するなどの対応が求められる既存サービスか、それとも新設のサービスかという「タイムライン」、そして「対処方法」という3つの軸を意識しながら、キャッシュDNSサーバのアクセス制限やテンプレートの変更といった対策を検討すべきとした。

　さらに、コミュニティ全体として「周知啓蒙」も進めていくべきという。それも、DNSサーバの設定に携わるネットワーク管理者だけでなく、著名なディストリビューションのBINDパッケージャや設定情報の提供者などとの連携も視野に入れたいという。

　一方でブロードバンドルータについては、まだどの機種がオープンリゾルバに該当するか分からない状況なので、ぜひ情報を持ち寄ってベンダに提案していければと述べた。

オープンリゾルバ対応、いつやるの？ 「今でしょ！」

　議論を踏まえた質疑応答のコーナーでは早速、ブロードバンドルータの情報共有に関して、JPCERT/CCが脆弱性情報ハンドリングの取り扱いを開始していることに触れ、情報の提供を歓迎した。さらに、ミーティングに参加していたブロードバンドルータのベンダ担当者からも、「そうした情報があればベンダ側にも連絡してほしい。ぜひ協力したい」との声が上がったほか、逆に、問題がない機種を集めた「ホワイトリスト」を作成すべきではないかという意見も出た。

　一方、ホスティング事業者の立場からは、顧客の設定との兼ね合いで、オープンリゾルバ設定をやめたくてもやめられない場合があるという、切実な悩みの声が上がった一方で、顧客に確認を取りながら順次設定を変更し、対応することができたという明るい声も寄せられた。

　さらに、「オープンリゾルバ」という言葉に問題があるのではないかというユニークな指摘も飛び出した。つまり、「オープン」というポジティブな印象を与える単語の代わりに「有害リゾルバ」と表現すべきではないかという。

　高田氏は最後に、現在のDNSとオープンリゾルバを巡る状況は、メールサーバのサードパーティリレー問題（オープンリレー問題）が浮上した当時を思い起こさせるものがあると述べた。当時、サードパーティリレー問題に対応するため、POP before SMTPやSMTP AUTHなどの技術が開発された。それらを利用し第三者中継の制限を適用した事業者もあったが、一方で不適切な設定が修正されないままのMTAも数多くあった。この状況といまのオープンリゾルバ問題は似通っているように思えるという。

　そして、数年前から問題になっていたオープンリゾルバ問題への対処を、いまは実害がないからと後回しにするのではなく、今から取り組んでほしいと述べた。「いつやるの？ 今でしょ！」（高田氏）。