Mordhau サーバーを DDoS 攻撃から守る

Frontline のラウンドの最中に全プレイヤーを一度に失い、そのあと数分オフラインになってサーバーリストにも出てこなくなる Mordhau サーバーに、ハードウェアの問題があることはまずありません。ほとんどの場合、Mordhau の専用サーバーが外に開けておく必要のある 4 つの UDP ポートのどれかに、攻撃が走っています。本記事ではまず、Mordhau の DDoS 対策として追加費用なしでご自身で片付けられる範囲を示し、次にその対策が物理的にどこで限界を迎えるかを示し、最後にサーバーの手前のネットワークで何が起きる必要があるかを説明します。

本記事の記述はすべて、Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS 上で動く公式の Mordhau 専用サーバー（Steam のアプリケーション ID 629800、Unreal Engine 4）を前提としています。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。攻撃がいま進行中の場合は、まず設定を何も変更せず、サーバーも再起動せずに、測定値を保存してください（第 9 節）。攻撃が終わってからでは、もう残っていません。Mordhau にはもう 1 つ理由が加わり、これを痛い形で学ぶ運用者が多くいます。サーバープロセスは終了するときに、メモリー上の状態を Game.ini に書き戻します。サーバーが動いている状態でこのファイルを編集した人は、次に停止したときに変更を失います。

Mordhau サーバーに DDoS 対策が必要な理由と、攻撃してくる相手

Mordhau サーバーが攻撃されるのは、そのアドレスが公開されており、ゲームトラフィックのすべてが UDP で流れ、障害がすぐに全員の目に触れるからです。サーバーブラウザーのエントリーには IP アドレスとゲームポートが平文で入っています。そうでなければプレイヤーがサーバーを見つけられません。公開のサーバーリストやトラッカーは同じデータを Steam の問い合わせポートから取得し、2 度目の公開を行います。つまりお使いのアドレスは秘密ではなく、製品情報の一部です。

そこにゲームの技術面が加わります。Unreal Engine 4 は動き、命中、受け流しを UDP で伝えます。UDP には要求できるような接続確立の手順がなく、UDP パケットの送信元アドレスは偽装できます。つまり攻撃側は、お使いのサーバーに入る必要も、正しく話しかける必要もなく、負荷をかけられます。Mordhau ではこれが多くのゲームより重くのしかかります。斬り合いは数十分の一秒の範囲で決まるため、200 ミリ秒の遅延が加わっただけで近接戦は成り立たなくなり、サーバーが実際に落ちるよりずっと前にそうなります。だからこそ小さな攻撃でも 1 ラウンドを壊せます。DDoS 攻撃が具体的に何であるかは、記事 DDoS 攻撃とは何か で解説しています。

典型的なきっかけは地味なものです。コミュニティー間の競合、BAN されたプレイヤー、負けた決闘、Discord でのもめ事です。攻撃を仕掛ける側には技術もまとまった金額も必要ありません。借りた booter のサービスが作業を済ませます。運用者からは、サーバーが満員のときにちょうど攻撃が始まり、空になると止まるという報告が繰り返し上がります。これは偶然ではなく、誰かがお使いのサーバーブラウザーのエントリーを見ていて、プレイヤー数をきっかけに使っているという手がかりです。

Mordhau で実際に問題になるポート

Mordhau の専用サーバーが外に必要とするのは、ちょうど 4 つの UDP ポート、7777、7778、15000、27015 です。それ以外は任意か、インターネットに出すものではありません。ポートは起動時にパラメーターとして渡します。

./MordhauServer.sh FFA_ThePit -log -Port=7777 -QueryPort=27015 -BeaconPort=15000 -RconPort=27020

ここで 2 つのことが繰り返し誤解されます。第一に、ビーコンポートの 15000 は付け足しではありません。ビーコンは、プレイヤーが参加したその瞬間にスロットを確保し、マップを読み込み終えたあとで追い出されないようにします。15000 が遮断されていたり過負荷になっていたりすると、ポート 7777 が応答していてもプレイヤーは入ってこられなくなります。第二に、Mordhau では RCON があらかじめ設定されていません。RconPassword と RconPort を設定して初めて有効になり、そのとき使われるのは UDP ではなく TCP です。

Mordhau サーバーの主要な数値をまとめます。

Mordhau で見られる攻撃のパターン

4 つのパターンで、Mordhau サーバーに対して行われることのほぼすべてが説明でき、それぞれが別のポートに当たります。

• ゲームポート 7777 への UDP フラッド。これは booter の標準的な攻撃です。サーバーブラウザーに載っているポートに、できるだけ多くの偽装パケットを送ります。狙うのは帯域幅とパケットレートで、脆弱性ではありません。誰かが接続を失うずっと前に、まずラグスパイクとして現れます。
• クエリポート 27015 へのクエリフラッド。A2S_INFO の問い合わせは 25 バイトの大きさで、サーバー名、マップ、ゲームモード、プレイヤー数を含む応答はその何倍にもなります。つまり攻撃側はわずかしか投じず、お使いの側に計算作業と送信方向のトラフィックを強います。
• ご自身のクエリポートを使ったリフレクション。ここではお使いのサーバーは標的ではなく道具です。攻撃側が送信元アドレスを偽装した問い合わせを送り、お使いのサーバーが被害者に応答します。これは 27015 での説明のつかない送信方向のトラフィックとして、そして事業者からの不正利用の通報として気づくことになります。
• ビーコンポート 15000 を使った参加とスロットの枯渇。帯域幅を燃やすのではなく、自動化された参加が確保済みのスロットを占めます。サーバーは動き続けますが満員になり、本物のプレイヤーは入ってこられなくなります。

さらに、RCON がインターネットに開いていると 5 つ目のパターンが加わります。RCON のポートに対する 1 秒間隔のログイン試行です。これはボリューム型になることはまれですが計算時間を使い、しかも 5 つのうち唯一、当たればサーバーを完全に手放すことになる場合です。

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

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

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

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

ss -lntup

注目するのはローカルアドレスの列です。0.0.0.0:7777 と [::]:7777 は「インターネット全体から到達できる」、127.0.0.1:27020 は「ローカルのみ」で、ファイアウォールルールは不要という意味です。ゲームのほかに、ウェブパネル、データベースのサービス、そしてとうに忘れられたボイスサービスが並んでいることがよくあります。攻撃側からの見え方は、外部からのスキャンで分かります。UDP はポートの一覧を短くします。完全な UDP スキャンは非常に遅いからです。

nmap -Pn -sU -p 7777,7778,15000,27015 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. Mordhau が本当に必要とする 4 つのポートだけを開ける

Mordhau には外に向けた UDP の許可が 4 つで足り、それ以外は制限するか、そもそも公開しません。UFW では次のようになります。自分自身を締め出さないよう、この順番どおりに実行してください。

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'Mordhau ゲーム'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau ビーコン'
ufw allow 27015/udp comment 'Mordhau クエリ'
ufw allow from 203.0.113.10 to any port 27020 proto tcp comment 'Mordhau RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

203.0.113.10 はご自身のアドレスに置き換えてください。重要なのは、ここに書かれていないものです。ウェブパネルの許可はなく、データベースの許可もなく、ファイルサーバーの許可もありません。追加で開いたポートはどれも、ゲームとは関係のない追加の標的です。復旧手段まで含む詳しい手順は 自分を締め出さずに UFW ファイアウォールを設定する にあります。

3. サーバーリストから消えずにクエリポート 27015 を制限する

問い合わせポートは制限してよいものの、閉じてはいけません。27015 UDP を閉じると、お使いのサーバーはサーバーブラウザーから消えます。プレイヤー数、マップ名、サーバー名がまさにこのポートから取得されるからです。送信元アドレスごとの上限が、可視性を失わずにこの問題を解決します。

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name mh_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

