<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>公共市場向け情報の記事次世代ファイアウォールの最大同時セッション数についての考察</title>
    <link>https://live.paloaltonetworks.com/t5/%E5%85%AC%E5%85%B1%E5%B8%82%E5%A0%B4%E5%90%91%E3%81%91%E6%83%85%E5%A0%B1/%E6%AC%A1%E4%B8%96%E4%BB%A3%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%E3%82%A6%E3%82%A9%E3%83%BC%E3%83%AB%E3%81%AE%E6%9C%80%E5%A4%A7%E5%90%8C%E6%99%82%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E6%95%B0%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E8%80%83%E5%AF%9F/ta-p/582565</link>
    <description>&lt;DIV class="lia-message-template-content-zone"&gt;
&lt;P&gt;　皆さんもよくご存じの通り市場で販売されている次世代ファイアウォール製品はほぼすべてがステートフルファイアウォールであり、TCP/UDPのセッションを識別し、内部でセッションテーブルが管理され、生成されたセッションの戻りパケットを自動的に通過させる仕組みで動作します。そのため、次世代ファイアウォールの製品選定するときに必ず確認すべきは「同時最大セッション数」です。同時最大セッション数とは、セッションテーブルの大きさであり、同時に処理できる最大セッション数であり、同時最大セッション数を超えると通信が不安定になったり、通信不可になることもあります。なので、最大同時セッション数は重要なのです。&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;　では、このセッションテーブルの管理はどのようにされているか皆さんご存じでしょうか？&lt;/P&gt;
&lt;P&gt;TCPやUDP、さらにICMPなどの通信で許可されている新しいセッションのパケットが最初に流れると、セッションテーブルに新しいエントリが生成されます。生成されてばかりだと、いつかセッションテーブルが一杯になりますが、これらのエントリは、そのセッションが継続している間は保持されますが、セッションが終了した場合に削除されます。そうしてセッションテーブルは管理されています。&lt;/P&gt;
&lt;P&gt;　ここで重要なのは、各セッションがどれぐらい保持されるかです。TCPの場合、TCPのメッセージの中でセッションを終了するためのFIN-CLOSEという手順があり、TCPセッションの終了が次世代ファイアウォールでも検知でき、FIN-CLOSEにてセッションテーブルからセッションを破棄できます。しかし、TCP通信でも昨今はWiFi環境での利用が増え、またWebブラウザを終了するなどの操作で、FIN-CLOSEしないTCPセッションがかなり発生します。それらのTCPセッションはセッションタイマー制御で通信がなくなってからタイムアウトするまで保持されます。一般的にTCPのセッションタイマーは3,600秒です。つまり実際の通信では例えば30秒しか使わないセッションだったとしても、FIN-CLOSEされなければ不要なTCPセッションは3,600秒保持されてしまいます。&lt;/P&gt;
&lt;P&gt;　また、UDPの場合、TCPと違いプロトコル的に通信を終了するという手順がありません。従いまして、UDPはすべてセッションタイムアウトでエントリが破棄されます。一般的にUDPのセッションタイマーは180秒や300秒ぐらいが多いです。つまり、例えばDNSによる名前解決で数秒程度の通信が行われても、そのセッションエントリは180秒や300秒ほど保持されます。&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;　ここまで読んで、既にお気づきの方もおられると思いますが、セッションテーブルにて保持されるセッションエントリでは、FIN-CLOSEされないTCPセッションや、UDPセッションの多くは既に不要になっているものが多く含まれるということです。昨今のクラウド利用で次世代ファイアウォールを通過するセッション数が増加するので、最大同時セッション数の多い上位機種の製品が必要と思われているケースもあると思いますが、実はこれらの不要なセッションのために同時セッション数が増加し、悩まれている可能性があります。&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;　この不要なセッションエントリを減らすために工夫がパロアルトネットワークスの次世代ファイアウォールでは実装されています。具体的な実装としては以下の2つです。&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;&lt;STRONG&gt;アプリケーション単位でのセッションタイマー&lt;/STRONG&gt;&lt;BR /&gt;パロアルトネットワークス次世代ファイアウォールでもTCPのセッションタイマーは3,600秒です。しかし、パロアルトネットワークスの次世代ファイアウォールはデフォルト設定のままでも通過するすべての通信のアプリケーション識別が行われ、実は識別されたアプリケーション毎にセッションタイマーが定義されています。例えば以下です。&lt;BR /&gt;　- google-base: TCP/60秒&lt;BR /&gt;　- youtube-base: TCP/60秒&lt;BR /&gt;　- instagram-base: TCP/60秒&lt;BR /&gt;　- facebook-base: TCP/60秒、UDP/30秒&lt;BR /&gt;　- zoom-base: TCP/60秒、UDP/300秒&lt;BR /&gt;　- ms-onedrive-base: TCP/60秒&lt;BR /&gt;　- gmail-base: TCP/1800秒&lt;BR /&gt;つまり、単純にTCPセッションとしてセッション管理されるわけではなく、各アプリケーションの通信特性を考慮し、無駄にセッションが保持されないようになっています。尚、アプリケーション毎のセッションタイマーの設定がないものやアプリケーション識別できないTCP通信については、TCPセッションのセッションタイムアウトである3,600秒が経過してからセッションテーブルが破棄されます。&lt;BR /&gt;&lt;BR /&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;SPAN&gt;&lt;STRONG&gt;セッション保持時間短縮(Accelerated Aging)機能&lt;/STRONG&gt;&lt;BR /&gt;パロアルトネットワークス次世代ファイアウォールでは、デフォルト設定でセッションテーブルの利用率が80％を超えた場合、このセッション保持時間短縮機能が自動的に動作し、セッションタイマーを半分にすることで、不要となっているセッションエントリを破棄する動作を行います。上述したようにTCPセッションでアイドルタイマーが1,800秒を超えているTCPセッションのほとんどが不要なセッションです。セッション保持時間短縮機能が動作した場合、TCPセッションタイムアウトは3,600秒から1,800秒に短縮されます。すると、アイドル時間が1,800秒を超えているセッションは破棄され、セッションテーブルの利用率を抑制します。この制御で不要であるセッションエントリを破棄することで、セッションテーブルが満杯になり、新規セッションエントリができなくなり通信が不安定になることを防いでいます。&lt;/SPAN&gt;&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;　他社ファイアウォールからパロアルトネットワークスの次世代ファイアウォールへ変更する場合や、他社次世代ファイアウォールと比較検討されるときに、最大同時セッション数の比較は行われますが、パロアルトネットワークス次世代ファイアウォールでは上述したようなセッションテーブルリソースを最適に利用する機能があることで、同じネットワーク環境でもセッションテーブルの消費が他社とは異なり低く抑えられます。過去に実環境での実測した結果では半分程度のセッション数になったという結果もあります。&lt;/P&gt;
&lt;P&gt;　他社製品で安価で最大同時セッション数が多いことをアピールしている製品もありますが、逆に無駄なリソースを消費しているだけとも言えますので、本当に必要なリソースがどれぐらいであるかを見極め、また、他社ファイアウォールでの同時セッション数とパロアルトネットワークスの場合の同時セッション数が異なるということをご理解いただき、適切なモデル選定をしていただければと思います。&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;　尚、パロアルトネットワークス次世代ファイアウォールでの、同時セッション数は、リアルタイムであればGUIやCLIにて確認ができますが、過去の傾向についてはPAシリーズ本体では確認できません。過去の同時セッション数を確認する方法としては、以下の方法があります。&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;Panorama&lt;BR /&gt;Panoramaを利用してPAシリーズを管理することで、PanoramaのDevice Health機能にて過去90日までのセッション数の推移が確認できます。&lt;BR /&gt;&lt;A href="https://docs.paloaltonetworks.com/panorama/10-2/panorama-admin/manage-firewalls/device-monitoring-on-panorama/monitor-device-health" target="_blank"&gt;https://docs.paloaltonetworks.com/panorama/10-2/panorama-admin/manage-firewalls/device-monitoring-on-panorama/monitor-device-health&lt;/A&gt;&lt;/LI&gt;
&lt;LI&gt;AIOps&lt;BR /&gt;PAシリーズのテレメトリ機能を有効にしていただき、AIOpsにてPAシリーズの情報の管理が可能です。&lt;BR /&gt;AIOps機能にて過去90日のセッション数の推移やセッション数に対するしきい値ベースのアラート設定ができます。&lt;BR /&gt;&lt;A href="https://docs.paloaltonetworks.com/ngfw/incidents-and-alerts/alerts/what-is-an-alert" target="_blank"&gt;https://docs.paloaltonetworks.com/ngfw/incidents-and-alerts/alerts/what-is-an-alert&lt;/A&gt;&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;今後の次世代ファイアウォールの検討時に参考になれば幸いです。&lt;/P&gt;
&lt;/DIV&gt;</description>
    <pubDate>Thu, 04 Apr 2024 04:01:10 GMT</pubDate>
    <dc:creator>khayakawa</dc:creator>
    <dc:date>2024-04-04T04:01:10Z</dc:date>
    <item>
      <title>次世代ファイアウォールの最大同時セッション数についての考察</title>
      <link>https://live.paloaltonetworks.com/t5/%E5%85%AC%E5%85%B1%E5%B8%82%E5%A0%B4%E5%90%91%E3%81%91%E6%83%85%E5%A0%B1/%E6%AC%A1%E4%B8%96%E4%BB%A3%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%E3%82%A6%E3%82%A9%E3%83%BC%E3%83%AB%E3%81%AE%E6%9C%80%E5%A4%A7%E5%90%8C%E6%99%82%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E6%95%B0%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E8%80%83%E5%AF%9F/ta-p/582565</link>
      <description>&lt;DIV class="lia-message-template-content-zone"&gt;
&lt;P&gt;　皆さんもよくご存じの通り市場で販売されている次世代ファイアウォール製品はほぼすべてがステートフルファイアウォールであり、TCP/UDPのセッションを識別し、内部でセッションテーブルが管理され、生成されたセッションの戻りパケットを自動的に通過させる仕組みで動作します。そのため、次世代ファイアウォールの製品選定するときに必ず確認すべきは「同時最大セッション数」です。同時最大セッション数とは、セッションテーブルの大きさであり、同時に処理できる最大セッション数であり、同時最大セッション数を超えると通信が不安定になったり、通信不可になることもあります。なので、最大同時セッション数は重要なのです。&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;　では、このセッションテーブルの管理はどのようにされているか皆さんご存じでしょうか？&lt;/P&gt;
&lt;P&gt;TCPやUDP、さらにICMPなどの通信で許可されている新しいセッションのパケットが最初に流れると、セッションテーブルに新しいエントリが生成されます。生成されてばかりだと、いつかセッションテーブルが一杯になりますが、これらのエントリは、そのセッションが継続している間は保持されますが、セッションが終了した場合に削除されます。そうしてセッションテーブルは管理されています。&lt;/P&gt;
&lt;P&gt;　ここで重要なのは、各セッションがどれぐらい保持されるかです。TCPの場合、TCPのメッセージの中でセッションを終了するためのFIN-CLOSEという手順があり、TCPセッションの終了が次世代ファイアウォールでも検知でき、FIN-CLOSEにてセッションテーブルからセッションを破棄できます。しかし、TCP通信でも昨今はWiFi環境での利用が増え、またWebブラウザを終了するなどの操作で、FIN-CLOSEしないTCPセッションがかなり発生します。それらのTCPセッションはセッションタイマー制御で通信がなくなってからタイムアウトするまで保持されます。一般的にTCPのセッションタイマーは3,600秒です。つまり実際の通信では例えば30秒しか使わないセッションだったとしても、FIN-CLOSEされなければ不要なTCPセッションは3,600秒保持されてしまいます。&lt;/P&gt;
&lt;P&gt;　また、UDPの場合、TCPと違いプロトコル的に通信を終了するという手順がありません。従いまして、UDPはすべてセッションタイムアウトでエントリが破棄されます。一般的にUDPのセッションタイマーは180秒や300秒ぐらいが多いです。つまり、例えばDNSによる名前解決で数秒程度の通信が行われても、そのセッションエントリは180秒や300秒ほど保持されます。&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;　ここまで読んで、既にお気づきの方もおられると思いますが、セッションテーブルにて保持されるセッションエントリでは、FIN-CLOSEされないTCPセッションや、UDPセッションの多くは既に不要になっているものが多く含まれるということです。昨今のクラウド利用で次世代ファイアウォールを通過するセッション数が増加するので、最大同時セッション数の多い上位機種の製品が必要と思われているケースもあると思いますが、実はこれらの不要なセッションのために同時セッション数が増加し、悩まれている可能性があります。&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;　この不要なセッションエントリを減らすために工夫がパロアルトネットワークスの次世代ファイアウォールでは実装されています。具体的な実装としては以下の2つです。&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;&lt;STRONG&gt;アプリケーション単位でのセッションタイマー&lt;/STRONG&gt;&lt;BR /&gt;パロアルトネットワークス次世代ファイアウォールでもTCPのセッションタイマーは3,600秒です。しかし、パロアルトネットワークスの次世代ファイアウォールはデフォルト設定のままでも通過するすべての通信のアプリケーション識別が行われ、実は識別されたアプリケーション毎にセッションタイマーが定義されています。例えば以下です。&lt;BR /&gt;　- google-base: TCP/60秒&lt;BR /&gt;　- youtube-base: TCP/60秒&lt;BR /&gt;　- instagram-base: TCP/60秒&lt;BR /&gt;　- facebook-base: TCP/60秒、UDP/30秒&lt;BR /&gt;　- zoom-base: TCP/60秒、UDP/300秒&lt;BR /&gt;　- ms-onedrive-base: TCP/60秒&lt;BR /&gt;　- gmail-base: TCP/1800秒&lt;BR /&gt;つまり、単純にTCPセッションとしてセッション管理されるわけではなく、各アプリケーションの通信特性を考慮し、無駄にセッションが保持されないようになっています。尚、アプリケーション毎のセッションタイマーの設定がないものやアプリケーション識別できないTCP通信については、TCPセッションのセッションタイムアウトである3,600秒が経過してからセッションテーブルが破棄されます。&lt;BR /&gt;&lt;BR /&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;SPAN&gt;&lt;STRONG&gt;セッション保持時間短縮(Accelerated Aging)機能&lt;/STRONG&gt;&lt;BR /&gt;パロアルトネットワークス次世代ファイアウォールでは、デフォルト設定でセッションテーブルの利用率が80％を超えた場合、このセッション保持時間短縮機能が自動的に動作し、セッションタイマーを半分にすることで、不要となっているセッションエントリを破棄する動作を行います。上述したようにTCPセッションでアイドルタイマーが1,800秒を超えているTCPセッションのほとんどが不要なセッションです。セッション保持時間短縮機能が動作した場合、TCPセッションタイムアウトは3,600秒から1,800秒に短縮されます。すると、アイドル時間が1,800秒を超えているセッションは破棄され、セッションテーブルの利用率を抑制します。この制御で不要であるセッションエントリを破棄することで、セッションテーブルが満杯になり、新規セッションエントリができなくなり通信が不安定になることを防いでいます。&lt;/SPAN&gt;&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;　他社ファイアウォールからパロアルトネットワークスの次世代ファイアウォールへ変更する場合や、他社次世代ファイアウォールと比較検討されるときに、最大同時セッション数の比較は行われますが、パロアルトネットワークス次世代ファイアウォールでは上述したようなセッションテーブルリソースを最適に利用する機能があることで、同じネットワーク環境でもセッションテーブルの消費が他社とは異なり低く抑えられます。過去に実環境での実測した結果では半分程度のセッション数になったという結果もあります。&lt;/P&gt;
&lt;P&gt;　他社製品で安価で最大同時セッション数が多いことをアピールしている製品もありますが、逆に無駄なリソースを消費しているだけとも言えますので、本当に必要なリソースがどれぐらいであるかを見極め、また、他社ファイアウォールでの同時セッション数とパロアルトネットワークスの場合の同時セッション数が異なるということをご理解いただき、適切なモデル選定をしていただければと思います。&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;　尚、パロアルトネットワークス次世代ファイアウォールでの、同時セッション数は、リアルタイムであればGUIやCLIにて確認ができますが、過去の傾向についてはPAシリーズ本体では確認できません。過去の同時セッション数を確認する方法としては、以下の方法があります。&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;Panorama&lt;BR /&gt;Panoramaを利用してPAシリーズを管理することで、PanoramaのDevice Health機能にて過去90日までのセッション数の推移が確認できます。&lt;BR /&gt;&lt;A href="https://docs.paloaltonetworks.com/panorama/10-2/panorama-admin/manage-firewalls/device-monitoring-on-panorama/monitor-device-health" target="_blank"&gt;https://docs.paloaltonetworks.com/panorama/10-2/panorama-admin/manage-firewalls/device-monitoring-on-panorama/monitor-device-health&lt;/A&gt;&lt;/LI&gt;
&lt;LI&gt;AIOps&lt;BR /&gt;PAシリーズのテレメトリ機能を有効にしていただき、AIOpsにてPAシリーズの情報の管理が可能です。&lt;BR /&gt;AIOps機能にて過去90日のセッション数の推移やセッション数に対するしきい値ベースのアラート設定ができます。&lt;BR /&gt;&lt;A href="https://docs.paloaltonetworks.com/ngfw/incidents-and-alerts/alerts/what-is-an-alert" target="_blank"&gt;https://docs.paloaltonetworks.com/ngfw/incidents-and-alerts/alerts/what-is-an-alert&lt;/A&gt;&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;今後の次世代ファイアウォールの検討時に参考になれば幸いです。&lt;/P&gt;
&lt;/DIV&gt;</description>
      <pubDate>Thu, 04 Apr 2024 04:01:10 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/%E5%85%AC%E5%85%B1%E5%B8%82%E5%A0%B4%E5%90%91%E3%81%91%E6%83%85%E5%A0%B1/%E6%AC%A1%E4%B8%96%E4%BB%A3%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%E3%82%A6%E3%82%A9%E3%83%BC%E3%83%AB%E3%81%AE%E6%9C%80%E5%A4%A7%E5%90%8C%E6%99%82%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E6%95%B0%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E8%80%83%E5%AF%9F/ta-p/582565</guid>
      <dc:creator>khayakawa</dc:creator>
      <dc:date>2024-04-04T04:01:10Z</dc:date>
    </item>
  </channel>
</rss>

