If you are reading this, then it is safe to say that you are now part of the NXLog community. In other words, you are ready to dive into the world of log collection. Excellent. You have made a great choice. However, before you start collecting logs you should know just how your NXLog log collection tool works.
The NXLog log collection tool uses loadable modules that are invoked within the input, data modification, and output stages. Because you can choose which modules to use in your NXLog configuration file, this provides countless possibilities for collecting logs based on your organization’s needs. Input modules work by reading your log data from various sources, whether these sources are on a remote server or found in a local directory. Output modules save your logs to a specific destination. And lastly, extension modules provide data transformation or parsing capabilities. The path these events take from the input to output block(s) is called the route.
Let’s bring all these pieces together in a simple and quick configuration guide. Windows will be the operating system featured in this blog post, so you can go ahead and download the Windows installer package. Already installed? Perfect. Let’s get started.
NXLog configuration steps
The first step is opening your NXLog configuration file which you will find in
the C:\Program Files\nxlog directory of your Windows system. You will notice
that your configuration file comes with default settings for advanced options.
However, for this simple guide, we do not need them. We will start by setting up
our log source, or in other words, our input. Here, we introduce the
modules
that provide the functionality to collect logs. In this scenario, our log
source will be the security channel of
Windows Event Log and we will use the
im_msvistalog
module to collect our events. To load an instance of this module, we will need
to choose an instance name, because it possible to load more than one instance
of a module. We will call our input instance input_events.
<Input input_events>
Module im_msvistalog
<QueryXML>
<QueryList>
<Query Id='0'>
<Select Path='Security'>*</Select>
</Query>
</QueryList>
</QueryXML>
</Input>On the next line, we use the Module directive to define which module NXLog
should load. Because this particular module supports XPath, a query language for
event selection that Windows Event Log uses, we use the <QueryXML> tag to
tell NXLog that this the beginning of an XPath query block. The next couple of
nested block tags support defining multiple queries. The single query
line we will use is based on the value we have assigned Path, which in our
case will be the Security channel. To learn more about creating these queries
you can read our guide on
event log filtering.
Secondly, we define our output instance. For consistency, let’s call our output
instance output_events. The name of the module that allows us to save our logs
to our local directory is
om_file.
The File directive lets us specify the exact directory path and filename where
we would like the logs to be saved. In this example, we will save them to
C:\Windows\Temp\logmsg.txt.
<Output output_events>
Module om_file
File 'C:\Windows\Temp\logmsg.txt'
</Output>The third step is to declare the route block. In the example below, we use the Path directive on line two (2) to clearly establish the flow of event data from the input stage to the output stage. We reference them by their instance names which function as unique identifiers.
<Route input_events_to_output_events>
Path input_events => output_events
</Route>Lastly, an important step is choosing any extension modules that might be needed for manipulating log data, be it for parsing, or for reading/writing various log log formats. Extension modules are used to extend and configure a wide range of capabilities available with the NXLog log collection tool.
<Extension json>
Module xm_json
</Extension>
<Input input_events>
Module im_msvistalog
<QueryXML>
<QueryList>
<Query Id='0'>
<Select Path='Security'>*</Select>
</Query>
</QueryList>
</QueryXML>
</Input>
<Output output_events>
Module om_file
Exec to_json();
File 'C:\Windows\Temp\logmsg.txt'
</Output>
<Route input_events_to_output_events>
Path input_events => output_events
</Route>In the example above, we parse the security logs collected from Windows Event
Log to JSON (JavaScript Object Notation), by using the to_json() procedure, in
our output instance. This is facilitated by first loading the
xm_json
extension module. In order to load this module, we define the json instance
shown in the first three lines of our finalized configuration listed above. Now,
when we navigate to C:\Windows\Temp\logmsg.txt we will observe that our logs
have arrived in JSON format as expected.
{
"EventTime": "2021-09-09T18:57:15.765021+03:00",
"Hostname": "DESKTOP-I9CD588",
"Keywords": "9232379236109516800",
"LevelValue": 0,
"EventType": "AUDIT_SUCCESS",
"SeverityValue": 2,
"Severity": "INFO",
"EventID": 4624,
"SourceName": "Microsoft-Windows-Security-Auditing",
"ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}",
"Version": 2,
"TaskValue": 12544,
"OpcodeValue": 0,
"RecordNumber": 70830,
"ActivityID": "{BC138851-A54F-000E-5888-13BC4FA5D701}",
"ExecutionProcessID": 916,
"ExecutionThreadID": 5208,
"Channel": "Security",
"Message": "An account was successfully logged on.\r\n\r\nS ",
"Category": "Logon",
"Opcode": "Info",
"Level": "Information",
"SubjectUserSid": "S-1-5-18",
"SubjectUserName": "DESKTOP-I9CD588$",
"SubjectDomainName": "WORKGROUP"
}And there you have it! You have successfully completed your first NXLog configuration guide. With this new found knowledge, we hope that you will continue to take advantage of our powerful log collection tool that is not only lightweight and resourceful, but also flexible enough to meet a variety of your organization’s needs.
GET STARTED TODAY
