午前3時のオペレーションセンターには、空調室外機の低い唸り音だけが残っていた。冷たい風が空のコーヒーカップで溢れたデスクを通り過ぎ、机の上に細かい冷たさを残していく。

私はキーボードの上でうたた寝をしており、頬にはまだ画面の反射する微かな光が触れていたが、ポケットの中の携帯電話が突然激しく振動し、太ももが痺れるほどだった──モニタリングシステムの緊急アラート通知だ。画面が点灯した瞬間、まばゆいほどの赤いポップアップがほとんどインターフェース全体を飲み込んだ：「北米地区『Fantasy Expedition』サーバークラスタ異常、ログイン成功率20%を割り込む、遅延500ms超過」。

私は慌てて頭を上げ、向かいの壁にあるモニタリングスクリーンを見た。心臓が一瞬で締め付けられた。

本来なら翡翠のように緑一色であるべきサーバーステータスバーが、まるで熱々の赤いペンキをぶちまかれたかのように、ニューヨークからサンフランシスコまでの12ノードすべてが点滅する赤いランプを灯しており、遅延数値が画面で狂ったように跳ね、ログインリクエスト失敗のログが毎秒数十行の速度で積み上がっていく。

私は机の上のマウスを掴み、冷たいキーボード上で素早く指を動かし、ゲーム内のワールドチャットバックエンドに切り替えた。スクリーンに溢れる不満は既に千行以上も積み重なっていた：「なんだこれ？二千ドル課金したアカウントでログインできねぇ？」「またサーバー落ち？ちゃんとしろよ！」「あと5分もこんなんじゃ、『Star Battlefield』に移るぞ！あっちのサーバーは一度も落ちたことないんだから！」

トラフィック分析レポートを見るまでもなく、またSYN Floodだ。

この手のものは、ゲームの深夜のオンライン人数が最低になる時間帯を狙って奇襲をかけてくる。台所の隅のゴキブリのように、人が最も疲れているときに現れて嫌がらせをする。

去年、ロサンゼルスのEdgeCastデータセンターで駐在オペレーションをしていた時、私はこの罠にひっかかった。あの日も午前2時、北米地区の某Eコマースプラットフォームのサーバーが突然ダウンした。私はノートPCを抱えてサーバールームに駆け込み、ラック上の動作指示燈はまばゆいほど赤く、冷却ファンの騒音さえも「過負荷」の焦りを帯びていた。

パケットキャプチャツールを起動すると、画面は異なるIPからのSYNパケットで埋め尽くされ、每秒近く1万リクエスト、サーバーの半オープン接続キューはデフォルトの1024から一気に上限まで達し、システムログは「tcp syn queue full」のエラーだらけだった。

當時、私は急いで対応するため、キュー容量を一時的に4096に拡張した。しかし、30分も経たないうちに、攻撃トラフィックが倍増し、キューは再び満杯になった。結局、高防御ノードを3倍の価格でレンタルして、ようやくその攻撃をしのいだ。

ゲーム業界がハッカーの攻撃に遭うのは日常茶飯事だが、高防御CDNでSYN Floodを防ぐのは、決して「設定を積み上げる」ような蛮力ではない。

先週、シアトルであるインディーゲームスタジオの防御戦略を調整するのを手伝った時、彼らの技術ディレクターであるマークは私をサーバールームに引っ張っていき、画面上の設定ファイルを指さして自信満々に言った。「tcp_max_syn_backlogを1024から8192に上げたよ。これで今回は大丈夫だろ？」

私は直接反論せず、使われていない阿里雲のサーバーを一台見つけ、hping3ツールを使ってSYN攻撃をシミュレートし、每秒500個の偽造ソースIPのSYNパケットを送信した。

最初、マークは腕を組んで笑っていた。「見ろ、遅延は10msしか上がってない、大丈夫だ！」

結果、2分も経たないうちに、テストサーバーのCPU使用率が15%から95%に急上昇し、ping値が12msから320msに跳ね上がり、ゲームのログイン画面は「読み込み中」の白い画面で固まってしまった。

マークはモニタリングデータを茫然と見つめ、無意識に机を叩きながら言った。「どうしてこうなった？キューは十分大きいはずじゃないか？」

私は画面上の接続状態図を指さして説明した。「キューは大きくなったが、各半オープン接続はIPやポートといった接続情報をメモリに占有し、ACK応答を待つためにCPUリソースも消費するんだ。」

攻撃トラフィックが倍増すると、システムリソースはすぐに食い尽くされ、通常のプレイヤーのログインリクエストはまったく割り込めなくなる──これはまるで、レストランがテーブルを増やしても、注文せずに席を占領する人々が来て、本当に食事をしたい客には依然として席がないようなものだ。

現在私たちが使っているこの防御のコンビネーションは、2年前に「Star Defense」をローンチした時に50万ドル以上の学费を払って得たものだ。

当時、ゲームはオープンベータテスト開始したばかりで、ユーザー数が200万人に急増したが、ローンチ3日目にSYN Flood攻撃に遭遇し、ピークは280万ppsに達し、サーバーは丸4時間ダウンした。

プレイヤーへのアイテム補償や返金、それに临时の高防御ノードレンタル費用だけで、前後して50万ドル以上を失い、初期プレイヤーの15%を流失した。今思い出してもまだ胸が痛む。

そして、その時から私たちはこの「多層防御」の戦術を少しずつ模索し始めたのだ。

第一の策はSYN Cookie机制。この策は「半オープン接続がリソースを占有する」問題を根源から解決できる。

通常、サーバーはSYNパケットを受信すると接続リソースを割り当て、クライアントのACKを待つ。しかし、SYN Cookieは逆のアプローチを取る──SYNパケットを受信しても直ちにリソースを占有せず、クライアントのIP、ポート、そして自分たちだけが知る動的キーを用い、SHA-1ハッシュアルゴリズムで64ビットの「暗号化クッキー」（Cookie値）を計算する。この値をSYN-ACKパケットのシーケンス番号に埋め込んで返信する。

クライアントが正当なものであれば、このCookie値をそのままACKパケットのシーケンス番号に含めて返信する。サーバーはACKを受信後、同じアルゴリズムで再計算し、2つの結果が一致すれば正常な接続と確認し、その時点で初めてリソースを割り当てて接続を確立する。

前回トロントノードで行った負荷テストでは、每秒10万SYNの攻撃をシミュレートした。SYN Cookieを有効にする前、サーバーのCPU使用率は99%に達し、メモリ使用率は70%を突破、ログイン遅延は300msを超えていた。有効化後、CPUは40%に直接低下し、メモリ使用率も35%に抑えられ、遅延は80ms前後で安定した。

ただし、この策にも弱点がある。每秒50万以上の超大流量攻撃に遭遇すると、暗号化計算自体が新たなボトルネックとなり、CPU使用率が再び上昇し始める。この時は第二の策で補う必要がある。

第二の策はLinuxカーネルプロトコルスタックのチューニングで、キーポイントは「拡張」ではなく「高速解放」にある。

私たちはとっくにtcp_max_syn_backlogを16384に調整しているが、これは基礎に過ぎない。本当に効果的なのは、tcp_synack_retriesパラメータを0に設定することだ──デフォルトでは、サーバーはSYN-ACK送信後、ACKを待つために5回再試行し、各間隔は1秒から32秒まで増加し、接続を解放するまでに最大63秒待つことになり、純粋なリソースの浪費だ。

0に設定後、異常なIP（例えばレピュテーション庫のブラックリストからのアドレス）が送信するSYNパケットを検出すると、サーバーは直ちにRSTパケットを返信して接続を切断し、ハッカーとの「時間稼ぎ」をしなくなる。

