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

夜に数分だけサーバーリストから消え、そのあいだ全プレイヤーをタイムアウトで落としてしまう Unturned サーバーは、ハードウェアに問題があることはまずありません。多くの場合は攻撃が走っており、しかも最も賑わっている時間帯を狙ってきます。本記事ではまず、追加費用なしでご自身で固められる範囲を示し、次にその対策が技術的にどこで限界を迎えるかを示し、最後にサーバーの手前のネットワークで何が起きる必要があるかを説明します。

本記事の記述はすべて、Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS 上で動く Unturned Dedicated Server（U3DS、SteamCMD のアプリケーション ID 1110390）を前提としています。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。攻撃がいま進行中の場合は、まず設定を変更せず、サーバーも再起動しないでください。第 10 項の測定値を保存します。攻撃が終わってからでは、もう残っていません。

Unturned サーバーがとくに狙われる理由

Unturned サーバーが攻撃されるのは、そのアドレスが公開されていて、ゲームトラフィックが UDP で流れ、しかも攻撃を仕掛ける側に技術もまとまった金額も必要ないからです。この 3 点はいずれも、ほかのたいていのゲームより強く当てはまります。

公開された Unturned サーバーは、自分の IP アドレスを自分から公開します。そうしなければ誰にも見つけてもらえないため、公開せざるを得ません。Steam のサーバーブラウザーは直接問い合わせ、unturned-servers.net や BattleMetrics のような第三者のサーバーリストは IP アドレスとポートを平文で掲載します。unturned-servers.net は自らの説明によれば、サーバーポートで UDP 接続を受け付けるかどうかを 5 分ごとに確認しています。攻撃側にとってこれは手間ではなく、ただのフォーム入力です。

さらにプレイヤー層の事情があります。Unturned は無料で参入障壁がなく、ロールプレイ系とサバイバル系のプロジェクトは同じプレイヤーをめぐって実際に競合しています。BAN されたプレイヤー、気を悪くした元管理者、隣のプロジェクトは、お使いのサーバーを 1 時間使えなくするために、サーバーへのアクセス権を必要としません。DDoS 攻撃が技術的に何であるか、そして偽装した送信元アドレスがなぜ追跡をこれほど難しくするのかは、記事 DDoS 攻撃とは何か で解説しています。

実際に問題になるポート

Unturned サーバーが占有するのは、連続するちょうど 2 つの UDP ポートです。Commands.dat で設定した値と、その値に 1 を足したポートです。初期設定ではそれが 27015 と 27016 になります。Smartly Dressed Games の公式ドキュメントは、この役割分担を次のように説明しています。最初のポートがサーバーリストの問い合わせを運び、2 つ目のポートがゲームトラフィックを運びます。設定するのは最初のポートだけで、2 つ目は自動的に決まります。

Name 私の Unturned サーバー
Port 27015
MaxPlayers 24
Map PEI
Mode Normal
Perspective Both
Owner 76561198000000000

Commands.dat は U3DS/Servers/<instance>/Server/Commands.dat にあります。この形式は独特で、よくある失敗の原因になります。1 行に 1 つのコマンド、等号は使わず、値は半角スペースで区切り、コマンドは大文字と小文字を区別します。// で始まる行はコメントです。

ファイアウォールにとって最も重要な点はこうです。2021 年 11 月 21 日公開のバージョン 3.21.30.0 以降、ポート 27017 は不要になりました。それ以前の Unturned サーバーは 3 つのポートを必要としていました。Steam の問い合わせがゲームポート +2 に載っていたからです。この更新で問い合わせはサーバー自身とポートを共有するようになり、3 つ目のポートはなくなりました。それにもかかわらず、ルーターの手順書、ホスティング事業者の Wiki、フォーラムの投稿はいまも 27017 を挙げています。27017 を開けておくことに、もう利点はありません。純粋な攻撃対象領域です。

