こんにちは！インフラやセキュリティの世界へようこそ。
初めてネットワーク機器やファイアウォールの設定画面を開いたとき、「ステートフル・パケット・インスペクション（SPI）」なんていう、かみそうな名前の機能を見て、「うっ、なんだか難しそう……」と冷や汗をかいた経験はありませんか？
大丈夫です！一歩ずつ、身近な例えから紐解いていけば、決して怖いものではありません。今回は、このSPIの仕組みと、そこに潜む落とし穴（脆弱性）、そして現場で私たちがどうやって守っているのかを、一緒に優しく学んでいきましょう！
—
1. ファイアウォールの「SPI（ステートフル・パケット・インスペクション）」ってなに？
いきなり難しい専門用語が出てきましたが、まずは私たちの日常生活に置き換えて考えてみましょう。
家の玄関の鍵と「メモ帳」の例え
想像してみてください。あなたは自分の家（社内ネットワーク）にいます。
昔ながらの古いファイアウォール（パケットフィルタリング）は、「この宛先の郵便物は入れちゃダメ」「この住所からのはOK」という、あらかじめ決めたルール表（表札のチェックリスト）だけを機械的に見て判断する頑固な門番でした。これだと、賢い泥棒が「住民の知り合いのふり」をして郵便物を偽装すると、簡単にスルーして通してしまいますよね。
そこで登場したのが、SPI（ステートフル・パケット・インスペクション）です。
SPIは、ただルール表を見るだけでなく、「いま、誰が外に出かけていて、誰とどんな会話をしているか」をメモ帳（セッションテーブル）にしっかり記録する優秀なコンシェルジュのような存在です。
1. 家の中（あなた）から外（ネット）へ行くとき：
「〇〇くんが、お使いに行ってきます！」とコンシェルジュのメモ帳に記録されます。
2. 外から返事が返ってきたとき：
コンシェルジュはメモ帳を開き、「あ、これはさっき〇〇くんが外に出したお使いの返事だな。だから通してあげよう！」と、通信の「文脈（ステート）」をちゃんと理解して通します。
3. 中から誰も声をかけていないのに、外から突然やってきたとき：
「あれ？ メモ帳にそんな予定（セッション）はないぞ。怪しいな！」と、ビシッと門前払いしてくれます。
この「通信の文脈や状態（State）を記憶して検査する（Inspection）」仕組みが、SPIの正体なんです。
—
2. 攻撃者が狙う盲点！「セッションテーブル枯渇攻撃（DoS）」のメカニズム
とっても賢いコンシェルジュ（SPI）ですが、実は「ある弱点」を抱えています。それは、「メモ帳（セッションテーブル）のページ数には限界がある」ということです。
セキュリティの現場では、この弱点を突いた「セッションテーブル枯渇攻撃（Stateful Firewall DoS）」といういやらしい攻撃が仕掛けられます。
いたずら電話でメモ帳をパンクさせる手口
攻撃者は、次のような意地悪を仕掛けます。
1. 家の中（社内ネットワーク）から外へ行くふりをして、膨大な数の「偽の外出予定（TCPの接続要求：SYNパケット）」をコンシェルジュに次々と伝えます。
2. コンシェルジュは真面目なので、「はい、わかりました！〇〇の予定ですね」と、自分のメモ帳にぜんぶ書き留めていきます。
3. しかし、攻撃者は実際にはお使いに行かず、連絡を無視し続けます。
4. あっという間に、コンシェルジュのメモ帳のページが真っ黒になり、満杯になってしまいます。
こうなるとどうなるでしょうか？
メモ帳がパンクしたコンシェルジュは、新しくやってきた本物の家族（本当の業務システムへのアクセス）からの「お使いに行ってきます！」という声すら、メモするスペースがなくて「ごめんなさい、今いっぱいでメモできません！」と拒絶せざるを得なくなります。
結果として、システム全体がダウンしてしまう……これが、セッションテーブル枯渇攻撃の恐ろしい仕組みです。
—
3. 現場のエンジニアはどう守っているのか？（実用的な対策と設定）
「じゃあ、メモ帳を無限に大きくすればいいじゃない！」と思われるかもしれませんが、ハードウェアのメモリ（リソース）には必ず限界があります。
そこで、私たちインフラエンジニアは、現場で次のような対策を組み合わせてファイアウォールやロードバランサーを守っています。
対策のポイント
- タイムアウト時間を短くする： 返事が来ない中途半端な通信のメモを、短い時間で自動的に消しゴムで消すように設定します。
- SYNフラッド対策（SYNバリケード）： 偽の連絡を大量に送りつける攻撃に対して、本物の通信かどうかを確かめる仕組み（クッキー技術など）を有効にします。
実際のネットワーク機器（例：Linuxのiptablesや一般的なファイアウォール）では、セッションの寿命（タイムアウト値）をチューニングすることが基本のキになります。以下は、その考え方を反映した設定のイメージです。
# 【Linux系ファイアウォール(iptables/netfilter)のチューニング例】
# コメント: 確立されていない（ハンドシェイク中のような）怪しいコネクションのタイムアウトを短くし、
# セッションテーブルが枯渇するのを防ぎます。
# TCPの接続確立待ち（SYN_RECV状態）のタイムアウトをデフォルトより短縮 (例: 30秒)
sudo sysctl -w net.ipv4.tcp_synack_retries=2
# 接続がアイドル状態（しばらく通信がない状態）になったセッションの掃除時間を調整
# コメント: 長時間放置された無駄なセッションを自動削除し、メモリを空けさせます。
sudo sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=120※実務では、ご利用の機器（Cisco、Palo Alto、Fortinet、AWS Security Groups など）のマニュアルを確認し、適切なタイムアウト値（TCP Timeout / UDP Timeout）を設定してくださいね。
—
4. まとめ：一歩ずつ、確実な守りを身につけよう
今回は、ファイアウォールの心臓部である「SPI（ステートフル・パケット・インスペクション）」の仕組みと、セッションテーブル枯渇という盲点についてお話ししました。
- SPIは、通信の「文脈（状態）」をメモ帳に記録して賢く不正を防ぐ機能であること。
- しかし、そのメモ帳のキャパシティには限界があり、攻撃者はそこを狙ってリソースを食いつぶそうとする（DoS）こと。
- 私たちは、タイムアウトの調整や適切なリソース管理によって、その泥棒の手口からインフラを守っていること。
セキュリティの世界は一見すると難しい言葉の連続ですが、こうして身近な例えに落とし込んでいけば、本質はとてもシンプルです。
「なんだ、そういうことだったんだ！」という小さな「わかった！」を積み重ねながら、一歩ずつ頼もしいエンジニアへの階段を登っていきましょう。
それでは、また次のセキュリティの冒険でお会いしましょう！
コメント