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

Terraria サーバーを DDoS 攻撃から守ろうとすると、特別な事情に向き合うことになります。Terraria は TCP だけを使います。ゲームトラフィックはちょうど 1 つのポート、7777 TCP を通り、UDP ポートはまったく開きません。ネットで流通しているゲームサーバー保護の助言はほぼすべて UDP のゲームを前提に書かれているため、ここでは的を外すか、間違った場所に効くかのどちらかになります。

本記事ではまず、追加費用なしでご自身で固められる範囲を示し、次にその対策が技術的にどこで限界を迎えるかを示し、最後にサーバーの手前のネットワークで何が起きる必要があるかを説明します。記述はすべて、Debian 12、Debian 13、Ubuntu 22.04 LTS、Ubuntu 24.04 LTS 上で動く専用の Terraria サーバー（vanilla、TShock、tModLoader）を前提としています。コマンドは root 向けに書かれているため、一般ユーザーの場合は先頭に sudo を付けてください。攻撃がいま進行中の場合は、まず設定を変更せず、サーバーも再起動しないでください。「ログを取る」の節にある測定値を保存します。攻撃が終わってからでは、もう残っていません。

Terraria サーバーが DDoS 攻撃に狙われる理由

Terraria サーバーが都合のよい標的になるのは、そのアドレスが必然的に公開されるからです。vanilla の Terraria には内蔵のサーバーブラウザーがありません。プレイヤーは「Multiplayer」と「Join via IP」から、つまり誰かが事前に公開したアドレスを通じて接続します。新しいプレイヤーを集めたい人は、terraria-servers.com、tserverweb.com、topg.org といったリストサイトにサーバーを登録するか、Discord でアドレスを配ります。このどの経路も、プレイヤーに渡すものと同じものを攻撃側にも渡します。IP アドレスとポートが平文で手に入るのです。

ハードウェア、ワールド、Mod リストを何も変えていないのに Terraria サーバーが落ち続けるなら、最も可能性が高い説明は攻撃です。そこにプロジェクト特有の事情が重なります。固定した遊ぶ時間、競合するサーバー、BAN されたプレイヤー、コミュニティ内のもめ事です。攻撃を仕掛ける側には技術も、まとまった金額も必要ありません。Terraria のサーバー booter は、月に数ユーロの定額サービスとして売られています。DDoS 攻撃が技術的に何であり、どう組み立てられるのかは、記事 DDoS 攻撃とは何か で解説しています。

Terraria は UDP ではなく TCP で動く

これが、ほかのほぼすべてのゲームサーバーとの最も重要な違いです。Terraria の専用サーバーは TCP のリスナーで接続を受け付け（ゲームエンジン内のクラスは Terraria.Net.Sockets.TcpSocket）、UDP ソケットを開きません。ここから、防御全体を左右する 4 つの帰結が生まれます。

• 完全に確立された TCP 接続は偽装できません。攻撃側は、ハンドシェイクを完了させるためにサーバーの SYN-ACK を受け取る必要があります。つまり、実際に接続している相手は本物のアドレスから来ています。そのため Terraria では、IP による遮断と接続数の上限が UDP のゲームよりはるかによく効きます。
• SYN フラッドは確かに偽装できます。ハンドシェイクを完了させないからです。この種類に対しては IP による遮断は効かず、SYN cookie と手前でのフィルタリングだけが効きます。
• ポート 7777 に受け付けられた TCP 接続はどれも、カーネルだけでなくゲームプロセス内のリソースを占有します。これが、スロット枯渇を最も少ない帯域幅で最も効く攻撃にしています。
• それでも UDP フラッドはお使いのサーバーに当たります。回線を埋めるのに、パケットを受け付ける必要はありません。Terraria が UDP を使わないことは回線を守らず、ゲームプロセス自身がパケットを処理しないようにするだけです。

例外が 1 つあります。専用サーバーを -steam と -lobby friends あるいは -lobby private を付けて起動すると、接続は Steam のネットワーク経由になり、27000 から 27100 の範囲の UDP ポートを使います。これは別の動作モードであり、IP アドレスで到達する従来型のサーバーではありません。

実際に問題になるポート

Terraria サーバーが開いたネットワークに必要とするポートは、ちょうど 1 つ、7777 TCP です。この表のそれ以外は、インターネットに出す必要がまったくないか、ご自身のアドレスだけに向けるものです。

