Linux-serverbeheer: patches, 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 heterogeener: Linux zorgt stilletjes voor de kracht achter de webservers, applicatie-backends, databasehosts, containerplatforms en cloud-native workloads waarvan de Windows-klanten 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 patch-procedures, dezelfde monitoringdekking, dezelfde beveiligingsmaatregelen en hetzelfde back-upbeleid, 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 vorige technicus heeft geschreven, en waarvan de back-ups worden gemaakt met de oplossing die de applicatie-eigenaar jaren geleden heeft ingesteld.

In deze gids wordt uitgelegd 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.

Beheer Linux-endpointsen samen met Windows vanuit één console.

Kaseya VSA 10 biedt geautomatiseerd patchbeheer, monitoring en beheer op afstand voor Linux-servers, waarmee hetzelfde operationele model dat voor Windows-endpointsen geldt, wordt uitgebreid naar Linux-omgevingen.

Ontdek Kaseya VSA 10

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 operationele 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 betreft 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 GUI-gestuurd 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 eigenaar heeft achtergelaten, zonder dat er een equivalent van groepsbeleid is waarop men kan terugvallen.

De derde is de stilte van het falen. Een Windows-service die niet goed functioneert, wordt meestal zichtbaar via de Gebeurtenisviewer, de SCM of een duidelijk signaal in de gebruikersinterface. Een Linux-service die niet goed functioneert, schrijft naar een logbestand, wordt afgesloten met een statuscode anders dan nul en valt vervolgens stil. Als niemand die logbestanden leest, weet niemand dat de service is uitgevallen. Discipline op het gebied van monitoring is bij Linux belangrijker 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 vanuit veiligheidsoogpunt meest cruciale onderdeel van dit vakgebied. Kaseya VSA 10 ondersteunt patchbeheer voor alle belangrijke Linux-distributies en automatiseert de workflow voor detectie, planning, goedkeuring en implementatie die bij handmatige pakketupdates nodig is.

Er zijn een paar gebieden waar bij het patchen speciale aandacht aan moet worden besteed.

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 actieve kwetsbaarheden (sudo, polkit, glibc, systemd) zijn vaak het doelwit van exploits gericht op het uitbreiden van rechten. Ze worden binnen de normale onderhoudscycli gepatcht, 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 toegangspunt met beperkte rechten wordt omgezet in volledige root-toegang.

Linux-monitoring en -observeerbaarheid

De monitoring van Linux-servers omvat vier gebieden: systeembronnen, beschikbaarheid van diensten, logboekactiviteit en bestandsintegriteit.

Bij het monitoren van systeembronnen worden de CPU-belasting, de geheugenbelasting, het schijfgebruik (zowel opslagruimte als I/O), het gebruik van de swapruimte en de netwerkdoorvoer bijgehouden. Een volle schijf is de meest voorkomende oorzaak van storingen in Linux-services; logmappen of transactielogboeken van databases die het rootvolume vullen, kunnen zonder waarschuwing het hele systeem op de host platleggen. Het instellen van drempelwaarden voor waarschuwingen bij schijfgebruik is 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 het systeem is gehackt.

Bij het toezicht op de integriteit van bestanden worden ongeoorloofde wijzigingen in cruciale systeembestanden opgespoord. Tools zoals AIDE of Tripwire leggen de verwachte toestand van systeembinaries en configuratiebestanden vast en geven een waarschuwing wanneer deze onverwacht veranderen. Dit is een controlemaatregel die een goed opgezette 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 applicatiespecifieke gezondheidsindicatoren te monitoren die met generieke monitoring niet worden gedekt.

Beveiliging en beveiligingsversterking van Linux

Het versterken van de beveiliging van Linux bouwt voort op een strikte patch-strategie. Naast het up-to-date houden van pakketten zijn de werkwijzen die het aanvalsoppervlak aanzienlijk verkleinen algemeen bekend en het waard om als standaardbasis toe te passen.

