DDoS 攻撃とは何か：技術、3 つのレイヤーと対策

DDoS 攻撃とは、人為的に作り出した過負荷によってサービスを到達不能にする試みで、非常に多くの異なる送信元から同時に実行されるものです。略語は Distributed Denial of Service、つまり分散して引き起こされたサービス拒否を表します。狙われるのはサーバーの中身でもソフトウェアの脆弱性でもなく、有限な資源です。回線の帯域幅、ネットワークカードのパケットレート、カーネルの状態テーブルの 1 枠、あるいはアプリケーションが 1 件の要求に費やす計算時間です。この 4 つの資源のうちどれか 1 つが埋まれば、本物の利用者は通れなくなります。しかも、誰かがシステムに侵入したわけではありません。

本記事はこのテーマの入口です。攻撃が起きる 3 つのレイヤー、1 バイトの要求が 5.1 万バイトの応答になる増幅率、攻撃の能力がどこから来て市場でいくらするのか、ご自身の測定値から攻撃をどう見分けるか、サーバー上で何がまだ効くのか、そしてその限界がどこに引かれるのかを解説します。すべての数値には出典を添えてあるので、ご自身で確認できます。サービスがいま止まっているなら、まず「攻撃を受けたときにやること」の節を読み、設定をいじるのではなく測定してください。

DDoS 攻撃は技術的に何なのか

どの DDoS 攻撃も非対称性で成り立っています。パケットを 1 つ送る費用は、標的がそのパケットを処理する費用より小さくなければなりません。あとは、この非対称性がどこで最大になるかという問題だけです。その場所はちょうど 4 か所あり、どれにも計算できる硬い上限があります。

回線の帯域幅。1 Gbit/s の接続が運べるのは毎秒 125 メガバイトで、それ以上はありません。それより多く送れば損失が出ます。埋まった接続は選別しないため、損失は攻撃側のパケットと同じように利用者のパケットにも当たります。

パケットレート。許される最小の Ethernet パケットは 64 バイトで、プリアンブルとパケット間隔を含めると回線上で 84 バイトを占めます。1 Gbit/s にはこれが毎秒約 149 万入ります。通常のサーバーのカーネルが破棄を始める前に処理できるのは、CPU とネットワークカードによりますが数十万です。ですからパケットレートは、ほぼ常に帯域幅より先に届く限界です。

状態テーブル。カーネルは半開きの TCP 接続とパケットの流れを覚えます。このテーブルの制限は件数で、毎秒のビット数ではありません。パケットごとに新しい送信元アドレスが付いていれば、ごくわずかな帯域幅で埋められます。

アプリケーションの計算時間。検索の要求、パスワード検証を伴うログイン試行、Mod の一覧を丸ごと返す問い合わせは、標的にとって送信側の千倍の費用になります。ここでは、効く攻撃に 10 Mbit/s さえ必要ないことがよくあります。

DoS と DDoS：測定できる違い

用語の土台は RFC 4732「Internet Denial-of-Service Considerations」、2006 年 11 月の IETF による情報提供文書です。そこには次のように書かれています。「A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work.」つまり DoS 攻撃は、発信源の数ではなく効果によって定義されています。その発信源が多数あり互いに独立しているとき、分散した、つまり DDoS になります。

実務でこの違いが効くのはちょうど 1 か所、遮断リストの長さです。1 つの発信源からの DoS 攻撃は、ルール 1 本で終わらせられます。Cloudflare は 2025 年 5 月に、161 か国 5433 の自律システムにまたがる 12 万 2145 の異なる送信元アドレスから来た攻撃を記録しています。新しいアドレスは平均で毎秒 2 万 6855、ピークで 4 万 5097 でした。これに間に合う速さで伸びる遮断リストは存在せず、しかも 1 件ごとに、すでに過負荷の機器でメモリーと検索時間を余計に消費します。

CISA、FBI、MS-ISAC の共同ガイド「Understanding and Responding to Distributed Denial-of-Service Attacks」は、攻撃をちょうど 3 つの手法に分けています。ボリューム型、プロトコル型、アプリケーション型です。この 3 分割がもっとも役に立ちます。4 つの資源のどれが狙われているかと、防御をどこに置く必要があるかを同時に表すからです。

DDoS 攻撃の 3 つのレイヤー

レイヤー 3 と 4 のボリューム型攻撃

ボリューム型攻撃がやりたいのは、標的の手前の回線を埋めることだけです。単位は毎秒のビット数です。手段はふつう UDP フラッドです。UDP には要求できるような接続確立の手順がなく、送信元アドレスは偽装できるからです。

公開されている記録のうち現時点で最大の例は次のものです。Cloudflare は 2025 年末までの期間について、31.4 Tbit/s の攻撃を自動で防いだと報告しています。継続は 35 秒でした。これは 1 Gbit/s のサーバー接続およそ 3 万 1400 本の容量が同時に、30 秒あまり続いたことに当たります。同じ報告には、ピーク値より規模を実感しやすい 2 つ目の数字があります。2025 年にこの同じ事業者が防いだ DDoS 攻撃は 4710 万件で、前年より 121% 増、平均で毎時 5376 件です。