正規のサーバーブラウザーは 1 分に数回お使いのサーバーに問い合わせます。1 秒に数回ではありません。したがって送信元アドレスごとに毎秒 10 件という値は、どのプレイヤーにも十分に寛大で、どのボットにも十分に厳しいものです。そのあと一致カウンターで、ルールがそもそも効いているか確認してください。

iptables -L INPUT -n -v | head -20
tcpdump -ni eth0 udp port 27015 -c 200 -q

ここにリフレクションの問いへの答えもあります。リフレクションでは、お使いのサーバーは攻撃されているのではなく、増幅器として悪用されています。問い合わせが送信元アドレスを偽装して届き、お使いの応答が第三者の被害者に当たります。これに対して送信元アドレスごとのレート制限は、ローカルで最も効く対策です。偽装した送信元アドレスが役に立つのは、お使いのサーバーが快く無制限に応答しているあいだだけだからです。

4. RCON をインターネットから切り離す

Mordhau では、RCON をどんな場合も無制限にインターネットに出してはいけません。この経路は Game.ini の [/Script/Mordhau.MordhauGameSession] の節で有効にします。

[/Script/Mordhau.MordhauGameSession]
ServerName=My Mordhau Server
MaxSlots=64
ServerPassword=
AdminPassword=YourLongRandomPassword
RconPassword=AnotherLongRandomPassword
RconPort=27020

Mordhau は Source RCON プロトコルを話します。つまり TCP であり、そのため一般的な RCON ツールとどれでも組み合わせられます。まさにそれを、認証情報を試し続けるスクリプトも利用します。3 つのルールでこの件は片付きます。第一に、RconPassword と AdminPassword は 2 つの異なる、長く、無作為なパスワードであり、サーバー名をひねったものではありません。第二に、RCON ポートの許可は、上の UFW のブロックのようにご自身のアドレスだけに限定します。第三に、固定したアドレスを持っていない場合は、ポートを外からは閉じたままにし、SSH のポートフォワーディング経由で到達します。そのあとローカルの 127.0.0.1:27020 に接続します。

ssh -N -L 27020:127.0.0.1:27020 root@YOUR.SERVER.IP.ADDRESS

それでも RCON を開けたままにする必要があるなら、少なくとも送信元アドレスごとの同時接続数を制限してください。RCON ツールに必要な接続は 1 本、ブルートフォースのスクリプトには数百本です。

iptables -I INPUT -p tcp --dport 27020 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

5. ビーコンポート 15000 を参加のあふれから守る

ビーコンポートは、Mordhau サーバーで過小評価されている攻撃点です。ゲームはこのポートを通して、参加してくるプレイヤーがまだ読み込んでいるあいだ、そのスロットを確保します。短い間隔で参加を繰り返し始めるボットは、それによってスロットを占め、ゲームに入ってくることは一度もありません。サーバーはオンラインのままなのに、満員に見えます。送信元アドレスごとの上限がこれを受け止めます。本物のプレイヤーは参加 1 回につきちょうど 1 回ビーコンを出し、毎秒 20 回ではないからです。

iptables -I INPUT -p udp --dport 15000 -m hashlimit --hashlimit-name mh_beacon --hashlimit-mode srcip --hashlimit-above 20/sec --hashlimit-burst 40 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name mh_game --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

2 つ目のルールはゲームポート向けで、見極めが必要です。ティックレートが 60 の場合、サーバーは接続している各プレイヤーと、1 方向あたり毎秒 60 パケットの規模でやり取りします。したがって送信元アドレスごとに毎秒 400 パケットという上限は、本物のプレイヤーには十分な余裕を残し、それでも明らかにあふれさせている送信元には当たります。厳しくする前に、まずは平常時を 1 週間測ってください。厳しすぎる設定は自分のプレイヤーを追い出し、そのあとそれを攻撃だと思い込むことになります。

