セキュリティデバイスのシステムログを設定する

コントロールプレーンとデータプレーンのログ

Junos OSは、システムのコントロールプレーンとデータプレーンで発生するイベントを記録するために個別のログメッセージを生成します。

• コントロールプレーンログは、システムログとも呼ばれ、ルーティングプラットフォームで発生するイベントを含みます。システムはコントロールプレーンイベントをルーティングエンジン上のeventdプロセスに送信し、その後、Junos OSポリシーを使用するか、システムログメッセージを生成するか、またはその両方を使用してイベントを処理します。コントロールプレーンログをファイル、ユーザー端末、ルーティングプラットフォームコンソール、またはリモートマシンのいずれかに送信することを選択できます。コントロールプレーンログを生成するには、[system]階層レベルでsyslogステートメントを使用します。

• データプレーンログは、 セキュリティログとも呼ばれ、主にデータプレーン内で処理されるセキュリティイベントが含まれます。

  セキュリティログは、テキスト形式またはバイナリ形式にすることができ、ローカルに保存するか(イベントモード)、外部サーバーに送信することができます(ストリームモード)。

  ストリームモードでは、ログ形式をbinary、protobuf、sd-syslog、またはsyslogとして設定できます。イベントモードでログ領域を節約するために、バイナリ形式を推奨します。

  以下の点に注意してください。

  • セキュリティログは、ローカル(オンボックス)、外部(オフボックス)、またはその両方に同時に保存できます。

  • デフォルトのログ モードはストリーム モードです。データプレーンイベントは、コントロールプレーンイベントと同様の方法でシステムログファイルに書き込まれます。セキュリティログのバイナリ形式を指定するには、オフボックスバイナリセキュリティログファイルの設定を参照してください

    注:

    SRXシリーズファイアウォールでイベントモードのログ記録を設定すると、デバイスがログをドロップすることがあります。

  解析エラーを回避するために、ストリームログ転送とオンボックスレポートでエスケープをサポートしています。ストリームモードは、ログがプロセスに送信されない場合、sd-syslogおよびbinary 形式eventdエスケープをサポートします。eventdプロセスに送信されるログでは、eventdプロセスで構造ログのエスケープが有効になっているため、escapeオプションを有効にしないことをお勧めします。イベントモードは、binary 形式でのみエスケープをサポートします。デフォルトでは、escapeオプションは無効になっています。set security log escapeコマンドを使用して、escapeオプションを有効にする必要があります。

冗長システムログサーバー

リモートサーバー向けのセキュリティシステムのログトラフィックは、2つの同時システムログ宛先をサポートするネットワークインターフェイスポートを介して送信されます。各システムログ宛先は個別に設定する必要があります。2つのシステムログ宛先アドレスが設定されている場合、同一のログが両方の宛先に送信されます。この機能をサポートするどのデバイスでも 2 つの宛先を設定できますが、2 つ目の宛先を追加することは、主にスタンドアロンおよびアクティブ/バックアップ設定の シャーシ クラスター 導入時の冗長バックアップとして役立ちます。

以下の冗長サーバー情報が利用可能です。

• 施設: cron

• 説明:cronスケジューリングプロセス

• 重大度レベル(重大度が高いものから低いものへ): debug

• 説明: ソフトウェア デバッグ メッセージ

概要

ソリッドステートドライブ(SSD)へのオンボックストラフィックログは、8つの外部ログサーバーまたはファイルをサポートします。

すべてのトラフィックログ情報を含むオールインワンのXMLファイルが追加されます。また、XMLファイルは、すべてのロギングヘッダーファイルとトラフィックログ関連のドキュメントを生成します。

サービス処理カード0(SPCs0)では、 ローカルログ管理されたデーモン(llmd) と呼ばれる新しいプロセス(デーモン)がサポートされており、オンボックストラフィックロギングを処理できます。SPCでフローによって生成されたトラフィックは、トラフィックログにリストされます。LLMD はこれらのログをローカル SSD に保存します。トラフィックログは、4つの異なるフォーマットで保存されます。ログ形式については、 表1 を参照してください。

表1:ログ形式

