Minecraft Bedrock サーバーを DDoS 攻撃から守る

夜になると数分だけサーバーリストから消え、そのあと戻ってくる Minecraft Bedrock サーバーに、ハードウェアの問題があることはまずありません。多くの場合は攻撃が走っており、しかもプレイヤーがいちばん多くオンラインになっている時間帯に走ります。本記事では、Minecraft Bedrock サーバーを DDoS 攻撃から守る手順を示します。まず追加費用なしでご自身で固められる範囲、次にその対策が物理的にどこで限界を迎えるか、最後にサーバーの手前のネットワークで何が起きる必要があるかです。

本記事の記述はすべて、Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS 上で動く Bedrock Dedicated Server、PocketMine-MP、Nukkit を前提としています。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。Java Edition を運用している場合、そちらで典型的なプロトコル攻撃は Minecraft の DDoS 対策と Nullping 対策 にまとめています。Bedrock サーバーのインストールそのものは Nukkit で Minecraft Bedrock サーバーをインストールする が解説しています。

攻撃がいま進行中の場合：設定は何も変更せず、サーバーも再起動しないでください。まず「事が起きる前に測定値を集める」の節にある測定値を保存してください。攻撃が終わってからでは、取り返しようがありません。

Minecraft Bedrock サーバーが DDoS 攻撃の標的になりやすい理由

Bedrock Edition は、コンソール、スマートフォン、タブレット、Windows で動くバージョンで、Minecraft のなかで最も大きなプレイヤー層を抱えています。サーバーが多い場所には、攻撃の動機もいちばん多く生まれます。競合するネットワーク、BAN されたプレイヤー、内部のもめ事です。しかも攻撃を仕掛ける側には、技術もまとまった金額も必要ありません。サーバー向けの booter は月額契約で売られています。

技術的な理由はもっと深いところにあります。Bedrock サーバーが話すのは UDP で、TCP ではありません。そして、何らかの認証が行われるよりずっと前に、問い合わせてきた相手すべてに応答します。この 2 つの性質がそろっていることが、ポート 19132 UDP を都合のよい標的にしています。DDoS 攻撃が具体的に何であるかは、記事 DDoS 攻撃とは何か で解説しています。

RakNet：誰も認証を済ませていない段階で応答する UDP プロトコル

RakNet とは、Minecraft Bedrock Edition がゲームトラフィックのすべてを流している UDP のネットワークライブラリです。UDP にはサーバーが要求できるような接続確立の手順がなく、そのため送信元アドレスは偽装できます。RakNet はその上に独自の信頼性の層を作ります。シーケンス番号、確認応答（ACK）、そしてクライアントが失われたパケットを再要求するための否定応答（NAK）です。

接続確立は 7 つのパケットで構成され、4 つがクライアントから、3 つがサーバーからです。

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

クライアントが Xbox Live の資格情報を含むログインパケットを送るのは、そのあとです。Bedrock サーバーを固めようとする人にとって決定的なのは、次の一文です。サーバーは、誰が来たのかを知る前に、すでに 7 つのパケットを処理し、計算時間とメモリーを費やし、何度も応答を返しています。つまり、認証の段階に働きかける対策はどれも、負荷が発生したあとになって初めて効きます。

さらに、もっと手前にある 2 つ目の入り口があります。プレイヤーのサーバーリストに名前、バージョン、プレイヤー数が表示されるために、サーバーは Unconnected Ping（パケット ID 0x01）に Unconnected Pong（パケット ID 0x1C）で応答します。このやり取りは本来の接続確立より前に行われ、いかなる資格情報も要求せず、Bedrock Dedicated Server ではサーバーをあらゆるサーバーリストから外すことなしに止められません。

増幅の経路としての Unconnected Ping：具体的な数字

増幅攻撃（Amplification）とは、攻撃側が送信元アドレスを偽装した小さな要求を第三者のサーバーに送り、その大きな応答を標的に届かせる攻撃です。このとき Bedrock サーバーは攻撃されているのではなく、使われています。Unconnected Ping では、計算が次のようになります。

