POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

FeedlyRSSTwitterFacebook
Rob Norris

本記事は、原著者の許諾のもとに翻訳・掲載しております。

このブログは、 FastMail 2015年アドベントカレンダー に掲載している8つ目の記事です。リンクをクリックすると全ての記事がご覧いただけます。

先月、 私たちはDDoS攻撃を受けました 。その週、私たちはこの手の攻撃スタイル、そしてその防御法に関して多くを学びました。この記事では、私たちが学んだことや、あなたのサービスがDDoSの攻撃にあった時に何ができるかを説明したいと思います。私たちはどうしても皆さんにこのことを伝えたいのです。急いでいる時にこのような情報をまとめて探しだすのは簡単ではありません。あなたが既に攻撃にあっている場合は特に難しくなります。ここに掲載されていることが少しでも皆さんのお役に立てるようであれば、うれしい限りです。

DDoSとは?

“DDoS”とは”Distributed Denial-of-Service(分散型サービス妨害)”の略なのですが、これを理解するには、まず DoS攻撃(サービス妨害攻撃) を知る必要があります。ではそこから説明していきましょう。

根本的に、全てのインターネットサービスはネットワークからリクエストを受け、それに関する処理を行い、結果を返信しています。これを行うには、サービスは各リクエストに対処するために、ネットワークの容量やCPUサイクル、メモリ、IOなどのリソースを確保しなくてはなりません。

Dos攻撃の目的は、リクエストへの応対を不可能または困難にすることです。一般的な攻撃手法は、外部から何らかの方法によって利用可能なリソースを疲弊させることで、正当なリクエストに対処するためのリソースが残らない状態にしてしまいます。

この状態にする手法は多く存在しますが、攻撃者が実行する最も簡単な手法の1つが、サービスがリクエストを受け取るネットワークの接続を制圧することです。これは”分散型”のやり方で簡単に行えてしまいます。マルウェアやウィルスによって感染された世界中のコンピュータは、ネットワークサービスに大量のリクエストを作るように誘導されると同時に、ネットワーク接続を詰まらせ、正当なリクエストを通すことを防いでしまいます。先月このことについては説明しましたが、要は「郵便局の正面玄関に大衆が押し寄せているので、私書箱にたどり着けない」と言ったような感じです。

分散型攻撃

DDoSの背景にある考え方は、サイトが対処できる受信量よりも多くのトラフィックを攻撃者に生成できるようにさせてしまうことです。サーバはインターネットへの大容量の接続先の最終地点ですから、単体のコンピュータにはサーバを制圧するための十分なネットワークリソースがないことがほとんどです。しかし、複数の異なるネットワーク上にある世界中のコンピュータが同時にリクエストを作った場合、全てのリクエストが合算されることで、サーバが対処できる範囲を超えることになります。

これを実現するには、” ボットネット “を使用します。ボットネットは、有害なソフトウェアがインストールされた多く(通常は何百や何千単位)の家庭や職場のコンピュータから構成されています。有害なソフトウェアはEメール(スパム/ウィルス)、ソフトウェアインストーラにあるアドオン(アドウェア/マルウェア)など、様々なソースから侵入し、一度インストールされるとコントロールサーバに”Phone Home(帰るコール)”という通信を行い、コマンドを待ちます。そして攻撃者は、攻撃されているサイトに多くのネットワークリクエストの送信を開始するよう、感染されたマシンにコマンドを発行します。

DDoS攻撃を仕掛ける他の方法に、”アンプ攻撃”があります。ある種のインターネッサービス(特にDNSやNTP)は、しばしば、正しく設定されていないことがあります。例えば、小容量のリクエストを経由して、大容量の応答をどこかに送信するようにサービスをごまかしてしまう方法です。もし複数のボットネットマシン全てが、このようなリクエストを作ったとしたら、ターゲットに膨大なトラフィックが押し寄せる結果となります。

ボットネットにアクセスするのは徐々に簡単になってきています。クレジットカードやビットコインで支払いをし、簡単なWebフォームでターゲットを選択することで、時間単位でボットネットを借りることができるWebサイトまであります。

攻撃はなぜ起こるのか?

