syslog-ng Premium Edition 7.0.24 - Administration Guide

allow-compress()

Description: Enable on-the-wire compression in TLS communication. Note that this option must be enabled both on the server and the client to have any effect. Enabling compression can significantly reduce the bandwidth required to transport the messages, but can slightly decrease the performance of syslog-ng PE, reducing the number of transferred messages during a given period.

Available in version 7.0.12 and later.

crl-dir()

Description: Name of a directory that contains the Certificate Revocation Lists for trusted CAs. Similarly to ca-dir() files, use the 32-bit hash of the name of the issuing CAs as filenames. The extension of the files must be .r0.

If the crl-dir() is set, and the peer certificate has been revoked, syslog-ng PE rejects the connection. If the peer certificate has not been revoked, or syslog-ng PE cannot access the CRL, syslog-ng PE accepts the connection.

ecdh-curve-list()

Description: A colon-separated list that specifies the curves that are permitted in the connection when using Elliptic Curve Cryptography (ECC).

The syslog-ng PE application automatically uses the highest preference curve that both peers support. If not specified, the list includes every supported curve.

Example:

ecdh-curve-list("prime256v1:secp384r1")

The syslog-ng Premium Edition application currently supports the following curves: sect163k1, sect163r1, sect163r2, sect193r1, sect193r2,, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1,, sect409k1, sect409r1, sect571k1, sect571r1, secp160k1,, secp160r1, secp160r2, secp192k1, prime192v1, secp224k1,, secp224r1, secp256k1, prime256v1, secp384r1, secp521r1,, brainpoolP256r1, brainpoolP384r1, brainpoolP512r1.

peer-verify()

Description: Verification method of the peer, the four possible values is a combination of two properties of validation:

• Whether the peer is required to provide a certificate (required or optional prefix).

• Whether the certificate provided needs to be valid or not.

The following table summarizes the possible options and their results depending on the certificate of the peer.

For untrusted certificates only the existence of the certificate is checked, but it does not have to be valid — syslog-ng accepts the certificate even if it is expired, signed by an unknown CA, or its CN and the name of the machine mismatches.

ssl-options()

Description: Sets the specified options of the SSL/TLS protocols. Currently, you can use it to disable specific protocol versions. Note that disabling a newer protocol version (for example, TLSv1.1) does not automatically disable older versions of the same protocol (for example, TLSv1.0). For example, use the following option to permit using only TLSv1.1 or newer:

ssl-options(no-sslv2, no-sslv3, no-tlsv1)

Using ssl-options(none) means that syslog-ng PE does not specify any restrictions on the protocol used. However, in this case, the underlying OpenSSL library can restrict the available protocols, for example, certain OpenSSL versions automatically disable SSLv2.

This option is available in syslog-ng PE7.0 and newer.

destination demo_tls_destination {
    network("172.16.177.147" port(6514)
    transport("tls")
    tls( ca-dir("/etc/syslog-ng/ca.d")
         key-file("/etc/syslog-ng/cert.d/clientkey.pem")
         cert-file("/etc/syslog-ng/cert.d/clientcert.pem")
         ssl-options(no-sslv2, no-sslv3, no-tlsv1) )
    ); };

trusted-dn()

Description: To accept connections only from hosts using certain certificates signed by the trusted CAs, list the distinguished names of the accepted certificates in this parameter. For example, using trusted-dn("*, O=Example Inc, ST=Some-State, C=*") will accept only certificates issued for the Example Inc organization in Some-State state.

trusted-keys()

Description: To accept connections only from hosts using certain certificates having specific SHA-1 fingerprints, list the fingerprints of the accepted certificates in this parameter. For example, trusted-keys("SHA1:00:EF:ED:A4:CE:00:D1:14:A4:AB:43:00:EF:00:91:85:FF:89:28:8F", "SHA1:0C:42:00:3E:B2:60:36:64:00:E2:83:F0:80:46:AD:00:A8:9D:00:15").

To find the fingerprint of a certificate, you can use the following command: openssl x509 -in <certificate-filename> -sha1 -noout -fingerprint

Prerequisites

The sender (also called the client) is the host that has ALTP configured in its destination driver. The receiver (also called the server) is the host that has ALTP configured in its source driver.

1. The sender initiates the connection to the receiver.

2. The sender and the receiver negotiate whether to encrypt the connection and to use compression or not.

3. If the connection should be encrypted, the sender and the receiver perform authentication (as configured in the tls() options of their configuration).

4. If the sender and the receiver have communicated earlier using ALTP, the receiver indicates which was the last message received from the sender.

5. The sender starts sending messages in batches. Batch size depends on the batch-size() parameter of the sender.

   For optimal performance when sending messages to a syslog-ng PE server, make sure that the batch-size() is smaller than the window size set using the log-iw-size() option in the source of your server.

6. When the receiver has successfully processed the messages in the batch, it sends an acknowledgment of the processed messages to the sender.

   What "successfully processed" means depends on the configuration of the receiver, for example, written to disk in a destination, forwarded to a remote destination using not ALTP, dropped because of filter settings, or written to the disk-buffer. (If the messages are forwarded using ALTP, see Using ALTP in a client-relay-server scenario.)

7. After receiving the acknowledgment, the sender sends another batch of messages.