Linux-serverbeheer: patching, monitoring en beveiliging voor MSP’s

De meeste MSP’s draaien op Windows. De meeste klanten werken met Windows. Maar het serverpark achter die klanten wordt steeds heterogener: Linux zorgt stilletjes voor de kracht achter de webservers, applicatie-backends, databasehosts, containerplatforms en cloud-native workloads waar de Windows-klanten van afhankelijk zijn. Of de MSP nu Linux wil beheren of niet, Linux is aanwezig in de omgeving.

De MSP’s die dit goed aanpakken, beschouwen Linux als een volwaardig onderdeel van hun beheersomgeving. Ze hanteren voor beide besturingssystemen dezelfde patchprocedures, dezelfde monitoring, dezelfde beveiligingsmaatregelen en dezelfde back-upstrategie, waar mogelijk vanaf dezelfde console. De MSP's die dit niet goed aanpakken, eindigen met Linux-servers die worden beheerd op basis van tribale kennis, handmatig worden gepatcht wanneer iemand eraan denkt, worden gemonitord door willekeurige bash-scripts die de laatste engineer heeft geschreven, en waarvan de back-up wordt gemaakt naar wat de applicatie-eigenaar jaren geleden heeft ingesteld.

In deze gids wordt besproken wat het beheer van Linux-servers in de praktijk inhoudt, waarin het beheer verschilt van dat van Windows, en hoe MSP’s beide besturingssystemen vanuit één uniform operationeel model kunnen beheren.

Wat is Linux-serverbeheer?

Linux-serverbeheer is het vakgebied dat zich bezighoudt met het up-to-date houden, monitoren, beveiligen, back-uppen en in goede staat houden van Linux-servers gedurende hun gehele levensduur. Het omvat zowel fysieke als virtuele servers, zowel op locatie als in de cloud, omgevingen met één distributie en gemengde omgevingen waarin alles draait, van Ubuntu Server tot RHEL, Debian en Amazon Linux.

De werkwijze komt in principe overeen met het beheer van Windows-servers. Er moeten patches worden geïnstalleerd. Services moeten worden bewaakt. Logbestanden moeten worden gecontroleerd. Back-ups moeten worden geverifieerd. Configuraties moeten worden beveiligd. De praktische uitvoering is echter anders, en dat is waar MSP’s die gewend zijn aan omgevingen met uitsluitend Windows in de problemen komen.

Waarin het beheer van Linux-servers verschilt van dat van Windows

Er zijn drie verschillen die het belangrijkst zijn.

Het eerste punt is pakketbeheer. Windows-updates worden geleverd via Windows Update of WSUS, één enkel updatekanaal voor het besturingssysteem en Microsoft-toepassingen. Linux-distributies maken gebruik van pakketbeheerders (apt voor Debian en Ubuntu, dnf of yum voor RHEL, CentOS en Fedora, zypper voor SUSE) die updates van het besturingssysteem, updates van toepassingen en het oplossen van afhankelijkheden vanuit één tool afhandelen. De workflow voor het installeren van patches is anders, de pakketrepositories zijn anders en de gevolgen van een mislukte update zijn anders.

Het tweede punt betreft de cultuur rond configuratiebeheer. Windows-omgevingen zijn sterk gebaseerd op grafische gebruikersinterfaces en worden beheerd via groepsbeleid. Linux-omgevingen zijn sterk gebaseerd op configuratiebestanden en worden vaak beheerd via Ansible, Puppet, Chef of shellscripts. Een MSP die geen gedocumenteerde configuratiebaseline voor een Linux-server heeft, neemt de toestand over die de vorige beheerder heeft achtergelaten, zonder dat er een equivalent van groepsbeleid is om op terug te vallen.

De derde is de stilte van het falen. Een Windows-service die niet goed functioneert, wordt meestal gesignaleerd via de Gebeurtenisviewer, de SCM of een duidelijk signaal in de gebruikersinterface. Een Linux-service die niet goed functioneert, schrijft naar een logbestand, sluit af met een statuscode die niet nul is, en wordt vervolgens stil. Als niemand die logbestanden leest, weet niemand dat de service is uitgevallen. Het is bij Linux nog belangrijker om de monitoring strikt te handhaven dan bij Windows, omdat het besturingssysteem zelf minder doet om een probleem te signaleren.

