Tips voor de expert: Linux beveiligen

Voorzie tot slot je bios (efi) van een wachtwoord en zet de Linux-machine achter slot en grendel. Met deze maatregelen heb je het vrijwel onmogelijk gemaakt om ongeoorloofd het root-wachtwoord te resetten.

Om software te kunnen installeren, moet je met root-permissies software packages installeren. Er zijn echter maar weinig mensen die packages eerst goed inspecteren om te kijken of ze niet toevallig kwaadaardige code (zoals rootkits) bevatten. En misschien ben je zelf ook weleens tevergeefs via apt, zypper, dnf of yum op zoek geweest naar een driver of programma. Gelukkig kwam je ergens op internet een package tegen met een veelbelovende beschrijving. Het probleem met packages van internet is echter dat je geen idee hebt wát je precies installeert.

belangrijk dat je zeker bent van je zaak. Daar is een vrij eenvoudige oplossing voor: gebruik alleen de repository’s die door je distributie beschikbaar worden gesteld. De kans dat er dan iets misgaat, is bijzonder klein. Het risico neemt dan ook toe wanneer je verder zoekt dan de software die door jouw Linux-distributie beschikbaar wordt gesteld.

Dat geldt al voor ogenschijnlijk betrouwbare externe partijen, maar al helemaal voor packages die je zelf op internet gevonden hebt. Mocht je toch software van internet downloaden en installeren, dan is het verstandig om te analyseren wat je precies gaat doen. Als het om rpm-packages gaat, gebruik dan de opdracht

vóórdat je die installeert.

Wellicht het grootste probleem van Linux zijn onbetrouwbare of gewoon slecht geschreven scripts. Heel veel toepassingen en met name webservers maken in ruime mate gebruik van scripts. Deze scripts kunnen bijvoorbeeld zijn inbegrepen in webpagina’s en kunnen ervoor zorgen dat taken geautomatiseerd worden uitgevoerd bij de selectie van een specifieke functie.

Dat probleem hebben we eens live mogen aanschouwen op een server waarop meerdere Apache virtual hosts draaiden voor een aantal websites die door verschillende mensen werden onderhouden. Het gevolg was een wildgroei aan php-, python- en perl-scripts, waarvan één exemplaar de optie had om vanuit het script een shell te openen.

In dit specifieke geval bleef de schade nog enigszins beperkt omdat de betreffende Apache-server gebruikmaakte van een specifiek account dat voor deze service was aangemaakt. In dit account was het echter wel mogelijk om een shell te openen, met als gevolg dat een hacker vanuit het script talloze andere scripts had weggeschreven in de directory /var/tmp/. Deze scripts waren gezamenlijk bezig een ddos-aanval uit te voeren op een aantal vooraanstaande websites.

Uiteraard had het nooit mogen gebeuren om met het httpd-account een shell te openen. Dit probleem is eenvoudig te voorkomen door in plaats van /bin/bash een programma als /sbin/nologin of /bin/false als shell te specificeren (en gelukkig doet ook bijna elke moderne Linux-distributie dat voor service-accounts). Het ontnemen van een login-shell voor service-accounts biedt echter geen alomvattende oplossing voor eventuele securityproblemen. Een systeem voor Mandatory Access Control zoals SELinux doet dat wel.

Op een systeem waar SELinux of AppArmor actief is, worden alleen handelingen toegestaan waarvoor specifiek een regel in de policy is aangemaakt. Dat betekent dat een Apache-proces bijvoorbeeld bestanden in de Apache DocumentRoot kan lezen of scripts kan uitvoeren vanuit de standaard directory voor scripts. Een handeling die echter niet specifiek is toegestaan, zal worden tegengehouden. Een voorbeeld daarvan is een script dat bestanden wil aanmaken in /var/tmp/- en deze vervolgens wil uitvoeren. Helaas zijn er nog steeds veel beheerders die SELinux direct uitzetten omdat ze er niet goed mee overweg kunnen.

Een volgende populaire kandidaat voor een succesvolle hack op Linux is ssh. Secure Shell is een handige service die het beheerders mogelijk maakt om van afstand in te loggen op Linux. Tegelijkertijd activeer je met ssh echter een service die het voor iederéén mogelijk maakt in te loggen. Zeker als sshd op de standaardpoort 22 draait en je systeem rechtstreeks aan het internet verbonden is.