ここから 2 つのことが直ちに導かれます。第一に、長いサーバー名は応答を大きくし、それによって第三者の攻撃側に提供してしまう増幅率も大きくします。短い名前は見た目の問題ではなく、ひとつの対策です。第二に、初期設定の増幅率 4 は、お使いのサーバーが反射の相手として魅力的にならない程度には小さいものの、ping のあふれがご自身の上りの回線に、入ってくる量の 4 倍を負わせる程度には大きいということです。

2024 年の増幅不具合は、信頼性の層そのものが悪用されたときにどこまで悪くなるかを示しています。当時使われていた RakNet ライブラリでは、Connection Request Accepted のパケットが信頼性ありと設定されていました。攻撃側は送信元アドレスを偽装したまま、この時点まで接続確立を進め、そのあと 0 から 8191 の範囲を指定した否定応答を 1 つだけ送ります。サーバーはそれを受けて、偽装されたアドレスに数千のパケットを送りました。攻撃側はそれ以上何もする必要がありません。修正は 3 つの変更で行われました。このパケットを信頼性なしに切り替えること、Open Connection Reply 1 で、本物のクライアントが返してくるクッキーを一緒に送ること、そしてパケットの上限を設けることです。上限は、送信元アドレスごとに 10 ミリ秒の周期あたり 120 パケット、全体で 1 周期あたり 1000 パケットです。

Bedrock Edition と Java Edition：DDoS 対策で違うところ

Java のサーバーを固めた経験がある人は、ほとんどすべてを取り違えて当てはめてしまいます。この 2 つのエディションは名前を共有していますが、ネットワークプロトコルは共有していません。

最も重要なのは SYN Cookie の行です。Java Edition では Linux のカーネルが SYN のあふれを防ぎ、Minecraft のプロセスはそれに気づきもしません。Bedrock Edition にはこの助けがありません。UDP パケットは 1 つずつサーバープロセスまで通され、そこで評価されます。Bedrock サーバーには、ポート 19132 へのフラッドに効く、オペレーティングシステム組み込みの保護がありません。UDP がそれを持たないからです。

SRV レコードがないという行には、多くの人が意外に思う実際上の結果があります。Bedrock Edition では、ポートを DNS のエントリーの後ろに隠せません。プレイヤーはアドレスとポートを手で入力します。ポートを移した人は、新しいポートをプレイヤー全員に伝える必要があります。

実際に問題になるポート

Bedrock Dedicated Server がバインドするのはちょうど 2 つのポートで、どちらも UDP です。server.properties では次のようになります。

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

これは Microsoft の初期設定で、Bedrock Dedicated Server のリファレンスに記載されています。この 2 つのポートの周りには、サーバーソフトウェアによって一緒に動くサービスがさらに並びます。

3 行目と 4 行目が、Bedrock サーバーで最も多い、避けられるはずの失敗です。Nukkit と PocketMine-MP では enable-query が出荷時から有効で、Nukkit ではうっかり有効にした RCON が 19132 TCP に載ります。つまりゲームと同じポート番号です。「19132 は開いている、それで問題ない」としか見ない人は、これを見落とします。

公式の Bedrock Dedicated Server の性質も、ここに挙げておきます。このサーバーには server-ip というディレクティブがありません。PocketMine-MP と Nukkit は持っていますが（server-ip、PocketMine ではさらに server-ipv6）、公式のサーバーは持っていません。つまり常にシステムのすべてのアドレスで待ち受けており、それを制限する手段はファイアウォールだけです。

費用をかける前に自分でできること

この節が最も長いのは意図的です。きちんと設定された Bedrock サーバーは、どこに置かれていようと、小規模から中規模の攻撃を自力で耐えます。

1. 現状把握：19132 で何が待ち受けているか

