Chapter 3. Securing and Hardening Linux Kernels

In this chapter, we will turn our attention to securing and hardening the one key piece that every container running on your Docker host relies on: the Linux kernel. We will focus on two topics: guides that you can follow to harden the Linux kernel and tools that you can add to your arsenal to help harden the Linux kernel. Let's take a brief look at what we will be covering in this chapter before diving in:

  • Linux kernel hardening guides
  • Linux kernel hardening tools
    • Grsecurity
    • Lynis

Linux kernel hardening guides

In this section, we will be looking at the SANS Institute hardening guide for the Linux kernel. While a lot of this information is outdated, I believe that it is important for you to understand how the Linux kernel has evolved and become a secure entity. If you were to step into a time machine and go back to the year 2003 and attempt to do the things you want to do today, this is everything you would have to do.

First, some background information about the SANS Institute. It is a private US-based company that specializes in cybersecurity and information technology-related training and education. These trainings prepare professionals to defend their environments against attackers. SANS also offers a variety of free security-related content via their SANS Technology Institute Leadership Lab. More information about this can be found at http://www.sans.edu/research/leadership-laboratory.

To help alleviate against this widespread attack base, there needs to be security focus on every aspect of your IT infrastructure and software. Based upon this, the first place to start would be at the Linux kernel.

SANS hardening guide deep dive

As we have already covered the background of the SANS Institute, let's go ahead and jump into the guide that we will be following to secure our Linux kernel(s).

For reference, we will be using the following URL and highlighting the sticking points that you should be focusing on and implementing in your environments to secure the Linux kernel:

https://www.sans.org/reading-room/whitepapers/linux/linux-kernel-hardening-1294

The Linux kernel is an always-developing and maturing piece of the Linux ecosystem and for this reason, it's important to get a firm grasp on the Linux kernel as it stands currently, which will help when looking to lockdown the new feature sets that might come in future releases.

The Linux kernel allows loading modules without having to recompile or reboot, which is great when you are looking to eliminate downtime. Some various operating systems require reboots when trying to apply updates to a certain operating system/application criteria. This can also be a bad thing with regards to the Linux kernel as the attackers can inject harmful material into the kernel and wouldn't need to reboot the machine, which might be caught by someone noticing the reboot of the system. For this reason, it is suggested that a statically compiled kernel with the load option be disabled to help prevent against attack vectors.

Buffer overflows are another way attackers can compromise a kernel and gain entry. Applications have a limit, or buffer, on how much a user can store in memory. An attacker overflows this buffer with specially crafted code, which could let the attacker gain control of the system that, in turn, will empower them to do whatever they want at that point. They could add backdoors to the system, send logs off to a nefarious place, add additional users to the system, or even lock you out of the system. To prevent these type of attacks, there are three areas of focus that the guide hones in on.

The first is the Openwall Linux kernel patch that was a patch created to address this issue. This patch also includes some other security enhancements that might be attributed to your running environments. Some of these items included restricted links and file reads/writes in the /tmp folder location and restricted access to the /proc locations on the filesystem. It also includes enhanced enforcement for a number of user processes that you could control as well as the ability to destroy shared memory segments, which were not in use, and lastly, some other enhancements for those of you that are running kernel versions older than version 2.4.

If you are running an older version of the Linux kernel, you will want to check out the Openwall hardened Linux at http://www.openwall.com/Owl/ and Openwall Linux at http://www.openwall.com/linux/.

The next piece of software is called Exec Shield and it takes a similar approach to the Openwall Linux kernel patch, which implements a non-executable stack, but Exec Shield extends this by attempting to protect any and all segments of virtual memory. This patch is limited to the prevention of attacks against the Linux kernel address space. These address spaces include stack, buffer, or function pointer overflow spaces.

More information about this patch can be found at https://en.wikipedia.org/wiki/Exec_Shield.

The last one is PaX, which is a team that creates a patch for the Linux kernel to prevent against a variety of software vulnerabilities. As this is something we will be talking about in-depth in the next section, we will just discuss some of its features. This patch focuses on the following three address spaces:

  • PAGEEXEC: These are paging-based, non-executable pages
  • SEGMEXEC: These are segmentation–based, non-executable pages
  • MPROTECT: These are mmap() and mprotect() restrictions

