こんにちは！ネットワークやインフラの世界へようこそ。
初めてサーバーを触ったり、Webサイトが動く仕組みを勉強したりしていると、何やら見慣れない横文字がたくさん出てきてクラクラしてしまいますよね。
「TCP？ 3ウェイハンドシェイク？ ステート遷移？」
「なんだか難しそう……私に理解できるかな……」
そんな不安を抱えているあなた、どうぞご安心ください！一歩ずつ、身近な例えを交えながら優しく紐解いていきましょう。今回は、インターネットの通信の土台を支える「TCPコネクション確立の裏側」と、そこに潜むセキュリティの脅威について、現場のプロの視点から熱くお伝えします！
—
1. 郵便配達でイメージする「TCPコネクション」
私たちが普段何気なく見ているWebページ。ブラウザにURLを入力してから画面が表示されるまで、実は裏側でサーバーとクライアント（あなたのパソコンやスマホ）が、ものすごいスピードで「挨拶のキャッチボール」をしています。
TCP（Transmission Control Protocol）というのは、「確実に、順番通りにデータを届けるための約束事」です。UDPが「とりあえず投げる！届いたかは知らん！」という手紙のポスティングだとすれば、TCPは「受領確認ハンコをもらう書留郵便」のようなものです。
そして、その書留郵便をやり取りする前に、「今から大事な荷物を送るけど、受け取る準備はいいかい？」とお互いに確認し合う儀式が、「3ウェイハンドシェイク（3段階の握手）」と呼ばれるプロセスなんです。
—
2. 3ウェイハンドシェイクの全貌とステート遷移のドラマ
このハンドシェイクの最中、パソコンやサーバーの中では、今の自分たちの関係性がどうなっているかを示す「ステート（状態）」が目まぐるしく変化しています。
まるで、初対面の2人が仲良くなるまでの心理状態の変化のようですよ。それぞれのステップを覗いてみましょう！
ステップ1：SYN送信（クライアント：SYN_SENT）
まず、クライアントがサーバーに対して、「おーい、お話しませんか？」と最初のパケット（SYN：Synchronizeの略）を送ります。
この瞬間、クライアントの心の中は「返事が来るのを待っている状態」、すなわち SYN_SENT（SYN送信済み）ステートになります。
「ちゃんと届いたかな……ドキドキ」と、返信をじっと待っている片想いのような状態ですね。
ステップ2：SYN受信とACK返信（サーバー：SYN_RCVD）
クライアントからの「お話しませんか？」を受け取ったサーバーは、「おっ、大歓迎だよ！私からもよろしくね！」という返事（SYN）と、「ちゃんと手紙を受け取ったよ」という確認（ACK：Acknowledgeの略）をセットにして送り返します。
このとき、サーバー側のステートが SYN_RCVD（SYN受信） になります。
「お、相手から話しかけられたぞ！こっちからも挨拶を返して、相手からの最終返事を待っている状態」ですね。いわば、両思いの確認が取れて、相手の最終返事を待っているドキドキのタイミングです。
ステップ3：接続完了！（お互いに ESTABLISHED）
サーバーからの返事を受け取ったクライアントは、「よーし、つながったね！」と最後に「確認オッケーの返事（ACK）」をサーバーに送ります。
この瞬間、クライアントもサーバーも、お互いのステートが ESTABLISHED（接続確立） に変わります！
めでたしめでたし、これで晴れてお互いに信頼し合える強固なコネクション（回線）が結ばれ、画像やテキストといった実際のデータをガンガン送り合えるようになるわけです。
—
3. この仕組みの裏に潜む魔物：SYNフラッド攻撃
さて、ここから少しセキュリティのお話をしましょう。
先ほど登場したステップ2の SYN_RCVD（SYN受信状態）、実はここにシステムをダウンさせる危険な罠が潜んでいます。
サーバーは、クライアントから SYN をもらうと、最終的な ACK が返ってくるまでの間、その接続を覚えておくためにメモリ（記憶のスペース）を少しだけ割り当てて待機します。
もし、悪意ある攻撃者が、実在しない適当なIPアドレスになりすまして、この SYN パケットを秒間何万発もサーバーに送りつけたらどうなるでしょうか？
[攻撃者] --(偽のSYN)--> [サーバー] (メモリを消費してSYN_RCVDで待機...返事こない！)
[攻撃者] --(偽のSYN)--> [サーバー] (メモリを消費してSYN_RCVDで待機...返事こない！)
[攻撃者] --(偽のSYN)--> [サーバー] (メモリを消費してSYN_RCVDで待機...返事こない！)サーバーは「おっ、また新しいお客さんだ！」と真面目にメモリを割り当てて SYN_RCVD の状態で待機し続けますが、相手は嘘の住所なのでいつまで経っても最後の ACK は返ってきません。
これを「SYNフラッド攻撃（SYN Flood Attack）」と呼びます。
サーバーの待機用メモリはあっという間にパンクし、本当に通信したい正当なお客さんのアクセスまで処理できなくなってしまいます。これが、Webサイトが突然繋がらなくなる原因の一つです。
—
4. 現場で役立つ！Linuxでのステート確認と対策
実務の現場でインフラを管理していると、「今、サーバーにどれくらい負荷がかかっているか」「変な接続待ちが溜まっていないか」を調査する場面に出くわします。
そんなときによく使う、Linuxの定番コマンドをご紹介しておきますね。ぜひ覚えて実務や検証環境で使ってみてください。
現在のTCPコネクションのステートを確認するコマンド
ターミナルを開いて、以下のコマンドを打ち込んでみましょう。
# 現在のTCPの接続状況（ステート）を一覧で確認する
ss -nat- 出力の見方のポイント:
LISTEN: サーバーが「お話しウェルカム！」と待ち受けている状態です（Webサーバーならポート80や443など）。SYN-RECV: 先ほど解説した、サーバーが接続の返事を待っているハーフオープン状態です。ここが不自然に何千件も並んでいたら、SYNフラッド攻撃を受けているか、アクセスが殺到しているサインです！ESTABLISHED: 元気にデータがやり取りされている健全な状態です。
現代のLinuxにおける防御設定（SYNクッキー）
先ほどのようなSYNフラッド攻撃に対して、現代のLinuxカーネルには素晴らしい防衛機能が備わっています。それが「SYNクッキー（SYN Cookies）」です。
設定ファイル（通常は /etc/sysctl.conf など）に以下の一行を追加することで、メモリを無駄に消費せずに攻撃をいなすことができます。
# /etc/sysctl.conf の末尾などに追記する設定例
# SYNフラッド攻撃を防ぐため、SYNクッキー機能を有効化する
net.ipv4.tcp_syncookies = 1設定を反映させるには、以下のコマンドを実行します。
# 設定ファイルを即座に反映させる
sudo sysctl -pこの「SYNクッキー」が有効になると、サーバーは手紙（SYN）を受け取っても、わざわざ専用のメモリを割り当てて記憶しません。その代わり、相手が送ってきた情報をもとに計算した「暗号のしるし（クッキー）」を返事（SYN-ACK）のなかにこっそり混ぜ込んでおきます。
そして、クライアントから正しい「しるし」付きの返事（ACK）が返ってきたとき初めて、メモリを割り当ててコネクションを確立するのです。
攻撃者の嘘には一切メモリを使わない、非常にスマートで強力な仕組みですね。
—
まとめ
いかがでしたでしょうか？
TCPの3ウェイハンドシェイクとステート遷移、そしてSYNフラッド攻撃のメカニズムが、少し身近に感じられたのではないでしょうか。
SYN_SENT: クライアントが返事を待っている片想い状態。SYN_RCVD: サーバーが返事をして、最後の確認を待っている状態（ここが攻撃の標的になりやすい）。ESTABLISHED: お互いに繋がって、ガッチリ通信できる状態。
インフラやネットワークの世界は、こうした「目に見えないやり取りのドラマ」の積み重ねで成り立っています。
日々のトラブルシューティングやセキュリティ対策も、基本となるこのパケットの流れとステートの理解さえあれば、怖くありません。一歩ずつ、確実に知識を血肉にしていきましょう！
それでは、また次回の技術解説でお会いしましょう！
コメント