ログ形式	説明	デフォルト
Syslog	ログを保存するための従来のログ形式。	はい
sd-syslog	構造化システムログファイル形式。 最も記述的で長いため、保存により多くのスペースが必要です。 サイズが大きいため、この形式で保存されたログの転送には時間がかかります。	-
ウェルフ	WebTrends拡張ログファイル形式は、業界標準のログファイル交換形式です。 Firewall Suite 2.0 以降、Firewall Reporting Center 1.0 以降、および セキュリティ Reporting Center 2.0 以降と互換性があります。	-
バイナリ	ジュニパー独自のフォーマット。 他のすべてのログ形式の中で説明性が最も低く、他のログ形式と比較して最もスペースを必要としません。	-
protobuf	構造化データをシリアル化するための、言語に依存しない、プラットフォームに依存しない、拡張可能な Google のメカニズム。 データのエンコードには別の方法が使用されます。 ファイルサイズはsyslogやsd-syslogに比べて小さいです。

オンボックスレポートメカニズムは、既存のロギング機能を強化したものです。既存のロギング機能は、システムトラフィックログを収集し、ログを分析し、CLIを使用してこれらのログのレポートをテーブル形式で生成するように変更されています。オンボックスレポート機能は、セキュリティログを表示するためのシンプルで使いやすいインターフェイスを提供することを目的としています。オンボックスレポートは、テーブルやグラフの形式で、さまざまなセキュリティイベントの使いやすいJ-Webページです。このレポートにより、ITセキュリティ管理者はセキュリティ情報を一目で特定し、実行すべきアクションを迅速に決定できます。画面、IDP、コンテンツセキュリティ、IPSecなどの機能について、ログの詳細な分析が(セッションタイプに基づいて)実行されます。

以下の基準に基づいて、レポートされるログデータのフィルターを定義できます。

注:

top、in-detail、in-intervalの条件を同時に使用することはできません。

• top <number>—このオプションを使用すると、コマンドで指定されているトップセキュリティイベントのレポートを生成できます。例:コンテンツセキュリティを通じて検出された上位5つのIPS攻撃または上位6つのURL。

• in-detail <number>—このオプションでは、詳細なログコンテンツを生成できます。

• in-interval <time-period>—このオプションでは、特定の時間間隔の間にログに記録されたイベントを生成できます。

• summary—このオプションでは、イベントの概要を生成できます。このようにして、必要に応じてレポートを微調整し、使用するデータのみを表示できます。

インターバル内のカウントを示すインターバル内の最大数は30です。長い期間が指定された場合、最大インインターバルが 30 未満になるようにカウンターが組み立てられます。

テーブルが異なれば属性も異なるため(セッションテーブルには「reason」属性がないが、コンテンツセキュリティには属性が持つ)、in-detailとsummaryの両方に「all」オプションがあります。「all」オプションには開始時間と停止時間以外のフィルタがありません。開始時刻と停止時刻以外のフィルターがある場合は、エラーが表示されます。

例:root@host> show security log report in-detail all reason reason1

アプリケーションとユーザーの可視性のためのアプリケーションファイアウォールログには、アプリケーションとネストされたアプリケーションが一覧表示されます。これらの機能のログにネストされたアプリケーションがリストされている場合、ネストされたアプリケーションがJ-Webにリストされます。ログにネストされたアプリケーションが適用できないまたは不明としてリストされている場合、アプリケーションのみがJ-Webにリストされます。

以下のCLIコマンドを使用して、リストにあるすべてのアプリケーションとネストされたアプリケーションのアプリケーションとユーザーを可視化します。

• カウント別上位ネストアプリケーションの場合—show security log report top session-close top-number <number> group-by application order-by count with user

• ボリューム別に見た上位ネストされたアプリケーションの場合—show security log report top session-close top-number <number> group-by application order-by volume with user

• ネストされたアプリケーションを持つカウント別上位ユーザーの場合—show security log report top session-close top-number <number> group-by user order-by count with application

オンボックスレポート機能は、工場出荷時のデフォルト設定をデバイスに読み込むと、デフォルトで有効になります。

工場出荷時のデフォルト設定には、ソリッドステートドライブ(SSD)の寿命を延ばすためのオンボックスレポート設定は含まれていません。オンボックスレポート機能を有効にするには、階層で set security log report CLIコマンドを設定します [edit security log] 。

J-Webユーザーインターフェイスでこのタスクを実行するには、 SRXシリーズデバイス向けJ-Webユーザーガイド を参照してください。