これにはいくつかの理由が挙げられますが、大きく分けて以下の3つのカテゴリーに分類されるでしょう。

  • 脅迫 – 攻撃者がターゲットを(恐らくデモンストレーションとして)脅し、攻撃を中止する代わりに金銭を要求する場合。先月私たちが受けた攻撃は、この手のものでした。
  • 仕返し –あなたが言ったことに対する攻撃者の反撃、または単にあなたが嫌いという場合。
  • ミスディレクション – 攻撃者が他のイベント(攻撃)からあなたの気を散らすという目的の場合。

運が悪ければ、攻撃の理由を知ることはできませんが、DDoS攻撃に対する計画や対応が実質的に変わるわけではありません。

DDoS攻撃に備える

理想的なのは、DDoS攻撃を受ける前に対策を練っておくことです。攻撃を受けている最中に防御を試みたり構築したりすることは非常に大変です。私たちの場合、日曜日に支払いをするよう手紙で要求され、翌水曜日に大規模な攻撃を実行すると脅されました。数日の猶予があったので良かったのですが(恐らく攻撃者は確信していたのでしょう)、とても憂うつな数日間でしたし、誰もぐっすり眠ることはできなかったはずです。攻撃当日の水曜日になって、「私たちはできる限りの準備はした」と覚悟を決めたのを覚えています。その時、私たちの心配が溶けるように消えてなくなりました。なぜなら、私たちにこれ以上できることは何もなかったからです。事前に攻撃に備えておけば、物事がものすごく悪い方向に進むとしても、より良い睡眠を得ることができるでしょう。

脅迫に対する応対

脅迫には 決して 応じてはいけません。脅迫は、ほとんどの司法で犯罪と見なされています。支払いをすることで攻撃を回避できるかもしれませんが、同時に攻撃者に対してあなたがお金を払う意思があると思わせてしまい、更なる攻撃の対象となってしまうことにもなります。そしてそのお金がボットネットを借りる時間の資金になってしまうのです。

前回も言いましたが、未来の攻撃者のあなた、 FastMailはどんな脅迫にも応じませんし、どんな状況下であろうと犯罪者にお金を払ったりはしません。

最低限のサービスレベル

本格的なDDoS攻撃を防御するのは非常に難しい、といういことを理解することが大切です。防御に”成功した”としても、恐らくいくつかのサービスを失っていることでしょう。あなたのサービスやユーザの期待値、受け入られる最低限のサービスレベルが何なのかを知っておくことが必要です。そしてそれに従って対応を計画してください。

私たちの場合、DNSと社内データセンタのVPNのリンクが非常に重要だと考えています。DNSが重要な理由は、DNSが動作していれば、もし私たちがオフラインになってしまっても、送信サイトに対して「オンラインに戻るまでメール送信を待たせる」というように指示することができるからです。しかしDNSを失うとバウンスメールとして戻ってきてしまいます。一方で、VPNは私たちのデータセンタ間をリンクしていて、外部ネットワークを失っても社内インフラを適切に運用し続けてくれます。つまり、攻撃に集中する必要がある時でも、全ての社内インフラ(例えばXDCR)がダウンすることはありません。

ネットワークの防御

ネットワークに流れ込んでくる大量のトラフィックを防ぐ良い方法は、非常に簡単でネットワークから離れることです。DDoS攻撃は、世界中のネットワークからあなたのネットワークにトラフィックを集中させようとします。もし、そのトラフィックをどこかへ追いやることができれば、ネットワーク接続は正当なリクエストに対して自由に応答することができます。

WebとDNSのミティゲーション

一般的なWebアプリケーションの場合、最も簡単な方法は、グローバルの分散型Web/DNSプロキシ(CDNとも言う)をサービスのフロントに置くことです。これには エニーキャスト を用い、Webサイトのトラフィックが、まずリクエストを作っているマシンに経路的に最も近いプロキシを通るように強制します。また、様々なタイプのDDoSのプロテクションやフィルタリングを実行するので、正当なものだけが送られます。