同じく重要なのがこの点です。Unturned に内蔵の RCON ポートはありません。公式ドキュメントにあるのはコンソール入力とコンソール出力だけで、これらはインターフェース ICommandInputOutput を通じて差し替えられます。Unturned サーバーで見かけるリモート操作機能は、いずれもプラグイン由来で、それぞれ独自の TCP ポートを持ち込みます。このポートはご自身で見つけ、ご自身で制限する必要があります。誰も代わりに守ってはくれません。

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

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

1. 現状把握：実際に何が待ち受けているか

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

ss -lnup
ss -lntp

1 つ目のコマンドは待ち受けている UDP ソケットを、2 つ目は TCP ソケットを表示します。注目するのはローカルアドレスの列です。0.0.0.0:27015 と [::]:27015 は「インターネット全体から到達できる」、127.0.0.1:3306 は「ローカルのみ」で、ファイアウォールルールは不要という意味です。ゲーム本体のほかに、RCON プラグイン、ウェブパネル、データベース、そして誰も使っていない 27017 上の古いテストサーバーが並んでいることがよくあります。攻撃側からの見え方は、外部からのポートスキャンで分かります。Unturned では必ず UDP で行ってください。

nmap -Pn -sU -p 27000-27050 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. 27015 と 27016 だけを開ける

Unturned では、外に向けた UDP の開放が 2 つあれば足ります。ゲームの動作に TCP ポートは 1 つも必要ありません。公式ドキュメントは両方のポートについて明示的に UDP を求めており、ゲームのネットワーク層（Steam Networking Sockets、ある更新以降は初期設定）は UDP だけで動作します。これに加えて TCP を開ける人は、古くなった手順書に従っています。

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Unturned クエリ'
ufw allow 27016/udp comment 'Unturned ゲーム'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

順番が重要です。そうしないと自分自身を締め出します。復旧手段まで含む詳しい手順は 自分を締め出さずに UFW ファイアウォールを設定する にあります。複数のインスタンスを動かす場合は、推奨されている間隔 2 を守り（27015、27017、27019）、インスタンスごとに実際に占有する 2 つのポートだけを開けてください。

ウェブパネル、データベース、RCON プラグインは、開かれたネットワークに出すものではありません。該当するポートを ufw allow from 203.0.113.10 to any port 8080 proto tcp でご自身のアドレスだけに制限するか、ローカルの SSH ポートフォワーディング ssh -N -L 8080:127.0.0.1:8080 root@YOUR.SERVER.IP.ADDRESS で管理画面にアクセスしてください。データベースは 127.0.0.1 にバインドします。

3. サーバーリストから消えずにクエリポートを守る

クエリポートは Unturned サーバーで最も弱い箇所です。サーバーはここで Steam の問い合わせ A2S_INFO、A2S_PLAYERS、A2S_RULES に応答します。ここを一律で閉じると、サーバーが問題なく動いていても、あらゆるサーバーリストから消えます。

A2S の応答は、要求よりはるかに大きくなります。US-CERT は UDP 増幅攻撃の概要（TA14-017A）で、Steam プロトコルの帯域幅増幅率を 5.5 としています。具体的にはこうです。攻撃側は送信元アドレスを偽装した問い合わせを他人のゲームサーバーに送り、約 5.5 倍に膨らんだ応答を本来の標的へ向けます。このときお使いのサーバーは被害者ではなく、第三者への増幅器です。逆方向では、クエリフラッド 1 つで、プレイヤーを 1 人も落とさずにサーバーをサーバーブラウザーから消せます。運用者が報告するのはまさにこれです。サーバーは動いていて、上のプレイヤーは何も気づかないのに、もう見つけてもらえません。

小規模なクエリフラッドには、送信元アドレスごとの上限が効きます。正規の問い合わせはめったに来ません。Steam のブラウザーは表示 1 回につき 1 度、ステータスサービスは数分ごとです。

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name unturned_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name unturned_game --hashlimit-mode srcip --hashlimit-above 300/sec --hashlimit-burst 500 -j DROP

2 つ目の数値はゲームの仕様から直接導かれます。Unturned は初期設定でプレイヤー 1 人を毎秒 50 パケットに制限します（Max_Packets_Per_Second）。したがって送信元アドレスごとに毎秒 300 パケットという上限は、同じアドレスの後ろに複数のプレイヤーがいても、1 つの回線に十分な余裕を残します。どちらの値も出発点で、絶対の正解ではありません。まずは平常時を 1 週間測ってください。そうしないと、自分のプレイヤーを追い出すことになります。

iptables のルールだけでは再起動で消えます。Debian と Ubuntu では apt-get install -y iptables-persistent と netfilter-persistent save で保存します。UFW を使っている場合、こうしたルールは /etc/ufw/before.rules に書きます。そうしないと、次の ufw reload で消えてしまいます。

あわせて、費用のかからない習慣が 1 つあります。ウェブサイトや Discord ボットでプレイヤー数を表示する場合、訪問者の側からサーバーに問い合わせるのではなく、一定の間隔で取得した結果をキャッシュしてください。そうしないと、訪問の多いステータスページは、間隔ごとに 1 件ではなく、訪問者ごとに 1 件の問い合わせを生みます。

4. Config.json で内蔵の上限を設定する

Unturned は Commands.dat と同じ Server フォルダーにある Config.json に、名前から想像されるより防御にとって重要な区画を備えています。初期設定は次のとおりです。

"Server": {
    "VAC_Secure": true,
    "BattlEye_Secure": true,
    "Max_Ping_Milliseconds": 750,
    "Timeout_Queue_Seconds": 15.0,
    "Timeout_Game_Seconds": 30.0,
    "Max_Packets_Per_Second": 50.0,
    "Join_Rate_Limit_Window_Seconds": 40.0,
    "Rate_Limit_Kick_Threshold": 10,
    "Use_FakeIP": false
}

Max_Packets_Per_Second は、接続済みのプレイヤー 1 人を毎秒 50 パケットに制限します。Join_Rate_Limit_Window_Seconds と Rate_Limit_Kick_Threshold は、40 秒のあいだに 10 回を超えて上限を突破した接続を切断します。VAC_Secure と BattlEye_Secure はプレイヤー側に両方のアンチチートを要求し、それによって使い捨てクライアントの大半を遠ざけます。

ここではっきりさせておくべき点があります。これらの上限が効くのは、実際に参加する、または参加しようとするクライアントに対してです。送信元アドレスを偽装したフラッドには効きません。そこではセッションがまったく成立しないからです。それでも重要なのは、最も多い単独の事例を受け止めるからです。改造された 1 つのクライアントが、自分だけでサーバーを過負荷にする場合です。Max_Ping_Milliseconds は 750 のまま残すのが妥当です。これより低く設定すると、ネットワークが少し揺れるたびに、サーバーは 1 ラウンドの半数のプレイヤーを追い出します。

5. 接続追跡の負荷を下げる

この点はほとんど常に見落とされ、ボリューム型攻撃のように見えて実際はそうではない障害を説明します。カーネルは UDP のトラフィックにも接続追跡（conntrack）のエントリーを作り、送信元アドレスが偽装されている場合、新しいアドレスごとに新しいエントリーが増えます。テーブルが埋まると、カーネルは区別せずにパケットを破棄します。攻撃とお使いのプレイヤーが一緒に落ちるわけです。システムログには nf_conntrack: table full, dropping packet と出ます。

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

最も効果的な手立ては、Unturned のトラフィックをそもそも追跡させないことです。ゲームは自分のセッションを自分で管理し、カーネル側での状態追跡を必要としません。

iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK
iptables -t raw -A PREROUTING -p udp --dport 27016 -j NOTRACK

この 2 つのポートの開放は、そのあと ESTABLISHED,RELATED を経由させてはならず、独立した受け入れルールとして書く必要があります。この点に注意してください。nf_conntrack_max を引き上げる価値があるのは、そのあとです。先にテーブルを大きくする人は、問題を数分先に動かすだけで、その代わりにメモリーを消費します。

サーバープロセスが取り出すより速くパケットが届くと、さらにソケットの受信バッファーがあふれます。回線が空いていても、プレイヤーにはパケットロスのように見えます。

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

