Print-friendly Version

How to Manage UFS Dumps Securely

Steven Sim, May 2007

Problem Definition

Here's a problem I have come across many times: Administrators frequently need to use ufsdump to conduct a file system dump to a tape drive that is connected to a remote system across what might be an untrusted network.

An additional requirement of some sites has been the need to encrypt the dump before it is written onto the tape. Encrypting the dump ensures that a misplaced dump does not compromise critical and sensitive data. However, the tape would then contain an encrypted dump, which is not recoverable without a proper key.

Yet another frequently encountered issue is the role of the operator. System administrators usually delegate daily tasks to operators who should not have root privileges. How can you conduct a proper file system dump using a non-root, low-privilege user account?

Suggested Solution

This article lays out a procedure to achieve all the objectives above in a single operation, using nothing but the following, standard utilities in the Solaris Operating System. No additional third-party software is required.

• Role-based access control (RBAC)

  By using Solaris RBAC, we can selectively assign the operator sufficient privileges to conduct the file system dump.

• Secure Shell (SSH) public key encryption and the dd command

  By using Solaris ssh asymmetric authentication, we can encrypt the backup stream when it transits the network as well as gain restricted access to the remote tape drive.

  The dd command is then used to accept and redirect the encrypted ufsdump data stream to the appropriate backup tape or file device.

  By using advanced options on the remote authorized_keys file, we can reduce very significantly any problems caused by compromised access keys.

• The Solaris crypt and encrypt utilities

  By using the Solaris 9 crypt command or the Solaris 10 encrypt utility, we can safely encrypt the dump before it is written onto tape.

  The key used to encrypt the dump could then be kept separate from the tape server, for example, by burning it onto a CD-R and storing the CD-R in a safe, dry place.

There are many possible variations for implementing this suggested solution. You are urged to explore variations of the basic procedure provided in the next section.

Procedure and Assumptions

The procedure is divided into three stages:

• Setup
• Backup
• Restoration

Assumptions

Assume we have two systems:

• Server A is the server whose file systems need to be dumped or backed up.
• The operator account on Server A is ubackup.
• Server B is the server that has a direct-attached, local tape drive.
• The operator account on Server B is uremote.
• Server B and Server A are reachable through a normal TCP/IP route.

The objective is to use ufsdump to do an encrypted dump of a file system found on Server A, across an untrusted network, to a locally attached tape drive on Server B. The resulting tape dump on Server B must also be encrypted.

Setup

1. As root on Server A, create a normal, low-privilege user (ubackup).

  # groupadd -g 10000 backup
  # projadd -g 10000 group.backup
  # useradd -d /export/home/ubackup -m -g backup ubackup
  # passwd ubackup

2. Still as root on Server A, assign the low-privilege user (ubackup) the proper RBAC "Media Backup" profile rights.

  # usermod -P "Media Backup" ubackup

3. Ensure that the user ubackup on Server A has the appropriate RBAC profile.

a. Log in as user ubackup on Server A:

  $ profiles

b. Ensure that you see the profile "Media Backup" among those listed:

  Media Backup
  Basic Solaris User
  All

4. Still as user ubackup on Server A, generate the SSH public-private key.

Note: If you decide to use an empty passphrase, skip the ssh-agent and ssh-add steps later in this procedure. If you do not want to use an empty passphrase, enter an appropriate passphrase for the new key when you run the following command.

  $ ssh-keygen -b 1024 -t rsa
  Generating public/private rsa key pair.
  Enter file in which to save the key
(/export/home/ubackup/.ssh/id_rsa):
  Created directory '/export/home/ubackup/.ssh'.
  Enter passphrase (empty for no passphrase):
  Enter same passphrase again:
  Your identification has been saved in
/export/home/ubackup/.ssh/id_rsa.
  Your public key has been saved in
/export/home/ubackup/.ssh/id_rsa.pub.
  The key fingerprint is:
  09:aa:ed:b7:24:31:69:64:fa:f1:50:dd:87:52:d0:d7
operator@ServerA

5. As root on Server B, create a normal, low-privilege user (uremote) on Server B:

  # groupadd -g 10000 backup
  # projadd -g 10000 group.backup
  # useradd -d /export/home/uremote -m -g backup uremote
  # passwd uremote

6. Set up the appropriate settings for the SSH authorized_keys file for user uremote on Server B.

a. Copy from the Server A ubackup user's ~/ssh/id_rsa.pub to the Server B uremote user's ~/ssh/authorized_keys.

b. Ensure that the authorized_keys file does not have write or execute permissions for group or other users.

c. Ensure that the ~/.ssh directory for user uremote on Server B has a permission value of 700.

7. (Optional!) To restrict the functionality of the keys even further, edit the Server B uremote user's ~/ssh/authorized_keys file and add the following text just before the ssh-rsa string (at the beginning of the line):

Original:

  ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA2j2o...<rest of key>

Edited:

  from="<Server A hostname or IP>",no-pty,no-port-forwarding,
no-X11-forwarding,no-agent-forwarding ssh-rsa ...<rest of key>

The previous change would ensure that the key can be used only by user ubackup from Server A. It would also ensure that the key has limited functionality even if it is compromised.