さらに、SYN_RECV状態のタイムアウト時間をデフォルトの60秒から10秒に短縮した。これにより、取り逃した半オープン接続があっても、10秒後には自動的にリソースが解放され、攻撃リソースの解放速度が3倍向上した。

去年東京データセンターで攻撃を処理した時、私はWiresharkでパケットキャプチャ分析を行い、ハッカーが使用している「SYN Killer」ツールが3秒ごとに一批のSYNパケットを送信しているのを確認した。結果、私たちのサーバーは秒でRSTを返信し、10分も経たないうちに、そのツールは「接続拒否回数が多すぎて送信を続行できません」というエラーをポップアップさせた。

同僚の小王と私は画面のエラーメッセージを見つめ、淹れたてのインスタントコーヒーをキーボードに噴き出しそうになりながら笑った──あのハッカーは、これほど「あっさりした」防御システムを見たことがなかっただろう。

第三の策はトラフィックスクリーニングセンターの「近傍ソースデプロイ＋多層フィルタリング」で、この策は「防御は成功したがプレイヤーがラグを感じる」問題を解決できる。

去年、「Mech Storm」モバイルゲームの北米地区が攻撃に遭遇した時、私たちは最初全てのトラフィックをバージニアのスクリーニングノードに流した。結果、西海岸のプレイヤーの遅延は50msから180msに急騰し、ゲームフォーラムは「PPTのようにカクつく」「スキルが発動できない」という苦情で溢れ、カスタマーサービスへの電話は鳴り止まず、中には「ゲーム削除」のスクリーンショットを晒すプレイヤーまで現れた。

後で私たちは緊急で戦略を調整し、ロサンゼルス、サンフランシスコといったプレイヤーが密集する西海岸都市にエッジスクリーニングノードをデプロイした。攻撃トラフィックはまずローカルノードでフィルタリングされ、正常なトラフィックだけが専用線でソースサーバーに戻される。

この調整により、西海岸プレイヤーの遅延は70ms以下に直接低下し、苦情量は90%急減、デイリーアクティブプレイヤーの流失率は8%から1.2%に抑えられた。

スクリーニング戦略も二層に分かれている：平時のトラフィックが少ない時は「SYNレート閾値」フィルタリングを使用する──単一IPが每秒20以上のSYNパケットを送信すると、グラフィカルCAPTCHAチャレンジが発動する。ハッカーの自動化ツールはCAPTCHAを識別できないため、自然に门外に遮断される。大流量攻撃（例えば每秒数百万pps）に遭遇した場合は、「行動分析モード」に切り替え、AIモデルで接続行動を検出する──通常のプレイヤーはSYN送信後直ちにACKを返信するが、ハッカーの攻撃パケットはSYNのみを送信し、ACKを返信しない。

あるIP範囲の接続の80%以上が「SYNのみ送信、ACK返信なし」であることが発見されると、システムは自動的にそのIP範囲全体をブラックリストに登録し、「ブラックホール」に放り込み、一つ一つ処理するリソース浪費を省く。

最も見落とされがちなのは第四の策──IPレピュテーション連携で、この策は私たちが「転ばぬ先の杖」を用意するのに役立つ。

我们现在Cloudflare、Akamai、阿里雲の3つのCDNプロバイダーと緊密に連携しており、彼らは1時間ごとに全球の悪意あるIPデータベースを更新する。HTTP Flood、DDoSを発動したことがあるIPでも、SYN攻撃を搞ったIPでも、すべてデータベースに記録され、私たちの防御システムに同期される。

前回、ブラジルノードであるIPがHTTP Flood攻撃を発動したのを検出し、5分も経たないうちに、このIPは私たちのSYN防御ブラックリストに同期された。2時間後、このIPが北米地区「Fantasy Expedition」サーバーでSYNパケットを送信しようとしたが、3個送信しただけでシステムに遮断された。

もっと効率的な遮断もあった：去年11月、私たちは攻撃源がAWSオレゴンリージョンのクラウドホストIPを大量に使用していることを発見した。レピュテーション庫を調べると、このIP範囲（約2.3万アドレス）は過去1週間のうちに、欧洲とアジアのノードで3回のSYN攻撃を発動しており、さらにこのIP範囲のプレイヤーログイン記録は、最近7日間で正常なログインがあったIPが0.8%しかないことを示していた。

私たちはこのIP範囲全体を直接ブラックリストに追加した。結果、スクリーニングノードのリソース占有率は82%から16%に急落し、オペレーションチームは手動で悪意あるIPを選別する必要がなくなり、丸半日を節約した。

午前4時3分、モニタリングスクリーン上の赤いランプはついに一つずつ消え、緑の「正常」表示がサンフランシスコノードから始まり、ゆっくりとニューヨークノードまで広がっていった。

トラフィック分析レポートによると、今回の攻撃のピークは347万ppsに達したが、プレイヤーのログイン遅延は一貫して83ms以下で安定し、ログイン成功率は17%から98.6%に回復した。

私は椅子にへたり込み、3杯目のブラックコーヒーを飲み干した。苦い液体が喉を滑り落ち、やっと張り詰めた神経が少しほぐれたのを感じた。

同僚の小王が温かい牛乳のカップを持ってやって来て、私の机の上に置いた。「片付いた？さっきはバックアップサーバーに切り替えるかと思ったよ。」

私は首を振り、画面の防御ログを指さした。「大丈夫だよ、Cookie机制とレピュテーション庫が耐え切った。バックアップノードは使わなかった。」

小王は笑いながら私の肩を叩いた。「このハッカーも執念深いな、午前3時に寝ずに攻撃するなんて。」

私はハッカーforumのブックマークページを開いた。先週見た「SYN Ghost 3.0」ツールがまだピン留め投稿に掲載されており、投稿者はCookie値の偽造で検知を回避できると主張し、添付のテスト動画では、某小型ゲームのサーバーが確かに攻略されていた。

「執念は執念だが、私たちも油断はできない。」

私はforumのページを小王に向けた。「明日出社したらこのツールをダウンロードし、解析してそのクラック原理を分析してくれ。ついでにサーバーの暗号化キーを更新し、毎日動的にローテーションするように変更しよう──ハッカーのツールが更新される度に、私たちの防御もアップグレードしなければならない。」

結局のところ、ゲームセキュリティは終わりのない猫と鼠のゲームだ。プレイヤーは、背後で300万ppsのSYN Floodが起こっているか、あるいは新しい攻撃手段が使われているかなど気にしない。ラグが10秒以上続けば、さっさとゲームを削除し、競合サーバーに移ってしまう可能性がある。

前回「Fantasy Continent」では、たった20秒のラグが原因で、その日のうちにデイリーアクティブプレイヤーの5%を失い、その後2ヶ月の運営キャンペーンと百万ドル近い特典を投入して、ようやくプレイヤーを呼び戻した。コストは防御への投資の3倍以上にもなった。

オペレーション部の壁には一行の赤いスローガンが貼ってある：「プレイヤーの10秒のラグは、私たちの100点の危機である」。

だから私たちは不文律を持っている：何時であろうと、モニタリングアラートが鳴れば、オペレーション要員は30分以内に配置につき、10分以内に初步的な防御方案を提示する。三重の冗長防御を余分に行っても、プレイヤーに一秒たりともラグを感じさせてはならない。

窗外はもううっすらと明るくなり、最初の陽光がオペレーションセンターのブラインドを通り抜け、モニタリングスクリーンに細長い光の斑点を投げかけていた。

私は画面の安定した緑の曲線を見つめ、温かい牛乳を一口飲み、心の中で悟った：この攻防戦は一時的に一段落しただけだ。次の警報は明日の明け方かもしれないし、明後日の午後かもしれない。しかし、プレイヤーがゲームにログインする瞬間を期待している限り、私たちはこの赤い防衛線を守り抜かねばならない。