ルールを 1 つ書く前に、お使いのサーバーが外に何を提供しているかを確認します。推測せず、実際に見てください。

ss -lntup
ss -lnup sport = :19132

注目するのはローカルアドレスの列です。0.0.0.0:19132 と [::]:19133 は「インターネット全体から到達できる」という意味です。その横に同じポート番号の TCP のエントリーが現れたら、RCON が動いています。攻撃側からの見え方は、外部からのポートスキャンで分かります。UDP には -sU を使います。

nmap -Pn -sU -p 19132,19133 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. 19132 UDP だけを開け、ほかはすべて閉じる

Bedrock サーバーには外に向けた許可が 1 つで足り、IPv6 を含めても 2 つです。UFW では次のようになります。自分自身を締め出さないよう、この順番どおりに実行してください。

ufw allow 22/tcp comment 'SSH'
ufw allow 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

IPv6 のプレイヤーがいない場合は 19133 の行を省き、PocketMine-MP ではさらに enable-ipv6=false を設定します。開けないポートは、守らなくてよいポートです。復旧手段まで含む詳しい手順は 自分を締め出さずに UFW ファイアウォールを設定する にあります。

3. LAN での可視性を切らないと、19132 は開いたままになる

これは、ポートを移そうとする人のほぼ全員がはまる罠です。ディレクティブ enable-lan-visibility は出荷時に true になっており、ローカルネットワークでの検索要求にサーバーが応答するようにします。Microsoft はこれについて、サーバーがそれによって標準ポートの 19132 と 19133 にも追加でバインドし、server-port と server-portv6 に別の値が入っていてもそうなると明記しています。

つまり、ポートを 19140 に移して安心している人は、引き続き 19132 で待ち受けています。インターネット上のサーバーでは、したがって server.properties に次の記述が必要です。

enable-lan-visibility=false

そのあと ss -lnup で、19132 が本当に消えたことを確認してください。ついでに同じ設定は、同じホスト上の 2 つの Bedrock サーバーが互いにポートを奪い合う問題も解決します。

4. クエリと RCON を無効にする

PocketMine-MP と Nukkit には GS4 クエリが付いています。これは UT3 プロトコルの流儀に沿った UDP のサーバー問い合わせで、この問い合わせにゲームが動いているのと同じポート 19132 で応答します。詳細な応答にはサーバー名、バージョン、ワールド名、許可リストの状態、アドレスとポート、プレイヤー数、接続しているプレイヤー全員の名前が含まれ、PocketMine-MP では希望すればプラグインの一覧も丸ごと含まれます。ステータスページや Discord ボットには便利ですが、攻撃側にはいつ攻撃する価値があるかを正確に教えてしまい、問い合わせ 1 件ごとに計算時間もかかります。

enable-query=off
enable-rcon=off

PocketMine-MP では値が off ではなく false で、プラグインの一覧は pocketmine.yml の settings.query-plugins: false で無効にします。あまり書かれていない位置づけも添えておきます。PocketMine-MP の GS4 クエリは、送信元アドレスで salt を付けたトークンを検査します。したがって、あの大きな応答を偽装したアドレスに反射させることはできません。それでも問い合わせは計算時間を使い、公開されるデータは攻撃側の標的選びを助けます。公式の Bedrock Dedicated Server はクエリも RCON も持たないため、そこではこの項目がなくなります。

RCON が実際に必要な場合は、Nukkit では必ず rcon.port に独自の値を設定し、ご自身のアドレスだけに許可してください。そうしないと server-port への戻りによって、お使いのサーバーの遠隔操作が 19132 TCP で待ち受けることになります。つまり、どこでも「開いている」と書き込んできたのと同じ数字の上です。

5. Xbox Live 認証を強制する

Xbox Live 認証とは、参加してくるプレイヤーが Microsoft の署名が付いた本物のアカウントを持っているかを検査する仕組みです。3 つのサーバーソフトウェアすべてで出荷時から有効になっており、そのままにしておくべきものです。