iptables のルールだけでは再起動で消えます。Debian と Ubuntu では次のように保存します。

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

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

6. Game.ini と Engine.ini：本当に効くもの

Mordhau には設定ファイルが 2 つあり、どちらも Linux では Mordhau/Saved/Config/LinuxServer/、Windows では Mordhau\Saved\Config\WindowsServer\ にあります。Game.ini はサーバー名、スロット、パスワード、管理者一覧、マップのローテーション、そして mod.io の Mod 識別子を扱い、Engine.ini はネットワークのふるまいを扱います。どちらも必ずサーバーを停止した状態で編集してください。そうしないと、サーバープロセスが終了するときにメモリー上の状態でご自身の変更を上書きします。

攻撃対象領域に本当に関わる設定は 3 つです。第一に ServerPassword です。招かれていない相手をすべて遠ざけますが、公開での見つけやすさを失いますし、ポート 7777 へのあふれにはまったく効きません。攻撃側はそもそも参加する気がないからです。第二に、現実的な MaxSlots の数です。Mordhau は最大 64 人向けに作られており、スロットが 1 つ増えるたびに、CPU が面倒を見なければならないパケットの発生源が 1 つ増えます。第三に Engine.ini のティックレートです。

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=60
LanServerMaxTickRate=60

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

Mordhau サーバーの標準のティックレートは 60 です。120 への引き上げはプレイヤー 1 人あたりのパケットレートと CPU 負荷を倍にするもので、つまり攻撃を受けているときにいちばん困るものです。ティックレート 120 の 64 スロットのサーバーは、平常時ですでに 1 方向あたり毎秒 8000 パケットの規模を生みます。継続的に撃たれている場合は、120 より 60 のほうが体感で明らかに安定します。

7. 接続追跡と受信バッファーの負担を下げる

見落とされがちな詰まりどころが、カーネルの接続追跡です。UDP の流れごとに固有のエントリーを持つため、数万の偽装された送信元アドレスからのあふれは、数秒でテーブルを埋めます。あふれると、サーバーは正規のパケットまで破棄し、ログには「nf_conntrack: table full」と出ます。現在値と上限は次のコマンドで分かります。

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack | tail -20

これには 2 通りの手立てがあります。上限を上げるか、ゲームのポートを追跡の対象から完全に外すかです。ゲームサーバーでは後者のほうがたいてい良い道です。UDP にはもともと、追跡する必要のある状態がないからです。

iptables -t raw -I PREROUTING -p udp --dport 7777 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 15000 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 27015 -j NOTRACK

受信バッファーを大きくし、ネットワークカードの待ち行列を深くすることも有効です。短い山がすぐに破棄につながらないようにできます。

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=4194304
sysctl -w net.core.netdev_max_backlog=5000

恒久的に残すには、これらの値を /etc/sysctl.d/ の下のファイル、たとえば 99-gameserver.conf に置きます。理解のうえで重要な点があります。バッファーを大きくしても、大きな攻撃に対する耐久力は上がりません。短い振れがそれだけでパケットを失わせることを防ぐだけです。

8. アドレスはサーバーリストに載り、それは変えられない

ここでは希望的な観測より正直さのほうが役に立ちます。公開された Mordhau サーバーの IP アドレスは、秘密にできません。サーバーブラウザーのエントリーに載り、問い合わせポートを定期的に読み出す第三者の公開サーバーリストに載り、一度でも接続したプレイヤー全員が知っています。したがってアドレスの変更で稼げるのは数時間、まれに数日です。攻撃側は、古いアドレスと同じ道で新しいアドレスを見つけるからです。

これに効くのは 3 つの習慣です。生の IP アドレスをご自身でどこにも公開しないこと、つまり Discord のチャンネルにもプロジェクトのページにも書かないことです。プレイヤーの接続はホスト名経由にして、いざアドレスを変えたときに参照先が全部壊れないようにします。そして古い DNS のレコードを片付けます。前のアドレスを指す A レコードを忘れていると、どんな変更も無意味になります。テストサーバーにも同じことが当てはまります。同じマシン上で外から到達できる 2 台目のサーバーは、本サーバーのアドレスを明かします。

