NXLog News and product updates

As a result of several months' hard work we have released the NXLog Enterprise Edition v4.0 yesterday. Below is a summary of what the new release brings.

NXLog users can benefit from a SANS course titled SEC555: SIEM with Tactical Analytics, the first vendor-neutral course of its kind.

About SANS

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.

TL;DR

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[26459]: 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.

The popularity of the ELK stack is steadily rising, many NXLog users send their event data to Elasticsearch and Kibana for log monitoring and analytics.

There are many tutorials and configurations scattered around on the web, some come with configuration samples that will likely not work properly.  For this reason we have written a short document introducing different options on how to use NXLog with Elasticsearch and Kibana, it's available under the documentation page.

Paul Nelson from Opsbot has written an excellent article titled Windows as a First-Class Centralized Logging Citizen discussing centralized logging using open source tools. Well worth the read!

Update: the article is no longer available.

The latest release of NXLog log management tools brings several bug fixes and enhancements such as better Snare compatibility and various regular expression modifiers.
The full changelog is listed below: