MTA:SA サーバーを DDoS 攻撃から守る

Multi Theft Auto: San Andreas のサーバーは、DDoS 攻撃を受けたときの振る舞いが、ほかのどの GTA マルチプレイヤー系プロジェクトとも違います。3 つの独立したネットワークサービスを同時に提供しているからです。22003 UDP のゲームトラフィック、22005 TCP の本格的な HTTP サーバー、そして 22126 UDP の ASE クエリです。この 3 つはそれぞれ個別に攻撃でき、落ち方もそれぞれ違います。本記事ではまず、追加費用なしでご自身で固められる範囲を示し、次にその対策が回線の物理でどこで終わるのかを示し、最後に MTA:SA に効く DDoS 対策が、サーバーの手前のネットワークで何をしなければならないのかを説明します。

攻撃がいま進行中なら、最も大事な問いは 3 つのサービスのどれが狙われているかです。プレイヤーは接続を保っているのに、参加時にリソースを読み込めなくなっているなら、狙われているのは 22005 の HTTP サーバーです。接続済みのプレイヤーは普通に遊び続けられるのに、サーバーがブラウザーから消えたなら、狙われているのは 22126 の ASE クエリです。すべての接続が同時に切れるなら、標的は 22003 か、あるいは回線が埋まっています。本記事の記述はすべて、Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS 上の MTA サーバーを前提としています。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。

MTA:SA サーバーが DDoS 攻撃の標的になりやすい理由

MTA:SA のプロジェクトが都合のよい標的になるのは、自分の住所を自分で公開しなければならないからです。サーバーがゲーム内のブラウザーに現れるのは、マスターサーバーリストに登録し、そのうえで外からの問い合わせに応答する場合だけです。このリストには IP アドレスとポートが平文で載るため、攻撃側にとって事前の偵察は不要です。

そこにシーンそのものの事情が重なります。ドイツ語圏とブラジルのロールプレイ系サーバー、ドリフト系サーバー、DayZ 風の再現サーバーが同じプレイヤー層を取り合っており、ピーク時間帯の障害は最も目立ちます。BAN されたプレイヤー、仲違いしたチーム、競合プロジェクトのいずれも、一晩を使い物にならなくするのに技術もまとまった金額も必要としません。シーンで booter や stresser と呼ばれる、料金を払って利用できる攻撃サービスは、月に数ユーロでちょうど 2 つの結果を売っています。MTA サーバーを数分間オフラインにすること、あるいはラグスパイクで遊べなくすることです。DDoS 攻撃が技術的に何であり、どんな攻撃の種類があるのかは、記事 DDoS 攻撃とは何か で解説しています。

技術面では、MTA:SA はほかのマルチプレイヤー向け改造よりも 2 か所で攻撃側に有利です。第一に、クエリが独立した UDP ポートに載っており、たった 1 バイトの要求に対して数キロバイトの応答を返します。第二に、どの MTA サーバーにも HTTP サーバーが付属しており、すべてのリソースのクライアント側ファイルを、認証なしで求めてきた相手全員に配布します。

実際に問題になるポート

MTA:SA サーバーが必要とするポートはちょうど 3 つです。ゲーム用の 22003 UDP、内蔵 HTTP サーバー用の 22005 TCP、ASE クエリ用の 22126 UDP です。3 つ目は自由に選べる設定ではなく、ゲームポートに 123 を足した値として固定的に決まります。serverport を 22010 にした人は、クエリを 22133 で受けることになります。

付属の mtaserver.conf にそのまま書かれているのに、繰り返し見落とされる細かい点が 2 つあります。httpport は serverport と同じ数値でもかまいません。一方が TCP、もう一方が UDP だからです。そして serverip は auto になっており、そのままにしておくべきです。固定した値を書き込むと ASE のソケットがそのアドレスだけに束縛され、アドレスが変わった時点でリストへの登録が壊れます。

ASE クエリプロトコルと、それが増幅器になる理由

ASE（All-Seeing Eye）は純粋な UDP のクエリプロトコルです。パケットの最初の 1 バイトが応答を決め、接続確立の手順はありません。MTA サーバーは 5 種類のクエリを知っており、22126 でそれらに応答します。

• s は完全な ASE クエリです。応答は EYE1 で始まり、サーバー名、ゲームタイプ、マップ名、バージョン、パスワードの有無、プレイヤー数、setRuleValue で設定されたすべてのルールの完全な一覧、そのあとに接続中の全プレイヤーを名前、得点、ping 付きで含みます。この応答にはサイズの上限がありません。
• b と r は、ゲーム内のブラウザー向けのより軽いクエリです。応答は EYE2 で始まり、断片化を避けるためにソースコード内で 1340 バイトで切り詰められます。
• x は短縮されたステータス情報を返し、v は ASE のバージョン識別子だけを返します。

ここから問題が生まれます。要求はペイロード 1 バイトだけで構成され、回線上では 29 バイト（IP ヘッダー 20 バイト、UDP ヘッダー 8 バイト、ペイロード 1 バイト）です。ペイロード 1400 バイトの応答は、回線上では 1428 バイトになります。比率は約 49 倍で、しかも UDP には接続確立の手順がないため、送信元アドレスを偽装できます。つまり攻撃側は、お使いのサーバーに一度も入らないまま、第三者への増幅器として使えるわけです。完全クエリでは、この倍率がプレイヤー数と、ゲームモードが設定するルールの数だけ大きくなります。

これに対して MTA は 2 つの歯止めを内蔵しており、どのフラッドが効いてどれが効かないのかを説明してくれるので、知っておく価値があります。サーバーは送信元アドレスごとに 6 秒間で最大 5 件のクエリに応答し、そのあと 7 秒間はそのアドレスを無視します。さらに応答を 10 秒間キャッシュし、要求ごとに組み立て直すことをしません。ところが送信元アドレスごとの数え上げは、一覧に 100 を超える異なる送信元アドレスが同時に並んだ瞬間に、まるごと飛ばされます。ボットネットからの分散したフラッドや、偽装した送信元では、まさにそれが通常の状態です。だから内蔵の歯止めは、本気の攻撃には効きません。

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

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

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

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

ss -lntup

予想されるのは MTA プロセスの 3 行、UDP の 0.0.0.0:22003、TCP の 0.0.0.0:22005、UDP の 0.0.0.0:22126 です。そこに加えて 0.0.0.0:3306 のデータベース、ウェブサーバー、忘れられたボイスサービスが現れるなら、それは止めるべきものです。攻撃側からの見え方は、外部からのポートスキャンで分かります。

nmap -Pn -sU -p 22003,22126 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p 22005 YOUR.SERVER.IP.ADDRESS

サーバー自身も、そのための専用コンソールコマンドを備えています。サーバーコンソールで openports を実行すると、3 つのポートすべてが外から到達可能かどうかを確認できます。

2. MTA が本当に必要とする 3 つのポートだけを開けておく

UFW では、実用に足る出発点の設定は次のようになります。自分自身を締め出さないよう、この順番どおりに実行してください。

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA ゲーム'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

復旧手段まで含む詳しい手順は、記事 UFW ファイアウォールを設定する にあります。KernelHost の KVM ルートサーバーと専用サーバーでは、回線が飽和している場合でも、カスタマーエリアの VNC コンソール経由でシステムに入れます。

データベースはインターネットに出すものではありません。ss -lntp | grep 3306 が 0.0.0.0:3306 を示すなら、/etc/mysql/mariadb.conf.d/50-server.cnf に bind-address = 127.0.0.1 の行を設定し、サービスを再起動してください。

3. サーバーリストから外れずに ASE ポートを制限する

SA-MP と違い、MTA:SA ではクエリが独立したポートに載っているため、ゲームの動作とは無関係に制限できます。これがこの構成の実務上いちばん大きな利点です。22126 に対するルールは、プレイヤーを 1 人も追い出しません。

ルールセットが UFW と干渉しないよう、nftables では専用のテーブルに置きます。

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