Patchbeheer voor Linux

Patchbeheer voor Linux is het meest voorkomende en meest beveiligingskritische onderdeel van dit vakgebied. Kaseya VSA 10 ondersteunt patchbeheer voor alle gangbare Linux-distributies en automatiseert de workflow voor detectie, planning, goedkeuring en implementatie die bij handmatige pakketupdates nodig is.

Er zijn een paar punten die extra aandacht verdienen.

Kernelupdates vereisen een herstart en moeten worden ingepland tijdens onderhoudsvensters, in combinatie met controles op het opnieuw opstarten van services. Opties voor het live patchen van de kernel, zoals Canonical Livepatch of kpatch, kunnen de frequentie van herstarts op kritieke hosts verminderen, maar ze vervangen geplande herstarts niet; ze stellen deze alleen uit.

Updates van OpenSSL en cryptografische bibliotheken hebben gevolgen voor een groot aantal afhankelijke toepassingen. Een kwetsbaarheid in OpenSSL van het type Heartbleed treft elke dienst die ermee is gekoppeld, en als een patch wordt geïnstalleerd zonder die diensten opnieuw op te starten, blijft de oude versie van de bibliotheek in het geheugen staan. Patchbeheer onder Linux houdt in dat je bijhoudt wat er op de schijf is gepatcht en wat er daadwerkelijk draait.

Webservers, databases en andere applicatiesoftware (Apache, Nginx, MySQL, PostgreSQL, Redis) draaien bovenop het besturingssysteem, maar hebben hun eigen updatecyclus en hun eigen CVE-feeds. De pakketbeheerders van de distributie zorgen voor de basispakketten, maar in productieomgevingen wordt vaak gebruikgemaakt van door leveranciers aangeboden repositories of containerimages die apart moeten worden bijgehouden.

Systeemhulpprogramma’s met een geschiedenis van kwetsbaarheden (zoals sudo, polkit, glibc en systemd) zijn vaak het doelwit van aanvallen die gericht zijn op het uitbreiden van rechten. Ze worden weliswaar volgens de normale patching-cycli bijgewerkt, maar het is de moeite waard om ze in het wijzigingsbeheer apart te vermelden, omdat een gemiste update voor een CVE in sudo ervoor kan zorgen dat een aanvaller met beperkte rechten volledige root-toegang krijgt.

Linux-monitoring en -observatie

Het monitoren van Linux-servers omvat vier aspecten: systeembronnen, beschikbaarheid van diensten, logboekactiviteit en bestandsintegriteit.

De monitoring van systeembronnen houdt de CPU-belasting, het geheugengebruik, het schijfgebruik (zowel opslagruimte als I/O), het gebruik van de swapruimte en de netwerkdoorvoer bij. Een volle schijf is de meest voorkomende oorzaak van storingen in Linux-services; logbestanden of transactielogboeken van databases die het root-volume vullen, kunnen zonder waarschuwing het hele systeem op de host platleggen. Waarschuwingen bij het overschrijden van drempelwaarden voor schijfgebruik zijn absoluut noodzakelijk.

Door de beschikbaarheid van services te controleren, wordt vastgesteld of de processen die de server zou moeten uitvoeren, daadwerkelijk actief zijn en reageren. Een systemd-service die als actief wordt weergegeven maar niet meer op verzoeken reageert, is onzichtbaar voor `systemctl status`; er moet extern worden gecontroleerd om de storing op te sporen. Controles van HTTP, databaseverbindingen en TCP-poorten vormen de basis.

Logboekmonitoring omvat systeemlogboeken (journald, /var/log/syslog, /var/log/messages), applicatielogboeken (toegangs- en foutenlogboeken van webservers, logboeken met trage databasequery’s) en beveiligingslogboeken (authenticatiegebeurtenissen, sudo-opdrachten, SSH-verbindingspogingen). Afwijkende patronen in deze logboeken zijn vaak het eerste teken dat er sprake is van een inbreuk.

Controle op de integriteit van bestanden spoort ongeoorloofde wijzigingen in cruciale systeembestanden op. Tools zoals AIDE of Tripwire leggen de verwachte toestand van systeembestanden en configuratiebestanden vast en geven een waarschuwing wanneer deze onverwacht veranderen. Dit is een controlemaatregel die een volwassen Linux-omgeving onderscheidt van omgevingen met minimale monitoring.

Kaseya VSA 10 biedt ondersteuning voor Linux-monitoring via SNMP-polling en agentgebaseerde controles, waarbij aangepaste scripts kunnen worden ingezet om toepassingsspecifieke gezondheidsindicatoren te monitoren die met generieke monitoring niet worden gedekt.

Beveiliging en beveiligingsversterking van Linux

Het versterken van de Linux-beveiliging bouwt voort op een strikte patching-routine. Naast het up-to-date houden van pakketten zijn er beproefde methoden die het aanvalsoppervlak aanzienlijk verkleinen; deze zijn algemeen bekend en verdienen het om als standaardbasis te worden toegepast.

SSH moet authenticatie op basis van sleutels vereisen, en geen wachtwoorden. In sshd_config moet PasswordAuthentication worden ingesteld op no, PermitRootLogin op no, en moet het inloggen plaatsvinden via accounts zonder beheerdersrechten die via sudo bevoegdheden kunnen uitbreiden. De meeste succesvolle brute-force-aanvallen op Linux-servers zijn het gevolg van het feit dat wachtwoordauthenticatie bij SSH is ingeschakeld, vaak op de standaardpoort 22.

Overbodige diensten en poorten moeten worden uitgeschakeld. Een webserver heeft geen mailrelay nodig, een databasehost heeft geen webserver nodig en een buildagent heeft geen van beide nodig. Door het aantal luisterende diensten te beperken, worden de toegangswegen voor een aanvaller naar de host verminderd.

Bij sudo-toegang moet het principe van minimale rechten worden gehanteerd. Het verlenen van algemene sudo-rechten aan de wheel-groep aan alle beheerders is weliswaar praktisch, maar onveilig. Door per commando sudo-toegang te verlenen en dit via auditd te registreren, wordt inzicht verkregen in welke bevoorrechte commando’s daadwerkelijk zijn uitgevoerd en door wie.

SELinux of AppArmor moet worden ingeschakeld als de distributie dit ondersteunt. Beide zijn systemen voor verplichte toegangscontrole die, naast de traditionele bestandsrechten, beperkingen opleggen aan wat processen mogen doen. De configuratie ervan is voor aangepaste applicaties geen sinecure, maar voor standaarddistributies verhogen ze de drempel voor een succesvolle aanval aanzienlijk.

Kaseya SIEM verwerkt syslog-uitvoer van Linux-servers en koppelt Linux-beveiligingsgebeurtenissen aan telemetriegegevens over eindpunten, netwerken en de cloud uit meer dan 60 gegevensbronnen. Mislukte authenticaties, gebeurtenissen waarbij rechten worden uitgebreid en ongebruikelijke procesuitvoering op Linux-servers zijn signalen die verloren gaan wanneer de logbestanden van elke server geïsoleerd op de host staan. Met cross-surface-correlatie wordt een mislukte SSH-burst, gevolgd door een succesvolle aanmelding en vervolgens een uitgaande verbinding naar een ongebruikelijke bestemming, weergegeven als één enkele aanvalsketen, in plaats van drie losstaande gebeurtenissen.

Back-up en noodherstel voor Linux-servers

Linux-servers vereisen dezelfde herstelmaatregelen als Windows-servers. Back-ups op image-niveau, applicatieconsistente back-ups, regelmatige hersteltests en een externe of in de cloud gerepliceerde kopie voor noodherstel.

