SSB can receive SNMP messages using the SNMPv2c protocol and convert these messages to syslog messages. SNMP messages are received using a special SNMP source that can be used in log paths like any other source. This section describes how to configure receiving SNMP messages.
To configure receiving SNMP messages
-
Navigate to Log > Options > SNMP source.
-
Ensure that the SNMP source option is enabled.
Figure 95: Log > Options > SNMP source — Receiving SNMP messages
-
The default community of the SNMP messages is public. Modify the Community field if your hosts use a different community.
|
|
NOTE:
SSB can receive messages only from a single community. |
-
To limit which hosts can send SNMP messages to SSB, create a hostlist policy, add the permitted hosts to the policy, and select the policy from the Hostlist field. For details on creating hostlists, see Creating hostlist policies.
-
To limit the rate of messages a host can send to SSB, enter the maximum number of packets (not messages) that SSB is allowed to accept from a single host into the Rate limit field. (This parameter sets the hashlimit parameter of the iptables packet filter that is applied to the source.)
|
|
Caution:
When rate limiting is enabled, and a host sends a large number of messages, SSB processes only the amount set in the Rate limit field. Any additional messages are dropped, and most probably lost. |
-
To use name resolution for SNMP messages, enable the Use DNS option.
-
Click 
.
This section describes how to create a custom syslog message source.
To create a custom syslog message source
-
Navigate to Log > Sources and click 
.
-
Enter a name for the source into the top field. Use descriptive names that help you to identify the source easily.
Figure 96: Log > Sources — Creating new message sources
-
Select the interface of IP alias where SSB will receive the messages from the Listening address field.
-
Enter the port number where SSB should accept the messages (for example 1999).
-
In the Transport field, select the networking protocol (UDP, TCP, TLS, ALTP or ALTP TLS) that your clients use to transfer the messages to SSB.
-
In case of UDP, TCP or TLS: select the syslog protocol used by the clients from the Incoming log protocol and message format section. The ALTP and ALTP TLS sources only work with the IETF-syslog protocol.
-
If the clients use the legacy BSD-syslog protocol (RFC3164), select Legacy (BSD-syslog, RFC3164). This protocol is supported by most devices and applications capable to send syslog messages.
-
If the clients use the new IETF-syslog protocol (for example the clients are syslog-ng 3.0 applications that use the syslog driver, or other drivers with the flags(syslog-protocol) option), select Syslog (IETF-syslog, RFC 5452).
To disable syslog message parsing and store the complete log in the message part, select Do not parse. It is useful if incoming messages do not comply with the syslog format.
-
When using TLS, SSB displays a certificate to the client. This certificate can be set at Log > Options > TLS settings (for details, see Setting the certificates used in TLS-encrypted log transport). Optionally, SSB can perform mutual authentication and request and verify the certificate of the remote host (peer). Select the verification method to use from the Peer verification field.
-
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.
When using ALTP TLS, SSB only accepts Required-trusted peer verification.
|
|
Caution:
UDP is a highly unreliable protocol, when using UDP, a large number of messages may be lost without any warning. Use TCP, TLS or ALTP whenever possible. |
-
Configure other, source-related options in the Other source options section, depending on what transport you have selected.
-
When using TCP or TLS, you can set the maximum number of parallel connections in the Maximum connections field. This option corresponds to the max_connections() syslog-ng parameter.
In case of ALTP or ALTP TLS: enter the number of maximum connections. The default value is 1000 connections. Select Allow compression to allow compression on level 6. Compression level cannot be changed.
-
When using TLS or ALTP TLS, configure the strength of the allowed cipher suites using one of the following options:
-
Compatible: It is a large set of cipher suites determined by the following cipher string:
ALL:!aNULL:!eNULL
The Compatible setting may allow permitting (and hence not safe) cipher suites for the Transport Layer Security (TLS) negotiations.
-
Secure: A smaller and more strict set of cipher suites where vulnerable cryptographic algorithms are eliminated. This cipher suite set is determined by the following cipher string:
HIGH:!COMPLEMENTOFDEFAULT:!aNULL:!eNULL:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA:!ECDHE-RSA-AES128-SHA:!ECDHE-RSA-AES256-SHA:!AES128-SHA:!AES256-SHA
-
In the Hostname and timestamp related settings section, you can configure the following:
-
To accept messages only from selected hosts, create a hostlist and select it in the Hostlist field. For details on creating hostlists, see Creating hostlist policies.
-
Set the Timezone option of the incoming messages if needed.
-
If the information sent by the hosts to this source can be trusted, enable the Trusted option. SSB keeps the timestamps and the hostname of the messages sent by trusted clients. This corresponds to enabling the keep_timestamp() and keep_hostname() syslog-ng options for the source.
-
Select the Use FQDN option if you wish to store the full domain name of the sender host.
-
Select the name resolving method to use from the Use DNS field.
-
To configure Message rate alerting for the source, see Configuring message rate alerting.
-
Set the character Encoding option of the incoming messages if needed.
-
Click .
-
Optional step: If you want to receive messages using the ALTP or ALTP TLS protocol, make sure that you have configured your syslog-ng clients to transfer the messages to SSB using ALTP or ALTP TPS protocol. For details, see Advanced Log Transfer Protocol in The syslog-ng Premium Edition Administrator Guide.
SSB stores log messages in binary or plain text log files called logspaces. You can define multiple logspaces, remote logspaces, and configure filtered subsets of each logspace.
Binary log files (logstores) correspond to the encrypted logstore() destination of syslog-ng. Logstores can be compressed, encrypted, and timestamped by an external Timestamping Authority (TSA). To make the contents of the logstore searchable, you can create a separate indexer configuration for each logstore.
A multiple logspace aggregates messages from multiple SSBs (located at different sites), allowing you to view and search the logs of several SSBs from a single web interface without having to log on to several different interfaces.
Remote logspaces enable you to access and search logspaces (including filtered logspaces) on other SSB appliances.
Filtered logspaces allow you to create a smaller, filtered subset of the logs contained in an existing local, remote or multiple logspace. Assigning a user group to a filtered logspace enables fine-grained access control by creating a group that sees only a subset of the logs from a logspace.
Summary of multiple, remote, and filtered logspace types provides a summary and comparison of these three logspace types.
Table 7: Summary of multiple, remote, and filtered logspace types
| Multiple |
Multiple SSBs located at different sites |
Aggregate messages from multiple logspaces into a single logspace
Pre-filter log messages and share with only select user groups |
✔ |
✔ |
| Remote |
Remote SSB |
Access a logspace on another SSB |
✔ |
✔ |
| Filtered |
Local / multiple / remote SSB(s) |
Control access to a logspace at a granular level by granting access only to a subset of a logspace |
✔ |
N/A |
By default, SSB has the following logspaces:
Figure 97: Log > Logspaces — Default logspaces in SSB
-
local: An unencrypted, binary logspace for storing the log messages of SSB.
-
center: An unencrypted, binary logspace for storing the log messages sent by the clients.
Logspaces are stored locally on the hard disk of SSB. To access a logspace remotely, you can configure another SSB to view and search the logspace as a remote logspace, or you can make the logspace accessible as a network drive.
Logstores are logspaces with binary log files for storing log messages sent by the clients. Logstores can be compressed, encrypted, and timestamped by an external Timestamping Authority (TSA). To make the contents of the logstore searchable, you can create a separate indexer configuration for each logstore.
The following limitations apply to logstores:
-
Indexing logstore files is currently limited: the indexer can handle only one file from a logstore for every day (SSB automatically starts a new log file for every day).
-
Logstore files consist of chunks. In rare cases, if the syslog-ng application running on SSB crashes for some reason, it is possible that a chunk becomes broken: it contains log messages, but the chunk was not finished completely. However, starting with SSB version 2 F1 the syslog-ng application running on SSB processes log messages into a journal file before writing them to the logstore file, reducing message loss even in the case of an unexpected crash.
Similarly, if the indexer application crashes for some reason, it may be possible that some parts of a logstore file are not indexed, and therefore the messages from this part of the file do not appear in search results. This does not mean that the messages are lost. Currently it is not possible to reindex a file.
These limitations will be addressed in future versions of SSB.