この値は /etc/sysctl.d/ に置き、sysctl --system で有効にします。必要かどうかはカーネルが教えてくれます。nstat -az の UdpRcvbufErrors が増えるか、ss -lunp の受信キューに常に何か残っているなら、この調整が効きます。どちらも 0 のままなら、変更しても何も変わりません。これは余裕の確保であって、保護ではありません。

6. 参加フラッド、待機列、許可リスト

参加フラッドとは、攻撃側が回線を埋めるのではなく、正規の参加経路を使ってスロットと計算時間を消費させる攻撃です。Unturned はこれに対して 4 つの手段を備えており、いずれも Commands.dat に書きます。

• Queue_Size 32 は待機列を設定します。初期設定は 8 枠、最大は 64 です。待機列が大きすぎると攻撃側を助け、小さすぎると再起動のたびに本物のプレイヤーを落とします。
• Whitelisted はサーバーを許可リスト方式に切り替えます。登録はコンソールで permit <SteamID64>、削除は unpermit <SteamID64> で行います。
• Password YourPassword は、アドレスをどこかの一覧から拾っただけの相手をすべて排除します。
• Filter は名前に許可されない文字を含むプレイヤーを拒否し、MaxPlayers 24 はスロット数をハードウェアが実際に支えられる範囲に保ちます。

許可リストが守るのはゲームのロジックで、回線ではありません。お使いのサーバーをあふれさせる攻撃側は、そもそも参加する気がありません。そのパケットは拒否されますが、それでも到着しています。問題はまさにそこです。

7. RocketMod、OpenMod とプラグインの側面

Unturned には広く使われているプラグインのプラットフォームが 2 つあり、どちらもサーバーと同じプロセスで動きます。RocketMod は古いほうです。当初の保守担当者は 2019 年 12 月 20 日に保守を終了し、ソースコードを MIT ライセンスで公開しました。以降は Smartly Dressed Games が派生版 Legally Distinct Missile（LDM）を保守しており、これは Dedicated Server にすでに同梱されています。Extras フォルダーの Rocket.Unturned を Modules フォルダーにコピーするだけです。開発元はこの派生版を明確に推奨しています。スレッド処理の不具合やテレポートの悪用といった、古い Rocket の問題を修正しているからです。

OpenMod は新しい後継で、当初の Rocket 保守担当者の 1 人が開発しています。RocketMod を置き換えるのではなく並行して動き、統合機能を通じて既存の Rocket プラグインも併用できます。防御の観点では、これは 2 つのことを意味します。

第一に、すべてのプラグインは本体プロセスにおける攻撃対象領域です。チャットメッセージごと、あるいはゲーム内のイベントごとにデータベースへの問い合わせを発生させるプラグインは、自作の Denial of Service です。イベントをループで発生させるプレイヤーが 1 人いれば、帯域幅をまったく使わずにサーバーを止められます。プラグインの一覧は短く保ち、ソースが公開されたプラグインを優先し、機能を追加するたびにサーバーのフレームレートを測ってください。

第二に、Unturned に独自の RCON ポートがないため、リモート操作機能はすべてプラグイン由来です。インストール後に ss -lntp でどの TCP ポートが開かれたかを確認し、ご自身のアドレスだけに制限してください。弱いパスワードで開いたままのリモート操作ポートは、DDoS の問題ではなく、乗っ取りの問題です。

8. Workshop のコンテンツと参加の処理

Workshop のコンテンツは参加の処理を重くし、それが攻撃されやすさに直接影響します。制御するのは同じ Server フォルダーにある WorkshopDownloadConfig.json です。

{
    "File_IDs": [],
    "Ignore_Children_File_IDs": [],
    "Query_Cache_Max_Age_Seconds": 600,
    "Max_Query_Retries": 2,
    "Use_Cached_Downloads": true,
    "Should_Monitor_Updates": true,
    "Shutdown_Update_Detected_Timer": 600
}

File_IDs には、マップと Mod の Workshop 識別子を書きます。起動時にサーバーが依存関係もあわせてダウンロードし、各プレイヤーは接続時に自動で追加ダウンロードします。知っておくべき結果が 3 つあります。第一に、Mod の一覧が大きいと参加に時間がかかり、攻撃のあとは全プレイヤーが同時に戻ってくるため、サーバーは二度目の負荷を受けます。第二に、Workshop のファイルが更新されると Should_Monitor_Updates がサーバーを停止させます。初期設定の Shutdown_Update_Detected_Timer は 600 秒で、そのあと再起動が起きるため、運用者は攻撃を受けている場面でこれを攻撃の成功と取り違えがちです。第三に、どの Mod もお使いのサーバー上で動く他人のコードです。

実務上はこうなります。一覧はできるだけ短く保ち、予期しない再起動があったらまずサーバーのログで Workshop の更新に関するメッセージを確認し、Should_Monitor_Updates を無効にするのは更新をご自身で計画する場合だけにしてください。

9. サーバーリスト、サーバーコード、Fake IP 機能

サーバーが公開されて一覧に載っている限り、お使いの IP アドレスは秘密にできません。一度接続したプレイヤーは全員それを知っていますし、第三者のサーバーリストはいずれにせよ公開します。それでも 2 つの習慣は役に立ちます。生のアドレスをご自身からどこにも公開しないこと、そしてプレイヤーをホスト名経由で接続させ、アドレスを変えてもすべての参照が壊れないようにすることです。定番の失敗は、古いアドレスを指したまま忘れられた A レコードで、これがあるとどんな変更も無意味になります。

インターネットで運用するなら、いずれにせよアプリケーション ID 304930 の Steam サーバー管理から取得する Game Server Login Token（GSLT）が必要です。これはあわせて、お使いのサーバーのサーバーコードが起動ごとに作り直されるのではなく、再起動をまたいで変わらないようにします。

Unturned にはさらに Fake IP 機能があります。Config.json の "Use_FakeIP": true で有効にし、コンソールコマンド CopyFakeIP が、公開すべきアドレスを返します。以降トラフィックは中継網 Steam Datagram Relay を通り、割り当てられるアドレスは 169.254.0.0 から 169.254.255.255 の範囲に収まり、サーバーの本当のアドレスはプレイヤーに表示されなくなります。Valve はこのトラフィックを、認証済み、暗号化済み、レート制限済みと説明しています。

その代償は大きく、あまり一緒に語られません。アドレスとポートは再起動ごとに変わり、独自のスクリプトなしではドメイン名を向けられず、Steam の一覧のうち「お気に入り」と「履歴」は機能せず、使えるのはブックマーク機能だけです。そしてなにより、この機能が守るのはゲームの経路だけです。お使いのサーバーは本当のアドレスを保持したままで、SSH、ウェブパネル、データベース、ウェブサイトはそこから引き続き到達できます。古い DNS レコード、ステータスページ、以前の接続からアドレスを知っている相手は、これまでどおり直接攻撃します。つまり Fake IP 機能は、サーバーの手前のネットワークでのフィルタリングの代わりにはならず、お使いのアドレスをそもそも知っている人の数を減らすだけです。

10. 攻撃中に推測しなくて済むようにログを取る

最も重要なのは、ほとんど誰も事前にやらない手順、つまりすべてが平常に動いているうちに基準値を作っておくことです。平常時の値がなければ、障害のあとで毎秒 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 portrange 27015-27016 -c 200 -q

tcpdump では必ず -c で件数を区切ってください。全負荷の状態での取得は、すでに過負荷のサーバーにさらに負荷をかけます。測定値の読み方と、攻撃をソフトウェアの不具合と見分ける方法は DDoS 攻撃を検知する にあります。

ここまでの対策が限界を迎える地点

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

一度計算してみてください。一般的なゲームサーバーは 1 Gbit/s の回線につながっており、これは毎秒 125 メガバイトです。誰かがそれより多く送った時点で、回線は埋まります。平常時の運用はそれを大きく下回ります。プレイヤー 24 人、初期設定で許される 1 人あたり毎秒 50 パケットなら、届くのは毎秒約 1200 パケットです。booter サービスは、何の準備もなしにその何倍もを生み出します。

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

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

KernelHost が用意している対策

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

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

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

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

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

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

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

2 つの段階の比較

