セキュリティポリシーの監視とトラブルシューティング
監視では、ネットワーク上のアクセスアクティビティの状態を表す有意義なデータがリアルタイムで表示されます。この洞察により、運用条件を簡単に解釈して影響を与えることができます。トラブルシューティングは、ネットワーク上のアクセスの問題を解決するためのコンテキストガイダンスを提供します。その後、ユーザーの懸念に対処し、タイムリーに解決策を提供できます。
セキュリティ アラームについて
ポリシー違反によりパケットがドロップされると、アラームがトリガーされます。ポリシー違反は、パケットが拒否ポリシーまたは拒否ポリシーに一致する場合に発生します。ポリシー違反アラームは、システムが以下の監査済みイベントのいずれかを監視するときに生成されます。
指定された期間内の送信元ネットワーク ID によるポリシー違反の数
指定された期間内の宛先ネットワーク識別子に対するポリシー違反の数
指定した期間内のアプリケーションに対するポリシー違反の数
指定した期間内のポリシー ルールまたはルール違反のグループ
これら 4 つのイベントに対応する 4 種類のアラームがあります。アラームは、送信元 IP、宛先 IP、アプリケーション、およびポリシーに基づいています。
パケットが拒否ポリシーまたは拒否ポリシーを検出すると、有効なすべてのタイプのアラームのポリシー違反カウンターが増加します。指定した期間内にいずれかのカウンタが指定したしきい値に達すると、アラームが生成されます。指定した期間が経過すると、ポリシー違反カウンターがリセットされ、別のカウント サイクルを開始するために再利用されます。
アラーム情報を表示するには、 コマンドを実行します show security alarms 。違反数とアラームは、システムを再起動しても持続しません。再起動後、違反カウントはゼロにリセットされ、アラームはアラーム キューからクリアされます。
適切なアクションを実行した後、アラームをクリアできます。アラームは、クリアするまで(またはデバイスを再起動するまで)キューに残ります。アラームをクリアするには、 コマンドを実行します clear security alarms 。アラームをクリアした後、その後の一連のフローポリシー違反により、新しいアラームが発生する可能性があります。
関連項目
例:ポリシー違反に対応するセキュリティアラームの生成
この例では、ポリシー違反が発生した場合にシステム アラームを生成するようにデバイスを設定する方法を示しています。デフォルトでは、ポリシー違反が発生してもアラームは発生しません。
要件
この機能を設定する前に、デバイス初期化以外の特別な設定を行う必要はありません。
概要
この例では、次の場合に発生するアラームを設定します。
アプリケーション サイズは 10240 単位です。
送信元 IP 違反が 20 秒以内に 1000 を超えました。
宛先 IP 違反が 10 秒以内に 1000 を超えました。
ポリシー一致違反が 100 を超えており、サイズは 100 単位です。
構成
手順
CLIクイック構成
この例を迅速に設定するには、以下のコマンドをコピーして、テキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを 階層レベルで CLI [edit] にコピー アンド ペーストして、設定モードから を入力します commit 。
set security alarms potential-violation policy application size 10240 set security alarms potential-violation policy source-ip threshold 1000 duration 20 set security alarms potential-violation policy destination-ip threshold 1000 duration 10 set security alarms potential-violation policy policy-match threshold 100 size 100
手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、 CLIユーザー ガイドの 設定モードでのCLIエディターの使用を参照してください。
ポリシー違反アラームを設定するには:
セキュリティ アラームを有効にします。
[edit] user@host# edit security alarms
アプリケーション違反が発生した場合にアラームを発生させるように指定します。
[edit security alarms potential-violation policy] user@host# set application size 10240
送信元 IP 違反が発生した場合にアラームを発生させるように指定します。
[edit security alarms potential-violation policy] user@host# set source-ip threshold 1000 duration 20
宛先 IP 違反が発生した場合にアラームを発生させるように指定します。
[edit security alarms potential-violation policy] user@host# set destination-ip threshold 1000 duration 10
ポリシー一致違反が発生した場合にアラームを発生させるように指定します。
[edit security alarms potential-violation policy] user@host# set policy-match threshold 100 size 100
結果
設定モードから、 コマンドを入力して show security alarms 設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。
policy {
source-ip {
threshold 1000;
duration 20;
}
destination-ip {
threshold 1000;
duration 10;
}
application {
size 10240;
}
policy-match {
threshold 100;
size 100;
}
}
デバイスの設定が完了したら、設定モードから を入力します commit 。
検証
設定が正常に機能していることを確認するには、動作モードから コマンド show security alarms を入力します。
一致するセキュリティ ポリシー
このコマンド show security match-policies を使用すると、一致基準(送信元ポート、宛先ポート、送信元 IP アドレス、宛先 IP アドレス、プロトコル)を使用してトラフィックの問題のトラブルシューティングを行うことができます。たとえば、適切なポリシーが設定されていないか、一致条件が正しくないためにトラフィックが通過しない場合、このコマンドを使用するとオフラインで作業し、 show security match-policies 問題が実際に存在する場所を特定できます。検索エンジンを使用して問題を特定するため、トラフィックに適切な一致ポリシーを使用できます。
オプションは、 result-count 表示するポリシーの数を指定します。リスト内で最初に有効なポリシーは、一致するすべてのトラフィックに適用されるポリシーです。その下にある他のポリシーは、最初のポリシーによって「シャドウ」され、一致するトラフィックによって検出されることはありません。
コマンドは show security match-policies 、セキュリティ ポリシーにのみ適用されます。IDP ポリシーはサポートされていません。
例 1: セキュリティ一致ポリシーを表示する
user@host> show security match-policies from-zone z1 to-zone z2 source-ip 10.10.10.1 destination-ip 192.0.2.1 source-port 1 destination-port 21 protocol tcp
Policy: p1, action-type: permit, State: enabled, Index: 4
Sequence number: 1
From zone: z1, To zone: z2
Source addresses:
a2: 203.0.113.1/25
a3: 10.10.10.1/32
Destination addresses:
d2: 203.0.113.129/25
d3: 192.0.2.1/24
Application: junos-ftp
IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800
Source port range: [0-0]
Destination port range: [21-21]
例2:結果カウント・オプションの使用
デフォルトでは、出力リストには、指定された特性のトラフィックに適用されるポリシーが含まれています。条件に一致するポリシーを複数一覧表示するには、 オプションを使用します result-count 。リストの先頭に表示されるポリシーは、常に一致するトラフィックに適用されるポリシーです。 result-count 値が 2 から 16 の場合、出力には、指定された result-countまでの基準に一致するすべてのポリシーが含まれます。最初のポリシーの後にリストされたすべてのポリシーは、最初のポリシーによって「シャドウ」され、一致するトラフィックには適用されません。
このオプションを使用して、新しいポリシーの位置をテストしたり、特定のトラフィックに期待どおりに適用されていないポリシーのトラブルシューティングを行います。
次の例では、トラフィック基準が 2 つのポリシーに一致します。リストの最初のポリシーである には、 p1トラフィックに適用されたアクションが含まれています。ポリシー p15 は最初のポリシーによってシャドウされるため、そのアクションは一致するトラフィックには適用されません。
user@host> show security match-policies from-zone zone-A to-zone zone-B source-ip 10.10.10.1 destination-ip 192.0.2.1 source-port 1004 destination-port 80 protocol tcp result-count 5
Policy: p1, action-type: permit, State: enabled, Index: 4
Sequence number: 1
From zone: zone-A, To zone: zone-B
Source addresses:
sa1: 10.10.0.0/16
Destination addresses:
da5: 192.0.2.0/24
Application: any
IP protocol: 1, ALG: 0, Inactivity timeout: 0
Source port range: [1000-1030]
Destination port range: [80-80]
Policy: p15, action-type: deny, State: enabled, Index: 18
Sequence number: 15
From zone: zone-A, To zone: zone-B
Source addresses:
sa11: 10.10.10.1/32
Destination addresses:
da15: 192.0.2.5/24
Application: any
IP protocol: 1, ALG: 0, Inactivity timeout: 0
Source port range: [1000-1030]
Destination port range: [80-80]
関連項目
ポリシーのヒット数の追跡
show security policies hit-countコマンドを使用すると、セキュリティ ポリシーが受信したヒット数に応じたユーティリティ レートが表示されます。この機能を使用して、デバイスで使用されているポリシーとその使用頻度を判断できます。選択したコマンド オプションに応じて、ヒット数を順序なしで一覧表示したり、昇順または降順で並べ替えたり、特定のカウントを上回る、下回る、または範囲内のヒット数に制限したりできます。ポリシーまたは名前付きゾーンに関連付けられているすべてのゾーンのデータが表示されます。
SRXシリーズ デバイスでのメモリ使用量のチェック
ポリシー構成の前後でメモリ値を比較することで、メモリの問題を特定できます。
SRX1400、SRX1500、SRX3400、SRX3600、SRX4100、SRX4200、SRX4600、SRX5400、SRX5600、SRX5800デバイス上のポリシー、ゾーン、アドレスなどのフローエンティティのメモリ(インストールされたJunos OSリリースによって異なります)は動的に割り当てられます。ただし、特定のプラクティスは、特にポリシーの実装中に、デバイスの現在のメモリ使用量を監視し、パラメーターを最適化してシステム構成のサイズを改善するのに役立ちます。
メモリ使用量を確認するには:
show chassis routing-engineコマンドを使用して、ルーティングエンジン(RE)の全体的なメモリ使用量を確認します。このコマンドの次の出力は、メモリ使用率が 39% であることを示しています。user@host#
show chassis routing-engineRouting Engine status: Slot 0: Current state Master Election priority Master (default) DRAM 1024 MB Memory utilization 39 percent CPU utilization: User 0 percent Background 0 percent Kernel 2 percent Interrupt 0 percent Idle 97 percent Model RE-PPC-1200-A Start time 2011-07-09 19:19:49 PDT Uptime 37 days, 15 hours, 44 minutes, 13 seconds Last reboot reason 0x3:power cycle/failure watchdog Load averages: 1 minute 5 minute 15 minute 0.22 0.16 0.07show system processes extensiveルーティングエンジンで実行されているプロセスに関する情報を取得するには、 コマンドを使用します。find nsdコマンドのshow system processes extensiveオプションを使用すると、使用中のメモリーの合計が 10 メガバイトで CPU 使用率が 0% のネットワーク・セキュリティー・デーモン (NSD) での直接使用量が表示されます。user@host# show system processes extensive | find nsd 1182 root 1 96 0 10976K 5676K select 2:08 0.00% nsd 1191 root 4 4 0 8724K 3764K select 1:57 0.00% slbd 1169 root 1 96 0 8096K 3520K select 1:51 0.00% jsrpd 1200 root 1 4 0 0K 16K peer_s 1:10 0.00% peer proxy 1144 root 1 96 0 9616K 3528K select 1:08 0.00% lacpd 1138 root 1 96 0 6488K 2932K select 1:02 0.00% ppmd 1130 root 1 96 0 7204K 2208K select 1:02 0.00% craftd 1163 root 1 96 0 16928K 5188K select 0:58 0.00% cosd 1196 root 1 4 0 0K 16K peer_s 0:54 0.00% peer proxy 47 root 1 -16 0 0K 16K sdflus 0:54 0.00% softdepflush 1151 root 1 96 0 15516K 9580K select 0:53 0.00% appidd 900 root 1 96 0 5984K 2876K select 0:41 0.00% eventd
構成ファイルのサイズを確認します。CLI を終了する前に、コンフィギュレーション・ファイルを一意の名前で保存します。次に、UNIX レベル シェルのシェル プロンプトから コマンドを入力して
ls -1 filename、次のサンプル出力に示すようにファイル サイズを確認します。user@host> start shell % ls -l config -rw-r--r-- 1 remote staff 12681 Feb 15 00:43 config
関連項目
セキュリティ ポリシーの統計情報を監視する
目的
以前に設定されたポリシーに基づいてJunos OSが許可または拒否するトラフィックを監視および記録します。
アクション
トラフィックを監視するには、カウントとログのオプションを有効にします。
カウント—個々のポリシーで構成可能。カウントが有効になっている場合、特定のポリシーでデバイスに入るセッションと、特定のポリシーで両方向にデバイスを通過するパケット数とバイト数の統計が収集されます。カウント(パケットとバイトのみ)では、トラフィックが指定したしきい値を超えたときにアラームが生成されるように指定できます。 count (セキュリティ ポリシー)を参照してください。
ログ—ロギング機能は、セッションの初期化(セッション初期化)またはセッションのクローズ(セッションクローズ)段階でセキュリティポリシーを使用して有効にできます。 ログ (セキュリティポリシー)を参照してください。
拒否された接続からのログを表示するには、 セッション初期化のログオンを有効にします。
終了/破棄後にセッションをログに記録するには、[ セッション終了時のログオン] を有効にします。
セッションログはフローコードでリアルタイムで有効になり、ユーザーのパフォーマンスに影響を与えます。 セッションクローズ と セッション初期化 の両方が有効になっている場合、 セッション初期化 のみを有効にする場合と比較して、パフォーマンスはさらに低下します。
セッションログ用に収集される情報の詳細については、 SRXシリーズサービスゲートウェイのセッションログエントリーで提供される情報を参照してください。
シャドウポリシーの検証
すべてのシャドウポリシーの検証
目的
1 つ以上のポリシーをシャドウするすべてのポリシーを検証します。
アクション
動作モードから、以下のコマンドを入力します。
論理システムの場合は、 コマンドを入力します
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-name。グローバルポリシーの場合は、 コマンドを入力します
show security shadow-policies logical-system lsys-name global。
root@host> show security shadow-policies from-zone zone-a to-zone zone-b
Policies Shadowed policies
P1 P3
P1 P4
P2 P5
意味
出力には、他のポリシーをシャドウするすべてのポリシーのリストが表示されます。この例では、P1 ポリシーは P3 および P4 ポリシーをシャドウし、P2 ポリシーは P5 ポリシーをシャドウします。
ポリシーが1つ以上のポリシーをシャドウする検証
目的
特定のポリシーが、その後に配置された 1 つ以上のポリシーをシャドウしているかどうかを確認します。
アクション
動作モードから、以下のコマンドを入力します。
論理システムの場合は、 コマンドを入力します
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-name policy policy-name。グローバルポリシーの場合は、 コマンドを入力します
show security shadow-policies logical-system lsys-name global policy policy-name。
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P1
Policies Shadowed policies
P1 P3
P1 P4
意味
出力には、特定のポリシーによってシャドウされているすべてのポリシーが表示されます。この例では、P1 ポリシーは P3 および P4 ポリシーをシャドウします。
ポリシーが 1 つ以上のポリシーによってシャドウされていることの検証
目的
特定のポリシーが、その前に配置されている 1 つ以上のポリシーによってシャドウされているかどうかを確認します。
アクション
動作モードから、以下のコマンドを入力します。
論理システムの場合は、 コマンドを入力します
show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-zone-name policy policy-name reverse。グローバルポリシーの場合は、 コマンドを入力します
show security shadow-policies logical-system lsys-name global policy policy-name reverse。
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P4 reverse
Policies Shadowed policies
P1 P4
意味
出力には、1つ以上のポリシーによってシャドウされた特定のポリシーが表示されます。この例では、P4 ポリシーは P1 ポリシーによってシャドウされます。
セキュリティポリシーのトラブルシューティング
ルーティングエンジンとパケット転送エンジン間のポリシーの同期
問題
説明
セキュリティ ポリシーは、ルーティング エンジンとパケット転送エンジンに保存されます。セキュリティポリシーは、設定をコミットする際にルーティングエンジンからパケット転送エンジンにプッシュされます。ルーティング エンジンのセキュリティ ポリシーがパケット転送エンジンと同期していない場合、設定のコミットは失敗します。コア ダンプ ファイルは、コミットが繰り返し試行された場合に生成される場合があります。非同期は、次の原因で発生する可能性があります。
ルーティング エンジンからパケット転送エンジンへのポリシー メッセージは、転送中に失われます。
ルーティング エンジンのエラー(ポリシー UID の再利用など)。
環境
ルーティングエンジンとパケット転送エンジンのポリシーは、コンフィギュレーションをコミットするために同期している必要があります。ただし、特定の状況下では、ルーティング エンジンとパケット転送エンジンのポリシーが同期しなくなり、コミットが失敗することがあります。
症状
ポリシー構成が変更され、ポリシーが同期していない場合、次のエラーメッセージが表示されます。 error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)> Please request security policies check/resync.
ソリューション
show security policies checksumセキュリティ ポリシーが同期していない場合は、 コマンドを使用してセキュリティ ポリシーのチェックサム値request security policies resync を表示し、コマンド を使用してルーティング エンジンとパケット転送エンジンのセキュリティ ポリシーの設定を同期します。
関連項目
セキュリティ ポリシーのコミット失敗の確認
セキュリティ ポリシーのコミットの検証
問題
説明
ポリシー構成のコミットの実行時に、システムの動作が正しくないことに気付いた場合は、次の手順を使用してこの問題のトラブルシューティングを行います。
ソリューション
動作可能な 表示 コマンド:セキュリティ ポリシーの操作コマンドを実行し、出力に表示される情報が期待したものと一致していることを確認します。そうでない場合は、構成を適切に変更する必要があります。
traceoptions:ポリシー設定でコマンドを設定します
traceoptions。この階層の下にあるフラグは、コマンド出力のshowユーザー分析に従って選択できます。使用するフラグを決定できない場合は、フラグ オプションallを使用してすべてのトレース ログをキャプチャできます。user@host#
set security policies traceoptions <flag all>
また、ログをキャプチャするために、オプションのファイル名を設定することもできます。
user@host# set security policies traceoptions <filename>
トレース・オプションでファイル名を指定した場合は、/var/log/<filename>でログ・ファイルを検索し、ファイルにエラーが報告されていないかどうかを確認できます。(ファイル名を指定しなかった場合、デフォルトのファイル名がイベントされます。)エラー メッセージには、障害の場所と適切な理由が示されます。
トレース・オプションを設定した後、誤ったシステム動作の原因となった設定変更を再コミットする必要があります。
アドレス名解決キャッシュの高可用性(HA)同期
ネットワーク・セキュリティー・プロセス (NSD) は、システムのリブート時、HA フェイルオーバーの発生時、またはプロセスがクラッシュした場合に再始動します。この間、セキュリティポリシーに多数のドメイン名アドレスが設定されている場合、SRXシリーズファイアウォールはDNSサーバーにリクエストを送信して、解決されたすべてのIPアドレスを取得しようとします。多数の DNS クエリと応答が交換されると、大量のシステム リソースが消費されます。そのため、SRXシリーズファイアウォールはDNSサーバーから応答を得ることができず、アドレス帳エントリー内のホスト名のアドレスが正しく解決されない可能性があります。これにより、セキュリティ ポリシーまたはセッションの一致が見つからないため、トラフィックがドロップする可能性があります。SRXシリーズファイアウォールの新しい拡張機能では、DNSクエリの結果をローカルDNSキャッシュファイルにキャッシュし、DNSキャッシュファイルをHAプライマリノードからHAバックアップノードに定期的に同期することで、この問題に対処しています。DNSキャッシュファイルには、IPアドレス、ドメイン名、およびTTL値が保存されます。HA フェイルオーバー後、前のバックアップノードがプライマリノードになります。すべての DNS キャッシュの結果は新しいプライマリノードで利用できるため、セキュリティポリシーの処理は続行され、ポリシールールに従ってパススルートラフィックが許可されます。
Junos OS リリース 19.3R1 以降、ポリシー DNS キャッシュメモリは、HA アクティブノード上の 1 つのローカル DNS キャッシュファイルに同期され、NSD 再起動時の DNS クエリーまたは応答を抑制するために HA バックアップノードにコピーされます。
同期を実行するには、次の手順を実行します。
この期間中にポリシー DNS キャッシュメモリの内容が変更された場合、ポリシー DNS キャッシュメモリは 30 秒ごとに /var/db/policy_dns_cache パスにある 1 つのローカルポリシー DNS キャッシュファイルに同期されます。
ローカル DNS キャッシュファイルは、ステップ 1 でローカル DNS キャッシュファイルが更新された直後に、HA プライマリノードから HA バックアップノードに同期されます。
同期には、次のコンテンツが含まれます。
ドメイン名
IPv4アドレスリストとそのTTL(有効期限)
IPv6 アドレス リストとその TTL
NSD が再始動すると、ローカル DNS キャッシュ・ファイルを読み取って構文解析し、すべてのキャッシュ・エントリーをメモリーにインポートします。この同期により、NSD 再始動時に DNS 照会が抑止されます。ポリシー設定を読み取るときに、ドメイン名の解決済み IP アドレスがすでに DNS キャッシュメモリに存在するため、HA フェイルオーバー中に新しいプライマリノードで NSD が再起動します。したがって、ドメイン名のすべての解決済みIPアドレスは、新しいプライマリノードのルーティングエンジンとパケット転送エンジンのポリシー内に存在するため、HAフェイルオーバー後のセキュリティポリシーに従って、新しいパススルートラフィックが許可されます。