Bedrock Dedicated Server ではディレクティブの名前が online-mode、PocketMine-MP と Nukkit では xbox-auth です。どちらの場合も true が出荷時の状態であり、正しい値です。

online-mode=true
xbox-auth=true

Microsoft はこれについて重要な留保を付けています。ローカルネットワークの外にあるサーバーに接続するクライアントは、この設定と無関係に、いずれにせよ常に Xbox Live 認証を必要とします。資格情報は署名されたトークンの連なりとしてログインパケットで送られ、Xbox の識別子（XUID）と表示名も一緒に送られます。

そして、誤解を防ぐための部分です。Xbox Live 認証が守るのはゲームのロジックであり、お使いの回線ではありません。これはログインパケットで行われる、つまり RakNet の接続確立が完全に終わったあとです。お使いのサーバーをあふれさせる攻撃側は、そもそも参加する気がありません。そのパケットは拒否されますが、それでも届いてはいるのです。そこが要点です。

6. 許可リストとプレイヤー数の上限、そしてそれが果たさないこと

許可リスト（以前は Whitelist）とは、参加を認められたプレイヤーの一覧です。Bedrock Dedicated Server では allow-list=true で有効にし、エントリーは allowlist.json に名前、XUID、そして ignoresPlayerLimit のフィールドとともに書きます。Nukkit と PocketMine-MP では、ディレクティブの名前が引き続き white-list です。

allow-list=true
max-players=60
player-idle-timeout=15

player-idle-timeout による短い待機時間は、スロット枯渇に効きます。席を占めているだけのプレイヤーは、指定した分数のあとで切断されます。値 0 は、何もしないことを理由に切断される人が誰もいないという意味で、本物のアカウントを使ってお使いの席をふさぐ攻撃側は、まさにそこを突きます。

ここでも前の節で述べた限界が当てはまり、これがそもそも最も見落とされる点です。許可リストが検査されるのは、ログインパケットが処理されたあとです。参加は防ぎますが、パケットは防ぎません。

7. 送信元アドレスごとにパケットレートを制限する

小規模な攻撃や作りの粗いボットには、送信元アドレスごとの上限が効きます。UDP では connlimit ではなく hashlimit を使います。UDP には接続というものがないからです。

iptables -I INPUT -p udp --dport 19132 -m hashlimit --hashlimit-name bedrock_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

このルールは、同じ送信元アドレスが毎秒 400 を超えるパケットを継続して送った時点で、UDP パケットを破棄します。この値は出発点で、正解ではありません。60 人が入って描画距離も大きいサーバーは、空のサーバーよりはるかに多くのパケットを生みますし、厳しすぎる設定は自分のプレイヤーを追い出します。まずは平常時を 1 週間測ってください。

Unconnected Ping では、はるかに厳しく設定してかまいません。本物のクライアントがサーバーの状態を問い合わせるのは、サーバーリストを開いているあいだだけで、そのとき 1 秒間隔です。nftables では、パケット ID が UDP ヘッダーの直後の最初のバイトであるため、まさにこの 1 つのパケットを狙えます。

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

式 @th,64,8 は、トランスポートヘッダーの 64 ビット目から 8 ビットを読みます。つまり UDP ペイロードの最初のバイトです。値 0x01 は Unconnected Ping のパケット ID です。何かを破棄する前に、同じ場所を観察に使うこともできます。

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

1 行目は入ってくる状態の問い合わせを数え、2 行目はご自身の応答を数えます。ほとんど誰も遊んでいないのに、両方が 1 秒間隔で数千に達するなら、見えているのは ping のあふれであって、お使いのプレイヤーではありません。

保存についての注意が 2 つあります。iptables のルールだけでは再起動で消えるため、Debian と Ubuntu では次のように保存します。

apt-get install -y iptables-persistent
netfilter-persistent save

そして UFW を使っている場合、こうしたルールは /etc/ufw/before.rules に書きます。そうしないと、次の ufw reload で消えてしまいます。

8. カーネルの接続追跡の負担を下げる

UDP のゲームでは TCP よりはるかに早く効いてくる詰まりどころがあります。カーネルは UDP のパケットの対ごとに、接続追跡のエントリーを作ります。送信元アドレスを偽装したあふれでは、パケットごとに新しい送信元アドレス、つまり新しいエントリーになります。テーブルがあふれると、サーバーは正規のパケットまで破棄し、ログには「nf_conntrack: table full, dropping packet」と出ます。

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

カウンターが継続して上限の近くにあるなら、ゲームトラフィックを追跡の対象から外せます。これは有効ですが、影響がないわけではありません。ですから両方向に設定し、そのあとで接続を試してください。

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

そのあと、このトラフィックには状態に基づくルールが効かなくなります。19132 UDP の許可は、したがって本当のポート許可でなければならず、ESTABLISHED の状態に頼ってはいけません。設定したあとは conntrack -L | grep 19132 でエントリーがもう作られないことを確認し、ルールを恒久的に保存する前に一度ゲームで接続してみてください。

9. Geyser と Floodgate をきちんと運用する

Geyser は、Bedrock のクライアントが Java Edition のサーバーで遊べるようにするブリッジです。19132 UDP で Bedrock の接続を受け、プロトコルを変換し、反対側では 25565 TCP で Java のサーバーと話します。Floodgate は、この Bedrock のプレイヤーが Java のアカウントなしで参加できるようにする追加要素です。DDoS 対策の観点では、これは 3 つのことを意味します。

第一に、Geyser を最新に保つことです。このブリッジは、まさに記録された攻撃の原因を 2 度作っています。2024 年 3 月には、上で述べた RakNet ライブラリの増幅不具合が広く悪用され、ビルド 478 で修正されました。2025 年 7 月には 2 件目が続きました。リソースパックの確認のために繰り返し送られるパケットが、プレイヤーごとに複数のセッションを作り、切断されたクライアントがネットワークのチャネルが閉じられないためにパケットを送り続けられる、というものです。ビルド 897 で修正されました。どちらの件も、プロジェクト自身が時系列とともに公表しています。

第二に、Java のサーバーはインターネットに出すものではありません。Geyser の設定では remote.address が auto つまり 127.0.0.1 を指し、remote.port が 25565 を指します。Java のサーバーもそれに合わせてローカルにバインドし、25565 TCP を外に開けないでください。そうしないと、攻撃対象領域が 1 つではなく 2 つになり、2 つ目は、ご自身がルールを考えたことのない側になります。

第三に、ファイル key.pem は秘密です。これは、Floodgate が Bedrock のアカウントについて Java の認証を飛ばすための鍵です。これを公開リポジトリに置いた人、サポートチケットに貼り付けた人、スクリーンショットに写した人は、自分のサーバーの認証を手放したことになります。プロジェクトはこれについて明確に警告しています。

10. 事が起きる前に測定値を集める

最も重要なのは、ほとんど誰も事前にやらない手順、つまりすべてが平常に動いているうちに基準値を作っておくことです。平常時の値がなければ、障害のあとで毎秒 4 万パケットが多かったのか、それとも単に土曜の夜だったのかを判断できません。apt-get install -y vnstat sysstat conntrack で測定は常に走り続けます。

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

このうち 3 つの値が、Bedrock サーバーではとくに物を言います。19132 の UDP ソケットで Recv-Q が継続して 0 でないことは、サーバープロセスが届いたパケットをもう十分な速さで取り出せていないという意味です。UdpRcvbufErrors は、そのために破棄されたパケットをちょうど数えており、回線ではなくプロセスが詰まりどころであることの最も固い証拠です。UdpNoPorts は、何も待ち受けていないポートを撃たれたときに増えます。これは、本来の攻撃の前に広く散らしたポートスキャンが行われたときの典型的な姿です。