より詳しく記録されている 2025 年 5 月の事例は、こうした攻撃を分解すると何が見えるかを示します。ピークで 7.3 Tbit/s、45 秒間で 37.4 テラバイト、平均で毎秒約 830 ギガバイトです。同じデータ量を 1 Gbit/s の回線で運ぶには 3 日あまりかかります。トラフィックの 99.996% は純粋な UDP フラッドで、同時に平均 2 万 1925、ピークで 3 万 4517 の宛先ポートに分散していました。この全ポートへの分散は典型です。攻撃側はどのポートが重要かを知らないので、全部を取ります。

プロトコル型攻撃：回線ではなくテーブルを狙う

プロトコル型攻撃は、カーネルが状態を覚えなければならないことを利用します。定番の例は SYN フラッドです。攻撃側は SYN ビットを立てた TCP パケットを、送信元アドレスを偽装して送ります。サーバーはその 1 つごとに、半開きの接続の待ち行列にエントリーを作り、一度も応答したことのないアドレスへ SYN-ACK を返し、待ちます。ここでの単位は毎秒のパケット数で、ギガビットではありません。

この待ち行列の長さは net.ipv4.tcp_max_syn_backlog にあり、通常のサーバーでは 4 桁です。1024 枠の待ち行列は、毎秒 149 万の SYN パケットなら 1 ミリ秒もかからず埋まります。計算上はそのために 1 Gbit/s で足り、テーブルだけが目的ならその一部で足ります。

同じ系統に、2021 年になって初めて記述された手口があります。状態を持つ中間機器を経由する TCP リフレクションです。論文「Weaponizing Middleboxes for TCP Reflected Amplification」は、TCP の状態を半分しか追っていないファイアウォールや検閲設備が、偽装された 1 つのパケットに対して丸ごと数ページ分の応答を返すことを示しました。これによって、それまで事実上不可能とされていた TCP の増幅利用も初めて可能になりました。

レイヤー 7 のアプリケーション型攻撃

アプリケーション型攻撃は通常のトラフィックに見えます。実際に通常のトラフィックで、量だけが違うからです。単位は毎秒の要求数です。完全に確立された接続で届くため、接続確立だけを評価する検査はすべてすり抜け、帯域幅もほとんど要りません。毎秒 1 万件の HTTP 要求は、要求の大きさによりますが 50 Mbit/s 未満であり、それでもデータベースを行き詰まらせるには十分です。

その基準になるのが HTTP/2 Rapid Reset で、2023 年 10 月 10 日に CVE-2023-44487 として公開されました。弱点は HTTP/2 の多重化にあります。攻撃側はストリームを開き、要求を送り、そのストリームをすぐに中断します。サーバーはすでに作業を始めていますが、攻撃側の側ではウィンドウの枠がただちにまた空きます。これで達した値は、毎秒 2 億 100 万要求（Cloudflare）、3 億 9800 万（Google）、1 億 5500 万（Amazon）でした。比較のために書くと、Cloudflare がそれまでに測ったレイヤー 7 攻撃の最大値は毎秒 7100 万要求でした。

ゲームサーバーでは、レイヤー 7 は接続確立そのものです。Minecraft のネットワークに対する Nullping、QuietException、偽のハンドシェイクフラッドは帯域幅をほとんど使わずに、プロキシの集まりを丸ごと止めます。パケット 1 つごとに、プロキシに費用の高い状態判断を強いるからです。これらのパターンが具体的にどう見えるかは Minecraft の DDoS 対策と Nullping 対策 にあります。

3 つのレイヤーの比較

実際の攻撃はこの区分を守りません。現場でもっとも厄介なのは多層の攻撃です。回線を占めるボリューム型の部分に、注意が帯域幅に向いた瞬間に通り抜けるレイヤー 7 の部分が加わります。この後に示す KernelHost で除去した攻撃のうち 1 件は、12 を超える異なる主要パターンが同時に走っていました。

増幅攻撃：1 バイトが 5.1 万バイトになる仕組み

増幅攻撃（Amplification）とは、攻撃側が自分で標的を撃つのではなく、外部の公開されたサービスに代わりに撃たせる攻撃です。攻撃側は開いているサービスに小さな要求を送り、送信元として被害者の IP アドレスを書き込みます。サービスは義務どおり応答しますが、宛先は被害者で、しかも応答は要求の何倍も大きくなります。

応答の大きさと要求の大きさの比を Bandwidth Amplification Factor、略して BAF と呼びます。BAF が 50 なら、自分の回線が 1 Gbit/s の攻撃側が標的へ 50 Gbit/s を向けられることを意味します。これが成り立つには 2 つがそろう必要があります。UDP の上で、聞かれた以上に答えるプロトコルと、送信元アドレスを偽装できることです。ですから IP スプーフィングは、どの増幅攻撃でも前提であり、単なる隠蔽の手口ではありません。

守る側にとっては、そこから厄介な性質が出てきます。トラフィックは本物の正当なサーバーから来ます。実在する DNS リゾルバー、実在する時刻サーバー、実在するゲームサーバーです。ですから送信元アドレスによる遮断リストは、国の半分を締め出すか、さもなければ効きません。

