1. Home
  2. Training Library
  3. Linux Security and Hardening | CSL4 A3.1 |

Securing the Boot Loader

Start course
Overview
Difficulty
Beginner
Duration
3h 21m
Description

In this section, you’ll take a deep dive into Linux security. You’ll build your knowledge and skills through a comprehensive overview of the key areas that you need to know to secure Linux systems.

You’ll begin with Linux security in general before moving on to physical security and the countermeasures you can employ to protect your hardware. From there, you’ll explore authentication systems and the various account types on a Linux system, and how to secure each one. You'll also learn how to enforce strong passwords and manage account and password expirations.

In the networking section, you'll learn how to secure network services that run on Linux systems. You'll also learn how the local firewall works in Linux and how to configure it. You’ll learn about file system security and how permissions work in detail, including special modes, file attributes, and ACLs. You'll also discover what rootkits are, how to detect them, and how to remove them.

You’ll also find several security resources you can use to continue your security education and stay on top of the latest security issues for Linux distributions.

There are several knowledge checks as you go through these resources. These will help you identify any areas that you might need or want to review. At the end you’ll find a final exam, where you can test yourself on what you’ve learnt.

Learning Objectives

  • Get a general view of Linux security including roles, network services, encryption, accounts, and multifactor authentication
  • 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
  • Understand the different types of accounts you'll find on a Linux system and the special precautions you need to take with each account type
  • Learn how to enforce good password security practices on your Linux systems
  • Learn about multi-factor authentication and how it can be implemented in Linux
  • Learn techniques and strategies to secure network services
  • Learn how to secure your files and directories on Linux through permissions, data sharing, special modes, file attributes, ACLs, and rootkits
Transcript

Now that we've configured the system to require a root password to get into single user mode, let me show you how easy it is to get around that too. Remember that when the bootloader loads the colonel, then the colonel loads in a knit system like a knit or system deep. What we can do is tell the colonel to use this shell as the init system is bypasses the init system altogether and drops you into a root shell. I've interrupted the boot process here and I'm going to go ahead and edit the kernel parameters. And what I'm going to do is simply type init equals bin slash bash. So what I'm doing is replacing the init system. I'm telling the kernel to use bash as the init system. I'll go ahead and execute this configuration. So instead of running the normal init process that executes the startup scripts and asks you for passwords and that sort of thing, just the bash shell is executed. To protect against this tactic, we need to stop someone from passing in arguments to the kernel. To do this, we can require a password on the bootloader before you are allowed to make any changes. Here's how to password protect the grub boot loader. First, we're going to play some configuration and Etsy grub dot D. You can place the configuration anywhere you want but I recommend using the 40 underscore custom file. Since it shouldn't be overwritten, even when the grub package is updated. Go ahead and modify that file. And what we're going to do here is put in set super users equals, and then you can choose a username. I'm just going to use root. You can put anything here. You could put Jason, you could put Bob, you could put admin this is not operating system related. This is for the bootloader. So we'll set super users in this example to root and we'll go ahead and put a password on this root account. We'll set the password for the root account to root. I know that's not very secure but this is just a simple example. Now, if you want to encrypt the passwords you can use the grub to make password P B K D F two command on Santos or REL or it's the grub dash M K P A S S w D dash P B K D F two on Ubuntu systems. So just look for grub and MK password is it varies from distribution to distribution. So if I run this and I enter a password then we get this output. So instead of using password root root then instead of using password route route what we would use would be password underscore P B K DF two root, and then this long output that's on your screen here grub dot P B K D F two Shaw five one 12, et cetera. And that's what would go in that 40 underscore custom file. If you wanted to use an encrypted password which I actually recommend. Next, you should rebuild the grub dot CFG file. Again, this will differ a bit, depending on how your distribution implemented grub for Santos and Red Hat. The command is grub two make config dash Oh four output and then we'll supply the path to the grub.com file. And we'll go ahead and hit enter and it will generate that configuration and use that additional configuration we added in the custom file for grub. If you're using Ubuntu, the command is update grub. Again, you're going to have to refer to the documentation for your specific distribution. Okay, we're going to go ahead and reboot the system and boot in a single user mode or attempt to boot into a single user mode. And we'll see if this works. So I'm here and I would normally press E and I'll go ahead and do that now. And now it's asking for a username, and this is the username that we supplied in the grub configuration. And this example I use root, but again you could use any username that you'd like. Let me supply a wrong password. If you supply the wrong password, you get booted to the main menu and then I'll do it again. This time with the correct password. Now I have access to the kernel parameters. Again, using a password on the bootloader prevents someone from booting into single user mode or bypassing it entirely by passing a net equals been bashed to the kernel. Even this solution isn't perfect because if you have physical access to the system, you can simply insert your own bootable CD DVD or USB device. I'm going to insert a virtual CD into our virtual CD rom here on our virtual machine. And I'll just go ahead and use this disc image. And I'm going to hit the power button again the virtual power button for this example. But again, this is exactly how you would do it if you had access to the physical system. So here we're booting from the CD. This CD is a Cintos installed disc, which also has some built in rescue and troubleshooting tools. I'm going to select the troubleshooting menu and then select rescue a Cento system. Now the system has been booted from this CD and on this particular CD it asked me if I would like to try to Mount the file systems and I'll go ahead and say, continue to go ahead and let the CD try to go ahead and mount the file systems for me. All right. I'll press enter to get to a shell. And here I am at the root shell. Oops. And then there are my discs. They're mounted under mount system image. And I can go in here. For example, I'll go to boot grub two and then I can just edit this grub dot CFG file. And we'll look for Here is the configuration we added the super users equals root and the password. And I could simply just edit this out, reboot the system. I'll go ahead and do that now. And now we have access to grub without a password. All right, now I've interrupted the boot process and I hit E to edit the configuration and I'm not prompted for a password. The important thing to remember here is that if someone can gain access to the storage that your server uses they can do whatever they want to with it. If your disc or a virtual disc rather live in the cloud then the service provider can potentially access your virtual disc and view and modify them. The way to mitigate this risk in this scenario is to encrypt your data. We'll talk about encryption in another part of the course.

About the Author