Linux hardening with sysctl

Linux Sysctl Hardening

The GNU/Linux kernel powers a lot of systems, from big mainframes to the Android device in your pocket. If you want to achieve more security on your Linux systems, it would make sense to start hardening there, right? While securing the kernel looks easy at first sight, there is more to it than initially meets the eye. Let’s have a look at some kernel options and defining the best sysctl values for Linux systems.

Why Invest Time in Kernel Security?

There is a lot going on within the Linux kernel. It is a complicated machine, doing the most low-level activities possible, like writing bits to disk, or sending data to the video buffer. When we look at it from a security point of view, there are a few areas which can use our attention:

  • File Systems
  • Kernel modules
  • Networking
  • Processes
  • Debugging

The options to harden the system in these areas depend on the type of kernel you use (monolithic or dynamic). When using a big monolithic kernel, every required module is added during compilation time. For security a good thing. At the same time, it also means less flexibility. For that reason, it is common to see the “dynamic” kernel being used. This means we can alter the behavior of the kernel during runtime. The most obvious example is loading new kernel modules, to provide more information. Something that is not possible with a monolithic kernel.

Kernel Tuning

Kernel parameters are one of the things we can change independently of how the kernel was built. By using a system control interface, we can talk to the kernel and read and change some settings. Good to know is that this is a powerful way to influence the behavior of the kernel. So it also comes with some risk. Still, it is definitely worth better understanding several of these areas, to optimize your kernel and have an increased level of performance and security. By knowing the details of these so called tunables, you can find the best possible sysctl values for your environment.

The interface to the kernel parameters is a commonly available utility named sysctl, short for system control. It talks with the Linux system control interface, which allows reading and writing to the available settings. These settings we call key-value pairs. So when referring to a sysctl key, we mean the setting by its name (e.g. vm.panic_on_oom). We can query the values with the sysctl command.

sysctl -a

The output will look something like this:

Screenshot of sysctl output, useful for kernel hardening

Overview of kernel settings

Procfs

Before we dive into some of these kernel settings, it is good to know that on Linux you will need the procfs file system. Usually you will not have to configure this, as it will be deployed automatically by your Linux distribution. To know if you have it, simply use mount and search for proc. And most likely it is mounted on /proc.

proc on /proc type proc (rw,noexec,nosuid,nodev)

This /proc mount point is based on a pseudo file system. That means the files in there are not normal files. Instead, they are special file handles for usage by the kernel and the system administrator. By using the cat command, we can see the value of a particular entry in /proc. Some of the available allow also writing, which equals setting a setting. The /proc mount point contains a lot of files. For this article, we have a special interest in the files in /proc/sys, as they reflect the keys used by sysctl.

When we have another look at the image above, we see several keys starting with “kernel.”. If we map these against the /proc file system, we will see they are in /proc/sys/kernel.

Screenshot of files in /proc/sys/kernel

So when looking in /proc/sys, we can see that the main categories are:

  • abi (application binary interface)
  • debug (debugging)
  • dev (devices)
  • fs (file systems)
  • kernel (kernel)
  • net (network)
  • vm (virtual memory)

Understanding Sysctl Keys and Values

Now comes the tricky part: understanding all the keys as part of these categories. Some of them will give a good idea, like /proc/sys/kernel/ctrl-alt-del, which determines how to act on this particular key combination. Most other keys remain cryptic for most of us. Fortunately, we have the web, and there are some places where we can find more about them. One of these resources is the kernel documentation project.

If we use the /proc/sys/kernel/ctrl-alt-del example, that means we can see its current value by catting the file.

cat /proc/sys/kernel/ctrl-alt-del

On our test system this gives back a “0” (zero). A first guess would make us think that it is disabled. To be sure, we look in the kernel documentation and see:

ctrl-alt-del:

When the value in this file is 0, ctrl-alt-del is trapped and
sent to the init(1) program to handle a graceful restart.
When, however, the value is > 0, Linux's reaction to a Vulcan
Nerve Pinch (tm) will be an immediate reboot, without even
syncing its dirty buffers.

Note: when a program (like dosemu) has the keyboard in 'raw'
mode, the ctrl-alt-del is intercepted by the program before it
ever reaches the kernel tty layer, and it's up to the program
to decide what to do with it.

So in other words, the key combination is not disabled. It is actually intercepted and the init process can make a decision on how to handle it. Now the interesting part is that Linux distributions will handle this differently, especially now with systemd being common. Before the action to take by the init process would be in /etc/inittab.

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

With systems using systemd, it will be depending on a target file (/usr/lib/systemd/system/ctrl-alt-del.target) and might look like this:

# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.

[Unit]
Description=Reboot
Documentation=man:systemd.special(7)
DefaultDependencies=no
Requires=systemd-reboot.service
After=systemd-reboot.service
AllowIsolate=yes
JobTimeoutSec=30min
JobTimeoutAction=reboot-force

[Install]
Alias=ctrl-alt-del.target

As you can see, a fairly simple kernel sysctl key, might require some more reading, before making a decision on the best sysctl value. So if you really want to disable the Ctrl+Alt+Del combination, you might want to change this systemd target file. Instead of calling the systemd-reboot.service, it should do nothing, so it truly ignores it.

Making Changes

If you want to change a specific kernel setting, then “write” it to the file. The simple way of doing this is by using the echo command. So to set the ctrl-alt-del key from our previous example to 0 (zero) as well:

echo 1 > /proc/sys/kernel/ctrl-alt-del

Simple as that, and easy to script. Even deployment with a configuration management tool like Ansible or Puppet can help configuring your systems properly. That is, if you fully understood what to tune (and why).

Why Use Sysctl?

So although it is possible to change runtime behavior of the kernel via the pseudo file system /proc, the sysctl utility has some advantages. The first one is that it can save settings in a file, which gets used upon a reboot. Second reason is that the tool can quickly gather all settings and display it (even with regular expressions!).

Configuration File: /etc/sysctl.conf

Sysctl can store configured settings in /etc/sysctl.conf. Then during boot time, these settings are applied. So it is good to understand that changing a kernel setting, will not make it permanent. Like making a change to a file in /proc, the sysctl can make a similar change. In our earlier example, that would be setting ctrl-alt-del to 0 (zero). As this setting is part of “kernel”, let’s change it.

sysctl -w kernel.ctrl-alt-del=0

To read the value, we use sysctl again.

sysctl kernel.ctrl-alt-del

It should now display the previously set value. Notice that some values can’t be set, as they are special counters or special purpose keys. So know this rule does not apply to all settings.

Another way to set a variable is changing the /etc/sysctl.conf variable, and reload the file. This way we can check if the setting is changed, and will be properly applied next boot as well.

sysctl -p /etc/sysctl.conf

By default /etc/sysctl.conf is used. In this case, the file name was not needed. For testing purposes it could make sense to use a different file. Then when everything works as expected, make the changes to /etc/sysctl.conf.

Showing Keys with Regular Expressions

To see all keys, we use the -a or –all parameter. If we combine this with pattern, we can quickly display all items containing a particular word.

sysctl -a --pattern "ipv6"

If you are into regular expressions, you can go wild ;-)

In later posts, we will go into more sysctl values for security. Got more tips for people new to this subject? Use the comments and let us know!

Lynis Enterprise

Lynis Enterprise screenshot to help with system hardening

This blog post is part of our Linux security series and the mission to get Linux and Unix-based systems more secure.

Does system hardening take a lot of time, or do you have any compliance in your company? Have a look at Lynis Enterprise.

Or start today with the open source security scanner Lynis (GitHub)


Leave a Reply

Your email address will not be published. Required fields are marked *