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

夜のセッションの途中で消え、10 分後にまた現れる RedM サーバーは、ハードウェアに問題があることはまずありません。多くの場合、ポート 30120 を狙った攻撃が走っており、しかもプレイヤーが最も多くオンラインにいる時間帯を選んで走ります。本記事では、RedM サーバーを DDoS 攻撃から守る方法を示します。まず、追加費用なしでご自身で固められる範囲、次にその対策の物理的な限界、最後に、攻撃がお使いの回線より大きい場合にサーバーの手前のネットワークで何が起きる必要があるかです。

本記事の記述はすべて、Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS 上で gamename rdr3 を設定して動く FXServer を前提としています。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。RedM は Cfx.re による Red Dead Redemption 2 の改造環境で、FiveM の姉妹プロジェクトです。両者は同じサーバープログラムで動くため、ネットワーク技術の一部は本当に同一です。該当する部分は本記事では 1 文で触れ、詳しい説明は記事 FiveM サーバーを DDoS 攻撃から守る にあります。本文のそれ以外の内容は RedM 固有のものです。

攻撃がいま進行中の場合：server.cfg は変更せず、サーバーも再起動しないでください。まずは測定値を保存します（「測定値を集める」の節を参照）。攻撃が終わってからでは、もう残っていません。

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

RedM サーバーは、そのプレイヤー数から想像されるより値打ちのある標的です。理由は、まさにこのシーンの規模が小さいことにあります。2026 年 9 月、公開されているサーバーリストの集計サイトは、稼働中の RedM サーバーを約 2000 台、同時接続プレイヤーを約 1.24 万人と数えており、これに対して FiveM は約 3.9 万台のサーバーと約 32.5 万人のプレイヤーでした。2000 台の RedM サーバーのうち 1 台を止めれば、3.9 万台の FiveM サーバーのうち 1 台を止めるより、シーン全体に対してはるかに大きな割合をネットワークから奪うことになります。つまり競合プロジェクトに損害を与えたい攻撃側にとって、ここでのてこの効きは比べものになりません。

加えてコミュニティの構造があります。RedM のロールプレイは、決まった時刻の固定したセッションで成り立っており、多くは事前登録とキャラクターの承認を伴います。20 時の障害は、たまたまいたプレイヤーではなく、その晩のために登録した人たちをそのまま狙い撃ちにします。さらに多くのプロジェクトは小さな予算の趣味として運営され、1 台の安価なサーバーに依存し、切り替えられる 2 つ目のインスタンスを持ちません。RedM のシーンで公開されている事例には、何か月にわたりほぼ毎日の間隔で続き、ゲームサーバーと別立てのボイスサーバーを同時に襲った攻撃の連続が記録されています。

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

実際に問題になるポート

RedM サーバーは初期設定で 1 つのポートだけにバインドし、しかも両方のプロトコルで待ち受けます。server.cfg には次のように書かれています。

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

set gamename rdr3 の行は、RedM サーバーを FiveM サーバーと区別する唯一の記述です。これが欠けていると、同じ FXServer が GTA V のサーバーとして登録され、RedM のクライアントは接続できません。RedM には独自のクエリポートも独自の RCON ポートもありません。サーバーへの問い合わせ、接続確立、ゲームトラフィック、RCON はすべて、30120 の同じ 2 つの記述を通ります。数字で見ると次のようになります。

挙げた 4 つのポートのうち、開いたネットワークに置いてよいのはちょうど 2 つ、30120 TCP と 30120 UDP です。ポート 40120 とポート 3306 はそこに属さず、ポート 22 の SSH はご自身のアドレスだけに限定すべきです。これは RedM サーバーで最も多い、避けられるはずの失敗です。多くのプロジェクトが既製の txAdmin のレシピで立ち上げ、そのあとサーバーが外に何を提供しているかを一度も確認しないからです。

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

この節が最も長いのは意図的です。きちんと設定された RedM サーバーは、どこに置かれていようと、小規模から中規模の攻撃を自力で耐えます。順番は意図して選んでいます。まず測り、次に閉じ、そのあとで初めて制限します。

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

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

ss -lntup

注目するのはローカルアドレスの列です。0.0.0.0:30120 と [::]:30120 は「インターネット全体から到達できる」、127.0.0.1:3306 は「ローカルのみ」で、ファイアウォールルールは不要という意味です。RedM サーバーでは FXServer のほかに、40120 の txAdmin、3306 の MariaDB、プロジェクトのページ用のウェブサーバー、ときにはボイスサービスが並んでいることがよくあります。攻撃側からの見え方は、外部からのポートスキャンで分かります。

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

2. 30120 の TCP と UDP だけを開けたままにする

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

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'RedM'
ufw allow 30120/udp comment 'RedM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

203.0.113.10 はご自身のアドレスに置き換えてください。アドレスが変わる回線では扱いにくいため、より良い方法は次の txAdmin の節にあります。復旧手段まで含む詳しい手順は 自分を締め出さずに UFW ファイアウォールを設定する にあります。

データベースは、どんな場合でも開いたネットワークに出してはいけません。VORP、RSGCore、RedEM:RP はいずれも MariaDB か MySQL を必要とし、多くは oxmysql を通じて server.cfg の接続文字列で接続します。この接続はローカルで完結するため、ポートが外から到達できる必要はありません。/etc/mysql/mariadb.conf.d/50-server.cnf に次の記述があるか確認してください。

bind-address = 127.0.0.1

3. FXServer の HTTP エンドポイントを固める

FXServer は 30120 の TCP 側で HTTP のリクエストに応答します。誰かが Red Dead Redemption 2 を起動する必要はありません。お使いの RedM サーバーがそこで何を返しているか、見てみてください。

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600
curl -s http://127.0.0.1:30120/dynamic.json

/players.json は接続中のプレイヤーとその識別子を、/info.json はサーバーの設定と読み込まれているリソースを、/dynamic.json は現在の使用状況を返します。この 3 つのエンドポイントこそが、FiveM と RedM のサーバーに対して記録されているレイヤー 7 の攻撃経路です。認証なしで到達でき、何度でも問い合わせられ、問い合わせ 1 件ごとにサーバーの作業が発生し、その内容は攻撃側に「いつ攻撃する価値があるか」を教えます。費用のかからない対策が 2 つあります。第一に、プレイヤーの接続元は応答に含めるべきではありません。それには server.cfg に 1 行あれば足ります。

sv_endpointPrivacy true

この設定は、サーバーの公開出力からプレイヤーの IP アドレスを隠します。第二に、Discord のボットやプロジェクトのページでプレイヤー数を表示している場合、訪問者からエンドポイントを問い合わせるのではなく、一定の間隔で結果を保存して使い回してください。これで、訪問の多いステータスページでも問い合わせは訪問者ごとではなく間隔ごとに 1 件になります。RedM のような小さなシーンでは、この効きが二重になります。1 つのサーバーステータス用ボットが、複数の Discord サーバーに同時に組み込まれていることがあるからです。

4. ポート 40120 の txAdmin を開いたネットワークから外す

txAdmin は FiveM と RedM 向けの FXServer ビルドに含まれる管理画面で、初期設定では 40120 TCP で待ち受けます。その先にはサーバーへの完全なアクセスがあります。再起動、BAN リスト、プレイヤーのデータベース、リソースの管理です。開放用の固定 IP アドレスがない場合は、このポートを外から閉じたままにし、SSH のローカルポートフォワーディング経由で到達してください。そのあとブラウザーで http://127.0.0.1:40120 を開きます。

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

txAdmin を公開したままにすると、問題が同時に 2 つ生まれます。ログインフラッドを仕掛けられるログイン画面と、ゲームとは関係がないのにリクエストごとに作業をするサービスです。迷うなら、txAdmin を 127.0.0.1 だけで待ち受けさせて、最初からローカルに閉じてください。

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

小規模な攻撃や作りの粗いボットには、送信元アドレスごとの上限が効きます。次の 2 つのルールは 30120 に対するもの、つまりこのゲームの両方のプロトコルに対するものです。

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

