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

夜のプレイ中に全プレイヤーを同時に追い出し、数分間オフラインになり、そのあと自然に復旧する Palworld サーバーは、ハードウェアに問題があることはまずありません。ほとんどの場合、攻撃が走っています。本記事では Palworld サーバーを DDoS 攻撃から守る方法を示します。まず追加費用なしでご自身で設定できる範囲、次にその対策が技術的にどこで終わるのか、最後にサーバーが到達可能なままであるためにサーバーの手前のネットワークで何が起きる必要があるかです。

本記事の記述はすべて、Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS 上で動く Pocketpair 公式の専用サーバー（Steam アプリ ID 2394010）を前提としています。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。攻撃がいま進行中なら、順番が決まっています。先に測り、それから変えることです。負荷のかかった状態での強制再起動は、最後の自動保存以降にワールドで起きたことをすべて捨て、そのあとには障害時の測定値も残りません。

Palworld サーバーが DDoS 攻撃で狙って止められる理由

Palworld サーバーは、固定したアドレスにいる小さく固定した観客です。専用サーバーは 32 プレイヤーに制限されており、ServerPlayerMaxNum で有効な範囲 1 から 32 のうちの値を指定します。代わりにゲームのメニューからホストすると 4 プレイヤーで、しかもホスト自身がオンラインのあいだだけです。この 32 のスロットからそれ以外のすべてが導かれます。集団は決まった夜の時間帯に遊び、互いに顔見知りで、20 時の障害はプレイヤーの一部ではなく全員に当たります。

そのときサーバーのアドレスは秘密ではありません。Palworld には事業者のサービスを介した仲介がありません。プレイヤーは IP アドレスとポートを直接接続の入力欄に書き込み、サーバーをコミュニティサーバーリストにも載せたい人は -publiclobby を付けて起動し、クエリポートに応答させます。つまり一度でも接続した人は全員が標的を知っています。このアドレスを月に数ユーロで撃つ booter サービスは、依頼する側に技術も手間も求めません。

技術面では、ゲームトラフィックのすべてが UDP で流れることが加わります。UDP には要求できるような接続確立の手順がなく、UDP パケットの送信元アドレスは偽装できます。つまり攻撃側は、サーバーに参加する必要も、正しく話しかける必要もなく、負荷をかけられます。そうした攻撃で技術的に何が起きるのかは、記事 DDoS 攻撃とは何か で解説しています。

Palworld サーバーで実際に問題になるポート

Palworld サーバーが開ける必要のあるポートはちょうど 1 つ、8211 UDP です。それ以外はすべて任意で、用途によってはインターネットに出ていること自体が害になります。ここから役に立つ区別が生まれます。ポート 8211 への DDoS 攻撃は必ずゲームトラフィックそのものに当たり、いっぽうポート 27015 UDP への攻撃はサーバーリストへの登録だけに当たります。

これらの切り替えはすべて 1 つのファイルにあります。Pal/Saved/Config/LinuxServer/PalWorldSettings.ini、Windows では対応する Pal\Saved\Config\WindowsServer\PalWorldSettings.ini です。ファイルは節の行 [/Script/Pal.PalGameWorldSettings] で始まり、そのあとに設定すべてを一覧として含む OptionSettings=(...) の 1 行が続きます。この括弧の内側に改行を入れると設定全体が無効になり、サーバーは何も言わずに初期値へ戻ります。サーバーディレクトリーにある雛形 DefaultPalWorldSettings.ini は編集しません。更新のたびに上書きされるからです。

Palworld サーバーを数字で見る

次の値は、フィルタールールとしきい値についてのあらゆる判断の土台になります。

クエリポートの 27015 が最も弱い箇所である理由

