Eigenen Server absichern: Linux und Windows

Einen eigenen Server sicherst du über fünf Bereiche ab, und in dieser Reihenfolge lohnt sich der Aufwand meiner Erfahrung nach am schnellsten. Erstens die Zugänge: Anmeldung mit Schlüssel statt Passwort, kein tägliches Arbeiten im Verwaltungskonto, Fernwartung nicht offen ins Internet. Zweitens die Aktualisierungen, automatisch für Sicherheitsupdates, weil das die einzige Maßnahme ist, die ohne dein Zutun weiterläuft. Drittens die offenen Dienste: erst nachsehen, was auf Verbindungen wartet, dann sperren, was von außen niemand braucht. Viertens die Sicherungskopien, getrennt vom Server und regelmäßig zurückgespielt. Fünftens die Protokollierung, damit du nach einem Vorfall etwas nachsehen kannst. Das ist eine Mindestbaseline, keine vollständige Absicherung, und welcher Punkt bei dir zuerst dran ist, hängt davon ab, was von außen erreichbar ist und was auf dem Server liegt. Das Bundesamt für Sicherheit in der Informationstechnik listet in seinen ersten Schutzmaßnahmen für Unternehmen das Aktualisieren an erster Stelle, dann Passwörter, dann Datensicherung mit Test.

Ich betreibe selbst Server, auf denen Dinge laufen, die ich nicht verlieren will, und habe die Sicherheitsarbeit an einen KI-Mitarbeiter abgegeben, der von außen prüft und jeden Fund belegt. Dazu unten mehr. Überlegst du noch, ob sich ein eigener Rechner lohnt: Eigener KI-Server: Hardware und Kosten und KI-Server für kleine Unternehmen. Hier geht es um den Server, der schon läuft, für die Website darauf um Website-Sicherheit online prüfen.

Zugänge: Schlüssel statt Passwort

In der OpenSSH-Dokumentation steht als Standardwert für PasswordAuthentication wie für PubkeyAuthentication jeweils yes, für das Verwaltungskonto steht PermitRootLogin auf prohibit-password. Das sind die Vorgaben des Upstream-Projekts, nicht automatisch die deines Servers: Distributionen und Cloud-Images setzen eigene Werte über Paketkonfiguration und Drop-in-Dateien, viele liefern die Passwortanmeldung bereits abgeschaltet aus. Was bei dir wirklich greift, zeigt sshd -T. Diese Ausgabe ist dein Ausgangspunkt, nicht die Handbuchseite.

Drei Schritte, in dieser Reihenfolge:

1. Schlüsselpaar anlegen und den öffentlichen Teil auf den Server bringen. Der private Teil bleibt auf deinem Rechner und bekommt eine Passphrase.
2. In einem zweiten Fenster testen, ob die Anmeldung mit Schlüssel funktioniert, bevor du irgendetwas abschaltest, und die erste Sitzung offen lassen, bis der Test durch ist. Das ist der Unterschied zwischen einer Umstellung und einer Aussperrung.
3. Erst dann PasswordAuthentication no setzen und PermitRootLogin auf no, wenn dein Arbeitskonto Verwaltungsrechte über sudo bekommen kann. Warte damit, bis ein zweiter Login mit Schlüssel geklappt hat, nicht nur der erste. AllowUsers oder AllowGroups grenzen zusätzlich ein, wer sich überhaupt anmelden darf, standardmäßig sind laut Dokumentation alle Benutzer und Gruppen erlaubt.

Der Schlüssel braucht danach dieselbe Sorgfalt wie vorher das Passwort: Passphrase drauf, bei Personalwechsel oder Verdacht tauschen, bei höherem Risiko eine zweite Stufe über AuthenticationMethods. Und wenn dir bei der Umstellung mulmig ist: Stell die Frage vorher in meiner Community, dort haben das genug Leute hinter sich.

Auf einem Windows-Server ist die Entsprechung die Fernwartung. Microsoft schreibt, dass das Aktivieren von Remotedesktop einen Port öffnet und man die Funktion nur in vertrauenswürdigen Netzen aktivieren soll; für den Zugriff von außen nennt Microsoft Portweiterleitung oder ein VPN. Der Standardweg ist das VPN oder ein administratives Gateway, dazu Mehrfaktor-Anmeldung, eine Beschränkung auf die zugelassenen Quellnetze und eine Überwachung der Anmeldeversuche. Eine schlichte Portweiterleitung im Router ist die begründete Ausnahme, nicht die Lösung. Netzwerkebenen-Authentifizierung (NLA) empfiehlt Microsoft für die meisten Umgebungen: Nutzer müssen sich anmelden, bevor die Sitzung überhaupt aufgebaut wird.

