SIEM 監視

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

The acronym SIEM stands for Security Information and Event Management. SIEM describes security monitoring features by collecting, filtering, normalizing, correlating and visualizing security events. It combines security information management (SIM) with security event management (SEM).

SIEM は Security Information and Event Management の略です。SIEM は、セキュリティイベントの収集、フィルタリング、正規化、相関分析、可視化といった セキュリティ監視 機能を表します。SIEM は、セキュリティ情報管理 (SIM) とセキュリティイベント管理 (SEM) を組み合わせたものです。

SIEM manages security events, which may come from an ordinary log (e.g. Apache logs), from the log of a specific security tool (logs of a firewall, IDS, honeypot, EDR, et cetera) or enriched events from another tool (another SIEM).

SIEM は、通常のログ (Apache ログなど)、特定のセキュリティツールのログ (ファイアウォール、IDS、ハニーポット、EDR などのログ)、または別のツール (別の SIEM) からの強化されたイベントから取得されるセキュリティイベントを管理します。

As with log collection, the generated SIEM events are stored in OpenSearch®, so the first requirement to make this monitoring work is to have an OpenSearch installation.

ログ収集と同様に、生成された SIEM イベントは OpenSearch® に保存されるため、この監視を機能させるための最初の要件は OpenSearch インストール です。

Pandora FMS SIEM generates security events using two components in the server, so events are also generated in two steps:

Pandora FMS SIEM は、サーバ内の 2 つのコンポーネントを使用してセキュリティイベントを生成するため、イベントも 2 つのステップで生成されます。

• Data standardization: All log collection entries are decoded, generating new normalized log entries that are stored temporarily.
• Event generation: Normalized logs are checked for compliance with a set of rules, in which case a SIEM event is generated with all the rule information and the normalized log that generated the event.

• データ標準化: すべてのログ収集エントリがデコードされ、新しい正規化されたログエントリが生成され、一時的に保存されます。
• イベント生成: 正規化されたログは、一連のルールに準拠しているかどうかがチェックされます。準拠している場合は、すべてのルール情報とイベントを生成した正規化されたログを含む SIEM イベントが生成されます。

Thus the complete flow for SIEM monitoring is:

したがって、SIEM 監視の完全なフローは次のようになります。

• Agents, plugins and other sources of information monitor or generate logs that are sent to the dataserver or syslogserver.
• dataserver and syslogserver take care of processing these log entries and store them on the OpenSearch server configured for log collection.
• siemserver decodes all logs obtained through log collection to generate normalized logs on the OpenSearch server configured for SIEM monitoring. These normalized logs are stored temporarily.
• siemevents processes each of the normalized logs and if they meet a set of predefined rules, SIEM events are generated and stored on the OpenSearch server configured for SIEM monitoring.

• エージェント、プラグイン、その他の情報ソースは、ログを監視または生成し、「dataserver」または「syslogserver」に送信されます。
• dataserver と syslogserver はこれらのログエントリを処理し、ログ収集用に設定された OpenSearch サーバに保存します。
• siemserver は、ログ収集で取得したすべてのログをデコードし、SIEM 監視用に設定された OpenSearch サーバ上に正規化されたログを生成します。これらの正規化されたログは一時的に保存されます。
• siemevents は、正規化された各ログを処理し、事前定義された一連のルールを満たす場合、SIEM イベントを生成して、SIEM 監視用に設定された OpenSearch サーバに保存します。

With the events generated, it is possible to check them for their operation from Pandora FMS Console.

生成されたイベントは、Pandora FMS コンソールから操作を確認できます。

To use SIEM event monitoring, it must first be activated from the main configuration.

SIEM イベント監視を使用するには、まずメイン設定から有効化する必要があります。

Go to menu Management → Settings → System Settings → SIEM → Activate SIEM, fill in the form completely and click Update to save the changes.

メニュー 管理(Management) → セッティング(Settings) → システム設定(System Settings) → SIEM → SIEM の有効化(Activate SIEM) に移動し、フォームをすべて入力して 更新(Update) をクリックして変更を保存します。

This will create the necessary templates on the OpenSearch server specified for log normalization and SIEM event generation.

これにより、ログの正規化と SIEM イベント生成用に指定された OpenSearch サーバに必要なテンプレートが作成されます。

It will also activate this type of monitoring in Pandora FMS servers where siemserver and siemevents were started.