クエリポートは Steam 形式 A2S でステータス要求に応答します。Counter-Strike や ARK のサーバーが応じるのと同じクエリです。A2S_INFO の要求は数十バイトの、接続を伴わない UDP パケットで、サーバー名、ワールド、プレイヤー数、進行状況を含む応答はその何倍にもなります。UDP では送信元アドレスを偽装できるため、攻撃側は他人のクエリポートに話しかけ、より大きな応答を本来の標的に向けられます。この場合お使いのサーバーは被害者ではなく増幅器で、その回線が代金を払わされます。

そのため Valve は 2020 年 12 月 8 日に A2S_INFO へ前置きのチャレンジを追加しました。サーバーはまず S2C_CHALLENGE で応答し、要求した側はトークンを返さなければならず、それによって送信元アドレスを偽装していないことを証明します。これで増幅は弱まりますが、なくなりはしませんし、本物のアドレスから来る同種のクエリの単純なフラッドには、まったく効きません。

Palworld についてはここから、Source エンジンに対する重要な利点が導かれます。ゲームトラフィックとサーバーへの問い合わせが別々のポートに載っていることです。Counter-Strike 2 では両方がポート 27015 を共有しているため、粗いレート制限は自分のプレイヤーまで一緒に追い出します。Palworld では 27015 UDP を厳しく制限することも完全に閉じることもでき、8211 UDP を流れているゲームトラフィックに一切触れません。リストへの登録が必要ない人は、-publiclobby とクエリポートをそのまま削り、攻撃対象領域をひとつ丸ごとネットワークから外します。

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

次の手順はボリューム型攻撃を止めません。それはサーバー上のソフトウェアには不可能です。ただしその下にあるものはすべて片づけられます。ポートスキャン、クエリのフラッド、管理ポート経由の乗っ取り、そして 32 のスロット全部を他人に占められることです。これは日常で Palworld サーバーを妨げるものの大半で、かかる時間は 30 分です。

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

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

ss -lntup

注目するのはローカルアドレスの列です。0.0.0.0:8211 は「インターネット全体から到達できる」、127.0.0.1:8212 は「ローカルのみ」で、ファイアウォールルールは不要という意味です。育ってきたサーバーでは、ゲームのプロセスのほかに管理パネル、マップ表示用のウェブサーバー、データベースが並んでいることがよくあります。攻撃側からの見え方は、外部からのポートスキャンで分かります。

nmap -Pn -sU -p 8211,27015 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. Palworld が本当に必要とするものだけを開ける

許可は 2 つで足り、しかも 2 つ目は任意です。UFW では次のようになります。自分自身を締め出さないよう、この順番どおりに実行してください。

ufw allow 22/tcp comment 'SSH'
ufw allow 8211/udp comment 'Palworld ゲームトラフィック'
ufw allow 27015/udp comment 'Palworld Steam クエリ'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

サーバーをコミュニティサーバーリストに載せないなら、3 行目は省いてください。その場合もプレイヤーは IP アドレスとポート 8211 で接続を続けられ、サーバーは公開の一覧から消えるだけです。復旧手段まで含む詳しい手順は 自分を締め出さずに UFW ファイアウォールを設定する にあります。

3. 25575 の RCON と 8212 の REST API をインターネットから外す

どちらのポートもサーバーを完全に制御できる管理用の入口で、どちらも初期状態では無効です。RCONEnabled=False と RESTAPIEnabled=False です。有効にする人は、それで何を公開することになるのかを知っておくべきです。

8212 TCP の REST API は、固定のユーザー名 admin と AdminPassword の値による HTTP Basic 認証で認証し、しかも暗号化されていない HTTP を使います。つまり管理パスワードは、要求 1 件ごとに元に戻せる形で回線を流れます。25575 TCP の RCON も同じく暗号化されていないテキストプロトコルで、Pocketpair は REST API を優先して非推奨と位置づけています。新規の導入では REST API が正しい選択で、どちらにも同じ原則が当てはまります。開いたネットワークに出さないことです。

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="a long random value"

管理画面には SSH のポートフォワーディング経由で到達させ、そのうえでローカルの 127.0.0.1:8212 に対して作業します。

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

AdminPassword は決して空にしないでください。空が初期値です。openssl rand -base64 32 の値で足ります。ServerPassword についても同じで、これはすぐあとで詳しく触れます。

4. リストへの登録を失わずにクエリポート 27015 を制限する

接続を伴わない Steam のパケットは、4 バイトがすべて立った状態（0xffffffff）で始まり、通常のゲームトラフィックにはこのヘッダーがありません。ここに送信元アドレスごとのレート制限をかけられるため、クエリを抑えながらリストへの登録を保てます。nftables では nft -f で読み込みます。

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

優先度 -10 によって、このルールは UFW のフィルターチェーンより先に効き、@th,64,32 は UDP ヘッダーの後ろの最初の 4 バイトを読みます。従来の iptables では、A2S_INFO の識別子との照合で同じ切り分けができます。

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

アドレスごとに毎秒 10 件のクエリは余裕のある値です。一覧のサービスは通常、数分に 1 回問い合わせるだけで、毎秒何度も問い合わせはしません。大事なのはこのルールを 27015 に置き、8211 には置かないことだけです。そうしないと自分のプレイヤーに当たります。

5. 8211 UDP のパケットレートを制限する

ゲームポートそのものでは、送信元アドレスごとの上限が少数の送信元からの小さなフラッドに効きます。Palworld ではこの上限を設定するのが比較的安全です。同時に接続しているのは最大 32 プレイヤーで、それぞれがちょうど 1 つの送信元アドレスを占めるからです。

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

この数値は出発点で、絶対の正解ではありません。32 プレイヤーと多数の拠点がある満員のサーバーは、4 人で遊ぶ回よりはるかに多くのパケットを生みますし、厳しすぎる設定は自分のプレイヤーを追い出します。まずは平常時を 1 週間測り、それから測ったピーク値の 2 倍に上限を置いてください。

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

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

UFW を使っている場合、こうしたルールは /etc/ufw/before.rules にも書きます。そうしないと、次の ufw reload で消えてしまいます。ルールにそもそも到達しているかは iptables -L INPUT -n -v で分かります。一致カウンターが 0 のままなら、そのルールは効いていません。

6. スロット枯渇に対するサーバーパスワード、BAN リスト、32 のスロット

スロット枯渇は Palworld サーバーに対する最も安い攻撃で、帯域幅を必要としません。専用サーバーのスロットは最大 32 なので、集団全体を締め出すには同時接続が 32 あれば足ります。ボリューム型攻撃は依頼する側に費用がかかりますが、32 のセッションには費用がかかりません。そのため小さなサーバーでは、この経路がどんなフラッドよりも魅力的になります。

Palworld には許可リストが内蔵されていません。モデレーションの手段はキック、BAN、サーバーパスワードで、まさにこのサーバーパスワードがスロット枯渇に対する最も効く単独の手立てです。

ServerPassword="a value only your group knows"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword は初期状態では空なので、IP アドレスとポートを知っている人は誰でも入れます。BanListURL は既定では Pocketpair が管理する一覧を指しており、プロジェクト独自の禁止を運用したい場合は自分のテキストファイルに向け直せます。ServerPlayerMaxNum は 32 を超えて設定しないでください。より大きな値はサポートされておらず、遅くとも次の更新で跳ね返ってきます。そして 1 つはっきりさせておきます。サーバーパスワードが守るのはスロットで、回線ではありません。サーバーをあふれさせる攻撃側は、そもそも参加する気がありません。

7. 接続追跡の負荷を下げ、バッファーを大きくする

この項目は、ボリューム型攻撃のように見えて実はそうでない障害を説明します。カーネルは UDP のトラフィックについても接続追跡（conntrack）にエントリーを作り、送信元アドレスが偽装されている場合はアドレスごとに新しいエントリーになります。テーブルが埋まるとカーネルは区別なくパケットを破棄し、攻撃とご自身のプレイヤーがそろって追い出され、ログには「nf_conntrack: table full」と出ます。現在値と上限は次のコマンドで分かります。

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

