Netscreen Screen OS6.2での不可思議な現象が、立て続けに発生したので、記載します。
因みに、2週間程度の解析時間は掛かりましたが、すべて、解決済です。
現象１） Routing Tableが記載されていないのに、PINGが通る！
１．１） DMZ側の管理サーバから、LAN側（Trust側）に設置済のサーバAに対して、PINGを打つと、戻ってくる。
１．２） しかしながら、LAN側のサーバAから、DMZ側の管理サーバにPINGを打っても、NO Replyとなる。
１．２）の現象は、単に、Netscreen上のRouting Tableに、DMZ側向けのRouting Tableが抜けていた為に発生。 従って、Routing tableを追加することで、問題解消。
しかしながら、なぜ、Routing tableがない状態で、１．１）が可能であったのか？？？
散々、Webで探したし、もちろん、Netscreenのあの分厚いManualも一通り、再度、目を通した結果、下記のブログに全く同じ現象があった。→ 世にも奇妙な物語
このブログによれば、「"応答パケットは、ルーティングテーブルに関係なく、要求パケットを送ってきた機器(のMACアドレス)に対して返される"」と言うことらしい。
残念ながら、Netscreen 公式Manual上での裏は取れなかったが、別環境で、意図的に、Routing Tableを記載せずに同じ様なテストをしたが、上記の動きは、確かにNetscreenのデフォルト機能らしい。 従って、完璧にではないけれども、問題解決＆悩み解消！
*****************************************
(3/25 追記)
本機能のManualでの裏が取れました！
set flow reverse-route clear-text prefer と言うコマンドが、Screen OS6.2から導入されているとの事。
要は、ルート冗長化等をする際等に、必要なMac chcheをReferする機能との事。
Defaultでは、「戻りPacketの通信経路は、Routing Tableを最初にReferするが、Routing Tableでの通信経路では、syn パケット／syn-ack パケット通信制限が掛かり、通信できない様な際は、MacアドレスをReferする様にする。」と言う設定になっている。
勿論、CLIベースで、この機能を無効に出来ることも可能との事です。
詳細はここ→ http://kb.juniper.net/InfoCenter/index?page=content&id=KB14429
************************************
２） Non-SYN Flags
文字で説明するのが、とても難しいのであるが、Screen OS5.0では、問題のなかったセグメントAから、セグメントBへのTCPベースのアクセスが突然、Screen OS6.2では不可となった。
理解不能なのは、ICMPやUDPベースの通信は、全く問題なかった点。
これは、Ncreen OSのVersion 5.1から適用されるようになった、Non-SYN Flagと言う機能によるものと確定した。
下記ManualのP17に記載されております。
http://www.juniper.net/techpubs/software/screenos/screenos6.2.0/ce_v4.pdf
(以下、引用）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Non-SYN Flags
By default, the security device checks for SYN flags in the first packet of a session and rejects any TCP segments with non-SYN flags attempting to initiate a session.
You can leave this packet flow as is or change it to so that the device does not enforce SYN flag checking before creating a session. Figure 9 on page 18 illustrates
packet flow sequences when SYN flag checking is enabled and when it is disabled.
NOTE: Changing the packet flow to check that the SYN flag is set for packets that do not belong to existing sessions also thwarts other types of non-SYN scans, such as a
null scan (when no TCP flags are set).
NOTE: By default, checking for the TCP SYN flag in the initial packet of a session is enabled when you install a Juniper Networks security device running ScreenOS
5.1.0 or higher. If you upgrade from a release prior to ScreenOS 5.1.0, SYN checking remains disabled by default—unless you have previously changed the
default behavior. These packet flows are the same whether the ingress interface is operating at Layer 3 (route or NAT mode) or at Layer 2 (transparent mode).
=====================================================================
要は、「SYS Flagでの接続が、最初に無いまま、発行されるACK Packetは、Dropされる。」と言うこと。 言われてみると、当たり前のSecurity機能ですね。
クリアですね。
解決策としては、ScreenOS 5.1.0以上では、Defaultで、enableとなっているとのことなので、コマンドレベルで、Disableにするだけですね。
ただし、Interface毎に、Enableにしたり、Disableすることはできないとの事。あくまでも、System Wideな設定との事。
(下記のコマンドを叩けば、Disableにできるとの事。）
=============================================================
You can enable and disable SYN checking with the following CLI commands:
set flow tcp-syn-check
unset flow tcp-syn-check
==========================================================
3) NATが機能しない。
NetscreenのNATモードに対して、理解が甘かった事を反省する。
【判明した点】
3.1) Netscreen FW Untrust Interface では、NATモードに設定しても意味はない。
（Netscreen Manual Concept & Example Fundamental P102)
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Untrust: Although you are able to select NAT as
the interface mode on an interface bound to the
Untrust zone, the security device does not
perform any NAT operations on that interface.
==========================================
3.2) Untrust Interfaceを、DMZ Interfaceへと変更しても、NATモードは動かなかった。
つまり、Untrust Interfaceだけが、NATモードが動作しない訳ではなく、DestがTrustであるならば、NATモードが動かないのかもしれない。
3.3） DMZ側でも、Untrust側からのTrafficでも、アドレス変換をしたいのならば、DIP（Dynamic IP）モードを使うしかない。DIPとは、Source Address Translationを実現する機能の一つで、これを使用する事で、Untrust側やDMZ側からのSource Addressを変換する事ができた。
Source Address Translationの詳細は、下記資料。
Page 17 → http://www.juniper.net/techpubs/software/screenos/screenos5.1.0/CE_v7.pdf
Page 73 → http://www.juniper.net/jp/jp/local/pdf/others/fsssg5-jp.pdf
【所感】
個人的には、3.1）のNetscreenの仕様に気が付くのに、一番時間がかかった。
Netscreenもそれなりに、癖があるという事ですねえ。（笑）
貴公子が知らないのは、兎も角、Netscreenの専業ベンダーが知らなかったのには、怒りですね。
結局、今回も、専門ベンダー（SI）が解決できない問題を、貴公子が解決したことになりますなあ。
因みに、2週間程度の解析時間は掛かりましたが、すべて、解決済です。
現象１） Routing Tableが記載されていないのに、PINGが通る！
１．１） DMZ側の管理サーバから、LAN側（Trust側）に設置済のサーバAに対して、PINGを打つと、戻ってくる。
１．２） しかしながら、LAN側のサーバAから、DMZ側の管理サーバにPINGを打っても、NO Replyとなる。
１．２）の現象は、単に、Netscreen上のRouting Tableに、DMZ側向けのRouting Tableが抜けていた為に発生。 従って、Routing tableを追加することで、問題解消。
しかしながら、なぜ、Routing tableがない状態で、１．１）が可能であったのか？？？
散々、Webで探したし、もちろん、Netscreenのあの分厚いManualも一通り、再度、目を通した結果、下記のブログに全く同じ現象があった。→ 世にも奇妙な物語
このブログによれば、「"応答パケットは、ルーティングテーブルに関係なく、要求パケットを送ってきた機器(のMACアドレス)に対して返される"」と言うことらしい。
残念ながら、Netscreen 公式Manual上での裏は取れなかったが、別環境で、意図的に、Routing Tableを記載せずに同じ様なテストをしたが、上記の動きは、確かにNetscreenのデフォルト機能らしい。 従って、完璧にではないけれども、問題解決＆悩み解消！
*****************************************
(3/25 追記)
本機能のManualでの裏が取れました！
set flow reverse-route clear-text prefer と言うコマンドが、Screen OS6.2から導入されているとの事。
要は、ルート冗長化等をする際等に、必要なMac chcheをReferする機能との事。
Defaultでは、「戻りPacketの通信経路は、Routing Tableを最初にReferするが、Routing Tableでの通信経路では、syn パケット／syn-ack パケット通信制限が掛かり、通信できない様な際は、MacアドレスをReferする様にする。」と言う設定になっている。
勿論、CLIベースで、この機能を無効に出来ることも可能との事です。
詳細はここ→ http://kb.juniper.net/InfoCenter/index?page=content&id=KB14429
************************************
２） Non-SYN Flags
文字で説明するのが、とても難しいのであるが、Screen OS5.0では、問題のなかったセグメントAから、セグメントBへのTCPベースのアクセスが突然、Screen OS6.2では不可となった。
理解不能なのは、ICMPやUDPベースの通信は、全く問題なかった点。
これは、Ncreen OSのVersion 5.1から適用されるようになった、Non-SYN Flagと言う機能によるものと確定した。
下記ManualのP17に記載されております。
http://www.juniper.net/techpubs/software/screenos/screenos6.2.0/ce_v4.pdf
(以下、引用）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Non-SYN Flags
By default, the security device checks for SYN flags in the first packet of a session and rejects any TCP segments with non-SYN flags attempting to initiate a session.
You can leave this packet flow as is or change it to so that the device does not enforce SYN flag checking before creating a session. Figure 9 on page 18 illustrates
packet flow sequences when SYN flag checking is enabled and when it is disabled.
NOTE: Changing the packet flow to check that the SYN flag is set for packets that do not belong to existing sessions also thwarts other types of non-SYN scans, such as a
null scan (when no TCP flags are set).
NOTE: By default, checking for the TCP SYN flag in the initial packet of a session is enabled when you install a Juniper Networks security device running ScreenOS
5.1.0 or higher. If you upgrade from a release prior to ScreenOS 5.1.0, SYN checking remains disabled by default—unless you have previously changed the
default behavior. These packet flows are the same whether the ingress interface is operating at Layer 3 (route or NAT mode) or at Layer 2 (transparent mode).
=====================================================================
要は、「SYS Flagでの接続が、最初に無いまま、発行されるACK Packetは、Dropされる。」と言うこと。 言われてみると、当たり前のSecurity機能ですね。
クリアですね。
解決策としては、ScreenOS 5.1.0以上では、Defaultで、enableとなっているとのことなので、コマンドレベルで、Disableにするだけですね。
ただし、Interface毎に、Enableにしたり、Disableすることはできないとの事。あくまでも、System Wideな設定との事。
(下記のコマンドを叩けば、Disableにできるとの事。）
=============================================================
You can enable and disable SYN checking with the following CLI commands:
set flow tcp-syn-check
unset flow tcp-syn-check
==========================================================
3) NATが機能しない。
NetscreenのNATモードに対して、理解が甘かった事を反省する。
【判明した点】
3.1) Netscreen FW Untrust Interface では、NATモードに設定しても意味はない。
（Netscreen Manual Concept & Example Fundamental P102)
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Untrust: Although you are able to select NAT as
the interface mode on an interface bound to the
Untrust zone, the security device does not
perform any NAT operations on that interface.
==========================================
3.2) Untrust Interfaceを、DMZ Interfaceへと変更しても、NATモードは動かなかった。
つまり、Untrust Interfaceだけが、NATモードが動作しない訳ではなく、DestがTrustであるならば、NATモードが動かないのかもしれない。
3.3） DMZ側でも、Untrust側からのTrafficでも、アドレス変換をしたいのならば、DIP（Dynamic IP）モードを使うしかない。DIPとは、Source Address Translationを実現する機能の一つで、これを使用する事で、Untrust側やDMZ側からのSource Addressを変換する事ができた。
Source Address Translationの詳細は、下記資料。
Page 17 → http://www.juniper.net/techpubs/software/screenos/screenos5.1.0/CE_v7.pdf
Page 73 → http://www.juniper.net/jp/jp/local/pdf/others/fsssg5-jp.pdf
【所感】
個人的には、3.1）のNetscreenの仕様に気が付くのに、一番時間がかかった。
Netscreenもそれなりに、癖があるという事ですねえ。（笑）
貴公子が知らないのは、兎も角、Netscreenの専業ベンダーが知らなかったのには、怒りですね。
結局、今回も、専門ベンダー（SI）が解決できない問題を、貴公子が解決したことになりますなあ。
0 件のコメント:
コメントを投稿