To learn more about PaX, visit https://pax.grsecurity.net.

Now that you have seen how much efforts you had to put in, you should be glad that security is now at the forefront for everyone, especially, the Linux kernel. In some of the later chapters, we will be looking at some of the following new technologies that are being used to help secure environments:

  • Namespaces
  • cgroups
  • sVirt
  • Summon

There are also a lot of capabilities that can be accomplished through the --cap-ad and --cap-drop switches on your docker run command.

Even like the days before, you still need to be aware of the fact that the kernel is shared throughout all your containers on a host, therefore, you need to protect this kernel and watch out for vulnerabilities when necessary. The following link allows you to view Common Vulnerabilities and Exposures (CVE) in the Linux kernel:

https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/cvssscoremin-7/cvssscoremax-7.99/Linux-Linux-Kernel.html

Access controls

There are various levels of access controls that you can layer on top of Linux as well as recommendations that you should follow with reference to certain users, and these would be the superusers on your system. Just to give some definition to superusers, they are the accounts on the system that have unfettered access to do anything and everything. You should include the root user when you are layering on these access controls.

These access control recommendations will be the following:

  • Restricting usage of the root user
  • Restricting its ability to SSH

    By default, on some systems, root has the ability to SSH to machine if SSH is enabled, which we can see from a portion of the /etc/ssh/sshd_config file on some Linux systems, as follows:

    # Authentication:

#LoginGraceTime 2m
#PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

    From what you can see here, the section for PermitRootLogin no is commented out with the # symbol so that means this line won't be interpreted. To change this, simply remove the # symbol and save the file and restart the service. The section of this file should now be similar to the following code:

    # Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

    Now, you may want to restart the SSH service for these changes to take affect, as follows:

    $ sudo service sshd restart
  • Restrict its ability to log in beyond the console. On most Linux systems, there is a file in /etc/default/login and in that file, there is a line that is similar to the following:
    #CONSOLE=/dev/console

    Similar to the preceding example, we need to uncomment this line by removing # for this to take affect. This will only allow the root user to log in at console and not via SSH or other methods.

  • Restrict su command

    The su commands allow you to login as the root user and be able to issue root-level commands, which gives you full access to the entire system. To restrict access to who can use this command, there is a file located at /etc/pam.d/su, and in this file, you will see a line similar to the following:

    auth required /lib/security/pam_wheel.so use_uid

    You can also choose the following line of code here, depending upon your Linux flavor:

    auth required pam_wheel.so use_uid

    The check for wheel membership will be done against the current user ID for the ability to use the su command.

  • Requiring sudo to run commands
  • Some other access controls that are remanded are the use of the following controls:
    • Mandatory Access Controls (MAC): Restricting what users can do on systems
    • Role-Based Access Controls: Using groups to assign the roles that these groups can perform
    • Rule Set Based Access Controls (RSBAC): Rule sets that are grouped in the request type and performs actions based on set rule(s)
    • Domain and Type Enforcement (DTE): Allow or restrict certain domains from performing set actions or preventing domains from interacting with each other

You can also utilize the following:

  • SELinux (RPM-based systems (such as Red Hat, CentOS, and Fedora)
  • AppArmor (apt-get-based systems (such as Ubuntu and Debian)

These RSBAC, as we discussed earlier, allow you to choose methods of control that are appropriate for what your system is running. You can also create your own access control modules that can help enforce. By default, on most Linux systems, these type of environments are enabled or in enforcing mode. Majority of people will turn these off when they create a new system, but it comes with security drawbacks, therefore, it's important to learn how these systems work and use them in the enabled or enforcement mode to help mitigate further risks.

More information about each can be found at the following:

Distribution focused

There are many Linux distributions, or flavors as they call them, in the Linux community that have been pre-baked to be already hardened. We referenced one earlier, the Owlwall flavor of Linux, but there are others out there as well. Out of the other two, one that is no longer around is Adamantix and the other is Gentoo Linux. These Linux flavors feature some baked-in Linux kernel hardening as standards of their operating system builds.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset