ログの監視と収集

Pandora FMS ドキュメント一覧に戻る

Pandora FMS のログ監視により、ユーザは、ログが処理されたタイムスタンプを使用して情報を順番に整理し、キャプチャされた複数のソースからのすべてのログを単一のコンソールで参照できます。

この情報には構造や形式は含まれておらず、ファイルに元々付いていたタイムスタンプに加えて、タイムスタンプ (受信時刻) とともにテキスト形式で保存されます。

これらのログは、セキュリティイベント (SIEM) の生成や、トラブルシューティング、法令遵守、フォレンジック分析などに利用できます。ログ処理能力は、ログ保存に使用するデバイスの容量によってのみ制限されます。

• エンドポイントで分析されたログ (eventlog またはテキストファイル) は、Pandora サーバへ転送されます。エージェントから送信される XML に (RAW) データとして含まれます。
• Pandora FMS データサーバは、エージェントから XML を受け取ります。そこには、監視とログの両方の情報が含まれています。
• データサーバが XML データを処理する時に、ログ情報を識別し、報告されたエージェントに関する情報やログのソースをプライマリデータベースに保存し、ログの保存には情報を自動的に OpenSearch に送信します。
• Pandora FMS はデータを OpenSearch インデックスに保存し、各 Pandora FMS インスタンスの日次インデックスを生成します。
• Pandora FMS サーバには、システム管理者が定義した間隔(デフォルトでは30日)でインデックスを削除するメンテナンスタスクがあります。
• フォーマットの問題を回避するために、ログは符号化されてネットワークを通過します。
• ログを暗号化してネットワーク経由で送信したい場合は、安全なトランスポート (Tentacle の安全な通信) を使用できます。
• ログは Syslog によって Pandora FMS Syslog サーバに送信され、ローカル Syslog サーバからのログが直接処理されるため、処理速度が大幅に向上します。
• さまざまなエージェントとリモート Syslog サーバを使用して負荷を分散し、ネットワークトポロジに最​​適な分散と適合性を実現できます。

ログの表示を有効化するには、管理(Management) → セットアップ(Setup) → システム設定 → ログ収集(Log collector) へ行き、設定を有効化する必要があります。ログ収集の有効化(Activate Log Collector) をクリックし、更新(Update) をクリックします。

OpenSearch オプション セクションで次の値を設定する必要があります。

1. OpenSearch IP: Pandora FMS で使用する OpenSearch サーバーの IP アドレス。
2. https の利用(Use https): インストールした OpenSearch 環境において接続に HTTPS が有効になっている場合は有効にする必要があります。
3. OpenSearch ポート(OpenSearch Port): TCP のポート番号。
4. 古い情報を削除する日数(Days to purge old information): 収集したデータを削除するまでの日数。
5. 基本認証(Basic authentication): (オプション) OpenSearch に基本認証が設定されている場合 (推奨)、ユーザ (User) とパスワード (Password) を入力する必要があります。

• インデックスサイズ(Indexing size): このパラメータ値は、OpenSearch の ignore_above 設定 として使用されます。
• シャード数(Number of shards): インデックスが持つプライマリシャードの数。デフォルトでは 1 に設定されています。この設定はインデックス作成時にのみ設定できます。クローズされたインデックスでは変更できません。
• レプリカ数(Number of replicas): 各プライマリシャードが持つレプリカの数。デフォルトでは 1 に設定されています。警告: この値を 0 に設定すると、ノードの再起動時に一時的に可用性が低下したり、データ破損時に永続的なデータ損失が発生する可能性があります。
• レプリカの自動拡張(Auto expand replicas): クラスター内のデータノード数に基づいてレプリカ数を自動拡張します。下限と上限をダッシュ​​で区切って設定するか（例：0-5）、上限に「all」を使用します（例：0-all）。自動拡張されたレプリカ数は、割り当てフィルタリングルールのみを考慮し、ノードあたりのシャード数などの他の割り当てルールは無視されることに注意してください。そのため、該当するルールによってすべてのレプリカを割り当てられない場合、クラスターの状態が「黄色」になる可能性があります。

