Skip to main content
Proceed at Your Own Risk: Changing kernel settings with sysctl is risky and could break your server. If you don’t know what you are doing, don’t have the time to debug issues, or just don’t want to take the risks, do not follow these steps.

Overview

The kernel is the brains of a Linux system. Securing it through sysctl parameters can provide additional hardening against various attacks and improve overall system security.

Why Sysctl Hardening?

Kernel hardening helps protect against:
  • Spoofing attacks
  • Denial of Service (DOS) attacks
  • Network-based exploits
  • Local privilege escalation
  • Information disclosure

Important Disclaimer

These settings are compiled from multiple reputable sources. Most of them are for general kernel hardening and performance, while others protect against spoofing and DOS attacks. Test each setting thoroughly before deploying to production.
Documentation for these settings references the Linux 2.2 kernel. Settings may have changed in newer kernels. Always test in a non-production environment first.

Testing Sysctl Changes

Before making any kernel sysctl change permanent, test it with the sysctl command:
Example:
There are no spaces in key=value, including before and after the equals sign.

Making Changes Permanent

Once you have tested a setting and verified it works without breaking your server, make it permanent by adding the values to /etc/sysctl.conf:
After updating the file, reload the settings:
If sysctl has trouble writing any settings, sysctl -w or sysctl -p will write an error to stderr. You can use this to quickly find invalid settings:

Sysctl Parameters Reference

Below is a comprehensive table of recommended sysctl hardening parameters:

File System Parameters

Kernel Parameters

Network Core Parameters

IPv4 Configuration Parameters

IPv4 ICMP Parameters

IPv4 General Parameters

IPv4 Neighbor Parameters

IPv4 TCP Parameters

IPv4 UDP Parameters

IPv6 Configuration Parameters

Unix Domain Socket Parameters

Virtual Memory Parameters

Additional Resources

This comprehensive list is compiled from multiple trusted sources:
Always test sysctl changes in a non-production environment before deploying to production systems. Keep backups and have a recovery plan ready.