ＡＤＳＬ - 1036554230 - したらば掲示板

991：とはずがたり：2015/11/10(火) 18:50:12: 　「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は、RFC 2827で規定されている、送信元IPアドレスの詐称を防ぐための技術だ。送信元IPアドレスを偽装した不正なパケットをはじき、オープンリゾルバへのDNS問い合わせパケットを受け付けないようにするとともに、「送信元（＝攻撃元）をちゃんと追跡できることもメリット」（インターネットイニシアティブ（IIJ）の松崎吉伸氏）という。

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

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

　もう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側からの問い合わせに答えてしまう設定となっている機器が存在しているという。