Differences

This shows you the differences between two versions of the page.

--- systems:media_server:secure_the_server:harden_linux_kernel_configuration_parameters [2025/05/31 13:41] – peter
+++ systems:media_server:secure_the_server:harden_linux_kernel_configuration_parameters [2025/05/31 16:07] (current) – peter
@@ Line 14: / Line 14: @@
 ----
-====== Make a backup of the existing /etc/sysctl.conf file ======
+===== Make a backup of the existing /etc/sysctl.conf file =====
 <code bash>
@@ Line 22: / Line 22: @@
 ----
-====== Modify the sysctl file ======
+===== Modify the sysctl file =====
 Add the following entries to the bottom of the **/etc/sysctl.conf** file to stop some spoofing attacks and enhance other security measures:
@@ Line 74: / Line 74: @@
 # Additional Security Measures
-dev.tty.ldisc_autoload = 0
+#dev.tty.ldisc_autoload = 0
 #kernel.modules_disabled = 1
 kernel.core_uses_pid = 1
@@ Line 87: / Line 87: @@
 ----
-====== Activate the kernel settings that have been modified ======
+===== Activate the kernel settings that have been modified =====
 This reloads the sysctl parameters:
@@ Line 94: / Line 94: @@
 sudo sysctl -p
 </code>
-<WRAP info>
-**NOTE:**
-  * **kernel.kptr_restrict=2** - A kernel pointer points to a specific location in kernel memory.
-    * These can be very useful in exploiting the kernel, but kernel pointers are not hidden by default — it is easy to uncover them by, for example, reading the contents of /proc/kallsyms.
-    * This setting aims to mitigate kernel pointer leaks.
-    * Alternatively, you can set kernel.kptr_restrict=1 to only hide kernel pointers from processes without the CAP_SYSLOG capability.
-  * **kernel.dmesg_restrict=1** - dmesg is the kernel log.
-    * It exposes a large amount of useful kernel debugging information, but this can often leak sensitive information, such as kernel pointers.
-    * Changing the above sysctl restricts the kernel log to the CAP_SYSLOG capability.
-  * **kernel.printk=3 3 3 3** - Despite the value of dmesg_restrict, the kernel log will still be displayed in the console during boot.
-    * Malware that is able to record the screen during boot may be able to abuse this to gain higher privileges.
-    * This option prevents those information leaks.
-    * This must be used in combination with certain boot parameters described below to be fully effective.
-  * **kernel.unprivileged_bpf_disabled=1** and
-  * **net.core.bpf_jit_harden=2** - eBPF exposes quite large attack surface.
-    * As such, it must be restricted.
-    * These sysctls restrict eBPF to the CAP_BPF capability (CAP_SYS_ADMIN on kernel versions prior to 5.8) and enable JIT hardening techniques, such as constant blinding.
-  * **dev.tty.ldisc_autoload=0** - This restricts loading TTY line disciplines to the CAP_SYS_MODULE capability to prevent unprivileged attackers from loading vulnerable line disciplines with the TIOCSETD ioctl, which has been abused in a number of exploits before.
-  * **vm.unprivileged_userfaultfd=0** - The userfaultfd() syscall is often abused to exploit use-after-free flaws.
-    * Due to this, this sysctl is used to restrict this syscall to the CAP_SYS_PTRACE capability.
-  * **kernel.kexec_load_disabled=1** - kexec is a system call that is used to boot another kernel during runtime.
-    * This functionality can be abused to load a malicious kernel and gain arbitrary code execution in kernel mode, so this sysctl disables it.
-  * **kernel.sysrq=4** -  The SysRq key exposes a lot of potentially dangerous debugging functionality to unprivileged users.
-    * Contrary to common assumptions, SysRq is not only an issue for physical attacks, as it can also be triggered remotely.
-    * The value of this sysctl makes it so that a user can only use the secure attention key, which will be necessary for accessing root securely.
-    * Alternatively, you can simply set the value to 0 to disable SysRq completely.
-  * **kernel.unprivileged_userns_clone=0** -
-</WRAP>
 ----