チェックポイント: CPUとRAMの最適化

こんにちは、同僚です！ 今日は、多くの Check Point 管理者にとって非常に関連性の高いトピックである「CPU と RAM の最適化」について説明したいと思います。 ゲートウェイや管理サーバーが予想外に多くのリソースを消費することは珍しいことではなく、どこでリソースが「漏洩」しているかを理解し、可能であればそれらをより適切に使用したいと考えています。

1.分析

プロセッサーの負荷を分析するには、エキスパート モードで入力する次のコマンドを使用すると便利です。

top すべてのプロセス、消費された CPU および RAM リソースの量 (パーセント)、稼働時間、プロセスの優先度、および その他 リアルタイムでи

cpwd_admin リスト Check Point WatchDog デーモン。すべてのアプリケーション モジュール、その PID、ステータス、実行数を表示します。

cpstat -f CPU OS CPU 使用率、その数、およびプロセッサ時間の分布 (パーセント)

cpstat -f メモリ OS 仮想 RAM の使用量、アクティブな RAM の量、空き RAM など

正しい指摘は、すべての cpstat コマンドはユーティリティを使用して表示できるということです。 cpview。 これを行うには、SSH セッションの任意のモードから cpview コマンドを入力するだけです。

ps auxwf すべてのプロセス、その ID、占有仮想メモリと RAM、CPU 内のメモリの長いリスト

コマンドの別のバリエーション:

ps-aF 最も高価なプロセスを表示する

fw ctl アフィニティ -l -a ファイアウォールのさまざまなインスタンスに対するコアの分散、つまり CoreXL テクノロジー

FW CTL PSTAT RAM 分析と接続、Cookie、NAT の一般的なインジケーター

フリー-m RAMバッファ

このチームは特別な注目に値する。 ネットサット とそのバリエーション。 例えば、 netstat -i クリップボードの監視の問題の解決に役立ちます。 このコマンドの出力にあるパラメータ RX ドロップ パケット (RX-DRP) は、不正なプロトコル ドロップ (IPv6、不正な / 意図しない VLAN タグなど) により自動的に増加する傾向があります。 ただし、別の理由でドロップが発生した場合は、これを使用する必要があります 論文このネットワーク インターフェイスがパケットをドロップしている理由の調査を開始します。 原因がわかれば、アプリラインの動作を最適化することもできます。

[監視] ブレードが有効になっている場合、オブジェクトをクリックして [デバイスとライセンス情報] を選択すると、SmartConsole でこれらのメトリックをグラフィカルに表示できます。

監視ブレードを継続的に有効にすることはお勧めできませんが、テストのために XNUMX 日程度有効にすることは十分に可能です。

さらに、監視用のパラメータをさらに追加できます。そのうちの XNUMX つであるバイト スループット (アプリケーションの帯域幅) は非常に便利です。

他に無料の監視システムがある場合は、 ザビックスは SNMP に基づいているため、これらの問題を特定するのにも適しています。

2. 時間の経過とともに RAM が「リーク」する

多くの場合、時間の経過とともに、ゲートウェイまたは管理サーバーが RAM を消費し始めるのではないかという疑問が生じます。 安心していただきたいのですが、これは Linux のようなシステムでは通常の話です。

コマンド出力を見てみると フリー-m и cpstat -f メモリ OS エキスパート モードからアプリラインで、RAM に関連するすべてのパラメーターを計算して表示できます。

現時点でゲートウェイ上で利用可能なメモリに基づく 空きメモリ + バッファメモリ + キャッシュされたメモリ = ±1.5GB、 いつもの。

SR が言うように、時間の経過とともに、ゲートウェイ/管理サーバーは最適化され、メモリの使用量が増加し、最大約 80% の使用率に達して停止します。 デバイスを再起動すると、インジケーターがリセットされます。 ゲートウェイがすべてのタスクを実行するには、1.5 GB の空き RAM があれば間違いなく十分であり、管理がそのようなしきい値に達することはほとんどありません。

また、前述のコマンドの出力には、どれだけの量があるかが表示されます。 低メモリ (ユーザー空間のRAM)および ハイメモリ (カーネル空間の RAM) が使用されます。

