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 treibt still und leise die Webserver, Anwendungs-Backends, Datenbankhosts, Containerplattformen und Cloud-nativen Workloads an, auf die die Windows-Kunden angewiesen sind. Unabhängig davon, ob der MSP Linux verwalten möchte oder nicht – Linux ist in der Umgebung präsent.

Die MSPs, die dies richtig handhaben, behandeln Linux als vollwertigen Bestandteil ihrer Infrastruktur. Sie wenden bei beiden Betriebssystemen dieselbe Patching-Disziplin, denselben Überwachungsumfang, dieselben Sicherheitsmaßnahmen und dieselbe Backup-Strategie 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 „Stammeswissen“ verwaltet werden, manuell gepatcht werden, wenn gerade jemand daran denkt, mit irgendwelchen Bash-Skripten überwacht werden, die der letzte Techniker geschrieben hat, und mit einer Backup-Lösung gesichert werden, die der Anwendungsverantwortliche 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.

Verwalten Sie Linux-Endgeräte zusammen mit Windows über eine einzige Konsole.

Kaseya VSA 10 bietet automatisiertes Patch-Management, Überwachung und Fernverwaltung für Linux-Server und erweitert damit das Betriebsmodell, das bereits für Windows-Endgeräte gilt, auf Linux-Umgebungen.

Entdecken Sie Kaseya VSA 10

Was versteht man unter Linux-Serververwaltung?

Die Linux-Serververwaltung ist das Fachgebiet, das sich damit befasst, Linux-Server während ihrer gesamten Lebensdauer auf dem neuesten Stand zu halten, zu überwachen, zu sichern, zu sichern und in einem einwandfreien Betriebszustand zu halten. Sie umfasst physische und virtuelle Server, sowohl vor Ort als auch in der Cloud gehostete, 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 abgesichert werden. Die Abläufe sind jedoch anders, und genau hier geraten MSPs, die an reine Windows-Umgebungen gewöhnt sind, in Schwierigkeiten.

Inwiefern sich die Verwaltung von Linux-Servern von der unter Windows 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 Arbeitsablauf beim Patchen 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-gesteuert und werden über Gruppenrichtlinien verwaltet. Linux-Umgebungen basieren hingegen weitgehend 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 vorherige Betreiber hinterlassen hat, ohne dass er auf ein Äquivalent zu Gruppenrichtlinien zurückgreifen kann.

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

Patch-Management unter Linux

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 dabei die Arbeitsabläufe zur Erkennung, Planung, Genehmigung und Bereitstellung, die bei manuellen Paketaktualisierungen erforderlich sind.

Einige Bereiche, in denen Korrekturen vorgenommen wurden, verdienen besondere Beachtung.

Kernel-Updates erfordern einen Neustart und sollten in Wartungsfenstern zusammen mit Überprüfungen zum Neustart der Dienste 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 vom Typ „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 wurde 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 Basispakete, doch in Produktionsumgebungen kommen häufig von Anbietern bereitgestellte Repositorys oder Container-Images zum Einsatz, die separat nachverfolgt werden müssen.