ほとんどの Unturned プロジェクトでは、標準で含まれる常時保護と、きちんとしたサーバー設定を組み合わせれば十分です。Advanced DDoS Protection は、誰かが個人的な問題として攻撃してくる場合への答えです。

よくある失敗とその対処

「手順書には 27015 から 27017 まで開けろと書いてある」：その手順書は 2021 年 11 月より古いものです。バージョン 3.21.30.0 以降、Unturned サーバーが必要とするポートは 2 つだけです。Steam の問い合わせがゲームポート +2 に載らなくなったからです。そこで 2 台目のインスタンスが動いているのでなければ、27017 は閉じてください。

「サーバーは動いているのに、どのサーバーリストにも載らない」：これはクエリフラッドの典型的な姿か、27015 UDP に対するご自身のルールが厳しすぎる場合の姿です。iptables -L INPUT -n -v で、ご自身のルールが一致を数えているか確認してください。カウンターが大きく伸びているなら、いま自分の一覧掲載をフィルタリングして消しています。27015 を一律で閉じてはいけません。

「全プレイヤーが同時にタイムアウトで落ちる」：まず接続追跡があふれていないかを確認してください（dmesg -T | grep -i conntrack）。テーブルが埋まると、カーネルは区別せずに破棄します。Timeout_Game_Seconds は初期設定で 30 秒です。この時間内に戻ってきたプレイヤーは、自分の枠を保てます。

「運用中にサーバーが勝手に再起動する」：これが攻撃であることはまれです。Workshop の更新を検知したというメッセージをログで確認してください。Should_Monitor_Updates は、初期設定の 600 秒が過ぎるとサーバーを停止させます。

「IP アドレスを変えたのに、2 時間後にまたオフラインになった」：攻撃側は新しいアドレスを、古いアドレスと同じ出どころ、たいていはサーバーリスト、Discord ボット、古い DNS レコードから手に入れています。アドレスの変更は時間稼ぎであって、解決ではありません。

「Fake IP 機能を有効にしたのに、それでも攻撃される」：この機能は新しいプレイヤーからアドレスを隠しますが、サーバーからアドレスを取り上げるわけではありません。古い一覧の掲載、ステータスページ、以前の接続からアドレスを知っている相手は、これまでどおりお使いのサーバーに直接到達でき、その上の SSH やウェブパネルにも同じように到達できます。

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

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

まとめ

• Unturned サーバーが必要とする開いた UDP ポートはちょうど 2 つです。Commands.dat で設定した Port（初期設定は 27015）と、その値に 1 を足したポート（27016）です。ゲームの動作に TCP は必要ありません。
• ポート 27017 は 2021 年 11 月 21 日公開のバージョン 3.21.30.0 以降は不要です。Steam の問い合わせがゲームポート +2 に載らなくなったからです。まだ開けている人は、古くなった手順書に従っています。
• Unturned に内蔵の RCON ポートはありません。リモート操作機能はすべてプラグイン由来で、独自の TCP ポートを持ち込み、ご自身で制限する必要があります。
• クエリポートの 27015 が最も弱い箇所です。クエリフラッドは、プレイヤーを 1 人も巻き込まずにサーバーをサーバーリスト上で見えなくし、Steam プロトコルの増幅率は US-CERT TA14-017A によると 5.5 です。
• Config.json の上限（Max_Packets_Per_Second 50.0、Rate_Limit_Kick_Threshold は 40 秒あたり 10 回）が効くのは、実際に参加するクライアントに対してだけで、偽装した送信元アドレスには効きません。
• 1 Gbit/s の回線は毎秒 125 メガバイトで埋まり、64 バイトのパケットなら毎秒約 149 万パケットで埋まります。プレイヤー 24 人の平常時は毎秒約 1200 パケットです。それを超える分を決めるのは、お使いのファイアウォールではなく、サーバーの手前のネットワークです。
• KernelHost では、2 段階の常時保護がすべてのサーバープランに追加料金なしで含まれ、提供開始時点から有効で、ヌルルーティングは行いません。フィルタールールをご自身で制御したい場合は、月額 50.00 EUR からの Advanced DDoS Protection を追加します。

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