Ab dem Moment, in dem es ‚mein Server‘ wurde, liegt alles in meiner Verantwortung
Beim letzten Mal habe ich die Mauer der Linux-CLI und der Berechtigungen (Permissions) überwunden. chmod, chown und auch das absolut verbotene chmod 777. Die Zugriffskontrolle auf einzelne Dateien hatte ich einigermaßen im Griff.
Aber damals unterlag ich einem großen Irrtum. Ich dachte, der Server sei sicher, solange ich nur die ‚Dateiberechtigungen‘ gut verwalte.
„Server-Sicherheit? Macht das nicht das Security-Team?“
In einem Großkonzern mag das so sein. Aber ich bin Solo-Entwickler. Serveradministrator, Sicherheitsbeauftragter, Netzwerkingenieur – das alles bin ‚ich‘. Die gesamte Verantwortung für die Sicherheit lag auf meinen Schultern.
Und was mir das bewusst machte, war das Server-Zugriffsprotokoll, das ich eines Montagmorgens entdeckte.
Die Krise: Jemand klopfte an die Tür meines Servers
Montagmorgen, als ich mich gewohnheitsmäßig per SSH mit dem Server verband und die Protokolle prüfte, entdeckte ich etwas Seltsames.
# Letzte fehlgeschlagene SSH-Anmeldeversuche prüfen
$ grep "Failed password" /var/log/auth.log | tail -20
Beim Anblick der Protokolle auf dem Bildschirm bekam ich Gänsehaut.
Feb 10 03:14:22 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:25 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:27 sshd: Failed password for admin from 185.220.xx.xx
Feb 10 03:14:30 sshd: Failed password for ubuntu from 185.220.xx.xx
...
Ab 3 Uhr morgens Hunderte von Login-Versuchen. Die IP-Adresse aus dem Ausland. Die Kontonamen wechselten zwischen root, admin und ubuntu. Das war jemand, der ein ‚automatisiertes Programm (Bot)‘ laufen ließ, um Passwörter per Brute Force zu knacken.
„Moment – bin ich nicht bereits gehackt worden…?“
Zum Glück kam niemand durch. Aber kann man vor einem Einbrecher, der vor der Tür Schlüssel um Schlüssel ausprobiert, wirklich sagen: „Er ist nicht reingekommen, also alles in Ordnung“? Ich begann sofort, den Sicherheitsstatus des Servers zu überprüfen.
Schritt 1: Die Eingangstür abschließen – SSH härten
Die Eingangstür des Servers ist SSH (Secure Shell). Genau das, was ich benutze, um mich mit dem Server zu verbinden. Das Problem: Auch Hacker wollen durch dieselbe Tür hinein. Zuallererst muss diese Eingangstür gehärtet werden.
SSH-Port ändern (Standard 22 → andere Nummer)
Der Standard-SSH-Port ist 22. Die automatischen Scanner der Hacker klopfen zuerst an Port 22. Allein durch das Ändern der Portnummer lassen sich über 90 % der Brute-Force-Angriffe abwehren.
# SSH-Konfigurationsdatei öffnen
$ sudo vi /etc/ssh/sshd_config
# Portnummer ändern (Standard 22 → z. B. 2222)
Port 2222
# SSH-Dienst neu starten
$ sudo systemctl restart sshd
Bildlich gesprochen: Einbrecher zielen meist auf den Haupteingang im Erdgeschoss (Port 22). Wenn Sie den Eingang auf die Dachtür im dritten Stock (Port 2222) verlegen, finden die meisten Einbrecher nicht einmal, wo die Tür ist.
Direkten Root-Login sperren
In den Protokollen ist zu sehen, dass Hacker zuerst das Konto ‚root‘ ausprobieren. root ist das höchste Administratorkonto in Linux – wer das knackt, kann den ganzen Server übernehmen.
# In der SSH-Konfigurationsdatei den direkten Root-Login sperren
$ sudo vi /etc/ssh/sshd_config
PermitRootLogin no
Nun ist eine SSH-Verbindung als root gar nicht mehr möglich. Man loggt sich mit einem normalen Konto ein und erhöht bei Bedarf per sudo die Rechte.
SSH-Schlüssel statt Passwort
Egal wie komplex ein Passwort ist – wenn ein automatisiertes Programm zehntausende Kombinationen durchprobiert, kann es irgendwann geknackt werden. Die sicherste Methode ist, die Passwort-Anmeldung komplett zu deaktivieren und sich nur mit einem ‚SSH-Schlüssel (Key)‘ anzumelden.
# Auf meinem Rechner (lokal) ein SSH-Schlüsselpaar erzeugen
$ ssh-keygen -t rsa -b 4096
# Öffentlichen Schlüssel auf den Server kopieren
$ ssh-copy-id -p 2222 user@my-server-ip
# Auf dem Server die Passwort-Anmeldung deaktivieren
$ sudo vi /etc/ssh/sshd_config
PasswordAuthentication no
SSH-Schlüssel-Authentifizierung ist kein ‚Schlüssel‘, sondern eine ‚Fingerabdruck-Erkennung‘. Ein Passwort (Schlüssel) lässt sich kopieren, aber der private Schlüssel (Fingerabdruck), der nur auf meinem Rechner liegt, ist praktisch nicht zu kopieren.
Schritt 2: Einen Zaun errichten – Firewall
Wenn die Eingangstür (SSH) gehärtet ist, geht es nun darum, rund um das Gebäude einen Zaun zu ziehen und die Zugänge zu kontrollieren. Das ist die ‚Firewall‘.
Ein Server hat insgesamt 65.535 Ports (Zugänge). Ohne Firewall stehen alle 65.000 Türen sperrangelweit offen. Man öffnet nur die nötigen Türen und schließt den Rest ab.
Das unter Linux am einfachsten zu verwendende Firewall-Tool ist ‚UFW (Uncomplicated Firewall)‘.
# UFW aktivieren
$ sudo ufw enable
# Standardrichtlinie: Eingehend alles blockieren, ausgehend erlauben
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
# Nur nötige Ports öffnen
$ sudo ufw allow 2222/tcp # SSH (geänderter Port)
$ sudo ufw allow 80/tcp # HTTP
$ sudo ufw allow 443/tcp # HTTPS
# Aktuellen Firewall-Status prüfen
$ sudo ufw status
| Port | Zweck | Status |
|---|---|---|
| 2222 | SSH (geänderter Port) | ✅ Erlaubt |
| 80 | HTTP (Web) | ✅ Erlaubt |
| 443 | HTTPS (Sicheres Web) | ✅ Erlaubt |
| 22 | SSH (Standard, nicht mehr in Verwendung) | ❌ Blockiert |
| Rest | Alle anderen | ❌ Blockiert |
Von 60.000 Türen sind genau 3 offen, der Rest wurde zugemauert. Der Einbrecher hat gar keine Tür mehr, an die er klopfen könnte.
Schritt 3: Kommunikation verschlüsseln – HTTPS
Wenn der Server Webdienste bereitstellt, muss auch die Kommunikation zwischen Benutzer und Server geschützt werden. Das ist ‚HTTPS‘.
HTTP verschickt Daten wie eine ‚Postkarte‘, die jeder unterwegs mitlesen kann. HTTPS verschickt die Daten in einem ‚versiegelten Brief‘. Selbst wenn jemand ihn abfängt, kann er den Inhalt nicht lesen.
Was wäre, wenn die Benutzerkennung und das Passwort, die ein Nutzer in ein Login-Formular eingibt, per HTTP übertragen würden? Jeder im selben Café-WLAN könnte sie im Klartext mitlesen.
Die einfachste Methode, HTTPS in der Praxis einzurichten, ist ein kostenloses SSL-Zertifikat von ‚Let’s Encrypt‘.
# Certbot installieren (Let's Encrypt-Automatisierungstool)
$ sudo apt install certbot python3-certbot-nginx
# Zertifikat ausstellen und automatisch in Nginx einbinden
$ sudo certbot --nginx -d mydomain.com
# Automatische Erneuerung testen (Zertifikat muss alle 90 Tage erneuert werden)
$ sudo certbot renew --dry-run
Mit diesen paar Befehlszeilen wird die Adresse meines Dienstes von http:// zu https://, und in der Adressleiste des Browsers erscheint das Schloss-Symbol. Das schafft bei den Nutzern Vertrauen: „Diese Seite ist sicher.“
Schritt 4: Automatisches Verteidigungssystem – Fail2Ban
Selbst wenn Sie den SSH-Port ändern und die Schlüssel-Authentifizierung einrichten, gibt es hartnäckige Bots da draußen. Es gibt garantiert welche, die auch den geänderten Port finden und sich anzumelden versuchen.
In solchen Fällen ist ‚Fail2Ban‘ nützlich. Ein Tool, das IP-Adressen automatisch sperrt, wenn sie eine bestimmte Anzahl fehlgeschlagener Login-Versuche überschreiten.
# Fail2Ban installieren
$ sudo apt install fail2ban
# SSH-Schutz konfigurieren
$ sudo vi /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
maxretry = 5
bantime = 3600
findtime = 600
| Einstellung | Bedeutung |
|---|---|
| maxretry = 5 | Bei 5 Fehlversuchen |
| bantime = 3600 | wird die IP 1 Stunde lang gesperrt |
| findtime = 600 | Gilt bei 5 Fehlversuchen innerhalb von 10 Minuten |
# Fail2Ban starten
$ sudo systemctl enable fail2ban
$ sudo systemctl start fail2ban
# Aktuell gesperrte IPs prüfen
$ sudo fail2ban-client status sshd
Fail2Ban ist ‚Überwachungskamera + Automatikschloss‘ vor der Eingangstür. Wenn eine verdächtige Person das Passwort mehrmals falsch eingibt, wird ihr automatisch der Zutritt verweigert.
Praxistipp: Sicherheits-Checkliste
Die bisher eingerichteten Maßnahmen fasse ich als Checkliste zusammen. Wer beim Aufsetzen eines neuen Servers diese Liste abarbeitet, hat eine grundlegende Schutzschicht.
| # | Punkt | Befehl/Einstellung |
|---|---|---|
| 1 | SSH-Port ändern | Port 2222 in sshd_config |
| 2 | Root-Login sperren | PermitRootLogin no |
| 3 | Auf SSH-Schlüssel umstellen | PasswordAuthentication no |
| 4 | Firewall aktivieren | ufw enable, nur nötige Ports erlauben |
| 5 | HTTPS einrichten | Let’s Encrypt + Certbot |
| 6 | Fail2Ban installieren | Automatische IP-Sperre bei Login-Fehlern |
| 7 | Regelmäßige Updates | sudo apt update && sudo apt upgrade |
Punkt 7 ist wichtiger, als man denkt. Sicherheitslücken werden täglich entdeckt. Egal wie gut die Firewall ist – wenn das OS oder die Software selbst Löcher hat, nützt das nichts. Regelmäßige Updates sind die einfachste und gleichzeitig wirksamste Sicherheitsmaßnahme.
Abschluss: Sicherheit ist nichts Besonderes, sondern Gewohnheit
Am Anfang kam mir das Wort Sicherheit überwältigend vor. Hacker abwehren, Eindringlinge erkennen, Verschlüsselung… Ich hielt das für Filmstoff.
Aber in der Praxis stellte sich heraus: Es braucht keine ausgefeilten Techniken. SSH-Port ändern, Firewall einschalten, Schlüssel-Authentifizierung einrichten, Fail2Ban installieren. Alles in ein paar Befehlszeilen erledigt. Wichtig ist nicht das ‚Wissen‘, sondern das ‚Tun‘.
Sicherheitsvorfälle passieren nicht durch hochentwickelte Hacking-Techniken, sondern auf Servern, auf denen die grundlegenden Maßnahmen nicht umgesetzt wurden.
Seit jenem Tag führe ich jedes Mal, wenn ich einen neuen Server aufsetze, diese Sicherheits-Checkliste unbedingt vor dem Code-Deployment durch. Bevor ich die Tür öffne, prüfe ich das Schloss. Das ist die grundlegendste Haltung, um einen Server zu schützen.
Bisher haben wir die Grundfitness (CLI, Berechtigungen, Sicherheit) trainiert, um in der Wildnis Linux zu überleben. Aber ein grundlegendes Problem bleibt: Mein Laptop (Windows) und der Linux-Server haben unterschiedliche Umgebungen. Auch die Java-Version und die Bibliotheken unterscheiden sich.
Es gibt eine Technologie, die die Ausrede „Auf meinem Rechner läuft’s aber“ endgültig beendet. Im nächsten Beitrag schauen wir uns ‚Virtualisierung und Container‘ an – sie eliminieren Umgebungsunterschiede komplett.