Applying double filters in NXLOG for windows event logs

In our previous NXLOG article, it was mentioned how it was possible to create filters by using the Exec drop() directive in NXLOG accompanied by a filtering if statement. This works well as a general solution to incoming logs, however, there exists a more specific way to filter out windows event logs. This works by adding a query inside the <input eventlog> tag inside nxlog.conf:

Query <QueryList>\
    <Query Id="0" Path="Security">\ #Selects the default path of the location of the event logs
        <Select Path="Security">*[System[EventID=4663]]</Select>\ #Selects an event log with a specific ID. Overrides the default path
    </Query>\
</QueryList>

Using this query filter you can more precisely specify what event logs to fetch. For example, perhaps instead of pulling logs with IDs you may want to pull all the security logs. Doing this with a query filter is very simple:

Query <QueryList>\
    <Query Id="0">\
        <Select Path="Security">*</Select>\
    </Query>\
</QueryList>

And you can similarly do this for the Application and System paths by appending <Select Path=”Application”>*</Select>\ and <Select Path=”System”>*</Select>\ respectively.

One particularly good use of these query filters is for double filtering event logs:

Query <QueryList>\
    <Query Id='1'>\
        <Select Path='Security'>*[Security/Level=4]</Select> \
    </Query>\
</QueryList>

If you wanted to obtain all the Security logs with security level 4 there exists no way to do so with a regular if statement. Once the logs from the initial QueryList filter get through you can further filter those logs using:

Exec if not($Message =~ /READ/m) drop();

Merging both the exec directive and QueryList would essentially allow only level 4 security logs that contain READ inside their message field to get forwarded.

Using both of these types of filters will allow you to have more flexibility and control over the data that gets forwarded through nxlog. Double filtering is especially useful for preventing log flooding by specifically choosing which logs will get forwarded to your preferred centralized logging solution.