もちろん、あなたの実際のサービスが攻撃されるのを止めることができるのは、攻撃者があなたに直接行き着く方法を知らない場合に限ります。もし、DNSで独自のネットワーク領域を公開したことがある場合は、フロントにプロキシサービスを置いたとしても、居場所が分かってしまいます。こういった場合は、一度も公開せず、あなたのプロキシプロバイダにだけ知らせるための、新しいパブリックIPアドレスを取得する必要があります。そうすることで、攻撃者があなたのネットワークを探し出すことがより困難になります。

FastMailの場合、たくさんの重要な非Webサービス(IMAP、SMTPなど)があるので、Webプロキシは十分ではありません。先程も言いましたが、DNSは私たちにとってとても重要なものなので、今ではパブリックDNSを扱うために CloudFlareのバーチャルDNS を使用しています。昔から使用している私たちのDNSネームサーバ ns1.messagingengine.com ns2.messagingengine.com は現在、世界中のCloudFlareサーバによって扱われています。これによって、実際に扱われるレコードに新しくてパブリッシュされていないIPアドレスで接続できます。私たちがサービスを中止すると、再度サービスを再開するまでキャッシュされた回答が提供し続けられます。

もしサービスにクラウドプロバイダを使用しているのであれば、まずはプロバイダに相談をし、彼らがどんなDDoSプロテクションサービスを提供しているか確認しましょう(彼らは何かしらのプロテクションを提供しています)。そしてもし攻撃されたら(または脅迫を受けたら)、彼らのセキュリティチームに知らせてください。情報や警告が多ければ多いほど、彼らはより良い仕事をこなすことができます。

データセンタプロバイダとの協力

私たちは、サービスをクラウドインフラストラクチャで稼働していません。その代わりに、様々な場所にインストールしたデータセンタで稼働させています。長年使用している主なデータセンタは、ニューヨークにある NYI です。NYIはインターネットへの接続を提供してくれるので、おのずと、ネットワークの防御については、まずは彼らと話し合うことになります。

私たちと同じようにしているのならば、あなたのデータセンタプロバイダは、” インターネットバックボーン “に直接リンクしています。インターネットバックボーンとは、”インターネット”を形成する、異なるインターネットサービスプロバイダやネットワークプロバイダや大きな組織を相互接続した集合体である、大容量のネットワークです。そこは、単に、処理されるトラフィックが膨大な量であるという理由から、DDoS攻撃を軽減するには最適な場所です。私たちのケースでは、私たちのネットワーク領域を世界に向けてアドバタイジングするために、NYIが彼らのネットワークパートナーを手配してくれました。これによって、不要なものをフィルタで除外し、正規のパケットを通過させ、私たちのネットワークに正当なパケットを渡してくれるDDoSミティゲーションサービスに指示を出してくれます。

私はこれが実際にどのように機能するのかについては、大まかなことしか分かりませんが(ネットワークのアドバタイジングには BGP を使い、 GREトンネル でフィルタされたトラフィックが私たちのネットワークを再度通過するようにする)、これが、ある意味で重要なのです。つまり、これは私たちのデータセンタプロバイダが提供するサービスの1つであり、彼らが管理してくれることにとても満足しています(豊富な知識を持ったメンバによる素晴らしいサービスを求めている方は、NYIに相談してみるといいでしょう)。

NYIはまた、非公開の狭い領域のIPアドレス取得についてサポートしてくれました。前述したように、私たちは、DNSのトラフィックをCloudFlareにプロキシするためにDNSサーバを追加しました。そしてこの領域を通して内部データセンタのVPNリンクをルートしました。理論的には、私たちのプライマリネットワークにアクセスが殺到した場合、このセカンダリネットワークが使用できるので、DNSや内部データセンタのトラフィックは障害を受けずに使い続けることができます。

データセンタプロバイダへの直接攻撃のように、防御不可能な攻撃は確かにあります。しかし、”コモディティ化された”ボットネットを利用して攻撃しようとする者にとっては、かなり難しいことです。ネットワークセキュリティには往々にして言えることですが、豊富なリソースと確固たる意志を持った攻撃者に対してはなすすべはほとんどありませんが、一般的な攻撃に対してならば、できることはたくさんあります。ここでお伝えしたいのは、そうした手段です。

トラフィックを知る

