Posts Tagged ‘linux’

Automated Remote Backups with rsync

One of the oldest and simplest ways to back up UNIX-like systems is with rsync. Automated remote backups are a simple matter of setting up rsync as a daemon on the system you want to back up and running an appropriate rsync command as a cron job on the backup target.

Let’s create /etc/rsyncd.conf on the machine to be backed up:

  read only=TRUE
  hosts allow=
  hosts deny=*
  uid = 0
  exclude = ssh/

Any number of modules can be defined with the [module_name] convention so different settings can be applied to different locations on the file system. Module names are used in the rsync:// protocol format insted of full path names. This block says, in English: Serve the contents of /etc/ except /etc/ssh/ to any host on the subnet at the location rsync://localhost/etc as though root was reading the files but don’t allow any modifications to the local file system.

Read the rsyncd.conf man page for more configuration options. Your rsync package probably comes with a compatible init script, be sure to enable it for your default runlevel.

On the backup server we’ll drop this little bash script into /etc/cron.hourly:


rsync -a -u --delete rsync:// /mnt/backups/serverxyz/etc

Now every hour the backup target will connect to the rsync daemon and download any files which have been changed or do not already exist in the backup tree, also deleting files which no longer exist on that server to preserve space.

Simple Disk or File-System Image Encryption with dm-crypt

dm-crypt is a part of modern Linux’s device mapper system which allows for the transparent application of a broad range of block cyphers to a virtual block device. The virtual block device is configured with the cryptsetup command and can point to a real block device (i.e. a real hard drive or partition) or a file which has been attached to a loop device as the underlaying source.

There are a lot of great reasons to use LUKS (Linux Unified Key Setup), not the least of which is the ability to encrypt the host operating system’s partition or change the encrypted volume’s passphrase. In this article however, we will simply be covering the mundane encryption of block devices with dm-crypt.

One of the advantages of encrypting a physical hard drive from head to toe is that there is no partition table around to leak metrics; if you followed Filling a Drive with Random Data: urandom, dd and Patience your encrypted file system will span the size of the device and any cryptographic boundaries should be undetectable.

If you will be working with a file instead of a real block device it will be necessary to create the file and set it up on a loop device before proceeding. Just as with wiping a disk it is recommended that /dev/urandom is used to initialize the file insted of /dev/zero but you may find the same benefit for much less time in simply creating a sparse file (please see Managing Raw Disk/File System Image Files for more details).

# dd if=/dev/urandom of=encrypted.img bs=1M count=1000
# dd if=/dev/zero of=encrypted.img seek=1000 bs=1M count=0
# losetup /dev/loop0 encrypted.img

Now we’re going to run the device through dm-crypt using 256 bit AES and SHA256 ESSIV. ESSIV is a method of generating initialization vectors which are difficult to predict; this helps protect against watermarking attacks. You will be asked to provide a passphrase, the longer and more complex the better.

# cryptsetup -c aes-cbc-essiv:sha256 create encryptedVolume /dev/loop0 (or /dev/sdd, etc)
Enter passphrase:

Alternatively, you may prefer to use a large chunk of random data stored in a file, perhaps on a USB stick.

# dd if=/dev/urandom of=/mnt/usb/passphrase.key bs=1K count=4
# cat /mnt/usb/passphrase.key | cryptsetup -c aes-cbc-essiv:sha256 create encryptedVolume /dev/loop0

This method provides excellent protection against brute force attacks but may add a physical security dilemma. Consider a case where law enforcement agents have a warrant to search and sieze your property; if they find the USB stick and figure out that it contains the key to your encrypted drive they don’t have to pressure you for your passphrase to use it. On the other hand, depending where and with whom the key is stored this approach could have benefits in a rubber-hose attack situation as 4K of random data is virtually impossible to memorize.

Our new virtual block device is located under /dev/mapper. Now we can create the filesystem of our choice on it:

# mke2fs -j /dev/mapper/encryptedVolume

Once the filesystem is in place the device can be mounted and used like any regular block or loop device:

# mkdir /mnt/encrypted
# mount /dev/mapper/encryptedVolume /mnt/encrypted

As long as the device is available through device mapper the contents of the encrypted volume are vulnerable to the same kind of attacks any part of your regular system is: malware, viruses, cockpit error and so on. When not in use be sure to unmount the file system and destroy the device mapper entry:

# umount /mnt/encrypted
# cryptsetup remove encryptedVolume

If your volume is file-backed it is now safe to unhitch it from the loop device:

# losetup -d /dev/loop0

Filling a Drive with Random Data: urandom, dd and Patience

Filling a block device with random data is a good first step in file system encryption, particularly where there will be no partition table or the partition table itself is to be encrypted. The objective is to make encrypted data indistinguishable from free space, obscuring important metrics like file and partition sizes. Although a single pass is not enough to completely obliterate any trace of previously existing files, tools like shred can be used where this is necessary.

There are two sources of random numbers provided by the linux kernel: /dev/random and /dev/urandom. /dev/random is more “random” than urandom; it takes cues from hardware sources like sound cards and cursor movements to produce output which is not likely to be fingerprinted. Consequentially, random only generates output as entropy becomes available which rules it out for anything intensive like overwriting a hard drive. Urandom is a software-implemented pseudo-random generator which means it does its best to produce genuinely random output from mathematical algorithms. Being based on fixed formulas, the output of urandom is theoretically fingerprintable and reproducible given a set of known factors. The upside is that it is relatively fast while providing arguably more than enough randomness for disk encryption camouflage.

# dd if=/dev/urandom of=/dev/sdb bs=1M

dd is a low-level file swiss army knife. The command above instructs dd to take data from input file /dev/urandom and put it into output file /dev/sdb (our second SATA hard drive). The default block size is too small to efficiently make use of a hard drive’s pipe so be sure to add bs=1M or more if you don’t want it to take weeks.

Unfortunately, urandom is computationally intensive enough that it is not likely to pump out data as fast as your drive can take it without maxing out a CPU core. It is possible to take advantage of multi-core systems by running multiple instances of dd with clever use of the seek flag.

To give you an idea of the time frame you are looking at, to completely overwrite a 2TB drive on a 2.4GHz Core 2 Quad one core was at 99% utilization for 49 and a half hours:

# dd if=/dev/urandom of=/dev/sdd bs=1M
1907728+1 records in
1907727+1 records out
2000397885440 bytes (2.0 TB) copied, 177862 s, 11.2 MB/s

Contrast 11.2MB/s with the typical 70MB/s+ write speed of this drive. It should be noted that both shred and openssl can be used instead if you would prefer to trade off randomness for speed but 2 days for 2TB isn’t all that bad – in my most humble of opinions – and doubles as a sort of burn-in test for new drives.

Return top
Online Marketing Toplist
Technology Blogs - Blog Rankings

Internet Blogs - BlogCatalog Blog Directory

Bad Karma Networks

Please Donate!

Made in Canada  •  There's a fox in the Gibson!  •  2010-12