サービス・ソリューション
お客さまサポート
前へ
次へ
閉じる開く

NTTPCコミュニケーションズ ホーム ＞ 会社情報 ＞ 研究開発 ＞ 技術者が紹介するNTTPCコミュニケーションズのテクノロジー ＞ DDoS(DNS AMP)攻撃に加担可能な「オープンレゾルバホスト」の問題点

会社情報

DDoS(DNS AMP)攻撃に加担可能な「オープンレゾルバホスト」の問題点

上級テクニカルアドバイザー（サーバーエンジニアリング）

中冨勝利

紹介記事

私はデータセンタ事業部サーバープラットフォーム担当に所属し、WebARENAのホスティングサービスの新サービス考案や検証に携わっています。
近年、サイバー攻撃による被害が深刻な問題になっており、時折ニュースでも取り沙汰される事も見受けられる様になってきてました。
ホスティング事業者として「攻撃を受ける側」は念頭に置きつつサービス開発を行なっておりますが、逆に「もし、お客さまのサーバーが攻撃者に利用され「加害者の一端を担っているケースは無いだろうか？」と足元を見直すケースが3月末にニュースにもなり、事業者として取り組みを始める時期であろうと考え「オープンレゾルバ(有害レゾルバ)ホスト」に関する情報を紹介します。

Openresolver(有害レゾルバ)とは？

  • 「何処の誰からの質問にも答えてしまう」DNSサーバー
  • 「管理者の意図としていない問い合わせ内容であっても」回答してしまうDNSサーバー

つまり「出前詐欺的」な行為を許し助長させているDNSサーバーであり「攻撃中継点」として利用されているケースが非常に多く存在し各ISP事業者、ネットワーク管理者共に注視している内容となっております。

DDoS(Distributed Denial of Service attack) と Dos(Denial of Service attack)

「DoSとは、あるインターネットサービス（例:DNSサービス）の正常なサービスが提供できないようにすることです。

また、それを複数の分散された攻撃箇所から行うことを「DDoS」と言います。

この違いを電話の場合を用いて大まかなたとえ話的に記述すると以下のような違いが有ります。

DoS=「複数の攻撃者が攻撃先の電話へ無限リダイアル」

【DoSの例】

DDoS=「攻撃者が直接の被害者を騙り、幾つものお店に大量の「偽の」出前注文を行い被害者に送りつける」

【DDoSの例】

これだけだと差異が分かりにくいかと思いますが

と言う点が大きな違いであると考えてくだされば、多少分かりやすくなるかと思います。

１つ１つの内容（パケット）だけでは「正常な要求なのか意図的な攻撃であるのか」の区別が行いにくく且つ防御対応が難しい攻撃方法でもあります。

特に「HTTP攻撃」などは、ご自身が書かれているブログや運用されているWebサイトが各メディアに放映、掲載された事による正常な要求がサーバー設定をオーバーフローしている可能性や、意図の有無を問わず同一の要求元アドレスからの異常なリクエスト数により通常の要求が返せなくなるほどのリクエストを要求してくるホストの存在があります。
どちらの場合もサーバー設定やリソース管理、アクセスリストの見直しを行うことにより、ある程度は改善可能な範囲ではありますが、このような「攻撃を行える設定」となっている「中間攻撃可能サーバー」の1つとして「Open Resolver Host」と呼ばれるホストが多数存在している状況であり、世界的に問題となっています。

ページの先頭へ

OpenResolverによる被害の歴史

ことの始まりは今から7年ほど前に遡り2006年頃からこの手法を用いた攻撃が観測されております。
この頃に発生した国内での被害発生例としては、

と言う実例が発生しております。
また、最近では 2013年3月下旬に「SPAMHAUS」と言う「SPAM発信ホスト情報提供」をサービス運用しているサイトに対して「DNS amplification」を用いたDDoS攻撃が行われ国内のニュースでも話題になりました。

ページの先頭へ

OpenResolverとなった理由/経緯

「BIND」と言う古くから使用されている DNSサービスプログラムのデフォルト(標準)設定に「送信元のアドレスを確認し対象外のアドレスには応答しない」と言う適切な設定が入っておらず「何処の誰からでも使用出来る状態」であった事が大きな原因になってしまった事が背景にあると考えています。
その他として「古いルーターファームウェア」や「些細な設定ミス」また、「サポートが完了したOS」による「意図しない問題点」を有しているホストやCPE(ルーター) が数多く実在する事も被害を増大化している原因となっています。