1 つ目のルールは、1 つのアドレスが同時に 8 本より多く開いた時点で新しい TCP 接続を破棄し、2 つ目は同じ送信元から毎秒 500 パケットを継続して超えた UDP パケットを破棄します。ここでの出発点の値は FiveM サーバーより少し低く置いています。32 スロットの RedM サーバーは、アドレスごとに生む正規の接続が単純に少ないからです。ただし出発点の値は絶対の正解ではありません。満員のロールプレイの夜は空のサーバーよりはるかに多くのパケットを生みますし、厳しすぎる設定は自分のプレイヤーを追い出します。まずは平常時を 1 週間測ってください。

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

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

UFW を使っている場合、こうしたルールは /etc/ufw/before.rules に書きます。そうしないと、次の ufw reload で消えてしまいます。さらに見落とされがちな詰まりどころが、カーネルの接続追跡です。あふれると、サーバーは正規のパケットまで破棄し、ログには「nf_conntrack: table full」と出ます。現在値と上限は次のコマンドで確認できます。

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. 32 スロットを参加フラッドから守る

RedM サーバーのスロット数は、OneSync なしでちょうど 32 です。OneSync ありで 48、それを超えるには 1024 席まで対応する Element Club の契約が必要です。この数はセキュリティに関わります。攻撃側が埋めなければならない上限そのものだからです。参加の試行を同時に 32 本開いたままにすれば、プレイヤーが 1 人も実際にゲーム内に到着しないまま、標準構成のサーバーを完全に占有できます。128 席の FiveM プロジェクトでは、同じしきい値が 4 倍になります。

RedM 固有の利点がこれを部分的に打ち消します。RedM は Red Dead Redemption 2 の本物のコピーを前提とし、Steam、Epic Games、Rockstar のいずれで購入したかは問わず、あわせて Rockstar のランチャーも必要です。つまり無料のゲームでよく見られる、何千もの使い捨てアカウントによる参加フラッドは、ここでは実際に金銭を要します。そのため攻撃は、ゲームのコピーが不要なネットワーク層と HTTP エンドポイントへ移ります。

それでも、通常の参加経路を使うものすべてには許可リストが効きます。実装はサーバー側のイベント playerConnecting で行い、そこで deferrals の仕組みを使って接続を保留し、識別子を検査し、そのあとで初めて通します。あわせて厳しいアカウント検査と、現実的なプレイヤー数の上限も設定します。

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance は 1 から 5 の値で、あるプロバイダーでプレイヤーの識別子がどれだけ変わってよいかを指定します。1 が最も厳しい設定です。sv_authMinTrust も 1 から 5 の範囲で、偽装された身元がどれだけありえないものでなければならないかを表します。こちらは 5 が最も厳しい値です。RCON のパスワードは、RCON が本当に必要な場合にだけ設定してください。この経路は同じ開いたポート 30120 に載っているからです。そして、はっきりさせておくべきことが 1 つあります。許可リストが守るのはゲームのロジックで、回線ではありません。お使いのサーバーをあふれさせる攻撃側は、そもそも参加する気がありません。そのパケットは拒否されますが、それでも届いてはいます。まさにそこが問題です。

7. RedM のサーバーリストへの掲載を正しく見積もる

ここは願望ではなく事実で考えたほうが得です。お使いの IP アドレスは秘密にできません。RedM は FiveM と同じ Cfx.re のマスターサーバー基盤を使い、リストの項目には connectEndPoints という項目に接続先が平文で入っています。servers-frontend.fivem.net の公開インターフェースを通じて、どの cfx.re コードからも対応するアドレスを問い合わせられ、これは RedM でも FiveM でも同じです。プロジェクトが Discord と直接接続だけで動いていて公開の掲載がまったく不要なら、sv_master1 "" でサーバーを非公開として運用できます。その場合、サーバーリストからは参加できなくなります。ただしこれは新しいプレイヤーからの見つけやすさをすべて失うことを意味し、2000 台のサーバーがあるシーンでは、見つけやすさこそが本来の成長の原動力です。

