SYSTEMS · 04 / 06
Server, die niemand mehr anfassen will, sind ein häufiges Ergebnis von jahrelangem Betrieb ohne Automatisierung. Wir planen, härten und automatisieren Linux-Infrastruktur so, dass jeder Host aus einer versionierten Beschreibung reproduzierbar ist. Härtung, Backup mit getestetem Restore und Monitoring gehören dabei zum Grundzustand, nicht zur Ausbaustufe.
Ausgangslage
Viele Linux-Umgebungen sind über Jahre per SSH gewachsen: Konfiguration wurde direkt auf dem Host geändert, ohne Notiz und ohne Versionsverwaltung. Wer das System aufgesetzt hat, ist längst nicht mehr im Haus. Ein Distributions-Upgrade wird verschoben, weil niemand weiß, welcher Dienst an welcher Datei hängt. Am Ende läuft ein Produktivsystem auf einem Release, für das es keine Sicherheitsupdates mehr gibt – und jede Änderung wird zum Risiko.
Backups existieren fast immer, belastbar sind sie selten. Ein Cronjob schreibt Datenbank-Dumps auf dieselbe Maschine oder denselben Storage, der im Schadensfall mit ausfällt. Niemand kennt den tatsächlichen Wiederherstellungspunkt, und ein vollständiger Restore wurde nie durchgeführt. Ob die Dumps konsistent sind, ob das Entschlüsselungspasswort noch bekannt ist und wie lange eine Wiederherstellung dauert, zeigt sich dann im Ernstfall.
Härtung wird als Einmalaktion bei der Installation behandelt. Der Passwort-Login über SSH bleibt aktiv, Datenbanken und Admin-Oberflächen hängen ohne Not am öffentlichen Interface, alle Dienste laufen unter demselben Konto, und Sicherheitsupdates werden manuell eingespielt – also unregelmäßig. Ein abgelaufenes Zertifikat oder eine vollgelaufene Partition fällt erst auf, wenn Nutzer anrufen.
Monitoring beschränkt sich häufig auf einen externen Ping-Check. Der sagt, dass die Maschine antwortet, aber nichts über Plattenfüllstand, Inode-Verbrauch, Speicherdruck, fehlgeschlagene systemd-Units, ausgebliebene Backup-Läufe oder Zertifikatslaufzeiten. Umgekehrt gibt es Umgebungen mit hunderten Alarmen pro Woche, die niemand mehr liest. Beides führt zum gleichen Ergebnis: Probleme werden entdeckt, wenn sie bereits Wirkung haben.
Vorgehen
Am Anfang steht eine Bestandsaufnahme, nicht ein Umbau. Wir erfassen Hosts, Paketstände, laufende Dienste, offene Sockets über ss -tulpen, Cronjobs und systemd-Timer, Firewallregeln, Zertifikate samt Laufzeit, Speicherplatz und die bestehenden Sicherungen. Das Ergebnis ist ein schriftliches Zustandsbild mit priorisierten Risiken. Erst danach entscheiden wir über Distribution, Zielarchitektur und die Reihenfolge der Eingriffe.
Konfiguration wird zu Code. Wir beschreiben Systeme in Ansible-Rollen, halten sie idempotent und prüfen Änderungen vorab mit ansible-playbook --check --diff gegen die laufende Umgebung. Geheimnisse liegen in ansible-vault oder einem externen Secret-Store, nie im Klartext im Repository. Ein Host lässt sich damit reproduzierbar neu aufsetzen, und jede Änderung ist im Git-Verlauf nachvollziehbar – mit Zeitpunkt, Autor und Begründung.
Die Härtung folgt einem festen Grundgerüst: SSH nur mit Schlüsseln, PermitRootLogin no, nftables mit Default-Deny und expliziten Freigaben, getrennte Systemnutzer pro Dienst, systemd-Units mit ProtectSystem=strict, PrivateTmp und eingeschränkten Capabilities. Sicherheitsupdates laufen über unattended-upgrades in einem definierten Wartungsfenster. Nach außen steht ein Reverse Proxy – nginx oder Caddy – mit ACME-Zertifikaten, automatischer Erneuerung, TLS 1.3 und HSTS.
Sicherungen planen wir vom Wiederherstellungsziel her: der akzeptable Datenverlust und die zulässige Ausfallzeit bestimmen Frequenz, Medium und Aufbewahrung. Wir arbeiten mit verschlüsselten, deduplizierenden Repositories, einer Kopie außerhalb des Standorts und append-only-Zugriff, damit ein kompromittierter Host seine eigenen Backups nicht löschen kann. Der Wiederherstellungstest ist Teil des Auftrags. Metriken sammelt Prometheus, Alarme laufen über Alertmanager, Dashboards liegen in Grafana.
Leistungsumfang
01
02
03
04
05
06
07
Einsatzfälle
Mehrere Hosts, keine Dokumentation, unklare Zuständigkeiten. Wir nehmen den Zustand auf, schließen die dringendsten Lücken und überführen die Konfiguration schrittweise in Ansible-Rollen.
Ein Release läuft aus dem Sicherheitssupport, etwa beim Wechsel auf Debian 13. Wir testen das Upgrade auf einer identisch beschriebenen Staging-Maschine, dokumentieren Abhängigkeiten und führen den Wechsel im Wartungsfenster durch – mit Rückweg.
Wenn Lizenzkosten, Datenschutzanforderungen oder Exportgrenzen dagegen sprechen: Aufbau der selbst betriebenen Variante, Datenmigration und ein Betriebskonzept, das ohne Spezialwissen auskommt.
Die Sicherungen laufen, aber niemand hat sie je zurückgespielt. Wir definieren die Wiederherstellungsziele, richten das Backup neu ein und führen einen vollständigen Restore auf frischer Hardware oder einer neuen VM durch.
Ergebnis
Ablauf
Fragen
In den meisten Fällen Debian stable oder Ubuntu LTS. Debian-Releases erhalten rund drei Jahre regulären Sicherheitssupport, danach folgt Debian LTS; eine Ubuntu-LTS-Version ist fünf Jahre abgedeckt und über Ubuntu Pro darüber hinaus. Entscheidend ist weniger die Distribution selbst als der Lebenszyklus: Er muss länger reichen als der Zeitraum, für den Sie planen.
Ja. Wir beginnen mit einer Bestandsaufnahme und stabilisieren zuerst das Nötigste: Zugriffswege, Sicherheitsupdates, Backup und Restore. Erst danach überführen wir die Konfiguration Dienst für Dienst nach Ansible. Ein kompletter Neuaufbau ist manchmal der kürzere Weg, aber nie der erste Vorschlag.
Die Kadenz wird gemeinsam mit den Wiederherstellungszielen festgelegt; ein Test je Quartal ist ein üblicher Richtwert, zusätzlich nach jeder Änderung an Sicherungsplan, Verschlüsselung oder Zielsystem. Getestet wird der vollständige Weg: Repository entsperren, Daten zurückspielen, Dienst starten, Konsistenz prüfen. Ergebnis ist eine gemessene Wiederherstellungszeit statt einer Annahme.
Wenn Datenhoheit, Vertragslage oder laufende Kosten dagegen sprechen, wenn der Dienst tief in eigene Systeme integriert ist oder wenn Sie den Datenexport ohnehin selbst betreiben müssten. Gegen Self-Hosting spricht fehlende Betriebskapazität: Ein selbst betriebener Dienst braucht Updates, Sicherungen und einen Ansprechpartner. Wir stellen beide Varianten mit Aufwand und Risiko gegenüber, statt die Frage grundsätzlich zu entscheiden.
Das Ansible-Repository, die Runbooks und die Zugangsstruktur gehören Ihnen und liegen in Ihrem Git. Wir setzen auf Werkzeuge, die frei verfügbar und weit verbreitet sind, und verzichten auf eigene Wrapper, die nur wir bedienen können. Nach der Übergabe kann Ihr Team oder ein Dritter ohne uns weiterarbeiten.
Verwandte Leistungen
05 / 06
DELIVERY
06 / 06
CONSULTING
03 / 06
ARCHITECTURE
Fachartikel dazu
Praxisleitfaden zur Basishärtung von Debian- und Ubuntu-Servern: SSH, nftables, unattended-upgrades, systemd-Sandboxing, sysctl, Logging und getestete Backups.
Abhängigkeiten sind heute die realistischste Angriffsfläche. Wie Lockfiles, SBOM, Signaturen und feste Patch-Fristen die Lieferkette absichern.
Was einen produktiven Container von einem Entwicklungscontainer unterscheidet: Multi-Stage-Builds, Digest-Pinning, PID 1, Secrets, Volumes und Ressourcenlimits.
Kontakt
Beschreiben Sie kurz Ihr System und die offene Frage. Wir antworten mit einer fachlichen Einschätzung – ohne Vertriebsschleife.