Template:ZMC security notes

You should take care to secure access to enterprise backup tools such as the Zmanda Management Console. Here is a list of some practices to help ensure that the ZMC and backups themselves are available only to authorized network administrators.

• When installing the ZMC, choose https rather than http for ZMC access. Use http only if the administrator, backup server, and all backup clients reside in a single network that is isolated from the internet. Install SSL certificates from a third party Certificate Authority (CA), or install a privately-generated and self-signed certificate. Using the SSL security model with a the appropriate certificate will prevent passwords and other sensitive data from being transmitted in plaintext over the network. If you use the Zmanda Management Console without such a certificate, all https communications between the users and the console (such as passwords) will be visible to anyone with a copy of the ZMC, regardless of account credentials.

• Change the password as soon as you log in to the default Admin account. Changing the password and ZMC user account administration is described here. Only create accounts on the backup server and the ZMC server for those trusted with the data processed by these systems.

• Use backup set ownership as a mechanism to limit access to the user data that is being backed up.

• Ensure that strong passwords (i.e. alpha and numerical, at least 8 characters) are in effect for all login accounts: ZMC accounts, and OS accounts for the backup and MySQL users.

• Enable backup encryption when using the ZMC to back up remote systems over the network. Take care to retain the encryption keys; if they are lost, the backup data will also be lost.

• Examine the zmc_audit logs regularly to ensure that unauthorized persons are not accessing the backup system. Examine the amfetchandresolve entries with special care, as they can show if unauthorized restores are occuring. To find all the restore operations that have been audited, log on to the ZMC server as root, then enter the following command:

grep amfetchandresolve /opt/zmanda/amanda/logs/zmc_audit.log

which will return something like the following if any restores have been executed:

2008-05-07|06:12:51|admin|johnsmith|INSERT INTO task_management (command_in,command_arg,task_name,user_id,configuration_id,status) 
VALUES ('/opt/zmanda/amanda/bin/amfetchandresolve', '--config \'johnsmith\' --client \'localhost\' --diskdev \'/tmp/mait\' --option 
\'KEEP_ORIGINAL\' --temp_dir \'/tmp\' --rs true', 'Restore', '1', '26', 'Initializing')|SUCCEEDED

If johnsmith is not a valid user with administration privileges, or there are restores in the log unexpected by the real-life John Smith, you should change the ZMC account passwords because this is evidence of a security breach.

• Add the following line to the inetd or xinetd (Solaris and MacOSX) configuration file installed on any backup clients:

only_from amanda_server

where amanda_server is the fully-qualified domain name of the backup server used by the client. More detailed instructions on securing bsd/tcp/udp connections can be found here.

In addition to these precautions, you should review the overall security of your network and follow the best practices for the industry.