Linux-Serververwaltung: Patches, Überwachung und Sicherheit für MSPs

Die meisten MSPs laufen unter Windows. Die meisten Kunden nutzen Windows. Doch die Serverinfrastruktur hinter diesen Kunden wird zunehmend heterogen: Linux sorgt still und leise für den Betrieb der Webserver, Anwendungs-Backends, Datenbankhosts, Containerplattformen und Cloud-nativen Workloads, auf die die Windows-Kunden angewiesen sind. Ob der MSP nun Linux verwalten möchte oder nicht – Linux ist in der Umgebung präsent.

Die MSPs, die dies richtig angehen, behandeln Linux als vollwertigen Bestandteil ihrer Infrastruktur. Sie wenden auf beide Betriebssysteme dieselben Patch-Richtlinien, denselben Überwachungsumfang, dieselben Sicherheitsmaßnahmen und dieselben Backup-Verfahren an – soweit möglich von derselben Konsole aus. Die MSPs, die dies nicht richtig umsetzen, haben am Ende Linux-Server, die auf der Grundlage von „Stammwissen“ verwaltet werden, manuell gepatcht werden, wenn jemand daran denkt, mit irgendwelchen Bash-Skripten überwacht werden, die der letzte Techniker geschrieben hat, und auf das gesichert werden, was der Anwendungsbesitzer vor Jahren eingerichtet hat.

Dieser Leitfaden behandelt, was die Verwaltung von Linux-Servern in der Praxis umfasst, inwiefern sich diese Verwaltungsmethode von der unter Windows unterscheidet und wie MSPs beide Betriebssysteme im Rahmen eines einheitlichen Betriebsmodells betreiben können.

Was ist Linux-Serververwaltung?

Die Linux-Serververwaltung ist die Disziplin, die dafür sorgt, dass Linux-Server während ihrer gesamten Lebensdauer auf dem neuesten Stand gehalten, überwacht, gesichert und in einem einwandfreien Betriebszustand gehalten werden. Sie umfasst physische und virtuelle Server, sowohl vor Ort als auch in der Cloud, Umgebungen mit einer einzigen Distribution sowie gemischte Umgebungen, in denen alles von Ubuntu Server über RHEL und Debian bis hin zu Amazon Linux läuft.

Der Umfang entspricht im Prinzip der Windows-Serververwaltung. Patches müssen installiert werden. Dienste müssen überwacht werden. Protokolle müssen überprüft werden. Backups müssen verifiziert werden. Konfigurationen müssen gesichert werden. Die technischen Abläufe unterscheiden sich jedoch, und genau hier geraten MSPs, die an reine Windows-Umgebungen gewöhnt sind, in Schwierigkeiten.

Inwiefern sich die Verwaltung von Linux-Servern von der von Windows-Servern unterscheidet

Drei Unterschiede sind dabei am wichtigsten.

Der erste Punkt ist die Paketverwaltung. Windows-Updates werden über Windows Update oder WSUS bereitgestellt, einen einzigen Update-Kanal für das Betriebssystem und Microsoft-Anwendungen. Linux-Distributionen verwenden Paketmanager (apt für Debian und Ubuntu, dnf oder yum für RHEL, CentOS und Fedora, zypper für SUSE), die Betriebssystem-Updates, Anwendungs-Updates und die Auflösung von Abhängigkeiten über ein einziges Tool abwickeln. Der Workflow für Patches ist unterschiedlich, die Paket-Repositorys sind unterschiedlich und die Folgen eines fehlgeschlagenen Updates sind unterschiedlich.

Der zweite Punkt ist die Kultur des Konfigurationsmanagements. Windows-Umgebungen sind stark GUI-basiert und werden über Gruppenrichtlinien verwaltet. Linux-Umgebungen basieren hingegen stark auf Konfigurationsdateien und werden häufig über Ansible, Puppet, Chef oder Shell-Skripte verwaltet. Ein MSP, der über keine dokumentierte Konfigurationsbasis für einen Linux-Server verfügt, übernimmt den Zustand, den der Vorbesitzer hinterlassen hat, ohne dass er auf ein Äquivalent zu Gruppenrichtlinien zurückgreifen kann.

Der dritte Punkt ist das Schweigen des Scheiterns. Ein fehlerhafter Windows-Dienst macht sich in der Regel über die Ereignisanzeige, das SCM oder ein eindeutiges Signal in der Benutzeroberfläche bemerkbar. Ein fehlerhafter Linux-Dienst schreibt in eine Protokolldatei, beendet sich mit einem Statuscode ungleich Null und verstummt. Wenn niemand diese Protokolle liest, bemerkt niemand, dass der Dienst ausgefallen ist. Die Überwachungsdisziplin ist unter Linux wichtiger als unter Windows, da das Betriebssystem selbst weniger unternimmt, um auf ein Problem hinzuweisen.

Linux-Patch-Management

Das Patch-Management unter Linux ist der häufigste und sicherheitskritischste Teil dieses Bereichs. Kaseya VSA 10 unterstützt das Patch-Management für alle gängigen Linux-Distributionen und automatisiert die Arbeitsabläufe für die Erkennung, Planung, Genehmigung und Bereitstellung, die bei manuellen Paketaktualisierungen erforderlich sind.

Einige Bereiche der Ausbesserungsarbeiten verdienen besondere Beachtung.

Kernel-Updates erfordern einen Neustart und sollten in Wartungsfenstern zusammen mit Überprüfungen des Dienstneustarts eingeplant werden. Optionen für Live-Kernel-Patches wie Canonical Livepatch oder kpatch können die Häufigkeit von Neustarts auf kritischen Hosts verringern, ersetzen jedoch geplante Neustarts nicht, sondern verschieben sie lediglich.

Aktualisierungen von OpenSSL und kryptografischen Bibliotheken wirken sich auf eine Vielzahl abhängiger Anwendungen aus. Eine Sicherheitslücke im Stil von „Heartbleed“ in OpenSSL betrifft jeden Dienst, der damit verknüpft ist, und wenn ein Patch ohne Neustart dieser Dienste installiert wird, bleibt die alte Bibliotheksversion im Speicher geladen. Patch-Management unter Linux bedeutet, nachzuverfolgen, was auf der Festplatte gepatcht ist und was tatsächlich ausgeführt wird.

Webserver, Datenbanken und andere Anwendungssoftware (Apache, Nginx, MySQL, PostgreSQL, Redis) laufen auf dem Betriebssystem, haben jedoch ihren eigenen Aktualisierungsrhythmus und ihre eigenen CVE-Feeds. Die Paketmanager der Distributionen kümmern sich um die Basis-Pakete, doch in Produktionsumgebungen kommen häufig von Anbietern bereitgestellte Repositorys oder Container-Images zum Einsatz, die separat nachverfolgt werden müssen.

Systemdienstprogramme mit bekannter Sicherheitslückenhistorie (sudo, polkit, glibc, systemd) sind häufig das Ziel von Exploits zur Rechteausweitung. Sie werden zwar im Rahmen der regulären Update-Zyklen gepatcht, sollten jedoch im Änderungsmanagement besonders hervorgehoben werden, da ein versäumtes Update für eine CVE in sudo dazu führen kann, dass aus einem Zugriff mit geringen Berechtigungen ein vollständiger Root-Zugriff wird.

Linux-Überwachung und Observability

Die Überwachung von Linux-Servern umfasst vier Bereiche: Systemressourcen, Verfügbarkeit von Diensten, Protokollaktivitäten und Dateiintegrität.

Die Überwachung der Systemressourcen erfasst die CPU-Auslastung, die Speicherauslastung, die Festplattenauslastung (sowohl Speicherplatz als auch E/A), die Auslastung des Auslagerungsspeichers und den Netzwerkdurchsatz. Eine volle Festplatte ist die häufigste Ursache für den Ausfall von Linux-Diensten; Protokollverzeichnisse oder Datenbank-Transaktionsprotokolle, die das Root-Volume füllen, können ohne Vorwarnung den gesamten Host lahmlegen. Die Einrichtung von Schwellenwertwarnungen für die Festplattenauslastung ist unabdingbar.

Die Überwachung der Dienstverfügbarkeit stellt sicher, dass die Prozesse, die der Server ausführen soll, tatsächlich laufen und auf Anfragen reagieren. Ein systemd-Dienst, der als aktiv aufgeführt ist, aber nicht mehr auf Anfragen reagiert, wird von `systemctl status` nicht erkannt; der Fehler muss daher extern überprüft werden. HTTP-, Datenbankverbindungs- und TCP-Port-Prüfungen bilden dabei die Grundlage.

Die Protokollüberwachung umfasst Systemprotokolle (journald, /var/log/syslog, /var/log/messages), Anwendungsprotokolle (Zugriffs- und Fehlerprotokolle des Webservers, Protokolle zu langsamen Datenbankabfragen) sowie Sicherheitsprotokolle (Authentifizierungsereignisse, Sudo-Aufrufe, SSH-Verbindungsversuche). Ungewöhnliche Muster in diesen Protokollen sind oft das erste Anzeichen für eine Kompromittierung.

Die Überwachung der Dateiintegrität erkennt unbefugte Änderungen an kritischen Systemdateien. Tools wie AIDE oder Tripwire erfassen den erwarteten Zustand von Systembinärdateien und Konfigurationsdateien und geben eine Warnmeldung aus, wenn sich diese unerwartet ändern. Dies ist eine Kontrollmaßnahme, die ausgereifte Linux-Betriebsumgebungen von Umgebungen mit minimaler Überwachung unterscheidet.

Kaseya VSA 10 ermöglicht die Überwachung von Linux-Systemen mittels SNMP-Abfragen und agentenbasierten Prüfungen. Darüber hinaus können benutzerdefinierte Skripte eingesetzt werden, um anwendungsspezifische Zustandsindikatoren zu überwachen, die bei einer generischen Überwachung nicht erfasst werden.

Linux-Sicherheit und -Absicherung

Die Absicherung von Linux-Systemen baut auf einer konsequenten Patch-Verwaltung auf. Neben der Aktualisierung der Pakete sind die Maßnahmen, die die Angriffsfläche deutlich verringern, allgemein bekannt und sollten als Standardgrundlage angewendet werden.

SSH sollte eine schlüsselbasierte Authentifizierung erfordern, keine Passwörter. „PasswordAuthentication“ sollte in der Datei „sshd_config“ auf „no“ gesetzt werden, „PermitRootLogin“ sollte auf „no“ gesetzt werden, und die Anmeldung sollte über nicht privilegierte Konten erfolgen, die über „sudo“ erweiterte Rechte erhalten. Die meisten erfolgreichen Brute-Force-Angriffe auf Linux-Server sind darauf zurückzuführen, dass die Passwortauthentifizierung bei SSH aktiviert bleibt, häufig auf dem Standardport 22.

Nicht benötigte Dienste und Ports sollten deaktiviert werden. Ein Webserver benötigt keinen Mail-Relay, ein Datenbankhost benötigt keinen Webserver und ein Build-Agent benötigt beides nicht. Durch die Verringerung der Anzahl der Dienste, die auf eingehende Verbindungen warten, werden die Angriffsmöglichkeiten für Angreifer auf den Host eingeschränkt.

Der Sudo-Zugriff sollte nach dem Prinzip der geringsten Berechtigungen erfolgen. Die pauschale Gewährung von Sudo-Rechten für die Gruppe „wheel“ an alle Administratoren ist zwar praktisch, aber sicherheitstechnisch bedenklich. Sudo-Einträge für einzelne Befehle, die über auditd protokolliert werden, bieten einen Überblick darüber, welche privilegierten Befehle tatsächlich ausgeführt wurden und von wem.

SELinux oder AppArmor sollten aktiviert werden, sofern die Distribution dies unterstützt. Bei beiden handelt es sich um Frameworks zur obligatorischen Zugriffskontrolle, die über herkömmliche Dateiberechtigungen hinaus einschränken, was Prozesse tun dürfen. Ihre Konfiguration für benutzerdefinierte Anwendungen ist nicht trivial, doch für Standarddienste der Distribution erhöhen sie den Aufwand für einen erfolgreichen Angriff erheblich.

Kaseya SIEM erfasst Syslog-Daten von Linux-Servern und korreliert Linux-Sicherheitsereignisse mit Endpunkt-, Netzwerk- und Cloud-Telemetriedaten aus über 60 Datenquellen. Authentifizierungsfehler, Ereignisse zur Rechteausweitung und ungewöhnliche Prozessausführungen auf Linux-Servern sind Signale, die verloren gehen, wenn die Protokolle der einzelnen Server isoliert auf dem Host verbleiben. Durch die oberflächenübergreifende Korrelation wird eine fehlgeschlagene SSH-Anfrage, gefolgt von einer erfolgreichen Anmeldung und einer ausgehenden Verbindung zu einem ungewöhnlichen Ziel, als eine einzige Angriffskette dargestellt und nicht als drei voneinander unabhängige Ereignisse.

Sicherung und Notfallwiederherstellung für Linux-Server

Linux-Server benötigen dieselben Wiederherstellungsmaßnahmen wie Windows-Server. Dazu gehören Backups auf Image-Ebene, anwendungskonsistente Erfassung, regelmäßige Wiederherstellungstests sowie eine externe oder in die Cloud replizierte Kopie für die Notfallwiederherstellung.

Datto BCDR bietet Image-Backups für Linux-VMs und Bare-Metal-Linux-Server und verfügt dabei über dieselben Funktionen zur anwendungskonsistenten Erfassung und sofortigen Virtualisierung, die die Plattform auch für das Backup von Windows-VMs bereitstellt. Auf derselben SIRIS können sowohl Windows- als auch Linux-Umgebungen gesichert werden, was die Wiederherstellungsvorgänge in Umgebungen mit gemischten Betriebssystemen vereinfacht.

Entdecken Sie Datto BCDR für die Sicherung von Linux-Servern.

Linux-Serververwaltung für MSPs: Verwaltung gemischter Umgebungen

Die meisten MSPs haben nicht die Wahl zwischen Windows und Linux. Sie haben es entweder mit einem Kunden zu tun, dessen primäre Infrastruktur auf Windows basiert, dessen kundenorientierter Web-Stack jedoch auf Ubuntu läuft, oder mit einem Kunden aus der Fertigungsindustrie, dessen ERP-Backend auf RHEL läuft, oder mit einem Kunden aus der Softwareentwicklung, dessen gesamte Build-Infrastruktur aus Linux-Containern besteht.

Was einen MSP wirklich auszeichnet, ist nicht, ob er Linux überhaupt unterstützt, sondern ob er dabei dieselbe operative Sorgfalt an den Tag legt. Betrachten wir einmal ein typisches Problem. Ein Kunde aus dem Bereich Professional Services mit 40 Benutzern verfügt über zwei Linux-VMs, auf denen sein öffentlicher Webauftritt und sein internes Wiki gehostet werden. Die Windows-Seite wird im Rahmen des Standarddienstes des MSP vollständig verwaltet. Die Linux-Seite ist zwar „abgedeckt“, wird aber nur manuell gepatcht, wenn gerade jemand daran denkt, und es gibt keine Überwachung außer Ping-Prüfungen. Ein Kernel-CVE wird veröffentlicht, eine Workstation wird über einen anderen Weg kompromittiert, und der Angreifer bewegt sich lateral zur ungepatchten Linux-VM, die zum Persistenzpunkt wird. Die Windows-Seite hielt stand. Die Linux-Seite, die der MSP nicht wirklich verwaltete, tat dies nicht.

Der technische Aufwand, um Linux auf denselben Standard zu bringen, ist nicht groß. Man muss den VSA-Agenten installieren, Patches planen, Überwachungsschwellenwerte festlegen, Syslog-Daten in das SIEM einspeisen und die Hosts in den Backup-Zeitplan aufnehmen. Das Schwierige daran ist, zu erkennen, dass ein halbverwalteter Linux-Server ein Risiko darstellt, das entweder ordnungsgemäß verwaltet oder ausdrücklich aus dem Umfang der Verwaltung herausgenommen werden muss – und nicht irgendwo dazwischen liegen darf.

Wie Kaseya Intelligence den Linux-Betrieb Kaseya Intelligence

Kaseya Intelligence stützt sich auf mehr als drei Exabyte aggregierter und anonymisierter Daten sowie über 17 Millionen verwaltete Endpunkte und ermöglicht so autonome Aktionen auf der gesamten Kaseya 365 . Der Wandel besteht darin, dass nicht mehr nur Empfehlungen ausgesprochen werden, sondern Ergebnisse ohne manuelles Eingreifen ausgeführt und validiert werden.

In Linux-Serverumgebungen spielt dies vor allem bei der Patch-Verwaltung eine Rolle, wo manuelle Planung und Überprüfungen nach der Installation dazu geführt haben, dass Linux im Vergleich zu Windows bisher unverhältnismäßig zeitaufwendig war. Die automatisierte Patch-Bereitstellung über Kaseya VSA 10 in Verbindung mit einer intelligenzgesteuerten Workflow-Validierung schließt diese Lücke. Die gleichen betrieblichen Effizienzvorteile, die die Windows-Patch-Verwaltung auf Tausende von Endgeräten skalierbar machen, gelten nun auch für Linux. Entdecken Sie Kaseya Intelligence.

Ein Linux-Server, der nach denselben Standards gepatcht, überwacht, abgesichert und gesichert wird wie die Windows-Server nebenan, ist kein exotisches Technikprojekt. Es handelt sich um dieselbe Verwaltungsdisziplin, die auf einen anderen Paketmanager angewendet wird. Die MSPs, die dies verinnerlichen und Linux als vollwertigen Bestandteil ihrer Infrastruktur betreiben, sind diejenigen, deren Kunden nicht von einem Linux-bezogenen Vorfall überrascht werden. Die MSPs, die dies nicht tun, sind diejenigen, die einem Kunden im Nachhinein erklären müssen, warum gerade der Rechner, von dem sie nicht so recht wussten, den Angreifer hereingelassen hat.