In this blog post, I will be describing how to encrypt a RHEL 7 disk with the Linux utility LUKS (cryptsetup). The result of this tutorial is for a disk to be unreadable (encrypted at rest), unless it is unlocked with a specific passphrase or key-file. The overall process to disk encryption is: install the LUKS utility, backup the data from our disk, format the disk with LUKS, write zeroes to the LUKS partition, mount the disk, and restore our data from backup.
The first step to encrypting a disk with LUKS is to install cryptsetup with your package manager :
yum install cryptsetupThe next step we need to take is to backup our file system because formatting the disk with LUKS overwrites all content on the disks. Since this disk partition was an XFS file system, we can use the xfsdump and xfsrestore utilities. For an XFS file system, you must first take an xfsdump:
[root@data-disk-creation-5 ~]# xfsdump -l 0 -f /dev/mapper/datab5e22f1f /testing xfsdump: using file dump (drive_simple) strategy xfsdump: version 3.1.4 (dump format 3.0) - type ^C for status and control ============================= dump label dialog ============================== please enter label for this dump session (timeout in 300 sec) -> testing dump session label entered: "testing dump"Here you will see that we assigned our dump the label of “testing dump”. It is important to remember what you label your dump so when you restore your dump, the proper data gets back onto the disk. Next, we must format our disk with LUKS and assign it a passphrase:
[root@data-disk-creation-5 ~]# cryptsetup luksFormat -y -v /dev/sdf1 WARNING! ======== This will overwrite data on /dev/sdf1 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: Command successful.If you wish to initially encrypt the disk with a key-file, simply use the –key-file option:
[root@data-disk-creation-5 ~]# cryptsetup luksFormat -y -v /dev/sdf1 --key-file /path/to/keyfileNow if we do a blkid, we will see that the disk is now type “crypto_LUKS”:
[root@data-disk-creation-5 ~]# blkid | grep sdf1 /dev/sdf1: UUID="dff34912-7b50-48d7-8014-438671c35eb5" TYPE="crypto_LUKS"The next step we have to take is to open the crypto_LUKS device:
[root@data-disk-creation-5 ~]# cryptsetup luksOpen /dev/sdf1 testingYou will see that we open our crypto_LUKS drive /dev/sdf1 and map it to the drive name testing, and will appear under /dev/mapper/testing.
[root@data-disk-creation-5 ~]# ls -l /dev/mapper/ lrwxrwxrwx 1 root root 8 Sep 1 16:30 testing -> ../dm-15Note: testing is an arbitrary name, and can be anything. For example, if you were to open the drive with:
[root@data-disk-creation-5 ~]# cryptsetup luksOpen /dev/sdf1 myTestingDeviceYou would see this device under /dev/mapper/myTestingDevice.
Now we need to take is to write 0’s to the device, which can take a very long time, depending on the size of the device. To track the progress of this command, we can use the pv tool. Here I use the -tp flags which display how long the command has been running and a progress bar — there are more options that you can use which are documented here. This allows me to see that my command is still running.
[root@data-disk-creation-5 ~]# pv -tp /dev/zero | dd of=/dev/mapper/testing bs=128M dd: error writing ‘/dev/mapper/testing’: No space left on device ] 0:00:01 [ <=> ] 0+8169 records in 0+8168 records out 1070596096 bytes (1.1 GB) copied, 9.73315 s, 110 MB/sNext, we need to take is to create a file system on the device mapper. Here I create an XFS file system on /dev/mapper/testing:
[root@data-disk-creation-5 ~]# mkfs.xfs /dev/mapper/testing meta-data=/dev/mapper/testing isize=512 agcount=4, agsize=65344 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0, sparse=0 data = bsize=4096 blocks=261376, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=855, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0Now we can mount this file system:
[root@data-disk-creation-5 ~]# mount /dev/mapper/testing /testingThe final thing we need to do is restore our data via xfsrestore. In order to restore, we need to find the session id of our xfsdump, which we can use xfsrestore to do:
[root@data-disk-creation-5 ~]# xfsrestore -I file system 2: fs id: 2259b43e-c3dc-4bf0-881d-17191509143c session 0: mount point: data-disk-creation-5:/testing device: data-disk-creation-5:/dev/sdf1 time: Fri Sep 1 16:25:16 2017 session label: "testing dump" session id: 82f95beb-39b3-406b-8e1e-a02f5312871e level: 0 resumed: NO subtree: NO streams: 1 stream 0: pathname: /dev/mapper/datab5e22f1f start: ino 67 offset 0 end: ino 1055490 offset 0 interrupted: NO media files: 1 media file 0: mfile index: 0 mfile type: data mfile size: 27096 mfile start: ino 67 offset 0 mfile end: ino 1055490 offset 0 media label: "testing dump" media id: dc32c8ca-6f8e-4607-92ae-f43b5992ffffHere we see our label from earlier “testing dump”, and under the session label, you will see the session id that we need to restore:
root@data-disk-creation-5 ~]# xfsrestore -f /dev/mapper/datab5e22f1f -S 2259b43e-c3dc-4bf0-881d-17191509143c /testingNow we have a fully encrypted disk with our original data on the disk. This disk is now encrypted at rest and can be opened by only the passphrase or key-file that was used to encrypt the disk when it was formatted.