Ein Linux-Server für Dateien, Mail-Gateway oder eine Branchenanwendung steht oft jahrelang, weil er selten stört. Genau deshalb bleiben SSH aus dem Internet, ein Root-Passwort aus dem Installationsjahr und eine Verwaltungsseite auf dem öffentlichen Port liegen. Härten im Alltag bedeutet, diese Wege zu schließen, ohne die Anwendung zu zerlegen. Zuerst sichern, dann einschränken, dann prüfen, ob der Dienst noch tut, was der Betrieb braucht.

Was an einem „läuft ja“-Server offen bleibt

Typisch ist ein Server, der hinter der Firewall „aus Versehen“ weitergereicht wird, weil ein Techniker einmal von zu Hause zugreifen wollte. Dazu kommt ein Benutzerkonto mit dem Namen der Firma und einem Passwort, das auch am WLAN hängt. Updates wurden bei der Inbetriebnahme gemacht und danach ausgesetzt, weil ein automatisches Update einmal einen Dienst neu gestartet hat. Wer jetzt nur die Anwendung ansieht, hält den Server für ruhig. Von außen ist er ein offenes Tor mit einem vertrauten Namen.

Härten ist kein Wettbewerb um möglichst viele Werkzeuge. Für einen einzelnen Server in einem KMU zählen wenige Punkte: SSH nur mit Schlüssel und nur aus dem Büro- oder VPN-Netz, kein Root-Login, eine Firewall auf dem Host, die nur die nötigen Ports hört, und Sicherheitsupdates in einem Fenster, in dem jemand den Dienst danach prüft. Verwaltungsoberflächen bleiben im internen Netz. Ein Break-Glass-Zugang liegt im Passwortmanager, nicht in einer Datei auf dem Desktop der Geschäftsführung.

Zugang, Updates und Dienste in eine nachvollziehbare Form bringen

  1. Sichern. Backup und einen dokumentierten Restore prüfen, bevor Regeln enger werden.
  2. Zugang. SSH auf Schlüssel umstellen, Root-Login sperren, Zugriff auf bekannte Netze begrenzen.
  3. Dienste. Alles abschalten, was nicht zur Aufgabe des Servers gehört, und den Zweck notieren.
  4. Updates. Sicherheitsupdates einem Fenster zuordnen und danach den eigentlichen Dienst testen.
  5. Kontrolle. Von außen und von einem Büro-PC prüfen, welche Ports noch antworten.

Der Server bleibt nur so sicher wie das Konto, mit dem sich Anwendungen anmelden. Ein Datenbankpasswort in einem weltlesbaren Skript macht die schönste Firewall wirkungslos. Deshalb gehört zur Härtung auch, Dienstkonten von Personenkonten zu trennen und Passwörter in den Passwortmanager zu legen. Die Anwendung selbst konfiguriert der Hersteller oder Ihr Fachbereich, wir schließen den Weg dahin.

Woran Projekte in der Praxis scheitern

  • SSH weiter aus dem ganzen Internet erlauben und nur den Port ändern.
  • Automatische Updates einschalten und niemanden benennen, der nach einem Neustart prüft.
  • Die Verwaltungsoberfläche über eine Portfreigabe „vorübergehend“ öffentlich lassen.
  • Den einzigen SSH-Schlüssel auf einem Notebook speichern, das beim Austritt mitgeht.

Beispiel aus dem Betriebsalltag

Ein Handelsbetrieb nutzte einen Linux-Server als Sprungpunkt für die Warenwirtschaft und hatte SSH auf der öffentlichen Adresse. Das Passwort stand in einem alten Ticket. Wir haben zuerst ein Backup der Konfiguration und der Anwendungsdaten gezogen, dann den Zugang auf Schlüssel über das VPN beschränkt und die nicht genutzte Weboberfläche abgeschaltet. Sicherheitsupdates laufen seither dienstags vormittags, danach öffnet die Buchhaltung einen Testauftrag. Der frühere Port aus dem Internet antwortet nicht mehr.

Kurze Entscheidungshilfe

  • Antwortet SSH nur aus dem Büro oder über das VPN?
  • Gibt es ein zweites autorisiertes Schlüsselpaar, falls ein Notebook ausfällt?
  • Ist dokumentiert, welche Dienste bewusst laufen?
  • Hat jemand nach dem letzten Update den eigentlichen Geschäftsprozess geklickt?

Wenn das Härten eines Linux-Servers im Alltag bei Ihnen ansteht, klären wir den Umfang unverbindlich: Linux-Server. Windows Server Lebenszyklus Alternativ direkt Kontakt aufnehmen oder die häufigen Fragen lesen.