1 つ目のルールは個々の送信元アドレスを、2 つ目はポート全体を制限します。両方そろっていることが大切です。アドレスごとにしか制限しないと、分散したフラッドは多数の単一送信元のあいだの隙間を通り抜けます。数値は厳しく取っていますが、ここではそれが妥当です。本物のサーバーブラウザーは、数秒に 1 回しかお使いのサーバーに問い合わせません。iptables なら hashlimit モジュールで同じことができます。

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

ポートを完全に閉じてしまう手は、裏技ではなく単なる取引です。ASE がなければお使いのサーバーはゲーム内のブラウザーから消え、自然に入ってくる新規プレイヤーの流れも消えます。それでもやりたい場合、<ase>0</ase> だけでは足りません。ソースコードでは、このポートの開放がインターネットモードと LAN モードの論理和にかかっています。つまり <donotbroadcastlan>0</donotbroadcastlan> が書かれている限り、<ase>0</ase> でもソケットは開いたままです。本当にポートを閉じたい人は、両方を設定します。

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

成長中のプロジェクトにとってより誠実な道はこうです。ポートは開けたままにし、レートを制限し、ゲームモードが setRuleValue で不要なルールを公開しないようにして増幅の効果を小さく保つ。ルールは 1 つ 1 つが完全クエリに載り、応答を大きくします。

4. 内蔵の HTTP サーバーの負荷を下げる

22005 の HTTP サーバーは、MTA:SA では独立した攻撃対象領域です。参加してくるプレイヤー全員が、稼働中の全リソースのクライアント側ファイルをそこからダウンロードするからです。独自モデルを持つロールプレイ系のプロジェクトでは、それがすぐに数百メガバイト、数百個の個別ファイルに分かれた形になります。内蔵サーバーは意図的に簡素な作りです。圧縮はなく、ワーカースレッドの数も固定の割り当てしかありません。数十件の同時取得があれば、本物のプレイヤーが数分間ロード画面で止まります。

最も効く手立ては、ダウンロードをゲームサーバーから完全に切り離すことです。MTA は配布すべきファイルを自分で mods/deathmatch/resource-cache/http-client-files に用意しています。このフォルダーを nginx か lighttpd で公開し、そのアドレスを mtaserver.conf に書きます。

<httpdownloadurl>http://cdn.your-domain.tld/mta</httpdownloadurl>

これで 2 つのことが同時に得られます。ダウンロードがそのために作られたウェブサーバーを通るようになり、しかもゲームサーバーのアドレスを通らなくなります。ウェブサーバーが別のマシンにあるか、コンテンツ配信ネットワークの背後にあるなら、ダウンロードに対するフラッドはゲームの動作に当たらなくなります。注意点として、外部アドレスが間違っているか到達できない場合、MTA は何も言わずに内蔵サーバーへ戻ります。

内蔵サーバーを使い続ける場合は、それ自身の上限を使ってください。mtaserver.conf では次のようになります。

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

httpmaxconnectionsperclient はクライアントごとの同時接続を、1 から 8 の許容範囲のうち 5 に制限します。httpdosthreshold は 1 つの IP アドレスが短時間に確立できる接続の数を制限し、初期値は 20 です。http_dos_exclude は個別のアドレスをそこから除外します。たとえばご自身のステータスページです。httpthreadcount はワーカースレッドの数を決め、初期値は 8、範囲は 1 から 20 です。値を上げると小さなファイルが多い場合に効きますが、ゲームの動作から計算時間を奪います。

さらに、同じポートで何がほかに配布されているかも考えてください。リソース webadmin と resourcebrowser は付属の設定では起動しており、22005 経由でブラウザーから到達できます。管理画面を無防備にインターネットへ出してはいけません。acl.xml で権限をきちんと割り当て、長いランダムなパスワードを持つ専用アカウントを用意し、必要ないときはそのリソースを停止してください。

5. mtaserver.conf にある内蔵の上限を使う

MTA には、ほとんどのプロジェクトが使っているよりも多くの保護上限が備わっています。一部はソースコードに固定されており、一部は mtaserver.conf にあります。次の表は、攻撃の際に役割を果たすものをまとめたものです。

3 つの設定は、意識して決める価値があります。maxplayers は 32 になっており、実態に合わせるべきです。スロットが 1 つ増えるごとに完全クエリが大きくなり、攻撃側が占有できる接続の数も増えます。bandwidth_reduction は medium になっており、maximum にすると送信側の負荷が目に見えて下がりますが、同期の精度を失います。そして <password></password> は、手間なしでお使いのサーバーを閉じた輪に変えつつ、リストへの登録は残します。参加フラッドが進行している最中の、最も速い非常ブレーキです。

6. 参加フラッドとイベントフラッドを区別する

2 つの攻撃パターンは回線ではなくゲームのロジックを狙うもので、しかも繰り返し混同されます。

参加フラッドは、すべてのスロットが埋まるか、サーバーが接続確立に追いつかなくなるまで、本物の接続を次々に張ります。MTA はこれを自ら、送信元アドレスごとに 30 秒間で 4 接続に制限し、そのあと 30 秒間はそのアドレスを無視します。歯止めがいま何をしているかは、コンソールコマンド debugjoinflood で分かります。この上限はアドレスごとに効くため、1000 のアドレスを持つボットネットは素通りします。それに効くのはサーバーパスワード、ゲームモード内の許可リスト、そして 22003 に対するレート制限です。

いっぽうイベントフラッドは、すでに接続しているプレイヤーから来ます。改造されたクライアントが triggerServerEvent をループで送り続け、サーバーが計算時間を出せなくなるまで続けます。MTA は初期設定でプレイヤー 1 人あたり毎秒 100 件のイベントを許し、それを超えるとイベントフラッドについてのメッセージを出します。ゲームモードが小さなイベントを多用している場合は、値を下げる前に確認してください。狭く設定しすぎると、自分のプレイヤーを追い出します。

それとは別に、サーバー側ではどこでも同じ原則が当てはまります。クライアントが送ってくる値を決して信用せず、プレイヤーはイベントの送信元から特定し、データベースへの問い合わせを起こすものはすべて制限する。検査していないイベントが 1 つでも問い合わせを始めるなら、ネットワーク攻撃を 1 つも使わずにサーバーを止められます。

7. サーバーリスト、IP アドレス、そこから漏れるもの

お使いの IP アドレスは秘密にできません。一度でも接続したプレイヤーは全員それを知っており、マスターサーバーリストへの登録はどうせそれを公開します。手前にドメインを置いても助けになりません。クライアントは名前を一度だけ解決し、そのあとはアドレスと直接やり取りします。

代わりに、お使いのアドレスがほかにどこから漏れているかを確認してください。MTA のプロジェクトでよくある漏れ口は、DNS に残った古い A レコードと AAAA レコード、同じマシンに置かれたプロジェクトのサイト、ASE クエリを公開で読み出すステータス表示付きの Discord ボット、古いホスト名が入った TLS 証明書、そして初期のフォーラム投稿です。ここから、多くのプロジェクトが学ぶのが遅すぎる 1 つの原則が出てきます。保護されたアドレスに移るときは、同時に古いアドレスも変えてください。古いアドレスが残っていると、それはあらゆるスキャナーのデータベースに載っており、攻撃は保護の横を通り抜けます。

mtaserver.conf の 2 つの項目は、可視性に直接関わります。<serverip>auto</serverip> は、はっきりした理由がない限り auto のままにします。そして <owner_email_address> は埋めるべきものです。項目が欠けていたり間違っていたりすると、マスターサーバーリストでの可視性に影響することがあります。

8. 攻撃中にデータがあるようログを取る

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

障害の最中は、まず 3 つのポートを切り分けます。次の 4 つのコマンドで足ります。

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

読み取りは見た目より簡単です。CPU 負荷が低いままバッファーのエラーが増えるなら、プロセスが処理しきれる量を超えたトラフィックが届いています。トラフィックが正常に見えるのに 1 つのコアが振り切れているなら、問題はネットワークではなくゲームモードにあります。22126 の取得で、ペイロードが 1 バイトだけのパケットが多く見えるなら、それは ASE フラッドです。22005 の開いた接続の数が四桁で居座るなら、狙われているのは HTTP サーバーです。tcpdump では必ず -c で件数を区切ってください。全負荷の状態での取得は、すでに過負荷のサーバーにさらに負荷をかけます。測定値をひとつずつどう読むかは、記事 サーバーで DDoS 攻撃を検知する で説明しています。