※OSサポート完了と同時に脆弱性対応パッケージ配信や新バージョンパッケージ配信が終了されるケースが多い為

上記以外にも

など間違えた運用ポリシーを施してそのまま放置されているDNSサーバーも稀に見受けられます。

ここで重要なポイントとして「プログラムのバグ(問題点)では無く「設定者の指示」されたように動作している」と言う点であり「BIND」と言うプログラム自体の問題では無く、設定を間違える事により他のDNSサービスプログラムでも発生しうる問題です。

ページの先頭へ

OpenResolverの現状と対策

何故 DNS OpenResolverがDDoS攻撃に利用されるか？

TCPパケットの場合は「ハンドシェイク」を行う事により相手への到達性や内容の精査及びデータの整合性が行える反面常に相手の状況を見てデータを送受信する為、戻りパケットが送られてくる TCP は攻撃者として使いにくい部分があります。
逆にUDPパケットの場合、データの整合性や相手への到達性を確認しません。
つまり、「実際の問い合わせ元であるか」と言う確認(ハンドシェイク)を行わない為、実攻撃者にパケットが戻らず攻撃先に直接配送する事が可能で攻撃者として優位に攻撃が可能な部分があります。

「DNS amplification」による増幅効果が非常に高い

ここで問題になる点として「小さな問い合わせパケットを用いて100倍超えのデータで回答させる事が可能」で有る事が攻撃者の目的と利点となります。
この問題点を「DNS amplification」と呼び、多くのDDoS攻撃の原因の1つとなっています。

また、OpenResolverホストの大半は Open Recurcive（所在を問わず再起問い合わせが可能）であると共に「DNSレコードキャッシュ」も有効です。
攻撃者は攻撃用のDNSサーバーと TXTレコードを用いて中間攻撃者のサーバーに名前解決の要求を行います。
たった、これだけの処理で攻撃者は「大きな回答(TXTレコード情報)と保持時間(TTL)の異常に長い TXTレコード」を中間攻撃者の DNSサーバーにキャッシュデータとして仕込む事が可能となります。
キャッシュデータが存在していた場合、ルートサーバーやコンテンツDNSサーバー(権威サーバー)に問い合わせを行わず、手持ちのキャッシュデータを要求元に回答します。
更に「無駄に長い保持時間のレコード」を仕込む事により攻撃者は有利に攻撃を行う事が可能となります。

これにより「元々は40Byte程度の問い合わせデータを送ることにより攻撃先に4000Byte超えのデータを送りつける事が可能」となります。 「たかだか4000Byte程度でしょ？」と言う考えもありますが、ここで重要な点として「BIND の標準最大要求可能」と「複数のホスト」を組み合わせてみます。

BIND の「同時に受け取る再帰的問合せ数」の標準値は「1000Reqest」となっています。
これは「1000リクエストまでの同時要求を受け付けます」と言う意味であり、上記の 40Byte を 1000回受け付けた場合の攻撃トラフィックは4000Byte * 1000 = 4,000,000Byte = 4MByte となります。
さらに、このようなホストが10台存在していた場合は「40MByte/Sec=320Mbps」の回線帯域とサーバーリソースやインフラリソースを消費し、目的の攻撃先へ攻撃パケットを送り込むことが可能になります。

一見すると「100倍ものデータを出してしまうのはBINDにも問題が有るのでは？」とも見えますが、レコードの長さなどは正常な値であり且つ、正規の設定を施す事により未然に防げる内容です。
その他には「DNSレコードのキャッシュを停止すれば良いのでは？」と思われる方もいらっしゃると思いますが「Open Recurcive」の設定である時点で外部の誰もが中間攻撃元として使用出来る状態となっていますので、実攻撃者から見れば「攻撃効率が良いか、多少悪いか」の違いに過ぎず攻撃元の1つである事には変わりはありません。

攻撃先を任意に選択する事が可能

