セキュリティポリシーの監視とトラブルシューティング
監視は、ネットワーク上のアクセス アクティビティの状態を表す有意義なデータをリアルタイムで提供します。このインサイトにより、運用状態を簡単に解釈し、効果を得ることができます。トラブルシューティングでは、ネットワーク上のアクセスの問題を解決するためのコンテキストガイダンスを提供します。その後、ユーザーの懸念に対処し、タイムリーに解決策を提供できます。
セキュリティ アラームについて
アラームは、ポリシー違反によりパケットが破棄された場合に発生します。ポリシー違反は、パケットが拒否または拒否のポリシーに一致した場合に発生します。ポリシー違反アラームは、システムが次の監査イベントのいずれかをモニタするときに生成されます。
指定した期間内の送信元ネットワーク識別子によるポリシー違反の数
指定した期間内の宛先ネットワーク識別子に対するポリシー違反の数
指定した期間内のアプリケーションに対するポリシー違反の数
指定した期間内のポリシールールまたはルール違反のグループ
この 4 つのイベントに対応する 4 種類のアラームがあります。アラームは、送信元 IP、宛先 IP、アプリケーション、ポリシーに基づいています。
パケットが拒否または拒否ポリシーに遭遇すると、有効なすべてのタイプのアラームのポリシー違反カウンターが増加します。指定された期間内にカウンターが指定されたしきい値に達すると、アラームが生成されます。指定した期間が経過すると、ポリシー違反カウンターがリセットされ、別のカウント サイクルを開始するために再利用されます。
アラーム情報を表示するには、 show security alarms コマンドを実行します。違反カウントとアラームは、システムを再起動しても持続しません。再起動後、違反カウントはゼロにリセットされ、アラームはアラーム キューからクリアされます。
適切な処置を行った後、アラームを解除できます。アラームは、クリアするまで(またはデバイスを再起動するまで)キューに残ります。アラームをクリアするには、 clear security alarms コマンドを実行します。アラームをクリアした後、その後に一連のフロー ポリシー違反が発生すると、新しいアラームが発生する可能性があります。
参照
例:ポリシー違反に応答したセキュリティ アラームの生成
この例では、ポリシー違反が発生したときにシステム アラームを生成するようにデバイスを設定する方法を示しています。デフォルトでは、ポリシー違反が発生してもアラームは発生しません。
必要条件
この機能を設定する前に、デバイス初期化以外の特別な設定を行う必要はありません。
概要
この例では、次の場合に発生するアラームを設定します。
アプリケーションサイズは10240ユニットです。
送信元 IP 違反が 20 秒以内に 1000 を超えました。
宛先 IP 違反が 10 秒以内に 1000 を超えました。
ポリシー一致違反が 100 を超えており、サイズは 100 ユニットです。
構成
プロシージャ
CLIクイック構成
この例を迅速に設定するには、以下のコマンドをコピーして、テキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを [edit] 階層レベルで CLI にコピー アンド ペーストして、設定モードから 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:show security match-policies
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 オプションを使用します。リストされている最初のポリシーは、常に一致するトラフィックに適用されるポリシーです。 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 コマンドを使用して、セキュリティ ポリシーが受信したヒット数に応じたセキュリティ ポリシーの効用率を表示します。この機能を使用して、デバイスで使用されているポリシーとその使用頻度を判断できます。選択したコマンド オプションに応じて、ヒット数を順序なしで一覧表示したり、昇順または降順で並べ替えたり、特定のカウントを上回ったり下回ったり、範囲内のヒット数に制限したりできます。ポリシーまたは名前付きゾーンに関連づけられているすべてのゾーンのデータが表示されます。
メモリ使用量の確認
デバイスからも削除されます前後のメモリ値を比較することで、メモリの問題を切り分けることができます。
特定のプラクティスは、特にポリシーの実装中に、デバイスの現在のメモリ使用量を監視し、パラメーターを最適化してシステム構成のサイズを適切に設定するのに役立ちます。
メモリ使用量を確認するには、次のようにします。
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コマンドを使用して、ルーティングエンジンで実行されているプロセスに関する情報を取得します。show system processes extensiveコマンドでfind nsdオプションを使用すると、使用中の合計メモリーが 10 メガバイト、CPU 使用率が 0% の Network Security Daemon (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 が有効な場合、特定のポリシーでデバイスに入るセッション、および特定のポリシーでデバイスを通過するパケット数とバイト数に関する統計情報が収集されます。カウント(パケットとバイトのみ)では、トラフィックが指定したしきい値を超えたときにアラームが生成されるように指定できます。 カウント(セキュリティポリシー)を参照してください。
ログ —ロギング機能は、セッション初期化(session-init)またはセッション終了(session-close)の段階で、セキュリティポリシーによって有効にできます。 ログ(セキュリティポリシー)を参照してください。
拒否された接続からのログを表示するには、 session-init のログオンを有効にします。
終了/破棄後にセッションをログに記録するには、 セッション終了時のログオンを有効にします。
セッションログはフローコードでリアルタイムに有効になり、ユーザーのパフォーマンスに影響を与えます。 session-close と session-init の両方が有効になっている場合、 session-init のみを有効にする場合と比較して、パフォーマンスはさらに低下します。
セッションログで収集される情報の詳細については、 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>でログファイルを調べて、ファイルにエラーが報告されているかどうかを確認できます。(ファイル名を指定しなかった場合、デフォルトのファイル名は eventd になります。エラーメッセージは、障害の場所と適切な理由を示します。
トレース オプションを設定した後、不正なシステム動作の原因となった設定変更を再コミットする必要があります。
アドレス名の高可用性(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 キャッシュファイルに同期され、HA バックアップノードにコピーされることで、NSD 再起動時の DNS クエリーや応答が抑制されます。
同期を実行するには、次の手順を実行します。
ポリシー DNS キャッシュメモリは、この期間中にポリシー DNS キャッシュメモリの内容が変更された場合、30 秒ごとに /var/db/policy_dns_cache パスにある 1 つのローカルポリシー DNS キャッシュファイルに同期されます。
ローカルDNSキャッシュファイルは、ステップ1でローカルDNSキャッシュファイルが更新された直後に、HAプライマリノードからHAバックアップノードに同期されます。
同期には、次のコンテンツが含まれます。
-
ドメイン名
-
IPv4アドレスリストとそのTTL(有効期限)
-
IPv6 アドレス リストとその TTL
NSD が再起動すると、ローカル DNS キャッシュ ファイルを読み取って解析し、すべてのキャッシュ エントリをメモリにインポートします。この同期により、NSD の再起動時に DNS クエリが抑制されます。NSD は、ポリシー設定を読み取るときにドメイン名の解決済み IP アドレスが DNS キャッシュメモリにすでに存在するため、HA フェイルオーバー中に新しいプライマリノードで再起動します。したがって、ドメイン名のすべての解決済みIPアドレスは、新しいプライマリノードのルーティングエンジンとパケット転送エンジンのポリシー内に存在するため、HAフェイルオーバー後のセキュリティポリシーに従って新しいパススルートラフィックが許可されます。
プラットフォーム固有のメモリ使用動作
Feature Explorerを使用して、特定の機能に対するプラットフォームとリリースのサポートを確認します。
次の表を使用して、プラットフォームのプラットフォーム固有の動作を確認します。
| プラットホーム |
差 |
|---|---|
| SRX シリーズ |
|