最も効く手立ては、ゲームトラフィックをそもそも追跡させないことです。Palworld は自分のセッションを自分で管理しています。

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

iptables での対応は iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK と、OUTPUT 向けに --sport を使った同じ行です。そのあとポートには明示的な許可が必要になります。追跡がなければ、既存の状態を確認するルールはもう効かないからです。サーバーのプロセスが取り出すより速くパケットが届くと、加えて受信バッファーがあふれます。プレイヤーにはこれが、回線が空いているのにパケットロスとして見えます。/etc/sysctl.d/ の下に追加し、sysctl -p で反映させます。

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

これらの値が必要かどうかは、カーネル自身が教えてくれます。nstat -az で UdpRcvbufErrors が増えているなら効きます。カウンターが 0 のままなら、この調整は何も変えません。

8. 深刻になる前に測定値を集める

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

tcpdump では必ず -c で件数を区切ってください。全負荷の状態での取得は、すでに過負荷のサーバーにさらに負荷をかけます。Palworld には加えて、ほかのどの道具も持たない測定値があります。REST API が有効なら、メトリクスエンドポイントがサーバーのフレームレート、現在のプレイヤー数、稼働時間などを返します。

curl -s -u admin:YOUR_ADMIN_PASSWORD http://127.0.0.1:8212/v1/api/metrics

この 1 つの数値が、最も多い 2 つの原因をきれいに切り分けます。パケットレートに異常がないのにサーバーのフレームレートが落ちるなら、それは攻撃ではなく負荷か、よく知られたサーバープロセスのメモリ使用量の増加です。フレームレートが安定しているのに受信パケットが平常時の値を大きく超えるなら、それは攻撃です。ネットワークの値をひとつずつどう読むかは サーバーで DDoS 攻撃を検知する にあります。

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

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

一度計算してみてください。一般的なゲームサーバーは 1 Gbit/s の回線につながっており、これは毎秒 125 メガバイトで、誰かがそれより多く送った時点で回線は埋まります。ゲームサーバープロジェクトに対する攻撃は、通常 5 から 50 Gbit/s、つまりお使いの回線の 5 倍から 50 倍です。そうなるとその背後の iptables のルールが良いかどうかは関係なくなります。プレイヤーのパケットは、その手前で通れなくなっているからです。

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

Palworld サーバーには、さらに不利な比率が加わります。32 プレイヤーで満員のサーバーが使うのは、1 Gbit/s の回線のごく一部にすぎません。つまり攻撃は平常運用の何倍かに達するために大きくある必要がなく、だからこそ大きなプラットフォームでは目にも留まらない規模の攻撃で、ここでは足りてしまいます。

どの程度の規模が実際に起きるのかの目安として、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 アドレスをネットワークから外す事業者は、ご自身にとって攻撃側と同じ結果をもたらします。Palworld は専用の保護プロファイルを持つゲームのひとつで、ほかにどのタイトルとプロトコルが対象かは ゲームサーバーの DDoS 対策をリアルタイムで にまとめています。

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

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

• 専用の保護 IP をフランクフルトの中核から割り当て、お使いのサーバーを当社のネットワーク内でそれに切り替えます。ご自身の側で作り直す作業はありません。
• ポートとプロトコルごとに自分で管理できる保護ルールをカスタマーエリアで設定できます。8211 UDP で何を許可するか、27015 UDP で何を許可するかを別々に決められ、そのためにチケットを書く必要はありません。
• 変更はリアルタイムで反映されます。そのため攻撃が進行している最中に調整でき、たとえばクエリポートだけを一時的に厳しく制限し、ゲームポートには触れないようにできます。
• ゲームに合わせた保護プロファイルを用意しており、Palworld についても、任意の TCP または UDP ポートで動く独自のアプリケーションについても同様です。