SSH moet authenticatie op basis van sleutels vereisen, en geen wachtwoorden. PasswordAuthentication moet in sshd_config worden ingesteld op „no”, PermitRootLogin moet worden ingesteld op „no”, en het inloggen moet plaatsvinden via accounts zonder beheerdersrechten, waarbij de rechten via sudo worden uitgebreid. 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 build-agent heeft geen van beide nodig. Door het aantal luisterende diensten te beperken, worden de toegangswegen die een aanvaller naar de host heeft, 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 biedt onvoldoende beveiliging. Sudo-opdrachten per commando, die via auditd worden geregistreerd, bieden inzicht in welke bevoorrechte opdrachten daadwerkelijk zijn uitgevoerd en door wie.

SELinux of AppArmor moet worden ingeschakeld wanneer de distributie dit ondersteunt. Beide zijn systemen voor verplichte toegangscontrole die, naast de traditionele bestandsrechten, beperkingen opleggen aan wat processen mogen doen. Het configureren ervan voor aangepaste toepassingen is geen eenvoudige opgave, maar voor standaarddistributiediensten verhogen ze de drempel voor een succesvolle aanval aanzienlijk.

Kaseya SIEM verwerkt syslog-uitvoer van Linux-servers en koppelt Linux-beveiligingsgebeurtenissen aan telemetriegegevens over endpointsen, 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 kopie op een externe locatie of in de cloud 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 ook biedt voor back-ups van Windows-VM’s. Op één en dezelfde ‘ SIRIS ’-appliance kunnen zowel Windows- als Linux-omgevingen worden opgeslagen, 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 kunnen niet kiezen 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 probleem. Een klant uit de professionele dienstensector met 40 gebruikers heeft twee Linux-VM’s waarop hun openbare website en hun interne wiki draaien. De Windows-omgeving wordt volledig beheerd binnen 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 CVE voor de kernel, een werkstation wordt via een andere route gecompromitteerd en de aanvaller verspreidt zich lateraal naar de niet-gepatchte Linux-VM, die zo het persistentiepunt wordt. De Windows-kant hield stand. De Linux-kant, die de MSP niet echt beheerde, hield het niet vol.

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

Hoe ‘ Kaseya Intelligence ’ de werking van Linux verandert

Kaseya Intelligence maakt gebruik van meer dan drie exabyte aan geaggregeerde en geanonimiseerde gegevens en meer dan 17 miljoen beheerde endpointsen, 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 endpointsen, beginnen nu ook voor Linux te gelden. Ontdek Kaseya Intelligence.

Een Linux-server die volgens dezelfde normen wordt gepatcht, gemonitord, 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 hun omgeving gebruiken, zijn degenen waarvan de klanten niet worden verrast door een incident met Linux. De MSP's die dit niet doen, zijn degenen die achteraf aan een klant moeten uitleggen waarom juist die server, waar ze niet zo goed van op de hoogte waren, de aanvaller binnenliet.

Belangrijkste punten

• Voor patchbeheer onder Linux worden distributiespecifieke pakketbeheerders gebruikt (apt, dnf, yum, zypper). Kaseya VSA 10 automatiseert dit voor alle gangbare distributies, naast het patchbeheer voor Windows.
• Authenticatie op basis van SSH-sleutels, minimale blootstelling van diensten, sudo met zo min mogelijk rechten en SELinux of AppArmor zijn beveiligingsmaatregelen die het aanvalsoppervlak van Linux aanzienlijk verkleinen.
• De syslog-opname van Kaseya SIEM brengt Linux-beveiligingsgebeurtenissen samen met endpoint-, netwerk- en cloudgegevens in de correlatie-laag, waardoor de blinde vlek die ontstaat door geïsoleerd logboekbeheer wordt weggenomen.
• Voor MSP’s vormt de half-managed Linux-server een risico. Je moet hem ofwel onder dezelfde operationele norm brengen als het Windows-park, ofwel expliciet buiten beschouwing laten; de tussenpositie is gedoemd te mislukken.