Ubuntu Server härten:
UFW, SSH, fail2ban, Updates.

Vor dem Härten: Standortbestimmung

Ein neu installiertes Ubuntu Server ist erstaunlich offen ausgeliefert. Was nach einer Minimal-Installation aktiv ist:

• SSH auf Port 22 mit Passwort-Login möglich
• Keine aktive Firewall (UFW installiert, aber inaktiv)
• Unattended-Upgrades nicht eingerichtet (nur Security-Quelle aktiviert)
• AppArmor aktiv, aber mit Standard-Profilen
• fail2ban nicht installiert

Mit den folgenden sechs Schritten wird das Setup deutlich abgesicherter. Erfahrungs-Schätzung: 1–2 Stunden für ein sauberes Initial-Hardening, wenn man weiß was man tut. Im Service-Auftrag plus Funktionstest und Dokumentation.

Schritt 1: UFW-Firewall einrichten

UFW (Uncomplicated Firewall) ist die Standard-Firewall-Konfiguration unter Ubuntu. Wir aktivieren sie als Standard-Default-Block und öffnen nur, was gebraucht wird.

# Standard: alles eingehend blockieren, alles ausgehend erlauben
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH erlauben (zunächst noch auf Port 22, wird in Schritt 2 geändert)
sudo ufw allow OpenSSH

# Bei Webserver: HTTP und HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Firewall aktivieren
sudo ufw enable

# Status prüfen
sudo ufw status verbose

Wichtig: vor dem ufw enable die SSH-Regel setzen, sonst sperrt man sich aus. Bei Plesk-Hosts kommen weitere Ports dazu: 8443 (Plesk-Backend), 8447 (Plesk-Updater), 21 (FTP), 25 / 465 / 587 (SMTP), 110 / 143 / 993 / 995 (POP3 / IMAP). Die genauen Ports hängen vom konkreten Setup ab.

Schritt 2: SSH absichern

SSH ist der wichtigste Angriffsvektor. Drei Maßnahmen, die zusammen den Großteil der automatisierten Bot-Angriffe ins Leere laufen lassen.

2a) SSH-Key generieren und hochladen

Auf dem lokalen Rechner (nicht auf dem Server!):

# Schlüssel generieren (Ed25519, modern und kurz)
ssh-keygen -t ed25519 -C "alex@workstation" -f ~/.ssh/server-key

# Schlüssel auf den Server hochladen
ssh-copy-id -i ~/.ssh/server-key.pub user@server-ip

# Test: Login ohne Passwort möglich?
ssh -i ~/.ssh/server-key user@server-ip

2b) SSH-Konfiguration anpassen

Auf dem Server /etc/ssh/sshd_config bearbeiten:

# Port wechseln (gegen Drive-By-Bots)
Port 22022

# Root-Login verbieten
PermitRootLogin no

# Passwort-Authentifizierung deaktivieren (NUR wenn SSH-Key funktioniert!)
PasswordAuthentication no
PubkeyAuthentication yes

# Maximale Login-Versuche
MaxAuthTries 3

# Idle-Timeout
ClientAliveInterval 300
ClientAliveCountMax 2

# Login-Banner (optional)
Banner /etc/issue.net

# Konfiguration prüfen, dann SSH-Daemon neu starten
sudo sshd -t  # Syntax-Check, gibt nichts aus wenn ok
sudo systemctl restart ssh

# UFW-Regel anpassen
sudo ufw allow 22022/tcp
sudo ufw delete allow OpenSSH

Faustregel: erst neue SSH-Verbindung in einem zweiten Terminal testen, bevor man die alte schließt. Wer sich aussperrt, braucht Konsolen-Zugang beim Hoster. Genau hier passieren die meisten Lockouts.

2c) fail2ban installieren

sudo apt install fail2ban

# eigene Konfiguration in /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
port = 22022
logpath = /var/log/auth.log

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Bei Plesk-Servern bringt Plesk eine eigene fail2ban-Integration mit (Tools & Einstellungen → Fail2Ban). Die ist oft komfortabler und überschneidet sich nicht mit einer manuellen Konfiguration – im Plesk-Setup nutzen wir die Plesk-Variante und ergänzen sie nur, wenn spezifische Jails fehlen.

Schritt 3: Automatische Sicherheits-Updates

Sicherheits-Patches sollten automatisch eingespielt werden – auch wenn man die Maschine selbst täglich anschaut. Ubuntu bringt dafür unattended-upgrades mit.

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure unattended-upgrades

Die Konfigurations-Dateien:

# /etc/apt/apt.conf.d/50unattended-upgrades

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
Unattended-Upgrade::Mail "alerts@example.com";

Wichtig: Automatic-Reboot nur aktivieren, wenn der Server eine geplante Wartungs-Zeit hat. Bei Plesk-Hosts ist das in der Regel nachts unproblematisch, bei spezialisierten Anwendungs-Servern muss das mit dem Anwendungs-Plan abgeglichen werden.

# Test: was würde ein Run aktuell installieren?
sudo unattended-upgrade --dry-run --debug

Schritt 4: AppArmor-Profile prüfen

