Een pas geïnstalleerd Linux-systeem is niet automatisch veilig. Gangbare distributies worden geleverd met configuraties die zijn ontworpen om snel te werken, niet om een inbraakpoging te weerstaan. De beveiliging van uw Linux-systeem dagelijks versterken, komt neer op een paar gerichte handelingen die u regelmatig herhaalt. Zo verkleint u het aanvalsoppervlak zonder van uw computer een onbruikbare vesting te maken.
systemd-sandboxing: elke Linux-service afzonderlijk afschermen
De meeste handleidingen over Linux-beveiliging gaan over gebruikersaccounts en bestandsrechten. Minder aandacht is er voor het afschermen van de services zelf. Een webserver of databasebeheerder draait vaak met veel ruimere rechten dan nodig.
Is het u weleens opgevallen dat een gecompromitteerde service bestanden kan lezen die niets met zijn functie te maken hebben? Precies dat voorkomt systemd-sandboxing. Drie directives maken een groot verschil:
- ProtectSystem=strict koppelt het rootbestandssysteem voor de betreffende service alleen-lezen aan, zodat er niets kan worden gewijzigd buiten de expliciet toegestane mappen.
- PrivateTmp=true geeft de service een geïsoleerde tijdelijke map die onzichtbaar is voor andere processen. Een aanvaller die toegang krijgt tot de /tmp-map van de service, ziet niet die van het systeem.
- NoNewPrivileges=true voorkomt dat de service na het opstarten meer rechten krijgt, zelfs als er een setuid-binary in het uitvoeringspad staat.
U stelt deze opties in het unitbestand van de service in, onder de sectie [Service]. Start de service na elke wijziging opnieuw op en controleer vervolgens of alles naar behoren werkt. Een te restrictieve directive kan legitieme toegang tot een socket of configuratiebestand blokkeren.
Wilt u meer weten over deze aanpak en andere methoden om uw systeem te beveiligen? De beveiligingstips van Hebdo Linux beschrijven verschillende scenario’s voor zowel werkstations als servers.
Controleer de werkelijke status van SELinux en AppArmor op uw systeem
Dat SELinux of AppArmor is geïnstalleerd, betekent niet dat deze mechanismen ook daadwerkelijk iets beveiligen. Waarom wordt dit punt zo vaak over het hoofd gezien? Omdat de aanwezigheid van een beveiligingsmodule in de kernel een vals gevoel van veiligheid geeft.
Een inactieve beveiligingsmodule beschermt geen enkel proces. Op een distributie als Ubuntu is AppArmor standaard aanwezig, maar niet alle profielen staan in de modus “enforce”. Sommige draaien in de modus “complain”: ze registreren overtredingen alleen in het logboek, zonder ze te blokkeren.
Concrete controleopdrachten
Voor AppArmor toont de opdracht aa-status een lijst met geladen profielen en hun modus. Elk profiel in de modus “complain” vormt een open deur. Voor SELinux geeft sestatus aan of de modus “enforcing”, “permissive” of “disabled” is.
Deze statussen controleren hoort bij nuttige dagelijkse controles. Een script dat via cron of een systemd-timer wordt gestart, kan een waarschuwing versturen als de modus na een herstart of kernelupdate op permissive staat. Dit soort ongemerkte terugval komt vaak voor bij versie-upgrades.
Linux-patches: controleer of de update daadwerkelijk actief is
Een patch installeren is niet voldoende. Na een kernelupdate kan uw computer nog steeds op de oude kernel draaien zolang deze niet opnieuw is opgestart. De pakketbeheerder geeft aan dat alles “up-to-date” is, maar het systeem blijft kwetsbaar.
Controleer na elke kritieke update welke kernel actief is. De opdracht uname -r toont de versie van de kernel die momenteel draait. Vergelijk deze met de nieuwste geïnstalleerde versie, die u in uw pakketbeheerder kunt vinden. Verschillen de versies, dan moet u het systeem opnieuw opstarten.
Patchbeheer op een productieserver
Op een server is opnieuw opstarten niet altijd meteen mogelijk. Leg het verschil tussen de geïnstalleerde en de actieve kernel vast. Sommige distributies bieden een mechanisme voor “live patching”, waarmee kernelpatches zonder herstart worden toegepast. Dit mechanisme dekt echter niet alle soorten kwetsbaarheden.
Een punt dat vaak wordt vergeten: alternatieve opstartopties. Als uw bootloader oude kernels bewaart, kan een onbedoelde herstart met een verouderde optie de verholpen kwetsbaarheden opnieuw introduceren. Verwijder oude kernels regelmatig uit de opstartlijst nadat u hebt bevestigd dat de nieuwe stabiel is.
Verklein dagelijks het blootgestelde netwerkoppervlak
Elke open poort is een mogelijk toegangspunt. Op een Linux-werkstation kunnen services zoals CUPS (afdrukken), Avahi (netwerkdetectie) of een SSH-server luisteren zonder dat u het merkt.
De opdracht ss -tlnp toont alle luisterende poorten en het bijbehorende proces. Loop deze lijst na:
- Een service die u niet gebruikt (bijvoorbeeld Avahi op een computer zonder netwerkprinter) schakelt u uit met
systemctl disable --now, gevolgd door de naam van de service. - Voor een SSH-server die op de standaardpoort (22) bereikbaar is, is authenticatie met een publieke sleutel veiliger dan met een wachtwoord. Schakel wachtwoordauthenticatie uit in
/etc/ssh/sshd_configmetPasswordAuthentication no. - De nftables-firewall (of iptables, afhankelijk van uw distributie) moet standaard inkomend verkeer weigeren, met expliciete uitzonderingen voor alleen de benodigde services.
Minder luisterende services betekent een kleiner aanvalsoppervlak om in de gaten te houden. Deze controle kost maar een paar minuten en verkleint het risico op aanvallen op afstand aanzienlijk.
Een Linux-systeem beveiligen is geen eenmalige klus. Services afschermen, controleren of beveiligingsmodules actief zijn, nagaan of patches daadwerkelijk draaien en onnodige poorten sluiten: samen vormen deze stappen een korte cyclus. Herhaalt u die elke week, dan dekt deze cyclus de meeste gangbare aanvalsvectoren op een Linux-werkstation of -server af.