Further usage restriction of the key is possible. For example, creating task-specific keys by explicitly specifying the actual command using command= would further restrict key functionality.

For more information, see Amy Rich's Secure Shell: Part 2 article on BigAdmin.

8. On Server A, as user ubackup, load ssh-agent and add the private key to enable secure asymmetric login. Also, enter the passphrase specified in Step 4, if you are prompted to do so.

  $ ssh-agent ksh
  $ ssh-add
  Enter passphrase for /export/home/steven/.ssh/id_rsa:
  Identity added: /export/home/steven/.ssh/id_rsa
(/export/home/steven/.ssh/id_rsa)

9. To ensure that the ssh login can take place automatically, enter the following from Server A as user ubackup:

  # ssh uremote@ServerB "ls -al"

The previous command should execute a simple ls -al on the remote server and return. On the first try, you might receive a message similar to the following:

  The authenticity of host '10.10.10.10 (10.10.10.10)' can't
be established.
  RSA key fingerprint is c1:dd:c9:ca:dd:c0:b4:d6:5d:12:ad:
2c:8c:c7:4a:f8.
  Are you sure you want to continue connecting (yes/no)? yes

If so, simply answer yes. On the second try of the same command, no more interactive password prompts should appear.

10. Log in to Server B as user uremote and generate on Server B the appropriate random-key file used for ufsdump encryption:

  $ dd if=/dev/random of=/export/home/uremote/.ssh/encrypt-key
bs=192 count=1

Ensure that the file is read-only by user uremote. Do not lose this key file!

To secure this key file, you can burn the key file onto a CD-ROM and subsequently place the CD-ROM in a safe, dry place.

A successful restoration would then require that the CD-ROM be placed into the CD-ROM tray on Server B.

Backup

1. Log in to Server A as user ubackup and conduct the dump from Server A.

Example using the Solaris 10 encrypt utility:

$ pfexec ufsdump 0bf 256 - /dev/md/rdsk/d5 | ssh uremote@ServerB \
"encrypt -a 3des -k /export/home/uremote/.ssh/encrypt-key | \
dd of=/dev/rmt/0n obs=128k conv=sync"

With the Solaris 9 OS, you must use the simpler crypt command:

$ pfexec ufsdump 0bf 256 - /dev/md/rdsk/d5 | ssh uremote@ServerB \
"crypt password | dd of=/dev/rmt/0n obs=128k conv=sync"

Caution

It is critically important that you record the ufsdump block size and dd block size, because the file restoration process requires you to know the respective block sizes, as shown in the Restoration section. Ideally, the block sizes would also match each other. That is, a ufsdump block size of 256 implies 256 blocks of 512 bytes each (256 * 512 / 1024 = 128K).

2. Monitor the backup processes using prstat.

On Server B, you can easily monitor the relevant processes using the prstat project facility:

$ prstat -Jj group.backup

To get the process tree, simply use this command:

$ ptree `pgrep dd`

Restoration

How do we now use the previously encrypted, remote dump to restore files?

On Server A, as root user, enter the following:

  # /usr/bin/ssh -n uremote@ServerB "dd bs=128k files=1
if=/dev/rmt/0n | \
  decrypt -a 3des -k /export/home/uremote/.ssh/encrypt-key" | \
  (cd /tmp; ufsrestore rvbf 256 - <files>)

Enter uremote user's password when prompted.

Sample output is shown below.

  # ssh -n admin@10.10.10.10 \
  "dd bs=128k files=1 if=/dev/rmt/1n | crypt testkey" | \
  ufsrestore bxvf 256 - /etc/apache2

  Verify volume and initialize maps
  admin@10.10.10.10's password:
  read: Not enough space
  0+0 records in
  0+0 records out
  Volume is not in dump format
  root@SunU60 # ssh -n admin@10.10.10.10 "dd bs=128k
files=1 if=/dev/rmt/1n | c>
  Verify volume and initialize maps
  admin@10.10.10.10's password:
  Note: doing byte swapping
  Dump   date: Thu Feb 01 09:54:45 2007
  Dumped from: the epoch
  Level 0 dump of / on fujitsu:/dev/dsk/c0d0s0
  Label: none
  Extract directories from tape
  Initialize symbol table.
  Make node ./etc
  Make node ./etc/apache2
  Extract requested files
  extract file ./etc/apache2/httpd.conf-example
  extract file ./etc/apache2/highperformance-std.conf
  extract file ./etc/apache2/highperformance.conf
  extract file ./etc/apache2/httpd-std.conf
  extract file ./etc/apache2/magic
  extract file ./etc/apache2/mime.types
  extract file ./etc/apache2/ssl-std.conf
  extract file ./etc/apache2/ssl.conf
  Add links
  Set directory mode, owner, and times.
  set owner/mode for '.'? [yn] y
  41837+0 records in
  41837+0 records out

If the wrong crypt key were used, you would see the following:

  root@SunU60 # ssh admin@10.10.10.10 "dd bs=128k files=1
if=/dev/rmt/1n | crypt wrongkey" | ufsrestore bxvf 256 -
  Verify volume and initialize maps
  admin@10.10.10.10's password:
  Volume is not in dump format
  41837+0 records in
  41837+0 records out

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.