VPS-Härtung (Härtung und Sicherheit von Linux-VPS)

1. Überblick über das Konzept und das systemische Problem

Unmittelbar nach der Initialisierung eines virtuellen Servers (VPS) bei einem Cloud-Provider (Hetzner, DigitalOcean, AWS) wird die Instanz innerhalb der ersten 5–15 Minuten von globalen Botnetzen gescannt. Viele Standard-Betriebssystem-Images haben die Passwort-Authentifizierung für den root-Benutzer aktiviert, offene Dienstports und keinen grundlegenden Schutz gegen Brute-Force-Angriffe.

VPS Hardening (Server-Härtung) ist ein ingenieurtechnisches Regelwerk zur Stärkung der Sicherheit des Linux-Betriebssystems gemäß dem CIS Benchmark-Standard (Center for Internet Security). Die Ziele des Hardenings sind:

• Minimierung der potenziellen Angriffsfläche (Attack Surface).
• Vollständige Eliminierung der Möglichkeit, sich über unsichere Kanäle mit Passwörtern anzumelden.
• Isolierung der Prozessausführung unter dem Superuser-Konto (Root).
• Einrichtung einer Ereignisüberwachung, automatischer Schließung von Zero-Day-Schwachstellen (0-day) und Paketfilterung auf Kernel-Ebene.

Початковий стан VPS (Високий ризик):
[Інтернет] ---> [Порт 22: SSH (Root + Пароль)] ---> [Повний злам системи]

Після Hardening (Багаторівнева оборона):
[Інтернет] ---> [UFW Фаєрвол (Default Deny)]
                     |
                     v
                [Fail2ban (Блокування сканерів)]
                     |
                     v
                [SSH: Тільки Ed25519 ключі, Non-Root sudo]
                     |
                     v
                [Автономні оновлення (unattended-upgrades)]

2. Architektonische Taxonomie und mentales Modell

Das Hardening wird in vier isolierten Sicherheitsebenen umgesetzt:

1. Ebene der Authentifizierung und Zugriffskontrolle (Identity & Access):
   • Vollständige Deaktivierung des direkten root-Logins über SSH (PermitRootLogin no).
   • Verbot der Passwort-Authentifizierung (PasswordAuthentication no).
   • Erstellung eines nicht privilegierten Benutzers mit obligatorischer Mitgliedschaft in der Gruppe sudo.
   • Installation kryptografischer Ed25519-Schlüssel.
2. Netzwerkebene (Network Perimeter):
   • Aktivierung von ufw mit einer Richtlinie zum Verwerfen aller eingehenden Pakete (default deny incoming).
   • Öffnung nur lebensnotwendiger Ports (z. B. 2222/tcp, 80/tcp, 443/tcp).
   • Bereitstellung von fail2ban zur automatischen Sperrung von Hosts, die anomale Anfragen generieren.
3. Betriebssystem- und Kernelebene (OS & Kernel):
   • Tuning der sysctl-Parameter zum Schutz des Netzwerk-Stacks (Verbot von ICMP-Redirects, Schutz vor SYN-Flood-Angriffen).
   • Aktivierung erweiterter Sicherheitsupdates (unattended-upgrades).
4. Anwendungs- und Laufzeitumgebungsebene (Runtime Isolation):
   • Ausführung von Docker-Containern und AI-Agenten unter separaten, nicht privilegierten UID/GIDs ohne Zugriff auf /var/run/docker.sock.

3. Technischer Pipeline und interne Mechanik

Schritt 1. Erstellung eines sudo-Benutzers und Deployment des SSH-Schlüssels

Nach der Verbindung mit dem sauberen Server unter Verwendung eines temporären root-Passworts erstellen wir sofort einen Ingenieursbenutzer:

# Створення користувача deploy з домашньою директорією та zsh/bash
adduser --gecos "" deploy
usermod -aG sudo deploy

# Копіювання публічного ключа Ed25519
mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Schritt 2. Härtung des OpenSSH-Daemons (/etc/ssh/sshd_config.d/99-hardening.conf)

Wir erstellen eine isolierte SSH-Konfigurationsdatei, um Überschreibungen während Paketupdates zu verhindern:

# Зміна порту (опціонально, але рекомендовано)
Port 2222