tcpdump では必ず -c で件数を区切ってください。全負荷の状態での取得は、すでに過負荷のサーバーにさらに負荷をかけます。測定値の読み方は DDoS 攻撃を検知する で解説しています。

ここまでの対策が限界を迎える地点：帯域幅とパケットレート

ここからは、どの設定ファイルでも解決できない部分です。これまでの対策はすべてお使いのサーバー上、つまり回線の末端で動きます。ファイアウォールのルールが判断するのは、すでにケーブルを通り終えたパケットです。破棄はできますが、送られなかったことにはできません。

一度計算してみてください。誰かが毎秒 125 メガバイトより多く送った時点で、お使いの回線は埋まります。5 から 50 Gbit/s の攻撃は、その 5 倍から 50 倍です。その後ろにある hashlimit のルールの出来は、そうなればもう関係ありません。プレイヤーのパケットは、その手前で通れなくなっているからです。

2 つ目の指標はパケットレートで、Bedrock サーバーではほぼ常にこちらが先に限界に達します。ゲームトラフィックの全体が多数の小さな UDP パケットで構成されており、まさにこの領域で攻撃側は最も安く動けます。お使いの回線を 3 分の 1 も埋めない攻撃でも、評価と破棄に計算時間が費やされるため、サーバーを停止させられます。運用者にはこれが「使用率はまったく高くなかったのに、それでも全員が落ちた」という形で見えます。ゲームの中では、同じことがラグスパイク、ラバーバンド現象、建築の途中での接続切れとして現れます。

これに対するローカルな設定はありません。ボリューム型攻撃は、サーバーの手前のネットワークで終わらせる必要があります。

Bedrock サーバーへの DDoS 攻撃に KernelHost が用意している対策

すべてのサーバーに標準で含まれる常時保護

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

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

決定的な性質が 2 つあります。保護は常時動いており、攻撃を受けてから反応する必要がありません。つまり、最初の数分だけサーバーが落ちている、ということが起きません。そしてヌルルーティングは使いません。お使いの IP アドレスはネットワークに残り、破棄されるのは有害なパケットだけです。IP アドレスをネットワークから外す事業者は、ご自身にとって攻撃側と同じ結果をもたらします。設置場所はフランクフルトです。どのゲームとプロトコルが対象かは ゲームサーバーの DDoS 対策をリアルタイムで にまとめています。

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

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

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

2 つの段階の比較

ほとんどの Bedrock のプロジェクトでは、標準で含まれる常時保護と、きちんとしたサーバー設定を組み合わせれば十分です。Advanced DDoS Protection は、誰かが個人的な問題として攻撃してくる場合への答えです。サーバーを現在ほかの場所で動かしている場合、問題を解決する最も現実的な方法は移転です。フィルタリングはサーバーの手前のネットワークで効くもので、そのネットワークは当社のものである必要があります。

よくある失敗とその対処

「ポートを 19140 に変えたのに、19132 が開いたままだ」：これは enable-lan-visibility=true です。Bedrock Dedicated Server はそのとき、server-port に何が入っていても 19132 と 19133 に追加でバインドします。false に設定し、サーバーを再起動し、ss -lnup で確認してください。

「allowlist.json を編集したら、自分も入れなくなった」：よくある原因は 2 つです。ディレクトリーに古い whitelist.json が残っていて、サーバーがそちらを読んでいるか、XUID のエントリーが欠けているか間違っているかです。Xbox Live 認証が有効な状態では、名前だけでは確実に足りません。

「攻撃を受けた側なのに、事業者がサーバーを止めた」：お使いのサーバー自身がパケットを送り出していなかったか確認してください。2024 年の RakNet 増幅不具合では、まさにそれが起きました。影響を受けたサーバーが第三者のアドレスに数千のパケットを送り、不正利用の通報にはポート 19132 が発信元として記載されていました。tcpdump -ni eth0 'udp src port 19132' -c 200 -q で、お使いのサーバーがどこに応答しているかが分かります。最新のビルドにすれば原因はなくなります。

