Encrypted transfer
In order to protect log data in transit from being modified or viewed by an attacker, NXLog provides SSL/TLS data encryption support in many input and output modules. Benefits of using SSL/TLS encrypted log transfer include:
-
strong authentication,
-
message integrity (assures that the logs are not changed), and
-
message confidentiality (assures that the logs cannot be viewed by an unauthorized party).
| It is important that certificates be renewed before expiration. The NXLog Manager dashboard can be configured with a "Certificate summary" which lists soon-to-expire certificates in a separate group. |
SSL/TLS encryption in NXLog
The SSL/TLS protocol encrypts log data on the client side and then decrypts it on the server side. It’s recommended to use 2048-bit keys or larger.
There are several modules in NXLog Enterprise Edition that support SSL/TLS encryption:
-
im_batchcompress and om_batchcompress support encryption of compressed log batches transferred between NXLog instances.
When using the SSL/TLS, there are two ways to handle authentication.
-
With mutual authentication, both client and log server agents are authenticated, and certificates/keys must be deployed for both agents. This is the most secure and prevents log collection if the client’s certificate is untrusted or has expired.
-
With server-side authentication only, authentication takes place only via a certificate/key deployed on the server. On the log server, the im_ssl AllowUntrusted directive (or corresponding directive for im_http or im_batchcompress) must be set to TRUE. The client is prevented from sending logs to an untrusted server but the server accepts logs from untrusted clients.
With the following configurations, a client reads logs from all log files
under the /var/log directory, parses the events with
parse_syslog(), converts to JSON with
to_json(), and forwards them over a secure connection
to the central server.
These configurations use mutual authentication: both agents are authenticated and certificates must be created for both agents.
<Extension _syslog>
Module xm_syslog
</Extension>
<Extension _json>
Module xm_json
</Extension>
<Input messages>
Module im_file
File "/var/log/*"
Exec parse_syslog();
</Input>
<Output central_ssl>
Module om_ssl
Host 192.168.56.103
Port 516
CAFile /opt/ssl/rootCA.pem
CertFile /opt/ssl/client.crt
CertKeyFile /opt/ssl/client.key
KeyPass password
Exec to_json();
</Output>The server receives the logs on port 516 and writes them to
/var/log/logmsg.log.
<Extension _syslog>
Module xm_syslog
</Extension>
<Input input_ssl>
Module im_ssl
Host 0.0.0.0
Port 516
CAFile /opt/ssl/rootCA.pem
CertFile /opt/ssl/central.crt
CertKeyFile /opt/ssl/central.key
KeyPass password
</Input>
<Output fileout>
Module om_file
File "/var/log/logmsg.log"
</Output>OpenSSL certificate creation
NXLog Manager provides various features for creating, deploying, and managing SSL/TLS 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 SSL/TLS 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
-