悪用されるプロトコルの増幅率

以下の値は、US-CERT すなわち CISA の警告 TA14-017A「UDP-Based Amplification Attacks」によるもので、2014 年以降も継続して拡充されています。業界全体が参照する基準です。

この表は、よく手入れされたファイアウォールでは遮断するポートの一覧が似てくる理由を説明します。ご自身でできることは限られますが重要です。ss -lnup で、この表にあるサービスがサーバー上でネットワークに開いていないかを確認してください。127.0.0.1 に束縛されていない memcached は、お使いのサーバーを第三者への武器に変え、ご自身の送信帯域幅を消費し、しかも抜け出しにくい遮断リストに IP アドレスを載せます。

ゲームの問い合わせプロトコルが仲間である理由

ゲームサーバーはこの表に 2 つの役で載っています。クエリポートが小さなパケットに対して、名前、マップ、プレイヤー数、Mod の一覧を丸ごと添えて応答するため、増幅器です。そして同じ問い合わせが計算時間を奪い、しかもそれがゲームのシミュレーションを担うコアであることが多いため、被害者でもあります。

Steam プロトコルの増幅率は 5.5 で低く、古い Quake プロトコルは 63.9 で高いです。ただし効き方は増幅率だけでは決まらず、個々の応答の大きさに左右されます。Mod が 200 個入ったサーバーは、入っていないサーバーよりはるかに大きな応答を返します。Bohemia Interactive は Arma 3 について、2015 年からチケット T83469 で、Steam のクエリポートへの偽装された問い合わせが 4 Mbit/s あればサーバーを停止させられたことを記録しています。毎秒 4 メガビットは、家庭用回線 1 本が出せる量より少ない値です。

ここから、どのゲームにも当てはまる原則が出てきます。クエリポートは制限するもので、閉じるものではありません。閉じればサーバーリストから消え、新しいプレイヤーには見つけられません。どのポートがそれに当たり、どこまで厳しく運用できるかは、この後に挙げるゲームごとの記事にあります。たとえば Arma 3、CS2 と Source 系タイトル、Rust です。

memcached の事例：GitHub への 1.35 Tbit/s

2018 年 2 月 28 日、GitHub は UTC の 17 時 21 分から 17 時 26 分まで到達不能で、17 時 30 分までは断続的にしかつながりませんでした。攻撃は 1.35 Tbit/s、毎秒 1 億 2690 万パケットに達し、1000 を超える異なる自律システムと数万の個別のエンドポイントから来ました。増幅には memcached が使われ、その率は最大 5.1 万です。攻撃側の 1 バイトが、標的に向けて最大 51 キロバイトを生みました。

この事例は今でも最良の教材です。3 つのことを同時に示すからです。第一に、増幅はボットネットの規模に勝ちます。攻撃側に 10 万台の機器は必要なく、必要だったのは開いた memcached のインスタンスで、当時は世界で 9 万を超える数がネットワーク上にありました。第二に、毎秒 1 億 2690 万パケットは、1 Gbit/s の回線がそもそも運べる量の約 85 倍です。サーバー上のどんな設定もこれを変えません。第三に、防御が働いたのはトラフィックがフィルタリング用のネットワークへ迂回されたからで、そのおかげで停止時間は 9 時間ではなく 9 分で終わりました。

DDoS 攻撃の能力はどこから来るのか

乗っ取られた機器で作るボットネット

ボットネットとは、悪意あるソフトウェアで乗っ取られた他人の機器の集まりで、攻撃側が中央からリモート操作します。所有者はふつう気づきません。機器は買った目的どおりに動き続けるからです。狙われるのは主に、常時ネットワークにつながり、めったに更新されず、初期パスワードのままの機器です。ルーター、監視カメラ、ネットワークレコーダー、テレビ用の端末です。

基準になるのは Mirai で、そのソースコードは 2016 年 9 月末に公開されました。論文「Understanding the Mirai Botnet」（USENIX Security 2017）はこのネットワークを 7 か月追い、最大時を 60 万台を超える感染機器としています。2016 年 9 月の Brian Krebs のサイトへの攻撃は 620 Gbit/s に達し、17.5 万台を超える機器から来ました。2016 年 10 月 21 日の DNS 事業者 Dyn への攻撃は Twitter、Spotify、Reddit を同時に到達不能にし、攻撃元の IP アドレスは約 10.7 万と数えられました。

9 年後、規模の桁が変わっています。Cloudflare は 31.4 Tbit/s の記録的な攻撃を、推定 100 万から 400 万台の感染機器からなるボットネットに帰しており、その多くは Android のテレビ用の端末です。2025 年 12 月の攻撃の波では、超ボリューム型の攻撃が 902 件、平均で 1 日 53 件数えられ、ピーク値は毎秒 90 億パケット、24 Tbit/s、毎秒 2 億 500 万要求でした。つまり 10 年のうちにボットネットの規模は 5 倍、達成された帯域幅は 50 倍になりました。

booter と stresser のサービス、そして攻撃の値段

ボットネットと依頼者のあいだには、攻撃の能力を定額で売るサービスがあります。こうしたサービスは「booter」「stresser」「IP stresser」として現れ、利用規約では自分のシステムの負荷試験のためだと主張します。しかし入力された標的が利用者のものかどうかを検証することはなく、まさにそこが道具と商品の違いです。

操作は入力欄が 3 つあるウェブ画面です。標的、ポート、継続時間です。支払いの手順も、顧客対応も、再販業者向けの制度もあります。入口の料金は月に 10 から 20 ユーロほど、帯域幅が大きく攻撃の継続時間も長い上位の料金は月に数百ユーロです。これで、小さなプロジェクトまで狙われる理由の答えが出ます。ゲームサーバーの土曜の夜を奪う攻撃は、仕掛ける側にとって映画のチケット 2 枚より安く、技術の知識も要りません。

反対側には、途切れない摘発の圧力があります。2026 年 4 月の国際的な作戦 PowerOFF の集中週間では、21 か国の当局がこうしたサービスの 53 のドメインを押収し、4 名を逮捕し、25 件の家宅捜索を行いました。その際に捜査側は 300 万件を超える利用者アカウントのデータにアクセスし、身元が判明した 7.5 万人を超える利用者に通知が送られました。2024 年 12 月には同じ作戦で 27 のプラットフォームが停止されています。つまりこうしたサービスに支払う人は、遅かれ早かれ押収されるデータベースに、支払いの足跡を残します。

DDoS 攻撃をどこで見分けるか

利用者の報告から何が分かるか

最初の情報はほぼ必ず利用者から来ます。そして聞こえより役に立ちます。次の 4 つの報告には明確な意味があります。

• 「全員が同時に落ちた」全利用者の同時の切断は、個々の接続ではなく回線かサービスのプロセスを指します。負荷の問題なら、利用者は順に落ちます。
• 「ping が 20 から 400 に跳ねて戻る」接続は続いたまま応答時間が揺れるのは、過負荷のプロセスではなく、標的の手前で待ち行列があふれているパターンです。
• 「サーバーリストではオフラインなのに、自分は接続できる」これはクエリフラッドの手がかりです。クエリポートが応答しなくなり、ゲームポートはまだ応答しています。
• 「携帯回線なら入れるが、自宅の回線では入れない」接続元のネットワークによって挙動が違うのは、お使いのサーバーではなく、そこへ至る経路のどれかが飽和している印です。

サーバーで測る 4 つの値

そのあと測定します。順番はこうです。パケットレート、帯域幅、接続の状態、破棄パケットのカウンター。CPU の使用率表示は最後です。ネットワークへの攻撃では目立たないままのことが多いからです。

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

sar -n DEV 1 10 は、インターフェースごとの毎秒のパケット数とバイト数を 10 秒間にわたって示します。決め手は比率です。バイト数が少ないのにパケットが多ければ小さなパケット、つまりプロトコル型攻撃です。パケットが少ないのにバイト数が非常に多ければ大きなパケット、つまり増幅攻撃です。ip -s link show は dropped と overrun の列で、カーネルがすでに破棄しているかを示します。ss -tn state syn-recv は半開きの接続を数えます。3 桁なら平常で、5 桁なら SYN フラッドです。そして nstat は、攻撃が終わったあとも残るカウンターを出します。

もっとも大事な手順は、事前にほとんど誰もやらないものです。すべてが平常に動いているあいだに基準値を取ることです。平常時の値がなければ、毎秒 4 万パケットが多いのか、それとも単に土曜の夜なのかを言えません。apt-get install -y vnstat sysstat で測定は常時走り続けます。読み方の詳しい手順は DDoS 攻撃を検知する にあります。

決定的なログの行

カーネルのログとウェブサーバーのログにある 4 つのメッセージは、事実上の証拠になります。最初の 3 つは dmesg -T | tail -50 で見えます。

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

1 行目は、半開きの接続の待ち行列があふれ、カーネルが SYN cookie に切り替えたことを意味します。そこに代わりに Dropping request と出ているなら net.ipv4.tcp_syncookies が 0 で、サーバーは本物を含めて要求を破棄しています。2 行目は接続追跡が満杯になったことを意味し、この瞬間から正当なトラフィックも破棄されます。3 行目は副作用です。カーネルがメッセージを抑えています。そうしなければログの書き出しに追われるからです。4 行目は問題をアプリケーションへ移します。

ウェブサーバーのアクセスログでは、2 つが物を言います。ステータスコード 499 の割合が急に増えるのは、応答が終わる前にクライアントが接続を閉じていることを意味します。作業だけを起こさせて読む気のないレイヤー 7 攻撃が、まさにこれをします。そしてほぼすべての要求でリファラーの欄が空なら、検索エンジンやソーシャルネットワークからのリファラーを伴う本物のアクセス急増とは区別できます。

裏取り：攻撃か、アクセス急増か、自分のミスか

サーバー自身で効くこと

