Check and harden your Linux kernel security parameters with sysctl …and automatize it!

Check and harden your Linux kernel security parameters with sysctl …and automatize it!

 Sysctl parameters are often overlooked when doing Linux hardening; learn how kernel parameters are materialized in userland, how to check what the security parameters are with sysctl to harden your hosts and how to automatize the check of a baseline against running Linux hosts.

 /proc/sys and sysctl

 The Linux kernel exposes parameters as files in the /proc/sys directory. These influence on multiple aspects of a host, including security. Most of these parameters can be modified at run-time, once the kernel is booted. The most notable subfolders of this hierarchy are the below:

 fs/            specific filesystems

               filehandle, inode, dentry and quota tuning

               binfmt_misc

kernel/        global kernel info / tuning

               miscellaneous stuff

net/           networking stuff

vm/            memory management tuning

               buffer and cache management

user/          Per user per user namespace limits

(see https://www.kernel.org/doc/Documentation/sysctl/README for a full list and details on each of the subfolders)

Each parameter is indeed a file under this hierarchy that can be written with root privileges and, most of the time, read by everyone. For example, the below example checks for the value of IPv4 forwarding on the machine, which is disabled in that case: 

 $ ls -l /proc/sys/net/ipv4/ip_forward

-rw-r--r-- 1 root root 0 Dec  3 02:41 /proc/sys/net/ipv4/ip_forward

$ cat /proc/sys/net/ipv4/ip_forward

0

Security is spread amongst the different subfolders of the above /proc/sys subfolders and does not constitute a subfolder per-se. Hence, it is necessary to check and modify all these categories to get a full vision of what the security level of a host is. Checking every file by hand was a tedious task and the kernel contributors created a userland tool called sysctl to abstract this hierarchy for users. Sysctl allow to pull the entire configuration of the system:

 # sysctl -a

abi.vsyscall32 = 1

crypto.fips_enabled = 0

debug.exception-trace = 1

debug.kprobes-optimization = 1

dev.cdrom.autoclose = 1

…

Get and set a key:

 # sysctl -n net.ipv4.ip_forward                                                                                                                                                                                                      

0

# sysctl -w net.ipv4.ip_forward=1

net.ipv4.ip_forward = 1

Or search for one:

 # sysctl -a -r 'forwarding'

net.ipv4.conf.all.bc_forwarding = 0

net.ipv4.conf.all.forwarding = 1

…

net.ipv4.ip_forward = 1

…

Building a security baseline

What parameter to set to what value is not an obvious task. For example, what value is secure for a web server might not be for a router and vice-versa. To address this problem and the lack of knowledge around it, several entities such as the American National Security Agency (NSA), the Center for Internet Security (CIS) or the National Cybersecurity Agency of France (ANSSI) have published recommendation guides and whitepapers on the subject. These can give the reader a good overview of what is relevant, what is not, and what may break production systems if set too quickly or with a too conservative approach.

But the reality is that these lists of parameters need to be modified to fit one’s business needs and security level. Not every business can follow the same requirements of defence sector’s actors and not every individual is willing to lose performance in favour of security.

Indeed, it should be kept in mind that performance can also be impacted by changing these parameters and that every change should be subject to a test period in a test environment.

The solution to this problem is to make a custom list of parameters, specifically selected for the needs of the target hosts. I can only encourage to do so. Not only will it fit your needs, but it may also teach you something in the process.

Automatization

I made a small shell script to automatize the check of a sysctl reference file containing the wanted values for security parameters against the current values of these parameters on a system, it can be found here:

https://github.com/jeffbencteux/sysctlchk

I also added a default reference file that can be used as a starting point by users that do not know yet what is available or relevant in terms of security parameters in the Linux kernel. Be aware that this list is by no mean exhaustive.

Hardening of Linux suffers too much of the perfect being the enemy of the better, you can start with a list of basic hardening parameters and then build it over time. It is also a continuous process so this kind of checks should be conducted regularly to ensure systems are correctly protected and do not deviate from the security policy.