セキュリティポリシーを最適化します。

69047

Created On 09/26/18 13:44 PM - Last Modified 06/08/23 08:35 AM

Resolution

セキュリティポリシーを構築または確認する際に念頭におくべきいくつかのベストプラクティスについて説明します。これらのヒントは、構成からの最適なエクスペリエンスを確保するために考慮しますが、パロアルトネットワークファイアウォールが正しく機能するために必須でも必須でもありません。これらは、管理者がいくつかのガイドラインに固執することによって防止されている可能性が予期しない問題に直面していたサポートエンジニアとして私の年に見てきた慣行です。

ゾーン

ベストプラクティスに対する一般的な違反は、ソースまたは宛先ゾーンで ' any ' を使用することです。多くの場合、管理者は最初にデフォルトの VWire 構成でファイアウォールをネットワークに接続するときに「any」ルールを設定することから始めます。これにより、トラフィックの各方向に対して2つの別個のルールを作成する必要なく、両方の方向のトラフィックが可能になります。

ゾーン内で ' any ' を使用すると、ポリシーがアカウントに対して更新されていない状態で、後の段階で追加された intrazone トラフィックやゾーンなど、考慮されていないセッションを意図せずに許可する可能性が開きます。追加ゾーン。

ただし、ゾーン間の特定の方向のトラフィックを1つのルールで制御できるようになる少しのトリックがあります。

ポリシーの種類は、ユニバーサルから interzone または intrazone に変更できますが、ポリシー内のすべてのゾーンが、同じゾーンではなく、同じゾーンでのみ、または他のゾーンとのみ通信するように制限されます。

下の図のポリシー2と3は、' type ' 以外のすべての方法で同じです (実際には、他のクローンです) が、ルール #2 が intrazone に設定され、ローカルからローカルへのセッションのみを許可するように、完全に異なる動作をします。、リモートからリモートに、ローカルではなくリモートに、またはリモートからローカルへ。規則 #3 は反対をする;ローカルとローカルの間、またはリモートとリモートの間ではなく、リモートとバイスの間でのみセッションを許可します。この小さな設定を使用する代わりに、恐ろしい ' 任意の ' を簡単にできるようになりますが、まだセキュリティを提供し、見落としを防ぐために適用されます。

2016-05-25 _13-57-33

サービス

PAN-OS 6.0 以降、新しいポリシーを作成するときのサービスの既定の設定は [アプリケーション-既定] に設定されますが、アプリケーションがルールの [アプリケーション] タブにも追加された場合にのみ、既定のアプリケーションポートが適用されます。PAN-OS 7.1 以降では、ポリシーにアプリケーションの既定の設定を適用すると、ポリシーの [アプリケーション] タブにアプリケーションがなくても、既定のアプリケーションポートが使用されます。ただし、サービスが ' any ' に設定されているポリシーを参照するのは、まだかなり一般的です。これも、不要なまたは不必要な接続を許可することで予期しない副作用につながることができます。

パロアルトネットワークファイアウォールによって処理されるすべてのセッションは、少なくとも、セキュリティポリシーを2回通過しています: 最初の SYN パケットが受信されると、ファイアウォールポリシーは、ルールがソースゾーン、ソースサブネット/IP、宛先と一致するかどうかを確認しますゾーン、宛先サブネット/IP、および宛先ポート。web ブラウジングを許可するという意図でルールが作成され、サービスが「any」に設定されている場合、このポリシーはポート21経由の FTP 接続に対してハンドシェイクを許可することになります。このセッションは、セッションがステートテーブルに作成されると、ファイアウォール上のリソースを取るとしている, NAT は、等を適用することができる. このセッションは TCP ハンドシェイクの後にのみブロックされ、アプリ ID が許可されたアプリケーションとしてこれを ' not ' として識別することができました。一方で、不要なリソースは、最初の SYN からブロックされている可能性がセッションに費やされた。

アプリケーション

管理者が許可する必要があるアプリケーションの完全な概要を持っていない可能性があるため、多くの場合、アプリケーションタブは ' any ' として残されます。これは、正確なアプリケーションがまだ知られていないときに、特定のアプリケーション特性に対する寛容なポリシーまたは制限された方針を作成するために行動特性を活用することでも是正できます。

ブロックされた-apps-フィルタは、多くの企業ネットワークで不良と見なすことができる一連の動作を一覧表示するので、管理者は、悪いことができるすべてのアプリケーションを認識していないかもしれませんが、彼はセキュリティポリシーを作成することができますをブロックする望ましくない方法です。毎週のコンテンツ更新プログラムは、新しいアプリケーションまたは更新されたアプリでアプリケーションフィルタを更新するため、administartor がポリシーを更新する必要なく、新しいアプリケーションが自動的に追加されます。

2016-05-25 _13-56-43

許可されたアプリフィルターは、ビジネス関連のアプリケーションに期待される一連の「良い」特性を順番に示しています。

allow1

セキュリティプロファイル

あなたは脅威の予防や山火事のサブスクリプションを持っていない場合, セキュリティプロファイルは、パロアルトのファイアウォールを真に次の世代を作るように、これらの製品への投資を検討してください (並列処理アーキテクチャのための脅威/ウイルスをはるかにスキャン従来のファイアウォール製品と比較して、追加のスキャンモジュールを使用する場合と比べて、スループットに対する影響が少ない。セキュリティプロファイルの詳細については、ベストを最大限に取得する方法が表示されます。

プリロードされた既定のセキュリティプロファイルは非常に短時間でシステムをセットアップするのに役立ちますが、すべての管理者が新しいセキュリティポリシーを作成することをお勧めします。

新しいプロファイルの作成にはいくつかの利点がありますが、一部の機能はカスタムプロファイルでのみ有効にできるため、フォレンジック分析を可能にする脆弱性に対してパケットキャプチャを有効にすることができます。dns の陥没は、ホスト名に関連付けられている dns IP アドレスを変更することによって悪意のある発信接続を防止するアンチスパイウェアで有効にすることができます, だけでなく、接続を防止するだけでなく、感染/不審なホストを簡単に追跡すること管理者。

より厳格なポリシーは、すべての種類の脅威をブロックするように有効にすることができますし、より多くのログは、url フィルタリングのために設定することができます (デフォルトの url フィルタリングは、例えば閲覧セッションを許可ログに記録しません)。

私は以下の例のプロファイルのカップルを強調表示されます:

カスタムウイルス対策プロファイルを使用すると、管理者はパケットキャプチャを有効にすることができ、また、野火が有効になっています (デフォルトのプロファイルには山火事の設定は含まれません)。

カスタムアンチスパイウェアプロファイルは、管理者がスパイウェアを送信するホストのためのより積極的なアプローチを設定することができます。これは、DNS 設定を構成することもできます: 陥没は、悪意のあるドメインは、C&C 通信や悪質なペイロードのダウンロードを防止するモック IP アドレスで毒されていることを確認します。

さらに、感染したクライアントを容易に追跡することもできます。悪意のある dns クエリが内部 dns サーバーから発生する可能性があるため、C&C 接続は元のリクエスタ (感染ホスト) から発信されます。

外部の動的ブロックリストがある場合は、これらをプロファイルに追加して、陥没または別のアクションに設定することもできます。

as .jpg