9. すべてが平常に動いているうちに測る

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

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 'udp port 7777 or udp port 15000 or udp port 27015' -c 200 -q

tcpdump では必ず -c で件数を区切ってください。全負荷の状態での取得は、すでに過負荷のサーバーにさらに負荷をかけます。とくに ip -s link の破棄パケットのカウンターに注目してください。CPU が静かなまま dropped の値が増えているのは、問題が計算能力ではなくパケットレートであることの最も明確な手がかりです。測定値の読み方は DDoS 攻撃を検知する で、サーバーを SteamCMD できちんと設置して最新に保つ方法は SteamCMD でゲームサーバーをインストールする で解説しています。

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

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

一度計算してみてください。一般的なゲームサーバーは 1 Gbit/s につながっており、これは毎秒 125 メガバイトです。誰かがそれより多く送った時点で、回線は埋まります。64 スロットの満員の Mordhau サーバーが必要とするのは、そのごく一部です。ティックレート 60 では、ゲームトラフィックは 1 方向あたり毎秒 4000 パケットの規模です。一方、借りた booter は何の苦もなく 5 から 50 Gbit/s を供給します。つまりお使いの回線の 5 倍から 50 倍です。その後ろにある iptables のルールの出来は、そうなればもう関係ありません。プレイヤーのパケットは、その手前で通れなくなっているからです。

2 つ目の指標はパケットレートで、帯域幅より早く限界に達することがよくあります。64 バイトの小さなパケットなら、1 Gbit/s の回線には毎秒約 149 万パケットが入ります。通常のサーバーのカーネルが破棄を始める前に処理できるのは、CPU とネットワークカードによりますがそのうち数十万です。つまり、お使いの回線を 3 分の 1 も埋めない攻撃でも、破棄のために計算時間が費やされるため、Mordhau サーバーを停止させられます。運用者にはこれが「使用率はまったく高くなかったのに、それでも全部落ちた」という形で見えます。

実際に現れる規模の目安として、KernelHost のサーバーでは、ボイスサーバーに対する毎秒 4150 万パケットを超える 473.4 Gbit/s 超の攻撃や、ゲームサーバーに対する 112.2 Gbit/s を超える UDP フラッドなどを除去してきました。これに対するローカルな設定はありません。ボリューム型攻撃は、サーバーの手前のネットワークで終わらせる必要があります。

KernelHost が用意している対策

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

KernelHost のすべてのサーバーには、3.2 Tbps の DDoS 基本保護が標準で含まれています。有効化も注文も設定もなしに常時動いており、Advanced DDoS Protection で強化することもできます。

• 標準装備：フランクフルトにおける 3.2 Tbps の Arbor リアルタイムフィルタリング。 UDP フラッド、SYN フラッド、ICMP フラッドといった一般的なフラッド攻撃や、リフレクション攻撃、増幅攻撃を、サーバーの直前で検知し、パケット単位で破棄します。
• Advanced DDoS Protection 利用時：グローバルなスクラビングネットワークにおける最大 17 Tbps の緩和能力。 非常に大規模な攻撃は、データセンターに届く前に、発生源の近くで除去されます。さらに、特化したプロファイルが個々のゲームを狙った攻撃をフィルタリングします。

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

継続的に撃たれている Mordhau サーバー向けの Advanced DDoS Protection

サーバーによっては、たまたまではなく、狙って何週間も攻撃されます。そのために Advanced DDoS Protection があり、月額 50.00 EUR、PrePaid、最低利用期間なし、初期費用なしで利用できます。グローバルなスクラビングネットワークにおける最大 17 Tbps の緩和能力が加わり、制御できる範囲も大きく広がります。

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

