HOME»情報処理安全確保支援士掲示板»平成29年春午後Ⅰ問1設問3(2)
投稿する
はい。TCPがコネクションを確立するためには3WAYハンドシェイクという手順が必要です
以下3つのパケットが正常にやり取りされてコネクションが確立されます。
SYN :接続元->接続先
SYN+ACK:接続元<-接続先
ACK :接続元->接続先
設問では、PCセグメントにあるPCが管理用PCのIPアドレスを詐称して、サーバセグメントの
サーバに通信しようとします。
その際、SYNは(C)->(A)の経路を通りますが、SYN+ACKはFWのルーティングテーブルにより
サーバセグメントの管理用PCへ返ろうとするので、(A)->(B)の経路を通ることになります。
そのためIPアドレスを詐称したPCにはSYN+ACKが返ってこず、3WAYハンドシェイクに
失敗します。
この設問で厄介なのは、3WAYハンドシェイクに失敗する理由が、表5のFWのフィルタリング
ルールだけではなく、暗黙のFWのルーティングによるものであるところです。
また、偽装したIPアドレスがステートフルパケットインスペクションとルーティングに
どのような作用をするかについての細かい動作は不明です。しかし設問の本質的な部分で
はないので、そこについては言及しません。
P6 最初の部分「・・・、図4のようにネットワーク構成を変更し、表5のようにFWの
フィルタリングルールを変更することとした。」
とあります。この記述から変更があったのは
・ネットワーク構成
・FWのフィルタリングルール
の2点になります。
また表5にFWのフィルタリングルールが大きく目立つように記載されています。
そのため、3WAYハンドシェイクが失敗する原因はFWのフィルタリングルールに
よるもののようにみえます。
しかし、本質的にはネットワーク構成の変更によるルーティングにより、
SYN+ACKが(A)->(B)に流れるからと推測されます。
本文中にはルーティングについて触れられていないので、ルーティングと
気づくのは少々難しいのかもしれません。
以前も同様の疑問が議論されたことがあったと記憶します。
この設問のネットワークの動作については単純そうに見えて、結構ややこしい
ということになります。
大変恐縮ですが、表5の項番24はルーティングではなく、フィルタリングです。
暗黙のFWのルーティングというのは、このFWにはNICが4つ
（インターネット、サーバセグメント、サーバ管理セグメント、PCセグメント）あり、
そのNICに対するルーティングを指します。
No.4の最後にも書きましたが、
OSや製品によって挙動が異なると思われます。
特にCisco系の機器での考え方と、Linux系OSでのプロトコルスタックでの考え方の
違いで、挙動が異なると思われます。
私の認識ではFWの保持しているステートの状態にもよりますが、SYNは
項番4の行きとして、SYN+ACKは項番4の戻りとしてFWで許可された後、
ルーティングでサーバ管理セグメントに流れたと想定しています。
前提として、このFWのステートはインターフェース情報は保持せず、純粋に
IPアドレスとポート番号のみをステートとして保持している必要があります。
この点については、インフラエンジニアとネットワークエンジニアとで
見解が異なると思われます。
私はLinuxが専門のインフラエンジニアなので、Linuxのプロトコルスタック的に
検討しました。IPアドレス偽装していても、FWのフィルタリングルールはすり抜け
られるが、ネットワーク層のルーティングで矛盾が生じてしまい、別の
ネットワークに流れるという認識です。
ですが、Cisco製品がメインのネットワークエンジニアの方だと、もっと別の
FWの挙動から考察をするかもしれません。特にFWがインターフェースからの
情報も加味している可能性をあげるかもしれません。
このようなさまざまな観点の話が過去にもあり、具体的に最終的な挙動を
確定するのは難しかったと記憶しています。
しかし、FWが単なるルータだったと仮定すれば、IPアドレス偽装をしても
結論としてルーティングで矛盾が生じることは確実なので、これを
解答と認識しております。
平成29年春午後Ⅰ問1設問3(2) [1452]
きなこさん(No.1)
この設問の解答はSYNパケット：C→A、SYN＋ACK：A→Bとなっており、経路については送信元のIPアドレスの詐称の影響によるもので、なんとなくわかるのですが、この場合、TCPコネクションが確立しないのは、SYNとSYN+ACKの経路が上記のように異なるからでしょうか。
手元の解説では、「当該パケットはFWによってサーバ管理セグメントの正当な管理用PCに中継されるため、TCPコネクションは確立しない」との記載があり、これが理解できず。。
手元の解説では、「当該パケットはFWによってサーバ管理セグメントの正当な管理用PCに中継されるため、TCPコネクションは確立しない」との記載があり、これが理解できず。。
2024.03.27 18:23
pixさん(No.2)
★SC ダイヤモンドマイスター
>この場合、TCPコネクションが確立しないのは、SYNとSYN+ACKの経路が上記のように
>異なるからでしょうか。
はい。TCPがコネクションを確立するためには3WAYハンドシェイクという手順が必要です
以下3つのパケットが正常にやり取りされてコネクションが確立されます。
SYN :接続元->接続先
SYN+ACK:接続元<-接続先
ACK :接続元->接続先
設問では、PCセグメントにあるPCが管理用PCのIPアドレスを詐称して、サーバセグメントの
サーバに通信しようとします。
その際、SYNは(C)->(A)の経路を通りますが、SYN+ACKはFWのルーティングテーブルにより
サーバセグメントの管理用PCへ返ろうとするので、(A)->(B)の経路を通ることになります。
そのためIPアドレスを詐称したPCにはSYN+ACKが返ってこず、3WAYハンドシェイクに
失敗します。
この設問で厄介なのは、3WAYハンドシェイクに失敗する理由が、表5のFWのフィルタリング
ルールだけではなく、暗黙のFWのルーティングによるものであるところです。
また、偽装したIPアドレスがステートフルパケットインスペクションとルーティングに
どのような作用をするかについての細かい動作は不明です。しかし設問の本質的な部分で
はないので、そこについては言及しません。
2024.03.27 18:50
きなこさん(No.3)
早速のご回答ありがとうございます。
接続先と接続元が異なるからですね。
→すみません、上記がよくわからなく、可能であれば解説いただけますと助かります。
接続先と接続元が異なるからですね。
>この設問で厄介なのは、3WAYハンドシェイクに失敗する理由が、表5のFWのフィルタリング
> ルールだけではなく、暗黙のFWのルーティングによるものであるところです。
→すみません、上記がよくわからなく、可能であれば解説いただけますと助かります。
2024.03.27 18:57
pixさん(No.4)
★SC ダイヤモンドマイスター
>→すみません、上記がよくわからなく、可能であれば解説いただけますと助かります。
P6 最初の部分「・・・、図4のようにネットワーク構成を変更し、表5のようにFWの
フィルタリングルールを変更することとした。」
とあります。この記述から変更があったのは
・ネットワーク構成
・FWのフィルタリングルール
の2点になります。
また表5にFWのフィルタリングルールが大きく目立つように記載されています。
そのため、3WAYハンドシェイクが失敗する原因はFWのフィルタリングルールに
よるもののようにみえます。
しかし、本質的にはネットワーク構成の変更によるルーティングにより、
SYN+ACKが(A)->(B)に流れるからと推測されます。
本文中にはルーティングについて触れられていないので、ルーティングと
気づくのは少々難しいのかもしれません。
以前も同様の疑問が議論されたことがあったと記憶します。
この設問のネットワークの動作については単純そうに見えて、結構ややこしい
ということになります。
2024.03.27 19:19
きなこさん(No.5)
ご回答ありがとうございます。
なるほど、FWのフィルタリングルールが引掛けのように用意されているので、ルーティングによるものだということが気づきにくい、ということですね。
なるほど、FWのフィルタリングルールが引掛けのように用意されているので、ルーティングによるものだということが気づきにくい、ということですね。
2024.03.27 19:33
tnsさん(No.6)
TCPコネクションが確立しないのは、pix様のおっしゃる通り3WAYハンドシェイクの失敗によるものです。暗黙のFWのルーティングというのは、恐らく表5の項番24の事だと思います（ciscoだと暗黙のdeny）。
ただし、スレ主様はarpの動作を理解されていない思われます（見当違いであればごめんなさい）。
【同一セグメントへのarp】
・ルータを経由しない
・自身でarp（L2のブロードキャスト）を行う
【別セグメントへのarp】
・ルータを経由する
・ルータ（本問であればFW）が該当セグメント側でarp（L2のブロードキャスト）を行う
・これにより別セグメント間（サーバ管理セグメント-サーバセグメント間）の通信がわからなくなる（設問３の１）
↓以下オマケ
そもそも、デフォルトゲートウェイのネットワークに属さないIPアドレスを設定している時点で、他のネットワークへの通信（今回であればsynパケット）は届かないんですけどね…
ただし、スレ主様はarpの動作を理解されていない思われます（見当違いであればごめんなさい）。
【同一セグメントへのarp】
・ルータを経由しない
・自身でarp（L2のブロードキャスト）を行う
【別セグメントへのarp】
・ルータを経由する
・ルータ（本問であればFW）が該当セグメント側でarp（L2のブロードキャスト）を行う
・これにより別セグメント間（サーバ管理セグメント-サーバセグメント間）の通信がわからなくなる（設問３の１）
↓以下オマケ
そもそも、デフォルトゲートウェイのネットワークに属さないIPアドレスを設定している時点で、他のネットワークへの通信（今回であればsynパケット）は届かないんですけどね…
2024.03.27 21:52
pixさん(No.7)
★SC ダイヤモンドマイスター
>暗黙のFWのルーティングというのは、恐らく表5の項番24の事だと思います
>（ciscoだと暗黙のdeny）。
大変恐縮ですが、表5の項番24はルーティングではなく、フィルタリングです。
暗黙のFWのルーティングというのは、このFWにはNICが4つ
（インターネット、サーバセグメント、サーバ管理セグメント、PCセグメント）あり、
そのNICに対するルーティングを指します。
No.4の最後にも書きましたが、
>以前も同様の疑問が議論されたことがあったと記憶します。
>この設問のネットワークの動作については単純そうに見えて、結構ややこしい
>ということになります。
OSや製品によって挙動が異なると思われます。
特にCisco系の機器での考え方と、Linux系OSでのプロトコルスタックでの考え方の
違いで、挙動が異なると思われます。
私の認識ではFWの保持しているステートの状態にもよりますが、SYNは
項番4の行きとして、SYN+ACKは項番4の戻りとしてFWで許可された後、
ルーティングでサーバ管理セグメントに流れたと想定しています。
前提として、このFWのステートはインターフェース情報は保持せず、純粋に
IPアドレスとポート番号のみをステートとして保持している必要があります。
この点については、インフラエンジニアとネットワークエンジニアとで
見解が異なると思われます。
私はLinuxが専門のインフラエンジニアなので、Linuxのプロトコルスタック的に
検討しました。IPアドレス偽装していても、FWのフィルタリングルールはすり抜け
られるが、ネットワーク層のルーティングで矛盾が生じてしまい、別の
ネットワークに流れるという認識です。
ですが、Cisco製品がメインのネットワークエンジニアの方だと、もっと別の
FWの挙動から考察をするかもしれません。特にFWがインターフェースからの
情報も加味している可能性をあげるかもしれません。
このようなさまざまな観点の話が過去にもあり、具体的に最終的な挙動を
確定するのは難しかったと記憶しています。
しかし、FWが単なるルータだったと仮定すれば、IPアドレス偽装をしても
結論としてルーティングで矛盾が生じることは確実なので、これを
解答と認識しております。
2024.03.27 22:27