Team Fortress 2: TF2 サーバーを DDoS 攻撃から守る

Team Fortress 2 のコミュニティサーバーが、夜、ラウンドの途中でプレイヤー全員を同時に失い、そのあと数分間サーバーブラウザーから消える場合、ハードウェアの問題であることはめったにありません。多くの場合、27015/UDP に対する攻撃が進行しています。本記事では TF2 サーバーを DDoS 攻撃から守る方法を示します。まず、これから 10 分のうちに追加費用なしでご自身でできることを挙げ、次にその手立てが物理的にどこで終わるかを示し、最後にその手前のネットワークで何が起きる必要があるかを説明します。

本記事の記述はすべて、SteamCMD でインストールした Source 専用サーバー（srcds_run -game tf）を Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS 上で動かす場合を前提としています。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。攻撃がいま進行中の場合は、まず何も変更せず、サーバーも再起動しないでください。先に第 9 節の測定値を保存してください。攻撃が終わってからでは、もう残っていません。

Team Fortress 2 サーバーに DDoS 対策が必要な理由

Team Fortress 2 は 2011 年から無料で遊べます。まさにそれが攻撃の採算を変えます。攻撃する側は使い捨てアカウントを無制限に用意でき、そのどれにも料金を払う必要がなく、BAN されても失うものがありません。買い切りのゲームなら金銭が必要になるところが、ここでは 1 分で済みます。

加えて、TF2 をほかの多くのゲームと分ける特徴があります。2016 年 7 月の更新「Meet Your Match」以降、新しいプレイヤーをコミュニティサーバーへ自動的に振り分けていた Quickplay がなくなりました。新しいプレイヤーはカジュアルモードで Valve のサーバーに入ります。コミュニティサーバーは、サーバーブラウザーからしか見つけられません。このリストから落ちたサーバーは、サーバープロセスが問題なく動いていても、新しいプレイヤーにとっては事実上存在しません。つまり、お使いのサーバーをリストから押し出すだけの攻撃でも、目的はすでに達成されています。

したがって、狙われやすいのは次のようなサーバーです。常連のいる常時稼働のコミュニティサーバー（24 時間の 2Fort、Trade、Jailbreak、Surf、Dodgeball、Mann vs. Machine）、ETF2L、RGL、ozfortress のリーグ運営で試合日程が決まっているリーグサーバー、そして運用者が誰かを BAN した直後のサーバーです。きっかけが技術的なものであることは、ほとんどありません。DDoS 攻撃とはそもそも何かは、記事 DDoS 攻撃とは何か で解説しています。

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

TF2 サーバーが外に必要とするポートは、ちょうど 1 つ、27015/UDP です。それ以外は、無効にできるか、制限すべきか、もともと出ていくだけです。この表が、以下のすべてのファイアウォールルールの土台になります。

1 台のマシンで複数のインスタンスを動かす場合、番号は順に上がります。ゲームは 27016、27017 と続き、SourceTV は 27021、27022 です。設定ファイルは tf/cfg/server.cfg にあり、マップが変わるたびに読み込み直されます。

共有された 27015 が最も弱い点である理由

TF2 ではゲームトラフィックとサーバー問い合わせが同じ UDP ポートを分け合っており、独立したクエリポートはありません。A2S_INFO の要求はちょうど 25 バイトです。4 バイトの FF FF FF FF、1 バイトの 0x54、そして終端のヌルを含む 20 バイトの文字列「Source Engine Query」です。サーバー名、マップ、プレイヤー数、タグを含む応答は、その何倍にもなります。米国の政府機関 CISA は、アラート TA14-017A で Steam プロトコルの増幅率を 5.5 としています。

UDP には接続確立の手順がなく、送信元アドレスも偽装できるため、これは長年にわたって開いた増幅の穴でした。攻撃する側は標的のアドレスを送信元として他人の Source サーバーに問い合わせ、サーバーはその応答を標的に送りました。A2S_PLAYER と A2S_RULES は以前から、事前に取得する前置きの要求（チャレンジ）を求めていましたが、A2S_INFO は求めていませんでした。Valve が A2S_INFO にも前置きの要求を追加したのは 2020 年 12 月です。サーバーは応答の代わりに S2C_CHALLENGE を返すことができ、問い合わせる側はそれを繰り返して送る必要があります。それによって、送信元アドレスを偽装していないことが示されます。

