Solving IT problems and building solutions

  • Wednesday, November 7, 2012

    How to encrypt the disk to protect the data


    Step1: We are going to use Linux Unified Key SetupFor that we need to install cryptsetup package.
    # yum install cryptsetup

    Step2: While using AWS, never attach the volume to be encrypted while launching the instance. If we do so, the instance will fail to boot up next time because it'll ask for decryption password while booting up which is not possible to supply in AWS. Still if it is absolutely mandatory to do this then I suggest trying to remove entries from fstab and crypttab but it is much easier to just attach the disk after the launching of the instance is done. Assuming that the attached disk is available at /dev/xvdf, we'll setup the encryption now.
    # cryptsetup -y -v luksFormat /dev/xvdf
    WARNING!
    ========
    This will overwrite data on /dev/xvdf irrevocably.

    Are you sure? (Type uppercase yes): YES
    Enter LUKS passphrase:
    Verify passphrase:

    Command successful.


    We can verify the encryption parameters as well. Default is AES 256 bit.
    # cryptsetup luksDump /dev/xvdf

    Step3: We'll open the device and map it to /dev/mapper/home so that we can use it.
    # cryptsetup luksOpen /dev/xvdf home
    Enter passphrase for /dev/xvdf:


    Step4: This step is optional. To further protect our data, we can zero out the entire disk before even creating the filesystem.
    # dd if=/dev/zero of=/dev/mapper/home

    Step5: Now we'll create a filesytem
    # mkfs.ext4 /dev/mapper/home

    Step6: Let us mount and copy the data from /home
    # mkdir /myhome
    # mount /dev/mapper/home /myhome
    # cp -a /home/* /myhome/
    # rm -rf /home
    # ln -s /myhome /home

    Great! Our /home directory is encrypted. But wait a minute.. this approach has a short coming. We have deliberately designed it so that the disk won't auto-mount during the boot because there is no way to give it a password in cloud environment during the boot. Since the disk won't mount, we won't be able to ssh into the machine because the authorized_keys file is kept inside the home directory of the user. To address this problem, either change the "AuthorizedKeysFile" in sshd_config or create a user with home directory in /var/lib or /opt and grant sudo for cryptsetup and mount commands. So after reboot, if we take the first approach, we would be able to ssh without any problem or we'll ssh via other user, mount the encrypted drive and then use it normally.

    $ ssh mountuser@<ip>
    $ sudo /sbin/cryptsetup luksOpen /dev/xvdf home
    $ sudo /bin/mount /dev/mapper/home /myhome/


    Couple of points to remember:
    • Do not forget the LUKS password. It cannot be retrieved, if lost.
    • Try it a couple of times on staging machines before doing it on the machines that matter.

    No comments:

    Post a Comment