Chat now with support
Chat with Support

syslog-ng Store Box 6.10.0 - Administration Guide

Preface Introduction The concepts of SSB The Welcome Wizard and the first login Basic settings User management and access control Managing SSB Configuring message sources Storing messages on SSB Forwarding messages from SSB Log paths: routing and processing messages Configuring syslog-ng options Searching log messages Searching the internal messages of SSB Classifying messages with pattern databases The SSB RPC API Monitoring SSB Troubleshooting SSB Security checklist for configuring SSB Glossary

Forwarding log messages to remote servers

This section describes how to forward messages from syslog-ng Store Box(SSB) to a remote server.

To forward messages from SSB to a remote server

  1. Navigate to Log > Destinations and select to create a new remote destination.

  2. Select Remote host.

    Figure 172: Log > Destinations — Creating server destinations

  3. Enter the IP address or hostname of the remote server into the Address field. Enter the port where the server is accepting syslog messages into the Port field.

    Note that the Address and Port pair must be unique for each remote destination.

  4. Select the network protocol used to transfer the log messages from the Transport field. The UDP, TCP, and the encrypted TLS protocols are available. The UDP and TLS protocols have additional parameters.

    When forwarding messages using UDP, the remote host will see the messages as if they originated from SSB. Select the Spoof source address option to make them seem to originate from their original sender.

    Caution:

    When using the Spoof source address option, SSB automatically truncates long messages to 1024 bytes, regardless of the Log > Options > Message size setting.

    For TLS, select a method to verify the identity of the remote host. The following options are available:

    • None: Do not request a certificate from the remote host, and accept any certificate if the host sends one.

    • Optional trusted: If the remote host sends a certificate, SSB checks if it is valid (not expired) and that the Common Name of the certificate contains the domain name or the IP address of the host. If these checks fail, SSB rejects the connection. However, SSB accepts the connection if the host does not send a certificate.

    • Optional untrusted: Accept any certificate shown by the remote host. Note that the host must show a certificate.

    • Required trusted (default setting): Verify the certificate of the remote host. Only valid certificates signed by a trusted certificate authority are accepted. See Uploading external certificates to SSB for details on importing CA certificates. Note that the Common Name of the certificate must contain the domain name or the IP address of the host.

    • Required untrusted: SSB requests a certificate from the remote host, and rejects the connection if no certificate is received. However, SSB accepts the connection if:

      • the certificate is not valid (expired), or

      • the Common Name of the certificate does not contain the domain name or the IP address of the host.

    NOTE: Consult the documentation of the remote server application to determine which protocols are supported.

    UDP is a highly unreliable protocol and a high amount of messages may be lost without notice during the transfer. Use TCP or TLS instead whenever possible.

  5. Select the syslog protocol to use from the Syslog protocol field.

    • To use the legacy BSD-syslog protocol described in RFC 3164, select Legacy and specify the message template to use. Select Legacy to use the message format described in the RFC, or ISO date to replace the original time stamp with an ISO8061 compliant time stamp that includes year and timezone information. To customize the format of the message contents using macros, select Custom message part only, or Custom on-wire message to completely reformat the message (including the headers). For details on using macros, see Hard versus soft macros in the syslog-ng PE Administration Guide. If you have no special requirements, use the ISO date template.

    • Use the new IETF-syslog protocol. Note that most syslog applications and devices currently support only the legacy protocol. Consult the documentation of the remote server application to determine which protocols are supported. If you need, you can customize the contents of the message using macros. Note that for the IETF-syslog protocol, the header cannot be customized. For details on using macros, see .

  6. If SSB would send several messages with identical content to the destination, it can send only a single message and a line Last message repeated n times.. Enter the number of seconds to wait for identical messages into the Suppress timeout field. This option corresponds to the suppress() parameter of syslog-ng.

  7. To limit the maximum number of messages sent to the destination per second, enter the maximum number of messages into the Message throttle field. Use this output-rate-limiting functionality only when using disk-buffer as well to avoid the risk of losing messages. Specifying 0 or a lower value sets the output limit to unlimited. This option corresponds to the throttle() parameter of syslog-ng.

  8. The time stamps of most log messages is accurate only to the second. The syslog-ng Store Box(SSB) appliance can include more accurate time stamps: set how many digits should be included in the Timestamp fractions of a second field. This option corresponds to the frac_digits() parameter of syslog-ng.

  9. If the server and SSB are located in a different timezone and you use the Legacy message template (which does not include timezone information), select the timezone of the server from the Timezone field.

  10. Set the size of the disk buffer (in Megabytes) in the Output disk buffer field. If the remote server becomes unavailable, SSB will buffer messages to the hard disk, and continue sending the messages when the remote server becomes available. This option corresponds to the log_disk_fifo_size() parameter of syslog-ng.

    Note that SSB does not pre-allocate the hard disk required for the disk buffer, so make sure that the required disk space is available on SSB. For details on creating archiving policies and adjusting the disk-fillup prevention, see Archiving and cleanup and Preventing disk space fill up.

    Example: Calculating disk buffer size

    The size of the disk buffer you need depends on the rate of the incoming messages, the size of the messages, and the length of the network outage that you want to cover. For example:

    • SSB is receiving 15000 messages per second

    • On the average, one message is 250 bytes long

    • You estimate that the longest time the destination will be unavailable is 4 hours

    In this case, you need a disk buffer for 250 [bytes] * 15000 [messages per second] * 4*60*60 [seconds] = 54000000000 [bytes], which is 54000 Megabytes (in other words, a bit over 50 GB).

  11. Click .

  12. To start sending messages to the destination, include the new destination in a logpath. For details, see Log paths: routing and processing messages.

Forwarding log messages to the Microsoft Azure Sentinel cloud

This section describes how to forward messages from syslog-ng Store Box (SSB) to the Microsoft Azure Sentinel cloud (Azure Sentinel).

Azure Sentinel is Microsoft's native cloud-based SIEM solution. Beside Microsoft's own cloud services, it can accept log messages from external sources. Microsoft provides 26 predefined Data connectors and a HTTP Data Collector API for further integrations.

From version 6.7.0, SSB uses the syslog-ng Premium Edition (syslog-ng PE) application's support to post messages to Azure Sentinel over HTTP and Secure HTTP (HTTPS).

For further details about how the application forwards messages to Azure Sentinel, see sentinel: Sending logs to the Microsoft Azure Sentinel cloud in the syslog-ng PE Administration Guide.

For more information about Azure Sentinel, see Microsoft Azure: Azure Sentinel documentation in the Microsoft Azure Documentation.

For more information about Data connectors used in Azure Sentinel, see Microsoft Azure: Connect data sources in the Microsoft Azure Documentation.

NOTE: This section and the other Azure Sentinel-related sections in this documentation are based on Azure Sentinel messaging service concepts and terminology. If you do not use the Azure Sentinel messaging service on a regular basis, One Identity recommends that you read the Azure Sentinel quick-start documentation to familiarize yourself with the messaging service's concepts and terminology before you continue reading these sections.

Prerequisites

This section describes the prerequisites for forwarding messages from syslog-ng Store Box (SSB) to the Microsoft Azure Sentinel cloud (Azure Sentinel).

NOTE: This section and the other Azure Sentinel-related sections in this documentation are based on Azure Sentinel messaging service concepts and terminology. If you do not use the Azure Sentinel messaging service on a regular basis, One Identity recommends that you read the Azure Sentinel quick-start documentation to familiarize yourself with the messaging service's concepts and terminology before you continue reading these sections.

Prerequisites to using the Azure Sentinel destination
  • WORKSPACE ID (which will function as the Workspace id on the SSB web interface)

  • PRIMARY KEY (which will function as the Auth secret on the SSB web interface)

NOTE: For more information about the WORKSPACE ID and the PRIMARY KEY on the Azure Sentinel side, see Getting the required credentials to configure syslog-ng PE as a Data Connector for Microsoft Azure Sentinel in the syslog-ng Premium Edition Administration Guide.

Limitations

This section describes the limitations for forwarding messages from syslog-ng Store Box (SSB) to the Microsoft Azure Sentinel cloud (Azure Sentinel).

  • Messages with HTTP 400 response code will be dropped

    If the message sent to Azure Sentinel is invalid, the Azure Sentinel messaging service will reply with an HTTP 400 response code.

    The message can be invalid for either of these reasons:

    • A required argument is missing from the message.

    • The message size exceeds limits.

    • The message itself has an invalid format.

    In these cases, SSB cannot successfully send the messages to Azure Sentinel. These messages would prevent SSB from sending further messages to the messaging service, therefore SSB must drop them.

  • Proxy limitations

    If you use a proxy, consider that only HTTP proxies are supported.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating