How do they do it? Linux server hardening

Security is anno 2019 niet meer weg te denken uit de IT. Dit is terecht omdat helaas maar al te veel personen, bedrijven en overheden onophoudelijk bezig zijn met digitale boevenpraktijken. Om ongewenst bezoek, verstoring van systemen of diefstal van gegevens (zoveel mogelijk) te voorkomen zijn behoorlijk wat beveiligingsmaatregelen te nemen. Server hardening is een proces om een aantal van deze beveiligingsmaatregelen te implementeren.

Hoewel dit proces best eenvoudig is kan de uitvoering in de praktijk zeer complex zijn. Je weet immers niet altijd exact wat een server wel of niet doet en welke instellingen dus ideaal zijn. Gelukkig is een aantal hulpmiddelen beschikbaar dat je op weg kan helpen met de implementatie.

Een goed begin…

Om van start te gaan met server hardening heb je een kader nodig. Hiervoor zijn diverse internationaal gebruikte standaarden beschikbaar. OpenSCAP (Open Security Content Automation Protocol, https://www.open-scap.org) is een toolset die van deze standaarden gebruik maakt. Grofweg bestaat de functionaliteit uit het beoordelen, meten en instellen van een vooraf gedefinieerd beveiligingsniveau. Deze definities zijn beschikbaar voor de meeste Linux-smaken en -versies. OpenSCAP kan bijvoorbeeld hardening implementeren met behulp van een “ruleset” (een set van hardening rules) die helemaal is aangepast voor RHEL7.

Het gebruik van tooling lijkt gemakkelijk (“alles is toch geautomatiseerd?”). In de praktijk hangt zo’n systeem echter aan een netwerk en bovendien vereist een interne organisatie vaak dat bepaalde security issues niet kunnen worden opgelost. Denk daarbij bijvoorbeeld aan eisen van een specifieke applicatie waardoor een firewall anders moet worden ingericht en specifieke instellingen van applicatie-accounts die vereisen dat van de standaard-beveiligingsnormen wordt afgeweken.

Binnen OpenSCAP wordt gewerkt met een lijst van regels ofwel rules (de eerder vermelde “ruleset”). Iedere geïmplementeerde rule maakt het Operating System een stukje veiliger. (Daar gaan we althans van uit.) Iedere rule is zeer goed beschreven. Zie het volgende voorbeeld (uit een SCAP compliancy report).

Eigen ervaringen tot nu toe

In de praktijk is het niet haalbaar (lees: gevaarlijk voor de continuïteit van de operationele processen) om alles ineens door te voeren. Iedere rule is echter voorzien van een label en het is vrij simpel om de hele ruleset vast te leggen in bijvoorbeeld een Excel-sheet. Met behulp van dit sheet maak je gewoon een stappenplan. Per rule kun je hierbij de impact op de eigen organisatie vastleggen (low, medium en high). Alle “low impact” items behoren dan bij fase 1 enzovoorts. Bovendien is het extra veilig (indien het mogelijk is) om dit toe te passen via een DTAP procedure (via Development, Test en Acceptatie naar Productie).

In de praktijk blijkt overigens dat men erg huiverig is voor de standaard firewall en SELinux. Beiden kunnen een hoge impact hebben op het correct functioneren van systemen. Het zijn echter wel juist de “services” die veel kunnen bijdragen aan goed beveiligde systemen en dat is dan ook de reden dat hier ALTIJD extra de nadruk op moet worden gelegd tijdens een implementatietraject.

OpenSCAP bestaat uit minimaal 3 packages (openscap, openscap-scanner en scap-security-guide) en is meestal onderdeel van de standaard repositories van de meest gangbare Linux distributies. Na installatie kan een CSV-bestand (de checklist) worden gegenereerd met daarin vermeld de security-items inclusief bijbehorend “severity level”. Op basis van dit bestand (na eventuele import in LibreOffice Calc of Excel) kan worden bepaald (onder meer via een eventuele impact op de organisatie) wat de vervolgstappen zijn (de fasering). Implementatie (remediation) kan vervolgens gebeuren via shell-scripts of via Ansible playbooks. De benodigde code hiervoor kan grotendeels met behulp van OpenSCAP worden gegenereerd!!!! Wij geven de voorkeur aan Ansible omdat dit een uitermate geschikt tool is om ook na een implementatie de gehele omgeving “in het gareel” te houden. Uiteraard is dit geen vereiste.

Wanneer gebruik wordt gemaakt van Satellite kunnen de vanuit oscap gegenereerde “compliancy reports” (default in HTML-formaat) naar een Satellite server worden verzonden waardoor in 1 overzicht de beveiligingsstatus van alle servers kan worden getoond. Ook kunnen de reports per server tot in detail worden bekeken.

OpenSCAP is (uiteraard) nog steeds in ontwikkeling en dat betekent dat (nu nog) niet voor ieder item een remediation-script of -playbook beschikbaar is. Het gevolg hiervan kan zijn dat wordt besloten om code uit te breiden (al dan niet met behulp van externe resources).

Na implementatie kun je, zeker bij gebruik van Ansible, bijna achterover leunen. Nieuwere versies van de standaard moet je uiteraard in de gaten houden maar verder kun je bewijzen dat de systemen aan de gestelde standaard voldoen (en dat is dan weer heel handig voor compliancy reports!!).

Omdat zeer waarschijnlijk niet alle punten op de checklist van toepassing zijn, is het in veel gevallen zinvol om de checklist te vergelijken met je eigen security baseline. Op basis hiervan kunnen vervolgens prioriteiten worden gesteld. Hierbij wordt zowel naar de operationele impact gekeken als naar de complexiteit van de implementatie. Als eerste deel van de implementatie zijn vaak de “low impact” items aan de beurt. Deze zijn dus makkelijk uit te voeren omdat ze geen of weinig invloed hebben op het functioneren van systemen.

Afhankelijk van de urgentie kunnen uiteraard ook onderdelen met een groter operationeel risico of hogere complexiteit als eerste worden opgepakt.

Tot slot

Wat optimaal beveiligd is, is lang niet altijd werkbaar. Het kan dan ook lastig zijn om sommige van de optimalisaties te implementeren. Dat kan onder andere komen door afhankelijkheden met andere systemen/applicaties of de manier waarop toegang en beheer op de server zijn ingericht. Je zult in de praktijk dan ook merken dat je vlot van start kunt. Met wat moeite kom je ook nog wel op 80%. In de praktijk blijkt dat gemiddeld aardig wat moeite moet worden genomen om (een deel) van die laatste 20% in te vullen. Denk hierbij aan de reeds bovenvermelde lokale firewall en SELinux.

Is het dan nog wel de moeite waard? Jazeker! Allereerst is iedere verbetering die wordt doorgevoerd er een. Daarnaast kun je, door überhaupt aan hardening te beginnen, zorgen voor een volgende stap in de volwassenheid van serverbeheer en configuratiemanagement. Hierdoor is de kans groot dat de organisatie zich meer bewust wordt van risico’s en de manier waarop gewerkt wordt. Bovendien komen door het periodiek uitvoeren van de remediation code en genereren van de compliancy reports afwijkingen sneller dan voorheen naar voren en worden risico’s door bijvoorbeeld fouten bij de server-uitrol teruggedrongen. Dat geeft niet alleen winst in het heden, maar reduceert ook de risico’s in de toekomst.

Meer weten?

info@atcomputing.nl

https://static.open-scap.org/openscap-1.2/oscap_user_manual.html

https://www.open-scap.org/tools/scap-workbench/

https://iase.disa.mil/stigs/scap/Pages/index.aspx

Onderwerpen
Actieve filters: Wis alle filters
Loading...