Datto BCDR biedt back-ups op image-niveau voor Linux-VM’s en bare-metal Linux-servers, met dezelfde applicatieconsistente vastlegging en mogelijkheden voor onmiddellijke virtualisatie die het platform biedt voor back-ups van Windows-VM’s. Eén en hetzelfde SIRIS kan zowel Windows- als Linux-omgevingen ondersteunen, wat het herstelproces in omgevingen met gemengde besturingssystemen vereenvoudigt.

Ontdek Datto BCDR voor back-ups van Linux-servers.

Linux-serverbeheer voor MSP’s: het beheren van gemengde omgevingen

De meeste MSP’s hebben niet de keuze tussen Windows en Linux. Ze krijgen te maken met een klant waarvan de primaire infrastructuur op Windows draait, maar waarvan de klantgerichte webstack op Ubuntu draait, of met een klant in de productiesector waarvan de ERP-backend op RHEL draait, of met een klant in de softwareontwikkeling waarvan de volledige build-infrastructuur uit Linux-containers bestaat.

Wat een MSP echt onderscheidt, is niet of ze Linux überhaupt ondersteunen, maar of ze daar dezelfde operationele nauwgezetheid aan de dag leggen. Laten we eens kijken naar een veelvoorkomend scenario. Een klant in de professionele dienstverlening met 40 gebruikers heeft twee Linux-VM’s waarop hun openbare website en hun interne wiki draaien. De Windows-omgeving wordt volledig beheerd via de standaarddienst van de MSP. De Linux-kant wordt weliswaar 'gedekt', maar er worden alleen handmatig patches geïnstalleerd wanneer iemand eraan denkt, zonder enige monitoring behalve ping-controles. Er verschijnt een kernel-CVE, een werkstation wordt via een ongerelateerde route gecompromitteerd en de aanvaller verplaatst zich lateraal naar de niet-gepatchte Linux-VM, die het persistentiepunt wordt. De Windows-kant hield stand. De Linux-kant, die de MSP niet echt beheerde, niet.

De technische werkzaamheden om Linux op hetzelfde niveau te brengen, zijn niet zo omvangrijk. Installeer de VSA-agent, plan het patchen in, stel bewakingsdrempels in, voer syslog-gegevens in het SIEM-systeem in en voeg de hosts toe aan het back-upschema. Het lastige is te beseffen dat de half-beheerde Linux-server een risico vormt dat ofwel goed moet worden beheerd, ofwel expliciet buiten het bereik moet worden gehouden – en niet ergens daar tussenin.

Hoe Kaseya Intelligence het beheer van Linux-systemen Kaseya Intelligence

Kaseya Intelligence maakt gebruik van meer dan drie exabyte aan geaggregeerde en geanonimiseerde gegevens en meer dan 17 miljoen beheerde eindpunten, waardoor autonome acties op het Kaseya 365 mogelijk worden. De verschuiving ligt in het niet langer alleen maar presenteren van aanbevelingen, maar het uitvoeren en valideren van resultaten zonder handmatige tussenkomst.

Voor Linux-serveromgevingen is dit vooral van belang bij het patchen, waar handmatige planning en controle na het patchen er in het verleden toe hebben geleid dat Linux onevenredig veel tijd kostte in vergelijking met Windows. Geautomatiseerde patchimplementatie via Kaseya VSA 10, in combinatie met op Intelligence gebaseerde workflowvalidatie, dicht die kloof. Dezelfde operationele voordelen die ervoor zorgen dat het patchen van Windows schaalbaar is voor duizenden eindpunten, beginnen nu ook voor Linux te gelden. Ontdek Kaseya Intelligence.

Een Linux-server die volgens dezelfde normen wordt gepatcht, bewaakt, beveiligd en waarvan back-ups worden gemaakt als de Windows-servers ernaast, is geen exotisch technisch project. Het is dezelfde beheersdiscipline toegepast op een andere pakketbeheerder. De MSP's die dit begrijpen en Linux als een volwaardig onderdeel van het park draaien, zijn degenen waarvan de klanten niet worden verrast door een incident met Linux. De MSP's die dat niet doen, zijn degenen die achteraf aan een klant moeten uitleggen waarom de machine waar ze niet helemaal van op de hoogte waren, degene was die de aanvaller binnenliet.