カーネル プロセス (Check Point カーネル モジュールなどのアクティブなモジュールを含む) は、低メモリのみを使用します。 ただし、ユーザー プロセスは低メモリと高メモリの両方を使用できます。 さらに、Low メモリは次とほぼ同じです。 合計メモリ.

ログにエラーがある場合のみ心配する必要があります。 「OOM (メモリ不足) のため、モジュールが再起動するか、メモリを再利用するためにプロセスが強制終了されます。」。 次に、ゲートウェイを再起動し、再起動しても問題が解決しない場合はサポートに連絡する必要があります。

完全な説明は次の場所にあります。 sk99547 и sk99593.

3. 最適化

以下は、CPU と RAM の最適化に関する質問と回答です。 自分自身に対して正直に答え、推奨事項に耳を傾ける必要があります。

3.1. アップラインは正しく選択されましたか? パイロットプロジェクトはありましたか？

適切なサイジングにもかかわらず、ネットワークが単純に拡大する可能性があり、この機器では負荷に対処できなくなります。 XNUMX 番目のオプションは、そのようなサイズ設定がなかった場合です。

3.2. HTTPS検査は有効になっていますか? そうである場合、テクノロジーはベスト プラクティスに従って構成されていますか?

参照する 記事あなたが当社のクライアントである場合、または sk108202.

HTTPS 検査ポリシー内のルールの順序は、HTTPS サイトの開設を最適化する上で非常に重要です。

ルールの推奨順序:

1. カテゴリ/URL によるバイパス ルール
2. カテゴリ/URL を使用してルールを検査する
3. 他のすべてのカテゴリのルールを検査する

ファイアウォール ポリシーと同様に、Check Point はパケットの一致を上から下まで検索するため、このパケットをスキップする必要がある場合にゲートウェイがすべてのルールを実行する際にリソースを無駄にしないため、バイパス ルールを先頭に配置するのが最適です。

3.3 アドレス範囲オブジェクトは使用されていますか?

ネットワーク 192.168.0.0 ～ 192.168.5.0 などのアドレス範囲を持つオブジェクトは、5 つのネットワーク オブジェクトよりも大幅に多くの RAM を消費します。 一般に、SmartConsole で未使用のオブジェクトを削除することをお勧めします。これは、ポリシーが設定されるたびに、ゲートウェイと管理サーバーがリソースを費やし、最も重要なことに、ポリシーの検証と適用に時間がかかるためです。

3.4. 脅威対策ポリシーはどのように構成されますか?

まず、Check Point では、IPS を別のプロファイルに移動し、このブレードに別のルールを作成することをお勧めします。

たとえば、管理者は、DMZ セグメントは IPS でのみ保護されるべきだと考えています。 したがって、ゲートウェイが他のブレードによるパケットの処理でリソースを無駄にしないようにするには、IPS のみが有効なプロファイルを使用してこのセグメント専用のルールを作成する必要があります。

プロファイルの設定に関しては、この記事のベスト プラクティスに従って設定することをお勧めします。 文書(17～20ページ)。

3.5. IPS 設定の検出モードのシグネチャはいくつありますか?

未使用の署名を無効にするという意味で、署名に熱心に取り組むことをお勧めします (たとえば、Adobe 製品の操作のための署名には多くの計算能力が必要であり、顧客がそのような製品を持っていない場合は、無効にすることが合理的です)署名）。 次に、可能な場合は Detect ではなく Prevent を設定します。これは、ゲートウェイが Detect モードでは接続全体の処理にリソースを費やすため、Prevent モードでは接続が直ちに切断され、パケットの完全な処理にリソースが浪費されません。

3.6. 脅威エミュレーション、脅威抽出、ウイルス対策ブレードによって処理されるファイルは何ですか?

ユーザーがダウンロードしない拡張ファイルや、ネットワーク上で不要と思われる拡張ファイルをエミュレートして分析することは意味がありません (たとえば、bat ファイルや exe ファイルは、ファイアウォール レベルでコンテンツ認識ブレードを使用して簡単にブロックできるため、ゲートウェイ リソースは支出が減りました）。 さらに、脅威エミュレーション設定では、サンドボックスで脅威をエミュレートする環境 (オペレーティング システム) を選択し、すべてのユーザーがバージョン 7 で作業しているときに環境 Windows 10 をインストールできますが、これも意味がありません。

3.7. ファイアウォールとアプリケーション層のルールはベスト プラクティスに従って配置されていますか?

ルールに多数のヒット (一致) がある場合は、それらを一番上に配置し、ヒット数が少ないルールは一番下に配置することをお勧めします。 重要なことは、それらが交差したり、互いに重なったりしないようにすることです。 推奨されるファイアウォール ポリシー アーキテクチャ:

説明：

最初のルール - 最も多く一致したルールがここに配置されます
ノイズ ルール - NetBIOS などの偽のトラフィックをドロップするためのルール
ステルス ルール - ゲートウェイへの認証ルールで指定されたソースを除くすべてのゲートウェイへのアクセスと管理を禁止します。
通常、クリーンアップ ルール、ラスト ルール、およびドロップ ルールは XNUMX つのルールに結合され、以前に許可されなかったすべてのルールが禁止されます。

ベスト プラクティス データについては、次の場所で説明されています。 sk106597.

3.8. 管理者が作成したサービスの設定は何ですか?

たとえば、一部の TCP サービスが特定のポート上に作成されている場合、そのサービスの詳細設定で「Match for Any」のチェックを外すことが合理的です。 この場合、このサービスは、それが表示されるルールに明確に該当し、[サービス] 列に [Any] が含まれるルールには参加しません。

サービスに関して言えば、タイムアウトを調整する必要がある場合があることに言及する価値があります。 この設定により、ゲートウェイ リソースをよりインテリジェントに使用できるようになり、大きなタイムアウトを必要としないプロトコルのために余分な TCP / UDP セッション時間を保持することがなくなります。 たとえば、以下のスクリーンショットでは、domain-udp サービスのタイムアウトを 40 秒から 30 秒に変更しました。

3.9. SecureXL は使用されていますか?また、加速の割合はどのくらいですか?

ゲートウェイのエキスパート モードでメイン コマンドを使用して SecureXL の品質を確認できます。 fwaccel統計 и fw アクセル統計 -s。 次に、どのような種類のトラフィックが加速しているのか、さらに作成できるテンプレート (テンプレート) を把握する必要があります。

デフォルトでは、ドロップ テンプレートは有効になっていないため、有効にすると SecureXL の動作にプラスの効果が生じます。 これを行うには、ゲートウェイ設定と [最適化] タブに移動します。

また、クラスターを使用する場合、CPU を最適化するために、UDP DNS、ICMP などの重要ではないサービスの同期を無効にすることができます。 これを行うには、サービス設定→詳細→接続の同期に移動し、クラスター上で状態同期が有効になっています。

すべてのベスト プラクティスについては、次のセクションで説明されています。 sk98348.

3.10. CoreXlはどのように使用されますか?

CoreXL テクノロジーにより、ファイアウォール インスタンス (ファイアウォール モジュール) に複数の CPU を使用できるようになり、デバイスのパフォーマンスの最適化に確実に役立ちます。 チームファースト fw ctl アフィニティ -l -a 使用されているファイアウォール インスタンスと、必要な SND (ファイアウォール エンティティにトラフィックを分散するモジュール) に渡されたプロセッサが表示されます。 すべてのプロセッサが関与していない場合は、次のコマンドを使用してプロセッサを追加できます。 cpconfig 玄関先で。
また、良い話は次のとおりです ホットフィックス マルチキューを有効にします。 マルチキューは、SND を備えたプロセッサが多くのパーセントで使用されており、他のプロセッサ上のファイアウォール インスタンスがアイドル状態である場合に問題を解決します。 そうすれば、SND は XNUMX つの NIC に対して多数のキューを作成し、カーネル レベルで異なるトラフィックに対して異なる優先順位を設定できるようになります。 その結果、CPU コアはよりインテリジェントに使用されるようになります。 方法については、以下にも説明されています。 sk98348.

結論として、これらは Check Point を最適化するためのベスト プラクティスのすべてではありませんが、最も一般的なものであると言いたいと思います。 セキュリティ ポリシーの監査をリクエストしたい場合、または Check Point の問題を解決したい場合は、お問い合わせください。 [メール保護].

ありがとうございました！

出所： habr.com