OpenResolverを利用した攻撃は送信パケットの偽装を行う事で「任意の攻撃先を自由に選択可能」と言う点もカジュアルな攻撃方法として利用されやすい点かと思われます。
1人の攻撃者が複数の中間攻撃サーバーを利用して各国の政府機関サイトや各国金融系サイトを日々攻撃することも意外と容易に可能です。
3月に発生した SPAMHAUS への攻撃も「SPAMMER HOST（迷惑/有害メールの配送元サーバー情報）」のリスト配信を停止させる為に複数の攻撃者による威圧的攻撃の一種であると考えられています。
また、その後もbitcoinの RMT(Real Money Trade)サイトへの攻撃やオンラインゲームサイトへの攻撃などを行なっている事も確認されています。

ここで注意しなければならない点として「攻撃先は中間攻撃者より手前に実攻撃者がいる事を知る術がなく、あくまで直接の攻撃元は不正中継を行ったサーバーであり、不正な設定で運用されている企業や個人のサービス如何を問わず、いつでも世界各国から訴訟対象となり得る」と言う点です。

訴訟問題に発展する可能性も視野に入れましょう

DDoS攻撃の攻撃先は被害を軽減させる為の対策として

の導入など攻撃に対処するだけでも膨大な人員リソースと費用が掛かることになります。
この費用プラス、攻撃時の機会損失、対応費用を含めた莫大な費用を訴訟により請求された場合の事を考えると、適正な保守運用を行う事がいかに大切であるかがご理解くだされるかと思われます。

ご自身のサイトや回線に対する影響

「DNSが不正利用される事による自サイト、利用回線への攻撃」も見逃せない点です。
これは、運用されている DNSサーバーが外部から不正利用可能であるが為、攻撃者から不要なDNSレコード情報を取得してしまい運用中のサービス全体のリソースが枯渇する可能性があります。

これらの不要なリソース利用によるサービス停止や動作不安定な状況が発生する可能性があります。
特に回線（ルーター）の問題が起因している場合は、「なんか調子が悪いから一旦ルーターを再起動してみよう」と一度再起動したら直ってしまったと言う方も多いかと思います。
使用している回線が「フレッツ系回線」でIPアドレスが動的割り当てであった場合はルーターの再起動で利用しているIPアドレスが変わった為に不正パケットが来なくなった可能性もありえます。
頻繁に障害が発生する場合は、一度ルーターのファームウェアの更新情報を確認される事をお勧めいたします。

ページの先頭へ

DNSサービスの適正な設定と管理運用

ネットワーク設定的対策(Spoofed IPを外部に送信せずルーターなどで破棄する)

・BCP-38の徹底
パケットの「ソースアドレス」が自ネットワーク以外のアドレスを「詐称アドレス」とみなして「外部」へ送信出来ないようにフィルタリングする。
・uRPF(unicast reverse path forwarding)の適用
上記 BCP-38 を1つ1つフィルターで制御する事は大きなネットワークに適用する事は運用管理上難しい為、ルーターのルーティングテーブルに存在しないアドレスをソースアドレスとして用いたパケットを「詐称アドレス」とみなしてルーター自身が自動的に破棄する。

上記2つのネットワーク的対処を行う事により不正な管理外ソースアドレス（ソースアドレス詐称）パケットを外部に送信する前に破棄する。

DNSサーバー的対策

上記2つの各項目的対策を適切に設定、管理、運用する事により、過半数以上のホストが適正な運用状態に移行出来ると考えられます。
こちらにつきましては、設定方法や確認方法を合わせて次回掲載予定です。

その他、「DNS運用を行っていたが諸事情により運用が難しくなった」、「設定変更の依頼が到着したが、どのように実施すればよいのかよくわからない」などのご相談がありましたら、弊社カスタマー窓口までご相談くださることによりお客さまにマッチした適切なサービスをご案内いたしますので遠慮無くご相談ください。

ページの先頭へ

今後の展開と方針

弊社NTTPCコミュニケーションズとしましては、不正中間攻撃ホストの特定と是正の為OpenResolverProject様からの申告内容を元に、中間攻撃可能ホストを特定し、既に弊社サービスをご利用中の一部のお客さま向けに周知と設定変更のお願いを実施しています。
今後も不正中継攻撃可能ホストの撲滅を目指し、ユーザー向け周知啓蒙活動と不正利用可能な機器の特定と対象機器ベンダーへの対策依頼を各方面から取り組む予定です。

出典

会社情報

別ウィンドウで開きます ・・・リンク先の外部サイトを別ウィンドウで開きます。

ページの先頭へ