localfile

location

The location field specifies where the log data comes from. It includes the following options.

• A path to a log file

• A Windows event channel

• The macOS ULS

• The journald system

For log file names, you can use strftime format strings. For example, you can reference a log file named file.log-2024-04-26 by file.log-%Y-%m-%d.

Wildcards can be used on Linux and Windows systems, if the log file doesn't exist at wazuh-logcollector start time, such log will be re-scanned after logcollector.vcheck_files seconds.

The location field is also valid to filter by channel in case of using an eventchannel supporting Windows.

In the following example we can see two configurations showing a channel filtering for firewall and Sysmon events.

<localfile>
    <location>Microsoft-Windows-Sysmon/Operational</location>
    <log_format>eventchannel</log_format>
</localfile>

<localfile>
    <location>Microsoft-Windows-Windows Firewall With Advanced Security/Firewall</location>
    <log_format>eventchannel</log_format>
</localfile>

Below we have some Windows wildcard examples.

<localfile>
    <location>C:\Users\wazuh\myapp\*</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>C:\xampp\apache\logs\*.log</location>
    <log_format>syslog</log_format>
</localfile>

<localfile>
    <location>C:\logs\file-%Y-%m-%d.log</location>
    <log_format>syslog</log_format>
</localfile>

command

Given a command output, it will be read as one or more log messages depending on command or full_command is used.

alias

Change a command name in the log message.

For example <alias>usb-check</alias> would replace:

ossec: output: 'reg QUERY HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR':

with:

ossec: output: 'usb-check':

frequency

Defines the interval (in seconds) between executions of the command. This option applies to both command and full_command.

only-future-events

It allows to read new log content since wazuh-logcollector was stopped.

By default, when wazuh-logcollector is started it reads the logs generated since that moment. Set it to no to collect events generated since wazuh-logcollector was stopped.

The attributes below are optional.

query

This label can be used to filter Windows eventchannel events or macOS ULS logs (macos) that Wazuh will process.

To filter Windows eventchannel events, XPATH format is used to make the queries following the event schema.

Example:

<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
  <query>Event[System/EventID = 4624 and (EventData/Data[@Name='LogonType'] = 2 or EventData/Data[@Name='LogonType'] = 10)]</query>
</localfile>

To filter macOS ULS logs (macos), Predicates format is used to make the queries.

Example:

<localfile>
  <location>macos</location>
  <log_format>macos</log_format>
  <query type="log,trace" level="debug">process == "sshd" OR message CONTAINS "invalid"</query>
</localfile>

The attributes below are optional and only valid for macOS ULS (macos).

label

Used to add custom data in JSON events. Set log_format to json to use it.

Labels can be nested in JSON alerts by separating the "key" terms by a period.

Here is an example of how to identify the source of each log entry when monitoring several files simultaneously:

<localfile>
  <location>/var/log/myapp/log.json</location>
  <log_format>json</log_format>
  <label key="@source">myapp</label>
  <label key="agent.type">webserver</label>
</localfile>

This is a sample JSON object from the log file:

{
  "event": {
    "type": "write",
    "destination": "sample.txt"
  },
  "agent": {
    "name": "web01"
  }
}

The additional fields configured above would appear in the resulting event as below:

{
  "event": {
    "type": "write",
    "destination": "sample.txt"
  },
  "agent": {
    "name": "web01",
    "type": "webserver"
  },
  "@source": "myapp"
}

target

Target specifies the name of the socket where the output will be redirected. The socket must be defined previously.

log_format

Specifies the format of the log to be read. This field is required.

Sample of multi-line log message in the original log file:

Aug 9 14:22:47 hostname log line one
Aug 9 14:22:47 hostname log line two
Aug 9 14:22:47 hostname log line four
Aug 9 14:22:47 hostname log line three
Aug 9 14:22:47 hostname log line five

Sample of log message as processed by wazuh-analysisd:

Aug 9 14:22:47 hostname log line one Aug 9 14:22:47 hostname log line two Aug 9 14:22:47 hostname log line three Aug 9 14:22:47 hostname log line four Aug 9 14:22:47 hostname log line five

out_format

This option allows formatting logs from Logcollector using field substitution.

