The kernel is responsible for the (innermost) basic functions of a Linux system.
It takes care of controlling the hardware, processing and managing the memory, and so on. Usually, the kernel is optimized to perform its tasks quickly and easily. From a security point of view, however, the basic settings aren’t always ideal.
In this blog post, we’ll give you some tips on how to make the kernel more secure. For example, you can use an option to prevent users without root privileges from reading the entire process list and other internal kernel information. From a security point of view, such settings are quite recommendable. Note, however, that the measures are associated with functional limitations and are therefore not target-oriented in every case.
Basically, there are three ways to influence the behavior of the kernel:
Many parameters of the kernel can be changed during operation via the /proc file system or much more elegantly by using the sysctl command. The first command reads the current state of kernel.kptr_restrict, while the second command changes it:
sysctl kernel.kptr_restrict
kernel.kptr_restrict = 1
sysctl -w kernel.kptr_restrict=2
Note that you must not use any spaces before or after the equal sign (=) in the second command!
sysctl -a returns a list of all kernel parameters along with their current settings. (Currently there are about 1,000 such parameters!) You can use sysctl -p to activate the sysctl settings stored in a file. Usually /etc/sysctl.conf is used as the file name. With most distributions, this file is automatically evaluated at system startup.
The following listing shows some useful settings. The explanations given are simplified or shortened for reasons of space. In particular, the use of many functions doesn’t require root privileges as specified here, but only certain capabilities. Based on this mechanism, processes running without root privileges can still use selected functions with extended privileges (see http://s-prs.co/v5696115):
# access to kernel logging (dmesg command) only
# with root privileges
kernel.dmesg_restrict=1
# use of the Extended Berkeley Packet Filter
# (sandboxing) only with root privileges
kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2
# prevents a kernel reboot at runtime
kernel.kexec_load_disabled=1
# kernel debugging only with root privileges
kernel.sysrq=4
# debugging other processes only with root privileges
kernel.yama.ptrace_scope=2
# prevents SYN flood attack
net.ipv4.tcp_syncookies=1
# disables the ping function
net.ipv4.icmp_echo_ignore_all=1
Further Reading: You can find useful descriptions of numerous sysctl options at https://sysctl-explorer.net.
References with further options that can be changed for kernel hardening are provided at the following two pages:
In RHEL, Ubuntu, and most other Linux distributions, the kernel is started via GRUB. This makes the Grand Unified Bootloader the first program to run after a server or virtual machine is powered on. GRUB searches for the Linux kernel file on the disk, loads the file into the memory, and executes it. On this occasion, GRUB can pass boot options to the kernel.
To change these options, you need to load the /etc/default/grub file into an editor and
modify the GRUB_CMDLINE_LINUX line. At the end of this line, you can integrate your own
options. Some options are used without parameters, whereas others expect one or several
parameters (para=value1,v2,v3). Again, it’s important that you don’t insert any spaces around the parameters of an option!
Changes to /etc/default/grub take effect only if you first update the GRUB configuration derived from the default file and then restart the server. For this purpose, you want to run the following commands:
grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL & clones only)
update-grub (Debian/Ubuntu only)
reboot (always)
We only present two boot options here as examples. But of course there are many more of them. However, before you blindly follow instructions from the internet and change boot options, you should do thorough research to rule out any undesirable side effects:
Editor’s note: This post has been adapted from a section of the book Hacking and Security: The Comprehensive Guide to Penetration Testing and Cybersecurity by Michael Kofler, Klaus Gebeshuber, Peter Kloep, Frank Neugebauer, André Zingsheim, Thomas Hackner, Markus Widl, Roland Aigner, Stefan Kania, Tobias Scheible, and Matthias Wübbeling.