これでリフレクションは弱まりますが、面倒がなくなるわけではありません。問い合わせのパケットは今もすべてお使いのサーバーに届き、応答されるか破棄されるかの前に計算時間を消費します。そして、サーバーを直接あふれさせる攻撃側は、そもそも増幅を必要としません。

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

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

1. 現状把握：何が待ち受けていて、起動行はどうなっているか

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

ss -lntup

127.0.0.1 または ::1 にバインドされているものは、開放の必要がありません。0.0.0.0 や [::] にあるものはインターネットから到達でき、そこには統計プラグインが一緒に持ち込んだ MySQL データベースや、FastDL のファイルを置いたウェブサーバーも含まれます。その結果を、ご自身の起動行と見比べてください。

./srcds_run -game tf -console \
  -port 27015 -steamport 26901 -nohltv \
  +maxplayers 24 +map ctf_2fort +sv_pure 1 \
  +sv_setsteamaccount YOUR_GSLT_TOKEN

この行にあるポートは、どれも意識して決めたものであるべきです。土台をどう用意するかは、記事 SteamCMD でゲームサーバーをインストールする にあります。

2. TF2 が本当に必要とするポートだけを開けたままにする

公開の TF2 サーバーが外に必要とする開放はちょうど 1 つ、加えてご自身のアドレス向けの RCON だけです。UFW では、自分を締め出さないために、この順序で実行します。

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'TF2 ゲームと A2S'
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment 'RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

203.0.113.10 はご自身のアドレスに置き換えてください。SourceTV をここに載せていないのは意図的です。配信しないのであれば -nohltv を付けて起動し、27020/UDP をそもそも使いません。これで TF2 サーバーの外から到達できる UDP の面は半分になります。リーグの試合を配信する場合は ufw allow 27020/udp を追加し、そのうえで tv_password を設定してください。

復旧手段まで含む完全な手順は、記事 自分を締め出さずに UFW ファイアウォールを設定する にあります。それでも締め出してしまった場合、KernelHost の KVM ルートサーバーと専用サーバーには、カスタマーエリアの VNC コンソールから入れます。これはゲスト側のネットワークに依存せずに動きます。

3. サーバーブラウザーから落ちずに A2S クエリを絞る

この分野で最も高くつく失敗がここにあります。27015/UDP を一律で遮断したり、大まかにレート制限したりすると、自分のプレイヤーを追い出し、攻撃側の望みどおりに攻撃を成立させます。ゲームトラフィックと問い合わせが同じポートを占めているため、境目はポートではなくパケットの種類の間に置く必要があります。

エンジンにはそのためのコンソール変数が 3 つあり、tf/cfg/server.cfg に書きます。

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

1 つ目は送信元アドレスごとに応答する問い合わせの数を、2 つ目はすべてのアドレスにまたがる合計を、3 つ目は平均化の窓を秒で決めます。これらが守るのは、無駄な応答の生成から CPU を守ることです。初期値はゲームとビルドによって異なるため、サーバーコンソールで find sv_max_queries を実行すると、お使いのサーバーがどの値を持っているか分かります。

TF2 で厄介なのは 2 つ目の値です。これはすべてのアドレスにまたがって応答に上限をかけます。低く設定しすぎると、クエリフラッドの最中にリストサービスからの要求にも応答しなくなり、サーバーブラウザーから、つまり新しいプレイヤーがお使いのサーバーを見つける唯一の道から消えます。まずは緩めに始めて、正規の問い合わせが通っていると測れてから絞ってください。

1 つ下の層では、同じトラフィックをきれいに切り分けられます。Source エンジンのコネクションレスパケットはすべて 4 バイトすべてが立った値（0xffffffff）で始まり、すでに接続済みのプレイヤーのトラフィックにはこの先頭がありません。これを手がかりに、ゲームトラフィックに触れずにレート制限をかけられます。

table inet tf2 {
    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
    }
}

このファイルは nft -f で読み込みます。優先度 -10 によって、このルールは UFW のフィルターチェーンより前に効き、@th,64,32 は UDP ヘッダーの直後の 4 バイトを読みます。

