The main source of information for users looking to configure NXLog was the NXLog [EE/CE] Reference Manual until recently. The Reference Manual is mostly what it is called: a reference manual. While it does cover what the software is capable of, unfortunately it is hard to use when you are tasked with setting up NXLog for a particular use case.
We are proud to announce the general availability of NXLog Enterprise Edition v3.0 which is a major step forward to enhance the features and reliability of our flagship product. Below is a list of highlights in the new major release.
Multi platform support for Windows Event Forwarding
A new input module (im_wseventing) can be used to collect forwarded events from Windows hosts. The Windows clients can be configured from Group Policy to send Windows EventLog using Windows Event Forwarding. NXLog already supported collecting Windows EventLog remotely in earlier versions over WMI and MSRPC but this new capability is a major step for secure data collection from Windows machines in agentless mode supporting both Kerberos and HTTPS data transfer. Moreover the new im_wseventing module is platform independent and works on GNU/Linux as well whereby a single NXLog server running on GNU/Linux can be used to collect all your event data in the enterprise including Syslog and Windows EventLog.
The Windows DNS service may not recreate the debug log file after rollover. If you get hit by the issue, make sure to use the C: drive for the debug log path.
The Windows DNS debug log
The Windows DNS debug log contains information on DNS queries and activity that can be important to monitor and analyze to detect malicious traffic. This requires some configuration changes for the DNS service in order to enable debug logging. Here is a short description on how to enable debug logging for the DNS service on windows, this also applies to Windows 2008 and later. It is possible to specify the file and path name of the DNS debug log file as well as the maximum size of the file.
Structured logging is on the rise. A lot of tools and logging services are finally moving towards structured logging and JSON seems to be the format of choice for this.
But what is structured logging? Traditionally logs were generated in the form of free form text messages prepended with some basic metadata such as the time of the event, severity and the source of the event. This is what the old RFC3164 style Syslog format looks like:
<30>Nov 21 11:40:27 myhost sshd: Accepted publickey for myhost from 192.168.1.1 port 424242 ssh2
This traditional syslog fromat has a header consisting of the severity, facility, timestamp, hostname and process name followed by a free form text string optionally containing additional metadata. The advantage of this is that log data in this format can be easily parsed and stored in text files for humans to look at.