Zum Inhalt springen
Hetzner Server absichern: SSH-Bruteforce stoppen, Logs kontrollieren und Snapshots klein halten

Hetzner Server absichern: SSH-Bruteforce stoppen, Logs kontrollieren und Snapshots klein halten

Warum Server-Sicherheit auch Speicher spart

Öffentlich erreichbare Server werden rund um die Uhr automatisiert gescannt – besonders auf SSH. Diese Zugriffsversuche sind meist harmlos, führen aber zu einem oft unterschätzten Problem: wachsende Log-Dateien.

Unbegrenzte System-, Auth- oder Docker-Logs sorgen dafür, dass Snapshots größer werden, Backups länger dauern und unnötig Speicher verbraucht wird. Mit ein paar gezielten Maßnahmen lässt sich das zuverlässig verhindern.

1) Erste Analyse: Wo geht der Speicher hin?

Bevor man aufräumt oder absichert, sollte man verstehen, was Platz belegt:

# Überblick über die Datenträger
df -h

# Größte Verzeichnisse
du -sh /* 2>/dev/null | sort -hr | head -20

# Größe der systemd-Journals
journalctl --disk-usage

# Größte Log-Verzeichnisse
du -sh /var/log/* | sort -hr | head -10

Typische Problemstellen bei SSH-Scans:

  • /var/log/journal (systemd-journald)
  • /var/log/auth.log (Authentifizierungsversuche)
  • /var/log/btmp (fehlgeschlagene Logins)

2) Journald begrenzen

Standardmäßig darf systemd-journald sehr viel Speicher nutzen. Eine Begrenzung verhindert dauerhaftes Wachstum:

# Einmaliges Aufräumen
journalctl --vacuum-size=100M

Empfohlene dauerhafte Limits:

nano /etc/systemd/journald.conf
SystemMaxUse=200M
SystemMaxFileSize=50M
RuntimeMaxUse=50M
systemctl restart systemd-journald

3) SSH absichern: Schlüssel statt Passwörter

Die wichtigste Sicherheitsmaßnahme für jeden Server: SSH-Zugriff ausschließlich über Schlüssel. Passwort-Logins sind anfällig für Bruteforce und erzeugen unnötig viele Logs.

Wichtig: Vor dem Deaktivieren von Passwort-Logins immer in einem zweiten Terminal testen, ob der SSH-Key funktioniert.

nano /etc/ssh/sshd_config

Empfohlene Einstellungen:

PubkeyAuthentication yes
PasswordAuthentication no

Optional (empfohlen):

PermitRootLogin prohibit-password

SSH neu starten (Ubuntu 24.04):

systemctl restart ssh

4) Fail2Ban: Automatische Abwehr

Fail2Ban überwacht Log-Dateien und sperrt IPs automatisch, wenn zu viele Fehlversuche auftreten. Das reduziert Angriffsversuche und Log-Spam erheblich.

apt update && apt install -y fail2ban

Minimal sinnvolle Konfiguration:

cat > /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 86400
EOF

systemctl enable fail2ban
systemctl restart fail2ban

Status prüfen:

fail2ban-client status sshd

5) Firewall-Regeln konsequent halten

Unabhängig davon, ob du UFW oder die Hetzner Cloud Firewall verwendest, gilt:

  • Nur Ports öffnen, die wirklich benötigt werden
  • Alles andere geschlossen halten

Wenn SSH auf einen alternativen Port gelegt wird (z. B. 1234):

  • Port 1234 erlauben
  • Port 22 schließen

Ein Port-Wechsel ist kein Sicherheitsfeature an sich, reduziert aber deutlich den automatisierten Scan-Traffic auf Port 22.

6) Optional: SSH-Port ändern (Ubuntu 24.04)

Beispiel für einen alternativen Port 1234:

# Backup
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

nano /etc/ssh/sshd_config
Port 1234

Ubuntu 24.04 nutzt standardmäßig einen Socket, der Port 22 erzwingen kann:

systemctl stop ssh.socket
systemctl disable ssh.socket
systemctl enable ssh.service
systemctl restart ssh.service

Port prüfen:

ss -tlnp | grep ssh

Verbindung testen:

ssh -p 1234 -i ~/.ssh/dein_key user@SERVER-IP

7) Docker-Logs begrenzen

Auch Docker-Logs können unbemerkt wachsen. Eine globale Log-Rotation verhindert das:

nano /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}
systemctl restart docker

Fazit

Eine solide Server-Härtung besteht nicht aus vielen exotischen Tools, sondern aus wenigen konsequenten Maßnahmen:

  1. SSH-Keys statt Passwörter
  2. Fail2Ban aktiv
  3. Firewall minimal halten
  4. Logs begrenzen

Damit bleibt der Server ruhig, sicher – und Snapshots wachsen nur noch durch echte Daten, nicht durch unnötigen Log-Spam.