Encrypted log transfer

NXLog supports TLS/SSL encryption to prevent data in transit from being viewed or modified by a malicious actor. Benefits of using TLS/SSL encrypted log transfer include:

Strong authentication - verifies the identity of the communicating parties
Data integrity - assures logs are not modified
Confidentiality - ensures unauthorized parties cannot access the logs

It is important to renew certificates before they expire to avoid disrupting the log collection and forwarding process. The NXLog Manager dashboard contains a Certificate summary widget highlighting certificates nearing expiration.

NXLog TLS/SSL configuration

TLS/SSL is a cryptographic protocol to encrypt data transmitted over the network. A client or server encrypts data using a certificate and private key pair. The receiving end must then decrypt the data with the public key. Authentication is required on the server side and optional on the client side. We recommend using 2048-bit or larger keys.

NXLog Enterprise Edition contains several modules that support TLS/SSL encryption:

im_ssl and om_ssl support secure TCP connections.
im_http and om_http support secure HTTP connections.
im_batchcompress and om_batchcompress support batched, encrypted, and compressed log transfer between NXLog instances.
Several other vendor-specific input and output modules support secure data transfer over HTTP.

There are two types of TLS/SSL authentication:

Mutual authentication requires both client and server to authenticate each other. Therefore, when NXLog is acting as a client collecting or forwarding logs, you must configure the relevant module instance with a CA certificate to verify the remote server’s identity and a client certificate and private key pair to encrypt its data. This is the most secure method.
One-way authentication only requires the server to present a certificate to the client. In this case, when NXLog is in client mode, you only need to configure the relevant module instance with a CA certificate to verify the remote server’s identity.

Example 1. Configuring NXLog as a client with TLS/SSL mutual authentication

The configuration below uses the om_ssl output module to send logs to a remote server using a secure channel over TCP. The server requires mutual authentication; therefore, the om_ssl instance must present a certificate during the TLS/SSL handshake.

nxlog.conf

<Output siem>
    Module         om_ssl
    Host           192.168.1.100:516
    CAFile         /etc/ssl/certs/rootCA.pem (1)
    CertFile       %CERTDIR%/client.pem (2)
    CertKeyFile    %CERTDIR%/client.key (3)
    KeyPass        password (4)
</Output>

1	Use the `CAFile` directive to specify the path of the certificate authority (CA) certificate NXLog should use to verify the remote certificate. Alternatively, use the `CADir` directive to point NXLog to a root certificate store.
2	The `CertFile` directive specifies the path to the certificate file to send during the TLS/SSL handshake.
3	The `CertKeyFile` directive specifies the path to the private key file that was used to generate the certificate specified by the `CertFile` directive.
4	Optional: The `KeyPass` directive specifies the passphrase of the private key. It is only required for encrypted private keys.

Example 2. Configuring NXLog as a client with TLS/SSL one-way authentication

This configuration uses the om_http output module to send logs to a remote web server over HTTPS. The server supports one-way authentication; therefore, the om_http instance only needs to verify the remote certificate to establish a connection.

nxlog.conf

<Output siem>
    Module        om_http
    URL           https://server:8080/
    HTTPSCADir    /etc/ssl/certs (1)
</Output>

1	Use the `HTTPSCADir` directive to point NXLog to a folder that contains a CA certificate that can verify the server certificate. The om_http module uses the OS root certificate store by default. Alternatively, use the `HTTPSCAFile` directive to use a specific CA certificate.

Example 3. Configuring NXLog to receive logs securely

This configuration uses the im_ssl input module to receive logs over a secure TCP channel. im_ssl supports both mutual and one-way authentication.

nxlog.conf

<Input tcp_ssl>
    Module         im_ssl
    ListenAddr     0.0.0.0:1514
    RequireCert    TRUE (1)
    CAFile         /etc/ssl/certs/rootCA.pem (2)
    CertFile       %CERTDIR%/server.pem (3)
    CertKeyFile    %CERTDIR%/server.key (4)
    KeyPass        password (5)
</Input>

1	Use the `RequireCert` directive to specify whether the remote client must present a certificate during TLS/SSL handshake.
2	If `RequireCert` is enabled, you must configure the `CAFile` or `CADir` directives to point NXLog to a CA certificate that can verify the remote certificate.
3	The `CertFile` directive specifies the path to the certificate file NXLog will send to the remote client during the TLS/SSL handshake.
4	The `CertKeyFile` directive specifies the path to the private key file that was used to generate the certificate specified by the `CertFile` directive.
5	Optional: The `KeyPass` directive specifies the passphrase of the private key. It is only required for encrypted private keys.

Using a well-known CA certificate bundle

A CA bundle contains root and intermediate certificates to verify server or client certificates during secure network communication.

Linux-based operating systems come with a default CA bundle containing industry root certificates to facilitate secure communication. However, the CA certificate store location varies depending on the OS distribution and version. The table below lists some common locations:

OS CA certificate store

OS	CA certificate store
Debian/Ubuntu	`/etc/ssl/certs`
RHEL/CentOS	`/etc/pki/ca-trust`
SLES	`/usr/share/pki/trust/anchors`
AIX	`/var/ssl/certs`
Solaris	`/etc/openssl/certs`

Debian/Ubuntu

/etc/ssl/certs

RHEL/CentOS

/etc/pki/ca-trust

SLES

/usr/share/pki/trust/anchors

AIX

/var/ssl/certs

Solaris

/etc/openssl/certs

Windows operating systems store default root certificates in the Trusted Root Certification Authorities certificate store. You can view the installed certificates from the Certificates MMC snap-in. Go to Start > Run and type certlm.msc to view computer certificates or certmgr.msc to view user certificates.

Most NXLog modules use the OS root certificate store to verify remote certificates. However, if this doesn’t work in your environment for some reason, you can configure NXLog to use a custom CA bundle. See the Curl tool CA certificates extracted from Mozilla for a CA bundle you can use. Download the certificate bundle by executing the following command on Linux:

$ wget https://curl.se/ca/cacert.pem

Or use the following PowerShell command on Windows:

> wget https://curl.se/ca/cacert.pem -OutFile cacert.pem

Once you have your CA bundle, place it in the default root certificate directory of your OS or use the CAFile or HTTPSCAFile directive accordingly to point NXLog to it, as shown in the configuration examples above.

Creating self-signed certificates with OpenSSL

NXLog Manager provides various features for creating, deploying, and managing TLS/SSL certificates, and is especially helpful when managing many NXLog agents across an organization. This section, however, provides steps for creating self-signed certificates with OpenSSL, a Linux-based TLS/SSL cryptography toolkit.

Generate the private root key for your Certification Authority (CA).
```
$ openssl genrsa -out rootCA.key 2048
```

Self-sign the key and create a CA certificate.

$ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 730 -out rootCA.pem

Create a certificate for each server.

Generate a private key for the server.
```
$ openssl genrsa -out server.key 2048
```
Generate the certificate signing request for the CA. When prompted for the Common Name, enter the server’s name or IP address.
```
$ openssl req -new -key server.key -out server.csr
```

Sign the request.

$ openssl x509 -req -in server.csr -CA rootCA.pem -CAkey rootCA.key \
                    -CAcreateserial -out server.crt -days 500 -sha256