Advanced DDoS Protection の対象は、KernelHost で動いているサーバーです。お使いの Mordhau サーバーが現在ほかの場所にあり、定期的にネットワークから撃ち落とされている場合、このフィルタリングへの道は移転です。移転できない場合は、Remote DDoS Protection がサーバーを今の場所のまま守ります。

2 つの段階の比較

一般的なフラッド攻撃に対しては、標準で含まれる基本保護と、きちんとした設定を組み合わせれば十分です。Advanced DDoS Protection は、誰かが個人的な問題として攻撃してくる場合への答えです。

よくある失敗とその対処

「ポート 27015 を閉じたら、サーバーがリストに出なくなった」：予想どおりの結果です。Steam の問い合わせポートは、名前、マップ、プレイヤー数をサーバーブラウザーに渡します。これがなければ、お使いのサーバーは表示されなくなるか、到達できないものとして扱われます。正しいのは遮断ではなく、送信元アドレスごとのレート制限です。

「サーバーは動いているのに、プレイヤーが入ってこられない」：まずポート 15000 UDP を確認してください。ビーコンは読み込み中のスロットを確保します。遮断されていたり、厳しすぎるフィルタリングを受けていたり、過負荷になっていると、ポート 7777 が応答してサーバーがブラウザーに載っていても、参加は途中で止まります。

「Game.ini の変更が、再起動後にまた消えている」：サーバーが動いている状態でファイルを編集しています。Mordhau のサーバープロセスは終了するときにメモリー上の状態を書き戻し、そのときにご自身の版を上書きします。サーバーを停止し、編集し、起動する、この順番です。

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

「サーバーは動いているのに、全員にラグスパイクが出て、命中が遅れて届く」：まず、CPU が静かなまま入力のパケットレートが上がっているかを見てください。それがまさに攻撃のパターンです。パケットレートが平常のままで CPU が 100 パーセントに張り付いているなら、それは DDoS 攻撃ではなく、たいていは高すぎるティックレート、多すぎるスロット、あるいは Mod です。

「事業者からポート 27015 の送信方向の不正利用を通報された」：お使いのサーバーがリフレクションの増幅器として悪用されました。問い合わせが送信元アドレスを偽装して届き、お使いのサーバーが第三者の被害者に応答したのです。27015 UDP に送信元アドレスごとのレート制限をかければ止まります。

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

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

まとめ

• Mordhau の専用サーバーが外に必要とする UDP ポートはちょうど 4 つです。7777（ゲーム）、7778（Steam）、15000（ビーコン）、27015（Steam の問い合わせ）です。それ以外は閉じておきます。
• Mordhau の RCON は Source RCON プロトコルに沿って TCP で動き、Game.ini の RconPassword と RconPort によって初めて有効になります。ポートはご自身のアドレスだけに限定してください。
• 27015 UDP は制限してよいものの、閉じてはいけません。これがないとお使いのサーバーはサーバーブラウザーから消えます。プレイヤー数、マップ、名前がこのポートから取得されるからです。
• 15000 UDP はビーコンポートで、読み込み中のスロットを確保します。遮断されていたり過負荷になっていると、サーバーが動いていてもプレイヤーは入ってこられません。
• Game.ini と Engine.ini は、サーバーを停止した状態でのみ編集してください。サーバープロセスが終了するときにメモリー上の状態を書き戻すからです。
• ローカルなファイアウォールのルールは帯域幅で終わります。1 Gbit/s は毎秒 125 メガバイトで、64 バイトのパケットなら毎秒約 149 万パケットです。それを超えた領域を決めるのは、サーバーの手前のネットワークだけです。
• KernelHost では、3.2 Tbps の基本保護がすべてのサーバープランに追加料金なしで含まれ、提供開始時点から有効で、ヌルルーティングは行いません。フィルタリングをご自身で制御したい場合は、月額 50.00 EUR の Advanced DDoS Protection で手に入ります。

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