サーバー上でできることは、よく言われるより多くあります。規模が小さいままのものすべてに効きます。作りの粗いボット、単一の発信源、クエリフラッド、アプリケーション型攻撃です。道具は nftables、接続追跡、SYN cookie、そして送信元アドレスごとのレート制限です。以下の記述はすべて Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS を対象とし、root 向けに書かれています。

nftables：早く破棄し、計算を少なくする

原則はこうです。破棄されるパケットは、できるだけ早く、できるだけ安く破棄する。その手前で走るルールはどれも、計算時間にパケットレートを掛けた費用になります。次の /etc/nftables.conf 向けのルールセットは、ウェブサーバーとゲームのサービスを通し、残りを破棄します。あわせて、送信元アドレスごとに新しい TCP 接続のレート制限をかけます。

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

読み込む前に adminips にご自身の固定アドレスを入れてください。そうしないと SSH から自分を締め出します。確認と有効化はこうします。

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

効果を決めるのは 3 点です。ct state established,related accept を意図して 2 番目のルールに置くのは、既存の接続がルールセット全体を通らないようにするためです。ct state invalid counter drop は、不正なフラグの組み合わせと遅れて届いた分割パケットを、1 つずつ書かなくても取り除きます。そして drop の前に置く counter は、あとでどのルールが効いたかを知るための仕掛けです。カウンターが 0 のままなら、そのルールには届いていません。これは効かないルールセットとはまったく別の診断です。

SYN cookie とバックログの限界

SYN cookie は、サーバーが半開きの接続を覚えず、必要な情報を暗号化して自分の応答番号に書き込む方式です。接続確立の 3 つ目のパケットが戻ってきたら、そこから状態を計算し直します。これで待ち行列はあふれません。これらの接続には待ち行列が存在しないからです。

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

これらの値は /etc/sysctl.d/ の下のファイルに入れ、sysctl --system で反映します。そうしなければ次の再起動で消えます。Debian と Ubuntu では tcp_syncookies が出荷時の状態で 1 になっており、これは正しい設定です。値 1 は「常に cookie」ではなく「待ち行列があふれたら cookie」を意味します。

その代償は現実にあり、めったに語られません。cookie には相手側の TCP オプションを入れる場所がありません。Linux がウィンドウスケーリングと選択的確認応答を救えるのは net.ipv4.tcp_timestamps が 1 のときだけで、そのとき情報がタイムスタンプに同乗するからです。タイムスタンプがなければ失われ、接続はその寿命が尽きるまで遅く動きます。さらに最大パケットサイズには 3 ビットしか使えないため、正確な値ではなく 8 段階の粗い区分になります。SYN cookie は接続を救う非常時の仕組みで、平常時の設定ではありません。

conntrack：最初に満杯になるテーブル

カーネルの接続追跡は、パケットの流れごとにエントリーを作ります。UDP に接続はありませんが、UDP についても作ります。分散した攻撃では、まさにこのテーブルが最初に尽きる資源で、しかも尽きるのが非常に速いです。毎秒 149 万パケットがそれぞれ新しい送信元アドレスを持つなら、26 万 2144 枠のテーブルは 5 分の 1 秒もかからず埋まります。

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

エントリー 1 件はおよそ 300 バイトを占めるため、52 万 4288 件でカーネルのメモリーを約 150 メガバイト使います。ハッシュテーブルの大きさは sysctl ではなくモジュールのパラメーターで設定し、通常は上限の 4 分の 1 にします。場所は /etc/modprobe.d/nf_conntrack.conf です。

options nf_conntrack hashsize=131072

ゲーム専用またはボイス専用のサーバーなら、ゲームトラフィックをそもそも追跡させないほうが洗練された解です。テーブルを丸ごと節約できます。

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

注意してください。notrack と状態を使うルールは両立しません。あるポートを追跡から外したら、そのポートに ct state を含むルールは使えません。使えば許可が効かなくなり、サービスは閉じたままになります。

送信元アドレスごとのレート制限

送信元アドレスごとのレート制限は、サーバー上で単独の対策としてもっとも効きます。攻撃側がやることにぴったり当たり、利用者がやることをぴったり通すからです。差は大きいです。本物のサーバーブラウザーは 1 分に数回問い合わせますが、攻撃側は毎秒数百回です。nftables では上のルールセットのように動的なセットを使い、従来の iptables では hashlimit を使います。

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP

こうしたルールの数値はどれも出発点で、真理ではありません。まず平常運転で 1 週間測ってください。そうしないと、しかも最悪の瞬間に、自分の利用者を追い出します。さらに、iptables だけのルールは再起動で消えること（apt-get install -y iptables-persistent のあとに netfilter-persistent save）、そして UFW のもとでは /etc/ufw/before.rules に置くこと（そうしないと次の ufw reload で消えます）にも注意してください。運用に使う完全なルールセットは サーバーを DDoS 攻撃から守る にあります。

サーバー上のフィルタリングが限界を迎える地点

ここからは、どの設定ファイルでも解けない部分です。ここまでの対策はすべてお使いのサーバー上、つまり回線の端で動きます。ファイアウォールのルールが判断するのは、すでにケーブルを通り終えたパケットです。破棄はできますが、送られなかったことにはできません。その手前の回線が埋まっていれば、利用者のパケットはそこより先へ進めません。ルールセットの出来とは無関係です。

この表は、自力の防御で足りるのかという問いに、個々の場合ごとに答えます。毎秒 1 億 2690 万パケットの GitHub への攻撃は、パケットレートなら 100 Gbit/s の接続 1 本にぎりぎり収まりますが、1.35 Tbit/s の量には同時に 14 本必要になります。31.4 Tbit/s の記録的な攻撃は、100 Gbit/s の接続を 314 本、完全に飽和させた量に当たります。ゲームサーバーはふつう 1 Gbit/s か 1 Gbit/s が 2 本につながっています。つまり自力の防御の限界は毎秒およそ 150 万から 300 万パケットで、実際にはそれよりはるかに手前です。カーネルが先に音を上げるからです。

もう 1 つ、さらに厄介な限界があります。回線が飽和すると、測定に使おうとした SSH の接続さえ届かないことがあります。そのときネットワークに依存しない接続手段、たとえばカスタマーエリアの VNC コンソールがなければ、何が起きているかを見ることさえできません。

サーバーの手前でしか効かないこと：ネットワークでのフィルタリングとスクラビング

有効にフィルタリングできるのは、攻撃より大きな容量を持つ側だけです。そのためには多くの回線が集まる場所、つまり 1 台のマシンではなくネットワークが必要です。そこには互いを補う 2 つの方式があります。

ネットワークでのリアルタイムフィルタリング。すべてのトラフィックが常にフィルタリングの段を通り、サーバーへ渡す前にパケット 1 つずつを評価します。利点は切り替えがないことです。保護が効くために、まず攻撃を検知する必要がありません。ゲームではまさにここが決め手です。切り替え時間が 2 分なら 1 ラウンドは失われますし、35 秒で終わる攻撃に対する 2 分の切り替え時間は、そもそも防御ではありません。

スクラビング。ネットワークが大きなボリューム型攻撃を検知すると、該当するトラフィックはフィルタリングの拠点へ迂回され、そこで有害な部分を取り除かれ、そのうえで標的へ届けられます。この迂回の意味は近さです。攻撃トラフィックは、データセンターまで来てから終わるのではなく、入ってきた場所で終わります。そのためにフィルタールールはネットワーク内に配られます。技術的には RFC 8955 で Flow Specification として記述されています。

なお、偽装された送信元アドレスに対する構造的な対策は 2000 年から知られており、RFC 2827、すなわち BCP 38 にあります。顧客を接続する側が、その境界で、送信元アドレスがその顧客に属さないパケットをすべて破棄するというものです。RFC 3704 はこれを複数の接続を持つネットワークへ広げます。すべての回線事業者がこれを実装していれば、増幅攻撃という種類は丸ごと片づいていました。片づいていないのは、一部が実装しないだけで足りてしまうからです。

そして 3 つ目の方法があります。しばしば保護として売られるため、知っておく必要があります。ヌルルーティング、技術的には RFC 5635 の Remote Triggered Black Hole Filtering です。攻撃を受けた IP アドレスをネットワーク内で到達不能として広告し、そのアドレス宛てのトラフィックをすべて破棄します。攻撃トラフィックも、利用者のトラフィックも同じです。これは事業者のネットワークを守りますが、ご自身にとっての結果は攻撃の成功と同じで、しかもたいていその後も数時間続きます。迷うときは、フィルタリングするのかヌルルーティングするのかを尋ねてください。その答えは、どんなハードウェアの記載よりも可用性を左右します。

KernelHost が用意している対策

すべてのサーバープランに含まれる常時保護

KernelHost の DDoS 対策は 2 段階で構成されており、有効化も注文も設定もなしに常時動いています。

• 第 1 段階：グローバルなスクラビングネットワークにおける 17 Tbps の緩和能力。 ボリューム型攻撃は、データセンターに届く前に、発生源の近くで除去されます。
• 第 2 段階：フランクフルトにおける 3.2 Tbps の Arbor リアルタイムフィルタリング。 サーバーの直前で、プロトコル固有のパターンを検知し、パケット単位で破棄します。

決定的な性質が 2 つあります。保護は常時動いており、サーバーの提供開始時点から有効です。つまり攻撃の最初の数分だけサービスが落ちている、ということが起きません。そしてヌルルーティングは使いません。お使いの IP アドレスはネットワークに残り、破棄されるのは有害なパケットだけです。どのゲームとプロトコルが専用のフィルタープロファイルを持つかは ゲームサーバーの DDoS 対策をリアルタイムで にまとめています。

継続的に攻撃されるプロジェクト向けの Advanced DDoS Protection

プロジェクトによっては、たまたまではなく狙って何週間も、毎晩同じ時刻に、パターンを変えながら攻撃されます。そのために Advanced DDoS Protection があり、月額 50.00 EUR から、PrePaid、最低利用期間なし、初期費用なしで利用できます。違いは容量の大きさではなく、制御できることにあります。