Terraria がクエリポートも RCON も持たないことは、セキュリティ上は良い知らせです。Counter-Strike、Rust、ARK でリフレクション攻撃に悪用され続けている 2 つのエンドポイントが、ここにはそもそも存在しません。その代わり、攻撃対象領域はポート 7777 にいっそう強く集中します。そして TShock を使う人は、ポート 7878 という 2 つ目の面を自分で追加することになります。

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

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

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

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

ss -lntup

注目するのはローカルアドレスの列です。0.0.0.0:7777 は「インターネット全体から到達できる」、127.0.0.1:7878 は「ローカルのみ」で、ファイアウォールルールは不要という意味です。このリストに Terraria のプロセス向けの UDP エントリーが出てくるなら、サーバーは Steam モードで動いています。攻撃側からの見え方は、外部からのポートスキャンで分かります。

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

2. 7777 TCP だけを開け、それ以外は閉じる

Terraria には外向けの開放が 1 つあれば足ります。UDP のルールは必要なく、7777 に対する UDP のルールは端的に誤りです。何も待ち受けていないポートへトラフィックを通すことになります。UFW では次のようになります。自分自身を締め出さないよう、この順番どおりに実行してください。

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/tcp comment 'Terraria'
ufw allow from 203.0.113.10 to any port 7878 proto tcp comment 'TShock REST'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

203.0.113.10 はご自身のアドレスに置き換えてください。復旧手段まで含む詳しい手順は 自分を締め出さずに UFW ファイアウォールを設定する にあります。パネルを運用している場合は、8080 と 2022 もご自身のアドレスだけに限定します。

3. serverconfig.txt：password、maxplayers、secure を正しく設定する

Terraria サーバーの中心となる設定ファイルは serverconfig.txt で、起動時に -config serverconfig.txt で渡します。セキュリティに決定的なディレクティブは 4 つです。

port=7777
maxplayers=16
password=ALongRandomPassword
secure=1
upnp=0
banlist=banlist.txt

password= は、通常の参加経路を通る参加フラッドに対して最も効く無料の対策です。理由はプロトコルにあります。クライアントはまずバージョン識別子（たとえば Terraria279）を付けたメッセージ 1 を送り、パスワードが設定されているとサーバーはメッセージ 37 で応答し、クライアントはメッセージ 38 で正しく答える必要があり、そのあとでようやくサーバーがメッセージ 3 でプレイヤースロットを含む許可を送ります。つまり正しいパスワードがなければ、攻撃側は参加処理の中で最も高くつくワールドの転送まで、決してたどり着けません。

maxplayers は 1 から 255 の値を取り、初期値は 16 です（バージョン 1.4.0.1 より前は 8 でした）。上限の 255 は恣意的な数字ではありません。Terraria はプレイヤーを 1 バイトで指定するからです。maxplayers を本当に必要な数より大きくしないでください。スロットはどれも、攻撃側が占有できるリソースです。secure=1 は内蔵のチート検査を有効にし（コマンドラインでは -secure）、upnp=0 はサーバーが自分の判断でルーターのポートを開けることを防ぎます。

4. TShock を固める：7878 の REST API とログインフラッド

TShock は Terraria で最も広く使われているサーバー拡張機能で、REST API という 2 つ目の本格的な攻撃対象領域を持ち込みます。これは標準でポート 7878 TCP に置かれ、serverconfig.txt ではなく tshock/config.json で設定します。出荷時の状態では無効になっており（"RestApiEnabled": false）、必要にならない限り、まさにそのままにしておくべきです。

使う必要がある場合、関係する値は次のとおりです。

"RestApiEnabled": true,
"RestApiPort": 7878,
"EnableTokenEndpointAuthentication": true,
"LogRest": true,
"RESTMaximumRequestsPerInterval": 5,
"RESTRequestBucketDecreaseIntervalMinutes": 1

ここで重要な点は 2 つです。第一に、EnableTokenEndpointAuthentication が false のままだと、エンドポイント /status はトークンなしでサーバー名、ポート、プレイヤー数、プレイヤー名を返します。ステータスページや Discord ボットには便利ですが、同時に、いつ攻撃する価値があるかを知りたい攻撃側にとっては無料の偵察になります。第二に、エンドポイント /v2/token/create はユーザー名とパスワードからアクセストークンを生成し、ポート 7878 が開いていれば外部から到達できます。つまり管理者アカウントに対するパスワードの推測攻撃であり、おまけに計算時間も削られます。RESTMaximumRequestsPerInterval と RESTRequestBucketDecreaseIntervalMinutes によるバケットはこれを抑えますが、ファイアウォールルールの代わりにはなりません。