Systemdienstprogramme mit bekannter Schwachstellenhistorie (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 Beobachtbarkeit

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. Ein volles Festplattenlaufwerk 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 unverzichtbar.

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 zwar als aktiv aufgeführt ist, aber nicht mehr auf Anfragen reagiert, ist für den Befehl „systemctl status“ unsichtbar; der Fehler muss daher extern überprüft werden, um ihn zu erkennen. 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 einen Sicherheitsverstoß.

Die Überwachung der Dateiintegrität erkennt unbefugte Änderungen an kritischen Systemdateien. Tools wie AIDE oder Tripwire legen den erwarteten Zustand von Systembinärdateien und Konfigurationsdateien als Referenz fest und geben eine Warnung 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 agentenbasierter Prüfungen. Zudem lassen sich benutzerdefinierte Skripte einsetzen, um anwendungsspezifische Zustandsindikatoren zu überwachen, die bei einer generischen Überwachung nicht erfasst werden.

Linux-Sicherheit und -Absicherung

Die Absicherung von Linux baut auf einer konsequenten Patch-Verwaltung auf. Neben der Aktualisierung der Pakete sind die Maßnahmen, die die Angriffsfläche erheblich 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, deren Berechtigungen über „sudo“ erweitert werden. Die meisten erfolgreichen Brute-Force-Angriffe auf Linux-Server sind darauf zurückzuführen, dass die Passwortauthentifizierung bei SSH aktiviert bleibt, häufig am Standardport 22.

Nicht benötigte Dienste und Ports sollten deaktiviert werden. Ein Webserver benötigt keinen laufenden 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 eines Angreifers auf den Host eingeschränkt.

Der Sudo-Zugriff sollte nach dem Prinzip der geringsten Berechtigungen erfolgen. Die pauschale Vergabe von Sudo-Rechten für die Gruppe „wheel“ an alle Administratoren ist zwar betrieblich 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 die herkömmlichen Dateiberechtigungen hinaus einschränken, was Prozesse tun dürfen. Die Konfiguration für benutzerdefinierte Anwendungen ist zwar nicht ganz einfach, doch bei Standarddiensten der Distribution erhöhen sie den Aufwand für einen erfolgreichen Angriff erheblich.

Kaseya SIEM erfasst Syslog-Ausgaben von Linux-Servern und korreliert Linux-Sicherheitsereignisse mit Endpunkt-, Netzwerk- und Cloud-Telemetriedaten aus über 60 Datenquellen. Authentifizierungsfehler, Ereignisse zur Ausweitung von Berechtigungen und ungewöhnliche Prozessausführungen auf Linux-Servern sind Signale, die verloren gehen, wenn die Protokolle der einzelnen Server isoliert auf dem jeweiligen Host gespeichert werden. Durch die plattformübergreifende Korrelation wird eine fehlgeschlagene SSH-Anmeldeserie, 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.

Datensicherung und Notfallwiederherstellung für Linux-Server

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

Datto BCDR bietet Backups auf Image-Ebene für Linux-VMs und Bare-Metal-Linux-Server – mit denselben Funktionen zur anwendungskonsistenten Erfassung und sofortigen Virtualisierung, die die Plattform auch für das Backup von Windows-VMs bereitstellt. Ein und dieselbe „ SIRIS “-Appliance kann sowohl geschützte Windows- als auch Linux-Umgebungen beherbergen, 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 entweder einen Kunden, dessen primäre Infrastruktur auf Windows basiert, dessen kundenorientierter Web-Stack jedoch unter Ubuntu läuft, oder einen Kunden aus der Fertigungsindustrie, dessen ERP-Backend auf RHEL läuft, oder einen Kunden aus der Softwareentwicklung, dessen gesamte Build-Infrastruktur aus Linux-Containern besteht.

Das Unterscheidungsmerkmal eines MSP ist nicht, ob er Linux überhaupt unterstützt, sondern ob er dabei dieselbe operative Sorgfalt an den Tag legt. Betrachten wir einmal ein typisches Problembild: 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. Eine neue 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 bereitstellen, Patches planen, Überwachungsschwellenwerte festlegen, Syslog-Daten in das SIEM einspeisen und die Hosts zum Backup-Zeitplan hinzufügen. Das Schwierige daran ist, zu erkennen, dass der halbverwaltete Linux-Server ein Risiko darstellt, das entweder ordnungsgemäß verwaltet oder ausdrücklich aus dem Umfang der Verwaltung ausgeschlossen werden muss – und nicht irgendwo dazwischen liegen darf.

Wie „ Kaseya Intelligence “ den Linux-Betrieb verändert

Kaseya Intelligence stützt sich auf mehr als drei Exabyte aggregierter und anonymisierter Daten sowie über 17 Millionen verwaltete Endpunkte und ermöglicht so autonomes Handeln auf der gesamten „ Kaseya 365 “-Plattform. Der Wandel besteht darin, dass nicht mehr nur Empfehlungen angezeigt werden, sondern Ergebnisse ohne manuelles Eingreifen umgesetzt 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 intelligenten Workflow-Validierung schließt diese Lücke. Die gleichen betrieblichen Effizienzvorteile, die die Patch-Verwaltung unter Windows auf Tausende von Endgeräten skalierbar machen, gelten nun auch für Linux. Erfahren Sie mehr unter Kaseya Intelligence.

Ein Linux-Server, der nach denselben Standards wie die daneben stehenden Windows-Server gepatcht, überwacht, abgesichert und gesichert wird, 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 ausgerechnet der Rechner, von dem sie nicht so recht wussten, derjenige war, über den der Angreifer eindringen konnte.

Die wichtigsten Erkenntnisse

• Das Patch-Management unter Linux erfolgt über distributionsspezifische Paketmanager (apt, dnf, yum, zypper). Kaseya VSA 10 automatisiert diesen Vorgang für alle gängigen Distributionen und integriert ihn in das Windows-Patch-Management.
• Die Authentifizierung per SSH-Schlüssel, eine minimale Offenlegung von Diensten, die Verwendung von „sudo“ nach dem Prinzip der geringsten Berechtigungen sowie SELinux oder AppArmor sind Maßnahmen zur Sicherheitshärtung, die die Angriffsfläche von Linux erheblich verringern.
• Durch die Syslog-Erfassung von Kaseya SIEM werden Linux-Sicherheitsereignisse zusammen mit Endpunkt-, Netzwerk- und Cloud-Daten in die Korrelationsschicht integriert, wodurch die durch eine isolierte Protokollverwaltung entstehenden blinden Flecken beseitigt werden.
• Für MSPs stellt der halbverwaltete Linux-Server ein Risiko dar. Entweder muss er denselben Betriebsstandards wie die Windows-Umgebung unterworfen werden oder ausdrücklich aus dem Leistungsumfang ausgeschlossen werden – ein Mittelweg ist zum Scheitern verurteilt.