「iptables のルールが効かない」：よくある原因は 3 つです。ルールが UFW のチェーンの後ろにあって到達しない、前回の再起動で消えていた（この場合は netfilter-persistent save か /etc/ufw/before.rules への記述が助けになります）、あるいは攻撃がボリューム型で、ルールはすでに埋まった回線の上で正しく動いている、のいずれかです。iptables -L INPUT -n -v で一致カウンターが増えているか確認してください。0 のままなら、そのルールには届いていません。

「サーバーはリストに出ているのに、誰も入れない」：エントリーに名前とプレイヤー数が表示されているなら Unconnected Pong は動いており、ポートは基本的に到達可能です。それでも参加に失敗する場合、原因はたいてい Xbox Live の認証か許可リストです。逆に IPv6 のプレイヤーだけが入れないなら、19133 UDP の許可が欠けています。

「サーバーは動いているのに、全員にラグスパイクが出る」：これは攻撃よりプラグインであることのほうが多いです。まず UDP ソケットの Recv-Q が増えているか、UdpRcvbufErrors が増えているかを見てください。どちらも動かず sar -n DEV 1 10 にも異常がないなら、それは DDoS 攻撃ではなく、サーバープロセス自身でした。Bedrock Dedicated Server では、そのあとスクリプトのウォッチドッグが手がかりになります。しきい値は server.properties の script-watchdog-hang-threshold と script-watchdog-slow-threshold にあります。

「これまで使っていた事業者に IP アドレスを遮断された」：それがヌルルーティングです。事業者はそれで自分のネットワークを守りますが、ご自身にとっての結果は攻撃の成功と同じで、多くの場合そのあと数時間続きます。判断に迷うときは、フィルタリングなのかヌルルーティングなのかを尋ねてください。その答えは、どんなハードウェアの仕様よりも可用性を左右します。

「tcpdump で見ても、おかしなところがない」：手前のネットワークですでにトラフィックが除去されている場合、サーバーには何も届かないのが当然です。フィルタリングが機能しているときの通常の姿です。逆に回線が飽和していると、測定に使おうとした SSH セッションさえ届かないことがあります。その場合は、ゲスト側のネットワークに依存せず動作する、カスタマーエリアの VNC コンソールを使ってください。

まとめ

• Minecraft Bedrock サーバーが外に必要とするポートはちょうど 1 つ、19132 UDP です。19133 UDP は IPv6 のプレイヤー向けのときだけ加わります。クエリ、RCON、19144 TCP のスクリプトデバッガー、25565 TCP の Geyser の背後にある Java サーバーは、インターネットに出すものではありません。
• ポートを移す人は enable-lan-visibility=false を設定する必要があります。そうしないと Bedrock Dedicated Server は 19132 と 19133 にも引き続きバインドします。
• Xbox Live 認証と許可リストが効くのはログインパケットの段階、つまり RakNet の接続確立が完全に終わったあとです。守るのはゲームのロジックと席で、回線ではありません。
• Unconnected Ping は 33 バイトで問い合わせられ、約 131 バイトで応答されます。増幅率は約 4 です。短いサーバー名が、この増幅率を小さく保ちます。
• UDP では connlimit ではなく hashlimit が効き、送信元アドレスが偽装された場合はカーネルの接続追跡が最初にあふれます。どちらも、最初の攻撃が来る前に測っておくべき値です。
• おおよそ 1 Gbit/s でお使いの回線は埋まり、64 バイトのパケットならそこに毎秒約 149 万パケットが入ります。それを超えた領域を決めるのは、サーバーの手前のネットワークでのフィルタリングだけです。
• KernelHost では、2 段階の常時保護がすべてのサーバープランに含まれ、提供開始時点から有効で、ヌルルーティングは行いません。Advanced DDoS Protection は、専用の保護 IP とポートごとに自分で管理できるルールを追加します。

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