Den eigenen Server absichern – sechs Grundregeln aus der Praxis
Ein Server im Internet wird ab der ersten Minute gescannt. Das merkt man spätestens beim ersten Blick in die Logs. Seit ich meinen eigenen Linux-Server betreibe – mit mehreren Websites, eigenem DNS und Mailserver – ist Absicherung für mich kein Zusatz mehr, sondern Teil jeder Änderung. Hier sind die Grundregeln, nach denen ich arbeite.
1. Standardmäßig alles zu
Die Firewall (bei mir UFW) blockiert eingehende Verbindungen grundsätzlich. Geöffnet wird nur, was ein Dienst wirklich braucht – und jede neue Freigabe ist eine bewusste Entscheidung. Eine Lektion dabei: Docker legt eigene Firewall-Regeln an und kann UFW umgehen. Container-Ports veröffentliche ich deshalb nur auf der lokalen Schnittstelle.
2. Dienste nur dort, wo sie gebraucht werden
Eine Datenbank, die nur von Anwendungen auf demselben Server genutzt wird, muss nicht aus dem Internet erreichbar sein. Meine Datenbanken lauschen nur lokal. Was nicht erreichbar ist, kann auch nicht angegriffen werden.
3. SSH: Schlüssel plus zweiter Faktor
Passwort-Logins allein sind zu schwach. Bei mir braucht jede SSH-Anmeldung einen Schlüssel und einen zeitbasierten Einmalcode (TOTP). Wichtig ist dabei ein Notfallplan: Ersatzcodes und der Zugang über die Konsole des Anbieters – sonst sperrt man sich bei einem Fehler selbst aus.
4. Automatische Updates und Schutz vor Brute Force
Sicherheitsupdates spielt unattended-upgrades automatisch ein. fail2ban sperrt Adressen, die wiederholt fehlgeschlagene Anmeldungen bei SSH oder Mail verursachen.
5. Minimale Rechte
Der Webserver darf die Dateien der Websites lesen – mehr nicht. Die Dateien gehören meinem Benutzer, der Webserver ist nur über die Gruppe berechtigt. Wird eine Anwendung kompromittiert, kann sie ihren eigenen Code nicht verändern.
6. Verschlüsselung überall – und getrennt
Jede Website hat ihr eigenes TLS-Zertifikat von Let’s Encrypt mit automatischer Erneuerung. Früher teilten sich mehrere Domains ein Zertifikat – fiel eine davon weg, scheiterte die Erneuerung für alle. Getrennte Zertifikate machen das System robuster. Für E-Mail kommen SPF, DKIM, DMARC, MTA-STS und DANE dazu, die Zone ist mit DNSSEC signiert.
Fazit
Keine dieser Maßnahmen ist für sich spektakulär. Die Sicherheit entsteht aus der Kombination – und aus der Gewohnheit, jede Änderung zu prüfen, bevor sie live geht: Konfiguration testen, dann neu laden, dann von außen kontrollieren.
Mehr zum Aufbau des Servers steht im Projekt Eigener Linux-Server.