また、siemserver および siemevents が開始された Pandora FMS サーバでもこのタイプの監視が有効になります。

To perform SIEM event monitoring, activate siemserver and siemevents servers in server configuration.

SIEM イベント監視を実行するには、サーバ設定 で siemserver および siemevents サーバを有効にします。

In order to decode and normalize log collection entries, it will be necessary to have decoding XML files that establish the way to obtain the necessary information in each case (hereinafter, “decoders”). These XML files will be located in the path indicated by the siem_decoders parameter of the server configuration, by default in:

ログ収集エントリをデコードおよび正規化するには、各ケースで必要な情報を取得する方法を確立するデコード XML ファイル（以下、「デコーダー」）が必要です。これらの XML ファイルは、サーバ設定の siem_decoders パラメータで指定されたパスに配置されます。デフォルトでは以下のパスです。

/usr/share/pandora_server/util/siem/decoders

In order to generate SIEM events, it will be necessary to have rules XML files that set the conditions to generate an event based on the information obtained in normalized logs (hereinafter, “rules”). These XML files will be located in the path indicated by the siem_events_rules parameter of the server configuration, by default in:

SIEM イベントを生成するには、正規化されたログから取得した情報に基づいてイベントを生成する条件を設定したルール XML ファイル（以下、「ルール」）が必要です。これらの XML ファイルは、サーバ設定の siem_events_rules パラメータで指定されたパスに配置されます。デフォルトでは以下の場所にあります。

/usr/share/pandora_server/util/siem/rules

Most of the log collection is done through Pandora FMS EndPoints. These agents, both in GNU/Linux® and MS Windows® systems, have specific types of modules to perform this task.

ログ収集の大部分は Pandora FMS エンドポイントを通じて行われます。GNU/Linux® と MS Windows® の両方のシステムで動作するこれらのエージェントには、このタスクを実行するための特定の種類のモジュールが搭載されています。

SIEM monitoring relies heavily on the type of log collected, so it will be necessary to specify module_source_type in log collection modules to indicate that type.

SIEM 監視は収集されたログの種類に大きく依存するため、その種類を示すにはログ収集モジュールで module_source_type を指定する必要があります。

The type is used by decoders and rules, so the active decoders and rules must be checked to know the type to be indicated in each log.

タイプは デコーダー と ルール によって使用されるため、各ログに示されるタイプを確認するには、アクティブな デコーダー と ルール をチェックする必要があります。

The most commonly used types of logs are:

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

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

Log collection on Linux systems is mainly done by reading log files. This can be achieved by using module configurations with this minimal structure:

Linux システムにおけるログ収集は、主にログファイルの読み取りによって行われます。これは、以下の最小限の構造を持つモジュール設定を使用することで実現できます。

module_begin
module_name <program_name>
module_type log
module_regexp <path_to_log_file>
module_pattern <capture_regexp>
module_source_type <log_type>
module_end

For example, to collect all access log entries from an Apache server:

たとえば、Apache サーバからすべてのアクセスログエントリを収集するには、次のようにします。

module_begin
module_name apache
module_type log
module_regexp /var/log/httpd/access_log
module_pattern .*
module_source_type web-log
module_end

Entries collected from a log like the above would be normalized by decoders such as web-accesslog, web-accesslog-ip or web-accesslog-domain among others.

上記のようなログから収集されたエントリは、web-accesslog、web-accesslog-ip、web-accesslog-domain などの デコーダー によって正規化されます。

The decoded logs of such a log could generate events such as Common\_web\_attack, XSS\_(Cross\_Site\_Scripting)\_attempt or SQL\_injection\_attempt among others.

このようなログのデコードされたログでは、Common\_web\_attack、XSS\_(Cross\_Site\_Scripting)\_attempt、SQL\_injection\_attempt などのイベントが生成される場合があります。

Log collection in MS Windows® is mainly done by monitoring system events, although it can also be done by reading log files as in Linux systems.

MS Windows® でのログ収集は主にシステムイベントの監視によって行われますが、Linux システムのようにログファイルを読み取ることによっても行うことができます。

Using the Windows event system, these logs may be collected by using module configurations with one of these two minimum configurations.

Windows イベントシステムを使用すると、これらの 2 つの最小構成のいずれかを含むモジュール設定を使用して、これらのログを収集できます。

If the events are either Application, System or Security:

イベントが Application、System、または Security のいずれかの場合:

module_begin
module_name <module_name>
module_type log
module_logchannel
module_source <Application|System|Security>
module_source_type <log_type>
module_end

Or if they are events belonging to a different channel:

または、別のチャネルに属するイベントの場合:

module_begin
module_name <module_name>
module_type log
module_logchannel
module_source <log_channel_path>
module_source_type <log_type>
module_end

For example, to collect all Security and Windows Defender event entries:

たとえば、すべての Security および Windows Defender イベントエントリを収集するには、次のようにします。

module_begin
module_name Windows_LogEvents_System
module_type log
module_logchannel
module_source Security
module_source_type ossec
module_end

module_begin
module_name Windows_LogchannelEvents_WindowsDefender
module_type log
module_logchannel
module_source Microsoft-Windows-Windows Defender/Operational
module_source_type ossec
module_end

Inputs collected from events such as the above would be normalized by decoders as windows_eventchannel.

上記のようなイベントから収集された入力は、デコーダー によって windows_eventchannel として正規化されます。

The decoded logs of events such as the above could generate events such as Windows\_error\_event, Short-time\_multiple\_Windows\_Defender\_warning\_events or Multiple\_Windows\_Defender\_error\_events among others.

上記のようなイベントのデコードされたログでは、Windows\_error\_event、Short-time\_multiple\_Windows\_Defender\_warning\_events、Multiple\_Windows\_Defender\_error\_events などのイベントが生成される場合があります。

Using log file monitoring, the configuration is identical to that of Linux systems. A minimal configuration like this is required:

ログファイル監視を使用する場合、設定は Linux システムと同じです。次のような最小限の設定が必要です。

module_begin
module_name <program_name>
module_type log
module_regexp <path_to_log_file>
module_pattern <capture_regexp>
module_source_type <log_type>
module_end

For example, to collect all log entries of an X server:

たとえば、X サーバのすべてのログ エントリを収集するには、次のようにします。

module_begin
module_name xserver
module_type log
module_regexp C:\server\logs\xserver.log
module_pattern .*
module_source_type xserver
module_end

With SIEM monitoring enabled and configured, a preview of the monitoring status may be accessed in the Operation → SIEM → Dashboard menu.

SIEM 監視を有効にして設定すると、操作(Operation) → SIEM → ダッシュボード(Dashboard) メニューで監視ステータスのプレビューにアクセスできるようになります。

Generated SIEM events can be fuly displayed in menu Operation → SIEM → Events.

生成された SIEM イベントは、メニュー 操作(Operation) → SIEM → イベント(Events) ですべて表示できます。

Each SIEM event will have a window with the event details, showing information of the normalized log and the rule that generated the event.

各 SIEM イベントにはイベントの詳細を示すウィンドウがあり、正規化されたログの情報とイベントを生成したルールが表示されます。

Depending on the decoders that normalized the log, the event will have Dynamic fields tab with useful log information.

ログを正規化した デコーダー に応じて、イベントには、役立つログ情報を含む 動的フィールド(Dynamic fields) タブが表示されます。

Depending on the rule that generated the event, there will be MITRE ATT&CKS® and SIEM groups tabs with useful information on the impact of the event.

イベントを生成したルールに応じて、MITRE ATT&CKS® および SIEM グループ(SIEM groups) タブが表示され、イベントの影響に関する有用な情報が表示されます。

Pandora FMS includes a series of decoders by default for SIEM monitoring, but any administrator may include their own.

Pandora FMS には、SIEM 監視用の一連の デコーダー がデフォルトで含まれていますが、管理者は独自のデコーダーを追加できます。

To include new decoders, first add or edit an XML file in the path indicated to Pandora FMS server in its configuration parameter siem_decoders.

新しい デコーダー を追加するには、まず Pandora FMS サーバ の設定パラメータ siem_decoders に指定されたパスにある XML ファイルを追加または編集します。

Decoders are loaded into the environment via XML files that Pandora FMS master server reads at each service startup.

デコーダーは、Pandora FMS マスター サーバが各サービスの起動時に読み取る XML ファイルを介して環境にロードされます。

Once decoders are loaded, their configuration is stored in the database, and each siemserver processes them for entries obtained through log collection.

デコーダーがロードされると、その設定がデータベースに保存され、各 siemserver はログ収集を通じて取得されたエントリに対してそれらを処理します。

