Linux als server

Er zijn mensen die Linux vooral gebruiken als desktop. De Linux desktop is echter niet waar Linux zijn grote populariteit aan te danken heeft. Geen enkel ander platform dan Linux wordt zo veelvuldig ingezet als server. In deze nieuwe serie maak je kennis met de verschillende aspecten van de Linux server.

Als je dan besloten hebt om Linux in te willen zetten als server, is de volgende vraag welke Linux dat dan moet worden. Daar zouden we al een heel artikel aan kunnen besteden, maar dat heeft niet veel zin. Uiteindelijk maakt het namelijk niet zo heel veel uit welke Linux distributie gebruikt wordt. Of het nu Debian, SUSE of Fedora is, over het algemeen worden er toch dezelfde services op aangeboden. We zullen om die reden proberen de artikel in deze nieuwe serie zoveel mogelijk distributie-onafhankelijk te schrijven. In sommige gevallen is dat echter niet mogelijk, omdat verschillende distributies een heel andere oplossing bieden. Dat zullen we dan per geval oplossen.

Beveiliging van de server
Welke Linux distributie je ook gebruikt, je zult iets moeten doen aan beveiliging. Dat wordt dan ook het eerste punt van aandacht in deze serie. Doel van dit artikel is om een algemeen overzicht te geven van de verschillende beveiligingsopties. In volgende afleveringen zullen we dan deze specifieke opties meer in detail bekijken.

Beveiliging op Linux wordt toegepast op verschillende niveaus. Op elke server, die rechtstreeks bereikbaar is vanaf het internet, zouden in elk geval de volgende oplossingen voor moeten komen:
•    Gebruikersaccounts en permissies
•    Chroot
•    Firewalling
•    Beheer van services
•    Kernel level security

Gebruikersbeheer
Om taken uit te kunnen voeren op een Linux server, is een identiteit nodig. Dat geldt voor personen die taken op de server uit willen voeren, maar ook voor de services die op de server gebruikt worden. Voor dit doel wordt gebruikgemaakt van gebruikersaccounts en permissies.

Services worden over het algemeen tijdens de installatie al voorzien van een specifiek gebruikersaccount. Het is gelukkig al heel lang geleden dat services standaard gebruik maakten van het account van de gebruiker root om taken uit te voeren. Veel services hebben een eigen gebruikersaccount, dat ook geen toestemming heeft om in te loggen op de server. Daar hoef je als beheerder van een server eigenlijk niets meer aan te doen. Ook de permissies voor de betreffende server staan standaard eigenlijk altijd goed ingesteld.

Naast de manier waarop de services aanmelden op het systeem, moet je als beheerder ook rekening houden met de wijze waarop je jezelf aanmeldt op je server. Dat kan natuurlijk rechtstreeks als root, maar het is verstandiger een shell te openen, waarin je niet standaard aangemeld bent als root. Distributies als Ubuntu dwingen dat af door het alleen standaard mogelijk te maken om beheerstaken uit te voeren middels sudo, op andere distributies zul je daar zelf over na moeten denken en komt het aan op een goede discipline van de beheerder. Maak er in elk geval geen gewoonte van standaard te werken als root, want de kans op een klein foutje met hele grote gevolgen is dan veel te groot!

Chroot
Wanneer je verschillende services aanbiedt op je server, moet je er altijd rekening mee houden dat er wellicht een keer een inbraak plaats vindt op de server. Concreet betekent dit dat een indringer er in kan slagen om shell toegang te verkrijgen tot je server en vanuit die shell toegang kan krijgen tot het bestandssysteem op de server. Een standaardoplossing hiervoor is de server te draaien in een chroot omgeving. Dit is een elegante beveiligingsmethode waarmee je er voor zorgt dat de server maar een beperkt deel ziet van alle bestanden, die op je server aanwezig zijn.

Door een chroot omgeving in te richten, beperk je dat doorgaans tot alleen maar de omgeving waar de configuratiebestanden en relevante documenten van de server staan. Hiermee voorkom je dat indringers via de server toegang krijgen tot kritische delen van de serveromgeving, zoals bijvoorbeeld de home directories van gebruikers. De meeste servers die daarvoor in aanmerking komen, zullen standaard gebruik maken van een chroot omgeving, maar soms is dit een parameter, die je in een script aan of uit kunt zetten.

Beheer van services
Om het risico van onheil zoveel mogelijk te beperken, moet je er als beheerder voor zorgen dat alleen services aangeboden worden, die ook echt nodig zijn. Als je kijkt naar de standaard services die aangeboden worden op een typische Linux distributie, komen daar soms services in voor waarvan je je af zou kunnen vragen of je die wel echt nodig hebt. Wat denk je bijvoorbeeld van de CUPS printserver, die door heel veel Linux distributies gewoon standaard aan gezet wordt? In veel gevallen is dat nergens voor nodig. Neem dus in elk geval eens kritisch door wat er allemaal standaard gestart wordt en beperk dat zo veel mogelijk.

Naast het bekijken van wat er door systemd of via de runlevels automatisch gestart wordt, is het aan te raden om ook gebruik te maken van tools als netstat (lokaal) of nmap (remote). Gebruik de opdracht netstat -tulpen om te zien wat er lokaal allemaal wordt aangeboden, of gebruik vanaf een andere computer de opdracht nmap om uit te vinden welke poorten er allemaal open staan op je server. De nmap utility is een uitstekende tool om een volledig beeld te krijgen en kan er toe leiden dat je services te zien krijgt, die je eigenlijk helemaal niet zou moeten zien.

Firewalling
Naast dat je er voor moet zorgen dat er alleen maar services worden aangeboden die ook echt nodig zijn, is het sterk aan te raden om een firewall te draaien. De firewall dient zowel inkomend als uitgaand verkeer in de gaten te houden. Monitoring van inkomend verkeer gebeurt eigenlijk altijd wel goed, maar de distributies laten nog wel eens een steekje vallen als het gaat om monitoring van uitgaand verkeer en dat is jammer. Monitoring van inkomend verkeer is op veel servers nauwelijks nodig. Als je alleen maar die services draait, die ook toegankelijk moeten zijn, waarom zou je dan nog inkomend verkeer moeten monitoren?

Monitoring van uitgaand verkeer is echter een heel ander verhaal. Het komt voor dat indringers inbreken op bijvoorbeeld de webserver. Dat doen ze dan door een legitieme connectie te maken naar poort 80, waarna ze eenmaal binnengedrongen een shell kunnen openen. Vanuit die shell kunnen dan scripts gestart worden, die allerlei connecties opzetten naar verschillende hosts op het internet. Dat is jammer en eenvoudig te voorkomen door ook firewalling aan te zetten voor uitgaand verkeer.

Kernel level security
Het laatste onderdeel van een solide server beveiliging, is kernel level security. Dit zorgt ervoor dat op kernel niveau beoordeeld wordt of specifieke handelingen wel toegestaan zijn. Hiervoor wordt gebruik gemaakt van profielen, die exact definiëren wat een toepassing wel of niet mag doen. Door hier van tevoren specifiek over na te denken, voorkom je verrassingen achteraf.

Twee systemen zijn met name gangbaar als het gaat om kernel level security: AppArmor en SELinux. AppArmor is relatief eenvoudig te beheren en staat standaard aan op Ubuntu Linux en SUSE. SELinux is een stuk lastiger te beheren en vereist nogal wat kennis om een server in te richten. Om die reden wordt vooral SELinux nogal eens uitgezet. Dit is echter zeer onverstandig, omdat daarmee de kans op security incidenten aanmerkelijk groter wordt.

Dit artikel heeft als inleiding op het thema “Linux server” een overzicht gegeven van de meest belangrijke beveiligingsopties, die je eigenlijk altijd zou moeten toepassen als je een Linux server aanbiedt. In volgende delen uit deze serie zullen deze verschillende beveiligingsaspecten verder uitgediept worden.