オンボックスのレポートログは、外付けSSDがない場合、メモリファイルシステム(MFS)に保存されます。MFS に保存できるログの最大数は、外付け SSD に保存できるログ数よりも少なくなります。これにより、メモリの枯渇と障害を防ぎます。MFS に保存されたログは、デバイスの再ブート後または電源障害後に保持されません。表 2 を参照して、オンボックスレポートとオフボックスレポートで記録されたログの数を知ってください。

表2:ログ数

レポートモード	セッション	画面	IDP	コンテンツセキュリティ	IPsec-VPN	スカイ
オフボックス	1200,000	120,000	120,000	120,000	40,000	120,000
オンボックス	500,000	50,000	50,000	50,000	20,000	50,000

注:

set security policies from-zone zone-name to-zone zone-name policy policy-name then log session-closeコマンドを使用してセッションのセキュリティポリシーを設定し、オンボックスレポート機能を使用してJ-Webのアプリケーショントラッキングにすべてのアプリケーションとネストされたアプリケーションをリストアップする必要があります。詳細については、ログ(セキュリティポリシー)を参照してください。

ログメッセージが記録された後、ログはログファイルに保存され、詳細な分析のためにルーティングエンジンのデータベーステーブルに保存され、詳細な分析のためにSSDカードに保存されます。

注:

この機能は、セッションの数またはボリューム、またはログのタイプに基づいて上位レポートの受信をサポートし、指定された時間範囲内で毎秒発生するイベントをキャプチャし、指定されたCLI条件のログコンテンツをキャプチャします。レポートの生成には、「summary」、「top」、「in-detail」、「in-interval」などのさまざまなCLI条件が使用されます。CLIを使用して一度に生成できるレポートは1つだけです。すべてのCLI条件を同時に使用することはできません。CLIを使用して一度に生成できるレポートは1つだけです。

この機能のメリットは次のとおりです。

• レポートはSRXシリーズファイアウォールにローカルに保存され、ログとレポートを保存するために個別のデバイスやツールは必要ありません。

• オンボックスレポートは、表やグラフの形式で各種セキュリティイベントの使いやすいJ-Webページです。

• セキュリティログを表示するためのシンプルで使いやすいインターフェイスを提供します。

• 生成されたレポートにより、ITセキュリティ管理チームはセキュリティ情報を一目で特定し、実行すべきアクションを迅速に決定できます。

オンボックスレポート機能では、以下がサポートされます。

• 要件に基づいたレポートを生成します。例:セッションの数またはボリューム、IDP、コンテンツセキュリティ、IPsec VPNなどのアクティビティのログの種類。

• 指定した時間範囲内のリアルタイムイベントをキャプチャする。

• CLIで指定したさまざまな条件に基づいて、すべてのネットワークアクティビティを、論理的で整理された、わかりやすい形式でキャプチャします。

オンボックス レポート機能

オンボックスレポート機能では、以下がサポートされます。

• Sqlite3 support as a library—SQLログデータベース(SQLiteバージョン3)は、REで実行されているデーモンやその他の潜在的なモジュールによって使用され、SRXシリーズファイアウォールにログを保存します。

• Running llmd in both Junos OS and Linux OS—転送デーモン(flowd)は、バイナリログからデータベースインデックスをデコードし、インデックスとログの両方をローカルログ管理されたデーモン(llmd)に送信します。

• Storing of logs into specified table of the sqlite3 database by llmd— 新しいsyslogデーモンを導入して、SRXシリーズファイアウォール上のローカルログを収集し、データベースに保存します。

  Junos OSは、ログをデータベースファイル内の単一のテーブルではなく、複数のテーブルに保存します。各テーブルには、最も古いログと最新のログのタイムスタンプが含まれています。開始時刻と終了時刻に基づいてクエリを開始すると、llmd は最新のテーブルを見つけてレポートを生成します。

  データベース・テーブルに過去 10 時間に生成された 500 万個のログが含まれている場合、そのテーブルからレポートを生成するには 30 分以上かかることがあります。パフォーマンスを向上させるために、大きなテーブルは複数の小さなテーブルに分割され、それぞれに 50 万個のログが含まれているため、同じレポートを生成するには 1 つの小さなテーブルのみをクエリする必要があります。

  パフォーマンスを向上させるために、より短い時間でクエリを実行することをお勧めします。

  • Database table definition—セッションログの場合、データタイプは送信元アドレス、宛先アドレス、アプリケーション、ユーザーなどです。セキュリティ機能に関連するログの場合、データタイプは攻撃名、URL、プロファイルプロトコルなどです。そのため、パフォーマンスの向上とディスク容量の節約に役立つように、異なるテーブルでさまざまなタイプのログを格納するように設計されています。SRXシリーズファイアウォールは、ログデータが記録されるときに、ログタイプごとにデータベーステーブルを作成します。

    データベース表のタイプごとに、デバイス固有の最大レコード数があります。表レコード数が制限に達すると、新しいログが最も古いログに置き換わります。Junos OSは、アクティブなトラフィックが通過するデバイスにログインを保存します。

    データベースファイルに複数のテーブルを作成して、ログを保存できます。テーブルにログを保存する容量を定義できます。

    ログ数の制限がテーブルの容量を超えると、Junos OSはログを2番目のテーブルに保存します。例えば、表1のログの制限がテーブルの容量を超えた場合、Junos OSは表2にログを保存します。

    ログ数の制限がファイル 1 の最後のテーブルを超えると、Junos OS はファイル 2 のテーブル 1 にログを保存します。例えば、テーブルnはファイル1の最後のテーブルです。ログがテーブルの容量を超えると、Junos OSはファイル2のテーブル1にログを保存します。

    表番号を変更した後すぐに有効にするには、 clear security log report 操作コマンドを使用します。

  • Database table rotation—データベーステーブルの各タイプには、デバイス固有の最大レコード数があります。表レコード数が制限に達すると、新しいログが最も古いログに置き換わります。

    補足プラットフォーム情報では、データベースファイルの容量について説明します。

• Calculating and displaying the reports that are triggered by CLI—データベースからのレポートは、インターフェイスとしてのCLIから受信されます。CLIを使用して、レポートの詳細を計算して表示できます。

テーブルの選択

複数のテーブルからレポートを生成する場合、llmd はタイムスタンプに基づいてテーブルをソートし、要求された開始時刻と終了時刻に従ってテーブルを選択します。

例えば、表1(1〜3)、表2(3〜5)、表3(6〜8)の3つの表があります。1から3、3から6、および6から8は、最新および最も古いログのタイムスタンプを示します。4から6までのレポートをリクエストすると、Junos OSは表2と表3からレポートを生成します。

テーブルのライフタイム

set security log report table-lifetimeコマンドを設定することで、テーブルのライフタイムを決定できます。Junos OSは、テーブル識別時間がテーブルの有効期間を超えた後、テーブルを削除します。例えば、テーブルのライフタイムを2として設定し、現在の日付が2019年7月26日の場合、2019年7月24日00:00:00にログが削除されることを意味します。

デバイスで日付と時刻を手動で変更すると、テーブルの有効期間が変更されます。例えば、テーブル識別時刻が 2019 年 7 月 19 日で、テーブルのライフタイムを 10 として設定した場合、Junos OS は 2019 年 7 月 29 日にテーブルを削除する必要があります。デバイスの日付を18-July-2019に変更すると、テーブルの実際のライフタイムは30-July-2019になります。

テーブル密度モード

オンボックスのログデータベースのデフォルトのストレージと検索メカニズムをアップグレードして、ログを管理しました。ログストレージと検索メカニズムの結果をカスタマイズできるようになりました。例えば、トラフィックログが少ないことが予想される場合は、開始時刻と終了時刻を持つデフォルト設定を使用できます。

ただし、大量のトラフィックログと、ログが生成される時間間隔が長くなることが予想される場合は、高デンスモードを有効にします。デンスモードを有効にするには、 set security log report table-mode dense 設定コマンドを使用します。

注:

Junos OSリリース22.4以前からJunos OSリリース23.2以降にアップグレードする前に、 set security log report table-mode dense 設定を削除する必要があります。

シャーシクラスターのシナリオ

シャーシクラスターでのオンボックスレポートの場合、ログはデバイスがアクティブなトラフィックを処理しているローカルディスクに保存されます。これらのログは、シャーシ クラスター ピアには同期されません。

各ノードは、各ノードがアクティブなトラフィックを処理する際にログを保存する責任があります。アクティブ/パッシブモードの場合、アクティブノードのみがトラフィックを処理し、ログもアクティブノードにのみ保存されます。フェイルオーバーの場合、新しいアクティブノードがトラフィックを処理し、ローカルディスクにログを保存します。アクティブ/アクティブモードでは、各ノードが独自のトラフィックを処理し、ログはそれぞれのノードに保存されます。