4. ログに NET_GetLong として現れる分割パケットフラッドを受け止める

この攻撃は Source エンジンに固有のもので、TF2 は今日まで古いエンジンの系統で動いているため、とくに強く当たります。通常のコネクションレスパケットのほかに、エンジンは分割されたパケットを扱います。それは FF FF FF FF ではなく FE FF FF FF で始まり、より大きなメッセージが複数の部分に分かれて続くことを予告します。サーバーはその部分を保持し、残りを待つ必要があります。

まさにこれが悪用できます。攻撃する側は、予告だけして決して完成しない部分パケットを、偽装した送信元アドレスで大量に送ります。CPU 負荷が上がり、ゲームが引っかかり、サーバーのログには NET_GetLong の行がたまっていきます。これには 1 台のマシンで足り、帯域幅はほとんど必要ありません。回線がほぼ空のままなので、運用者はこれを DDoS 攻撃として報告することが繰り返しあります。

正規の TF2 クライアントがサーバーへ分割されたパケットを送る理由はほとんどないため、ここでは厳しい制限が妥当です。

udp dport 27015 @th,64,32 0xfffffffe \
    meter tf2split { ip saddr limit rate over 5/second burst 10 packets } drop

この行は、第 3 節のルールと同じチェーンに入ります。クライアントからのアップロードという、分割されたパケットの数少ない正当な理由の 1 つは、sv_allowupload 0 で追加的に取り除けます（第 7 節を参照）。

5. RCON を開いたインターネットから外す

Source エンジンの RCON プロトコルは、パスワードを TCP で平文のまま送ります。ご自身とサーバーの間の経路を読める相手は、そのあと RCON パスワードを手にします。そして RCON を握った相手は、マップを変え、全プレイヤーを BAN し、サーバーを停止できます。これは DDoS の問題ではなく乗っ取りですが、攻撃として報告されることが繰り返しあります。

rcon_password は空のままにも、推測できる値にもしないでください。openssl rand -base64 32 の出力で十分です。あわせて、ログイン試行に対するブレーキも用意します。

rcon_password "A_RANDOM_VALUE_HERE"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

これで、30 秒のうちに 3 回失敗したアドレスは 24 時間遮断されます。find sv_rcon を実行すると、お使いのビルドがどの変数を持っているか分かります。それでも第 2 節のファイアウォールルールのほうが効果的です。試行そのものをアプリケーションまで通さないからです。接続元が変わる回線からアクセスする場合は、SSH でローカル転送を用意し、そのうえで RCON を 127.0.0.1 に向けてください。

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

6. 転送レートに上限をかけ、ハイバネーションは有効のままにする

Team Fortress 2 は毎秒 66.67 ティックで固定して動きます。そこから生じるトラフィックの量を決めるのはティックではなく、1 つのクライアントが要求してよい量です。上限がなければ、プレイヤーはそれぞれのクライアントが求めるだけ受け取り、その費用はお使いの送信帯域幅で支払うことになります。

sv_minrate 50000
sv_maxrate 100000
sv_mincmdrate 40
sv_maxcmdrate 66
sv_minupdaterate 40
sv_maxupdaterate 66

一度計算してみてください。sv_maxrate 100000 では、プレイヤー 1 人が毎秒 100 キロバイトまで受け取れます。24 スロットなら毎秒 2.4 メガバイト、つまり送信で約 19 Mbit/s です。sv_maxrate 0 にすると上限がなくなります。リーグサーバーは意識してそうしますが、スロット数の多い公開サーバーではやめておくべきです。ティックレートの上限を外すプラグインは、プレイヤー 1 人あたりのパケットレートを何倍にもし、同じ計算をそのまま押し上げます。

2 つ目の点は、しばしば間違われます。TF2 は誰も接続していないと休眠に入り、その状態では CPU をほとんど使いません。多くの運用者は、サーバーが「起きている」ように感じられるようにこれを無効にします。複数のインスタンスが載ったマシンでは、それは何もしていない状態で CPU が埋まっていることを意味し、攻撃はすでに満杯のシステムに当たります。初期設定のままにしてください。

sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1

