Configuring the IPMI interface from the BIOS after losing IPMI password
It may happen that you inadvertently lose the IPMI pasword of your syslog-ng Store Box (SSB). In that case, you will be required to:
-
Shut down SSB.
-
Unplug the SSB physical appliance's power cord.
-
Wait 30 seconds.
-
Replug the power cord.
-
Restart the appliance.
-
Re-configure the IPMI interface from the BIOS.
To confgure IPMI from the BIOS, complete the following steps.
Incomplete TSA response received
When using a TSA certificate generated with Windows Certificate Authority, you might see a similar error message:
Incomplete TSA response received, TSA HTTP server may be responding slowly; errno='Success (0)', timeout_seconds='30'
When generating the certificate, make sure that you do the following:
Optional Key Usage: If Key Usage is present, it must be digitalSignature and/or nonRepudiation. Other values are not permitted. Make sure that in Encryption, Allow key exchange without key encryption (key agreement) is selected.
|
Caution:
In Encryption, do NOT select Allow key exchange only with key encryption (key encipherment), because it will result in errors. |
For details, see Generating TSA certificate with Windows Certificate Authority on Windows Server 2008 or Generating TSA certificate with Windows Certificate Authority on Windows Server 2012.
Correct Alerting & Monitoring and Management group privilege mismatch
When attempting to upgrade to syslog-ng Store Box(SSB) version 6.3 (or newer), or upload an older configuration, you might see an error message similar to the following:
Pre-check failed
Error upgrading XML database - One or more user groups have group privilege mismatch for the Basic Settings > Alerting & Monitoring and Basic Settings > Management pages.
To continue the upgrade or import process, first, complete the steps in section 'Correct Alerting & Monitoring and Management group privilege mismatch' in https://docadmin.quest.com/syslog-ng-store-box/6.3.0/administration-guide/troubleshooting-ssb
This error is probably due to the fact that one or more of your usergroups currently have
-
Basic Settings > Alerting & Monitoring group privilege, but no Basic Settings > Management group privilege, or have
-
Basic Settings > Management group privilege, but no Basic Settings > Alerting & Monitoring group privilege.
The content of the Alerting & Monitoring and Management group privileges changed in SSB version 6.3 the following way:
-
Instead of a single menu item, the configuration of Basic Settings > Alerting & Monitoring will be split to Basic Settings > Alerting and Basic Settings > Monitoring.
-
The configuration of Basic Settings > Management > SNMP trap settings and Basic Settings > Management > SNMP agent settings will be moved to Basic Settings > Alerting > SNMP trap settings and Basic Settings > Monitoring > SNMP agent settings in the menu, respectively.
These changes to the group privilege contents will NOT be mapped during the upgrade process.
As a result, the usergroups that currently have Basic Settings > Alerting & Monitoring group privilege would gain additional access rights to SNMP trap settings and SNMP agent settings.
Before you start the upgrade process, you must change the group privileges of these usergroups the following way:
-
Navigate to AAA > Access Control, and Edit the group privileges of the usergroup that
-
only has Basic Settings > Alerting & Monitoring group privilege, but no Basic Settings > Management group privilege, or
-
only has Basic Settings > Management group privilege, but no Basic Settings > Alerting & Monitoring group privilege.
-
Change your configuration so that both group privileges are the same. Either grant both Basic Settings > Management and Basic Settings > Alerting & Monitoring group privileges to the usergroup, or revoke both group privileges.
-
Repeat the previous steps for all affected usergroups.
-
Commit your changes and retry upgrading your machine to SSB version 6.3.
Security checklist for configuring SSB
Security checklist for configuring SSB
The following checklist is a set of recommendations and configuration best practices to ensure that your syslog-ng Store Box(SSB) is configured securely.
General security recommendations
-
As a general recommendation, use 2048-bit RSA keys (or stronger), AES-256-CBC cipher (or stronger), and SHA-256 hash algorithm (or stronger). For more specific information, see the relevant sections of the Administration Guide.
-
Use mutual authentication whenever possible, as detailed below, when configuring log sources, log destinations or LDAP user database.
-
One Identity recommends that you generate certificates using your own public key infrastructure (PKI) solution and then upload them to SSB. Certificates generated by SSB cannot be revoked, therefore, they can become a security risk if compromised.
-
-
Use every keypair or certificate only for one purpose. Do not reuse cryptographic keys or certificates, for example, do not use the same certificate for the SSB webserver and for encrypting logstores.
-
For backward compatibility reasons, SSB does not enforce strict security configuration for backup, archive, and share - using SMB/CIFS and NFS - therefore, any security expectations need to be ensured by the joining peers and the underlying network architecture. For more information on backups and archiving, see Data and configuration backups in the Administration Guide and Archiving and cleanup in the Administration Guide.
Log traffic and storage specific security recommendations
-
When creating logspaces on Log > Logspaces, use LogStore type rather than plain text files and apply encryption.
-
When encrypting log files, One Identity recommends:
-
Using 2048-bit RSA keys (or stronger). For more information, see Creating logstores in the Administration Guide.
-
Using AES-256-CBC cipher (or stronger) and SHA-256 hash algorithm (or stronger). For more information, see General syslog-ng settings in the Administration Guide.
-
One Identity recommends using User Temporary private key store for decrypting and viewing encrypted logs on the Search > Logspaces interface. Avoid using User Permanent private key store or shared decryption private key uploaded on the Log > Logspaces interface. For more information, see Browsing encrypted logspaces in the Administration Guide.
-
For the Server certificate and the Time Stamping Authority (TSA) certificate, upload the private key as well. One Identity recommends using 2048-bit RSA keys (or stronger). These two certificates must be issued by the same Certificate Authority. For more information on uploading certificates and keys created with an external PKI, see Uploading external certificates to SSB in the Administration Guide.
-
When granting user privileges, make sure that only the intended users can access logspaces.
By default, members of the search group can view the stored messages online. Use the Access control option to control which usergroups can access a logspace. For more information, see Managing user rights and usergroups in the Administration Guide.
-
Configure each logsource in SSB at Log > Sources as follows:
-
For Transport, select TLS.
-
For Incoming log protocol and message format, select Syslog (IETF-syslog, RFC 5452).
-
For Peer verification, select Required-trusted.
-
For Cipher suite, select Secure.
By applying the Secure cipher suite, SSB will not allow permissive cipher suites to be used for remote connections.
-
If log messages must be forwarded outside the box, configure log destinations at Log > Destinations in a similar way as the logsources described above (Steps 1-4). Note that you cannot set cipher suites since the TLS server is the remote side (Step 5). For more information, see Forwarding log messages to remote servers in the Administration Guide.
-
Consider that connections for log source or destination types UDP, TCP, SQL, and SNMP are not encrypted. Even though ALTP is encrypted, it can still be compromised.
-
Enable flow-control to prevent message loss. For more information, see Managing incoming and outgoing messages with flow-control in the Administration Guide.
Accessing SSB
-
Disallow permissive cipher suites for HTTPS connections towards the SSB webserver. When configuring the cipher suite capability for HTTPS connections, use the Secure cipher suite set under Basic Settings > Management > Web interface and RPC API settings > Cipher suite. For more information, see Web interface and RPC API settings in the Administration Guide.
-
-
-
-
-
-
Prefer configuring SSB to use the local user database. If LDAP is needed, make sure to configure mutual authentication. For more information on local user management, see Managing SSB users locally in the Administration Guide.
Networking considerations
-
SSB stores sensitive data. Use a firewall and other appropriate controls to ensure that unauthorized connections cannot access it.
-
If possible, enable management access to SSB only from trusted networks.
-
Make sure that the HA interface of SSB is connected to a trusted network.
-
Make sure that for the communication between the peer nodes, for example, log sending, log receiving, or webserver interface communication, you have the properly secure configuration as described above.