Linux hardening with sysctl settings

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. We will have a look at some kernel options and how to select the best sysctl values for Linux systems.

After reading this article you know…

• Why you should take care of tuning the Linux kernel and apply hardening measures
• What some of these hardening measures are useful
• How to use sysctl and make changes to the system
• How to ensure that sysctl settings are applied after reboots

Why invest time in Linux kernel security?

There is a lot going on within the Linux kernel. It is like a complicated machine with many small tasks to perform. Most of these tasks are low-level interactions with the hardware, 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:

The procfs file system

Before we dive into some of these kernel settings, it is good to know that on Linux you will need the procfs file system. You will not have to configure this usually, 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.

Many common system administration utilities are using the /proc file system. Examples are tools like ps, free, top, and watch.

Understanding the structure in /proc/sys

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.

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)

Using 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. For that reason, there is a sysctl overview.

Another source is to look at 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 returns a value of 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:

# cat /usr/lib/systemd/system/ctrl-alt-del.target
# 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.

Changing kernel settings

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 in configuring your systems properly. That is, if you fully understood what to tune and why.

Why use sysctl instead of /proc?

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. The second reason is that the tool can quickly gather all settings and display it (even with regular expressions!).

Making temporary changes

It is good to know that changing a kernel setting will not change it permanently. If you use sysctl to set a value, that is similar to making a change to a file in the /proc directory. In our earlier example, we changed the ctrl-alt-del setting and gave it a value of zero (0). Do to this with sysctl, we add the category followed by a dot and the key. As this setting is part of the category kernel, the related command would be:

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.

Making permanent changes

Configuration file: /etc/sysctl.conf

Sysctl can store configured settings in /etc/sysctl.conf . These settings are applied during boot time.

Configuration directory: /etc/sysctl.d

Modern Linux distributions don’t store all settings into one big file, but split into smaller sections. These individual files are stored in /etc/sysctl.d. Together with sysctl.conf they form the sysctl configuration.

Reloading the sysctl configuration

Another way to set a variable is changing the /etc/sysctl.conf and reload it. 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 or better, a separate file in /etc/sysctl.d.

Showing keys with regular expressions

To see all keys, we use the -a or -all parameter. If we combine this with a 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 ;-)

Did you learn something from this article? Great! Got any questions or suggestions? Let it know!