セキュリティポリシーの監視とトラブルシューティング
監視は、ネットワーク上のアクセスアクティビティの状態を表す意味のあるデータをリアルタイムで提示します。このインサイトにより、運用状況を簡単に解釈し、影響を与えることができます。トラブルシューティングは、ネットワーク上のアクセスの問題を解決するための状況に応じたガイダンスを提供します。そうすれば、ユーザーの懸念に対処し、タイムリーに解決策を提供できます。
セキュリティアラームについて
アラームは、ポリシー違反によりパケットがドロップされたときにトリガーされます。ポリシー違反は、パケットが拒否または拒否ポリシーに一致する場合に発生します。ポリシー違反アラームは、システムが以下の監査済みイベントのいずれかを監視すると生成されます。
指定期間内の送信元ネットワーク識別子によるポリシー違反の数
指定された期間内の宛先ネットワーク識別子に対するポリシー違反の数
指定期間内のアプリケーションに対するポリシー違反の数
指定した期間内のポリシールールまたはルール違反のグループ
これら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 セキュリティ 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が以前に設定されたポリシーに基づいて許可または拒否するトラフィックを監視および記録します。
アクション
トラフィックを監視するには、カウントとログオプションを有効にします。
カウント—個々のポリシーで設定可能。カウントが有効になっている場合、特定のポリシーのデバイスに入るセッションの統計情報と、特定のポリシーのデバイスの両方向を通過したパケット数とバイト数の統計が収集されます。カウント(パケットとバイトのみ)については、トラフィックが指定されたしきい値を超えるたびにアラームを生成するように指定できます。 カウント(セキュリティポリシー)を参照してください。
ログ—ログ機能は、セッション初期化(session-init)またはセッション終了(session-close)段階でセキュリティポリシーを使用して有効にできます。 ログ(セキュリティポリシー)を参照してください。
拒否された接続からのログを表示するには、 log on 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コマンド出力のユーザー分析に従って選択できます。使用するフラグを決定できない場合は、flagオプション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キャッシュファイルにキャッシュし、HAプライマリノードからHAバックアップノードにDNSキャッシュファイルを定期的に同期することで、この問題に対処します。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キャッシュファイルに同期されます。
ステップ HA でローカル DNS キャッシュ ファイルが更新された直後に、ローカル DNS キャッシュ ファイルが HA プライマリ ノードから HA バックアップ ノードに同期されます。
同期には以下のコンテンツが含まれます。
-
ドメイン名
-
IPv4アドレスリストとそのTTL(Time to live)
-
IPv6アドレスリストとそのTTL
NSDが再起動すると、ローカルDNSキャッシュファイルを読み取り、解析し、すべてのキャッシュエントリをメモリにインポートします。同期により、NSDの再起動中にDNSクエリが抑制されます。ポリシー設定を読み取るときに、ドメイン名の解決済みIPアドレスがDNSキャッシュメモリにすでに存在するため、HAフェイルオーバー中にNSDが新しいプライマリノードで再起動します。そのため、ドメイン名の解決済みIPアドレスはすべて、新しいプライマリノードのルーティングエンジンとパケット転送エンジンのポリシー内に存在するため、HAフェイルオーバー後のセキュリティポリシーに従って新しいパススルートラフィックが許可されます。
プラットフォーム固有のメモリ使用動作
機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。
お使いのプラットフォームに固有の動作を確認するには、以下の表を使用して下さい:
| プラットフォーム |
違い |
|---|---|
| SRXシリーズ |
|