Blog Part 3: How to Fine-Tune NXLog for Windows Server for Cybersecurity Success

Introduction

So far in this series, we’ve learned what NXLog is, how it compares to alternatives, and why it’s a strong choice for Windows Server environments.

Today, let’s go deeper.

Fine-tuning NXLog is not just about getting the logs flowing — it’s about making sure we collect the right logs, with right details, to meet cybersecurity goals and audit requirements.

Both freshers and experienced professionals will find this guide useful!

Why Fine-Tuning Matters?

Reduces noise (collecting too much irrelevant data is expensive and confusing)
Ensures important security events are not missed
Helps meet audit and compliance standards (PCI DSS, HIPAA, GDPR, etc.)
Improves SIEM performance (sending clean, enriched logs)

Key Areas to Fine-Tune in NXLog for Windows Servers

Selecting Specific Event IDs
Enhancing MSSQL Log Collection
Capturing Important Web Server Logs (IIS, Apache)
Expanding $raw_event and $Message Fields
Adjusting Output Modules Carefully

1. Selecting Specific Event IDs for Windows Event Logs

By default, if you collect all Windows logs, you’ll also collect tons of irrelevant entries (like Service Control Manager events or print jobs!).

Instead, focus on high-value Event IDs related to security and operations.

Suggested Critical Event IDs:

Example Query:

<Input in_eventlog>
    Module im_msvistalog
    Query <QueryList>\
            <Query Id="0">\
              <Select Path="Security">*[System[(EventID=4624 or EventID=4625 or EventID=4720 or EventID=1102)]]</Select>\
            </Query>\
          </QueryList>
</Input>

2. Enhancing MSSQL Log Collection

In cybersecurity, it’s crucial to monitor database activities.

Apart from normal transactions, focus on suspicious activities like:

Multiple failed login attempts
Schema changes
New users created
Database backups/restores

Suggested MSSQL Queries:

SELECT * FROM sys.dm_exec_sessions WHERE is_user_process = 1;
SELECT * FROM sys.dm_audit_actions WHERE action_id IN ('SC', 'AU');

Note:
Use the im_odbc module in NXLog to schedule these queries every few minutes.

3. Capturing Important IIS, Apache, FTP, DNS, DHCP Logs

IIS and Apache logs provide a goldmine of cybersecurity data:

Client IPs
URLs accessed
Status codes (e.g., 401 Unauthorized, 404 Not Found)
Timestamps
User-Agent Strings

Best Practice:
Enable Extended Logging Fields for IIS and Apache.

Sample important fields to enable:

cs-uri-stem
cs-uri-query
sc-status
cs-user-agent
c-ip (client IP)

4. Expanding $raw_event and $Message Fields

By default, NXLog captures basic data — but you can expand it to collect full details for cyber audits.

Add enrichment like:

Hostname
IP Address
Time Zone
Event Origin
Custom Tags (e.g., Application=”MSSQL”, SystemType=”Server”)

Example:

<Extension _syslog>
    Module      xm_syslog
</Extension>

<Output out_syslog>
    Module      om_udp
    Host        10.10.10.10
    Port        514
    Exec        to_syslog_bsd();
</Output>

You can customize Exec further:

Exec $Message = $raw_event + " Application=MSSQL SourceHost=" + hostname_fqdn();

This way, your logs are SIEM ready with rich context.

5. Adjusting Output Modules Carefully

Always remember:

UDP is faster but unreliable (use for low-risk data)
TCP is reliable (use for critical logs)
TLS adds encryption (best for sensitive environments)

Output Example for Encrypted Forwarding:

<Output out_secure>
    Module om_ssl
    Host 192.168.100.10
    Port 6514
    CAFile %CERTDIR%/ca-cert.pem
    CertFile %CERTDIR%/client-cert.pem
    CertKeyFile %CERTDIR%/client-key.pem
</Output>

Sample Fine-Tuned NXLog Config File (For Reference Only)

## nxlog.conf
## Note: This is not a final config file. It is provided for your reference. Please contact your OTM support team for final integration.

<Extension _json>
    Module xm_json
</Extension>

<Input in_eventlog>
    Module      im_msvistalog
    Query       <QueryList>\
                   <Query Id="0">\
                     <Select Path="Security">*[System[(EventID=4624 or EventID=4625 or EventID=1102)]]</Select>\
                   </Query>\
                 </QueryList>
</Input>

<Input in_mssql>
    Module      im_odbc
    ConnectionString "Driver={SQL Server};Server=localhost;Database=master;Trusted_Connection=yes;"
    SQL "SELECT * FROM sys.dm_exec_sessions WHERE is_user_process = 1;"
</Input>

<Input in_iis>
    Module      im_file
    File        "C:\\inetpub\\logs\\LogFiles\\W3SVC1\\*.log"
</Input>

<Output out_syslog_secure>
    Module      om_ssl
    Host        192.168.1.10
    Port        6514
    CAFile      %CERTDIR%/ca-cert.pem
    CertFile    %CERTDIR%/client-cert.pem
    CertKeyFile %CERTDIR%/client-key.pem
</Output>

<Route main>
    Path in_eventlog, in_mssql, in_iis => out_syslog_secure
</Route>

Quick Tips for Success

✅ Always test config files on a development server first.
✅ Tune and validate outputs with your SIEM team.
✅ Monitor NXLog’s own logs (nxlog.log) to catch issues early.
✅ Periodically review your Event ID filters.

Conclusion

Fine-tuning NXLog isn’t just a technical task — it’s a security strategy.

By being smart about what you collect, how you collect, and where you send it, you can dramatically improve visibility, reduce risks, and meet compliance standards confidently.

Tomorrow, we’ll focus on troubleshooting NXLog and common mistakes to avoid. 🚀