지금 지원 담당자와 채팅
지원 담당자와 채팅

syslog-ng Premium Edition 7.0.32 - Administration Guide

Preface Introduction to syslog-ng The concepts of syslog-ng Installing syslog-ng PE The syslog-ng PE quick-start guide The syslog-ng PE configuration file Collecting log messages — sources and source drivers
How sources work default-network-drivers: Receive and parse common syslog messages internal: Collecting internal messages file: Collecting messages from text files google-pubsub: collecting messages from the Google Pub/Sub messaging service wildcard-file: Collecting messages from multiple text files linux-audit: Collecting messages from Linux audit logs mssql, oracle, sql: collecting messages from an SQL database network: Collecting messages using the RFC3164 protocol (network() driver) office365: Fetching logs from Office 365 osquery: Collect and parse osquery result logs pipe: Collecting messages from named pipes program: Receiving messages from external applications python: writing server-style Python sources python-fetcher: writing fetcher-style Python sources snmptrap: Read Net-SNMP traps 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 udp-balancer: Receiving UDP messages at very high rate unix-stream, unix-dgram: Collecting messages from UNIX domain sockets windowsevent: Collecting Windows event logs
Sending and storing log messages — destinations and destination drivers
elasticsearch2>: Sending messages directly to Elasticsearch version 2.0 or higher (DEPRECATED) elasticsearch-http: Sending messages to Elasticsearch HTTP Event Collector file: Storing messages in plain-text files google_pubsub(): Sending logs to the Google Cloud Pub/Sub messaging service google_pubsub-managedaccount(): Sending logs to the Google Cloud Pub/Sub messaging service authenticated by Google Cloud managed service account hdfs: Storing messages on the Hadoop Distributed File System (HDFS) http: Posting messages over HTTP kafka(): Publishing messages to Apache Kafka (Java implementation) (DEPRECATED) kafka-c(): Publishing messages to Apache Kafka using the librdkafka client (C implementation) logstore: Storing messages in encrypted files mongodb: Storing messages in a MongoDB database network: Sending messages to a remote log server using the RFC3164 protocol (network() driver) pipe: Sending messages to named pipes program: Sending messages to external applications python: writing custom Python destinations sentinel(): Sending logs to the Microsoft Azure Sentinel cloud snmp: Sending SNMP traps smtp: Generating SMTP messages (email) from logs splunk-hec: Sending messages to Splunk HTTP Event Collector sql(): Storing messages in an SQL database stackdriver: Sending logs to the Google Stackdriver cloud 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) unix-stream, unix-dgram: Sending messages to UNIX domain sockets usertty: Sending messages to a user terminal — usertty() destination Client-side failover
Routing messages: log paths, flags, and filters Global options of syslog-ng PE TLS-encrypted message transfer Advanced Log Transport Protocol Reliability and minimizing the loss of log messages Manipulating messages parser: Parse and segment structured messages Processing message content with a pattern database Correlating log messages Enriching log messages with external data Monitoring statistics and metrics of syslog-ng Multithreading and scaling in syslog-ng PE Troubleshooting syslog-ng Best practices and examples The syslog-ng manual pages Glossary

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

Available in version 7.0.12 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 PE 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 PE application uses this certificate to authenticate the syslog-ng PE 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 PE 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 PE. 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")
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.

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.

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 PE supports only DH parameter files in the PEM format. If you do not set this parameter, syslog-ng PE 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).

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.

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

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

Starting with syslog-ng PE version 7.0.7, you can use password-protected private keys in the network() and syslog() source and destination drivers. The path and the filename cannot contain whitespaces. For details, see Password-protected keys.

peer-verify()
Accepted values: optional-trusted | optional-untrusted | required-trusted | required-untrusted
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 PE will reject the connection.

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 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.

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.

Advanced Log Transport Protocol

Logging using ALTP

Caution:

Note that in earlier versions of syslog-ng Premium Edition, Advanced Log Transport Protocol is called Reliable Log Transfer Protocol (RLTP).

The syslog-ng PE application can send and receive log messages in a reliable way over the TCP transport layer using the Advanced Log Transport Protocol (ALTP). ALTP is a proprietary transport protocol that prevents message loss during connection breaks. The transport is used between syslog-ng PE hosts (for example, a client and a server, or a client-relay-server), and interoperates with the mechanisms of syslog-ng PE's flow-control and the reliable disk-buffer option, thus providing the best way to prevent message loss. The sender detects which messages the receiver has successfully received. If messages are lost during the transfer, the sender resends the missing messages, starting from the last successfully received message. Therefore, messages are not duplicated at the receiving end in case of a connection break (however, in failover mode, this is not completely ensured).

ALTP also allows for encrypted and non-encrypted connections to be received on the same port, using a single source driver.

NOTE: Because of the communication overhead, the ALTP protocol is slower than other transport protocols, which might be a problem if you need to collect a high amount (over 200000 messages per second) of log messages on your log server. For performance details of syslog-ng PE see the syslog-ng Premium Edition Performance Guideline at the syslog-ng Premium Edition Documentation page.

NOTE: Make sure that you have set the value of the log_msg_size() parameter large enough in your configuration. If its size is less than the size of the sent messages, it might result in disk fill-up and no incoming logs.

Caution:

    In the following cases, it is possible to lose log messages even if you use ALTP:

  • If you use ALTP together with the non-reliable disk-buffer option, it is possible to lose logs.

  • When sending logs through a relay that is using the non-reliable disk-buffer option, it is possible to lose logs if the relay crashes.

  • When sending logs through a relay that is using the non-reliable disk-buffer option, it is possible that logs are duplicated if the relay crashes, or it is stopped.

  • If the underlying disk system of syslog-ng PE fails to write the log messages to the disk, but it does not return a write error, or some other hardware or operating-system error happens.

The ALTP protocol works on top of TCP, and can use STARTTLS for encryption. ALTP supports IPv4 and IPv6 addresses. Inside the ALTP message, the message can use any format, for example, RFC3164 (BSD-syslog) or RFC5424 (IETF-syslog). The default port of ALTP is 35514.

ALTP can be added to the configuration like a transport protocol within the syslog() driver and the network() driver.

How ALTP connections work

This procedure summarizes how two syslog-ng PE hosts (a sender and a receiver) communicate using the Advanced Log Transport Protocol (ALTP).

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.

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택