Zmanda Documentation > Amanda Enterprise Edition Security Features

Amanda Enterprise Edition Security Features

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

ProgramPre-RequisiteEncryption MethodCipher Algorithm supportedProConMisc
amcryptaespipe, uuencode, gpgSymmetricAES128,AES192,AES256Very secure(1)setup required, passphrase to store MD5 IV and 64 AES keys to en/decrypt
Easy to deploypassphrase to store passphrase to en/decrypt
no need to store decryption keyamrecover (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/
$ ssh-keygen -t rsa 
  • Copy ~amandabackup/.ssh/ 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 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.
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 methodProtocolPort usedTransportPerformanceAdvantage
bsdtcp and udp10080 and 3 portsclear textfasterwidely used,
better performance
sshtcp onlytwo tcp portsencryptedslowersecure 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-Server   Backup-Client
planner  UDPPORTRANGE    amandad@10080/udp
dumper   UDPPORTRANGE    sendbackup@10080(udp)
(*) only when index is enabled in dumptype.
(taper to set up direct to tape communication with dumper on Backup-Server localhost using TCPPORTRANGE ports)
          BACKUP-Client     Backup-Server
amrecover LOW_TCPPORTRANGE  amindexd@10082/tcp*
amrecover LOW_TCPPORTRANGE  amidxtaped@10083/tcp
(*) 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
 amandad: time 1.383: stream_accept: connection from
 amandad: time 1.390: stream_accept: connection from

Amanda server log

dumper: stream_client: connected to
dumper: stream_client: our side is
dumper: stream_client: connected to
dumper: stream_client: our side is
dumper: stream_client: connected to
dumper: stream_client: our side is

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.


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.