Linux Hardening 16 min leestijd

Linux Kernel Hardening met Sysctl: Gids voor Beveiligingsparameters

Leer hoe je de Linux-kernel verhardt met sysctl-parameters. Stap-voor-stap gids met netwerk-hardening, ASLR, eBPF-beveiliging, boot-parameters, kernel-hardening-checker audit en Ansible-automatisering — afgestemd op CIS Benchmarks 2026.

Editorial Team

De Linux-kernel heeft honderden runtime-parameters die bepalen hoe je systeem zich gedraagt — van netwerkverkeer tot geheugenbeheer en procesbeveiliging. Het probleem? Standaard staan die parameters ingesteld op maximale compatibiliteit, niet op veiligheid. En dat is precies waar sysctl om de hoek komt kijken.

Met sysctl pas je kernelparameters aan zonder de kernel opnieuw te compileren of je server te herstarten. Eerlijk gezegd is het een van de meest onderschatte beveiligingstools die je tot je beschikking hebt. In deze gids lopen we stap voor stap door alle essentiële beveiligingsparameters, inclusief boot-time hardening, geautomatiseerde audits met kernel-hardening-checker, en automatisering met Ansible — volledig afgestemd op de CIS Benchmarks van 2026.

Wat is sysctl en waarom zou je het gebruiken?

sysctl is een interface waarmee je kernelparameters leest en wijzigt via het virtuele bestandssysteem /proc/sys/. De parameters zijn verdeeld over een aantal categorieën:

  • /proc/sys/net/ — netwerkconfiguratie (TCP/IP, firewalling, routing)
  • /proc/sys/kernel/ — kernelgedrag (logging, proces-isolatie, BPF)
  • /proc/sys/fs/ — bestandssysteembeveiliging (symlinks, hardlinks, core dumps)
  • /proc/sys/vm/ — virtual memory management (ASLR, swappiness, overcommit)

Om het even in perspectief te plaatsen: in 2025 werden er 5.530 CVE's geregistreerd voor de Linux-kernel. Dat zijn gemiddeld 8 tot 9 nieuwe kwetsbaarheden per dag. Veel van die aanvallen richten zich op standaard kernelconfiguraties. Door sysctl-parameters correct in te stellen, verklein je het aanvalsoppervlak aanzienlijk — en voorkom je hele categorieën exploits voordat ze überhaupt een kans krijgen.

Sysctl-parameters instellen en persistent maken

Er zijn drie manieren om sysctl-parameters in te stellen. Laten we ze even langslopen.

Tijdelijke wijziging (verloren na herstart)

# Enkele parameter wijzigen
sudo sysctl -w net.ipv4.tcp_syncookies=1

# Huidige waarde opvragen
sysctl net.ipv4.tcp_syncookies

Handig voor testen, maar na een reboot ben je alles kwijt.

Permanente wijziging via configuratiebestanden

Voor persistente instellingen gebruik je drop-in bestanden in /etc/sysctl.d/. Dit is echt beter dan /etc/sysctl.conf direct bewerken — het is overzichtelijker en distributieupdates overschrijven je wijzigingen niet.

# Maak een beveiligingsspecifiek configuratiebestand
sudo nano /etc/sysctl.d/90-security-hardening.conf

# Pas alle instellingen toe zonder herstart
sudo sysctl --system

Drop-in bestanden worden in alfabetische volgorde geladen. Gebruik een numeriek prefix (zoals 90-) om de laadvolgorde te bepalen. Hogere nummers overschrijven lagere, dus je security-instellingen krijgen voorrang.

Boot-time parameters via GRUB

Sommige beveiligingsparameters kun je alleen bij het opstarten instellen via de kernel command line in /etc/default/grub. Daar gaan we verderop uitgebreid op in.

Netwerkbeveiliging met sysctl

De netwerkstack is doorgaans het grootste aanvalsoppervlak van een Linux-server. Dus hier beginnen we.

SYN flood bescherming en TCP-hardening

# /etc/sysctl.d/90-security-hardening.conf

# SYN cookies inschakelen tegen SYN flood attacks
net.ipv4.tcp_syncookies = 1

# TCP SACK uitschakelen (veelgebruikt aanvalsvector, zelden nodig)
net.ipv4.tcp_sack = 0

# TCP timestamps uitschakelen (voorkomt tijdsgebaseerde fingerprinting)
net.ipv4.tcp_timestamps = 0

# Maximaal aantal SYN-backlog verbindingen verhogen
net.ipv4.tcp_max_syn_backlog = 4096

Anti-spoofing en routebeveiliging

# Reverse Path Filtering inschakelen (strikte modus)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Source routing uitschakelen (voorkomt IP-spoofing)
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# ICMP redirects weigeren (voorkomt MITM-aanvallen)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# Geen ICMP redirects versturen (tenzij je een router bent)
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Secure ICMP redirects alleen accepteren
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

ICMP en broadcast bescherming

# ICMP broadcast echo negeren (Smurf-aanval bescherming)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Ongeldige ICMP-foutmeldingen negeren
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Martian packets loggen (pakketten met onmogelijke bronadressen)
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

IP forwarding uitschakelen

# Schakel IP forwarding uit tenzij de server als router fungeert
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

Let op: Gebruik je Docker, Kubernetes of LXC-containers? Dan moet net.ipv4.ip_forward op 1 blijven staan. Gebruik in dat geval nftables of iptables-regels om forwarding te beperken tot container-netwerken. Dit is een van die parameters waar ik in de praktijk regelmatig vergeten configuraties tegenkom — even checken dus.

Kernel-zelfbescherming en informatielekken voorkomen

Aanvallers gebruiken informatielekken uit de kernel vaak als eerste stap om hun exploits te verfijnen. De onderstaande parameters beperken de zichtbaarheid van kernelinternals — en dat maakt het leven van een aanvaller een stuk lastiger.

Kernellogboeken en symbolen afschermen

# Kernel dmesg logs beperken tot root (voorkomt info-leaks)
kernel.dmesg_restrict = 1

# Kernel pointers verbergen in /proc/kallsyms
kernel.kptr_restrict = 2

# Kernel profiling uitschakelen voor onbevoegde gebruikers
kernel.perf_event_paranoid = 3

eBPF en JIT-compiler hardening

eBPF is geweldig voor monitoring en netwerking, maar het vergroot ook het aanvalsoppervlak behoorlijk. In 2025 en begin 2026 zijn er meerdere CVE's verschenen die eBPF-kwetsbaarheden betroffen. Niet iets om lichtzinnig mee om te gaan.

# Unprivileged BPF uitschakelen
kernel.unprivileged_bpf_disabled = 1

# JIT hardening inschakelen (constant blinding tegen heap spraying)
net.core.bpf_jit_harden = 2

User namespaces en SysRq beperken

# Unprivileged user namespaces uitschakelen (privilege escalation preventie)
kernel.unprivileged_userns_clone = 0

# SysRq key volledig uitschakelen
kernel.sysrq = 0

# Core dumps van SUID-programma's uitschakelen
fs.suid_dumpable = 0

Belangrijk: De parameter kernel.unprivileged_userns_clone is beschikbaar op Debian/Ubuntu-kernels. Op RHEL/AlmaLinux-systemen kun je user namespaces beperken via user.max_user_namespaces = 0. Even opletten dus op welke distro je zit.

Geheugen- en ASLR-hardening

Address Space Layout Randomization (ASLR) maakt het voor aanvallers veel moeilijker om geheugenlocaties te voorspellen. Het is een van de effectiefste beveiligingsmechanismen die de kernel biedt, en toch laten veel beheerders het bij de standaardinstellingen. Zonde.

# Volledige ASLR inschakelen (stack, heap, mmap, VDSO)
kernel.randomize_va_space = 2

# Maximale entropie voor mmap randomisatie
vm.mmap_rnd_bits = 32
vm.mmap_rnd_compat_bits = 16

# Memory overcommit beperken (voorkomt OOM-gebaseerde aanvallen)
vm.overcommit_memory = 0

# Geheugen initialiseren bij allocatie en vrijgave (via boot parameter)
# init_on_alloc=1 init_on_free=1

Bestandssysteembescherming

Deze parameters beschermen tegen TOCTOU (Time-of-Check-Time-of-Use) race conditions en andere bestandsgebaseerde aanvallen. Klinkt misschien theoretisch, maar deze aanvalsvectoren worden in de praktijk echt benut.

# Symlink-bescherming inschakelen
fs.protected_symlinks = 1

# Hardlink-bescherming inschakelen
fs.protected_hardlinks = 1

# FIFO-bescherming inschakelen
fs.protected_fifos = 2

# Regular file bescherming inschakelen
fs.protected_regular = 2

Wat deze parameters doen: ze voorkomen dat gebruikers symlinks of hardlinks aanmaken naar bestanden waar ze geen eigenaar van zijn. Dat is een veelgebruikte techniek bij privilege escalation-aanvallen, vooral in world-writable directories als /tmp.

Kernel boot-parameters voor extra beveiliging

Naast de runtime sysctl-parameters zijn er een aantal cruciale beveiligingsinstellingen die je alleen bij het opstarten van de kernel kunt configureren. Voeg deze toe aan GRUB_CMDLINE_LINUX in /etc/default/grub.

# Bewerk GRUB configuratie
sudo nano /etc/default/grub

# Voeg beveiligingsparameters toe aan GRUB_CMDLINE_LINUX:
GRUB_CMDLINE_LINUX="pti=on init_on_alloc=1 init_on_free=1 slab_nomerge intel_iommu=on amd_iommu=force_isolation randomize_kstack_offset=on modules.sig_enforce=1 lockdown=confidentiality"

# Pas de GRUB configuratie toe
sudo update-grub    # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL/AlmaLinux

Even een overzicht van wat deze parameters precies doen:

  • pti=on — Kernel Page Table Isolation, beschermt tegen Meltdown en bepaalde KASLR-bypasses
  • init_on_alloc=1 init_on_free=1 — initialiseert geheugen met nullen bij allocatie en vrijgave, voorkomt informatielekken
  • slab_nomerge — voorkomt slab-merging, maakt heap-overflow exploits flink moeilijker
  • intel_iommu=on / amd_iommu=force_isolation — IOMMU inschakelen tegen DMA-aanvallen
  • randomize_kstack_offset=on — randomiseert de kernel-stack offset per syscall
  • modules.sig_enforce=1 — staat alleen ondertekende kernelmodules toe
  • lockdown=confidentiality — beperkt toegang tot kernelinternals voor alle gebruikers, inclusief root

Compleet sysctl hardening-profiel

Goed, nu het volledige plaatje. Hieronder vind je een productieklaar configuratiebestand dat alle eerder besproken parameters combineert. Kopieer dit naar /etc/sysctl.d/90-security-hardening.conf en je hebt een solide basis.

# /etc/sysctl.d/90-security-hardening.conf
# Linux Kernel Security Hardening - April 2026
# Getest op Ubuntu 24.04 LTS en RHEL 9 / AlmaLinux 9

# === Netwerk: TCP Hardening ===
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_max_syn_backlog = 4096

# === Netwerk: Anti-spoofing ===
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# === Netwerk: ICMP Hardening ===
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1

# === Netwerk: Forwarding (uitschakelen tenzij router/container host) ===
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# === Kernel: Informatielekken voorkomen ===
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.perf_event_paranoid = 3

# === Kernel: eBPF Hardening ===
kernel.unprivileged_bpf_disabled = 1
net.core.bpf_jit_harden = 2

# === Kernel: Privilege Escalation Preventie ===
kernel.sysrq = 0
fs.suid_dumpable = 0

# === Geheugen: ASLR ===
kernel.randomize_va_space = 2
vm.mmap_rnd_bits = 32
vm.mmap_rnd_compat_bits = 16
vm.overcommit_memory = 0

# === Bestandssysteem: TOCTOU Bescherming ===
fs.protected_symlinks = 1
fs.protected_hardlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2

Activeer alle instellingen met:

sudo sysctl --system
# Controleer of de instellingen correct zijn toegepast
sysctl net.ipv4.tcp_syncookies kernel.dmesg_restrict kernel.randomize_va_space

Automatische audit met kernel-hardening-checker

Handmatig tientallen parameters controleren is foutgevoelig — en eerlijk gezegd, saai. De tool kernel-hardening-checker van Alexander Popov doet het voor je: die controleert in één keer je Kconfig-opties, boot-parameters én sysctl-instellingen.

Installatie en gebruik

# Installeren via pip
pip install kernel-hardening-checker

# Of klonen vanuit GitHub
git clone https://github.com/a13xp0p0v/kernel-hardening-checker.git
cd kernel-hardening-checker

# Automatische detectie en audit van de draaiende kernel
sudo ./bin/kernel-hardening-checker -a

# Alleen sysctl-parameters controleren
sudo sysctl -a > /tmp/sysctl-output.txt
./bin/kernel-hardening-checker -s /tmp/sysctl-output.txt

# JSON-uitvoer voor integratie met monitoring
sudo ./bin/kernel-hardening-checker -a -m json

De tool ondersteunt X86_64, X86_32, ARM64, ARM en RISC-V. Gebruik -m verbose voor gedetailleerde uitleg per parameter en -m show_fail om alleen falende checks te zien.

Integratie in CI/CD-pipelines

Je kunt kernel-hardening-checker ook integreren in je DevSecOps-pipeline. Zo valideer je automatisch de kernelconfiguratie bij elke deployment — geen handmatige checks meer nodig.

# Voorbeeld: GitLab CI stap voor kernel audit
kernel_security_audit:
  stage: security
  script:
    - pip install kernel-hardening-checker
    - ssh $TARGET_HOST "sudo sysctl -a" > sysctl-output.txt
    - kernel-hardening-checker -s sysctl-output.txt -m json > audit-report.json
    - |
      FAIL_COUNT=$(jq '[.[] | select(.result == "FAIL")] | length' audit-report.json)
      if [ "$FAIL_COUNT" -gt 5 ]; then
        echo "Te veel falende kernel security checks: $FAIL_COUNT"
        exit 1
      fi
  artifacts:
    paths:
      - audit-report.json

Automatisering met Ansible

Bij meer dan een handjevol servers wordt handmatige configuratie al snel onwerkbaar. Met Ansible's ansible.posix.sysctl module rol je kernelhardening consistent uit over je hele infrastructuur. In mijn ervaring is dit de aanpak die het beste schaalt.

# playbooks/kernel-hardening.yml
---
- name: Linux Kernel Security Hardening
  hosts: all
  become: true
  vars:
    security_sysctl_params:
      # Netwerk hardening
      net.ipv4.tcp_syncookies: 1
      net.ipv4.tcp_sack: 0
      net.ipv4.conf.all.rp_filter: 1
      net.ipv4.conf.default.rp_filter: 1
      net.ipv4.conf.all.accept_redirects: 0
      net.ipv4.conf.default.accept_redirects: 0
      net.ipv4.conf.all.send_redirects: 0
      net.ipv4.conf.default.send_redirects: 0
      net.ipv4.icmp_echo_ignore_broadcasts: 1
      net.ipv4.conf.all.log_martians: 1
      # Kernel hardening
      kernel.dmesg_restrict: 1
      kernel.kptr_restrict: 2
      kernel.unprivileged_bpf_disabled: 1
      net.core.bpf_jit_harden: 2
      kernel.sysrq: 0
      kernel.randomize_va_space: 2
      # Bestandssysteem
      fs.protected_symlinks: 1
      fs.protected_hardlinks: 1
      fs.protected_fifos: 2
      fs.protected_regular: 2

  tasks:
    - name: Beveiligingsparameters instellen via sysctl
      ansible.posix.sysctl:
        name: "{{ item.key }}"
        value: "{{ item.value }}"
        sysctl_file: /etc/sysctl.d/90-security-hardening.conf
        sysctl_set: true
        reload: true
      loop: "{{ security_sysctl_params | dict2items }}"

    - name: Kernel hardening audit uitvoeren
      ansible.builtin.command:
        cmd: kernel-hardening-checker -s /tmp/sysctl-audit.txt -m json
      register: audit_result
      changed_when: false

    - name: Auditresultaten opslaan
      ansible.builtin.copy:
        content: "{{ audit_result.stdout }}"
        dest: /var/log/kernel-hardening-audit.json
        mode: "0640"

Wil je het nog makkelijker? Kijk dan naar de community-role devsec.hardening.os_hardening van Ansible Galaxy. Die past standaard al uitgebreide sysctl-hardening toe volgens CIS Benchmark-richtlijnen.

CIS Benchmark-compliance en sysctl

De parameters in deze gids zijn afgestemd op de CIS Benchmarks voor Linux. Hier een overzicht van de belangrijkste mappings:

  • CIS 3.1–3.4 (Netwerkparameters) — alle netwerk sysctl-parameters in deze gids voldoen aan de CIS-vereisten voor IP forwarding, ICMP redirects, source routing en reverse path filtering
  • PCI DSS Requirement 2.2 — vereist dat systemen worden geconfigureerd volgens erkende hardening-standaarden; sysctl-hardening valt hier direct onder
  • NIST 800-53 SC-7 (Boundary Protection) — netwerk sysctl-parameters implementeren grensbescherming op kernelniveau
  • NIST 800-53 SI-16 (Memory Protection) — ASLR en geheugen-initialisatieparameters voldoen aan deze eis

Gebruik Lynis en OpenSCAP om je sysctl-configuratie automatisch te toetsen aan CIS-profielen.

Veelgestelde vragen

Wat is het verschil tussen sysctl en kernel boot-parameters?

Sysctl-parameters kun je tijdens runtime wijzigen via /proc/sys/ of het sysctl-commando, zonder herstart. Kernel boot-parameters stel je daarentegen in via GRUB en die kun je alleen wijzigen door de server opnieuw op te starten. Sommige beveiligingsinstellingen — zoals Kernel Page Table Isolation (pti=on) en kernel module signing (modules.sig_enforce=1) — zijn uitsluitend als boot-parameter beschikbaar.

Kan sysctl-hardening mijn applicaties breken?

Kort antwoord: ja, dat kan. De meest voorkomende problemen: net.ipv4.ip_forward=0 breekt Docker/Kubernetes-netwerking, kernel.unprivileged_userns_clone=0 kan browsers en sandbox-applicaties beïnvloeden, en net.ipv4.tcp_sack=0 kan de prestaties op verbindingen met veel pakketverlies verminderen. Test wijzigingen daarom altijd eerst in een staging-omgeving en pas parameters stapsgewijs toe. Serieus, sla die stap niet over.

Hoe vaak moet ik mijn sysctl-instellingen controleren?

Kernel hardening is een continu proces, geen eenmalige actie. Plan minimaal wekelijkse geautomatiseerde audits met tools als kernel-hardening-checker of Lynis. Controleer je instellingen ook na elke kernel-update, distributie-upgrade of wijziging in je serverfunctie (bijvoorbeeld wanneer een server containerhost wordt).

Werken deze parameters op alle Linux-distributies?

De meeste parameters in deze gids werken op alle gangbare distributies met kernel 5.x en hoger (inclusief de huidige 6.x LTS-reeks). Uitzonderingen zijn kernel.unprivileged_userns_clone (Debian/Ubuntu-specifiek) en bepaalde AppArmor/SELinux-gerelateerde parameters die distributieafhankelijk zijn. Controleer altijd met sysctl -a | grep parameternaam of een parameter beschikbaar is op jouw systeem.

Hoe verhoudt sysctl-hardening zich tot SELinux of AppArmor?

Ze vullen elkaar aan. Sysctl beperkt het gedrag van de kernel zelf — welke netwerkpakketten worden geaccepteerd, welke informatie zichtbaar is, hoe geheugen wordt beheerd. SELinux en AppArmor bepalen daarentegen wat individuele processen en applicaties mogen doen. Voor optimale beveiliging gebruik je beide: sysctl als eerste verdedigingslinie op kernelniveau, en SELinux/AppArmor als applicatie-niveau toegangscontrole. Het een vervangt het ander niet.

Over de Auteur Editorial Team

Our team of expert writers and editors.