# Повна заборона root-доступу та паролів
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Дозвіл виключно надійних криптографічних ключів
PubkeyAuthentication yes
AuthenticationMethods publickey

# Захист сесій від зависання
ClientAliveInterval 300
ClientAliveCountMax 2

# Відключення небезпечних функцій перенаправлення
X11Forwarding no
AllowTcpForwarding yes

Testen der Konfiguration vor dem Neustart:

# Валідація синтаксису (якщо порожній вивід — конфіг коректний)
sudo sshd -t
sudo systemctl restart sshd

Schritt 3. Konfiguration der Linux-Kernel-Parameter (/etc/sysctl.d/99-security.conf)

# Захист від TCP SYN Flood атак
net.ipv4.tcp_syncookies = 1

# Заборона перенаправлення пакетів маршрутизації (захист від Man-in-the-Middle)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Ігнорування підроблених ICMP-відповідей
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Заборона IP Source Routing
net.ipv4.conf.all.accept_source_route = 0

Anwenden der Kernel-Änderungen ohne Neustart:

sudo sysctl --system

4. Praktische Ingenieursszenarien im Produktionsbetrieb

01. Automatisiertes Hardening via Cloud-Init auf Hetzner Cloud

Beim Erstellen eines virtuellen Servers über Terraform oder das Hetzner Control Panel wird ein User Data Script (cloud-init) übergeben. Der Server startet bereits mit deaktiviertem Root-Zugang, einem vorab erstellten Benutzer, generierten UFW-Regeln und konfiguriertem SSH auf einem Nicht-Standard-Port. Dies eliminiert vollständig das Zeitfenster der Schwachstelle in den ersten Lebensminuten der Maschine.

02. Automatische Aktualisierung von Kernel-Sicherheitspatches ohne Eingriff

Konfiguration des Pakets unattended-upgrades in Ubuntu:

sudo apt install unattended-upgrades update-notifier-common
sudo dpkg-reconfigure --priority=low unattended-upgrades

Der Server lädt und installiert kritische Sicherheitsupdates aus offiziellen Security-Repositorien automatisch jede Nacht, während das Tool needrestart kompromittierte Dienste ohne Neustart des Betriebssystems automatisch neu startet.

03. Isolierung des internen Traffics des Docker-Daemons

Docker versucht automatisch, Ports an alle Netzwerkschnittstellen (0.0.0.0) zu binden. Während des Hardenings wird die Datei /etc/docker/daemon.json so konfiguriert, dass die Standard-Bindung eingeschränkt wird:

{
  "iptables": true,
  "live-restore": true,
  "userland-proxy": false
}

Dies stellt sicher, dass Dienste ohne explizites Mapping auf den lokalen Host innerhalb des virtuellen Docker-Netzwerk-Bridges bleiben und keine Ports im öffentlichen Internet offenlegen.

5. Fallstricke, typische Fehler und Sicherheit

1. Versehentliche Selbstsperrung (SSH Lockout): Der häufigste Ingenieursfehler: Den Passwortzugriff schließen und Root verbieten, ohne zu überprüfen, ob der öffentliche Schlüssel für den neuen Benutzer funktioniert oder ob der neue Port in UFW erlaubt ist. Schließen Sie niemals die ursprüngliche Terminal-Sitzung, bevor Sie sich erfolgreich in einem parallelen Tab verbunden haben.
2. Speicherung des sudo-Passworts in Skripten oder .bash_history: Die Verwendung von echo "password" | sudo -S ... in Shell-Skripten oder die Eingabe von Passwörtern im Terminal führt zu Leaks im Klartext in der Befehlshistorie. Verwenden Sie sudo visudo, um spezifische Befehle ohne Passwort (NOPASSWD) für spezialisierte Service-Accounts in CI/CD-Pipelines zu delegieren.
3. Ignorieren der Sicherheit der Out-of-band-Konsole des Providers: Sogar ein perfekt gehärteter Server kann kompromittiert werden, wenn das Konto in der Konsole des Hosting-Providers (Hetzner Cloud Console, DigitalOcean Dashboard) durch ein einfaches Passwort ohne hardwarebasierte Zwei-Faktor-Authentifizierung (2FA / WebAuthn) geschützt ist. Der Zugang zur Provider-Konsole entspricht dem direkten physischen Zugang zur Hauptplatine des Servers.