ヒント：この記事は2万文字を超えていますので、最後まで我慢してください。
今日から新連載の技術記事が始まります。新連載の技術記事のテーマはDDoS攻撃研究関連ものということだ。DDoS攻撃研究関連ものはこの数年間私の一つ得意な分野です。私のインフラはすべてセキュリティを最優先考えな要件に設計されています。その「DDoS攻撃」は、もはや今インタネットとインフラで第一目そして最大のセキュリティ問題だ。
この一連の技術記事を始める前に、DDoS攻撃は何だろを知る必要があります。
**彼を知り己を知れば百戦殆うからず。**DDoS攻撃から防御するには、まずさまざまなタイプのDDoS攻撃の原理を知る必要があります。だから今回は、DDoS攻撃に対する効果的な防御方法を見つける方法として、一般的なDDoS攻撃の実装について解説します。
じゃ、今日の記事は「DDoS攻撃は何」という説明に始まります。
1. まず、知っておくの基本知識
まず、DDoS攻撃を理解する前に、ある程度の知識が必要です。以下の基本的な知識はすべて、DDoS攻撃を中心に説明します。
1.1 - OSI Reference Model / OSI参照モデル / OSI階層モデル / OSI Layer Model
OSIにおいて「コンピュータの持つべき」だとされた、通信機能を階層構造に分割したモデルである。ISOの定義によると、すべてのネットワーク通信は7つの階層に分類されます。
本来の定義は以下のようになっています:
- L7 (Layer 7): Application Layer アプリケーション層
- L6 (Layer 6): Presentation Layer プレゼンテーション層
- L5 (Layer 5): Session Layer セッション層
- L4 (Layer 4): Transport Layer トランスポート層
- L3 (Layer 3): Network Layer ネットワーク層
- L2 (Layer 2): Data Link Layer データリンク層
- L1 (Layer 1): Physical Layer 物理層
しかし、これはあくまでも理論的なモデルです。実際には、Layer 5とLayer 6の両階層を無視するのが一般的です。だから、実質的には5層のネットワークモデルを日常的に使っているということです。
各層の概念を分かりやすくするために、各層で機能するものの例を挙げてみましょう:
- L7 (Layer 7): DNS、FTP、SSH、HTTP(S)など
- L4 (Layer 4): TCP、UDP、ICMPなど
- L3 (Layer 3): ルータ、BGP、ARPなど
- L2 (Layer 2): ネットワークスイッチ、ネットワークアダプターなど
- L1 (Layer 1): ストレートケーブル、光ファイバー、ハブなど
これは分かりやすいように。ちがみに、OSIモデル以外は、まだTCP/IPモデルがある。でもなんでもいい、ただのモデルだ。
1.2 - TCP
TCPは、最も一般的に使用されているインターネット接続プロトコルの一つです。ここでTCPの原理を詳しく説明する必要はなく、グーグル検索をすれば、私ができる以上に詳しく説明してくれます。
しかし、知っておかなければならないのは、TCPがどのようにハンドシェイクで接続を確立するのか、という2点です。 2つ目は、TCP接続の切断を各OSでどのように処理しているかということです。
TCPがどのようにハンドシェイクで接続を確立するのか
上の図からわかるように、TCPハンドシェイクプロセスには3つのインタラクションがあります。
クライアントによって開始された最初のインタラクションのプロセスを「SYN」と呼ぶ。サーバーはクライアントからのSYN要求を受信した後、「SYN-ACK」と呼ばれる応答を返し、一定期間接続を維持します。サーバーから「SYN-ACK」応答を受信した後、クライアントから「ACK」と呼ばれる最終応答が送信されます。全プロセスを組み合わせたものがTCPハンドシェイクです。
この処理から明らかなように、IPを偽装することでSYN要求を直接送信できることがわかります。でもACKはだめ。
IPを偽装してSYNリクエストを送信すると、サーバーのリソースの一部を消費して、ACK応答を受信できる状態にしまいます。この状態は「SYN_REVD」です。しかし、ほとんどの Linux システムでは、ACK 応答が受信されない場合、15 秒後にこの接続を閉じます。
サーバーがクライアントからACK応答を受信した後、サーバーはTCP接続を維持し、データを受信できる状態になります。
TCP接続の切断
上図は一般的なTCP接続の切断の処理だ。理論上、両方も接続を停止する要請を提出できます。どちらが接続停止の要請を提出するば、その提出方が「TIME_WAIT」状態になります。「TIME_WAIT」状態は、OSがソケットリソースを再利用するのを待機している状態で、この待機プロセス中にソケットリソースは再アクティブ化されません。一定期間待機した後、OSはこれらのソケットリソースを完全に再利用し、次の使用を待ちます。デフォルト設定では、Linux OSの「TIME_WAIT」時間は60秒、BSDの「TIME_WAIT」時間は45秒、そしてWindows OSの「TIME_WAIT」時間は240秒です。
一般的な状況で、大体はClientをTCP接続を停止の要請を提出するですが、でも、ウェブサービスは全然違う。原因はちょっと複雑ですが、簡単に言えば、ウェブサービスで、99%の状況はサーバー自身をTCP接続を停止するそういうことです。
この点については、まずHTTPプロトコル標準に「Keep-Alive」モードがあることを知っておきましょう。HTTP 1.0 標準では、「Keep-Alive」はデフォルトで無効になっています。HTTP 1.1標準以降、「Keep-Alive」はデフォルトで有効になっています。
HTTP標準によると、「Keep-Alive」がオフの場合、サーバーはデータ転送が完了した後に、対応するTCP接続を停止し、「TIME_WAIT」状態になります。そして、Keep-Alive を有効にすると、データ転送後もサーバーは TCP 接続を維持し、対応する TCP 接続を閉じるかどうかはクライアントに委ねられます。
しかし、実際のところ、ほとんどのクライアントブラウザでは、たとえデータ転送から時間が経っていても、ページが閉じられていない限り、積極的に接続を閉じることはなく、開いたままの状態が続いています。この場合、ウェブサーバーでは、接続リソースを解放するために、長時間データを送信していない接続を閉じる「Keep-Aliveタイムアウト」の設定を行います。
これこそ、「ウェブサービスで、99%の状況はサーバー自身をTCP接続を停止する」の原因です。
1.3 - UDP
UDPは、非常にシンプルになるように設計されたデータ転送方式です。 TCPとは異なり、UDPには接続の概念がありません。 簡単に言うと、UDPは、送信されるデータをパッケージにラップして、直接受信者に送信するようなものです。
非常にシンプルなデザインで、UDPが簡単に偽造されてしまうことがよくわかります。 データを送信する前にハンドシェイクが必要なTCPとは異なり、IPを偽装してUDPパケットをサーバーに送信すると、サーバーはそのIPが偽装かどうかを見分けることができません。
また、UDPにはトランスポートストリームという概念がないため、典型的なUDPフラッドは巨大なUDPパケットをターゲットサーバーに直接送信し、サーバー全体の帯域幅を一杯にしてしまいます。
UDPプロトコル自体は適法性を確認するために何もしないので、アプリケーションではそれに応じて処理しなければなりません。
しかし、ほとんどのアプリケーションでは、UDPプロトコルを使ってデータを転送する際に、適法性を厳密にチェックしていないのが現実です。 この結果、UDPを使用するすべてのアプリケーションは、理論的には反射攻撃のために悪用される危険性があるということになります。
唯一の例外は、データ転送プロトコルとしてUDPを使用するWireGuardですが、WireGuardの暗号アルゴリズムはAEADを完全に実装したもので、WireGuardはリプレイ攻撃に強い転送プロトコルを設計しています。
つまり、もしWireGuardは不正なパケットを受信しているも何も返事しない。
1.4 - 帯域幅
厳密にはより科学的な用語ですが、ここではあくまでも通信回線容量の一般的な用語として解釈しています。
サーバーを購入する際には、ネットワークカードの速度で表記されていることが多いです。 それは、このサーバーの最大通信速度はどのくらいなのかということです。
理論的には、サーバーがどれだけの帯域幅を持っているかというと、どんな規模のフラッドDDoS攻撃にどれだけ対抗できるかということになります。
しかし、実際には、DDoS攻撃への耐性はサーバーの帯域幅に依存していません。
画像は、典型的なネットワークのルーティングパスを示しています。
実際の帯域幅は、様々なポイントを結ぶネットワークパスの容量に依存していることがよくわかります。 例えば、当社のサーバーに100Gbpsの帯域幅のラベルが貼られていて、データセンター全体で40Gbpsの帯域幅があるとすると、実際には40Gbpsの帯域幅が利用できることになります。
1.5 - pps / packets per second / パケット毎秒
ppsとは、デバイスが1秒間に処理できるパケット数を測定する単位です。見落としがちですが、実はとても重要な指標です。
例えば、Linux サーバーが Windows サーバーよりも優れたパフォーマンスを発揮することは誰もが知っていますが、Linuxサーバーが何「pps」をホストできるかを知っている人はどれくらいいるでしょうか？
正解は、dpdkやnetmap、そしてXDP（eXpress Data Path）やNDIV（Network Diverter framework）を使わずにパケットロス0%でLinuxカーネルを経由してパケットを処理するには「25000 pps」がLinuxの限界です。この結果はハードのメリットとは無関係です。 その理由については、今後の記事で詳しく解説していきたいと思います。
また、1秒間に何個のパケットを処理できるかは、ネットワークインフラの重要な指標となります。十分に注意を払わないと、ネットワークインフラがクラッシュする可能性があります。
1.6 - 反射攻撃 / リフレクション攻撃
反射攻撃は、DDOS攻撃を実現方法の一つです。DDOS攻撃の8割を占めるようになったのも、この方法です。
反射攻撃は通常、UDP プロトコルを使用するインターネットサービスを悪用します。なぜUDPプロトコルなのか？ 先でUDPプロトコルの特徴について述べましたが、UDPプロトコルはTCPプロトコルのようにクライアントの存在を確認するためのハンドシェイクを必要としません。反射攻撃としてよく悪用されるサービスは、NTP、memcached、SSDP、LDAP、DNSなど。
上の図は、一般的な反射攻撃の流れを示しています。実際、**反射攻撃では、攻撃対象のIPを偽装したUDPパケットを使って反射元へのリクエストして、そのIPが偽装されているから、攻撃対象のIPにリクエスト結果を返信されてしまいます。**理論的には、データ転送にUDPプロトコルを使用するすべてのサービスが反射攻撃として悪用される可能性があると言ってもいいでしょう。もちろん、TCP SYNにも一定の反射効果があります。
UDPプロトコルを使用するのサービス中、唯一の例外はWireGuardです。原因は先も説明しました。
1.7 - 増幅攻撃
実際、増幅攻撃と反射攻撃はいつも一緒になっています。つまり、DDos攻撃が増幅攻撃されている以上、反射攻撃でなければならない。一般的には「反射増幅攻撃」と呼んでいます。しかし、ここでは分かりやすく説明するために、「反射増幅攻撃」を「反射攻撃」と「増幅攻撃」に分けて説明します。
増幅攻撃とは、クエリサービスの特性を使用する攻撃方法であり、クエリ結果のサイズはクエリ要求のサイズよりも数十倍、数百倍大きくなり、攻撃トラフィックが増幅されます。
増幅攻撃の利用はUDPプロトコルと密接に関係しており、増幅攻撃のソースはすべて、一般的な「NTP」サービスのようにUDPプロトコルを通信プロトコルとして利用しているインターネットサービスです。NTPサービスはレイテンシーの関係上、通信にUDPプロトコルを使用するように設計されていますが、このサービスのため、クライアントがNTPサーバーにクエリ要求を行う際には、多くのデータを提出する必要がなく、NTPサーバーはクエリ要求の数百倍のサイズのクエリ結果を返してきます。NTPサービスを例にとると、増幅攻撃の原理を簡単に理解できます。
簡単に言えば、NTPサーバーへのクエリ要求を発信するためにターゲットIPを偽造し、NTPサーバーがターゲットIPにクエリ結果を送信することです。
図から、増幅攻撃の目的は、リフレクションソースを介して攻撃トラフィックを増幅し、ターゲットサーバーの帯域幅を占有することであることがわかります。
ただし、反射攻撃と同様に、理論的には、すべての増幅攻撃がUDPプロトコルを利用するサービスであるとは限りません。TCP SYNにも一定の反射効果があります、それにもちろん一定的な増幅効果があります。しかしTCP SYNには、増幅効果がただの４倍くらいたけだ、そしてTCP SYNのパケットサイズが非常に小さい、４倍の増幅はまだ小さいすぎる。だから、TCP SYNの反射増幅攻撃は意味はない。
ですから、反射増幅攻撃一番優先の狙いは高倍率のデータパケット増幅効果を追求することです。この高倍率は基本的に100倍以上の増幅を追求する。この倍率やっはり一般的には不可能ですが、でももしソフトがバグそれとも深刻な脆弱性がありますのとき、それは可能だ。
1.8 - ゾンビネット / Zombie Net / ボットネット / Bot Net
ウィキでボットネットの説明は、攻撃者の指令や遠隔操作などを受け入れるよう、コンピュータウイルスなどに感染させた多数のコンピュータを組織したネットワーク。
この説明大体は問題ないですが、ちょっと古いです。ボットネットは今までもう３０年歴史があります、この３０年間は定義ほとんどん変わらない。ただし今のボットネットはただのパソコンじゃありません、今のボットネットの主要コンポーネントはもうはやスマートデバイスになっています。例えば、スマートソケット、スマートバルブ、ルーター、スマート冷蔵庫など。
これらのスマートゾンビデバイスには、チェックアウトが困難し、 そして、チェックしても修理は困難です。ですから、スマートデバイスに基づくボットネットは、ボットネットとしては非常に安定した特性を備えています。
2. DDoS攻撃の分類
今回私は、DDoS攻撃の分類を他の人とは全く違うものにしようと思います。普通的な大体は攻撃の方法に分類するですが、でもそれは攻撃に対応するの時、理解難しい。そこで、ここではDDoS攻撃を攻撃目的、例えば「帯域幅を枯渇させる」と「サーバーやネットワークインフラ設備の処理リソースを枯渇させる」このようなにして、別に分類してみます。
でもこの分類方法はもちろん問題があります。例えば「帯域幅を枯渇させる」。**すべてDDoS攻撃はもし規模が大きいすぎっての時「帯域幅を枯渇させる」みだいの効果があります。**ですから、ここの攻撃目的は第一目標に基準をして、それままに分類しています。
2.1 帯域幅を枯渇させる
「帯域幅を枯渇させる」とは、通常のトラフィックがターゲットに到達できないように、攻撃ターゲットの帯域幅を巨大な攻撃トラフィックで埋める攻撃方法です。
しかし理論的には、ターゲットがサービスをそのままつづく提供できなくために、DDoS攻撃もそのままつづくする必要がなければならない。
これって、攻撃者にとって、この攻撃は費用効果が高くないでしょう？確かにそうです。
でも、現実は、DDoS攻撃のクリーニング機能を提供するベンダーを除いて、今世界中99割のサーバープロバイダーやホスティングプロバイダーやデーターセンターもDDoSの攻撃を受けるサーバーへに**ブラックホールルータ（Null Route）します。それで、攻撃ターゲットもサービス提供不能の状態です。攻撃者の目標は達成されました。このブラックホールルータ（Null Route）**の状態はほとんど1時間以上に続きます、その状態続くの時間は全部プロバイダーの決定事項です。
したがって、ほとんどの攻撃者は、DDoS攻撃のクリーニングを提供しないサーバーでのみこの攻撃方法を使用します。
でも例外もあります。もしその攻撃目標はISPなれば、攻撃者は大きいな攻撃トラフィックがあるとき、ISPはブラックホールルータ（Null Route）を絶対使わない。その時攻撃者は攻撃にそのままつづくする必要がなければならない。
このカテゴリに該当する一般的なDDoS攻撃には、以下のようなものがあります：
2.1.1 UDPフラッド攻撃 [Layer 4攻撃]
理論的に、すべてのUDPを使っているのDDoS攻撃はUDPフラッド攻撃です。でも普通に言えば、UDPフラッド攻撃は、特に、意味のない（データ内容はランダムな内容およびその他の無意味な内容）大規模な攻撃UDPパケットを発信するのDDoS攻撃を指します。
このタイプの攻撃のUDPパケットは通常IPを偽造します。このタイプの攻撃の発信元は、通常、広帯域幅の商用サーバーのみです。 ハーキンされたサーバーか、攻撃者自身が購入したサーバーである可能性があります。
いずれにせよ、家庭用の設備のボットネットがUDPフラッド攻撃に使用されることはほとんどありません。
原因は、ほとんどの家庭用光回線プロバイダーがUDPパケットでQoS操作を実行するためです。そしてもし大きいなUDPパケットを発信しているのばいは、７０％のISPはこのパケットを直に捨てます。つまり、家庭用光回線は大きいなUDPパケットを発信することは難しい。
ですから、普通的にこのタイプの攻撃は明らかな特徴があります。さらにフィルタリングするために、これらのデータパケットが送信されるASNネットワークを簡単に追跡できます。
この種の攻撃は今ではまれです。 攻撃者にとって、この攻撃は費用効果が高くないからです。
2.1.2 NTP反射増幅攻撃 [Layer 7攻撃]
NTP反射増幅攻撃は、反射増幅攻撃の中でも最も一般的なものです。
理論的には、通信プロトコルとしてUDPプロトコルを使用するすべてのサービスが反射増幅攻撃に悪用される可能性があります。しかし、正しい設定とNTPサーバーのバージョンに脆弱性がなければ、通常のNTPサーバーでは1回のリクエストの結果が1.8倍に増幅されるだけです。
ただし、設定に欠陥があり、脆弱性のあるバージョンのNTPサーバーを使用している場合、このリクエストの結果は最大で557倍に増幅されます。
幸いなことに、今のグローバルインターネットには、このような高倍率のNTPサーバーはありません。しかし、何十倍ものリクエストの結果を増幅できるサーバーは今でも存在しており、現在までに何千台ものサーバーが存在しています。
なぜNTPサーバーはリクエストの結果をそれほど増幅できるのですか？これは、NTPサーバーでは「monlist」という機能が有効になっているためです。 この機能は、バージョン4.2.7以下のNTPサーバーではデフォルトで有効になっています。この機能を有効にしたNTPサーバーでは、攻撃者はこの機能を使用して、NTPサーバーが最後にリクエストした600のリクエスト結果のIPに対して再度リクエストの結果を送信することができます。
攻撃者は、IPアドレスを偽装してNTPサーバーに一定数のリクエストを送信し、NTPサーバーのモンリストを埋めることで、攻撃トラフィックをモンリスト機能で増幅させることができます。 NTPサーバーのモンリストを埋める過程で、NTPサーバーはすでに増幅元の反射として動作し、被害者ターゲットに攻撃トラフィックを送信しています。monlistが一杯になると、攻撃者はmonlist機能を使って、NTPサーバーの最大帯域幅サイズを送信します。これが、一部のNTPリフレクション増幅攻撃の攻撃トラフィックが増加し、一定期間後にピークに達する理由です。
現在の世界では、世界のインターネットに利用可能なNTPサーバーが数千台しか残っていないとしても、各サーバーが100Mbpsの帯域幅を持っていると仮定すると、200Gbps以上の攻撃トラフィックを簡単にヒットさせることができます。
以上がNTP反射増幅攻撃の原理です。
2.1.3 DNS反射増幅攻撃 [Layer 7攻撃]
DNS反射増幅攻撃は、プロトコルの特徴を利用した攻撃です。 通常の通常のDNSクエリのリクエストは36Byteで、返される結果はほぼ120Byteを超えています。 なので、通常のDNSの反射増幅は3倍程度です。 これはDNSサーバーのソフトウェアの設定ミスや脆弱性によるものではありません。
では、DNS反射増幅攻撃の増幅率を上げることは可能ですか？
もちろん、できる。
まず、nslookクエリのように、DNSクエリリクエストにクエリパラメータを追加します。続く、1つのドメイン名の下に数十、数百のAレコードやCNAMEレコードなど、多くのレコードが返ってくるドメイン名を選択することができます。
最後に、上記の2つのポイントを組み合わせると、50倍を超える攻撃リクエストを作成できます。
2.1.4 SSDP反射増幅攻撃 [Layer 7攻撃]
SSDPサービスを一般的に使用するデバイスは、内部ネットワークデバイスであるべきであり、パブリックネットワークにさらされるべきではありません。SSDPサービスを一般的に使用するデバイスは、内部ネットワークデバイスであるべきであり、パブリックネットワークにさらされるべきではありません。 しかし、一部の企業や家庭では、ネットワークの誤設定により、SSDP を使用するデバイスが公開ネットワークにさらされており、攻撃者に悪用される。SSDP反射増幅攻撃は、攻撃パケットが30倍に増幅される可能性があります。
企業や家庭での誤った設定のネットワークに加えて、ここ2年間で、適切に設定された内部ネットワーク内から発生する SSDP 反射増幅攻撃もあることがわかりました。 分析の結果、内部ネットワークの下にはすでにボットネットの一部である他のデバイスが存在しており、ボットネットは内部ネットワークをスキャンして攻撃することで、これらのSSDPデバイスを悪用していると結論づけました。
2.1.5 CLDAP反射増幅攻撃 [Layer 7攻撃]
CLDAPは軽量なディレクトリアクセスプロトコルです。 しかし、CLDAPの反射増幅攻撃は、100％はWindowsサーバーから来ると言えます。 これは、Linuxで使用されているオープンソースのLDAPソフトウェア「openLDAP」が、15年前にUDPプロトコルの使用を停止したためです。
**CLDAP反射増幅の原因は、Windowsサーバーの所有者がWindowsファイアウォールのパブリックネットワークの状態を正しく設定していなかったことにあります。**しかし、CLDAP の反射増幅攻撃の増幅率を増加してこす CLDAP バグは存在します。
現在、CLDAP反射増幅攻撃の最大倍率は86倍です。
2.1.6 Memcached反射増幅攻撃 [Layer 7攻撃]
Memcached反射増幅攻撃は、今まで私を見てきた中で一番でかいの攻撃トラフィックが増幅されているはずです。
memcachedは、汎用の分散型メモリキャッシュシステムである。
2018年の春、私自分が運営しているのCDNサービスは世界中のMemcachedサーバーから大量の攻撃トラフィックを受け、攻撃トラフィックの帯域幅は1.8Tbpsのピークに達していました。正直、当時はこの程度のDDoS攻撃を見たのは初めてでした。 当時の攻撃トラフィックは、私と私のアップストリーム回線プロバイダが利用可能な帯域幅のほぼすべてを占めていました。
その後、Memcachedの反射増幅攻撃の原理を分析してみたところ、以下のような結論に至りました。
memcachedの反射増幅攻撃の最も直接的な原因は、memcachedサーバーの管理者がmemcachedのリスニングアドレスを誤って設定したことです。 通常のmemcachedは、パブリックネットワーク(0.0.0.0)ではなく、ローカルのループバックネットワーク(127.0.0.1)をリッスンしているはずです。
また、パブリックネットワークをリッスンするように設定されているmemcachedサーバーでは、管理者は、memcachedサーバーへの不正アクセスをブロックするためのファイアウォールを効果的に設定するためのルールを持っていません。しかし、さらに分析してみると、Memcachedの反射増幅攻撃のトラフィックのほとんどが、RHEL、CentOS、FedoraなどのRed Hat系のLinuxディストリビューションからのものであることがわかりました。
結果、CentOSで自分でテストしてみたところ、この問題の一番直接的な原因がわかりました。 このような設定エラーが蔓延している最も直接的な原因は、Red Hat系のLinux ディストリビューションで使用されている yum ツールインストールの memcached サーバー側のデフォルト設定が、パブリックネットワークを直接リッスンするようになっていることです (0.0.0.0)。 ほとんどのCentOSサーバー管理者は、その後、トラブルのためにFirewalldをシャットダウンします。
しかし、パッケージ管理に apt を使用している Ubuntu や Debian などの他の Linux ディストリビューションでは、この問題はそれほど広くはありません。だって、apt を使用してインストールされた memcached の設定ファイルは、デフォルトでローカルのループバックネットワーク (127.0.0.1) をリッスンします。 管理者が勝手に設定ファイルを変更しない限り、この問題は起こりにくい。
問題がどのように発生するかは、すでに理解しています。 しかし、memcachedはどのようにして膨大な攻撃トラフィックを発生させているのでしょうか？
ウェブ上で公開されているいくつかのPoCを見てみたところ、どれも出力を攻撃するためにmemcachedの「get」コマンドを使っていることがわかりました。しかし、私の経験上、費用対効果の高い方法ではない。では、もし私たら、どっやて攻撃トラフィックの増加を最大化するために何をすればいいのでしょうか？
まず、memcachedの値はデフォルトで1MBなので、値が1MBのレコードを構築します。 そして、「gets」コマンドを使って攻撃リクエストを作成します。 これは、最大攻撃倍率50万倍のmemcached反射増幅攻撃を構築します。
だからこそ、冒頭で言った「Memcached反射増幅攻撃は、今まで私を見てきた中で一番でかいの攻撃トラフィックが増幅されているはずです。」ということです。
2.1.7 QUIC反射増幅攻撃 [Layer 7攻撃]
QUICプロトコルはUDPで実装されたHTTPSプロトコルであり、将来のHTTP/3プロトコルの基礎となるものです。QUICプロトコルの元祖はGoogleで、GoogleがQUICを発明した理由は、YouTubeで使うことがほとんどだったと思います。
しかし、前に言ったように、UDPプロトコルを使用するすべてのサービスは、理論的には反射増幅攻撃のために悪用される可能性があります。QUICプロトコルも例外ではない。
しかし、QUICの反射増幅攻撃は、私がここ数年間で見つけた反射増幅攻撃の中で最も興味深い形である。
自分のCDNサービスでは、もともとQUICプロトコルを有効にして、オンラインストリーミングの客さんをサポートし、ストリーミングコンテンツをより早く配信できるようにしていました。しかし、ある時、クライアントから「ウェブサイトが異常に高いトラフィックを使っている」と報告を受けました。というわけで、そんな斬新な攻め方を発見しました。
QUIC反射増幅攻撃は、0-RTT機能を悪用して、サーバーを騙して攻撃対象にデータを送信させます。 この攻撃を利用した場合、攻撃トラフィックを数十倍、数百倍に増幅することが容易にできる。正確に何倍に増幅できるかは、攻撃者が要求したファイルの大きさに依存する。この根本的な原因は、リプレイ攻撃のためのQUICプロトコルの元々の設計の欠陥であり、現在のHTTP/3のベータ版では大部分が修正されていますが、それでも攻撃トラフィックの10倍の増幅を達成しています。
この攻撃の最も興味深い点は、ほとんどのCDNノードサーバーが通常のサーバーよりもはるかに多くの帯域幅を持っているという事実を攻撃者が利用し、CDNノードサーバーを利用して反射増幅攻撃を実行するという点です。 CDNノードサーバーの数は少ないですが、1点で利用できる帯域量が非常に大きいため、非常に高い攻撃ピークを打つことができます。
もちろん、現在では大手CDNサービスプロバイダの数社が問題を修正しています。 私自身のCDNサービスも含めて、QUICプロトコルのサポートを直接停止しています。 なので、この手の攻撃は今のところあまり見られません。
2.1.8 OpenVPN Server 反射増幅攻撃 [Layer 7攻撃]
OpenVPNはVPNクラスのソフトウェアです。
デフォルトでは、OpenVPNはデータ転送にUDPプロトコルを使用します。なので、反射増幅攻撃できるがどうかなの可能性があります。実際でのテストの結果、1つのパケットに対する増幅倍率はわずか5倍であることが判明しました。しかし、これより深刻な問題があります。
OpenVPNのサーバーは、パケットロスなどのネットワーク問題に対処するために、データ再送の仕組みを設計しています。 簡単に言えば、サーバーからクライアントに送られたパケットに応答がない場合、OpenVPNサーバーは30秒以内にパケットを再送しようとし続けます。 この30秒の間に、攻撃トラフィックは元の5倍から60倍に増幅されます。
しかし、本当に根本的な問題は、なぜ OpenVPN サーバーが偽のリクエストに反応しているのでしょうか? それは熟考すべき問題である。たとえば、WireGuard はこのような偽造された要求には一切応答しません。 とりあえず、OpenVPNのプロトコルがうまく設計されていないと言っておきましょう。
2.1.9 TeamSpeak Server 反射増幅攻撃 [Layer 7攻撃]
TeamSpeakは、チームの音声コミュニケーションツールです。 通信にはUDPプロトコルを使用します。 だから反射増幅攻撃に使われてもおかしくない。 もちろん、TeamSpeakの反射増幅攻撃は基本的に5倍以下と増幅率を持っているわけではないので、これみたいな簡単に紹介してもいいと私がそう思ういます。
2.1.10 BitTorrent Tracker Server 反射増幅攻撃 [Layer 7攻撃]
BitTorrent プロトコルは、ピアツーピア ネットワークでのファイル共有に使用されるネットワーク プロトコル プログラムです。
Trackerサーバーは、BitTorrentプロトコルのさまざまなユーザーが相互に通信するために使用する方法です。 ユーザーは、これらのユーザーとの接続を確立するようにTrackerサーバーに要求することにより、他の既存のユーザーを取得します。 もちろん、Trackerサーバーを介してオンラインユーザーを取得することに加えて、BitTorrentプロトコルはDHTネットワークを使用して他のユーザーを発見するようになりました。
デフォルトでは、TrackerサーバーはHTTPプロトコルとUDPプロトコルの両方を使用してサービスを提供します。ここにあるように、UDPプロトコルの使用は間違いなく反射増幅攻撃が可能です。
では、Trackerサーバーを使用して反射増幅攻撃を実行する原理は何ですか？
最初に、非常に人気のあるTorrentリソースを探します。例えば、同時に5000以上のクライアントをオンラインで持っているTorrentリソースなどです。 そして、IP アドレスを偽造して、このTorrentリソースのユーザーのリストをTrackerサーバーに要求します。 デフォルトでは、通常の Tracker サーバーは 500 個の有効なクライアントのリストを返す。 このように反射増幅攻撃の効果を得ることができます。
Trackerサーバーは、500の有効なクライアントのリストの結果を返します。これにより、通常、攻撃トラフィックが30倍に拡大されます。 Trackerサーバーがより多くの有効なクライアントを返すように設定されている場合、攻撃トラフィックの拡大率はさらに大きくなります。
これは非常にまれな反射増幅攻撃であり、実際の使用例をほとんど検出していません。 この攻撃方法が私によって発見され、私が以前にそれを開示したことがないからといって、誰もそれを使用していないという意味ではありません。 ただし、技術的な問題はほとんどないため、この攻撃方法は非常に簡単に使用できます。 私のさらなる分析によると、UDPプロトコルのサポートが有効になっているTrackerサーバーは世界中に6000以上あり、これらを使用すると、かなりの攻撃トラフィックを引き起こす可能性があります。
「帯域幅を枯渇させる」の分類結論
実際、反射と増幅の原理を使用する多くのDDoS攻撃があります。 ただし、基本的に1つの共通点があります。つまり、偽造されたIPを使用してリフレクションオリジンサーバーにリクエストを送信します。
このタイプの攻撃の目的は、実際には攻撃対象の帯域幅を使い果たしてサービス拒否の効果を達成することです。
しかし、IP偽造データパケットの場合、防御側として、防御するための良い方法はありません。
理論的には、すべてのISPおよびASネットワーク管理者がIP偽造を禁止できる場合、反射増幅攻撃は不可能です。
しかし、これは本当に不可能です。
2.2 サーバーやネットワークインフラ設備の処理リソースを枯渇させる
本分類のDDoS攻撃手法の主目的は、いずれもサーバーやルータなどのネットワークインフラの処理資源を枯渇させることである。
しかし、冒頭でも述べたように、すべてのDDoS攻撃は、一定の規模に達すると帯域幅を枯渇させる効果があります。
2.2.1 サーバーの処理リソースを枯渇させる
この分類によるDDoS攻撃の主な攻撃対象は、ネットワークの帯域リソースではなく、サービスを提供するサーバーの処理リソースそのものである。 一般的な攻撃の種類は以下の通りです：
2.2.1.1 TCP-ACK フラッド攻撃 [Layer 4 攻撃]
TCP-ACKフラッド攻撃は、不正なリクエストがサーバーの限られたTCPソケットリソースを使用しているという事実を利用して、サーバが通常のリクエストを処理できないようにする攻撃です。
TCP-ACKの洪水攻撃は、誤解を招くような名前が付けられています。 TCPハンドシェイク処理の最後のハンドシェイク要求を利用した攻撃ではなく、ハンドシェイクが成功してすでにデータ転送を開始できる状態になっている。
先ほどTCPプロトコルについて説明しましたが、TCPプロトコルのハンドシェイクが成功した場合は、要求されたIPが真正に確認されていることを意味し、偽装IPではありません。このように、TCP-ACKフラッディング攻撃は、ほとんどボットネットを利用した攻撃です。
しかし、過去2年間のTCP-ACKフラッディング攻撃のピーク帯域幅も500Gbpsを超えることが多く、明らかに高い値を示していることも無視できません。
その直接的な原因は、世界中のIoTデバイスが日に日に増えているため、ほとんどのIoTデバイスが脆弱性を抱えていることにあります。 その結果、主要なボットネットはIoTデバイスで構成されるようになりました。 明らかにIoTデバイスは通常のPCよりも数が多くなるだろうし、PCと比較して2つの非常に明確な利点があります。 利点の1つは、IoTデバイスが非常に一貫してオンラインになっており、基本的に1日24時間接続されていることです。 2つ目の利点は、IoTデバイスが動作するウイルス対策ソフトがないため、IoTデバイスに対するウイルスコードを殺すことが非常に難しいということです。
ボットネットによって開始されたTCP-ACKフラッディング攻撃に加えて、インターネット上で公開されているSock5プロキシを悪用したTCP-ACKフラッディング攻撃があります。
ただし、一般に、リフレクションや増幅攻撃などのUDP攻撃と比較して、TCP-ACKフラッディング攻撃は、TCP-ACKフラッディング攻撃のソースを追跡する可能性があります。
2.2.1.2 アプリケーション層へのDDoS攻撃 / Layer 7 攻撃 [Layer 7 攻撃]
アプリケーション層攻撃、いわゆるLayer 7 攻撃。 その名の通り、冒頭のOSI階層モデルのアプリケーションと第7層の両方に対する攻撃です。
もちろん、理論的にはアプリケーション層攻撃には、HTTP(S)フラッディング攻撃やDNSフラッディング攻撃も含まれています。
しかし、**アプリケーション層攻撃は基本的にHTTP(S)フラッディング攻撃やDNSフラッディング攻撃以外のアプリケーションに対するDDoS攻撃を具体的に指して使われています。**例えば、ExChangeのメールサーバーや一部のゲームサーバーに対する飽和DDoS攻撃。
このタイプのDDoS攻撃で使用される攻撃要求は、通常のアプリケーションのデータ通信プロトコルであるため、アプリケーションは通常の処理フローに従って攻撃要求を処理できます。 攻撃リクエストが非常に大量に流入すると、アプリケーションはこれらの攻撃リクエストの処理でビジー状態になり、通常のユーザーのリクエストをタイムリーに処理できなくなり、サービス拒否が発生します。深刻な場合、アプリケーションは直接過負荷になり、クラッシュして、通常のサービスを提供できない可能性があります。
一般的に、私自分でHTTP以外のプロトコルアプリケーションを開発する場合は、使用するデータ通信プロトコルにクライアント側の検証機能を追加しますが、でもこれはDDoS攻撃を直接防止するものではない。検証情報を使用して、ファイアウォールなどのフィルタリングデバイスを直接使用して、これらの違法なリクエストをより簡単にフィルタリングできるという利点があります。 第2に、アタッカーを追跡するための手がかりを提供します。
2.2.1.3 HTTP フラッド攻撃 / CC(Challenge Collapsar)攻撃 [Layer 7 攻撃]
HTTPフラッド攻撃は、本質的にアプリケーション層攻撃です。 ただし、HTTPフラッド攻撃に対する防御は他のタイプのDDoS攻撃とは異なるため、ですから別のカテゴリに分類されます。
HTTPフラッド攻撃は、基本的に、攻撃方法に応じて、GET攻撃、POST攻撃、脆弱性攻撃の3つのカテゴリに分類できます。
GET攻撃とPOST攻撃は、それぞれHTTPプロトコルの2つの一般的なデータ送信方法に対応しています。しかし、攻撃の目的に関する限り、数年前の2つの攻撃方法には若干の違いがありますが、現在の状況では、2つの攻撃方法の最終的な目的は同じであることが示されています。
数年前、GET攻撃は主にWebサーバーソフトウェア、特にApache 2.2より前の飽和攻撃手法を狙っていました。Apache 2.2 以下のデフォルトの作業モードは「Prefork」モードですが、手動で「Worker」モードや「Event」モードに変更することができますが、Apache 2.2 では「Event」モードは安定していません。だから普通な状況で一般人大体は「Prefork」と「Worker」を使っている。これを見ていると、簡単に問題が見えてきる。 もし攻撃者が大量のリクエストを送ると、「Prefork」や「Worker」モードの Apache はゆっくりとサーバ上の利用可能なメモリを埋め尽くし、最終的には Linux カーネルがプロセスを「kill」してしまう。 攻撃者が「Keep-Alive」を有効にした状態でリクエストを送ると、Apache はさらに速くクラッシュする可能性がある。これはサービスを拒否する効果がある。
しかし、現在では、Apache 2.2が段階的に廃止され、Apacheは公式にはバージョン2.4しかサポートしておらず、ほとんどのウェブアプリケーションはウェブサーバソフトウェアとしてNginxを使用し始めています。だからこそう、Webサーバソフトウェアに対するサービス拒否攻撃は非常に稀です。 Apache 2.4 はデフォルトの「Event」モードを使用しているので、Apache は「Event」モードでは Nginx と同様のパフォーマンスとリソース消費を提供します。もしWebサーバーソフトウェア自体を崩壊させるには、非常に多くのリクエストが必要になるため、Webサーバーソフトウェアに対するサービス拒否攻撃が非常に困難になります。 このように、攻撃側のゴールは事実上シフトしている。
攻撃者は現在、HTTPフラッド攻撃を使用して、Webサービスの本当のバックエンドであるデータベースを標的にしています。攻撃リクエストがウェブサービスのフロントエンドを通って実行されるようにして、リクエストが最終的にデータベースに到達し、データベースによって処理されるようにします。 大量の攻撃リクエストでは、データベースが圧倒され、最終的には通常のリクエストを処理できなくなり、Webサービス全体がダウンしてしまいます。
では、一般的なWebサービスのどの機能が、キャッシュされずにデータベースから最新のデータを直接要求するのでしょうか。
**私の個人的な経験によれば、一般的に攻撃されやすいWebサービス機能には、ユーザーログイン、検索、RSSサブスクリプションがあります。**もちろん、GETを使用してデータを送信する検索機能に加えて、他のほとんどの機能はPOSTを使用してデータを送信します。ほとんどの場合、これらのWebサービスの機能はキャッシュ戦略を設定しないか、キャッシュが簡単にバイパスされます。そのため、DDoS防御対策を十分に行う必要があります。
**HTTPフラッド攻撃方法には、ボットネットによるHTTPフラッド攻撃や、多数のプロキシサーバから要求されたHTTPフラッド攻撃、XSSやCSRFを利用したHTTPフラッド攻撃、さらには一部の国では一般ユーザーのWebアクセスを直接乗っ取るをHTTPフラッド攻撃など。 もう1つの特別なリフレクションHTTPフラッド攻撃は、初期バージョンのWordPressのXmlrpc脆弱性を使用した反射HTTPフラッド攻撃です。 **反射HTTPフラッド攻撃と呼んでいますが、一般的な反射攻撃の原理とはまったく異なります。 つまり、HTTPフラッド攻撃を開始する方法はたくさんありますが、最も一般的な方法は、多数のプロキシサーバーを介して攻撃リクエストを送信することです。
実際、すべてのDDoS攻撃の中で、HTTPフラッド攻撃の防御方法は最も簡単だ。簡単に言えば、HTTPフラッディング攻撃を防御するという考え方は、実際には「すべてのリクエストのマンマシン検証」という1つの主要なポイントです。 つまり、このリクエストが実際の人類の閲覧によって生成されているかどうかを確認する方法を見つける必要があります。 後で、HTTPフラッド攻撃に対する防御のアイデアを詳しく紹介する記事を書きます。
2.2.1.4 HTTPS フラッド攻撃 [Layer 7 攻撃]
実際には、攻撃リクエスト数が特に多くない場合は、HTTPSのフラッド攻撃はHTTPのフラッド攻撃とほとんど同じな結果だ。
ただし、もし攻撃リクエスト数がとっても高いな状況には、フロントエンドサーバーは、SSLオフロード操作で多くの処理リソースを消費します。このフロントエンドサーバーは、Layer 7 ロードバランサーおよびWebファイアウォール（WAF）の場合もあります。
HTTPSフラッド攻撃の発動方法は、基本的にはHTTPフラッド攻撃と同じです。しかし、攻撃者が攻撃トラフィックのピークに自信がある場合、一般的なHTTPSフラッド攻撃の主な標的は、WebサービスでのSSLオフロードに使用されるフロントエンド設備です。
SSLオフロード操作には、多くのCPU処理リソースが必要です。 最高のサーバーセントラルプロセッサAMD EPYC 7742がSSLオフロードに使用されている場合でも、1秒あたりの処理速度は約100,000リクエストにすぎません。4つのCPUを搭載したサーバーを使用していても、経験豊富な攻撃者にとって、1秒あたり400,000件の攻撃リクエストは難しくない。
攻撃者がボットネットによって起動されたHTTPSフラッド攻撃を使用する場合、これは、要求の正当性を判断する前に、暗号化された要求を復号化するSSLオフロード処理設備を引き続き追加する必要があることを意味します。 これは基本的に悪夢であり、誰がより多くの処理リソースを持っているかを見るだけの競争です。
幸い、攻撃者の80％は多数のプロキシサーバーを使用して攻撃要求を送信します。これらの攻撃要求はすべて16進数で構築された固定データパケットです。 これは、分析を通じてこれらの攻撃リクエストのシグネチャを取得し、ファイアウォールを直接使用してブロックできることを意味します。
2.2.1.5 ローアンドスロー攻撃 [Layer 4 & 7 攻撃]
ローアンドスロー攻撃とは、プロトコルの欠陥（脆弱性ではなくプロトコルの欠陥であることに注意）を利用してシステムリソースを悪用するDDoS攻撃の一種です。
ローアンドスロー攻撃には2つの既知の攻撃方法があります。 1つは、POSTを介して非常に遅い速度でHTTPデータを人為的に送信することです。 もう1つは、TCPプロトコルのハンドシェイクプロセス中に不安定な接続を作成することであり、このTCP接続は、パケット損失率が高く、レートが非常に低い状況に人為的に作られます。
HTTPベースのローアンドスロー攻撃は、ウェブサーバソフトウェアのスレッドリソースを標的にします。ウェブサーバソフトウェアは通常、データ受信を処理するために別のスレッドを起動することを選択するためです。 スレッドリソースが大量の攻撃リクエストによって占有されると、ウェブサーバソフトウェアとオペレーティングシステムは、新たなアクセスリクエストを処理することができなくなります。
TCPベースのローアンドスロー攻撃のターゲットは、オペレーティングシステムのソケットリソースのみです。
しかし、どんなローアンドスロー攻撃がベースになっているとしても、検出することは困難です。それらのデータパケットには、非常に明白な攻撃特性がないからです。したがって、ローアンドスロー攻撃の影響を減らすために、Webサーバーソフトウェアとオペレーティングシステムの間の接続タイムアウトオプションのみを変更できます。
もちろん、リバースプロキシツールがWebサービスのフロントエンドとして使用されている場合、ローアンドスロー攻撃の影響はフロントエンドサーバーに完全に限定されます。
2.2.2 ネットワークインフラ設備の処理リソースを枯渇させる
この部分のDDoS攻撃は、基本的に、コアルーター、境界ルーター、ゲートウェイ、DNSサーバーなどのネットワークインフラ設備に対する攻撃です。 主な攻撃対象はサービスを提供するサーバーではありませんが、サーバーに影響を与える可能性もあります。
これらのネットワークインフラ設備への攻撃は、より広範な影響を与える可能性があります。 たとえば、DNSサーバーへの攻撃は、このDNSサーバーを使用する他のユーザーにも影響します。 データセンターのコアルーティングに対するDDoS攻撃により、データセンター全体のネットワークインフラ設備が通常のサービスなどを提供できなくなります。
2.2.2.1 TCP-SYN フラッド攻撃 [Layer 4 攻撃]
TCP-SYNフラッド攻撃は、TCPハンドシェイクプロセスでSYNと呼ばれる最初のパケットを使用するDDoS攻撃です。SYNパケットの特徴の1つは、サイズが非常に小さいため、攻撃の規模が非常に大きくない限り、基本的にTCP-SYNフラッド攻撃に大きな帯域幅のピークはありません。
通常の状況では、サーバーは、TCPハンドシェイクプロセスを続行するためのSYNリクエストを受信した後、応答としてSYN-ACKを返します。 クライアントがACK応答を返すのを待つこのプロセスでは、サーバーは通常、使用されたばかりのポートを予約し、リクエストをSYN待機キューに保存します。
クライアントがACK応答を長時間返さない場合、Linuxシステムは通常、予約されたシステムリソースを解放し、15秒後にそれらを再利用します。 明らかに、この15秒の待機時間は、他のキューに比べて比較的短いです。 しかし、問題は、SYN攻撃リクエストが大量にある場合、LinuxのSYN待機キューのデフォルトの長さは128のみであり、通信ポートが65,535しかないため、Linuxはデフォルトで30,000を超えるポート番号で応答するという事実にあります。そのため、理論的には、攻撃者は1秒間に2,369回のSYN攻撃リクエストを送信し、サーバのSYNキューをすべての応答ポートで満たすためにそれらを送信し続けるだけで済むことになります。
しかし、インフラエンジニア達が座って死ぬのを待たないことは明らかです。SYN待機キューの長さを増やし、下側のポートを応答ポートとして開き、「SYN Cookie」機能を直接有効にするだけで、SYNフラッド攻撃は基本的にその効果を失っています。
では、SYNフラッド攻撃の実際の恐ろしい部分はどこにあるのでしょうか。
まず、SYNフラッド攻撃を開始する方法を知る必要があります。 SYNフラッド攻撃を開始するには、一般的に3つの方法があります。1つ目は、攻撃者が直接開始するSYNフラッド攻撃です。 この種の直接SYN攻撃は、基本的に広い帯域幅を使用する商用サーバーですが、このサーバーは攻撃者に侵入された後に制御される場合もあれば、攻撃者が直接購入する場合もあります。 直接開始されたSYNフラッド攻撃は、IPを偽造していない可能性があります。IPが偽造されていない場合は、直接IPをブロックできます。 2つ目は、偽造IP情報を使用したSYNフラッド攻撃です。 この攻撃方法は、UDPフラッド攻撃に少し似ており、基本的に現在最も一般的な攻撃状況です。 3つ目は、ボットネットによって起動されたSYNフラッド攻撃です。 ただし、どのような状況であっても、一般的には「SYN Cookie」機能が有効になっている限り、影響は最小限に抑えられます。
次は怖いところです。1つはハードウェアファイアウォールです。**一般的なハードウェアファイアウォールには、「pps」というパフォーマンスインデックスがあります。市場に出回っているほとんどのハードウェアファイアウォールのデフォルトルールは、非常に大きなパケットをクリーンアップすることですが、SYNパケットのサイズは小さすぎ、多くのファイアウォールは基本的にこれらのSYNパケットをインターセプトしません。**ただし、ハードウェアファイアウォールは基本的に、低コストのハードウェアまたは直接カスタマイズされたチップを使用してすべてのリクエストを処理します。SYNフラッド攻撃の規模が十分大きい場合、ハードウェアファイアウォールの転送容量を直接占有する可能性があります。同時に、「pps」はゲートウェイまたはルーターにとって非常に重要な指標でもあります。一般的に、**ルーターまたはハードウェアファイアウォールがデバイスの最大負荷「pps」をマニュアルでマークしていることがわかります。基本的に、この処理能力を超えると、ルーターのパフォーマンスの低下または直接的なダウンタイムしか発生しないため、拒否が達成されますサービス攻撃。**ただし、ほとんどのハードウェアファイアウォールとルーターに「SYN Cookie」機能がないことは非常に現実的であり、SYNフラッド攻撃に直面しても基本的に無力です。したがって、SYNフラッド攻撃の主な標的は、実際にはこれらのネットワークインフラ設備です。
2.2.2.2 ICMP(Ping) フラッド攻撃 [Layer 4 攻撃]
ICMPプロトコルは、ネットワークの状態をチェックするためによく使用されます。 ICMPパケットのサイズは基本的に非常に小さく、SYNと同様です。 ICMPのサイズも可変ですが、大きすぎるICMPパケットは基本的にファイアウォールによってブロックされるか、ISPによって直接廃棄されるため、ICMPパケットのほとんどはそれほど大きくありません。 これは基本的に、通常のサーバーのICMPデータパケットのサイズを制限するか、ICMPエコー機能を直接無効にします。これにより、サーバーにあまり影響を与えません。 ただし、ルーターやゲートウェイなどのネットワークインフラ設備の処理能力は限られているため、ICMPエコーはある程度のリソースを消費します。 ICMPリクエストが多すぎると、ネットワークインフラ設備はこれらのICMPリクエストに応答するのに飽き、通常の要求を処理できなくなります。
しかし、実際には、ICMPフラッド攻撃に対処するのは非常に簡単です。パブリックネットワーク上でネットワークインフラ設備を公開しない、そしてICMP機能をオフにしない、基本的にICMPフラッド攻撃は大きな影響を与えません。
通常、攻撃者はボットネットを使用してICMPフラッド攻撃を仕掛けますが、ICMPフラッド攻撃は攻撃者にとって非常に費用対効果の高い攻撃方法ではないため、今のところ見ることは困難です。
2.2.2.3 DNS フラッド攻撃 [Layer 7 攻撃]
ここでのDNSフラッド攻撃とは、DNSプロトコルを使用してターゲットにDDoS攻撃を仕掛けるのではなく、ターゲットが使用するドメインDNSに対して起動されるDDoS攻撃を指します。 これは、前述のDNS反射増幅攻撃とは完全に異なります。
つまり、攻撃対象が使用するドメインDNSが攻撃を受け、通常のサービスを提供できない状態になり、攻撃対象がサービスを正常に提供できなくなります。
上記のDDoS攻撃方法に加えて、通常、攻撃対象のDNS解析レコードを必死にクエリするボットネットがあり、ドメインDNSの過負荷を引き起こし、サービスを提供できません。 もちろん、攻撃者が使用するドメインDNSが解析の数に毎月の制限がある場合、またはドメイン名DNSサービスがボリュームごとに請求される場合、ドメインDNSプロバイダーはドメインのDNS解析を一時停止するか、高額の請求書を発行する可能性があります。
DNSの洪水攻撃に対して私ができる唯一のアドバイスは、信頼できるドメインDNSベンダーに切り替えることです。
2.2.3 DoS類の脆弱性を利用するの攻撃
このカテゴリのDDoS攻撃は特別です。過去数年間の私の経験によれば、このカテゴリの攻撃はDoS攻撃としか見なせず、DDoS攻撃とは言えません。 なぜなら、基本的には攻撃元は1つだけであり、通常はリクエストが数個しかないからです。
すべてのオペレーティングシステムとソフトウェアに脆弱性があります。 特に近年のLinuxの人気とユーザーの増加に伴い、Linuxは時々深刻な脆弱性にさらされることになります。 これらの脆弱性の多くは、DoS攻撃の実装に使用できます。
でも正直に言えば、このカテゴリで議論することはあまりないです。だから、インフラエンジニアの皆さんがサーバーのオペレーティングシステムとソフトウェアを適時に更新することをお勧めします。
「効果的な簡単のWebサーバセキュリティ対策」で以前書いた一連の記事を読むことをお勧めします。
3. 終了
正直に言えば、この記事でこんなに多くの内容が書かれるとは思っていませんでした。 いくつかDDoS攻撃の原理について説明しましたが、20,000文字を超えるとは思っていませんでした。そして、私は実際にこの記事を2か月間書きました。本当に予想外です。
この10年間の経験を整理し、最後に言葉で書くので、この記事を書くのにうんざりしています。 そして、私の母国語は日本語ではないので、書くことの効率は本当に低いです。
なぜこの記事を書く必要があるのですか？日本のインターネットをもっと安全にしたいと思っています。以前、完全に無知な日本のブロガーが書いた本当に酷いDDoS防御対策の数々を読んだことがありました。しかし、日本語でDDoS攻撃防御についての記事をさらに調べてみたところ、多くの人がDDoS攻撃とは何かを知らず、書かれた記事は完全に誤解を招く読者であることがわかりました。たとえば、海外のIPをブロックする場合は、非常に面白いIPリストをApacheにインポートするのではなく、すべて海外からのルートを直接ヌルルートしてください。じゃないと、何も意味はない。だって攻撃リクエストがサーバーに到着できる。
このバカみたいな対策はインフラエンジニアに対する侮辱だ。