*ステートフルインスペクション－その３*

ここでは引き続き、ファイアウォール機器が実装しているステートフルインスペクション機能について説明します。
以下、2人の会話をご覧ください。

後輩 せんぱ～い (^ー^*)
今日もよろしくおねがいします。
先輩 うんうん。
後輩 昨日は周りのものが全部パケットに見えちゃいましたよ～ヾ(・ε・。)
夢にも見ちゃいました。
先輩 うんうん、パケットの気持ちが分かって良かったね～ (･ε･。)ヾ(^ー^;)
後輩 これから毎日、パケット漬けの日々が続くんですね。。。ε=(´∇｀;)
先輩 まぁ、そう言うな。
そういえば、ステートフルインスペクションの処理フロー図が見つかったよ。(．．)

Filter図5

後輩 う～ん、この「せっしょんてーぶる」って言うのは何ですか？
先輩 あぁ、コレね。前に説明した、「通信が始まるときに動的に生成されるフィルタ」のことだよ。
後輩 「フィルタ」じゃなくて「テーブル」なんですね。
でも、やっぱり良く分かんない。。。（？＿？）
先輩 IPアドレスやポート番号だけじゃなくて、そのTCPセッションに関するその他の情報も退避されているんだ。
セッションの情報が記録されているテーブルだから、「セッションテーブル」。
後輩 そっか。
シーケンス番号とか、他の情報もチェックするんでしたね。
先輩 そう。
で、初めてのパケット、つまりSYNパケットが来ると、こんな動きになる。(．．)

Filter図6

後輩 初めてのパケットだから、セッションテーブルに存在しないんですね。( ゜゜)
でもポリシーでは許可されているから、そのセッションをテーブルに登録してからパケットを転送すると。
先輩 そう(￣ー￣)
で、そのセッションに続くその後のパケットの処理はこんな感じ。(．．)

Filter図7

後輩 既にセッションテーブルに登録されているから、現在のセッション状態との整合性をチェックするんですね。( ゜゜)
じゃ、2番目以降のパケットは、全てこの処理フローになるんですね。
先輩 そうそう(￣ー￣)(￣ー￣)
うまく出来てるだろう？
後輩 今の話は分かったんですけど、1つ質問がありまーす (^o^)／
先輩 ん？
後輩 最初のパケットのフラグがSYNじゃなかった場合は3-WAYハンドシェイクと照らし合わせるとルール違反になると思うんですけど、どこで拒否されるんですか？
先輩 ほぉ～、いい質問だね。 (・ω・)
ポリシーでチェックされる対象はSYNパケットだけだから、それ以外のパケットはポリシーでチェックされる前に拒否されるんだ。
後輩 なるほど～、確かに良く出来てますね。
そういえば、前に言っていた問題点って何ですか？
先輩 あ～、問題点というわけじゃないんだけど。
どっちかというと、注意事項かな。
後輩 もったいぶらずに教えてくださいヨ～（＞_＜。)
先輩 まぁ、焦るな。
この「セッションテーブル」っていうのが引っ掛かるところなんだ。
後輩 え～、でも、セッションテーブルのおかげでこの仕組みが成り立つんですよね？
先輩 もちろんそうなんだけど、一度登録したセッションテーブル上のセッションを、いつ消すかが問題なんだ。
後輩 （？＿？）
通信が終わったら、消せばいいんじゃないですか？
先輩 さぁ、そこだ。( ﾟДﾟ)_σ
終わったかどうかの判断は、どうやって？
後輩 えっ？
3-WAYハンドシェイクで、FINパケットが来たら終わったと判断すればいいんじゃ。。。？(;´Д`)
先輩 うん、ほとんどの場合はそれでいいんだけど、ユーザが端末のケーブルを抜いたり、アプリケーションが突然終了した場合はどうかな？
後輩 それは無理かもしれませんけど。。。
そういうのはあんまり気にしなくてもいいんじゃないですか？
先輩 うん、出来れば気にしたくないんだけど。
ネットワーク機器というのは、通常は24時間365日連続稼動が前提なので、そうもいかないんだ。
後輩 （？＿？）
先輩 つまり、仮にそういうセッションが全体の数パーセントだったとしても、理論的には永遠に消えることがないから、どんどんメモリ上のゴミとして溜まっていくので非常にマズいんだ。
後輩 （！＿！）
先輩 なので、各セッションにはタイムアウト値が設定されているんだよ。
最後のパケットを処理してから一定の時間が経過すると、勝手に消えてくれるのでゴミにならないんだ。
後輩 はぁ～、完璧じゃないですか！
そこまで考えられているのに、注意事項なんてあるんですか？
先輩 最後のパケットを処理してから一定の時間で消去するということは、逆に考えるとどうなる？
後輩 む、難しいことを聞きますね。え～っと、通信がなかったら消える。。。（ｰ'`ｰ;）
先輩 実際に通信しているホスト間は、データを流していなくてもセッションをお互いに保持しているはずだよね？
後輩 あっ、もしかして！（・０・☆）
ホスト間はセッションを終了していなくても、無通信だったらお構いなしに自分のテーブルから消しちゃう？
先輩 そうそうそうそう(￣ー￣)(￣ー￣)(￣ー￣)(￣ー￣)
つまり、こんな感じね(．．)

Filter図8

後輩 な、なるほど～（ﾟ〇ﾟ；）
セッションテーブルから消えちゃったから、ポリシーチェックに行っちゃうんですね～。
先輩 そうそうそうそうそう(￣ー￣)(￣ー￣)(￣ー￣)(￣ー￣)(￣ー￣)
後輩 で、そんな事情を知らないホストが出したパケットはセッションの続きのパケットだからSYNフラグが立っていなくて、ポリシーチェックの対象にならずに拒否されてしまうんですね～！
先輩 そうそうそうそうそうそう(￣ー￣)(￣ー￣)(￣ー￣)(￣ー￣)(￣ー￣)(￣ー￣)
後輩 せ、せんぱい！
わたし、どうしたらいいんですか～？(＠Д＠;）
先輩 い、いや、そんなに取り乱さなくても。。。（￣◇￣；
これは理論的にジレンマの状態だから、仕方ないんだよ。でも、タイムアウト値は変えられるから、ある程度は調整可能だよ。
後輩 そっか。長くすれば、テーブルから消えずに済みますね。
でも、根本的な解決にはならないような。。。（￣ー￣？）
先輩 そう、察しがいいね。例えばTELNETなどのように対象を管理するような通信の場合、ログインしたまま放置される可能性もあるね。そのまま何もしなければ無通信状態になっちゃうけど、「どれぐらいの間、何もしない状態が続くか？」なんて誰も決められないよね。
後輩 そうですよね。TELNET接続を放置しておくのもどうかと思いますが、それは使う人の勝手だし。。。
確かに、これは注意事項ですね。
先輩 というわけで、かなり長かったけどステートフルインスペクションの話はこれで終わり！∠(・_・)
理解できたかな？
後輩 難しかったけど、何とか理解できました！∠(・_・)
ありがとうございました～。

以上でアクセス制御の話は終わりです。
引き続き、「アクセスポリシーの策定」をご覧ください。。。

ネットワークセキュリティ関係者の部屋 > ネットワークセキュリティ実践劇場 > ステートフルインスペクション－その３