Aktualisierungen, und warum sie bei mir zuerst kommen

Das BSI nennt Schwachstellen in Programmen wörtlich "nach wie vor eines der Haupteinfallstore für Cyber-Angriffe" und setzt Sicherheitsupdates in seiner Liste erster Schutzmaßnahmen auf Position eins. Ich auch, aus einem praktischen Grund: Alle anderen Maßnahmen brauchen dich, diese läuft von allein weiter.

Debian und Ubuntu bringen dafür unattended-upgrades mit. Das Debian-Wiki hält fest, dass die Standardkonfiguration Sicherheitsupdates automatisch einspielt, aber keine neuen Funktionen; die Ubuntu-Serverdokumentation nennt als voreingestellte Quellen die Hauptquelle und die Sicherheitsquelle, während -updates, -proposed und -backports auskommentiert sind. Zwei Einstellungen lohnt ein Blick: Unattended-Upgrade::Automatic-Reboot steht laut Dokumentation auf false, ein Neustart nach einem Kernel-Update passiert also nicht von selbst, und Unattended-Upgrade::Mail schickt dir einen Bericht. Was auf deinem Server eingestellt ist, sagt dir aber nicht die Dokumentation, sondern der Blick in /etc/apt/apt.conf.d/50unattended-upgrades und 20auto-upgrades, denn Anbieter-Images bringen eigene Vorgaben mit. Und was passieren würde, zeigt ein Probelauf mit unattended-upgrade -v --dry-run.

Auf Windows Server hält Microsoft in der Dokumentation zu den Update-Richtlinien eine Besonderheit fest: Windows Server bezieht keine Funktionsupdates über Windows Update, es greifen also nur die Richtlinien für Qualitätsupdates. Die erscheinen laut derselben Quelle üblicherweise am zweiten Dienstag im Monat, und du kannst sie um 0 bis 35 Tage verzögern. Ein kleiner Verzug ist eine legitime Entscheidung, wenn du erst eine Maschine als Probe aktualisierst. Ein Verzug ohne Ende ist keine. Und läuft auf dem Server eine Anwendung, die einen Neustart nicht verträgt, brauchst du zusätzlich ein Wartungsfenster mit festem Termin.

Offene Dienste und der Netzwerkfilter

Vor jeder Firewall-Regel steht eine Inventur. Auf Linux zeigt ss -tulpen, welche Dienste auf Verbindungen warten und an welche Adresse sie gebunden sind, auf Windows leistet Get-NetTCPConnection -State Listen dasselbe. Der häufigste vermeidbare Fund ist ein Dienst, der an alle Adressen gebunden ist, obwohl ihn nur die Anwendung auf demselben Rechner braucht. Eine nur lokal genutzte Datenbank gehört an die lokale Adresse gebunden, nicht hinter eine Firewall-Regel, die man später wieder aufmacht.

Danach der Filter. Dafür stehen meist drei Ebenen nebeneinander: nftables direkt, ein Aufsatz wie ufw, und die Firewall deines Anbieters vor der Maschine. Unter Ubuntu ist ufw verbreitet und für einen einzelnen Server oft die einfachste Wahl, vorinstalliert oder gesetzt ist es deshalb nicht. Seine Handbuchseite nennt als Voreinstellung eingehend verweigern, weiterleiten verweigern, ausgehend erlauben: Du erlaubst gezielt die Dienste, die von außen erreichbar sein sollen, und schaltest die Firewall ein. Für die Fernwartung gibt es ufw limit, das laut Dokumentation Verbindungen verweigert, wenn eine IP-Adresse innerhalb von 30 Sekunden sechs oder mehr Verbindungen aufzubauen versucht. Das bremst automatisierte Anmeldeversuche, ersetzt die Schlüsselanmeldung aber nicht.

Auf Windows Server aktiviert die Sicherheitsbasislinie für Windows Server 2025 laut Microsoft die Firewall auf allen Profilen, verweigert eingehenden Verkehr grundsätzlich und lässt nur Ports mit ausdrücklicher Erlaubnisregel offen; dazu kommen das Abschalten von SMBv1 und die Beschränkung von TLS auf 1.2 oder höher. Microsoft rät, vor dem Einsatz in der Produktion sorgfältig zu testen, weil etwa die TLS-Untergrenze Verbindungen zu älteren Systemen verhindern kann.

Bei einem gemieteten Server sitzt meist noch ein Filter beim Anbieter davor. Zwei Filter sind kein Widerspruch, aber du solltest wissen, welcher gerade greift, sonst suchst du irgendwann eine Stunde nach einem Fehler, der eine Ebene höher sitzt.

Sicherungskopien, und der Test, den fast alle auslassen