• 専用の保護 IP をフランクフルトの中核から割り当て、お使いのサーバーを当社のネットワーク内で切り替えます。ご自身の側で作り直す作業はありません。
• ポートとプロトコルごとに自分で管理できる保護ルールをカスタマーエリアで設定できます。ゲームポートで何を許可するか、クエリポートで何を許可するかを分けて指定できるため、問い合わせプロトコルの節で説明した非対称性をそのまま利用できます。
• 変更はリアルタイムで反映されます。そのため、メンテナンス枠を待つのではなく、攻撃が進行している最中に調整できます。
• サービスに合わせた保護プロファイルを用意しており、改造したアプリケーションや独自のアプリケーションを任意の TCP または UDP ポートで動かす場合にも対応します。

Advanced DDoS Protection は KernelHost で動いているサーバー向けで、KernelHost にサーバーがあることが前提です。プロジェクトを現在よそで動かしていて、そこで定期的に攻撃を受けているなら、こちらへの移設が道であり、これまでのアドレスを遠隔で面倒を見る形ではありません。

2 つの段階の比較

運用中に実際に除去した 4 件の攻撃

次の 4 件の攻撃は KernelHost のサーバーに当たり、いずれも障害なしで、リアルタイムで完全に除去されました。図は防御のライブ監視から取ったものです。

TeamSpeak 3 のボイスサーバー、9987 UDP。複数のパターンが同時に走る複雑な攻撃で、473.4 Gbit/s 超、毎秒 4150 万パケット超です。これは 1 Gbit/s の接続のパケットレートの約 28 倍です。

ARK のゲームサーバー、7777 UDP。構造の複雑さはない単純な UDP フラッドですが、112.2 Gbit/s 超、毎秒 870 万パケット超です。ARK のクラスターを自分でどう固めるかは ARK サーバーを DDoS 攻撃から守る にあります。

全ポート攻撃、0-65535 の TCP と UDP。12 を超える異なる主要パターンが全ポートに対して同時に走り、合計で 21.3 Gbit/s 超、毎秒 390 万パケット超です。この事例は、平均 2 万 1925 の宛先ポートを示した 2025 年 5 月の Cloudflare の事例と同じ、全ポートへの分散を見せています。

Minecraft と OpenVPN、25565 TCP と 1194 UDP。16 を超える異なる主要パターンを組み合わせた攻撃で、毎秒 400 万パケット超、8.6 Gbit/s 超です。2 つのサービスは異なるプロトコルを話すにもかかわらず、どちらも終始到達可能でした。

攻撃を受けたときにやること、この順番で

個々の手順よりも順番が重要です。もっとも多い誤りは最初の 5 分で起きるからです。

1. 設定をいじるのではなく測定する。まず sar -n DEV 1 10、ip -s link show、ss -s、dmesg -T の値をファイルに保存してください。攻撃が終わればもう残っておらず、それがなければ誰も助けられません。
2. 再起動しない。再起動はすべてのカウンター、すべての接続状態、あらゆる証拠を消します。しかも負荷は数秒後に戻ります。
3. どのレイヤーかを確定する。バイト数をパケット数で割ると平均パケットサイズが出ます。100 バイト未満ならプロトコル型攻撃、1000 バイト超なら増幅攻撃、大きさが平常で CPU 負荷が高ければレイヤー 7 です。
4. 管理用のポートを閉じる。パネル、データベース、RCON、そして公開する必要のないものはすべて、ご自身のアドレスだけに限定します。これは攻撃対象領域をすぐに、しかも利用者への危険なしに小さくします。
5. レート制限をかける。クエリポートには厳しく、実際に使うポートには緩く。クエリポートは閉じないでください。閉じればあらゆるサーバーリストから消えます。
6. 自分のアドレスを急いで変えない。アドレスの変更が効くのは、新しいアドレスがまた公開されないあいだだけです。忘れられた古い DNS レコードが 1 つあれば、変更は無意味になります。
7. 数字を添えて事業者に相談する。時刻、宛先ポート、パケットレート、帯域幅、平均パケットサイズを書いてチケットを開いてください。この 5 つの情報が、お使いのアドレス向けにフィルタールールを調整する速さを決めます。
8. そのあと記録する。いつ始まり、どれだけ続き、どのパターンだったかを残してください。同じ時刻に繰り返される攻撃は、そのプロジェクトに専用の保護 IP が必要かどうかの判断材料になります。

長く続く深刻な攻撃の詳しい手順は 深刻な DDoS 攻撃を受けたらどうするか にあります。

法的な位置づけ：DDoS 攻撃は犯罪です

オーストリアでは、DDoS 攻撃は刑法（StGB）第 126b 条「コンピューターシステムの機能の妨害」に当たります。基本の構成要件では 6 か月以下の自由刑、または 360 日分以下の罰金刑が定められています。妨害が長く続いた場合は 2 年以下です。そのために作られたと分かるプログラムで多数のシステムを攻撃した場合は 3 年以下です。そして損害が 30 万ユーロを超える場合、重要インフラへの攻撃の場合、または犯罪組織の構成員としての場合は、6 か月以上 5 年以下という枠になります。あわせて刑法第 126c 条は、そのために用いるプログラムの製造、流布、提供の段階ですでに処罰の対象としています。

