Data Encryption
Data encryption can be done either on the Amanda server or the Amanda client. Data encrytion can be configured for each backup unit (disklist file entry). Data encryption is configured as part of the dumptype configuration in amanda.conf configuration file.
Use data encryption only if need as it requires lot of CPU resources and can potentially increase the backup window. Amanda's flexibility in specifying data encryption method at fine granularity helps to balance the data security needs versus the backup window.
Amanda Enterprise edition provides three reference crypt programs for data encryption. These programs should be sufficient to meet most of the data encryption needs. Amanda also supports custom encryption programs for backup data. Choose the appropriate data encryption program based on your needs after reviewing the advantages and dis-advantages of each program.
A critical element of data encryption is the crypt key and passphrase management. Please consider how the keys will be managed and who will have access to keys before choosing a encryption method. The default protection in Amanda for keys and passphrases uses Unix file user permissions. Please contact Zmanda services ([email protected]) if you need more help with crypt keys management.
Table: Various encryption programs in Amanda enterprise edition
| Program | Pre-Requisite | Encryption Method | Cipher Algorithm supported | Pro | Con | Misc |
|---|---|---|---|---|---|---|
| amcrypt | aespipe, uuencode, gpg | Symmetric | AES128,AES192,AES256 | Very secure(1) | setup required, passphrase to store | MD5 IV and 64 AES keys to en/decrypt |
| amcryptsimple | gpg | Symmetric | AES128,AES192,AES256,3DES, CAST5,BLOWFISH,TWOFISH | Easy to deploy | passphrase to store | passphrase to en/decrypt |
| amgpgcrypt | gpg | public-key | AES128,AES192,AES256,3DES, CAST5,BLOWFISH,TWOFISH | no need to store decryption key | amrecover (2) does not work | pub-key to encrypt, private-key to decrypt |
(1) multi-key (up to 64) keys are rotated for encryption. Almost impossible to crack.
(2) since private key is not stored in the system, use amrestore to restore backup data.
Transport Encryption
Amanda Enterprise edition provides transport encryption using OpenSSH. OpenSSH allows Amanda to encrypt the transfer of data between Amanda clients and server during backup process. Supported ciphers are AES, 3DES, Blowfish and CAST128. 3DES is used by default.
Default authentication mechanism in Amanda is bsd and it does not provide any encryption. Transport encyrption also increases the backup window. Use transport encryption for backing up Amanda clients across internet or insecure networks. Since transport encryption is specified as part of dumptype configuration, it can be different for each backup unit (disklist file entry - DLE).
Steps to configure ssh authentication
- Use auth "ssh" in the dumptype definition
- Amanda user (i.e: amandabackup) and location of amandad binary (i.e.: /usr/lib/amanda/amandad) should be the same on the server and all the clients. Amanda user and location of amanda binaries are the same on Amanda server and clients if the Amanda enterprise RPMs are used. To configure client which does not have the same amanda username or have different amandad path, add the following two variables to the dumptype used for backup:
dumptype ssh-tar {
....<other dumptype parameters>...
client_username "amanda-username-on-the-client"
amandad_path "path-to-amandad-on-the-client"
}
- On the Amanda server, generate ssh keys. This setup should be done only once. If you install using Amanda enterprise RPMs, this is already done during installation. The step should be done as "amandabackup" user. It creates two files - ~amandbackup/.ssh/id_rsa and ~amandabackup/.ssh/id_rsa.pub
$ ssh-keygen -t rsa
- Copy ~amandabackup/.ssh/id_rsa.pub to Amanda client machines through a secure channel(*), append it to ~amandabackup/.ssh/authorized_keys and set file permissions for authorized_keys appropriately.
$ chmod 600 ~amandabackup/.ssh/authorized_keys
(*) for example: copy id_rsa.pub to a floppy or flash drive and hand carry to the client machine.
- Run ssh-add on the Amanda server to add the RSA identities to the authentication agent. This command will prompt for passphrase.
$ ssh-add
- Run amcheck to verify the configuration.
- Note
- Backup process will use ssh for transport encryption and authentication. The recovery process (amrecover and amrestore does not use ssh for authentication or encryption.
Table: Authentication methods in Amanda enterprise edition
| Auth method | Protocol | Port used | Transport | Performance | Advantage |
|---|---|---|---|---|---|
| bsd | tcp and udp | 10080 and 3 ports | clear text | faster | widely used, better performance |
| ssh | tcp only | two tcp ports | encrypted | slower | secure authentication and transport encryption |
Communication port usage
Amanda uses various TCP and UDP ports for communication between Amanda server and client. The port and protocol usage between server and client is required to configure the firewalls (if any) betweeen Amanda server and clients.
- Amanda Enterprise edition uses the following port ranges:
- TCP port range: 11000-11040
- UDP port range: 700-740
- Low TCP port range (used by recovery process) : 700-740
Amanda configuration checker command - amcheck uses UDP port in the range of 700 to 740 on the Amanda server to communicate with amandad which uses udp port 10080 on the Amanda client.
Table: List of network ports used for control messages and data communication between Amanda server and client
- Configuration check tool - amcheck
Backup-Server Backup-Client amcheck UDPPORTRANGE amandad@10080/udp
- Backup process - amdump
Backup-Server Backup-Client planner UDPPORTRANGE amandad@10080/udp dumper UDPPORTRANGE sendbackup@10080(udp) dumper TCPPORTRANGE TCPPORTRANGE (DATA) dumper TCPPORTRANGE TCPPORTRANGE (MESG) dumper TCPPORTRANGE TCPPORTRANGE (INDEX)* (*) only when index is enabled in dumptype.
(taper to set up direct to tape communication with dumper on Backup-Server localhost using TCPPORTRANGE ports)
- Recovery process - amrecover
BACKUP-Client Backup-Server amrecover LOW_TCPPORTRANGE amindexd@10082/tcp* amrecover LOW_TCPPORTRANGE amidxtaped@10083/tcp amrecover LOW_TCPPORTRANGE TCPPORTRANGE (DATA) (*) only when index is enabled in dumptype.
Configuring firewall using iptables between Amanda server and client
This section makes the following assumptions
- Each host has a basic policy of "deny all incoming" and "accept all outgoing"
- Each host has a basic policy of "accept all from localhost"
- Amanda Enterprise Edition has been installed on the Amanda server and client.
Backup process - amdump command
There are two methods to use iptables for Amanda backup process.
IP tables connection tracking module for Amanda
This approach uses the iptable connection tracking module for Amanda, ip_conntrack_amanda. The connection tracking module findsthe connection ports by searching for the "CONNECT" command in the packet and mark them as RELATED to the original outgoing connection. (You may also add ip_nat_amanda to use the connection tracking module in a NAT environment).
The procedure to configure to IP table connection tracking module is specific to the linux distribution.
- To load ip_conntrack_amanda, Change the following line in
Fedora/Redhat distributions: /etc/sysconfig/iptables-config file should have IPTABLES_MODULES="ip_conntrack_amanda" Suse distributions: /etc/sysconfig/SuSEfirewall2 file should have FW_LOAD_MODULES="ip_conntrack_amanda"
- Add a iptables ruleset to allow ESTABLISHED and RELATED packets.
Example: iptables command to add the ruleset
# iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- Restart iptables
Example: Restart iptables command
Redhat/Fedora distributions: # /etc/init.d/iptables restart Suse distributions: Run YaST2
Example: System log messages when Amanda client sends following command to Amanda server:
CONNECT DATA 11001 MESG 11003 INDEX 11004
Amanda client log
amandad: time 1.381: stream_accept: connection from 192.168.10.237.11053 amandad: time 1.383: stream_accept: connection from 192.168.10.237.11054 amandad: time 1.390: stream_accept: connection from 192.168.10.237.11055
Amanda server log
dumper: stream_client: connected to 192.168.10.211.11001 dumper: stream_client: our side is 0.0.0.0.11053 dumper: stream_client: connected to 192.168.10.211.11003 dumper: stream_client: our side is 0.0.0.0.11054 dumper: stream_client: connected to 192.168.10.211.11004 dumper: stream_client: our side is 0.0.0.0.11055
iptables rulesets
- Set input filtering on the backup server for the ports being used.
Example: Allow incoming connections through TCP using port 11000 to 11040
# iptables -A INPUT -p tcp --dport 11000:11040 -j ACCEPT
- Set input filtering on Amanda client for the ports being used.
# iptables -A INPUT -p udp --dport 10080 -j ACCEPT # iptables -A INPUT -p tcp --dport 11000:11040 -j ACCEPT
Backup recovery process - amrecover command
IP tables connection tracking module does not work for recovery process. Configure IP tables rule sets.
- Amanda server:
iptables -A INPUT -p tcp --dport 10082:10083 -j ACCEPT iptables -A INPUT -p tcp --dport 11000:11040 -j ACCEPT
- Amanda client: amrecover process is initiated from the Amanda client, no INPUT iptables ruleset is required.
SE Linux environment
SELinux (Security-Enhanced Linux) is an implementation of mandatory access control in the Linux kernel using the Linux Security Modules (LSM) framework. Standard Linux security has a discretionary access control model.
SELinux targeted policy
Fedora Core 3, Fedora Core 4 and RHEL 4 by default use SELinux in targeted policy mode. In this mode, only the following daemons are protected: dhcpd, httpd (apache.te), named, nscd, ntpd, portmap, snmpd, squid, and syslogd. As a result, Amanda processes are not impacted by targeted policy mode.
SELinux strict policy
All processes and daemons running in the system is protected by SELinux strict policy. File operations (read/write/getattr) are allowed only if it is granted by the policy.
To make Amanda to work under this mode, SELinux policy update is required. Amanda Enterprise Edition provides updates to policy to allow Amanda to work seamlessly. Amanda enterprise edition provides following files in /var/lib/amanda/example/selinux directory on the Amanda server.
- users
- amanda.fc
- amanda.te
Do the following changes in the Amanda server to work under SELinux strict policy (All these steps have to be performed as super-user):
- Replace /etc/selinux/strict/src/policy/users by /var/lib/amanda/example/selinux/users
- Replace /etc/selinux/strict/src/policy/file_contexts/program/amanda.fc by /var/lib/amanda/example/selinux/amanda.fc
- Replace /etc/selinux/strict/src/policy/domains/program/amanda.te by /var/lib/amanda/example/selinux/amanda.te
- Change directory to /etc/selinux/strict/src/policy
- Load the policies
# cd /etc/selinux/strict/src/policy; make load
Note: Depending on your Amanda configuration, changes to amanda.te/amanda.fc are likely needed.
User Authentication through the Web-based GUI
As with all applications, there is no guarantee of security between users sharing the same *NIX or Windows user account. Information entered by one user may be accessible to another user sharing the same *NIX or Windows users account. An Amanda Enterprise administrator should use a secure OS account (in other words, an account not shared with any other user) when logging into Amanda via the web.
Summary
Running Amanda in a firewall environment should only be part of the security measures. Another Amanda feature to consider is the ssh authentication model which offers robust secured authentication mechanism as well as total transport communication encryption. In additon, Amanda encryption feature provides data encryption to protect files with sensitive information.