De Linux-kernel corrigeert nu meer dan 1.500 CVE per grote versie, en de projecties voor Linux 7.3 naderen de 2.000 CVE per release. Deze inflatie, aangedreven door AI-ondersteunde code-analysetools, verandert de spelregels voor systeembeheerders radicaal. Het beschermen van een Linux-systeem is niet langer alleen het inschakelen van een firewall en het uitvoeren van een wekelijkse apt upgrade: het is een werk van sorteren, prioriteren en voortdurende defensieve architectuur.
Prioritering van CVE van de Linux-kernel: omgaan met de stroom van patches
Tussen de versies 6.9 en 6.19 van de kernel lag het tempo rond de 500 gecorrigeerde CVE per release. Sinds Linux 7.0 is dit volume verdubbeld en vervolgens verdrievoudigd. De onderhouders zelf geven aan “compleet overweldigd” te zijn door de stroom van rapporten die via geautomatiseerde tools worden gegenereerd.
Voor een beheerder betekent dit dat het systematisch patchen van elke CVE onrealistisch is geworden zonder prioriteringstools. Het blind toepassen van alle patches betekent dat de diensten continu opnieuw moeten worden opgestart, met een risico op functionele regressie bij productiebelastingen.
Een ruwe CVSS-score van 7.5 voor een netwerk kwetsbaarheid heeft niet dezelfde impact op een server die is geïsoleerd achter een privé-netwerk als op een machine die is blootgesteld in een DMZ. Een contextuele CVSS-score benadering maakt het mogelijk om de werkelijk kritieke patches te prioriteren.
Tools zoals KernelCare (live patching zonder herstart) of de OVAL-stromen die door de distributies worden geleverd, filteren de toepasbare CVE voor uw werkelijke configuratie. De middelen die aan de beveiliging op Hebdo Linux zijn besteed, complementeren deze technische monitoring nuttig.
SSH-configuratie en controle van geprivilegieerde toegang onder Linux
SSH blijft de meest gerichte aanvalsvector op blootgestelde Linux-servers. De standaardconfiguratie van OpenSSH op de meeste distributies is functioneel, maar niet veilig.
sshd_config-instellingen die prioriteit hebben voor vergrendeling
- PermitRootLogin no en deactivering van wachtwoordauthenticatie (PasswordAuthentication no): alleen Ed25519- of ECDSA-sleutelauthenticatie zou op een productie-server moeten worden toegestaan
- Beperk de versleutelingsalgoritmen tot moderne suites via KexAlgorithms en Ciphers, waarbij expliciet diffie-hellman-group1-sha1 en CBC worden uitgesloten
- Activeer AllowUsers of AllowGroups om de SSH-toegang te beperken tot een nominatieve lijst van accounts, in plaats van alleen op de firewall te vertrouwen
- MaxAuthTries ingesteld op 3 en LoginGraceTime verlaagd tot 30 seconden om het venster voor brute-force-aanvallen te beperken
Beheer van privilege-escalatie met sudo
De sudoers-configuratie verdient net zoveel aandacht als SSH. Een te permissieve sudoers-bestand annuleert elk beleid van minimale privileges. We zien nog steeds regelmatig configuraties waarin een applicatie-account beschikt over ALL=(ALL) NOPASSWD: ALL, wat neerkomt op het verlenen van permanente root-toegang.
De beste praktijk is om gerichte command-aliases (Cmnd_Alias) te creëren voor elke applicatierol, en elke sudo-aanroep te loggen via syslog. In combinatie met auditd biedt dit een volledige traceerbaarheid van geprivilegieerde acties.
Vermindering van het netwerk-aanvalsoppervlak op een Linux-server
Elke open poort en elke actieve service vertegenwoordigt een potentieel toegangspunt. De vermindering van het aanvalsoppervlak begint met een rigoureuze inventarisatie.
De opdracht ss -tulnp (die netstat vervangt) toont de sockets die luisteren met het bijbehorende proces. Op een typische webserver zouden alleen de poorten 22, 80 en 443 zichtbaar moeten zijn. Elke extra service (postfix, cups, avahi-daemon, rpcbind) moet worden uitgeschakeld via systemctl disable als deze niet vereist is, en vervolgens worden gemaskeerd met systemctl mask om een onopzettelijke heractivatie te voorkomen.
Voor netwerkfiltering heeft nftables iptables vervangen als het standaardframework op recente kernels. De declaratieve syntaxis via sets en maps vereenvoudigt het beheer van regels op grote schaal. Een standaardbeleid dat drop is op de input- en forward-ketens, met expliciete opening van noodzakelijke stromen, blijft de basis.
Audit en logging: auditd, journald en Linux-inbraakdetectie
Zonder gecentraliseerde logging blijft elke compromittering onzichtbaar totdat de schade is vastgesteld. Het audit-framework van de Linux-kernel (auditd) maakt het mogelijk om kritieke systeemaanroepen met een fijne granulariteit te monitoren.
De regels die prioriteit hebben voor configuratie betreffen de monitoring van wijzigingen op /etc/passwd, /etc/shadow, /etc/sudoers en de SSH-configuratiebestanden. Een auditctl-regel van het type -w /etc/shadow -p wa -k shadow_changes logt elke schrijf- of attribuutwijziging op het bestand.
Voor inbraakdetectie op bestandsniveau genereert AIDE (Advanced Intrusion Detection Environment) een cryptografische handtekening van de systeemstructuur. Elke ongeoorloofde wijziging van een binaire of configuratiebestand genereert een waarschuwing bij de volgende scan. Een dagelijkse scan via cron met rapportverzending via een versleuteld kanaal vormt een minimum levensvatbaar.
Journald, in combinatie met een externe aggregatie (via systemd-journal-remote of een verzamelaar zoals rsyslog naar een SIEM), maakt het mogelijk om gebeurtenissen tussen meerdere servers te correleren. Een aanvaller die een machine compromitteert, zal proberen de lokale logs te wissen. Het verzenden van logs naar een derde server maakt deze wissen ineffectief.
Cyber Resilience Act en naleving van Linux-systemen in Europa
De Cyber Resilience Act (CRA) verplicht softwareleveranciers, inclusief diegene die open source-componenten integreren, om verplichtingen te volgen met betrekking tot kwetsbaarheden en het bieden van patches gedurende de levensduur van het product. De eerste rapportageverplichtingen gaan in september 2026 in.
Voor teams die Linux in een professionele omgeving implementeren, betekent de CRA concreet dat de traceerbaarheid van componenten (SBOM, Software Bill of Materials) en de mogelijkheid om een patchbeheerproces aan te tonen, wettelijke vereisten worden, niet alleen best practices. De belangrijkste distributies zijn begonnen met het leveren van bruikbare SBOM, maar de verantwoordelijkheid voor naleving blijft bij de entiteit die het product op de Europese markt brengt.
De combinatie van een kernel die bijna 2.000 CVE per release genereert en een regelgevend kader dat een gedocumenteerd beheer van elke kwetsbaarheid vereist, maakt live patching-tools en automatisering van prioritering niet langer optioneel, maar structureel noodzakelijk voor elke Linux-infrastructuur in productie.
