この記事では、2016 年 9 月と 10 月に発生した前例のない #DDoS 攻撃の影響について簡単に説明し、回復力の向上に関心のある方向けのガイダンスを提供します。
モノのインターネットの到来を祝いましょう! 9月から3回サイバー兵器として使用されたため、ついにそれが到来したことがわかります。 それは、ブロガーでジャーナリストのブライアン・クレブス氏に対する大規模な攻撃から始まった。クレブス氏のウェブサイトkrebsonsecurity.comは、CDN Akamai によってホストされ、保護されていた。 この攻撃は Akamai の他の顧客に影響を及ぼすほど深刻だったため、同社はブロガーに対する無償の弁護を断念した。
業界の研究者(F5 を含む)は、DVR やビデオカメラ、その他の「モノ」で構成された新しいボットネットについて警告を受けました。 しかし、DVR とビデオ カメラは、高い CPU 能力 (したがって、高度なマルウェアをホストできる) と高帯域幅のアップリンク (それぞれ最大 100 Mbs の攻撃を開始) の両方を備えているため、重要です。 Krebs に向けた攻撃トラフィックの合計は 620 Gbs で、当時としては世界最大の DDoS 攻撃でした。
2 回目の攻撃では、フランス最大のホスティング プロバイダー (文献によれば世界第 3 位) である OVH がほぼ 1 日中機能停止状態になりました。 多くのメディア報道では、OVH 攻撃の規模は Krebs 攻撃のほぼ2 倍、つまり 1 秒あたり 1 テラビットであると報告されています。
3番目でおそらく最悪の攻撃は、DNSサービス会社であるDynに対するものでした。 Dyn は、Twitter、Spotify、GitHub (皮肉なことに IoT ボットネット コードが投稿された場所) など、多くの有名な Web サイトの DNS プロバイダーです。
奇妙な偶然だが、業界の重鎮であるブルース・シュナイアー氏は先月、大規模な国家によるDDoS攻撃が迫っていると警告しながらインタビューを回っていた。 彼の内部情報は、インターネットの中核インフラに対する調整型DDoS攻撃を発見していた匿名の業界筋から得たものだった。
しかし、結局のところ、それらの探りを入れる攻撃は単なる偶然だったのかもしれない。 シュナイアー氏自身も自身のブログで、Dyn 攻撃は国家によるものとは全く考えていないと認めている。 しかし、おそらくその国家はただ見守って待っているだけなのでしょう。
クレブス、OVH、およびダイン事件における犯人特定への鍵は、おそらくブライアン・クレブス自身から得られるものと思われる。
「DYNへの攻撃は、DYNの研究者ダグ・マドリー氏が、テキサス州ダラスで北米ネットワーク事業者グループ(NANOG)の会議でDDoS攻撃について講演したわずか数時間後に発生しました。… KrebsOnSecurity.comに対する記録的な620GbpsのDDoS攻撃は、私がマドリー氏と共同で執筆した記事を公開したわずか数時間後に発生しました。」
おそらく、敵対者はブライアン・クレブスかダグ・マドリー、あるいはその両方に対して意図を持った個人(または小グループ)です。
本格的な米中サイバー戦争によって何百万人ものユーザーが影響を受けることは誰もが理解できるだろう。 しかし、それが一人の個人による別の一人の個人に対する個人的な意図であることが判明したらどうでしょうか? それは国家による攻撃よりもさらに恐ろしいことだ。 他人に対して恨みを持つ一人の人間が、何百万人もの人々にとって重要なサービスを中断させられるなんて、いったいどんなインターネットを構築しているのでしょうか。
F5 は、1 年以上にわたってモノのインターネット (IoT) デバイスの探索を監視してきました。 この問題に関する最初のレポートは 2016 年 7 月に公開され、Telnet および SSH ブルート フォース スキャンが前年比 140% 増加したことが示されました。 Telnet と SSH は広く使用されているリモート管理ポートであり、ベンダーのデフォルト (または推測しやすい) のユーザー名とパスワードで、知らないうちにインターネットに公開されていることがよくあります。
2016 年 10 月に Krebs、OVH、Dyn に対して行われた前例のない DDoS 攻撃では、まさにこの手法 (IoT デバイスの Telnet ポートとベンダーのデフォルト パスワードをスキャンする) を使用して、独自の機能を備えたボットネットが作成されました。
再び誰もが標的にされる。 ボットハンターたちは、これまでは手の届かない標的だと思われていた世界最大級のプロバイダーに対して、サイバー兵器を向けることをためらいません。
これらの攻撃は一夜にして起こったように思えるかもしれませんが、実際には、ボット ハーダーは少なくとも 1 年間かけて、脆弱な IoT デバイスをゆっくりと探し、発見し、侵害してきました。
実のところ、私たちは IoT ボットネット Mirai の機能についてかなりよく理解しています。 F5 の研究者たちは、Mirai ボットの作者が hackforums.net でソース コードを公開した直後に、Mirai ボットの技術的な分析記事を執筆しました。
総合的な攻撃力は、おそらく以前のボットネットよりも桁違いに大きく、1秒あたりテラビットを超えるものとなるでしょう。
IoT ボットネットには、次のような高度な DDoS 手法が含まれます (ただし、これらに限定されません)。 以下の規範的なガイダンスのセクションでは、可能な場合にこれらを軽減する方法に関する推奨事項を示します。
HTTP GET フラッドはすでに有害でした。 長年にわたり、攻撃者は大きなオブジェクトや低速のデータベース クエリに対する大量の HTTP リクエストを送信することで、Web サイトを無効にすることができました。 通常、これらのリクエストは、ハードウェア パケット処理を備えたほとんどのデバイスにとって通常の HTTP リクエストと同じように見えるため、標準のファイアウォールをそのまま通過します。 Mirai 攻撃コードは、クラウドベースの DDoS スクラバーのフィンガープリントを作成し、スクラバーが送り返す 302 リダイレクトを回避することで、さらに一歩進んでいます。 リダイレクトは、以前は単純なボットを阻止する良い方法でしたが、これは単純ではありません。
Mirai ボットには、標的の DNS プロバイダーに対する「水責め」攻撃が含まれています。 この手法は、ボットが送信するクエリの数が大幅に少なくて済むため、ISP の再帰 DNS サーバーがターゲットの権威 DNS サーバーに対して攻撃を実行できるため、通常の DNS リフレクションおよびアンプ攻撃とは異なります。 この攻撃では、ボットは解決する対象のドメイン名を含む整形式の DNS クエリを送信し、その名前にランダムに生成されたプレフィックスを追加します。 攻撃は、ターゲットの DNS サーバーが過負荷になり、応答しなくなったときに有効になります。 その後、ISP の DNS サーバーは自動的にクエリを再送信し、ターゲット組織の別の権威 DNS サーバーを試して、ボットに代わってそれらのサーバーを攻撃します。
Dynは、ブログ投稿「10月21日金曜日の攻撃に関するDyn分析概要」の中で、水責め拷問が実際に彼らに対して行われたことを確認した。
「たとえば、攻撃の影響により、再帰サーバーがキャッシュを更新しようとしたため、正当な再試行アクティビティが大量に発生し、多数の IP アドレスにわたって通常の 10 ~ 20 倍のトラフィック量が発生しました。 DNS トラフィックの輻輳が発生すると、正当な再試行によってトラフィック量がさらに増加する可能性があります。
悪意のある攻撃は少なくとも 1 つのボットネットから発信されたものと思われますが、再試行ストームにより、現在わかっているよりもはるかに多くのエンドポイントが存在するという誤った兆候が示されました。 私たちはまだデータの分析に取り組んでいますが、このレポートの時点では、悪意のあるエンドポイントは最大 100,000 個あると推定されています。 」
F5の研究者リロン・シーガル氏は数週間前の投稿で、Krebs氏を倒したボット、Miraiのウォーター・トーチャー攻撃の仕組みを詳しく説明していました。
ボットの作成者によると、いわゆる「TCP STOMP」攻撃は、緩和デバイスを回避することを目的とした単純な ACK フラッド攻撃のバリエーションです。 この攻撃の実際の実装を分析すると、ボットは完全な TCP 接続を開き、接続を維持するために正当なシーケンス番号を持つ ACK パケットを大量に送信し続けるようです。
新しい IoT ボットの個々の脅威ベクトルを理解した上で、それらの個々の脅威ベクトルを軽減するためのガイダンスを提供することができます。
ガイダンスを始める前に明確にしておきましょう。 Krebs、OVH、および Dyn 攻撃はそれぞれ別格です。 明らかに、既存の DDoS 緩和技術では攻撃者を簡単に撃退することはできず、そのためサービス停止が発生し、メディアで大きく報道されました。 しかし、最終的には多くのケースで緩和策が効果を発揮しました。 また、Anycast や分散データセンターの使用などの適切なアーキテクチャも役立ちました。 なお、米国西海岸および西部地域は Dyn 攻撃による影響をほとんど受けなかったことに注意してください。
私たちの指導は私たち自身の顧客から来ています。 F5 は 20 年間にわたり世界の有名ブランドにapplicationsを提供してきましたが、その顧客の多くは毎日 DDoS 攻撃を受けています。 最も経験豊富なお客様は、防御を 3 つまたは 4 つのゾーンに分割しています。
したがって、最高の DDoS 耐性アーキテクチャは次のようになります。
これは、F5 の顧客によって長年にわたって広く使用されてきた DDoS 保護リファレンス アーキテクチャです。 完全なリファレンス アーキテクチャと推奨プラクティスについては、F5.com をご覧ください。 ただし、より迅速に理解できるように、これらの攻撃に関連するガイダンスを以下に詳しく説明します。
フランスのホスティング会社OVHは990Gbsのボリューム型攻撃を受けた。 Dyn 攻撃は 1.2 テラビットでピークに達したという報告がありました。 通常、その規模の攻撃を軽減できるのは、大規模な防御に特化したクラウド スクラバーだけです。 F5 の Silverline DDoS Protection などのクラウド スクラバーは、攻撃トラフィックを傍受してクリーンアップし、事前に準備されたトンネルを介して正常なトラフィックのみをターゲットに送信します。
ガイダンス: 組織は、攻撃を受ける前に、1 つ以上のクラウド スクラバーと契約を結んでいることを確認する必要があります。 事前に準備されたトンネルを構成することは、ボリューム型攻撃の最中に簡単に実行できるものではありません。 DDoS 戦略の一環として、クラウド スクラビング DDoS 防御と契約します。
ガイダンス: 攻撃拡散はボリューム攻撃に役立ちます。 DNS もあなたの味方になることを忘れないでください。DDoS 攻撃が発生したときに拡散させるために、複製されたコンテンツをグローバル データ センターにエニーキャストします。 Anycast に参加する各データセンターは、攻撃を分散するのに役立ちます。
関連資料:
Mirai ボットには、標準の SYN フラッド、TCP フラッド、UDP フラッドなど、いくつかのレイヤー 4 攻撃が含まれています。 これらの古い脅威ベクトルは、クラウド スクラバーで軽減するか、十分に小さい場合はデータ センターのネットワーク防御層で軽減する必要があります。 ネットワーク防御層は、ネットワーク ファイアウォールを中心に構築されます。 SYN フラッドや ICMP フラグメンテーション フラッドなどの計算攻撃を軽減するように設計されています。 この層は、入口ポイントの混雑(通常は定格パイプ サイズの 80 ~ 90 パーセント)までのボリューム攻撃も軽減します。
ガイダンス: 多くのファイアウォールは、適切に構成されていない限り、DDoS 攻撃に耐えられません。 設定については、ネットワーク ファイアウォールのベンダーに確認してください。 一部の顧客は、レイヤー 4 攻撃を撃退するためにファイアウォールの前に DDoS 対策デバイスを配置します。
ガイダンス: F5 ファイアウォール モジュール (BIG-IP Advanced Firewall Manager (AFM)) は、レイヤー 4 攻撃を撃退するために特別に設計されました。 一部のアーキテクトは、まさにこのようなケースで、従来のネットワーク ファイアウォールの前面または代わりに BIG-IP AFM を使用します。 AFM を搭載したハードウェア アプライアンスは、フィールド プログラマブル ゲート アレイを使用して 30 種類を超えるパケット フラッドを撃退し、CPU の負荷を軽減します。
関連資料:
Mirai ボットは、強力な HTTP GET フラッドを生成し、ダイレクトを処理できます。 GET フラッドはネットワーク防御デバイスにとって通常のトラフィックのように見えるため、application層で処理する必要があります。 GET フラッドは、F5 がこれまでに確認したapplication層攻撃の中で最も一般的なタイプであり、顧客が使用している製品ポートフォリオに応じて、これを軽減する方法は多数あります。
ガイダンス: 単純なリダイレクトを処理できるボットの場合、F5 では、1 秒あたりのリクエスト数に基づいて接続を調整するか、「ログイン ウォール」と呼ばれるものを使用することを推奨しています。 ログイン ウォールでは、データベース クエリなどのキャッシュされていないリソースや動的リソースを使用する前に、applicationへの接続が認証される必要があります。
関連資料:
Dyn 攻撃に関して、議論する価値のある DNS の問題が 2 つあります。 最初で最も簡単なのは、新しいタイプの攻撃の 1 つによって DNS プロバイダーがオフラインになった場合にどうするかということです。 Dyn は Twitter、GitHub、Spotify の名前サービスプロバイダーであったため、Dyn がブロックされると、エンドユーザーはこれらのサービスの IP アドレスを見つけることができませんでした。
ガイダンス: 重要なapplicationsのアドレスを提供する複数の DNS プロバイダーを含む (ただしこれに限定されません) DNS プランに回復力を組み込みます。 この方法では、プロバイダーの 1 つが一時的に攻撃を受けた場合でも、他のプロバイダーがアドレスを提供できます。 エンドユーザーの速度が数ミリ秒遅くなる可能性がありますが、applicationsとサービスは引き続き利用できます。
2 番目の問題は、独自の DNS サーバーが攻撃を受けた場合にどうするかということです。 DNS は最もターゲットとなるサービスであり、HTTP が 2 番目です。 DNS が中断されると、すべての外部データセンター サービス (単一のapplicationだけでなく) が影響を受けます。 この単一の完全障害点と、多くの場合十分にプロビジョニングされていない DNS インフラストラクチャにより、DNS は攻撃者にとって魅力的なターゲットになります。
自分のサーバーが攻撃を受けていない場合でも、下流の DNS サーバーが停止すると、別の DNS サーバー セットが自身のキャッシュを埋めようとして、自分の DNS サーバーに大量のリクエストを送信する可能性があることに留意してください。 Dyn 社では、この問題が発生した際に通常の 10 ~ 20 倍のリクエストが報告されており、これは状況に対処しようとしている正規の DNS サーバーからのリクエストでした。
ガイダンス: DNS サービスのかなりの割合が、小規模から中規模の DDoS 攻撃にも耐えられないほどプロビジョニング不足になっています。 DNS キャッシュは、DNS サービスの認識されるパフォーマンスを向上させ、標準的な DNS クエリ攻撃に対する耐性を提供できるため、人気が高まっています。 攻撃者は、キャッシュによって得られるパフォーマンス上の利点をすぐに奪ってしまう「no such domain」(または NXDOMAIN)攻撃と呼ばれる攻撃に切り替えました。
F5 のお客様の場合、F5 は、F5 DNS Express™ と呼ばれる DNS プロキシ モジュールを使用して DNS サービスをフロントエンド化することを推奨します。 DNS Express は、既存の DNS サーバーの前で絶対リゾルバとして機能します。 サーバーからゾーン情報を読み込み、すべてのリクエストを解決するか、NXDOMAIN を返します。 これはキャッシュではないため、NXDOMAIN クエリ フラッドによって空にすることはできません。
ガイダンス: DDoS 攻撃中は DNS が頼りになることを忘れないでください。DDoS 攻撃が発生したら、複製されたコンテンツをグローバル データ センターにエニーキャストして拡散させましょう。
ガイダンス: DNS サービスの配置を検討します。 多くの場合、DNS サービスは、最初のセキュリティ境界とは別に、独自のデバイス セットとして存在します。 これは、DNS を、それが提供するapplicationsから独立させるために行われます。
複数のデータ センターを持つ一部の大企業では、BIG-IP DNS と DNS Express および BIG-IP AFM ファイアウォール モジュールを組み合わせて、メインのセキュリティ境界外で DNS を提供しています。 このアプローチの主な利点は、DDoS によりネットワーク防御層がオフラインになった場合でも DNS サービスが利用可能であり続けることです。
関連資料:
Krebs、OVH、Dyn 攻撃は、DDoS の新たな段階を示しています。 同時に、これらはモノのインターネットの成熟を象徴するものでもあります。
ご覧のとおり、F5 は DDoS に関する調査、対策、執筆において豊富な経験を有しており、お客様と協力してapplicationsの可用性を維持したいと考えています。 これには、F5 からパートナー、顧客に至るまで、すべての関係者の警戒が必要になります。
顧客であってもそうでなくても、攻撃を受けた場合は、 F5 Silverline DDoS Protection は電話一本で利用できることを覚えておいてください。 866-329-4253。
IoT の脅威に関しては、ブラックハットは常に互いに情報を共有しています (彼らは Mirai が Krebs と OVH を攻撃した後、それを共有し、Dyn 攻撃に使用しました)。 私たち情報セキュリティコミュニティは、彼らの戦略に倣い、団結してこの世界的な IoT の問題を解決する必要があります。 私たちにはそうする以外に選択肢はありません。 問題を理解し、解決し、進化していくのは人間の本質です。
今後数年間は、攻撃の規模が拡大し、スクラビング サービスの帯域幅が拡大してこれらの大規模な攻撃に対応できるようになり、IoT デバイスの製造元がデバイスのセキュリティ上の脆弱性に対処する方法を模索する中で、間違いなく問題が発生するでしょう。 組織と消費者は、これまでのすべての主要な問題と同様に、この進化する脅威に慣れる必要があります。