Chatta subito con l'assistenza
Chat con il supporto

syslog-ng Open Source Edition 3.25 - Administration Guide

Preface Introduction to syslog-ng The concepts of syslog-ng Installing syslog-ng The syslog-ng OSE quick-start guide The syslog-ng OSE configuration file source: Read, receive, and collect log messages
How sources work default-network-drivers: Receive and parse common syslog messages internal: Collecting internal messages file: Collecting messages from text files wildcard-file: Collecting messages from multiple text files linux-audit: Collecting messages from Linux audit logs network: Collecting messages using the RFC3164 protocol (network() driver) nodejs: Receiving JSON messages from nodejs applications mbox: Converting local email messages to log messages osquery: Collect and parse osquery result logs pipe: Collecting messages from named pipes pacct: Collecting process accounting logs on Linux program: Receiving messages from external applications python: writing server-style Python sources python-fetcher: writing fetcher-style Python sources snmptrap: Read Net-SNMP traps sun-streams: Collecting messages on Sun Solaris syslog: Collecting messages using the IETF syslog protocol (syslog() driver) system: Collecting the system-specific log messages of a platform systemd-journal: Collecting messages from the systemd-journal system log storage systemd-syslog: Collecting systemd messages using a socket tcp, tcp6, udp, udp6: Collecting messages from remote hosts using the BSD syslog protocol— OBSOLETE unix-stream, unix-dgram: Collecting messages from UNIX domain sockets stdin: Collecting messages from the standard input stream
destination: Forward, send, and store log messages
amqp: Publishing messages using AMQP collectd: sending metrics to collectd elasticsearch2: Sending messages directly to Elasticsearch version 2.0 or higher (DEPRECATED) elasticsearch-http: Sending messages to Elasticsearch HTTP Bulk API file: Storing messages in plain-text files graphite: Sending metrics to Graphite Sending logs to Graylog hdfs: Storing messages on the Hadoop Distributed File System (HDFS) Posting messages over HTTP http: Posting messages over HTTP without Java kafka: Publishing messages to Apache Kafka (Java implementation) kafka: Publishing messages to Apache Kafka (C implementation, using the librdkafka client) loggly: Using Loggly logmatic: Using Logmatic.io mongodb: Storing messages in a MongoDB database network: Sending messages to a remote log server using the RFC3164 protocol (network() driver) osquery: Sending log messages to osquery's syslog table pipe: Sending messages to named pipes program: Sending messages to external applications pseudofile() python: writing custom Python destinations redis: Storing name-value pairs in Redis riemann: Monitoring your data with Riemann slack: Sending alerts and notifications to a Slack channel smtp: Generating SMTP messages (email) from logs snmp: Sending SNMP traps Splunk: Sending log messages to Splunk sql: Storing messages in an SQL database stomp: Publishing messages using STOMP syslog: Sending messages to a remote logserver using the IETF-syslog protocol syslog-ng(): Forward logs to another syslog-ng node tcp, tcp6, udp, udp6: Sending messages to a remote log server using the legacy BSD-syslog protocol (tcp(), udp() drivers) Telegram: Sending messages to Telegram unix-stream, unix-dgram: Sending messages to UNIX domain sockets usertty: Sending messages to a user terminal: usertty() destination Write your own custom destination in Java or Python Client-side failover
log: Filter and route log messages using log paths, flags, and filters Global options of syslog-ng OSE TLS-encrypted message transfer template and rewrite: Format, modify, and manipulate log messages parser: Parse and segment structured messages db-parser: Process message content with a pattern database (patterndb) Correlating log messages Enriching log messages with external data Statistics of syslog-ng Multithreading and scaling in syslog-ng OSE Troubleshooting syslog-ng Best practices and examples The syslog-ng manual pages Creative Commons Attribution Non-commercial No Derivatives (by-nc-nd) License Glossary

Password-protected keys

Starting with syslog-ng OSE version 3.14, you can use password-protected private keys in the network() and syslog() source and destination drivers.

Restrictions and limitations
  • IMPORTANT: Hazard of data loss! If you use password-protected keys, you must provide the passphrase of the password-protected keys every time syslog-ng OSE is restarted (syslog-ng OSE keeps the passphrases over reloads). The sources and destinations that use these keys will not work until you provide the passwords. Other parts of the syslog-ng OSE configuration will be unaffected.

    This means that if you use a password-protected key in a destination, and you use this destination in a log path that has multiple destinations, neither destinations will receive log messages until you provide the password. In this cases, always use disk-based buffering to avoid data loss.

  • The path and the filename of the private key cannot contain whitespaces.

  • Depending on your platform, the number of passwords syslog-ng OSE can use at the same time might be limited (for example, on Ubuntu 16.04 you can store 16 passwords if you are running syslog-ng OSE as a non-root user). If you use lots of password-protected private keys in your syslog-ng OSE configuration, increase this limit using the following command: sudo ulimit -l unlimited

Providing the passwords

The syslog-ng-ctl credentials status command allows you to query the status of the private keys that syslog-ng OSE uses in the network() and syslog() drivers. The command returns the list of private keys used, and their status. For example:

syslog-ng-ctl credentials status
Secret store status:
/home/user/ssl_test/client-1/client-encrypted.key SUCCESS

If the status of a key is PENDING, you must provide the passphrase for the key, otherwise syslog-ng OSE cannot use it. The sources and destinations that use these keys will not work until you provide the passwords. Other parts of the syslog-ng OSE configuration will be unaffected. You must provide the passphrase of the password-protected keys every time syslog-ng OSE is restarted.

The following log message also notifies you of PENDING passphrases:

Waiting for password; keyfile='private.key'

You can add the passphrase to a password-protected private key file using the following command. syslog-ng OSE will display a prompt for you to enter the passphrase. We recommend that you use this method.

syslog-ng-ctl credentials add --id=<path-to-the-key>

Alternatively, you can include the passphrase in the --secret parameter:

syslog-ng-ctl credentials add --id=<path-to-the-key> --secret=<passphrase-of-the-key>

Or you can pipe the passphrase to the syslog-ng-ctl command, for example:

echo "<passphrase-of-the-key>" | syslog-ng-ctl credentials add --id=<path-to-the-key>

For details on the syslog-ng-ctl credentials command, see The syslog-ng control tool manual page.

TLS options

The syslog-ng application can encrypt incoming and outgoing syslog message flows using TLS if you use the network() or syslog() drivers.

NOTE:

The format of the TLS connections used by syslog-ng is similar to using syslog-ng and stunnel, but the source IP information is not lost.

To encrypt connections, use the transport("tls") and tls() options in the source and destination statements.

The tls() option can include the following settings:

allow-compress()
Accepted values: yes | no
Default: no

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 OSE, reducing the number of transferred messages during a given period.

Available in version 3.19 and later.

ca_dir()
Accepted values: Directory name
Default: none

Description: Name of a directory, that contains a set of trusted CA certificates in PEM format. The CA certificate files have to be named after the 32-bit hash of the subject's name. This naming can be created using the c_rehash utility in openssl. For an example, see Configuring TLS on the syslog-ng clients. The syslog-ng OSE application uses the CA certificates in this directory to validate the certificate of the peer.

cert-file()
Accepted values: Filename
Default: none

Description: Name of a file, that contains an X.509 certificate (or a certificate chain) in PEM format, suitable as a TLS certificate, matching the private key set in the key-file() option. The syslog-ng OSE application uses this certificate to authenticate the syslog-ng OSE client on the destination server. If the file contains a certificate chain, the file must begin with the certificate of the host, followed by the CA certificate that signed the certificate of the host, and any other signing CAs in order.

cipher-suite()
Accepted values: Name of a cipher, or a colon-separated list
Default: Depends on the OpenSSL version that syslog-ng OSE uses

Description: Specifies the cipher, hash, and key-exchange algorithms used for the encryption, for example, ECDHE-ECDSA-AES256-SHA384. The list of available algorithms depends on the version of OpenSSL used to compile syslog-ng OSE. To specify multiple ciphers, separate the cipher names with a colon, and enclose the list between double-quotes, for example:

cipher-suite("ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384")

For a list of available algorithms, execute the openssl ciphers -v command. The first column of the output contains the name of the algorithms to use in the cipher-suite() option, the second column specifies which encryption protocol uses the algorithm (for example, TLSv1.2). That way, the cipher-suite() also determines the encryption protocol used in the connection: to disable SSLv3, use an algorithm that is available only in TLSv1.2, and that both the client and the server supports. You can also specify the encryption protocols using ssl-options().

You can also use the following command to automatically list only ciphers permitted in a specific encryption protocol, for example, TLSv1.2:

echo "cipher-suite(\"$(openssl ciphers -v | grep TLSv1.2 | awk '{print $1}' | xargs echo -n | sed 's/ /:/g' | sed -e 's/:$//')\")"

Note that starting with version 3.10, when syslog-ng OSE receives TLS-encrypted connections, the order of ciphers set on the syslog-ng OSE server takes precedence over the client settings.

crl-dir()
Accepted values: Directory name
Default: none

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.

dhparam-file()
Accepted values: string (filename)
Default: none

