キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
8254
閲覧回数
11
いいね!
5
返信

ステートフルインスペクションは何を見て、戻りトラフィックである事を判断する?

tomo456
Level 1
Level 1

「ステートフルインスペクション」はトラフィックの情報を読み取り、送信したトラフィックに対し、
その戻りトラッフィクの通信を許可する技術であると認識しています。


疑問は表題の通りなのですがどの情報確認して、戻りトラフィックである事を判断しているのですか?
一応、なんとなくですが、以下の情報を確認していることは理解いたしました。

TCPの場合
①L4ヘッダ内のコントロールフラグ(ACK=1である事)
②元&宛IPアドレス(L3ヘッダ)
③元&宛ポート番号

●質問
 ・③はどのレイヤのヘッダ情報でしょうか?
 ・そのほかに確認している情報がありますか?
 ・UDPの場合、どの情報を確認していますか(TCPとの確認情報の違いは①の有無だけ)?

質問のご回答、また私に間違った認識に対しての指摘など、ご意見を伺いたく思います。
宜しくお願い致します。

1 件の受理された解決策

受理された解決策

Akira Muranaka
Level 8
Level 8


こんにちは!

いい質問ですね。 TCPの戻り通信は、基本的に レイヤー3のIPアドレス情報や レイヤー4のポート情報の他、シーケンスやACK番号を利用して、そのセッション(コネクション)に該当した戻りパケットかどうか判定してます。シーケンスやACK番号は データ交換するたびに加算されていくので、このシーケンスやACK番号も追跡することで、不正なパケットの混入などを防止してます。

UDP通信の場合は、UDPはコネクションレスの通信なので、ご認識の通り ②や③で 戻りパケットかどうか確認してます。

元の投稿で解決策を見る

5件の返信5

Akira Muranaka
Level 8
Level 8


こんにちは!

いい質問ですね。 TCPの戻り通信は、基本的に レイヤー3のIPアドレス情報や レイヤー4のポート情報の他、シーケンスやACK番号を利用して、そのセッション(コネクション)に該当した戻りパケットかどうか判定してます。シーケンスやACK番号は データ交換するたびに加算されていくので、このシーケンスやACK番号も追跡することで、不正なパケットの混入などを防止してます。

UDP通信の場合は、UDPはコネクションレスの通信なので、ご認識の通り ②や③で 戻りパケットかどうか確認してます。

ご回答、ありがとうございます。


TCP
・L3のIPアドレス
・L4の元&宛ポート情報
・シーケンス番号
・コントロールフラグ(ACK)

UDP
・L3のIPアドレス
・L4の元&宛ポート情報

 Akira Muranaka様

 

こちらは少し古い投稿ですが、最近不思議な事象があったので質問させてください。

以下のような環境があるとします。

 

------------

サーバ1(10.1.1.10)---interface1 ASA interface2 ---サーバ2(10.2.1.10)

                |

                                                interface3

------------

 

ASAには次のようなルートを入れていたとします。

route interface1 10.0.0.0 255.0.0.0 10.1.1.1 1

route interface3 10.1.1.0 255.255.255.0 10.3.1.1 1

サーバ2(10.2.1.10)のセグメントはdirectly connected

 

事象としては

  1. サーバ1(10.1.1.10)からサーバ2(10.2.1.10)への通信は成功
  2. サーバ2(10.2.1.10)からサーバ1(10.1.1.10)への通信は失敗(ルーティングとしてロンゲストマッチでinterface3から出ていくため)

 

事象2は失敗するのは理解できるのですが、事象1が成功したのが少し理解できません。

もし戻り通信でルーティングテーブルを見ているのであればinterface3の方へ行き失敗すると思います。

 

事象1はステートフルインスペクションの機能で、戻り通信の際に接続データのinput/outputのセッション情報(今回で言うとinput/interface1 → output/interface2など)を見て、元来た道を使って戻ったから成功したのでしょうか?

 

以上、よろしくお願いいたします。

Akira Muranaka
Level 8
Level 8

こんにちは!

 

はい、私も ヤマダさんのご指摘のとおりかと思いました! コネクション情報に Ingressと Egress情報は記録されているため、状況的に Connection情報が優先されるためだと思います。

 

コネクションの Ingress・Egress Interfaceの制御能力はRouting Tableよりも強いはずです。例えば ASA/FTDは Policy Base Routing (PBR) をサポートしており PBRが適用されたコネクションはRoutingテーブルに関係なく Egress Interfaceを強制転送可能です。同じ理屈で今回の事象が発生してるのでは、と思いました。

 

参考:
https://community.cisco.com/t5/-/-/ta-p/4307203

いつもご回答ありがとうございます!!

 


コネクションの Ingress・Egress Interfaceの制御能力はRouting Tableよりも強いはずです。例えば ASA/FTDは Policy Base Routing (PBR) をサポートしており PBRが適用されたコネクションはRoutingテーブルに関係なく Egress Interfaceを強制転送可能です。同じ理屈で今回の事象が発生してるのでは、と思いました

なるほど。すごく勉強になりました!

ありがとうございます。