From the 3.16 release Cognito supports automated backup, wherein a backup archive is created and transferred to an external server.
These backups can be used to restore a Cognito unit to a running state after a component failure or other disaster, or they can be used to restore system state to a replacement brain, should a Cognito unit suffer a full system failure.
For backing up to another Vectra brain appliance please see the Help Center article: Brain To Brain Automated Backups
To restore a backup created using the method below please see the Help Center article: Restoring A Backup
The brain appliance communicates to the backup server using SCP or SFTP on TCP port 22. This connection is required unidirectionally with the brain appliance initiating the connection.
The archives capture all known host objects, detection objects (including their PCAP files), and campaign objects, as well as Cognito configuration information including users, roles, triage rules, sensor pairings, and UI settings.
All backups are encrypted using GPG with a Vectra-proprietary key. Backups can only be decrypted by Vectra support at this time.
All backups are "full backups", as opposed to incremental or other strategies.
The archive size will vary with the number of hosts, detections, and campaigns on the system. It is typically expected that the archives will reach a size of 5-50 GB, with the largest backups being taken on the larger and busier deployments.
Version 5.8 extends the SFTP backup mechanism to support username / password along with the existing SSH-Key based authentication. Versions prior to 5.8, only SSH-Key based authentication to a remote storage host is supported. The backup archive file is securely transferred via either SCP or SFTP. For ease of implementing secure hosting without permitting SSH command execution, we recommend SFTP deployments where possible.
Note: Processes on the Cognito brain are stopped for approximately 10 minutes during a backup. No traffic on the brain's direct capture interfaces will be processed during the backup. However, any attached sensors will buffer metadata during this period, which can serve to minimize the impact in production.
The backup process will generate audit log entries tracking backup start, backup complete, backup transfer start, and backup transfer complete. In order to utilize this, enable audit logs via Syslog under the Notifications tab in Settings.
An MD5 hash of the backup archive is provided via audit logs. The integrity of the backup can be independently verified using this hash.
The backup server may be any SCP/SFTP compatible server that supports RSA key authentication. In most cases our customers use Linux servers based upon the common Linux distributions, e.g. Ubuntu or Redhat; however, any backup server supporting SCP/SFTP with RSA key authentication will work.
Please note that in SCP mode SSH (shell) access to the server is required for the backup to operate normally, requiring that the backup server use a Linux operating system.
The following information is required:
- A network-connected server to which the backup archives are to be sent. It is recommended that the server have at least 100–500 GB of disk space to store the backup files, depending on your own retention strategy.
- The transfer protocol that should be used (currently SCP or SFTP are supported).
- The name of the backup folder on the particular server.
- A username for the server, this username will be used for the transfer.
- The day-of-week and time-of-day for scheduling. Currently backup runs on a weekly basis.
During the setup, a unique key will be generated from the Vectra Cognito brain for the backup. The generated public key will need to be added to the list of authorized keys for the user account on the target server to allow the copy of the file to the target server. This step should be completed by the administrator or user of the target server.
All configuration commands listed below should be entered by the user at the CLI prompt after logging in as the 'vectra' user.
All commands can be suffixed with '-h' or '--help' to provide contextual help for the command.
The retention can be defined in the backup configuration using the argument:
--target-rotate N ( N being the number of backups 0=off, eg. 5 = last 5 backups )
If not defined --target-rotate will have the value of 0 thus backup rotation will be disabled. In this case, you may want to perform the backup on the longer-term storage facility directly, based on organizational needs for archiving/retention/audit.
We recommend keeping at least the last 5 backups on the external server if backups are performed on a weekly basis.
Backup retention notes
To ensure that the backup server has enough space for a new backup the backup service will delete old backups before starting the transfer of a new backup. This may mean that your backup server temporarily shows one fewer archive backup than configured by this option.
If using SCP to transfer the backups please ensure that SSH and remote command execution are permitted. When using SCP the brain will attempt to SSH to the backup server to rotate the backup files, if this is not permitted then the backup rotation will fail and old backups will accrue.
The following process may be used to configure a new automated backup:
backup clear backup configure-target --target-user <username> [--target-sftp-password <password>] --target-server <hostname|ip> --target-path <pathname> --copy-mode <scp|sftp> --enable-external --target-rotate 5 backup show backup test backup enable --weekday <dayofweek> --hour <hourofday>
In the above example, adding the optional --target-sftp-password will allow for username/password based authentication on the SFTP server, the copy-mode must be SFTP.
For example, the following sequence of commands sets up a backup on Sunday at 2:00 AM. The data is copied to /mnt/backup/cognito on storage1.example.local using the username 'backup' and keeping the last 5 backups :
backup clear backup configure-target --target-user backup --target-server storage1.example.local --target-path /mnt/backup/cognito --copy-mode sftp --enable-external --target-rotate 5 backup show
Full list of options available for configure-target can be found below:
vscli > backup configure-target --help
Usage: backup configure-target [OPTIONS]
Configure the target for external copy
--target-brain TEXT Hostname of brain which receives backups.
--brain-key TEXT Target brain API key.
--enable-brain Enable backup copy to remote brain.
--disable-brain Disable backup copy to remote brain.
--target-user TEXT Target SSH Username to copy backup file.
--target-server TEXT Target Server to copy backup file.
--target-path TEXT Target Path to copy backup file.
--target-sftp-password Target SFTP Password option (5.8 and above only)
--s3-bucket-name TEXT Target S3 Bucket to copy backup file.
--aws-access-key-id TEXT AWS Access Key ID for S3 backups.
--aws-secret-access-key TEXT AWS Secret Access Key for S3 backups.
--aws-region-name TEXT AWS Region for S3 backups.
--target-rotate INTEGER Max backups to keep on target. 0=off.
--clear-sftp-password Clear SFTP password
--copy-mode [scp|sftp|s3] Copy protocol to use for external copy.
--enable-external Enable external copy of backup.
--disable-external Disable external copy of backup.
-h, --help Show this message and exit.
The RSA public key from the 'backup show' command should now be copied to the ~/.ssh/authorized_keys file in the home directory of the target user on the target server.
This step should be complete and tested before enabling the scheduled backup. The following command will copy a temporary file to the backup server to verify that the target is reachable:
Once tested the backup may be enabled:
backup enable --weekday sunday --hour 2
Mar 21 14:09:45 - -: AUDIT [dvc="192.168.51.30" dvchost="192.168.51.30" version="3.16" user="admin" role="None" source="None" type="user_action" outcome="success" message="Scheduled Backup started"]
Mar 21 14:20:08 - -: AUDIT [dvc="192.168.51.30" dvchost="192.168.51.30" version="3.16" user="admin" role="None" source="None" type="user_action" outcome="success" message="Scheduled Backup completed"]
Backup copy start:
Mar 21 14:50:08 - -: AUDIT [dvc="192.168.51.30" dvchost="192.168.51.30" version="3.16" user="admin" role="None" source="None" type="user_action" outcome="success" message=”Scheduled Backup copy to external target started"]
Backup copy completed (success)
Mar 21 14:55:08 - -: AUDIT [dvc="192.168.51.30" dvchost="192.168.51.30" version="3.16" user="admin" role="None" source="None" type="user_action" outcome="success" message=”Scheduled Backup copy to external target completed. md5sum\=1122334455”]
Backup copy completed (failure)
Mar 21 14:55:08 - -: AUDIT [dvc="192.168.51.30" dvchost="192.168.51.30" version="3.16" user="admin" role="None" source="None" type="user_action" outcome="failure" message=”Scheduled Backup copy to external target completed.”]