The following procedure describes how to restore the configuration and data of SSB from a complete backup, for example, after a hardware replacement.
It is possible to receive indexer errors following data restore. Data that was still in the memory of SSB during backup might have been indexed, but as it was not on the hard drive, it was not copied to the remote server.
To make sure that all data is backed up (for example, before an upgrade), shut down syslog-ng before initiating the backup process.
Statistics about syslog-ng and logspace sizes are not backed up. As a result, following a data restore, the Basic Settings > Dashboard page will not show any syslog-ng and logspace statistics about the period before the backup.
To restore the configuration and data of SSB from a complete backup
Connect to your backup server and locate the directory where SSB saves the backups. The configuration backups are stored in the config subdirectory in timestamped files. Find the latest configuration file (the configuration files are called SSB-timestamp.config).
Connect to SSB.
If you have not yet completed the Welcome Wizard, click Browse, select the configuration file, and click Import.
If you have already completed the Welcome Wizard, navigate to Basic Settings > System > Import configuration > Browse, select the configuration file, and click Import.
Navigate to Policies > Backup & Archive/Cleanup. Verify that the settings of the target servers and the backup protocols are correct.
Navigate to Basic Settings > Management > System backup, click Restore now and wait for the process to finish. Depending on the amount of data stored in the backup, and the speed of the connection to the backup server, this may take a long time.
Navigate to Log > Logspaces, and click Restore ALL. Depending on the amount of data stored in the backup, and the speed of the connection to the backup server, this may take a long time.
It may happen that you inadvertently lose the IPMI pasword of your 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.
To apply the procedure outlined here, you will need physical access to a monitor and keyboard.
Press the DEL button when the POST screen comes up while the appliance is booting.
Figure 169: POST screen during booting
In the BIOS, navigate to the IPMI page.
On the IPMI page, select BMC Network Configuration, and press Enter.
Figure 170: IMPI page > BMC Network Configuration option
On the BMC Network Configuration page, select Update IPMI LAN Configuration, press Enter, and select Yes.
Figure 171: BMC Network Configuration page > Update IPMI LAN Configuration
Stay on the BMC Network Configuration page, select Configuration Address Source, press Enter, and select Static.
Figure 172: BMC Network Configuration page > Configuration Address Source
Still on the BMC Network Configuration page, configure the Station IP Address, Subnet Mask, and Gateway IP Address individually.
Figure 173: BMC Network Configuration page > Station IP Address, Subnet Mask, Gateway IP Address
Press F4 to save the settings, and exit from the BIOS.
About a minute later, you will be able to log in on the IPMI web interface.
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.
In Encryption, do NOT select Allow key exchange only with key encryption (key encipherment), because it will result in errors.
The following checklist is a set of recommendations and configuration best practices to ensure that your SSB is configured securely.
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.
When exporting the configuration of SSB, or creating configuration backups, always use encryption. Handle the exported data with care, as it contains sensitive information, including credentials. For more information on encrypting the configuration, see "Encrypting configuration backups with GPG" in the Administration Guide.
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.
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 Timestamping 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. For more information, see "Creating syslog message sources in SSB" in the Administration Guide.
Enable flow-control to prevent message loss. For more information, see "Managing incoming and outgoing messages with flow-control" in the Administration Guide.
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.
Use strong passwords, which have at least 12 characters including lower case letters, upper case letters, numbers, and special characters. For local SSB users, set the password policy strength to strong on AAA > Settings > Minimal password strength. For more information, see "Setting password policies for local users" in the Administration Guide.
Accessing the SSB host directly using SSH is not recommended or supported, except for troubleshooting purposes. In such case, the One Identity Support Team will give you exact instructions on what to do to solve the problem.
For security reasons, disable SSH access to SSB when it is not needed. For more information, see "Enabling SSH access to the SSB host" in the Administration Guide.
Permit administrative access to SSB only from trusted networks. If possible, log messages from clients and administrative access to the SSB web interface should be originated from separate networks.
Configure SSB to send an alert if a user fails to login to SSB. For more information, see the Login failed alert in "System related traps" in the Administration Guide.
Configure Disk space fill up prevention, and configure SSB to send an alert if the free space on the disks of SSB is low. For more information, see "Preventing disk space fill up" 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.
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.