7. FastDL を分け、アップロードを無効にする

コミュニティサーバーは独自のマップで成り立っており、まさにそこから 2 つ目の攻撃対象領域が生まれます。sv_downloadurl がなければ、プレイヤーはコンテンツをゲームのネットワークチャンネル経由で、つまり試合を計算しているのと同じポート、同じプロセス経由で受け取ります。それは毎秒わずかなキロバイトで、しかも 1 ファイルずつです。200 メガバイトのマップ集があれば、プレイヤー 1 人につき数分間お使いのサーバーを塞ぎます。

sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64
sv_downloadurl "https://fastdl.example.org/tf/"

net_maxfilesize は初期状態で 15 で、最大 64 メガバイトまで上げられます。sv_allowupload 0 は、クライアントが独自のファイル（たとえばスプレー画像）をサーバーへ送るのを防ぎ、それによって第 4 節の分割されたパケットの数少ない正当な理由の 1 つを取り除きます。

決定的なのは、FastDL のホストがどこにあるかです。ゲームサーバーと同じ IP アドレスに置かれていれば、443/TCP への HTTP フラッド 1 つで回線が埋まり、それによって 27015/UDP も塞がります。高速ダウンロードは別のホストか、コンテンツ配信のネットワークの後ろに置いてください。そうすれば、ファイルへの攻撃はゲームに当たりません。

8. 投票システム、参加フラッド、プラグインを制限する

どの障害も帯域幅が原因とは限りません。TF2 は無料なので、ゲームのロジックへの攻撃にかかる費用はアカウントだけです。あらゆるスロットを埋める参加フラッド、ボイスとチャットのスパム、そして正規のプレイヤーを追い出す投票の悪用です。TF2 の初期設定はこの点ですでに理にかなっていますが、しばしば緩められます。

sv_allow_votes 1
sv_vote_issue_kick_allowed 0
sv_vote_allow_spectators 0
sv_vote_creation_timer 150
sv_vote_failure_timer 300
sv_vote_quorum_ratio 0.6

これが標準値です。投票は許可され、キック投票は許可されず、観戦者は投票に参加せず、2 回の投票の間は 150 秒、失敗したあとは 300 秒空き、投票の可決には 60 パーセントの賛成が必要です。sv_vote_issue_kick_allowed 1 を設定する人は、公開サーバーで確実に悪用される道具を自分で開けていることを知っておくべきです。

それを超える部分は、TF2 では SourceMod と Metamod:Source から来ます。どちらも tf/addons/ にあり、コンソールで meta version と sm version に応答します。Counter-Strike 2 とは違い、ここでの土台は成熟しており、BAN リスト、参加時の検査、チャットの制限のためのプラグインが通常の手段です。それについて 2 つの規則があります。どのプラグインも同じプロセス内のコードであり、落ちたプラグインはサーバーを一緒に連れていきます。そして、独自のウェブサービスを持つプラグインは追加のポートを開き、ときにはまさに守りたいアドレスを公開します。実際に動いているものは sm plugins list で分かります。

エンジン側をどれだけ真剣に見る必要があるかは、2020 年 4 月が示しています。TF2 と CS:GO の古いソースコードが流出したあと、Creators.TF や Red Sun のような大規模なコミュニティ運用者は、悪用を懸念してサーバーを一時的に停止しました。サーバーバイナリは最新に保ち、拡張機能はエンジンのバージョンに合わせてください。

9. 火が出る前に測って記録する

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

ip -s link show eth0
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xfffffffe"

1 つ目のコマンドは、インターフェースごとのパケット、エラー、破棄パケットのカウンターを表示します。10 秒の間隔をおいて 2 回実行してください。そうすれば絶対値ではなくレートが得られます。2 つの記録はクエリフラッドと分割パケットフラッドを切り分け、第 3 節と第 4 節のどちらのルールが実際に必要なのかという問いに答えます。記録は必ず -c で件数を限ってください。全負荷の状態では、記録そのものが計算時間を食います。

サーバーの内側では、コンソールコマンド stats が 1 行で CPU 負荷、毎秒キロバイトでの送受信のネットワーク負荷、サーバーの FPS、プレイヤー数を返します。プレイヤー数が平常なのにサーバーの FPS がティックの値を大きく下回る場合、サーバーはゲーム以外の何かに取り組んでいます。測定値の読み方は記事 サーバーで DDoS 攻撃を検知する にあります。

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

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

満員の TF2 サーバーの通常運転と実際の攻撃を並べると、その比がはっきりします。

一般的なゲームサーバーは 1 Gbit/s につながっており、これは毎秒 125 メガバイトです。誰かがそれより多く送った時点で、回線は埋まります。2 つ目の量はパケットレートで、たいていは帯域幅より先に効きます。どのパケットもネットワークスタックを 1 回通る費用がかかり、そのあと破棄される場合でも同じです。だからこそ、お使いの回線を 3 分の 1 も埋めない攻撃でも、サーバーを止められます。運用者にはこれが「使用率はまったく高くなかったのに、それでも全部落ちた」という形で見えます。

どの規模が実際に起きるのかの目安として、KernelHost のサーバーではとりわけ次の 2 例をリアルタイムでフィルタリングしました。ゲームサーバーに対する 112.2 Gbit/s 超、毎秒 870 万パケット超の UDP フラッドと、ボイスサーバーに対する 473.4 Gbit/s 超、毎秒 4150 万パケット超のマルチベクトル攻撃です。473.4 Gbit/s は 1 Gbit/s の接続の約 470 倍です。これに対する設定は、サーバー上には存在しません。

よく使われる 2 つの非常手段は役に立ちません。ヌルルーティングは攻撃されている IP アドレスをネットワークから外し、攻撃を終わらせますが、お使いのサーバーも終わらせます。攻撃を受けてから迂回させる方式は、切り替え時間として、まさに試合の決着がつく数分を奪います。効くのは、サーバーの手前のネットワークで常に動いているフィルタリングだけです。

KernelHost が TF2 サーバーへの攻撃に用意している対策

どのサーバープランにも含まれる常時保護

KernelHost の DDoS 対策は 2 段階で構成されており、注文も有効化も設定も必要なく、提供開始時点から常時動いています。

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

TF2 サーバーにとって決定的な性質が 2 つあります。フィルタリングは常時動いており、攻撃を受けてから反応する必要がありません。つまり、プレイヤーが弾き出され、サーバーがサーバーブラウザーから落ちる切り替え時間がありません。そして、ヌルルーティングは使いません。お使いの IP アドレスはネットワークに残り、破棄されるのは有害なパケットだけです。どのゲームとプロトコルが対象かは、記事 ゲームサーバーの DDoS 対策をリアルタイムで にまとめています。

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

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

• フランクフルトの中核から出す専用の保護 IP。 当社のネットワーク内で、お使いのサーバーをこのアドレスに切り替えます。ご自身の側で作り直す作業は必要ありません。
• ポートとプロトコルごとに自分で管理できる保護ルール。 27015/UDP で何を許すか、27020/UDP で何を許すか、27015/TCP で何を許すかを、チケットを書かずにカスタマーエリアで別々に設定できます。
• 変更はリアルタイムで反映されます。試合が終わるのを待たずに、攻撃が進行している最中に調整できます。
• それぞれのゲームに合った保護プロファイル。 Team Fortress 2 とほかの Source タイトルはもちろん、独自のアプリケーション向けの自由な TCP プロファイルと UDP プロファイルもあります。

この提供は、KernelHost で動いているサーバーに向けたものです。お使いの TF2 サーバーが現在ほかの事業者にあり、定期的に撃たれている場合、この保護への道は移転です。

2 つの段階の比較

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

よくある失敗とその対処

「サーバーは動いているのに、サーバーブラウザーに出ない」場合：まず Game Server Login Token を確認してください。TF2 サーバーが公開で掲載されるにはトークンが必要で、sv_setsteamaccount で設定し、アプリケーション ID 440 向けに発行します。Steam は 30 日間使われなかったトークンを取り消します。長く止めていたあとに消えたサーバーは、新しいトークンだけで済むことが多く、攻撃されていません。その次に考えるのが、低すぎる sv_max_queries_sec_global や、27015/UDP への大まかなファイアウォールルールです。

「CPU が 100 パーセントなのに、回線はほぼ空」の場合：これはクエリフラッドか分割パケットフラッドの典型的な姿です。サーバーのログに NET_GetLong の行がないか確認し、第 9 節の 2 つの tcpdump の行で、どちらの種類のパケットが届いているかを測ってください。

「nftables か iptables のルールが効かない」場合：原因は 3 つが多いです。ルールが UFW のチェーンの後ろにあって到達しない（だからこその優先度 -10 です）、前回の再起動で失われた、あるいは攻撃がボリューム型で、すでに埋まった回線に対してルールが正しく働いている、のいずれかです。nft list ruleset でカウンターが増えているか確認してください。0 のままなら、ルールに到達していません。

「IP アドレスを変えたのに、翌日にはまたオフラインだった」場合：攻撃する側は、新しいアドレスを古いアドレスと同じ場所から手に入れます。お使いのサーバーは、サーバーブラウザーに再び載った時点で自分でそれを公開し、古い DNS レコードと Discord のステータスボットが残りを済ませます。アドレスの変更は数時間を稼ぐだけで、解決ではありません。

「帯域幅に異常がないのに、サーバーが再現性をもって落ちる」場合：多くは DDoS 攻撃ではなく、エンジンのバージョンに合っていないプラグインか、古いサーバーバイナリです。ここでは sm plugins list とバージョンの突き合わせのほうが、どのフィルタールールより速く答えに着きます。

「何もしていない状態のあと、サーバーの反応が遅れる」場合：それはハイバネーションであり、不具合ではありません。誰も接続していない間は CPU 負荷をほぼ 0 に下げます。そしてそれは、まさに余裕を残しておきたい状態です。

「サーバーで見知らぬ管理コマンドが実行されている」場合：DDoS 攻撃ではなく、RCON アクセスの侵害です。パスワードを直ちに変更し、ポートをご自身のアドレスだけに限定し、パスワードが平文で回線を流れることを思い出してください。

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

まとめ

• TF2 サーバーが外に必要とするポートは、ちょうど 27015/UDP です。27015/TCP の RCON はご自身のアドレスだけに限定し、27020/UDP の SourceTV は配信しないのであれば -nohltv で無効にします。
• ゲームトラフィックと A2S クエリは同じポートを分け合っています。27015/UDP を一律で遮断したりレート制限したりする人は、自分のプレイヤーを追い出します。境目はパケットの種類の間に置く必要があり、UDP ヘッダーの直後の 4 バイトで見分けられます。
• 先頭が FE FF FF FF の分割パケットフラッドは、帯域幅ではなく CPU 負荷を生み、ログには NET_GetLong として現れます。TF2 ではこの種類のパケットに厳しい制限をかけるのが妥当です。
• 「Meet Your Match」以降、新しいプレイヤーがコミュニティサーバーを見つける道はサーバーブラウザーだけです。ご自身をこのリストから押し出す対策は、攻撃そのものと同じように働きます。
• 満員の 24 スロットのサーバーが処理する受信パケットは毎秒約 1,600 です。コミュニティのゲームサーバーに対する攻撃は、通常 5 から 50 Gbit/s、毎秒数百万パケットです。
• 1 Gbit/s は、可能な限り小さいパケットなら毎秒約 149 万パケットを運びます。この境目を越えた先を決めるのはサーバーの手前のネットワークだけで、サーバー上のどのルールでもありません。
• KernelHost では、2 段階の常時保護がどのサーバープランにも追加料金なしで含まれ、提供開始時点から有効で、ヌルルーティングもありません。ポートごとのルールをご自身で制御したい場合は、Advanced DDoS Protection が月額 50.00 EUR から加わります。

お使いのサーバーがすでに KernelHost で動いている場合、フィルタリングは何もしなくても有効です。それでも異常に気づいたときは サポートチケット を開いてください。お使いの IP アドレス向けにフィルタールールを調整します。攻撃が進行中の場合は、WhatsApp の緊急チャット +43 650 8209883 でもご連絡いただけます。その際は 4 つの情報をすぐにお知らせください。IP アドレス、ポート、ご自身のタイムゾーンでの時間帯、そして見えている症状です。これで確認のやり取りが 1 往復減り、試合が進行中のときはそれが効きます。