より効くのは 2 つの習慣です。生の IP アドレスをご自身でどこにも公開しないこと、つまり Discord のチャンネルにもプロジェクトのページにも書かないことです。そして、いざというときにすべての参照が壊れずにアドレスを変えられるよう、プレイヤーはホスト名で接続させてください。よくあるのが古い DNS レコードです。以前のアドレスを指す A レコードが 1 つ残っていると、どんな変更も無意味になります。

8. VORP、RSGCore、RedEM のイベントをサーバー側で検査する

DDoS 攻撃として報告される障害の多くは、たった 1 つのスクリプトに原因があります。RedM のリソースはネットワークイベントで通信し、サーバーが検査せずに実行するイベントは開いた扉です。クライアントで任意の値を付けて TriggerServerEvent を投げれば、ドルを生み出し、馬を出現させ、あるいはループでデータベースへの問い合わせを起こしてサーバーを止められます。これは普及している 3 つのフレームワークすべてに同じように当てはまります。2020 年以来もっとも大きなスクリプト基盤を持つ VORP Core、RSGCore、そして古参の RedEM:RP です。

とくに弱いのは在庫とキャラクターのリソースです。呼び出しごとにデータベースへ書き込むからです。1 秒に 10 回在庫の状態を保存するイベントループは、たいていのパケットの洪水より強く RedM サーバーに負荷をかけますし、しかも内側から来るため、ファイアウォールは効きません。

3 つの原則で、その大半を受け止められます。RegisterNetEvent で登録するのは、本当にクライアントから来るべきイベントだけにしてください。クライアントが送ってくる値は決して信用せず、プレイヤーは source からサーバー側で特定してください。そして、同じイベントを 1 人のプレイヤーが何回起こせるかを制限してください。とくにデータベースへの問い合わせを含むものすべてで必要です。回線が静かなのにサーバーが重いときは、クライアントのコンソールで resmon 1 を実行すればリソースごとの計算時間が分かり、たいていは原因がいちばん上に出ます。

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 port 30120 -c 200 -q

tcpdump では必ず -c で件数を区切ってください。全負荷の状態での取得は、すでに過負荷のサーバーにさらに負荷をかけます。あわせて、負荷が 30120 の UDP 側にあるのか TCP 側にあるのかにも注意してください。UDP の負荷はゲームトラフィックに向けたパケットの洪水を、TCP の負荷は HTTP エンドポイントに向けた洪水を示し、どちらも必要な対策が異なります。測定値の読み方は DDoS 攻撃を検知する にあります。

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

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

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

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

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

RedM が FiveM と違う点

短く答えると、ネットワーク技術は同一で、周辺の条件は同一ではありません。どちらも同じ FXServer で動き、どちらも 30120 の TCP と UDP を使い、どちらも 40120 の txAdmin で管理します。上に書いたポート、レート、エンドポイントの話はすべて両方に当てはまります。違うのは前提条件で、攻撃がどれだけ早く効くかは、まさにそこで決まります。

この表のうち 3 点が防御にとって決定的です。第一に、シーンが小さいことが RedM サーバー 1 台ごとの標的としての価値を高めます。障害がプレイヤー全体のうち大きな割合に及ぶからです。第二に、32 スロットという初期の上限は、参加の洪水がサーバーを閉ざすまでのしきい値を下げます。第三に、RedM 向けの既製の防御レシピは FiveM 向けより少ないため、多くのプロジェクトが初期設定のまま動いています。防御の方法は同じで、出発点の状態が悪いのです。

KernelHost が用意している対策

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

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

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

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

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

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

• 専用の保護 IP をフランクフルトの中核から割り当て、お使いのサーバーを当社のネットワーク内で切り替えます。ご自身の側で作り直す作業はありません。
• ポートとプロトコルごとに自分で管理できる保護ルールをカスタマーエリアで設定できます。30120 UDP で何を許可するか、30120 TCP で何を許可するかを分けて指定でき、そのためにチケットを書く必要はありません。RedM ではとくにこの分離が役に立ちます。ゲームトラフィックと HTTP エンドポイントが同じポート番号に載っていて、パターンがまったく異なるからです。
• 変更はリアルタイムで反映されます。そのため、攻撃が進行している最中に調整できます。
• アプリケーションに合った保護プロファイル。30120 の Cfx.re サーバー向けに適したプロファイルがあり、改造したアプリケーションや独自のアプリケーションを任意の TCP または UDP ポートで動かす場合にも対応します。

どちらも、KernelHost に置かれているサーバーが対象です。お使いの RedM プロジェクトが現在よそで動いており、定期的にネットワークから撃ち落とされているなら、おすすめは追加の製品ではなく移転です。

2 つの段階の比較

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

よくある失敗とその対処

「サーバーが RedM のサーバーリストに出てこない。攻撃を疑っている」：まず設定を確認してください。set gamename rdr3 が欠けていると、FXServer は GTA V のサーバーとして登録され、RedM の一覧には現れません。portal.cfx.re のライセンスキーが欠けているか合っていない場合も、掲載は成立しません。攻撃は見え方が違います。掲載は残ったまま、接続が失敗します。

「何百人ものプレイヤーが参加時にエラーになる。洪水のように見える」：たいていはゲームビルドの問題です。sv_enforceGameBuild がリソースの想定と合っていないと、クライアントは「server specified an invalid game enforcement」と表示します。お使いのフレームワークが要求する値、通常は 1436 か 1491 を設定し、サーバーを完全に再起動してください。

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

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

「サーバーは動いているのに、全プレイヤーにラバーバンド現象が出る」：これは攻撃よりスクリプトであることのほうが多いです。まず resmon 1 で、どれかのリソースが計算時間を食いつぶしていないかを確認し、お使いのフレームワークの在庫とキャラクターのリソースを調べてください。sar -n DEV 1 10 に異常がなければ、DDoS 攻撃ではありませんでした。

「txAdmin に失敗した接続試行が何百件も出ている」：これは参加の洪水で、当たっているのはゲームのロジックであって回線ではありません。これに効くのは許可リスト、sv_authMinTrust によるアカウント検査、そして送信元アドレスごとの接続数上限です。

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

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

まとめ

• RedM サーバーが必要とする開放ポートはちょうど 2 つです。endpoint_add_tcp と endpoint_add_udp で設定する 30120 TCP と 30120 UDP で、独自のクエリポートや RCON ポートはありません。
• 40120 TCP の txAdmin と 3306 TCP のデータベースは開いたネットワークに置くものではなく、それぞれご自身のアドレスと 127.0.0.1 に限定します。
• sv_endpointPrivacy true は公開出力からプレイヤーの IP アドレスを外し、ステータスを保存して使い回す仕組みは、Cfx.re サーバーに対して記録されているレイヤー 7 の攻撃経路である /players.json の負荷を下げます。
• RedM サーバーのスロット数は OneSync なしで 32、OneSync ありで 48、Element Club で 1024 までです。スロット数が少ないほど参加の洪水は安く済み、許可リストとアカウント検査の重みが増します。
• RedM と FiveM は同じ FXServer で動き、違いは set gamename rdr3 だけです。そのためネットワークの防御は同一ですが、周辺の条件は違います。約 2000 台の RedM サーバーに対して約 3.9 万台の FiveM サーバーという差が、RedM プロジェクト 1 つごとの標的としての価値を高めます。
• ローカルのファイアウォールルールは、回線が埋まる地点で終わります。1 Gbit/s は毎秒 125 メガバイトで、64 バイトのパケットなら毎秒約 149 万パケットが入ります。それを超えるものはすべて、サーバーの手前のネットワークで終わらせる必要があります。
• KernelHost では、2 段階の常時保護がすべてのサーバープランに含まれ、提供開始時点から有効で、ヌルルーティングは行いません。フィルタリングをご自身で制御したい場合、Advanced DDoS Protection は月額 50.00 EUR から、専用の保護 IP とポートとプロトコルごとの独自ルールを提供します。

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