From Pandora FMS Console, it will be possible to view the loaded decoders with their complete configuration from menu Operation → SIEM → Decoders.

Pandora FMS コンソールでは、メニュー 操作(Operation) → SIEM → デコーダー(Decoders) から、ロードされた デコーダー とその完全な設定を表示できます。

It is also possible to disable decoders from this view, so that siemserver does not take them into account when normalizing log entries.

このビューから デコーダー を無効にすることもできます。これにより、siemserver はログ エントリを正規化するときにデコーダーを考慮しなくなります。

Decoders are configured and loaded in Pandora FMS with XML files. These files may have the following valid syntax:

デコーダーは、Pandora FMS で XML ファイルを使用して設定およびロードされます。これらのファイルの有効な書式は次のとおりです。

<var name="VarName">VarValue</var>
 
<decoder name="DecoderName" discard="yes|no">
    <parent>DecoderName</parent>
    <program_name>REGEXP</program_name>
    <type>EventType</type>
    <prematch type="pcre2">REGEXP</prematch>
    <prematch offset="after_parent">REGEXP</prematch>
    <prematch offset="after_prematch">REGEXP</prematch>
    <regex type="pcre2">REGEXP</regex>
    <regex offset="after_parent">REGEXP</regex>
    <regex offset="after_regex">REGEXP</regex>
    <order>Field1, Field2.Sub1, Field2.Sub2</order>
    <json_null_field>string|discard</json_null_field>
</decoder>

↑Full syntax

↑書式

Used to indicate variables with their values, and use them later in XML ($VarName).

変数とその値を示すために使用され、後で XML で使用されます ($VarName)。

<var name="VarName">VarValue</var>

↑Full syntax

↑書式

It is the decoder information, with its name. The XML file itself may contain several.

これはデコーダー情報とその名前です。XMLファイル自体に複数のデコーダーが含まれる場合があります。

• name: It is the name of the decoder. Several decoders may have the same name, and they are all evaluated.
• discard: With a yes or no value, it allows to discard logs from the decoder evaluation if they match this one. Decoders with discard=“yes” are evaluated before the rest (as long as they do not have a parent decoder).

• name: デコーダー の名前です。複数の デコーダー が同じ名前を持つ場合、それらはすべて評価されます。
• discard: yes または no の値を指定すると、この値に一致するログを デコーダー の評価から破棄するかどうかを指定します。discard=“yes” が指定された デコーダー は、他のものより先に評価されます (親 デコーダー がない限り)。

<decoder name="DecoderName" discard="yes|no">
  …
  …
  …
</decoder>

↑Full syntax

↑書式

It specifies the name of the parent decoder to generate a hierarchical structure.

階層構造を生成するために親 デコーダー の名前を指定します。

    <parent>DecoderName</parent>

↑Full syntax

↑書式

The name of the program to be found in the log headers or in the source_id of the log.

ログヘッダーまたはログの source_id で見つかるプログラムの名前。

• type: It allows you to specify the type of regular expression. If not specified, OS Regex is used.

• type: 正規表現の種類を指定します。指定がない場合は、OS Regex が使用されます。

    <program_name>REGEXP</program_name>

As the case may be, it is specified for PCRE2:

場合によっては、PCRE2 で次のように指定されます。

    <program_name type="pcre2">REGEXP</program_name>

↑Full syntax

↑書式

The type of logs for which the decoder will be compared. It must match the log type.

デコーダーが比較するログの種類。ログの type と一致する必要があります。

    <type>EventType</type>

↑Full syntax

↑書式

If the contents of the log match this, it generates a normalized log.

ログの内容がこれに一致する場合、正規化されたログが生成されます。

• type: It allows you to specify the type of regular expression. If not specified, OS Regex is used.
• See offset.

• type: 正規表現の種類を指定します。指定がない場合は、OS Regex が使用されます。
• offset を参照してください。

    <prematch type="pcre2">REGEXP</prematch>
    <prematch offset="after_parent">REGEXP</prematch>
    <prematch offset="after_prematch">REGEXP</prematch>

↑Full syntax

↑書式

Groups captured with this regular expression are normalized information for the log.

この正規表現でキャプチャされたグループは、ログの正規化された情報です。

• type: It alows you to specify the type of regular expression. If not specified, OS Regex is used.
• See offset.

• type: 正規表現の種類を指定します。指定がない場合は、OS Regex が使用されます。
• offset を参照してください。

    <regex type="pcre2">REGEXP</regex>
    <regex offset="after_parent">REGEXP</regex>
    <regex offset="after_regex">REGEXP</regex>

↑Full syntax

↑書式

Values captured by regex are stored in these field names, sorted by capture groups.

regex によってキャプチャされた値は、キャプチャグループによってソートされてこれらのフィールド名に格納されます。

    <order>Field1, Field2.Sub1, Field2.Sub2</order>

↑Full syntax

↑書式

Null values of the capture groups will be stored as empty strings or discarded.

キャプチャグループの null 値は空の文字列として保存されるか、破棄されます。

    <json_null_field>string|discard</json_null_field>

↑Full syntax

↑書式

It is used to indicate the order in which checks are performed and to discard from the log content for the following checks the text that matches the regular expression: after_parent, after_regex, after_prematch. For example:

これは、チェックの実行順序を示すために使用され、以下のチェックにおいて正規表現 after_parent、after_regex、after_prematch に一致するテキストをログコンテンツから削除します。例：

<decoder name="my_decoder">
  <prematch type="pcre2">^\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d </prematch>
  <regex type="pcre2" offset="after_prematch">(\w):(\d+)</regex>
  <order>srcip,srcport</order>
</decoder>

It will check that the text in the log matches the regular expression ^\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d , will discard that content of the text and when evaluating the regex, it will capture accordingly. In the example, it would remove a date from the text when evaluating to simplify the capture groups.

ログ内のテキストが正規表現 ^\d\d\d\d/\d\d/\d\d \d\d​​:\d\d:\d\d に一致するかどうかを確認し、テキストの該当部分を破棄して、regex を評価する際にそれに応じたキャプチャ処理を行います。この例では、キャプチャグループを簡素化するために、評価時にテキストから日付を削除します。

Pandora FMS includes a set of default rules for SIEM monitoring, but any administrator may include their own.

Pandora FMS には SIEM 監視用のデフォルトの ルール セットが含まれていますが、管理者は独自のルールを追加できます。

To include new rules, first add or edit an XML file in the path indicated to Pandora FMS server in its configuration parameter siem_rules.

新しい ルール を含めるには、まず、設定パラメータ siem_rules で Pandora FMS サーバに指定されたパスにある XML ファイルを追加または編集します。

Rules are loaded into the environment by means of XML files that Pandora FMS master server reads at each service start.

ルールは、Pandora FMS マスター サーバが各サービスの起動時に読み込む XML ファイルによって環境にロードされます。

Once rules are loaded, their configuration is stored in the database, and each siemevents server processes them for normalized entries in SIEM monitoring.

ルールがロードされると、その設定がデータベースに保存され、各 siemevents サーバはそれを SIEM 監視の正規化されたエントリとして処理します。

From Pandora FMS console, it will be possible to see loaded rules with their full configuration fom menu Operation → SIEM → Rules.

Pandora FMS コンソールでは、メニュー 操作(Operation) → SIEM → ルール(Rules) から、読み込まれた ルール とその完全な設定を確認できます。

It is also possible to disable rules from this view, so that siemevents does not take them into account when processing normalized logs.

このビューから ルール を無効にして、正規化されたログを処理するときに siemevents がそれらを考慮しないようにすることもできます。

Rules that could not be read from the XML files will be marked in the Console as “not active” and will not be taken into account when generating SIEM events. Rules that were manually disabled by an administrator will not be taken into account either. Therefore, for rules to be evaluated, they must be active and enabled.

XMLファイルから読み取れなかったルールは、コンソールで「無効」とマークされ、SIEM イベントの生成時に考慮されません。管理者によって手動で無効化されたルールも考慮されません。したがって、ルールを評価するには、ルールがアクティブかつ有効化されている必要があります。

Rules are classified in several levels, ranging from the lowest (0) to the highest (15). The following table describes each level, providing information on the severity of each event generated by SIEM monitoring.

ルールは、最低レベル（0）から最高レベル（15）まで、複数のレベルに分類されます。以下の表は各レベルについて説明し、SIEM 監視によって生成される各イベントの重要度に関する情報を提供します。

Based on these levels, events will have a specific severity that will be displayed on the console:

これらのレベルに基づいて、イベントには特定の重要度が与えられ、コンソールに表示されます。

• Informational: Levels from 0 to 6.
• Normal: Levels from 7 to 8.
• Warning: Levels from 9 to 11.
• Critical: Levels from 12 to 15.

• 情報(Informational): レベル 0 から 6。
• 正常(Normal): レベル 7 から 8。
• 警告(Warning): レベル 9 から 11。
• 障害(Critical): レベル 12 から 15。

Detailed syntax elements

詳細書式要素

<var name="VarName">VarValue</var>
 
<group name="GROUP1,GROUP2,">
    <rule id="N" level="N" frequency="N" timeframe="N" ignore="N" overwrite="yes|no">
        <if_matched_sid>N</if_matched_sid>
        <if_matched_group>GROUP</if_matched_group>
        <same_id />
        <different_id />
        <same_field>Field1</same_field>
        <same_field>Field2.Sub1</same_field>
        <different_field>Field1</different_field>
        <different_field>Field2.Sub1</different_field>
        <description>TEXT</description>
        <match type="pcre2">RREGEXP</match>
        <match negate="yes|no">RREGEXP</match>
        <regex type="pcre2">RREGEXP</regex>
        <regex negate="yes|no">RREGEXP</regex>
        <decoded_as>DecoderName</decoded_as>
        <category>EventType</category>
        <field name="Field1">REGEXP</field>
        <field name="Field2.Sub1" negate="yes|no">REGEXP</field>
        <program_name negate="yes|no">REGEXP</program_name>
        <time>TIME-RANGE</time>
        <weekday>DAYS</weekday>
        <if_sid>PARENT1, PARENT2</if_sid>
        <if_group>GROUP</if_group>
        <if_level>N</if_level>
        <info type="text|link|cve">TEXT|LINK|CVE</info>
        <group>GROUP1,GROUP2,</group>
        <mitre>
            <id>MITRE_ID</id>
            <id>MITRE_ID</id>
        </mitre>
    </rule>
</group>

See also Case study.

ケーススタディも参照してください。

↑Complete syntax.

↑完全な書式

<var name="VarName">VarValue</var>

Used to indicate variables with their values, and use them later in XML ($VarName).

変数とその値を示すために使用され、後で XML で使用されます ($VarName)。

↑Complete syntax.

↑完全な書式.

<group name="GROUP1,GROUP2,">
…
</group>

It allows rule grouping. It is also used for conditions of the same rules.

rule によるグループ化が可能です。また、同じルールの条件にも使用されます。

↑Complete syntax.

↑完全な書式

    <rule id="N" level="N" frequency="N" timeframe="N" ignore="N" overwrite="yes|no">
    …
    </rule>

It is the information in the rule:

ルール内の情報は次のとおりです。

1. id: Rule identifier. It must be unique (unless another rule is overwritten).
2. level: Level of the event when generated (0 to 15). Rules with level 0 do not generate an event.
3. frequency: Times that a concurrence must take place to generate an event. Rule frequency is checked for logs of the agent itself, not for any log.
4. timeframe: Time window in which concurrences must be given (seconds).
5. ignore: This rule restarts your frequency counters after these seconds.
6. overwrite: With yes or no values, it allows to overwrite the configuration of a rule with the same ID. If together with overwrite=“yes” the rule has level=“0”, it is evaluated before any other and in case of a log match, it discards the evaluation of the rest of the rules for that log.

1. id: ルール識別子。他のルールが上書きされない限り、一意である必要があります。
2. level: イベント生成時のレベル（0～15）。レベルが 0 のルールはイベントを生成しません。
3. frequenity: イベントを生成するために同時発生する必要がある回数。ルールの頻度は、エージェント自身のログに対してチェックされ、他のログに対してはチェックされません。
4. timeframe: 同時発生が許容される時間枠（秒）。
5. ignore: このルールは、ここで指定した秒数後に frequenity カウンターをリスタートします。
6. overwrite: yes または no の値を指定することで、同じ ID を持つルールの設定を上書きできます。 overwrite=“yes” と同時に level=“0” のルールが設定されている場合、他のルールよりも先に評価され、ログが一致した場合は、そのログの残りのルールの評価は破棄されます。

↑Complete syntax.

↑完全な書式

        <if_matched_sid>N</if_matched_sid>

The rule is satisfied if another rule with the indicated ID triggered an alert the times indicated by frequency within the timeframe time.

指定された ID を持つ別の rule が timeframe 時間内に frequency で指定された回数アラートを発報した場合、ルールは満たされます。

↑Complete syntax.

↑完全な書式

        <if_matched_group>GROUP</if_matched_group>

Like if_matched_sid but for groups.

if_matched_sid と似ていますが、グループ用です。

↑Complete syntax.

↑完全な書式

        <same_id />

Concurrences with the same ID must be given.

同じ ID による同意を与える必要があります。

↑Complete syntax.

↑完全な書式

        <different_id />

Concurrences with different IDs must be given.

異なる ID による一致を指定する必要があります。

↑Complete syntax.

↑完全な書式

        <same_field>Field1</same_field>
        <same_field>Field2.Sub1</same_field>

Concurrences with the same values in the field must take place.

フィールド内が同じ値で一致する必要があります。

↑Complete syntax.

↑完全な書式

        <different_field>Field1</different_field>
        <different_field>Field2.Sub1</different_field>

Concurrences with different values in the field must take place.

フィールド内の異なる値との一致が行われる必要があります。

↑Complete syntax.

↑完全な書式

        <description>TEXT</description>

The text for the event to be generated.¹⁾

生成されるイベントのテキスト。(変数は、説明と info でカスタムフィールドの値とともに使用できます。例: $(Field1)、$(Field2.Sub1)、$(Field2.Sub2)))

↑Complete syntax.

↑完全な書式

        <match type="pcre2">RREGEXP</match>
        <match negate="yes|no">RREGEXP</match>

If the contents of the log match this, it generates a SIEM event.

1. type: It allows you to specify the type of regular expression. If not specified, OS Regex is used.
2. negate: With a yes value you may deny the match.

ログの内容がこれに一致する場合、SIEM イベントが生成されます。

1. type: 正規表現の種類を指定できます。指定しない場合は、OS Regex が使用されます。
2. negate: yes を指定すると、一致を否定できます。

↑Complete syntax.

↑完全な書式

        <regex type="pcre2">RREGEXP</regex>
        <regex negate="yes|no">RREGEXP</regex>

Same as “match”.

1. type: It allows you to specify the type of regular expression. If not specified, OS Regex is used.
2. negate: With a yes value you may deny the regular expression.

“match” と同じです。

1. type: 正規表現の種類を指定できます。指定しない場合は、OS Regex が使用されます。
2. negate: yes を指定すると、正規表現を拒否できます。

↑Complete syntax.

↑完全な書式

        <decoded_as>DecoderName</decoded_as>

The rule is satisfied if the log was decoded by the indicated decoder.

指定された デコーダー によってログがデコードされた場合、ルールは満たされます。

↑Complete syntax.

↑完全な書式

        <category>EventType</category>

The rule is satisfied if the type of the decoder matches.

デコーダー のタイプが一致する場合、ルールは満たされます。

↑Complete syntax.

↑完全な書式

        <field name="Field1">REGEXP</field>
        <field name="Field2.Sub1" negate="yes|no">REGEXP</field>

If the indicated field matches the value, it complies with the rule.

1. negate: With a yes value, it allows to deny the match with the field.

指定されたフィールドが値と一致する場合、ルールに準拠します。

1. negate: yes 値を指定すると、フィールドとの一致を拒否できます。

↑Complete syntax.

↑完全な書式

        <program_name negate="yes|no">REGEXP</program_name>

If the source of the log matches, the rule is met.

1. negate: With a yes value, it allows to deny matches with the source log.

ログのソースが一致する場合、ルールは満たされます。

1. negate: yes の値を指定すると、ソースログとの一致を拒否できます。

↑Complete syntax.

↑完全な書式

        <time>TIME-RANGE</time>

If the event is generated in the indicated time range, the rule matches.

指定された時間範囲内にイベントが生成された場合、ルールは一致します。

↑Complete syntax.

↑完全な書式

        <weekday>DAYS</weekday>

If the event is generated the days the rule complies with (monday - sunday, weekdays, weekends).

イベントが生成された場合、ルールが日 (monday - sunday, weekdays, weekends) に準拠します。

↑Complete syntax.

↑完全な書式

        <if_sid>PARENT1, PARENT2</if_sid>

The rule is met if any of the parent rules are met.

親ルールのいずれかが満たされると、ルールは満たされます。

↑Complete syntax.

↑完全な書式

        <if_group>GROUP</if_group>

The rule is met if the log meets any other rule in the specified group.

ログが指定されたグループ内の他のルールを満たす場合、ルールは満たされます。

↑Complete syntax.

↑完全な書式

        <if_level>N</if_level>

The rule is met if another rule with the same level has been met.

同じレベルの別のルールが満たされている場合、そのルールは満たされます。

↑Complete syntax.

↑完全な書式

        <info type="text|link|cve">TEXT|LINK|CVE</info>

Additional information for the generated event.²⁾

生成されたイベントの追加情報。³⁾

↑Complete syntax.

↑完全な書式

        <group>GROUP1,GROUP2,</group>

List of rule groups.

ルールグループのリスト。

↑Complete syntax.

↑完全な書式

        <mitre>
            <id>MITRE_ID</id>
            <id>MITRE_ID</id>
        </mitre>

List of the MITRE IDs of the rule.

ルールの MITRE ID のリスト。

The following code describes a rule for PHP-related SELinux logs. This rule creates events for any attempt to connect to ports other than the usual ones on a web server.

以下のコードは、PHP 関連の SELinux ログのルールを記述しています。このルールは、Web サーバ上の通常のポート以外のポートへの接続試行に対してイベントを作成します。

<rule id="100201" level="6">
        <decoded_as>setroubleshoot_program</decoded_as>
        <match>/usr/sbin/php-fpm</match>
        <field name="object_target" type="pcre2">^(?!.*\b(9200|3306|80|443)$).*$</field>
        <field name="object_target" type="pcre2">^(?!.*(directory|file) (conf|data_in|cron.lock)).*$</field>
        <description>SELinux prevented /usr/sbin/php-fpm execution on: $(action) access on the $(object_target)</description>
        <mitre>
            <id>T1071.002</id>
        </mitre>
        <group>exec,threat,PHP</group>
</rule>

Thus, connections to ports 9200, 3306, 80 and 443 will not create events. Neither will events of type directory or file.

したがって、ポート 9200、3306、80、および 443 への接続ではイベントは作成されません。directory または file タイプのイベントも作成されません。

General decoder decoder used for SELinux:

SELinux で使用される一般的な デコーダー :

<decoder name="setroubleshoot">
    <program_name>^setroubleshoot$</program_name>
</decoder>
 
<decoder name="setroubleshoot_program">
    <parent>setroubleshoot</parent>
    <prematch type="pcre2">(SELinux is preventing|SELinux está negando a)</prematch>
    <regex type="pcre2">(\S+) (?:from|de) (\S+) (?:access on the|el acceso a) (.+?)\. (?:For complete SELinux messages run: sealert -l|Si quiere los mensajes de SELinux completos, ejecute sealert -l) (\S+)$</regex>
    <order>binary,action,object_target,sealert_id</order>
</decoder>
 
<decoder name="setroubleshoot_program">
    <parent>setroubleshoot</parent>
    <prematch type="pcre2">failed to retrieve rpm info for path</prematch>
    <regex type="pcre2">failed to retrieve rpm info for path (\S+)</regex>
    <order>path</order>
</decoder>

Regular expressions are sequences of characters that define a pattern.

正規表現はパターンを定義する文字のシーケンスです。

There are two types of regular expressions valid for decoders and rules: OS Regex and PCRE2.

デコーダーと ルールに有効な正規表現には、OS Regex と PCRE2 の 2 種類があります。

They are simple regular expressions based on a library made in C language. It is designed to be simple and at the same time support the most common regular expressions.

To use the following characters you must escape them with \:

• The * and + modifiers may only be applied to backslash expressions, not to single characters (e.g. \d+ is supported, 0+ is not supported).
• Alternation cannot be used in a group, e.g. (foo|bar) is not allowed.
• Complex backtracking is not supported, e.g., \p*\d*\s*\w*:, it does not match only colon because \p* consumes the colon.
• . matches a literal period, while \. matches any character.
• \s matches only an ASCII space (32), not other blanks such as tabs.
• There is no syntax to match a caret, asterisk or more literal (although \p will match an asterisk or more, along with some other characters).

Perl Compatible Regular Expression (PCRE2) provides features such as recursive patterns, look-ahead and look-back assertions, non-capture groups, non-voracious quantifiers, extended syntax for characters and character classes, among others.

For more details, see the PCRE2 syntax documentation.

See the topic SIEM alert system.

See the topic SIEM events reports.

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