Description: Specifies a file containing Diffie-Hellman parameters, generated using the openssl dhparam utility. Note that syslog-ng OSE supports only DH parameter files in the PEM format. If you do not set this parameter, syslog-ng OSE uses the 2048-bit MODP Group, as described in RFC 3526.

ecdh-curve-list()
Accepted values: string [colon-separated list]
Default: none

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

This option is only available when syslog-ng is compiled with OpenSSL version 1.0.2 or later. In the case of older versions, prime256v1 (NIST P-256) is used.

The following example curves work for all versions of OpenSSL that are equal to or later than version 1.0.2:

ecdh-curve-list("prime256v1:secp384r1")
key-file()
Accepted values: Filename
Default: none

Description: The name of a file that contains an unencrypted private key in PEM format, suitable as a TLS key. If properly configured, the syslog-ng OSE application uses this private key and the matching certificate (set in the cert-file() option) to authenticate the syslog-ng OSE client on the destination server.

peer-verify()
Accepted values: optional-trusted | optional-untrusted | required-trusted | required-untrusted | yes | no
Default: required-trusted

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.

The remote peer has:
no certificate invalid certificate valid certificate
Local peer-verify() setting optional-untrusted TLS-encryption TLS-encryption TLS-encryption
optional-trusted TLS-encryption rejected connection TLS-encryption
required-untrusted rejected connection TLS-encryption TLS-encryption
required-trusted rejected connection rejected connection TLS-encryption

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.

Caution:

When validating a certificate, the entire certificate chain must be valid, including the CA certificate. If any certificate of the chain is invalid, syslog-ng OSE will reject the connection.

Starting with syslog-ng OSE version 3.10, you can also use a simplified configuration method for the peer-verify option, simply setting it to yes or no. The following table summarizes the possible options and their results depending on the certificate of the peer.

The remote peer has:
no certificate invalid certificate valid certificate
Local peer-verify() setting no (optional-untrusted) TLS-encryption TLS-encryption TLS-encryption
yes (required-trusted) rejected connection rejected connection TLS-encryption
pkcs12-file()
Accepted values: Filename
Default: none

Description: The name of a PKCS #12 file that contains an unencrypted private key, an X.509 certificate, and an optional set of trusted CA certificates.

If this option is used in the configuration, the value of key-file() and cert-file() will be omitted.

You can use the ca-dir() option together with pkcs12-file(). However, this is optional because the PKCS #12 file may contain CA certificates as well.

Passphrase is currently not supported.

Example: Using pkcs12-file()

In the following example, the first command creates a single PKCS #12 file from the private key, X.509 certificate, and CA certificate files. Then, the second half of the example uses the same PKCS #12 file in the syslog-ng configuration.

Example:
$ openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca.crt -out server.p12
Example configuration:
source s_tls {
    syslog(
        transport(tls)
        tls(
            pkcs12-file("/path/to/server.p12")
            ca-dir("/path/to/cadir") # optional
            peer-verify(yes)
        )
    );
};
sni()
Accepted values: yes | no
Default: no

Description: When set to yes in a destination that uses TLS encryption, this option enables Server Name Indication (also called Server Name Identification, SNI). The syslog-ng OSE sends the hostname or the IP address set in the destination to the server during the TLS handshake.

Available in syslog-ng OSE3.24 and newer.

Example: Using Server Name Indication

The following destination sends the hostname of its destination during the TLS handshake.

destination demo_tls_destination_with_sni {
    network(
         "logserver.example.com" 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")
            sni(yes)
        )
    );
};
ssl-options()
Accepted values: comma-separated list of the following options: no-sslv2, no-sslv3, no-tlsv1, no-tlsv11, no-tlsv12, none
Default: no-sslv2

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 OSE 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 OSE3.7 and newer.

Example: Using ssl-options

The following destination explicitly disables SSL and TLSv1.0

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()
Accepted values: list of accepted distinguished names
Default: none

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()
Accepted values: list of accepted SHA-1 fingerprints
Default: none

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

NOTE:

When using the trusted-keys() and trusted-dn() parameters, note the following:

  • First, the trusted-keys() parameter is checked. If the fingerprint of the peer is listed, the certificate validation is performed.

  • If the fingerprint of the peer is not listed in the trusted-keys() parameter, the trusted-dn() parameter is checked. If the DN of the peer is not listed in the trusted-dn() parameter, the authentication of the peer fails and the connection is closed.

template and rewrite: Format, modify, and manipulate log messages

This chapter explains the methods that you can use to customize, reformat, and modify log messages using syslog-ng Open Source Edition.

Customize message format using macros and templates

The following sections describe how to customize the names of logfiles, and also how to use templates, macros, and template functions.

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione