こんにちは！NOC（ネットワークオペレーションセンター）の現場で、日々ネットワークを流れる無数のパケットたちと格闘しているシニアエンジニアの「タカさん」です。
皆さんは、Webサイトにアクセスしたとき、裏側でどのような「会話」が行われているか想像したことはありますか？
インターネットの世界では、私たちが普段使っているスマートフォンやパソコンと、お目当てのWebサーバーとの間で、目にも留まらぬ速さで丁寧な「挨拶」が交わされています。
しかし、時にはその丁寧な挨拶の仕組みを悪用して、サーバーを動けなくしてしまう「SYN（シン）フラッディング攻撃」といういたずら（サイバー攻撃）が発生することがあります。
「なんだか難しそうな名前だな…」と思った方も安心してください！今回は、この攻撃の仕組みと、サーバーの中で何が起きているのかを調べるためのコマンド（ss や netstat）の使い方を、身近な「郵便局の窓口」や「電話のやり取り」に例えて、一歩ずつ丁寧に紐解いていきます。
インフラの世界へ一歩を踏み出したばかりのあなたも、この記事を読み終える頃には、障害の予兆をスマートに見つけ出せるようになりますよ。それでは、一緒に学んでいきましょう！
—
1. TCPの「3ウェイ・ハンドシェイク」は、とても丁寧な電話の挨拶
ネットワークの通信で最もよく使われる「TCP」というプロトコル（約束事）では、データを送る前に必ずお互いの意思を確認し合います。これを3ウェイ・ハンドシェイク（3方向の握手）と呼びます。
これを、日常の「電話」に例えてみましょう。
【ステップ1】 あなた（クライアント）：「もしもし、聞こえますか？」（SYN）
↓
【ステップ2】 相手（サーバー）：「はい、聞こえますよ！そちらも聞こえますか？」（SYN-ACK）
↓
【ステップ3】 あなた（クライアント）：「はい、聞こえます！よろしくお願いします！」（ACK）このように、3回のやり取りがあって初めて「よし、お互いに声が届くね。話を始めよう！」と、通信のパイプ（コネクション）がつながります。
ここで注目してほしいのが、【ステップ2】の段階です。
サーバーは「はい、聞こえますよ！」と返事（SYN-ACK）をした後、あなたから「よろしくお願いします！」という最後の返事（ACK）が返ってくるのを、受話器を耳に当てたままじっと待っています。
この「最後の返事を待っている一時的な状態」のことを、専門用語で SYN_RECV（シン・レシーブ） と呼びます。
—
2. SYNフラッディング攻撃：悪意ある「呼び出しっぱなし」
では、もし悪意を持った人が、この仕組みを悪用したらどうなるでしょうか？
犯人は、大量のコンピューターを使って、サーバーに対して「もしもし！」（SYN）という電話をものすごい勢いでかけまくります。
サーバーは生真面目ですから、かかってきた電話すべてに対して「はい、聞こえますよ！」（SYN-ACK）と返事をし、相手からの最後の返事（ACK）を待ちます。
しかし、犯人は最初から会話をする気はありません。最後の「よろしくお願いします！」（ACK）を絶対に返さないのです。あるいは、存在しない嘘の電話番号（IPアドレス）を使って電話をかけてくるため、サーバーの返事は虚空に消えてしまいます。
犯人：「もしもし！」（SYN）
サーバー：「はい、聞こえますよ！」（SYN-ACK）
（……犯人は沈黙……）
サーバー：「あれ？返事がないな。受話器を持ったまま、もう少し待ってみよう...」（SYN_RECV状態でキープ）これを「SYN（シン）フラッディング攻撃」と呼びます。「フラッド（Flood）」とは「洪水」という意味。つまり、返事待ちの電話でサーバーを洪水のように溢れさせてしまう攻撃です。
サーバーの「受付窓口（ソケットバッファ）」が満杯に！
サーバーのメモリの中には、この「返事待ちの電話」を一時的に並べておく「待合室（リッスンキュー / ソケットバッファ）」が用意されています。
しかし、待合室の椅子の数には限りがあります。
返事の来ない電話（SYN_RECV 状態の接続）で待合室の椅子がすべて埋まってしまうと、一般のユーザーが「もしもし！」と電話をかけてきても、サーバーは「もう満席で、誰も待合室に入れません！」と、接続を拒否せざるを得なくなります。
これが、Webサイトが繋がらなくなってしまうメカニズムなのです。
—
3. 現場の武器：ss と netstat コマンドで異常を見抜く
NOCのエンジニアは、Webサイトの動きが重くなったり、繋がらなくなったりした時、すぐにサーバーにログインして「待合室の状態」を観察します。
その時に使う強力な武器が、ss（ソケット統計） コマンドや netstat（ネットワーク統計） コマンドです。
※最近のLinuxでは、より高速で詳細な情報が表示できる ss コマンドの使用が推奨されていますが、古くから使われている netstat も現役で見かけることがあります。
ss コマンドで「待合室の行列」を見てみよう
まずは、現在の接続状態を表示するコマンドを実行してみましょう。
# 接続の状態（State）が「SYN-RECV」になっているものだけを絞り込んで表示します
ss -n -t state syn-recvもし、サーバーがSYNフラッディング攻撃を受けている場合、このコマンドを実行すると、画面に以下のような行が何百行、何千行とギッシリ表示されることになります。
State Recv-Q Send-Q Local Address:Port Peer Address:Port
SYN-RECV 0 0 192.168.1.100:80 203.0.113.5:12345
SYN-RECV 0 0 192.168.1.100:80 198.51.100.22:54321
SYN-RECV 0 0 192.168.1.100:80 203.0.113.88:9876
... (延々と続く) ...State（状態）: すべてSYN-RECVになっていますね。最後の返事を待って、身動きが取れなくなっている接続です。Local Address:Port: あなたのWebサーバーのIPアドレス（例:192.168.1.100）と、Webポート（80番）です。Peer Address:Port: 相手（送信元）のIPアドレスです。攻撃の際は、ここがデタラメなIPアドレスで埋め尽くされることが多いです。
netstat で SYN_RECV の数を数えてみよう
「画面を埋め尽くす文字を見るより、今いくつ SYN_RECV があるのか数字で知りたい！」という時は、以下のようにお馴染みのコマンドを組み合わせて数をカウントします。
# netstatの出力から「SYN_RECV」という文字を検索し、その行数をカウントします
netstat -an | grep SYN_RECV | wc -l普段の平穏なサーバーであれば、この数字は 0 や、せいぜい 数個 程度です。
しかし、攻撃を受けている最中は、この数字が 1000 や 5000 といった異常な値に跳ね上がります。
これこそが、サーバーの中で「待合室が満杯になって悲鳴を上げている」決定的な証拠（兆候）なのです。
—
4. サーバーの「待合室」を広げる・守るための設定
もし、あなたの管理するサーバーがこのような状況に陥ったら、どうすれば良いでしょうか？
Linuxサーバーには、この「呼び出しっぱなし攻撃」から身を守るための設定（カーネルパラメーター）が用意されています。
設定ファイル /etc/sysctl.conf に以下の設定を書き込むことで、サーバーの防衛力をぐっと高めることができます。
# --- SYNフラッディング攻撃対策の設定例 ---
# 1. SYN Cookies（シン・クッキー）を有効にする
# これを「1」にすると、待合室が満杯になっても、特別な「引換券（クッキー）」を発行することで、
# 待合室の椅子を使わずに安全に接続を処理できるようになります。最大の防御策です！
net.ipv4.tcp_syncookies = 1
# 2. 待合室（SYN半オープン接続のキュー）の容量を増やす
# デフォルト値（128や512など）から大きく増やして、より多くの「返事待ち」に耐えられるようにします
net.ipv4.tcp_max_syn_backlog = 2048
# 3. 返事が来ない相手にあきらめて電話を切るまでの回数を減らす
# デフォルトでは5回ほど掛け直しますが、これを「2回」程度に減らすことで、諦めを早くし、
# 溜まった「SYN_RECV」状態を素早くお掃除（解放）します
net.ipv4.tcp_synack_retries = 2設定の反映方法
設定を書き換えたら、以下のコマンドを実行してシステムに即座に反映させます。
# 設定ファイルの内容をシステムに即時反映するコマンドです
sudo sysctl -pこれで、サーバーは「悪意ある呼び出し」に対して非常にタフになり、簡単には倒れなくなります！
—
まとめ
最後に、今回学んだ大切なポイントをおさらいしましょう！
1. 3ウェイ・ハンドシェイクは、通信を始めるための「もしもし」「はい」「よろしく」の3ステップ。
2. 最後の「よろしく」を待っている状態が SYN_RECV。
3. SYNフラッディング攻撃は、最後の「よろしく」をわざと返さず、サーバーを返事待ち（SYN_RECV）のパケットで埋め尽くす攻撃。
4. 異常事態は、 ss や netstat コマンドを使って、SYN_RECV の数が異常に増えていないか調べることで検知できる。
5. 対策として、 tcp_syncookies や tcp_max_syn_backlog などの設定を調整する。
ネットワークのトラブルシューティングは、まるで「パケットという目に見えない郵便物の迷子や、いたずら電話の犯人を探す探偵」のような仕事です。
難しそうに見える黒い画面（CLI）も、こうして現実世界に置き換えてみると、何が起きているのかがすんなりイメージできるようになりますよね。
焦らず、一歩ずつ。パケットの気持ちに寄り添いながら、頼れるインフラエンジニアへの道を歩んでいきましょう！応援しています！
コメント