Firewall und Fail2Ban: Den Server vor dem Internet schützen

Dein VPS hängt am Internet. Ab dem Moment, in dem er eine öffentliche IP bekommt, wird er angegriffen — nicht vielleicht, sondern garantiert. Automatisierte Scanner durchforsten permanent alle IP-Bereiche nach offenen Ports und bekannten Schwachstellen. Eine Firewall und Fail2Ban sind deshalb keine optionalen Extras, sondern die zweite Verteidigungslinie nach der SSH-Absicherung.

Warum eine Firewall, wenn nichts Sensibles läuft?

Ein häufiges Missverständnis: „Auf meinem Server läuft doch nur eine kleine Website, was soll da passieren?“ Die Antwort ist einfach. Angreifer interessieren sich nicht für deine Daten — sie wollen deine Ressourcen. Ein kompromittierter Server wird für Spam-Versand, DDoS-Angriffe oder Kryptomining missbraucht. Du merkst es vielleicht erst, wenn dein Hoster den Server sperrt oder du eine Rechnung für Terabytes an Traffic bekommst.

Eine Firewall löst dieses Problem an der Wurzel: Sie lässt nur den Traffic durch, den du explizit erlaubst. Alles andere wird verworfen, bevor es einen Dienst erreicht.

UFW einrichten — die unkomplizierte Firewall

Ubuntu bringt mit UFW (Uncomplicated Firewall) ein Frontend für iptables mit, das hält, was der Name verspricht. Die Grundlogik ist simpel: Erst alles verbieten, dann gezielt öffnen. Dieses Prinzip heißt Default Deny und ist der einzig sinnvolle Ansatz für eine Firewall.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Ausgehenden Traffic erlaubst du, weil dein Server selbst Verbindungen aufbauen muss — für Paket-Updates, DNS-Auflösung, API-Aufrufe oder E-Mail-Versand. Eingehenden Traffic sperrst du komplett und öffnest dann nur die Ports, die du wirklich brauchst.

sudo ufw allow 22/tcp    # SSH
sudo ufw allow 80/tcp    # HTTP
sudo ufw allow 443/tcp   # HTTPS

Bevor du UFW aktivierst, stelle sicher, dass Port 22 geöffnet ist. Sonst sperrst du dich im selben Moment aus, in dem die Firewall aktiv wird. Ich habe das einmal erlebt — es war kein guter Tag.

sudo ufw enable
sudo ufw status verbose

Die Ausgabe sollte dir genau drei offene Ports zeigen — SSH, HTTP und HTTPS. Alles andere ist geblockt. So soll es sein.

FTP explizit blockieren

FTP ist ein Protokoll aus den 1970er Jahren, das Passwörter im Klartext überträgt. Es gibt keinen einzigen guten Grund, FTP auf einem modernen Server zu verwenden. Trotzdem taucht es immer wieder auf — manchmal, weil ein Hoster es standardmäßig aktiviert, manchmal, weil jemand „mal schnell eine Datei hochladen“ wollte.

sudo ufw deny 21/tcp
sudo ufw deny 20/tcp

Ja, UFW blockiert bereits alles, was nicht explizit erlaubt ist. Aber eine explizite Deny-Regel für FTP hat zwei Vorteile: Sie dokumentiert die bewusste Entscheidung, und sie bleibt wirksam, selbst wenn jemand später versehentlich die Default-Policy ändert. Explizit ist besser als implizit — bei Firewalls ganz besonders.

Fail2Ban — wenn die Firewall nicht reicht

Eine Firewall kontrolliert, welche Ports erreichbar sind. Aber Port 22 muss offen bleiben, sonst kommst du selbst nicht mehr auf den Server. Genau diesen offenen Port nutzen Brute-Force-Angriffe: Sie probieren systematisch Benutzernamen und Passwörter durch, bis sie Zugang haben. Auch wenn du Passwort-Authentifizierung deaktiviert hast, erzeugen diese Versuche Last und füllen deine Logs.

Fail2Ban löst das Problem elegant. Es überwacht Log-Dateien in Echtzeit, erkennt fehlgeschlagene Anmeldeversuche und sperrt die IP-Adresse des Angreifers für eine definierte Zeit. Das Konzept dahinter nennt sich Jail — ein Gefängnis für auffällige IP-Adressen.

sudo apt install -y fail2ban

Fail2Ban bringt eine Standardkonfiguration mit, die du nicht direkt bearbeiten solltest — sie wird bei Updates überschrieben. Stattdessen legst du eine lokale Konfiguration an, die Vorrang hat.

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Die SSH-Jail konfigurieren

Im Abschnitt [sshd] der Datei jail.local passt du die wichtigsten Parameter an:

[sshd]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
findtime = 600
bantime  = 3600

maxretry ist die Anzahl fehlgeschlagener Versuche, bevor eine IP gesperrt wird — drei ist ein guter Wert, der echte Tippfehler noch toleriert, aber Brute-Force-Angriffe schnell stoppt. findtime definiert das Zeitfenster in Sekunden: drei Fehlversuche innerhalb von zehn Minuten lösen die Sperre aus. bantime legt fest, wie lange die Sperre gilt — eine Stunde reicht, um automatisierte Angreifer abzuschütteln, ohne legitime Benutzer dauerhaft auszusperren.

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Testen, ob alles funktioniert

Sicherheitsmaßnahmen, die du nicht testest, sind wertlos. Du weißt nicht, ob sie funktionieren, bis es zu spät ist. Also prüfst du jetzt, ob Firewall und Fail2Ban korrekt arbeiten.

# Firewall-Status prüfen
sudo ufw status numbered

# Fail2Ban-Status prüfen
sudo fail2ban-client status
sudo fail2ban-client status sshd

Der Fail2Ban-Status zeigt dir die aktive Jail, die Anzahl der aktuell gesperrten IPs und die Gesamtzahl der bisherigen Sperren. Auf einem frischen Server siehst du hier bereits nach wenigen Stunden die ersten gesperrten IPs — ein eindrucksvoller Beweis dafür, dass die Einrichtung keine Paranoia war, sondern Notwendigkeit.

Falls du eine gesperrte IP manuell entsperren musst — etwa weil du dich selbst ausgesperrt hast — geht das so:

sudo fail2ban-client set sshd unbanip [IP-ADRESSE]

Die zweite Schicht steht

Dein Server hat jetzt eine Firewall, die nur den nötigen Traffic durchlässt, und einen Schutzmechanismus gegen Brute-Force-Angriffe. Zusammen mit der SSH-Absicherung aus dem ersten Teil hast du drei unabhängige Sicherheitsschichten: Key-only-Authentifizierung, Firewall und automatische IP-Sperren. Keine einzelne davon ist perfekt — aber zusammen machen sie deinen Server zu einem deutlich unattraktiveren Ziel. Im nächsten Schritt installierst du nginx und richtest SSL ein.