ゲームへの参加自体には、さらに別の TShock の値が効きます。MaximumLoginAttempts は 3 で、3 回失敗したプレイヤーを切断します。RequireLogin（初期値 false）はすべてのプレイヤーにアカウントを要求します。EnableIPBans（初期値 true）と KickProxyUsers（初期値 true）は、確立された接続の送信元アドレスが偽装できないという性質があるため、TCP のゲームではとくによく効きます。攻撃として報告されがちな griefing に対しては、しきい値 TileKillThreshold（60）、TilePlaceThreshold（20）、TileLiquidThreshold（15）、ProjectileThreshold（50）が効き、いずれも毎秒あたりの操作回数です。

5. 送信元アドレスごとに接続を制限し、SYN cookie を確認する

Terraria が TCP で動くため、最も効くローカルのルールは送信元アドレスごとの同時接続数の上限です。本物のプレイヤーに必要なのは、ちょうど 1 つです。

iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m hashlimit --hashlimit-name terraria_syn --hashlimit-mode srcip --hashlimit-above 10/min --hashlimit-burst 20 -j DROP

1 つ目のルールは、あるアドレスが同時に 3 つより多く開いた時点で、新しい接続を破棄します。2 つ目は、同じ送信元からの接続試行のレートを 1 分に 10 回、余裕 20 に制限します。どちらの数値も出発点で、絶対の正解ではありません。共有された回線（シェアハウス、学校のネットワーク、携帯電話事業者）の背後にあるサーバーでは、同じアドレスの下に複数の正規のプレイヤーが見えます。まずは平常時を 1 週間測ってください。

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

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

UFW を使っている場合、こうしたルールは /etc/ufw/before.rules に書きます。そうしないと、次の ufw reload で消えてしまいます。ハンドシェイクを完了させない偽装された SYN パケットに対しては、ここまでのルールはどれも効かず、効くのはカーネル自身です。次の 3 つの値を確認してください。

sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn

net.ipv4.tcp_syncookies は 1 である必要があり、Debian と Ubuntu では通常すでにそうなっています。SYN cookie は半開き接続の待ち行列を使わず、クライアントの応答から状態を再構成します。これにより、回線が埋まらない限り SYN フラッドは的を外します。net.core.somaxconn は Linux 5.4 以降で 4096、それ以前は 128 です。値が小さいと、ゲームプロセスが受け付ける前にカーネルが確立済みの接続を破棄します。

6. スロット枯渇を防ぐ：ポートスキャンがサーバーを満員にする理由

スロット枯渇は、Terraria サーバーに対して最も安く済む効果的な攻撃です。攻撃側は、サーバーのプレイヤースロットと同じ数の TCP 接続をポート 7777 に対して開き、そのまま保持します。帯域幅はほとんどかかりませんが、サーバーは満員になります。本物のプレイヤーには「Server is full」と表示され、回線には何も目立つことが起きていないのに入れなくなります。運用者が Terraria で攻撃に気づかないことが多いのは、まさにこれが理由です。

原因は数え方にあります。接続は、クライアントがバージョン識別子を送る前に受け付けられます。かつては、こうした幽霊接続は TCP のセッションが期限切れになるまで占有されたままでした。1.4.5 系列でこれは緩和され、すぐに切断するクライアントにはスロットが予約されなくなりました。ただし 1.4.5.7 と 1.4.5.8 の初期版では、TCP 接続が開かれてハンドシェイクが完了しないだけで、専用サーバーが未処理の ObjectDisposedException で落ちました。nc -z 1 回や、監視の到達性チェックで足りたのです。この不具合は数週間のうちに静かに修正されましたが、古いコンテナーイメージには今も残っていることがあります。ですからサーバーのバージョンは最新に保ってください。これは一般論ではなく、具体的な可用性の問題です。

設定も 2 つ役に立ちます。TShock を使う人は MaxSlots を希望するプレイヤー数にし、serverconfig.txt の maxplayers をそれより 2 つ多くします。そうすると、ゲームプロセスが最後の空きに通してしまう代わりに、TShock が余分な接続をきちんとしたメッセージで拒否します。そして前の節の接続数の上限が、1 つのアドレスが一度に全スロットを占有することを妨げる、まさにそのルールです。

7. UPnP を無効にし、アドレスを自分から公開しない

Terraria サーバーは初期設定で、UPnP によって自分のポートをルーターに開けようとします。レンタルしたサーバーでは効果がなく、家庭内のネットワークでは、あとから存在を忘れるポートを開けます。serverconfig.txt の upnp=0 か、コマンドラインの -noupnp で無効にしてください。

ここでは願望よりも正直さが役に立ちます。お使いの IP アドレスは秘密にできません。一度接続したプレイヤーは全員それを知っていますし、リストサイトへの登録でどうせ公開されます。有効なのは 2 つの習慣です。生の IP アドレスをご自身でどこにも公開せず、プレイヤーにはホスト名で接続させてください。Terraria のクライアントはホスト名を解決するため、いざというときにアドレスを変えても、参照がすべて壊れることはありません。そして古い DNS レコードは片付けてください。以前のアドレスを指す A レコードが忘れられていると、どんな変更も無意味になります。

8. ステータスの問い合わせを通さず、キャッシュする

Terraria に問い合わせプロトコルがないため、ステータスページ、Discord ボット、リストサイトは 2 つのうちどちらかの方法でお使いのサーバーの状態を調べます。7777 に本物の TCP 接続を張ってクライアントを装うか、TShock の REST API に問い合わせるかです。どちらもお使いのサーバーに作業を生じさせ、どちらも問い合わせる側の数に比例して増えます。

対策に費用はかかりません。訪問者から問い合わせないことです。1 つのサービスだけが決まった間隔で状態を取得し（30 秒か 60 秒で足ります）、その結果をキャッシュして、すべての訪問者にはキャッシュした状態を返してください。これで、訪問の多いステータスページが生む問い合わせは、訪問者 1 人あたり 1 件ではなく、間隔あたり 1 件になります。REST API をこれに使う場合は、ポート 7878 をこのサービス 1 つのアドレスに限定します。

9. ログを取り、いざというときにデータを持っておく

最も重要な手順は、ほとんど誰も事前にやらないことです。すべてが正常に動いているうちに基準値を作ることです。平常時の値がなければ、事後に毎秒 4 万パケットが多かったのか、それとも単に土曜の夜だったのかを言えません。apt-get install -y vnstat sysstat で測定が継続的に走ります。障害の最中には 5 つのコマンドで足ります。

sar -n DEV 1 10
ss -s
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 tcp port 7777 -c 200 -q

3 つ目のコマンドが Terraria 固有です。半開きの接続を数えます。2 桁なら正常、4 桁か 5 桁なら SYN フラッドです。ss -s はあわせて TCP 接続の総数を示し、この数がゲーム内に誰もいないのに maxplayers とほぼ同じなら、スロット枯渇が見えています。tcpdump では、必ず -c で制限してください。全負荷の下での取得は、すでに過負荷のサーバーにさらに負担をかけます。値の読み方は DDoS 攻撃を検知する にあります。

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

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

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

2 つ目の指標はパケットレートで、帯域幅より先に限界に達することがよくあります。64 バイトの小さなパケットなら、1 Gbit/s の回線には毎秒約 149 万パケットが入ります。通常のサーバーのカーネルが破棄を始める前に処理できるのは、CPU とネットワークカードによりますがそのうち数十万です。SYN フラッドでは、SYN パケット 1 つごとに状態の判断が発生するため、限界はさらに低くなります。毎秒数万の SYN パケットでも、回線が埋まるはるか手前で、標準的な Linux の接続受け付けを麻痺させるには十分です。運用者にはこれが「使用率はまったく高くなかったのに、それでも全部落ちた」という形で見えます。

そして 3 つ目が、Terraria で最も見落とされる点です。攻撃側はお使いのプロトコルに合わせてくれません。どの UDP ポートでも何も待ち受けていないのに、UDP フラッドとリフレクションのトラフィックをお使いのアドレスに送ってきます。お使いのサーバーはそれらのパケットを正しく破棄しますが、パケットはすでに回線を占有しており、Terraria サーバーは 1 つのパケットもゲームプロセスに届かないままオフラインになります。どの規模が現実に起きるのかの目安として、KernelHost のサーバーでは、毎秒 4150 万パケットを超える 473.4 Gbit/s 超の攻撃や、ゲームサーバーに対する 112.2 Gbit/s 超の UDP フラッドが除去されています。これに対するローカルの設定はありません。ボリューム型攻撃は、サーバーの手前のネットワークで終わらせる必要があります。

KernelHost が用意している対策

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

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

• 第 1 段階：グローバルなスクラビングネットワークにおける 17 Tbps の緩和能力。ボリューム型攻撃は、データセンターに届く前に、発生源の近くで除去されます。
• 第 2 段階：フランクフルトにおける 3.2 Tbps の Arbor リアルタイムフィルタリング。サーバーの直前で、プロトコル固有のパターンを検知し、パケット単位で破棄します。Terraria にとって具体的には、7777 TCP に対する SYN フラッドと接続フラッドがここで終わり、お使いのネットワークカードには届きません。

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

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

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

• 専用の保護 IP をフランクフルトの中核から割り当て、お使いのサーバーを当社のネットワーク内で切り替えます。ご自身の側で作り直す作業はありません。
• ポートとプロトコルごとに自分で管理できる保護ルールをカスタマーエリアで設定できます。7777 TCP で何を許可するかを指定し、それ以外はすべて閉じることができ、そのためにチケットを書く必要はありません。
• 変更はリアルタイムで反映されます。そのため、攻撃が進行している最中にも調整でき、たとえば送信元アドレスごとに許可する接続レートをより厳しくできます。
• アプリケーションに合わせた保護プロファイル。Terraria のような TCP のゲームにも、任意の TCP または UDP ポートで動く独自のアプリケーションや改造したアプリケーションにも、適したプロファイルがあります。

2 つの段階の比較

ほとんどの Terraria プロジェクトでは、標準で含まれる常時保護と、きちんとしたサーバー設定を組み合わせれば十分です。Advanced DDoS Protection は、誰かが個人的な問題として攻撃してくる場合への答えです。現在サーバーをほかの場所で動かしている場合、保護をあとから追加することはできず、KernelHost への移転によって手に入ります。フィルタリングはネットワークの一部であり、サーバー上の追加機能ではありません。

よくある失敗とその対処

「サーバーは満員なのに、誰も入っていない」：これはスロット枯渇です。ss -tn dst :7777 | wc -l で実際に開いている接続の数を確認し、プレイヤーリスト（サーバーコンソールの playing）と突き合わせてください。数が合わなければ、外部からの接続がスロットを占有しています。対策は、送信元アドレスごとの接続数の上限、サーバーパスワード、そして最新のサーバーバージョンです。

「7777 UDP を開放したのに何も変わらない」：そのとおりで、7777 UDP では何も待ち受けていません。Terraria は TCP だけを使います。UDP の開放が直接害になるわけではありませんが、不要な開口部であり、別のゲームの手順書をそのまま写した確かな印です。

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

「攻撃を受けていないのにプレイヤーが落ちる」：connlimit の上限を厳しすぎる値にすると、共有された回線の背後にいるプレイヤーに当たります。TCP では UDP のゲームより早く起きます。途切れたあとの再接続がすぐに新しい接続を作る一方で、古い接続はまだ TIME_WAIT に残っているからです。値を段階的に上げ、一致カウンターを観察してください。

「サーバーが重いのに、回線は静かだ」：これは攻撃より、Mod かプラグインであることのほうが多いです。tModLoader では追加した Mod のどれもが同じプロセス内で計算時間を使い、エンティティーの多いワールドは、余分なパケットが 1 つも届かなくても 1 つのコアを使い切ります。sar -n DEV 1 10 に異常がなければ、DDoS 攻撃ではありませんでした。

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

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

まとめ

• Terraria サーバーが必要とする開放ポートはちょうど 1 つ、7777 TCP です。ゲームは UDP ソケットを開かず、問い合わせプロトコルも RCON も持ちません。
• ポート 7878 TCP の TShock の REST API が 2 つ目の攻撃対象領域です。RestApiEnabled を false のままにするか、ポートをご自身のアドレスだけに限定してください。
• serverconfig.txt のサーバーパスワードが最も効く無料の対策です。メッセージ 37 に正しく答えられない攻撃側は、ワールドの転送まで決してたどり着けないからです。
• Terraria で最も安く済む攻撃はスロット枯渇です。7777 に受け付けられた TCP 接続はどれも、目立つ帯域幅をまったく使わずに 1 席を占有します。これに効くのは送信元アドレスごとの上限、パスワード、そして最新のサーバーバージョンです。
• Terraria は TCP を使うため、確立された接続の送信元アドレスは偽装できません。IP による遮断はここでは UDP のゲームよりよく効きます。偽装された SYN フラッドに対しては、SYN cookie と手前でのフィルタリングだけが効きます。
• UDP フラッドは、Terraria が UDP を使わないにもかかわらず、お使いのサーバーを麻痺させます。ゲームプロセスが何かを見る前に、回線を埋めてしまうからです。
• おおよそお使いのアップリンクの帯域幅の規模を超えると、決めるのはサーバーの手前のネットワークだけです。KernelHost ではこのフィルタリングが 2 段階で、常時動いており、すべてのサーバープランに追加料金なしで含まれています。

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