AppArmor ist Ubuntus Mandatory-Access-Control-System. Es ist standardmäßig aktiv, aber mit eher schwachen Profilen für viele Dienste.

# Status prüfen
sudo aa-status

# Welche Profile sind im Enforce-Mode?
sudo aa-status | grep -A1 "enforce mode"

Für viele Setup-Standardfälle ist AppArmor mit den Default-Profilen brauchbar. Wer es ernster meint:

sudo apt install apparmor-utils apparmor-profiles apparmor-profiles-extra

# Beispiel: nginx-Profil aktivieren
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo systemctl restart apparmor

Wichtig: AppArmor-Profile können bestehende Anwendungen brechen, wenn sie zu strikt sind. Erst im Complain-Mode laufen lassen, Logs (journalctl -k) ansehen, dann auf Enforce stellen.

Schritt 5: Logging und Monitoring

Ohne Beobachtung ist Härtung blind. Die Mindest-Ausstattung:

5a) journalctl-Basis-Befehle

# Letzte Boot-Logs
sudo journalctl -b

# Auth-Versuche der letzten 24 Stunden
sudo journalctl _SYSTEMD_UNIT=ssh.service --since "24 hours ago"

# Live-Tail
sudo journalctl -f

5b) Log-Rotation und -Retention

Standardmäßig werden Logs durch logrotate verwaltet. Für sicherheits-relevante Logs (auth.log, fail2ban.log) sollten längere Retention-Zeiten gesetzt werden:

# /etc/logrotate.d/rsyslog anpassen
/var/log/auth.log
{
    rotate 12
    monthly
    missingok
    notifempty
    delaycompress
    compress
}

5c) Optional: aktives Monitoring

Für Server in produktivem Einsatz: Netdata (Realtime-Metriken), Munin (langfristige Trends), oder zentrales Logging mit Loki/Grafana. Bei Plesk-Setups gibt es teilweise eingebaute Monitoring-Tools, die für viele Use-Cases ausreichen.

Schritt 6: Regelmäßige Audits

Härtung ist kein einmaliger Vorgang. Drei Werkzeuge für regelmäßige Prüfungen:

Lynis: Sicherheits-Audit

sudo apt install lynis
sudo lynis audit system

# Ausgabe enthält Score und konkrete Verbesserungs-Vorschläge

Debsums: Dateiintegrität gegen Paket-Manifest

sudo apt install debsums
sudo debsums -c  # Prüft, ob Pakete unverändert sind

chkrootkit / rkhunter: Rootkit-Scanner

sudo apt install chkrootkit
sudo chkrootkit

Diese Tools sollten Teil eines monatlichen oder quartalsweisen Audit-Rhythmus sein. Ein Cron-Job, der Lynis monatlich läuft und das Ergebnis per E-Mail schickt, ist wenig Aufwand und liefert kontinuierliche Sichtbarkeit.

Häufige Fehler beim Härten

Fehler 1: SSH-Lockout durch Fehlkonfiguration

Kommt bei fast jedem Hardening-Anfänger einmal vor: PasswordAuthentication deaktiviert, aber der SSH-Key noch nicht eingerichtet. Oder die UFW-Regel für den neuen SSH-Port falsch geschrieben.

Faustregel: immer eine zweite SSH-Sitzung offen lassen, während du Änderungen testest. Erst wenn die neue Verbindung in einem frischen Terminal funktioniert, alte Sitzung schließen.

Fehler 2: UFW-Regel-Reihenfolge falsch

UFW arbeitet stateful, aber wenn man Regeln in falscher Reihenfolge zufügt, können vorherige Regeln greifen, bevor neue zum Zuge kommen. sudo ufw status numbered gibt eine Übersicht, sudo ufw delete N löscht Regel Nr. N.

Fehler 3: fail2ban-Bantime zu kurz

3600 Sekunden (1 Stunde) ist Standard, aber für ernste Bots zu wenig. 86400 (1 Tag) oder noch mehr für IPs mit drei oder mehr Lockouts ist üblich. Permanent-Ban via recidive-Jail ist die Eskalations-Stufe.

Fehler 4: AppArmor-Profile zu strikt

Ein Enforce-Profil, das Datei-Zugriffe blockiert, kann ganze Dienste lahmlegen. Erst Complain-Mode, dann Audit-Logs ansehen, dann Profil anpassen, dann Enforce. Nicht andersherum.

Fehler 5: Automatic-Reboot ohne Anwendungs-Plan

Wenn unattended-upgrades nachts neustartet, aber zu der Zeit ein Backup-Job läuft oder eine Datenbank-Migration aktiv ist, gibt es Inkonsistenzen. Reboot-Zeit muss zur Anwendungs-Wartungsfenster passen.

Plesk-Spezifika

Bei Plesk-Hosts gibt es einige Sondertruppen, die das normale Härten ergänzen:

• Plesk-eigene Fail2Ban-Integrationstatt manueller fail2ban-Konfiguration nutzen.
• Plesk-Firewall-GUIparallel zur UFW – nicht beide gleichzeitig konfigurieren.
• ModSecurity in Pleskals zusätzliche Web-Application-Firewall aktivierbar.
• Auto-Update für Plesk selbsteinrichten (Tools & Einstellungen → Updates).