Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsOn a Linux server, keep a supported, patched kernel; retain its built-in self-protection; enforce the SELinux or AppArmor policy supported by your distribution; and apply a tested seccomp profile to each service that can use one. Restrict kernel-module loading when your drivers and recovery process allow it. Treat KASLR and kernel-address exposure controls as additional layers, not substitutes for updates or access controls. There is no universal sysctl checklist: settings and defaults depend on the distribution, kernel, boot chain, and workload.
Which hardening choices matter most?
Kernel hardening is layered. The upstream kernel describes mechanisms that reduce attack surface and make exploitation harder, while its threat model makes clear that these protections do not eliminate vulnerabilities or guarantee security. Keep the kernel and distribution security updates current, then select controls that fit the server’s actual services and operating model. See the Linux kernel threat model and kernel self-protection documentation.
| Choice | What to weigh | Practical direction |
|---|---|---|
| SELinux or AppArmor | Distribution support, policy availability, operator skill, application compatibility, and audit workflow | Use the option your distribution supports and your team can maintain with effective policy. Kernel LSM usage; AppArmor documentation. |
| Seccomp profile strictness | The syscalls the workload needs, profile upkeep, runtime support, and diagnostic impact | Reduce the service’s available syscall surface, but test its real lifecycle. Seccomp BPF documentation. |
| Signed modules or disabled module loading | Required drivers, hardware changes, update workflow, boot integrity, and recovery access | Constrain arbitrary module loading using the approach compatible with required drivers and operations. Kernel self-protection documentation. |
| Host and container controls | Workload privilege, runtime policy, host LSM, capabilities, and administrative boundaries | Layer controls across host and workload; avoid privileged containers unless necessary. Kubernetes kernel security constraints. |
| Kernel defaults or custom sysctls | Distribution and version, threat model, compatibility, persistence, and verification | Keep supported defaults unless a defined risk warrants a tested change; do not assume defaults match across distributions. Ubuntu kernel protections. |
Keep kernel self-protection and memory protections enabled
Prefer a supported distribution kernel with its self-protection features enabled. The kernel documentation describes strict permissions intended to prevent executable code from being writable, data from being executable, and read-only data from being writable. It says most architectures enable these options by default, but implementation and configurability vary by architecture. Avoid disabling them to address an unrelated compatibility issue without understanding the security and operational trade-off.
KASLR and kernel-address exposure
Kernel Address Space Layout Randomization (KASLR) randomizes kernel memory placement, making attacks that rely on known addresses harder. It is probabilistic: information leaks can weaken its value, so it belongs alongside patching and access controls rather than serving as a standalone barrier. Kernel-address exposure controls, including kernel.kptr_restrict, are also relevant, but their defaults and behavior are distribution-specific. Ubuntu’s kernel-protection guidance is specific to Ubuntu; do not apply its defaults to another distribution without checking that system’s documentation.
#1 Best Overall
Use the distribution’s supported SELinux or AppArmor policy
SELinux and AppArmor are examples of Linux Security Modules (LSMs), the kernel framework that provides hooks for security checks. The active LSM list can be inspected at /sys/kernel/security/lsm. Framework support alone does not establish that a particular service is confined; use the policy system supported by your distribution and ensure it is actually applied.
AppArmor requires a loaded profile
AppArmor applies task-centered profiles. A task without a profile is unconfined by AppArmor, and userspace must load a profile for it to enforce restrictions beyond ordinary discretionary access controls. Therefore, an installation or an enabled framework is not proof that a service has an effective AppArmor policy. Confirm the relevant service profile is loaded and enforcing before relying on it. See the upstream AppArmor documentation.
Rank #2
Do not switch LSM configuration casually
Changing LSM selection or boot parameters can affect which policy is available and how the distribution expects it to be configured. Follow the distribution’s supported setup and policy set rather than transplanting instructions from another system.
Apply a tested seccomp policy to services
Seccomp is an opt-in userspace mechanism for reducing the kernel system calls available to a process. In the kernel documentation’s words, “The “seccomp” system provides an opt-in feature made available to userspace, which provides a way to reduce the number of kernel entry points available to a running process.” Use a profile supplied or maintained by the service, service manager, or container runtime when available; otherwise, ensure the policy is matched to the program’s actual needs. The seccomp documentation explains the interface and its role.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Test the profile against startup, normal operation, upgrades, diagnostics, and recovery. An overly restrictive filter can break legitimate behavior. Seccomp also does not express every logical behavior or information-flow policy; the kernel documentation frames it as one component of a broader security policy, which may also require an LSM.
For Kubernetes workloads
Apply workload policy alongside host protections and least privilege. Kubernetes warns that privileged containers can override or undo protections such as seccomp, AppArmor, or SELinux constraints. Grant privileged mode only when the workload genuinely requires it, and account for that exception in the security boundary. See Kubernetes’ documentation on Linux kernel security constraints.
Rank #4
Restrict kernel-module loading with an operations plan
Arbitrarily loaded kernel modules can add code with kernel-level authority. The kernel’s self-protection guidance describes signed modules and disabling module loading as ways to prevent arbitrary code from being loaded. Choose a restriction that fits the system: a server relying on externally supplied drivers or frequent hardware changes may be disrupted by a blanket module ban.
Before enforcing a restriction, inventory required modules, validate how signing and boot policy work on the target distribution, and document how to recover if a driver or hardware change is needed. Kernel lockdown may provide another layer where the distribution, boot chain, kernel configuration, and LSM initialization support it; its availability and effects are not uniform enough to assume a default or prescribe a cross-distribution command. Check the relevant distribution documentation before enabling it.
Make sysctl changes only for a defined, verified need
Sysctls can limit exposure, but kernel and distribution defaults differ. The available guidance does not establish one complete set of numeric values that is safe for every Linux server. Avoid copying generic “hardening” snippets as a universal baseline: a setting may be inappropriate for a particular distribution, workload, or compatibility requirement.
For any proposed sysctl change, identify the specific risk it addresses, consult the target distribution’s documentation for the relevant kernel version, check the effective value on that host, and test the change against the service and recovery workflow. Ubuntu’s kernel-protection page is useful for Ubuntu systems, not evidence of identical defaults elsewhere. The ANSSI Linux configuration recommendations are another configuration reference; apply version-specific recommendations against the target system and its current policy.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