ログ収集は、Microsoft Windows® 用エージェントと Unix® エージェント (Linux®、MacOS X®、Solaris®、HPUX®、AIX®、BSD® など) の両方でエージェントを通じて行われます。

エージェントは、監視対象の各エンドポイントからローカル情報を収集するために使用されます。

イベント または プレーンテキスト (従来のログ) を収集できます。

Linux 構文と同様に、モジュールタイプ log はトークン module_regexp と一緒に使用されます。

MS Windows では、 module_pattern_exclude はサポートしていません。

# Logs extraction
module_begin
module_name Apache_log
module_description Logs extraction module
module_type log
module_regexp C:\server\logs\apache.log
module_source_type apache
module_pattern .*
module_end

この目的には、Microsoft Windows® 環境でのみ動作する特別な logchannel モジュールが使用されます。このモジュールを使用すると、イベントのソースと種類に応じて、特定のフィルターに基づいて MS Windows® イベントログから情報を取得できます。

このモジュールの一般的な形式:

module_begin
module_name MyEvent
module_type log
module_logchannel
module_source <logName>
module_eventtype <event_type/level (optional)>
module_eventcode <event_id (optional)>
module_application <source (optional)>
module_pattern <text substring to match (optional)>
module_source_type <siem log type (optional)>
module_end

重複した情報の表示を避けるため、エージェントが最後に実行されてから発生したイベントのみが考慮されます。そのため、初回実行時には、既存のイベントがすべて収集されるわけではありません。収集されたイベントは、初回実行時から送信され始めます。

以下のすべてのパラメータは、大文字と小文字を正しく入力する必要があります。

• module_source.
• module_source_type.
• module_eventtype.
• module_eventcode.
• module_application.

ログに記録されたイベントの生成元。アプリケーション名（イベントを取得する別の方法）を示す module_application と明確に区​​別することが重要です。module_application を使用する場合、これはオプションパラメータですが、どちらか一方を使用する必要があります。

これは MS Windows NT® の時代から続く古い分類です。最もよく知られているのは、システム、アプリケーション、セキュリティなど、数百あります。いずれにせよ、スペイン語では “Registro” または “Nombre de registro” という名前で表示されます。

つまり、このスクリーンショットでは “Sistema” のように見えますが、フィルタリングを可能にするキーは英語で表現する必要があります。この場合は “System” です。“Aplicación” ではなく “Application“、また ”Seguridad” ではなく “Security” です。その他の長いログ名はそのまま使用し、“System, Application, Security” のように、イベントを取得して表示できるように常に英語で記述する必要があります。

翻訳なしの長い名前の module_source の例:

Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Administración

SIEM 監視は収集されるログの種類に大きく依存するため、ログ収集モジュールで module_source_type を指定してその種類を指定する必要があります。この種類は decoders と rules で使用されるため、各ログで表示される種類を確認するには、有効な デコーダー と ルール を参照する必要があります。

最も一般的に使用されるログの種類は次のとおりです。

• syslog.
• ids.
• web-log.
• squid.
• host-information.
• ossec.

SIEM を介して Windows イベントを処理するには、ossec タイプを使用する必要があります。詳細については、SIEM 監視ドキュメント を参照してください。

これは、Windows のすべてのセキュリティ イベントを収集し、SIEM を通じて特定のセキュリティイベントを処理できるようにする具体的な例です。

# Security Events
module_begin
module_logchannel
module_name Security_Events
module_type log
module_source Security
module_source_type ossec
module_end

これは、イベントの種類（MS Windows®のバージョンによって異なります：Error, Warning, Information, Audit success, Audit failure…）をフィルタリングするために使用されるオプション属性です。これは、Windowsイベントビューアで確認できる値として表現されます。

この例では、レベル 3 (警告) の安全イベントが採用されます。

module_begin
module_logchannel
module_name Security_Events_Warning
module_type log
module_source Security
module_event_type 3
module_source_type ossec
module_end

オプションパラメータ。特定のイベントIDを使用して、そのIDを持つイベントのみをフィルタリングできます。おそらく最も正確なフィルタです。

このスクリーンショットでわかるように、イベントビューアーでは eventID が参照されています。

この例では、レベル 3 (警告) の安全イベントが採用されます。

module_begin
module_logchannel
module_name Security_Events_4798
module_type log
module_source Security
module_eventcodee 4798
module_source_type ossec
module_end

イベントの発生源。これはオプションのフィールドです。

イベントプロバイダーの名前を取得するには、詳細なイベントリストの name フィールドに表示されるイベントプロバイダーの正確な名前を指定する必要があります。これを行うには、Windowsイベントビューアで、イベントプロバイダーを右クリックし、プロパティ を選択し、module_application に必要なパラメータ Full name をコピーします（以下のスクリーンショットを参照）。

これらは、Windows イベントビューアーに表示されるベンダー名の一般的な例ですが、各アプリケーションが特定の名前を使用するため、さらに多くの例が存在する可能性があります。

オペレーティングシステムプロバイダー:

• Microsoft-Windows-Winlogon
• Microsoft-Windows-Security-Auditing
• Microsoft-Windows-User Profiles Service
• Microsoft-Windows-WindowsUpdateClient
• Microsoft-Windows-DNS-Client
• Microsoft-Windows-GroupPolicy
• Microsoft-Windows-TaskScheduler
• Microsoft-Windows-TerminalServices-LocalSessionManager
• Microsoft-Windows-Eventlog
• Microsoft-Windows-WMI
• Microsoft-Windows-Application-Experience
• Microsoft-Windows-PrintService
• Microsoft-Windows-Time-Service

一般的なアプリケーションまたはサービスプロバイダー:

• MSSQLSERVER
• Microsoft Outlook
• Microsoft Office Alerts
• VSS
• Microsoft Exchange Server
• Application Error
• Windows Defender
• Windows Firewall

高度な診断に関連するイベントの具体的な例:

• Microsoft-Windows-Kernel-General
• Microsoft-Windows-DistributedCOM
• Microsoft-Windows-Power-Troubleshooter
• Microsoft-Windows-Kernel-Boot
• Microsoft-Windows-Resource-Exhaustion-Detector
• Microsoft-Windows-Ntfs
• Microsoft-Windows-Kernel-Processor-Power

一般的なベンダーの例をいくつか示します (Microsoft 以外)。

• Google Chrome
• Mozilla Firefox
• VMware Tools
• Citrix Broker Service
• Oracle Database
• Symantec Endpoint Protection
• McAfee Security
• ESET Security
• Apache Service
• TeamViewer
• Adobe Acrobat
• Backup Exec
• Dropbox Update

これらのプロバイダは、Pandora FMS エージェントを通じてイベントを収集または除外するためのフィルタリング基準として機能します。スペースが含まれる場合でも、引用符を使用しないでください。例えば、“Pandora FMS” の場合は以下のようになります。

module_begin
module_name Pandora_Events_Windows
module_type log
module_logchannel
module_application Pandora FMS
module_source Application
module_end

• Sysmon とは?

Sysmon(システムモニター) は、Microsoft が Sysinternals Tools の一部として開発した無料のツールで、Windows オペレーティングシステムでの詳細なイベントの監視とログ記録を大幅に改善するように設計されています。

その主な目的は、システムとアプリケーションのセキュリティに関連するアクティビティを記録することです。これらのアクティビティは通常、標準のイベントビューアーでは十分な詳細が記録されません。

• Sysmon の用途は?

Sysmon は、次のような主要なシステムイベントを包括的に記録することで、セキュリティインシデントの監視と早期検出に主に焦点を当てています。

1. プロセスの作成と実行。
2. ネットワーク接続（受信および送信）。
3. Windows レジストリの変更。
4. DLL ライブラリの読み込み。
5. ファイルへのアクセスと変更。
6. 不審なメモリおよびプロセスの使用。
7. 正規のプロセスへのコードインジェクション。

これらのアクティビティは通常、マルウェアや攻撃者によって企業ネットワークへの侵入試行やネットワーク内での拡大に悪用されます。

• Sysmon はどのように動くのか?

Sysmonは、カーネルモードでドライバーをインストールすることで動作し、オペレーティングシステムのアクティビティに関するリアルタイム情報を収集します。収集されたデータは、Windowsイベントビューアー（Event Viewer）に送信されます。

• Sysmon は Pandora FMS による監視をどのように改善しますか?

Pandora FMS は Windows エージェントを使用して、これらの詳細なイベントを Sysmon チャネルから直接収集し、Pandora 中央サーバに送信できます。

この組み合わせたアプローチ (Sysmon + Pandora FMS + Pandora SIEM) は、Windows ベースのホストの監視とセキュリティに大きな利点をもたらします。

1. 詳細なセキュリティ可視性：従来のイベントログをはるかに凌駕する詳細な情報を提供します。疑わしい動作を包括的に分析し、異常や潜在的な脅威をリアルタイムで特定できます。
2. 高度な攻撃の早期検知：ラテラルムーブメント、悪意のあるスクリプトの実行、疑わしいサーバへの接続といった高度な攻撃を容易に検知できます。
3. 即時対応機能：Pandora FMSは、Sysmonイベントで定義されたルール（疑わしいプロセスの実行、ログへのアクセス、異常な接続試行など）に基づいて自動アラートを生成できます。
4. 履歴と相関分析：Pandora FMSは、Sysmonによって長期間にわたって生成された履歴イベントを保存、参照、相関分析できます。これは、フォレンジック調査やセキュリティ監査に不可欠です。
5. 高度なレポート：自動抽出機能により、サイバーセキュリティ監査、コンプライアンス、インシデント事後分析用のレポートを簡単に作成できます。

• 統合の実例

Pandora エージェントを通じて Sysmon アラートが送信され、次のような内容を示しているとします。

1. 不明なプロセスが疑わしいIPアドレスへの送信接続を作成した。
2. 不明なDLLがメモリにロードされた。
3. 予期しないプロセスによってWindowsレジストリが変更されようとした。
4. Pandora FMS はこれらの詳細なイベントを受信し、即座にアラートを生成し、重大な損害が発生する前にインシデントに迅速に対応できるようにします。

• Sysmon のインストールと使用

Sysmon は、Microsoft 公式の “Sysinternals Suite” に含まれており、Intel 32 ビットおよび 64 ビット システム、および新しい ARM 64 ビット アーキテクチャ (Windows 11) でも利用できます。

Sysmon は、何を「監視」すべきかを指定するための、かなり詳細な設定ファイルを持っています。「すべて」を監視すると、ホストのパフォーマンスと、このすべての情報を収集するシステムの両方に影響を与えます。Pandora FMS エージェントには、ユーザが変更できる基本設定ファイルが組み込まれており、デフォルトでは多くのセキュリティ情報が生成されます。

Sysmon の使用方法の詳細については、ドキュメント SIEM を参照してください。

module_begin
module_name WinEvtLog
module_type log
module_logchannel
module_source Microsoft-Windows-Sysmon/Operational
module_source_type windows
module_end

他のイベントとは異なり、このイベントでは module_source_type ossec ではなく module_source_type windows を使用します。また、Pandora SIEM に付属のSIEMルールで定義されている WinEvtLog という名前を使用します。他の名前やタイプを使用した場合、期待どおりに動作しません。