ドイツでは刑法（StGB）第 303b 条「コンピューター妨害」が適用されます。3 年以下の自由刑または罰金刑、そのデータ処理が事業所、企業、官庁のためのものである場合は 5 年以下、そして営利的な行為や重要インフラへの侵害など特に重い場合は 6 か月以上 10 年以下です。未遂も処罰され、予備的な行為については刑法第 303b 条第 5 項が第 202c 条を参照しています。

ですから booter と stresser のサービスはグレーゾーンではなく、犯罪の有料の一部です。ここでは 3 点が繰り返し誤解されています。第一に、「自分のシステムの負荷試験のためだけ」という注記は何も合法にしません。これらのサービスは、入力された標的が誰のものかを検証しないからです。第二に、処罰されるのは運営者だけでなく依頼者も同じです。Europol は 2026 年 4 月の集中週間のあと、まさにそれをはっきりさせるために、身元が判明した 7.5 万人を超える利用者へ明示的に通知を送りました。第三に、こうしたサービスを使って自分のサーバーへ負荷試験をかけることも解決策ではありません。攻撃トラフィックが事業者のネットワーク、つまり他の利用者の回線を通るためで、これはどのホスティング契約でも禁じられています。サービスの耐久性を本当に測りたいなら、事前に告知し、事業者と取り決めたうえで行います。本節は法律の状況を紹介するものであり、法律上の助言ではありません。

お使いのサービスに合ったガイド

本記事は原理を説明するものです。どのポートを開けるべきか、どの設定の指定がどの問い合わせを制限するか、そのゲームでの限界はどこか。それはサービスごとの記事にあり、いずれもポートの事実をまとめた表を備えています。

• 基礎と手順：DDoS 攻撃を検知する、サーバーを DDoS 攻撃から守る、深刻な DDoS 攻撃を受けたらどうするか、リアルタイムフィルタリングによるゲームの DDoS 対策
• Minecraft とボイス：Minecraft と Nullping、Minecraft Bedrock、TeamSpeak 3、Hytale
• GTA を土台にしたロールプレイ：FiveM、RedM、RAGE MP と alt:V、SA-MP と open.mp、MTA:SA
• サバイバルと建築：Rust、ARK、DayZ、Palworld、Conan Exiles、Project Zomboid、Terraria、Unturned
• タクティカルとシューティング：CS2 と Source、Arma 3、Call of Duty、Team Fortress 2、Left 4 Dead 2、Garry's Mod、Mordhau、Lineage 2

まとめ

• DDoS 攻撃は、有限な 4 つの資源のうち 1 つを埋めます。帯域幅、パケットレート、カーネルの状態テーブル、アプリケーションの計算時間です。脆弱性を突かないため、更新だけでは守れません。
• RFC 4732 は DoS 攻撃を、発信源の数ではなく効果によって定義しています。分散と呼ぶのは発信源が多いときで、2025 年 5 月の Cloudflare の事例では 161 か国の 12 万 2145 のアドレスでした。
• CISA、FBI、MS-ISAC は 3 つの手法を区別します。Gbit/s で測るボリューム型、毎秒のパケット数で測るプロトコル型、毎秒の要求数で測るアプリケーション型です。それぞれに別の防御が必要です。
• 増幅攻撃は開いた UDP サービスを悪用します。その率は Steam プロトコルの 5.5、SSDP の 30.8、NTP の 556.9 から memcached の 5.1 万までで、US-CERT の TA14-017A で確認できます。
• 能力は乗っ取られた機器のボットネットから来ます。2016 年の Mirai の 60 万台から、31.4 Tbit/s の記録的な攻撃の背後にある推定 100 万から 400 万台までで、月に 10 ユーロほどから再販されています。
• サーバー上では nftables、SYN cookie、調整した conntrack の上限、送信元アドレスごとのレート制限が効きます。これらは毎秒約 150 万パケットで終わります。1 Gbit/s の接続がそれ以上運べないからです。
• この限界より上では、サーバーの手前のネットワークでのフィルタリングだけが決め手になります。ヌルルーティングは防御ではなく、攻撃側が望んだ結果そのものです。
• KernelHost では、2 段階の常時保護がすべてのサーバープランに追加料金なしで含まれ、提供開始時点から有効で、ヌルルーティングは行いません。グローバルなスクラビングネットワークにおける 17 Tbps の緩和能力と、フランクフルトにおける 3.2 Tbps の Arbor リアルタイムフィルタリングです。Advanced DDoS Protection は月額 50.00 EUR から、専用の保護 IP とポートごとに自分で管理できるルールを追加します。
• DDoS 攻撃はオーストリアでは刑法第 126b 条、ドイツでは刑法第 303b 条により処罰されます。サービスの運営者だけでなく、依頼者も同じです。

プロジェクトをすでに KernelHost で動かしている場合、フィルタリングは何もしなくても有効です。それでも異常に気づいたときは、手順 7 の 5 つの情報を添えて サポートチケット を開いてください。お使いの IP アドレス向けにフィルタールールを調整します。攻撃が進行中の場合は、WhatsApp の緊急チャット +43 650 8209883 でもご連絡いただけます。