The list of available parameters is:

Attributes:

ignore_binaries

This specifies to ignore binary files, testing if the file is UTF8 or ASCII.

If this is set to yes and the file is, for example, a binary file, it will be discarded.

<localfile>
    <log_format>syslog</log_format>
    <location>/var/logs/*</location>
    <ignore_binaries>yes</ignore_binaries>
</localfile>

age

This specifies to read-only files that have been modified before the specified age.

For example, if the age is set to 1 day, all files that have not been modified since 1 day will be ignored.

<localfile>
    <log_format>syslog</log_format>
    <location>/var/logs/*</location>
    <age>1d</age>
</localfile>

exclude

This indicates the location of a wild-carded group of logs to be excluded.

For example, we may want to read all the files from a directory, but exclude those files whose name starts with an e.

<localfile>
    <log_format>syslog</log_format>
    <location>/var/logs/*</location>
    <exclude>/var/logs/e*</exclude>
</localfile>

reconnect_time

Defines the interval of reconnection attempts when the Windows Event Channel service is down.

multiline_regex

This specifies a regular expression, match criteria and replace option for logs with a variable amount of lines.

The attributes below are optional.

The behavior of the match attribute is as follows

For example, we may want to read a Python Traceback output as one single log, replacing newline with spaces

<localfile>
    <log_format>multi-line-regex</log_format>
    <location>/var/logs/my_python_app.log</location>
    <multiline_regex replace="wspace">^Traceback</multiline_regex>
 </localfile>

ignore

Specify a regular expression to ignore log lines or command outputs when matching. Whether several ignore labels are defined, entries are ignored when matching any of the specified ones.

Use the type attribute to define the regular expression type. By default, PCRE2 is applied.

For example, to ignore events related to configuration changes in the audit log:

<localfile>
    <log_format>audit</log_format>
    <location>/var/log/audit/audit.log</location>
    <ignore type="PCRE2">type=.+_CHANGE</ignore>
    <ignore type="osregex">type=CONFIG_\.+</ignore>
</localfile>

restrict

Specify a regular expression to restrict processed log lines or command outputs. Whether several restrict labels are defined, entries are processed when matching all of them.

Use the type attribute to define the regular expression type. By default, PCRE2 is applied.

For example, to restrict syslog events related to a particular user name:

<localfile>
    <log_format>syslog</log_format>
    <location>/custom/file/path</location>
    <restrict type="PCRE2">username_\d?</restrict>
    <restrict type="osregex">Jun\.+</restrict>
</localfile>

filter

Collects journald logs selectively by filtering specific fields.

Specify a PCRE2 regular expression as the filter. Use the field attribute to select the journald field to match.

Use the ignore_if_missing attribute to control logs that lack the specified field:

• yes: Wazuh ignores the filter and accepts logs even if the field is missing.

• no: Logs without the field do not match the filter and are filtered out.

Multiple <localfile> blocks combine with OR logic.

Filters inside the same <localfile> block combine with AND logic. A log entry must match all filters in that block to be collected.

In the following example, Wazuh collects journald logs if any of these conditions hold:

• The field _SYSTEMD_UNIT equals ssh.service.

• The field _SYSTEMD_UNIT equals cron.service and either:

  • The field PRIORITY matches 0, 1, 2, or 3, or

  • the PRIORITY field is missing.

This configuration captures:

• All SSH logs

• High-severity cron messages and anomalous cron entries that lack priority information.

<!-- For monitoring log files -->
<localfile>
  <location>journald</location>
  <log_format>journald</log_format>
  <filter field="_SYSTEMD_UNIT">^ssh.service$</filter>
</localfile>

<localfile>
  <location>journald</location>
  <log_format>journald</log_format>
  <filter field="_SYSTEMD_UNIT">^cron.service$</filter>
  <filter field="PRIORITY" ignore_if_missing="yes">[0-3]</filter>
</localfile>

When multiple journald blocks are present:

• If no block has filters, Wazuh collects all journald logs.

• If at least one block has filters, Wazuh applies filters only from blocks that include them. Blocks without filters are ignored. This lets restrictive blocks override the default 'collect everything' behavior.