Advanced DDoS Protection は KernelHost にあるサーバーを対象としています。Palworld のプロジェクトをいまよその事業者で運用していて継続的に攻撃されている場合は、そのために KernelHost へ移せば、提供開始時点から両方の段階が効きます。

2 つの段階の比較

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

Palworld サーバーでよくある失敗とその対処

「27015 を遮断したら、サーバーがコミュニティの一覧から消えた」：それは予想された挙動です。リストへの登録を担っているのがクエリポートだからです。一律で遮断するのではなく、手順 4 のようにコネクションレスパケットを送信元アドレスごとに制限してください。そもそもリストへの登録が必要ないなら、ポートは閉じたままにし、-publiclobby を削り、プレイヤーには直接接続用に IP アドレスとポート 8211 を渡してください。

「IP アドレスを変えたのに、2 時間後にまたオフラインになった」：攻撃側は新しいアドレスを、古いアドレスと同じ場所から手に入れています。Palworld ではほぼ必ず 3 つのうちのどれかです。アドレスをもともと直接接続の入力欄に入れているプレイヤー、それを新たに公開するステータス表示付きの Discord ボット、あるいは以前のアドレスを指す古い DNS の A レコードです。アドレスの変更は時間稼ぎであり、解決ではありません。

「サーバーにラグスパイクが出るのに、回線は静かだ」：Palworld ではこれは攻撃よりも負荷であることが多いです。サーバーのプロセスは稼働時間が伸びるにつれてメモリを着実に多く使うため、計画的な再起動は平常運用の一部であり、応急処置と考えるべきものではありません。メトリクスエンドポイントでサーバーのフレームレートと、プロセスのメモリ使用量を確認してください。そのとき sar -n DEV 1 10 に異常がないなら、DDoS 攻撃ではありませんでした。

「32 のスロットがすべて埋まっているのに、ゲーム内には誰も見えない」：それはスロット枯渇で、回線ではなくゲームのロジックに当たります。ServerPassword を設定し、目立つアカウントを BAN リストで遮断し、8211 UDP のパケットを送信元アドレスごとに制限してください。

「REST API を数日間、外から到達できる状態にしていた」：それなら管理パスワードは漏れています。暗号化されていない HTTP 上の HTTP Basic 認証は、要求ごとにそれを元に戻せる形で送るからです。AdminPassword を変え、8212 TCP を外向きに閉じ、この画面へは SSH のポートフォワーディング経由でしか到達しないようにしてください。

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

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

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

まとめ

• Palworld サーバーが開ける必要のあるポートはちょうど 1 つ、8211 UDP です。クエリポートの 27015 UDP は、コミュニティサーバーリストへの登録のためだけに必要です。
• 25575 TCP の RCON と 8212 TCP の REST API は、決して開いたネットワークに出すものではありません。どちらも認証情報を暗号化せずに送ります。RCON は Pocketpair によって非推奨とも位置づけられています。
• Palworld ではゲームトラフィックとサーバーへの問い合わせが別々のポートに載っているため、8211 UDP を流れているゲームトラフィックに触れずに 27015 UDP を厳しく制限できます。
• 専用サーバーはスロットが 32 に制限されているため、スロット枯渇が最も安い攻撃になります。それに対して最も効く単独の手立ては ServerPassword の設定です。Palworld には許可リストが内蔵されていないからです。
• ローカルの対策は回線で終わります。1 Gbit/s は毎秒 125 メガバイトで、64 バイトのパケットならそこに毎秒約 149 万パケットが入ります。それを超えるものは、サーバーの手前のネットワークで終わらせる必要があります。
• KernelHost では、2 段階の常時保護がすべてのサーバープランに追加料金なしで含まれ、提供開始時点から有効で、ヌルルーティングは行いません。専用の保護 IP とポートごとに自分で管理できるルールを備えた Advanced DDoS Protection は、月額 50.00 EUR から始まります。

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