In this course, you'll learn about the importance of physical security and the threats posed by attackers who gain unauthorized physical access to your Linux system. We'll cover a range of points to consider when securing your Linux systems and the best strategies to take.
Learning Objectives
- Understand the security challenges you'll face both when in direct control of your physical systems and when you use a third party to host them
- Understand what to look for when choosing a third-party provider
- Understand the physical security implications of using cloud environments
- Learn specific strategies for mitigating physical security risks and protecting your Linux systems against the most common physical attacks
- Learn about data encryption and how to implement it on new Linux systems, as well as those that are already in service
Intended Audience
This course is intended for anyone who wants a solid grasp of physical security considerations for their Linux system.
Prerequisites
To get the most out of this course, you should already have a good working knowledge of Linux. If you want to brush up on your Linux skills, consider taking our Learn Linux in 5 Days learning path first.
The following process that I'm about to show you will work for any device that can be presented to your system. If you plug in a USB drive to your Linux system, create a new virtual disc for your Linux VM, or present a virtual volume to your Linux Cloud Instance, you can use this process. It's important to point out that what we're about to do will remove all the data that exists on that device. I have a virtual machine here and what I'm going to do is present a physical or I guess a virtual disc to it, in this instance. So again, I'm gonna make sure it's powered off, I'm gonna go to the settings of that machine. I'm going to add some storage here. Just create a new hard disc device. We'll create a new disc and we'll leave it at eight gigabyte, that's fine. Again, this would be the equivalent of physically putting another disc inside a server. So now I'm gonna power that server on. Okay, now the system is booted and I'm going to go ahead and log into it here. We need the cryptsetup utility in order to set up luks and encryption on our system. And it doesn't look like it's currently installed on this one. So typically I would just search for the software here. It's CentOS seven or a real seven equivalent machine and I'm just going to use yum search cryptsetup. And then I can see that the package name here is cryptsetup. I do believe on earlier versions, such as red hat six and CentOS six it's cryptsetup dash luks. So I'm going to go ahead and install cryptsetup now. We also attach the disc before we boot it up, let's run fdisc dash l to list the devices in our system and see if we can find out what device file is associated with our disc. Here, dev/sda, which is already being used, is 85 gig. That's not it, but if you look below that dev/sdb is about an eight gigabyte drive which is the size of the disc that we presented to this system. So the device is dev/sdb for this new disc that we installed. If you want to ensure that no un-encrypted data is left on the device that we're about to encrypt let's fill it with random data. Doing so will also conceal or obscure the parts of the device that contain encrypted data as opposed to just random data. To do this, we'll use a utility like shred. I'll do shred dash V, which is for verbose, dash N, which is the number of iterations. And I'll do just one. We'll those pass over this device once, and we'll supply the file here, dev/sdb. What this command is doing is writing random data to that disc. Next, we're going to initialize the device. To do that, I'll run sudo cryptsetup luxsFormat and then pass it that device. This'll go ahead and ask us for our passphrase here. Now that it's initialized we can go ahead and open the device. We'll run cryptsetup luxsOpen and pass the device to it which is slash dev slash sdb in this case, and a name that will be used to create the virtual block device in slash def mapper. So we'll just use opt as an example. Supply the passphrase that opens the device, and now we should have a virtual block device in dev mapper. Let's just look at the last few entries there. You can see that the virtual block device was created in slash dev slash mapper slash opt. Now we can use that virtual block device like any other block device. I'm going to go ahead and just put a file system directly on that device. So we'll run mkfs, we'll make it an ext4 file system. We'll run that on that device there. Okay, that's created. So, now let's go ahead and mount our file system, on slash opt. I'll create an entry in the Fs tab for it, dev mapper opt. We're going to mount it on slash opt. It's an ext4 file system, we don't need any specialized mounting options, and that will be our entry there. So we can go ahead and mount that device. And when we look there, we can see that opt is mounted on slash dev slash mapper slash opt. Now, when we create files and place them in opt they will be encrypted. From this point on, we use the file system like we normally would and allow luxs and DM crypt to handle the encryption. Here, I'll just create a simple little file. Oops, I need permission here. We'll do it like this. In order for the device to be mounted at boot time we'll need to make an entry in slash etc slash crypt tab. This will cause you to be prompted for the passphrase during the boot process, so the device can be opened. The first piece of information we need to supply is the name that we used, and here we used opt, so we'll just place this here. And that will be the virtual block device that gets created in slash dev slash mapper. Next we need to supply the underlying block device. Here, it's slash dev slash sdb. The next field in this file is for the passphrase but we can specify none here and that will force us to be prompted for the password on boot. The last column here is for options and we're just going to use the luks standard format. So we'll type in luks there go ahead and write and save that file. Also want to point out that the crypt tab supports the UUID equals UUID syntax just like the Fs tab file does here. And you can get that information by running blkid and then you can see the UUID, so these blocked devices. And then the one we're looking for is the cryptid the crypto luks device which is in this case, slash dev slash sdb. So if you wanted to use this format instead of supplying slash dev slash sdb in the crypt tab file, you would instead supply UUID equals two one one two five, et cetera, et cetera there. This is probably a better option for removable devices that you can't guarantee will have the same physical device file associated with it at each boot. So now that we have the crypt tab set up let me just go ahead and quickly show you that it will ask for the password when we perform a reboot. There it is, it's asking for our password. I'll go ahead and enter it. Quickly log in here, and you can see that opt is mounted on that virtual block device file of slash dev slash mapper slash opt. Let's say you didn't want to automatically mount this volume on boot, but instead you want to use this device for a while and then stop using it. So let's go ahead and remove its entry from etc crypt tab. I'll just comment it out there and also remove it from fstab. Again, I'll just place a comment there and let's go ahead and reboot.
Jason is the founder of the Linux Training Academy as well as the author of "Linux for Beginners" and "Command Line Kung Fu." He has over 20 years of professional Linux experience, having worked for industry leaders such as Hewlett-Packard, Xerox, UPS, FireEye, and Amazon.com. Nothing gives him more satisfaction than knowing he has helped thousands of IT professionals level up their careers through his many books and courses.