Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Encrypting a RHEL 7 Disk With LUKS

DZone's Guide to

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.

· Security Zone
Free Resource

Discover an in-depth knowledge about the different kinds of iOS hacking tools and techniques with the free iOS Hacking Guide from Security Innovation.

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.

Learn about the importance of a strong culture of cybersecurity, and examine key activities for building – or improving – that culture within your organization.

Topics:
security ,encryption ,linux ,data security

Published at DZone with permission of Marco Corona. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}