Uit meerdere tests blijkt dat een dergelijk systeem binnen een kwartier gevonden is en de eerste ssh-brute-force-attack te verduren krijgt. In een ssh-brute-force-attack probeert de aanvaller toegang te krijgen door geautomatiseerd voor de hand liggende gebruikersnamen en vaak gebruikte wachtwoorden uit te proberen om in te breken. Als de aanvaller dit maar lang genoeg volhoudt, zal dat uiteindelijk ook wel een keer lukken.

De mogelijkheid om toegang te krijgen via ssh is echter vrij eenvoudig tegen te houden door de ssh-service zelf te voorzien van een aantal niet-standaard parameters. Om te beginnen is het aan te raden om geen ssh-services aan te bieden op de standaardpoort 22; geautomatiseerde scripts scannen doorgaans namelijk alleen op die poort.

Vervolgens is het een goed idee om gebruik te maken van de optie AllowUsers, waarmee je aangeeft welke gebruikers via ssh in mogen loggen en álle andere gebruikers de toegang ontzegt. Daarnaast kun je overwegen ssh-logins door middel van wachtwoorden uit te zetten en alleen toegang te verlenen aan gebruikers die gebruikmaken van een ssh-public/private-keypaar. Met deze maatregelen zorg je ervoor dat ssh nagenoeg onneembaar wordt.

Tot slot is er nog een categorie in Linux (en elk ander besturingssysteem) die aandacht behoeft: de zero-day-exploit. Dat zijn kwetsbaarheden in software die nog niet (algemeen) bekend zijn en dus nog moeten worden ontdekt. Zodoende is het extreem lastig je daartegen te wapenen. Toch zijn er maatregelen die je kunt treffen.

Om te beginnen, is het noodzakelijk om regelmatig patches en updates te installeren. Wellicht is de onbekende exploit voor jouw distributie allang gevonden en staat de oplossing gewoon klaar in de vorm van een patch. De dagen van ‘If it ain’t broke, don’t fix it’ liggen ver achter ons en elk modern computersysteem dat aan internet verbonden is behoort met regelmaat te worden voorzien van de allerlaatste patches.

Wil je echt boven op de feiten zitten en op de hoogte blijven van nieuwe problemen, nog vóórdat er patches voor zijn uitgebracht? Dan loont het de moeite om deze site in de gaten te houden. Hier worden namelijk alle beveiligingsproblemen gepubliceerd op het moment dat ze bekend zijn. Dit stelt je in staat om meteen maatregelen te nemen als de problemen op jouw omgeving van toepassing zijn.

Daarnaast kun je onbekende problemen in zekere mate tegenhouden door gebruik te maken van Mandatory Access Control, waarmee je handelingen die een toepassing niet hoort te doen een halt toeroept, en dat beperkt het risico dat zero-day-exploits schade aanrichten aanzienlijk.

Zoals elk besturingssysteem heeft Linux een aantal zwakke plekken. Daarnaast biedt Linux echter alles wat nodig is om je systeem tegen die zwakke plekken te beschermen. Als je de risico’s dat jouw Linux-systeem wordt gehackt tot een minimum wilt beperken, volstaat het om een paar maatregelen te nemen. Om te beginnen zou elk Linux-systeem gebruik moeten maken van SELinux of AppArmor. Daarmee voorkom je dat toepassingen ongewenste handelingen uitvoeren – denk daarbij aan het script op de webserver dat een shell wil openen, maar ook aan onbekende gevaren (zero-day-exploits).

Daarnaast helpt een consequente updatestrategie natuurlijk ook. Als je niet regelmatig zelf wilt bekijken welke nieuwe exploits zijn gepubliceerd, zorg er dan in elk geval voor dat onbekende problemen voorkomen kunnen worden door updates te installeren.

Een derde maatregel die behoorlijk efficiënt is, is sshd-services aanbieden op een niet-standaard poort, zodat dictionary-attacks weinig kans maken. Combineer dat met de AllowUsers-parameter in sshd_config en zorg ervoor dat inloggen op afstand alleen is toegestaan door één account met een ongebruikelijke naam.

Tot slot: als het mogelijk is de server fysiek te beveiligen door hem in een afgesloten ruimte te zetten, bemoeilijk je daarmee ook alle pogingen om het root-wachtwoord ongeoorloofd te veranderen, met als resultaat een Linux-systeem dat bijna niet te hacken is.