Encrypting a RHEL 7 Disk With LUKS
Encrypting a RHEL 7 Disk With LUKS
Encryption is a central aspect of cybersecurity. In this post, you'll learn the basics of encryption, by securing a RHEL 7 disk.
Join the DZone community and get the full member experience.Join For Free
Protect your applications against today's increasingly sophisticated threat landscape.
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 cryptsetup
The 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, but for ext2,3,4 file systems, you can follow these steps. 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/keyfile
Now 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 testing
You will see that when we open our crypto_LUKS drive /dev/sdf1 and map it to the drive name testing, it 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-15
Note: 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 myTestingDevice
You would see this device under /dev/mapper/myTestingDevice.
Now the next step we need to take is to write 0s 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/s
Next, we need to create a file system on the device mapper. Here, I've created 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=0
Now we can mount this file system:
[root@data-disk-creation-5 ~]# mount /dev/mapper/testing /testing
The final thing we need to do is restore our data via xfsrestore. In order to restore it, 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-f43b5992ffff
Here we see our label from the 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 /testing
Now 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.
Published at DZone with permission of Marco Corona . See the original article here.
Opinions expressed by DZone contributors are their own.