Das BSI führt im Baustein CON.3 Datensicherungskonzept, Edition 2023, eine eigene Gefährdung "Fehlende Wiederherstellungstests": "Werden Daten regelmäßig gesichert, gewährleistet dies nicht automatisch, dass diese auch problemlos wiederhergestellt werden können." Das regelmäßige Testen steht dort als Basis-Anforderung, nicht als Kür.

Eine Sicherungskopie, die nie zurückgespielt wurde, ist eine Vermutung. Der Test gehört zum Verfahren.

Fünf Punkte, die in der Praxis am häufigsten schiefgehen:

• Die Kopie liegt auf demselben System. Eine Spiegelung über RAID zählt laut BSI ausdrücklich nicht als Datensicherung, weil die gespiegelten Daten simultan verändert werden: Sie hilft gegen einen Plattendefekt, nicht gegen Überschreiben oder Schadsoftware.
• Die getrennte Kopie hängt an denselben Zugangsdaten. Ein Sicherungsziel, das der Server selbst löschen darf, ist gegen Schadsoftware nur halb getrennt.
• Der Schlüssel liegt neben der verschlüsselten Kopie. Das BSI nennt genau diesen Fall: Ist bei einem Datenverlust auch der Schlüssel betroffen, sind die Daten verloren.
• Es gibt nur eine Generation. Wird die einzige Kopie jede Nacht überschrieben, sichert die Nacht nach einem Verschlüsselungsangriff den Schaden mit. Mindestens eine Generation gehört deshalb auf einen Speicher, der sich nachträglich nicht überschreiben lässt, oder auf ein Medium, das nach der Sicherung abgehängt wird.
• Niemand hat je zurückgespielt. Der Test ist der Punkt, den fast alle auslassen, und der einzige, der die anderen vier aufdeckt.

Ein Test muss nicht groß sein: ein leeres System, eine Wiederherstellung, ein Blick, ob die Anwendung startet und die Daten vom erwarteten Tag stammen, dazu eine Notiz mit Datum und benötigter Zeit. Diese Zeit sagt dir, wie lange ein Ausfall dauern würde. Wie oft du testest, leitest du aus zwei Größen ab: wie viele Stunden Datenverlust du verkraftest und wie lange die Wiederherstellung dauern darf. Je enger beide Werte, desto häufiger der Test. Wie das für eine Container-Umgebung aussieht, steht in Kubernetes Backup: etcd und Volumes sichern.

Protokollierung: sehen, was war

Protokolle verhindern nichts. Sie entscheiden, ob du nach einem Vorfall sagen kannst, was passiert ist, oder ob du raten musst.

Auf Systemen mit systemd sammelt journald die Meldungen. In der aktuellen Fassung der Dokumentation ist Storage=persistent der Standardwert; bei der Einstellung auto entscheidet allein die Existenz des Verzeichnisses /var/log/journal darüber, ob die Protokolle einen Neustart überleben oder nur im Arbeitsspeicher liegen. Verlass dich auch hier nicht auf den Standardwert: Ältere systemd-Fassungen und einzelne Distributionen weichen ab, und was bei dir wirklich gilt, zeigt systemd-analyze cat-config systemd/journald.conf. Ein Protokoll, das beim Neustart verschwindet, hilft genau dann nicht, wenn du es brauchst. Der Netzwerkfilter protokolliert bei ufw laut Dokumentation standardmäßig auf der Stufe "low", wenn nichts anderes angegeben ist.

Auf Windows Server übernimmt das die Ereignisanzeige. In der Sicherheitsbasislinie für Windows Server 2025 erfassen laut Microsoft nahezu alle Unterkategorien der erweiterten Überwachung Erfolg und Fehler, Anmeldungen, Kontenverwaltung und besondere Rechte werden überwacht, der Prozessstart wird samt Befehlszeile aufgezeichnet und das Sicherheitsprotokoll auf mindestens 192 MB vergrößert.

Bei mir liegt zusätzlich eine Kopie der Protokolle außerhalb des Servers, weil jemand mit Zugriff dort auch Spuren verwischen kann. Diese Kopie ist selbst schützenswert, denn in Protokollen stehen IP-Adressen, Benutzernamen und manchmal mehr: Leg fest, wer sie lesen darf, wie lange sie bleiben, wann sie gelöscht werden und woran du merkst, dass jemand sie verändert hat.

Wo eine Prüfung von außen anfängt

Die fünf Bereiche oben sind der Boden, nicht die Decke. Darüber liegen die Anwendungen selbst, Rechte nach dem kleinsten nötigen Zugriff, der Umgang mit Geheimnissen, TLS, ein geregelter Blick auf bekannte Schwachstellen, eine Alarmierung, die jemanden erreicht, und ein Plan für den Ernstfall. Und selbst dann weißt du nur, dass die bekannten Türen zu sind, nicht, wie dein Server von außen aussieht. Genau das ist die Frage, die am Ende zählt.

Diesen Teil macht bei mir Falk, mein KI-Mitarbeiter für Sicherheit. Er prüft gestuft statt in einem Durchgang: zuerst von außen ohne jeden Zugang, dann als unangemeldeter Besucher, und wo ich es freigebe, mit Zugang oder Einsicht in den Quellcode. Zu jedem Fund gehören ein Beleg, eine Einstufung nach dem CVSS-Standard und ein Reparaturvorschlag, nicht nur ein Listeneintrag; wie ein solches Audit von der Freigabe bis zur Nachprüfung abläuft, steht im eigenen Beitrag. Der automatisierte Teil läuft gedrosselt, bei mir mit höchstens 20 Anfragen pro Minute, damit eine Prüfung den Betrieb nicht stört.

Der Rahmen ist dabei so wichtig wie die Methode. Jeder Auftrag bekommt einen eigenen Zuschnitt und eine schriftliche Freigabe für genau das gemeinte System, und bevor die vorliegt, geht keine einzige Anfrage raus. Fremde Systeme ohne schriftlichen Scope prüft er nicht, destruktive Aktionen macht er nicht. Deshalb gibt es diese Arbeit auch nicht als Paket von der Stange: Die Freigabe gilt für ein bestimmtes System. Willst du zwischendurch selbst nachsehen, ob die Verschlüsselung deiner Dienste sauber steht, reicht die Anleitung in SSL-Zertifikat prüfen.

Häufige Fragen

Reicht ein sehr langes Passwort nicht auch?

Ein langes, einzigartiges Passwort ist deutlich besser als ein kurzes, und ohne Schlüsselverfahren das Mittel der Wahl. Bei SSH hat der Schlüssel zwei Vorteile: Ein starker Schlüssel ist praktisch nicht durchprobierbar, und der private Teil wird nie an den Server übertragen. Angreifbar bleibt er anders, nämlich kopiert, gestohlen oder mit schwacher Passphrase. Deshalb: Schlüssel mit Passphrase, und regelmäßig tauschen.

Sollte ich SSH auf einen anderen Port legen?

Das reduziert das Rauschen in den Protokollen, weil automatisierte Scanner meist zuerst den Standardport abklopfen. Als Schutz taugt es wenig, ein Portscan findet den Dienst trotzdem. Mach es, wenn dich die Fehlversuche stören, aber nicht statt Schlüsselanmeldung und Filter.

Kann ein automatisches Update etwas kaputtmachen?

Ja, das kann passieren, und deshalb ist die Voreinstellung bei Debian und Ubuntu auf Sicherheitsquellen beschränkt und startet nicht von selbst neu. Der Probelauf mit --dry-run zeigt vorher, was eingespielt würde. Die Gegenfrage gehört dazu: Ein Server mit einer seit Wochen offenen Lücke ist das größere Risiko.

Mein Server ist gemietet. Macht der Anbieter das nicht?

Das hängt vom Vertrag ab. Bei einem verwalteten Angebot kümmert sich der Anbieter meist um das Betriebssystem, bei einem unverwalteten Server oder VPS in der Regel nur um Hardware und Netz. Lies nach, wo die Grenze verläuft, und geh im Zweifel davon aus, dass alles darüber deine Aufgabe ist.

Ist Linux oder Windows sicherer?

Die Frage führt in die falsche Richtung. Beide Systeme bringen brauchbare Bordmittel mit, und in beiden Fällen entscheidet die Einrichtung: offene Dienste, Zugänge, Update-Stand. Der praktische Unterschied liegt darin, womit du dich auskennst: Ein System, dessen Protokolle du lesen kannst, ist in deinen Händen sicherer.

Wie du weitermachst

Nimm dir zwei Stunden und geh in dieser Reihenfolge vor. Erstens: Schreib auf, welche Dienste auf deinem Server lauschen. Zweitens: Stell die Anmeldung auf Schlüssel um, mit dem zweiten Fenster als Sicherheitsnetz. Drittens: Schalte automatische Sicherheitsupdates ein und lass dir den Bericht schicken. Viertens, der Schritt, den fast alle überspringen: Spiel eine Sicherungskopie auf ein leeres System zurück und notiere Datum und Dauer. Trag die vier Punkte in eine Tabelle mit den Spalten Maßnahme, erledigt am, nächste Prüfung ein, dann hast du mehr als die meisten kleinen Betriebe, die ich kenne. Und wenn du den Schritt dahinter gehen willst, einen KI-Mitarbeiter, der gestuft prüft und jeden Fund belegt: Der Weg dorthin liegt in meiner Community Claude Practitioners.