あなたのアプリケーションはおそらく1つか2つのタイプのトラフィックにしか関心がないでしょう。例えば、ポート443のTLSトラフィックです。ネットワーク装置やホストのファイアウォールは、こちらが気にも留めないものを、恐らく既に見落としてしまっています。問題は、このトラフィックは、既にあなたのネットワーク上に存在し、正当なトラフィックと回線容量を奪い合っているということです。

トラフィックが分かれば、アップストリームのネットワークプロバイダに相談して、不要なトラフィックをブロックしてもらうことができます。そうしたトラフィックがネットワークに打撃を与えることがなければ、対処する必要もありません。

私たちの場合、最初の”威嚇射撃”は、NTPリクエストとポート80へのランダムなUDPパケットで構成されていました。どちらも私たちの関心対象ではなく、ホストのファイアウォールで長い間ブロックされていました。攻撃の最中、入ってくるパケットの90%はこの種のものであり、正当なトラフィックはほんの10%でした。私たちは侵入をブロックし、残りに対しては通常のサービスを行っていましたが、10%のパケットしか通過できていないと、TCPの接続に問題が生じます。そこでNYIに依頼して、私たちのネットワークに接近する前にこのトラフィックをブロックしてもらいました。さらに様々なことが判明するに従い、他のものも同様にブロックしてもらいました。

こうすることで、未来の攻撃者は、正当に見えるようにトラフィックを生成しなくてはなりません。この生成はふつう難しくはありませんが、少なくとも、ある種の一般的な攻撃スタイルを排除できます。未来の攻撃者が少しでも攻撃しにくくなるようにしておけば、いざ攻撃を防ぐ際にはそうしたことが全て役に立ちます。

アプリケーションの防御

最初に言ったように、DoS攻撃は、正当なネットワークリクエストに対するサービスに必要なリソースを、攻撃により疲弊させることです。DDoSにおいてターゲットとなるリソースはネットワークですが、他のタイプの攻撃についても検討することが大切です。私たちのケースでは、攻撃者の能力も真の動機も分かりませんでした。そして、もし私たちのネットワークに対する攻撃の企てが失敗して、攻撃者がさらに異なる種類の攻撃に変えた場合、どうなっていたでしょう。そこで私たちはアプリケーションのレベルで アルゴリズムの複雑性を利用した攻撃 に対抗する防御を追加する方法を検討し始めました。

この種の攻撃の根幹は、「攻撃者は必ずサーバを攻撃する」ということです。ですから、防御のサポートについてアプリケーションが分かることを全て利用できます。私たちのケースでは、時間をかけて、ついに”良い”リクエストと”悪い”リクエストのプロファイリングを確立しました。攻撃を受けている時は、”悪い”リクエストがアプリケーションコードに到達する前に、ファイアウォールで排除されるようなコマンドを実行することができます。”良い”、”悪い”と引用符で囲んだ理由は、”悪い”リクエストは、必ずしもサービスしたくないリクエストとは限らないからです。ただ、一度に大量に送られてくるので(攻撃されている時ですが)、”良い”リクエストにサービスする能力に大きな影響を与えてしまうのです。”良い”と”悪い”の構成要素はアプリケーションによってかなり異なるので、ここでお伝えできるような一般的なアドバイスはあまりありません。

“良い”リクエストと”悪い”リクエストをどうやってプロファイリングするかについては、あえて詳しい話をしないでおこうと思います。というのも、攻撃の前に、自分たちのシステムをどのように”備える”かについて、未来の攻撃者にヒントを与えたくないからです。また、このプロファイリングは今後もずっと、変え続けていきます。

ユーザに伝える

技術的な防御は非常に有効ですが、完全に食い止める方法はありません。つまり、あなたのユーザは攻撃に気が付くということです。ですから、実際に攻撃が行われる前に、ユーザに対して現在の状況を伝えましょう。

私たちのケースでは、初期の”威嚇射撃”が進行している段階で ステータスページTwitterのアカウント を通してユーザに伝えました。私たちは”DDoS”についてはっきりと言及しました。なぜなら、私たちのユーザの多くは、DDoSとは何か、どのように適切に対処すべきかといった技術的な知識が豊富だったからです。私たちは注意深く、防御の準備が整うまで詳細については明かさないようにしました。というのも、準備が整うまで、攻撃者に意図を悟られたくなかったからです。最悪の場合、こちらの準備が整う前に、攻撃者は私たちが支払を行うつもりがないことを知り、こちらの決意を試しながら攻撃を早めに仕掛けてきたでしょう(もしそうだったとしても、私たちの態度は変わらなかったでしょうが)。私たちは、準備が整った段階で このブログに記事を掲載しました

ユーザに対して可能な限りの警告を行うことで、彼ら自身も準備をする時間が持てました。ユーザの反応は肯定的なものが圧倒的多数でした。私たちは、幸運を祈る、という何百ものメッセージを受け取りました。また、私たちが進んで姿勢を明確にしたおかげで、たくさんの方が新規登録してくれました。中には、実際には私たちのサービスを利用するつもりはないが、何か具体的なサポートをしたいと、定期購読を申し出てくれた素晴らしい方もいました。

ありふれた言い方かもしれませんが、顧客は最大の財産です。顧客に尽くし、その知性に敬意を持ちましょう。そうすれば、彼らは困難な時にきっと助けてくれるでしょう。

事後分析

おめでとうございます、難局を乗り越えましたね。

確かに、片付けや修理などがいくらかあります。インターネットと長い期間切断されていた事態にうまく対処できるインターネットサービスなんて、そうはありません。ただ、この段階で考えなければならないことは他にもいくつかあります。

追随者の警戒

今や、世界中がこの事件を知っています。あなたの提供しているサービスの範囲によっては、世界のほんの小さな一部分かもしれませんが、ユーザに全てを伝えているので、その話は広まります。ですから、この機に乗じる攻撃者を警戒しましょう。最初の攻撃者はあきらめたかもしれませんが、模倣犯はよく現れるものです。何より彼らは、こちらが警戒を緩めたのでは、と考えているかもしれません。

攻撃者に関するデータの収集

できる限り、今回の攻撃に関する情報を集めます。送信元IPアドレスは最も重要な情報ですし、攻撃の量も大切な情報です。この情報をアプリケーションで保持している他のデータと照合できれば、とても役に立ちます。ある種のミティゲーションサービスを利用しているのでしたら、彼らにその情報について尋ねてみましょう。ブラックリストの作成に活用して、次回の攻撃への準備に追加できます。でも、次のことも大切ですよ。それは…

コンピュータセキュリティ機関への通報

多くの管轄区域には、コンピュータやインターネット上の脅迫を専門に扱う何らかの機関があり、この種の攻撃に多大な関心を持っています。オーストラリアには CERT Australia があり、アメリカ合衆国には、 US-CERT があります。こうした機関は、送信元IPアドレスと攻撃に関するその他の情報を活用し、他の事件から得た類似する情報と関連付けることができます。これは、攻撃を行っているグループを突き止める上で役に立ちます。

セキュリティ対策の見直し

常日頃から行っているでしょうが、今が見直しのチャンスです。もし、ある範囲においては適切な防御がなされていると知られていれば、意志を固めた攻撃者は、何か違った方法をとるでしょうし、それに備えなければなりません。攻撃から学んだことを活用して、他の範囲のセキュリティを強化できるかもしれません。

まとめ

DDoSは非常に恐ろしいものです。二度と経験したくありませんし、皆さんにも経験してほしくはありません。しかし今や私たちは、再び攻撃を受けた時には、少なくとも何が起こるのか、どのように対処すればいいのかについて、少し詳しくなったと言えます。

監修者
監修者_古川陽介
古川陽介
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
複合機メーカー、ゲーム会社を経て、2016年に株式会社リクルートテクノロジーズ(現リクルート)入社。 現在はAPソリューショングループのマネジャーとしてアプリ基盤の改善や運用、各種開発支援ツールの開発、またテックリードとしてエンジニアチームの支援や育成までを担う。 2019年より株式会社ニジボックスを兼務し、室長としてエンジニア育成基盤の設計、技術指南も遂行。 Node.js 日本ユーザーグループの代表を務め、Node学園祭などを主宰。