サーバーのログそのものは logs/server.log に、スクリプトのログは logs/scripts.log にあります。どちらのパスも mtaserver.conf にあり、移動できます。

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

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

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

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

MTA:SA にはもう 1 つ、最も早く効く 3 つ目の限界があります。サーバーはネットワークポートを 1 つの処理の流れで読み取ります。22126 に対するクエリフラッドはこの流れを占めてしまうため、回線が埋まるはるか前に、本物のプレイヤーの同期パケットが受信バッファーで無駄になります。プロセスはそれで落ちるのではなく、ただ遅くなり、プレイヤーにはラバーバンド現象として見えます。HTTP サーバーについても同じです。こちらもゲームの動作と計算時間を分け合っています。

どの程度の規模が実際に起きるのかの目安として、KernelHost のサーバーでは、ボイスサーバーに対する毎秒 4150 万パケット超で 473.4 Gbit/s 超の攻撃と、ゲームサーバーに対する毎秒 870 万パケット超で 112.2 Gbit/s 超の UDP フラッドが除去されています。前者は、1 Gbit/s の回線が受け取れる帯域幅の約 473 倍、パケットレートの約 28 倍です。これに対応するローカルの設定はありません。ボリューム型攻撃は、サーバーの手前のネットワークで終わらせる必要があります。

KernelHost が用意している対策

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

KernelHost のどのサーバーも、常時動いている 2 段階のフィルタリングの背後にあります。

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

決定的な性質が 3 つあります。保護は常時動いているため、サーバーがオフラインになる検知の待ち時間がありません。ヌルルーティングは使いません。攻撃を受けたアドレスはネットワークに残り、破棄されるのは有害なパケットだけで、本物のプレイヤーの接続は続きます。そして追加費用はかからず、提供開始時点からすべてのサーバープランに含まれます。KVM ルートサーバーからゲームサーバー、専用サーバーまで同じです。フィルタリングはレイヤー 3、4、7 で、あらゆる TCP ポートと UDP ポートに対して行われます。つまり 22003 UDP、22005 TCP、22126 UDP に同時に効きます。運用はドイツのフランクフルトにあるデータセンター maincubes で行っています。どのゲームとプロトコルに専用プロファイルがあるかは、記事 ゲームサーバーの DDoS 対策をリアルタイムで にまとめています。

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

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

• 専用の保護 IP をフランクフルトの中核から割り当てます。お使いのサーバーは KernelHost のネットワーク内でそれに切り替えられるため、ご自身の側で作り直す作業はありません。
• ポートとプロトコルごとに自分で管理できる保護ルールをカスタマーエリアで設定できます。MTA:SA ではまさにここが要点です。22003 UDP、22005 TCP、22126 UDP に別々のルールを設定できるため、性質のまるで違う 3 つのサービスを一律に扱う必要がありません。
• 変更はリアルタイムで反映されます。チケットも待ち時間も要りません。つまり攻撃が進行している最中に調整できます。
• ゲームに合わせた保護プロファイル。Multi Theft Auto は専用プロファイルとして用意されており、ウェブサーバー、ボイスサーバー、同じ保護アドレスの背後に収まる独自の TCP または UDP アプリケーションも同様です。

2 つの段階の比較

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

よくある失敗とその対処

「22126 を遮断したのに、サーバーはどのリストにも出ないままで、それでもクエリが届き続ける」：それならソケットはまだ開いています。<donotbroadcastlan>0</donotbroadcastlan> が設定されている限り、<ase>0</ase> だけではポートは閉じません。ss -lnup | grep 22126 で、本当に何も待ち受けていないかを確認してください。

「プレイヤーがロード画面で止まるが、ゲームそのものは普通に動いている」：それは 22003 への攻撃ではなく、22005 の HTTP サーバーが限界に来ています。httpdownloadurl でダウンロードを外に出し、httpmaxconnectionsperclient と httpthreadcount を確認してください。

「サーバーがブラウザーから消えたのに、入っているプレイヤーは何も気づいていない」：それなら狙われているのは 22126 だけです。接続済みのプレイヤーには影響がありませんが、新規プレイヤーの流入には影響します。正しい答えはこの 1 つのポートに対するレート制限で、ゲームポートに対するものではありません。

「IP アドレスを変えたのに、2 時間後にまたオフラインになった」：攻撃側は新しいアドレスを、古いアドレスと同じ場所から手に入れています。多くはリストへの登録、ステータスを問い合わせる Discord ボット、あるいは古い DNS レコードです。アドレスの変更は時間稼ぎであり、解決ではありません。

「22003 にアドレスごと毎秒 20 パケットのレート制限をかけた」：それは厳しすぎます。同期が活発なときは 1 人のプレイヤーだけでもそれを超えますし、同じ NAT アドレスの背後にいる複数のプレイヤーは同じ枠を分け合います。それでは自分のプレイヤーを追い出します。いっぽう 22126 では、厳しい値でも問題になりません。

「ファイアウォールで自分を締め出した」：再起動は助けになりません。UFW は起動時に自分のルールを復元するからです。KernelHost ではカスタマーエリアの VNC コンソールを開き、そこで ufw disable を実行してください。VNC コンソールはゲスト側のネットワークに依存せず動作します。

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

「攻撃が終わるのを待つだけにしている」：効いた攻撃は繰り返されます。時刻をタイムゾーン付きで、継続時間、ピーク値、対象になったポートを記録してください。サポートチケットにも、まさにこの情報が必要です。フィルタリングを狙って調整するためです。

まとめ

• MTA:SA サーバーが必要とするポートはちょうど 3 つです。ゲーム用の 22003 UDP、内蔵 HTTP サーバー用の 22005 TCP、ASE クエリ用の 22126 UDP です。3 つ目はゲームポートに 123 を足した値として固定的に決まります。
• ASE クエリは独立したポートに載っているため、プレイヤーを 1 人も締め出さずに制限できます。これが SA-MP との最も重要な違いです。SA-MP ではゲームとクエリが同じポートを共有しています。
• 22126 に届いたたった 1 バイトの要求が、最大で数キロバイトの応答を生み、しかも送信元アドレスは偽装できます。制限のない ASE ポートは、標的と増幅器の両方になります。
• MTA が内蔵する歯止めは送信元アドレスごとに効きます。6 秒間に 5 件のクエリ、30 秒間に 4 件の参加です。同時の送信元アドレスが 100 を超えるとクエリの数え上げが飛ばされるため、分散したフラッドは素通りします。
• 22005 の内蔵 HTTP サーバーは独立した攻撃対象領域です。httpdownloadurl でダウンロードを外部のウェブサーバーに出せば、それをゲームの動作から切り離せます。
• サーバー上で動くものはすべて、小規模な攻撃についてしか判断できません。1 Gbit/s では毎秒約 149 万パケットで終わりで、ルールの出来とは無関係です。
• KernelHost の 2 段階の常時保護はすべてのサーバープランに追加料金なしで含まれ、ヌルルーティングなしで動作します。ポートごとのルールを自分で制御したい場合は、月額 50.00 EUR からの Advanced DDoS Protection を追加します。

プロジェクトをすでに KernelHost で動かしている場合、フィルタリングは常時有効なので、何も有効化する必要はありません。それでも異常に気づいたときは、期間、ポート、観測した挙動を添えて サポートチケット を開いてください。お使いのアドレス向けにルールを調整します。攻撃が進行中の場合は、WhatsApp の緊急チャット +43 650 8209883 でもご連絡いただけます。よその事業者でホスティングしていて定期的に攻撃を受けているなら、フランクフルトへの移転のほうが近道です。いま起きている場合の次の手順は、記事 深刻な DDoS 攻撃を受けたらどうするか にあります。