ログの例:

module_begin
module_name Syslog
module_description Sample log collection of syslog messages file
module_type log
module_regexp /var/log/messages
module_pattern .*
module_pattern_exclude DEBUG
module_end

ログタイプモジュールの説明の詳細については、特定のディレクティブの章を参照してください。

このタイプのタグ module_type log を定義することで、データベースに保存されず、ログコレクターに送信されることを示します。このタイプのデータを持つモジュールは、ログコレクターが有効になっている限り、すべてログコレクターに送信されます。有効になっていない場合、情報は破棄されます。

より完全な例:

module_begin
module_name apache_access
module_type log
module_regexp /var/log/httpd/access_log
module_pattern .*
module_pattern_exclude \s200\s|\s301\s
module_source_type web-log
module_end

module_begin
module_name Audit denied
module_type log
module_regexp /var/log/audit/audit.log
module_pattern denied
module_end

module_begin
module_name Syslog
module_type log
module_regexp /var/log/messages
module_pattern error|fail|panic|segfault|denied|timeout|critical|alert|emergency|memory|core_dumped|failure|attack|bad|illegal|refused|unauthorized|fatal|failed|Segmentation|Corrupted
module_end

module_begin
module_name Secure
module_type log
module_regexp /var/log/secure
module_pattern Failed|failure|invalid|denied|accepted|root
module_end

このコンポーネントにより、Pandora FMS は、それが配置されているマシンの syslog を分析し、その内容を対応する OpenSearch サーバに保存できるようになります。

Syslog サーバの主な利点は、ログの統合を補完することです。Syslog サーバの Linux® および Unix® 環境からのエクスポート機能によってサポートされているため、Syslog サーバでは、ソースに関係なくログを照会し、単一の共通ポイント (Pandora FMS コンソールログビューア) で検索できます。

Syslog サーバ 8.2102 のインストールは、クライアントとサーバの両方で実行する必要があります。

dnf install rsyslog

設定ファイル /etc/rsyslog.conf にアクセスして、TCP および UDP 入力を有効にします。

  (...)

# Provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")

# Provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")

  (...)

rsyslog サービスを再起動します。サービスが利用可能になったら、次のコマンドでポート 514 にアクセスできることを確認します。

netstat -ltnp

クライアント側 では、Syslog サーバにログを送信できるように rsyslog を設定します。/etc/rsyslog.conf にてリモートホストを設定する行を見つけて有効にします (remote-host をサーバの IP アドレスに変更します)。

action(type="omfwd" Target="remote-host" Port="514" Protocol="tcp")

rsyslog が受信するログのサイズは、デフォルトでは 8 キロバイトです。これより大きなログを受信すると、完全なログが受信されるまで、残りのコンテンツを含む新しいエントリが追加されます。これらの新しいエントリには、ログを送信したホストの名前が含まれていないため、この動作により、コンソールに新しい不要なログソースと新しいエージェントの両方が作成されることがあります。これを回避するには、次の行を追加して、受信するログのサイズを増やすことをお勧めします。

$MaxMessageSize 512k

ファイルを保存してテキストエディタを終了します。

Pandora FMS サーバでこの機能を有効にするには、pandora_server.conf ファイルで 次の内容 を有効にします。

# Enable (1) or disable (0) the Pandora FMS Syslog Server
syslogserver 1

# Full path to syslog's output file.
syslog_file /var/log/messages

# Number of threads for the Syslog Server
syslog_threads 2

# Maximum number of lines queued by the Syslog Server's
syslog_max 65535

Pandora FMS サーバでは、トークン syslog_whitelist を使用して、大文字と小文字を区別する正規表現または regexp に一致するログのみを 許可 し (たとえば、windows は Windows と同じではありません)、それ以外を破棄 することができます。

トークン syslog_blacklist を使用すると、設定された regexp に一致するログを 拒否 することができます (その他はすべて許可)。

両方のトークンはデフォルトで無効になっています。

• syslog_whitelist: このトークンを有効にすると、regexp に準拠するログのみが受け入れられ、残りは破棄されます。
  • このトークンが有効化され、デフォルトのフィルタ .* が設定されている場合は、すべてが受け入れられます。
  • 重要: 上記のトークンが正規表現なしで有効化されると、何も許可されません。
• 許可されたキーワードのフィルタリングが最初に実行されるため、次のステップの作業が削減されます。
• syslog_blacklist: regexp を配置すると、それに準拠するすべてのものが破棄されます (このトークンが有効化されていても、regexp がない状態の場合は、何もブロックされません)。
• syslog_blacklist によるフィルタリングは最後に行われます。

ログ収集ツールでは、主に 2 つの機能が重要です。情報の検索機能 (日付、データソース、キーワードなどでフィルタリング) と、時間単位ごとの発生回数で描画された情報の表示機能 (メニュー 操作(Operation) → モニタリング(Monitoring) → ログビューア(Log viewer)) です。

最も重要かつ便利なフィールドは、検索(Search) テキストボックスに入力する検索文字列と、使用可能な 3 つの検索タイプ (検索モード(Search mode)) の組み合わせです。

• 完全一致(Exact match): リテラル文字列検索。ログには完全一致が 含まれます。
• すべての単語(All words): 同じログ行内の順序に関係なく、指定された単語をすべて含む検索を行います。
• 任意の単語(Any word): 順序に関係なく、指定された単語の いずれか を含むものを検索します。
• フィルタリングされたコンテンツのコンテキストを表示するオプションをオンにすると、検索に関連する他のログ行の情報とともに状況の概要が表示されます。

この機能を使用すると、データキャプチャモデル に基づいて情報を分類し、ログエントリをグラフィカルに表示できます。

これらのデータキャプチャモデルは基本的に、データソースを解析してグラフとして表示できる正規表現と識別子です。

高度なオプションにアクセスするには、高度なオプション(Advanced options) をクリックします。結果の表示タイプを選択できるフォームが表示されます。

• ログエントリを表示します（プレーンテキスト）。
• ロググラフを表示します。
• ロググラフの表示オプション (表示モード) を使用して、キャプチャモデル (キャプチャモデルの使用(Use capture model)) を選択できます。
• デフォルトモデルである Apache ログモデルでは、Apache ログを標準形式 (access_log) で処理または解析し、応答時間の比較グラフを取得したり、アクセスしたページと応答コード別にグループ化したりできます。
• 新しいキャプチャ モデルを作成するには、[編集] または [作成] をクリックします。

このオプションを使用すると、頻繁に使用するフィルタリング設定を保存し、フィルターリストを作成できます。すべてのフィルター値を設定したら、フィルタを保存(Save filter) をクリックして名前を付けます。その後、保存(Save) をクリックして設定や変更を保存できます（既存のフィルタに保存することもできます）。

それ以外の場合は、フィルタ読み込み(Load filter) をクリックして保存済みのフィルターのリストをドロップダウンすることで、これらの設定をいつでも読み込むことができます。フィルターを1つ選択し、フィルタ読み込み(Load filter) をクリックしてください。

PFMS アンカーシステムを使用すると、セクションタイトルにあるピン留めアイコン をクリックすることで、フィルター設定を含む ログビューア へのショートカットを保存できます。

フィルターが再読み込みされると、 アイコンが表示され、クリックすると、ピン留めされたアイテムからフィルターが削除されます。

Pandora FMS バージョン 749 以降、ログソース状態 と呼ばれるボックスがエージェント表示に追加され、そのエージェントによる最後のログ更新の日付が表示されます。虫眼鏡のアイコンをクリックすると、そのログにフィルタしたログビューワ表示にリダイレクトされます。

Pandora FMS ドキュメント一覧に戻る