Freorit

Warum Server-Härtung wichtig ist

Ein frisch installierter Linux Server ist funktional, aber nicht sicher. Er lauscht auf vielen Ports, akzeptiert Passwortauthentifizierung, protokolliert alles auf der Festplatte und hat minimalen Schutz vor Brute-Force-Angriffen.

Server-Härtung ist der Prozess der systematischen Reduzierung dieser Angriffsflächen. Es ist keine einzelne Aktion — es ist ein geschichteter Ansatz.

Das Problem

Standard-Linux-Installationen sind sinnvoll für Entwicklung, nicht für Produktion. Häufige Sicherheitsversäumnisse:

• SSH erlaubt Passwortauthentifizierung (anfällig für Brute Force)
• Alle Ports sind offen und zeigen verfügbare Dienste an
• Keine Ratenbegrenzung bei fehlgeschlagenen Anmeldeversuchen
• Logs wachsen unbegrenzt und verbrauchen Speicherplatz
• Keine Backup-Strategie bedeutet Datenverlust ist unvermeidlich, nicht nur möglich
• System-Updates sind manuell, wodurch bekannte CVEs ungepatcht bleiben

Die Lösung

Dieser Guide führt durch sechs Härtungsschichten, die jeweils auf die vorherige aufbauen:

1. Fundament: Benutzer, Berechtigungen, Updates
2. SSH: Schlüsselbasierte Authentifizierung, Protokollbeschränkungen
3. Firewall: Zustandsabhängige Regeln, Ausgangsfilterung
4. Eindringlingsprävention: Fail2ban Ratenbegrenzung
5. Monitoring: Logs, Metriken, Alerting
6. Backup: Automatisierte Wiederherstellung, getestete Restores

Schicht 1: System-Fundament

Bevor SSH, Firewall oder Fail2ban, muss das Fundament solide sein: minimale Benutzerrechte, Dateisystem-Berechtigungen und aktuelle Software.

Prinzip der geringsten Privilegien

Erstelle Konten nur für das Notwendige. Deaktiviere ungenutzte Dienste.

sudo useradd -m -s /bin/bash -G sudo deploy
sudo passwd deploy
# Grant sudo ohne Passwort für spezifische Befehle (optional)
# echo "deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl" | sudo tee -a /etc/sudoers.d/deploy
    

Nutze niemals root für tägliche Aufgaben. Benutze immer einen normalen Benutzer mit sudo für administrative Aktionen.

Dateisystem-Berechtigungen

Beschränke sensitive Dateien auf Nur-Lese für Root:

sudo chmod 600 /etc/ssh/sshd_config
sudo chmod 700 /root
sudo chmod 644 /etc/passwd
sudo chmod 640 /etc/shadow
    

Automatische Sicherheits-Updates

Aktiviere unbeaufsichtigte Upgrades um CVEs automatisch zu patchen:

sudo apt-get install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
    

Verifiziere, dass es läuft:

sudo systemctl status unattended-upgrades
sudo grep -r "^Unattended-Upgrade::Automatic-Reboot:" /etc/apt/apt.conf.d/
    

Kernel-Parameter Audit

Härtung des Kernel-Verhaltens zur Risikominderung bei häufigen Exploits:

# IP-Forwarding deaktivieren (außer für Router)
net.ipv4.ip_forward = 0

# SYN Cookies aktivieren (Schutz vor SYN Flood)
net.ipv4.tcp_syncookies = 1

# ICMP Redirects ignorieren (MITM-Prävention)
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

# Verdächtige Pakete loggen
net.ipv4.conf.all.log_martians = 1

# ICMP Ping-Anfragen ignorieren (optional, bricht einige Monitoring)
# net.ipv4.icmp_echo_ignore_all = 1
    

Änderungen anwenden:

sudo sysctl -p
    

Schicht 2: SSH-Härtung

SSH ist der primäre Remote-Zugriffsmechanismus. Fehlkonfiguration hier ist der schnellste Weg zur Kompromittierung.

SSH Schlüsselbasierte Authentifizierung

Generiere einen starken ED25519-Schlüssel (bevorzugt gegenüber RSA für neue Schlüssel):

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod -C "deploy@server"
    

Kopiere den öffentlichen Schlüssel zum Server:

ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub deploy@server.example.com
    

Passwortauthentifizierung deaktivieren

Sobald Schlüssel vorhanden sind, deaktiviere Passwort-Login:

Port 22
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Stärkere Algorithmen
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com

# Begrenzte gleichzeitige Sessions
MaxSessions 2
MaxStartups 10:30:100

# Client-Keepalive
ClientAliveInterval 300
ClientAliveCountMax 2

# X11, Tunneling, Agent-Forwarding deaktivieren (außer wenn nötig)
X11Forwarding no
AllowAgentForwarding no
PermitTunnel no

# Beschränkung auf spezifische Benutzer
AllowUsers deploy
    

Validierung und Reload:

sudo sshd -t
sudo systemctl reload ssh
    

Port-Änderungen (Optionale Defense-in-Depth)

SSH von Port 22 zu verschieben reduziert automatisierte Scanner-Geräusche (keine Sicherheitsmaßnahme, nur operative Hygiene):

Port 2222
    

Aktualisiere deine lokale SSH-Konfiguration:

Host server.example.com
Port 2222
User deploy
IdentityFile ~/.ssh/id_ed25519_prod
    

Schicht 3: Firewall-Konfiguration

Eine Firewall blockiert unerwünschten eingehenden Traffic und optionally beschränkt ausgehenden.

UFW (Uncomplicated Firewall)

UFW ist ein Frontend für iptables, das einfacher zu verwalten ist:

sudo apt-get install -y ufw

# Setze Standard-Richtlinien: Eingehend ablehnen, Ausgehend erlauben
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Erlaube SSH (essentiell um dich nicht auszusperren)
sudo ufw allow 22/tcp
# Oder wenn du einen benutzerdefinierten Port nutzt:
# sudo ufw allow 2222/tcp

# Erlaube HTTP/HTTPS für Web-Dienst (wenn läuft)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Firewall aktivieren
sudo ufw enable

# Verifizieren
sudo ufw status
    

Ratenbegrenzung

Begrenze wiederholte Verbindungen von derselben IP um Brute Force zu verhindern:

sudo ufw limit 22/tcp
    

Dies erlaubt max 6 Verbindungen pro 30 Sekunden von einer einzelnen IP.

Logging

Aktiviere Firewall-Logging um verworfene Pakete zu erfassen:

sudo ufw logging on
sudo ufw logging high
    

Logs anschauen:

sudo tail -f /var/log/ufw.log
    

Schicht 4: Eindringlingsprävention mit Fail2ban

Auch mit Schlüssel-Auth werden Angreifer schwache Passwörter ausprobieren. Fail2ban blockiert IPs automatisch nach wiederholten fehlgeschlagenen Login-Versuchen.

Installation & Konfiguration

sudo apt-get install -y fail2ban

# Starten und aktivieren
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
    

Erstelle einen lokalen Konfigurationsoverride (editiere nicht /etc/fail2ban/jail.conf):

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5

# IP-Whitelist (vertrauenswürdiges Netzwerk, Büro, VPN)
ignoreip = 127.0.0.1/8 192.168.1.0/24 10.0.0.0/8

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

Lade Fail2ban neu:

sudo systemctl reload fail2ban
    

Überwache aktive Banns

sudo fail2ban-client status
sudo fail2ban-client status sshd
    

Entsperre eine IP wenn nötig:

sudo fail2ban-client set sshd unbanip 192.0.2.100
    

Schicht 5: Monitoring & Logging

Logs sind nur nützlich wenn zentralisiert, rotiert und überwacht. Ein einzelner Server der seine Festplatte mit Logs füllt ist ein Denial-of-Service-Szenario.

Log-Rotation

Konfiguriere logrotate um alte Logs zu komprimieren:

/var/log/syslog
/var/log/auth.log
/var/log/ufw.log
{
daily
rotate 14
compress
delaycompress
notifempty
create 0640 syslog adm
sharedscripts
postrotate
/lib/systemd/systemd-logind-control reload-config > /dev/null 2>&1 || true
endscript
}
    

Journal-Limits

Systemd Journal kann groß werden. Begrenzen Sie seine Größe:

SystemMaxUse=500M
SystemMaxFileSize=100M
MaxRetentionSec=30day
    

Neu laden:

sudo systemctl restart systemd-journald
    

Zu überwachende Schlüssel-Logs

• /var/log/auth.log — SSH-Anmeldungen, Sudo-Nutzung, Fail2ban-Blöcke
• /var/log/syslog — System-Events, Service-Neustarts
• /var/log/ufw.log — Firewall verworfene Pakete
• journalctl -u SERVICE — Spezifische Service-Logs

Schicht 6: Backup & Recovery

Keine Server-Härtung hilft wenn du nicht aus einer Kompromittierung oder einem Datenverlust wiederherstellen kannst. Backups sind nicht optional.

Backup-Strategie: 3-2-1 Regel

• 3 Kopien: Original + 2 Backups
• 2 Medientypen: Lokale Festplatte + Cloud
• 1 Standort: Mindestens ein Backup außerhalb des Standorts

Lokales automatisiertes Backup

Nutze rsync für effiziente tägliche Backups auf eine sekundäre Festplatte:

#!/bin/bash
BACKUP_DIR="/backup"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# Sichere kritische Verzeichnisse
rsync -av --delete \
--exclude='/proc' \
--exclude='/sys' \
--exclude='/dev' \
--exclude='/tmp' \
--exclude='/var/tmp' \
--exclude='/var/log' \
/ "$BACKUP_DIR/backup_$TIMESTAMP/"

# Behalte nur die letzten 7 täglichen Backups
find $BACKUP_DIR -maxdepth 1 -type d -name "backup_*" -mtime +7 -exec rm -rf {} \;
    

Offsite-Backup (Cloud)

Für kleinere Daten, nutze S3 oder äquivalent:

sudo apt-get install -y awscli

# AWS Anmeldedaten konfigurieren
aws configure

# Sichere zu S3 (Beispiel)
aws s3 sync /home/deploy/app s3://my-backups/app/ --delete
    

Teste deine Wiederherstellung

Ein Backup das du nicht wiederherstellen kannst ist nutzlos. Teste regelmäßig:

# Stelle eine einzelne Datei wieder her
rsync -av /backup/backup_20250610_120000/etc/passwd /tmp/restored_passwd

# Verifiziere
cat /tmp/restored_passwd
    

Best Practices

1. Defense in Depth

Keine einzelne Schicht ist ausreichend. SSH-Schlüssel allein stoppen nicht einen kompromittierten Benutzeraccount. Firewalls allein stoppen keine Application-Exploits. Überlagere Schutzmaßnahmen.

2. Minimale Exposition

Exponiere nur was notwendig ist. Wenn ein Dienst nicht nötig ist, deinstalliere ihn.

sudo systemctl disable apache2
sudo apt-get remove apache2
    

3. Änderungserkennung

Erkenne unbefugte Änderungen mit AIDE (Advanced Intrusion Detection Environment):

sudo apt-get install -y aide aide-common
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Prüfe auf Änderungen
sudo aide --check
    

4. Benutzer-Verantwortlichkeit

Überwache Sudo-Nutzung und SSH-Anmeldungen. Wisse wer sich wann angemeldet hat:

sudo grep "sudo:" /var/log/auth.log | tail -5
sudo lastlog
    

5. Halte Geheimnisse separat

Committe niemals Passwörter, API-Schlüssel oder Zertifikate zur Versionskontrolle. Nutze Umgebungsvariablen oder Secret-Management-Tools.

export DB_PASSWORD="$(cat /root/.db_password)"
# Oder nutze einen Secret Manager
export DB_PASSWORD="$(vault read -field=password secret/db)"
    

Gelernte Lektionen

Technische Erkenntnisse

• SSH-Schlüssel sind nicht ausreichend: Schlüssel-basierte Auth ist stärker als Passwörter, verhindert aber nicht dass kompromittierte Accounts normal SSH'en. Überlagere mit Ratenbegrenzung und Firewall-Regeln.
• Logs sind Sicherheit: Logs sind nicht nur zum Debuggen; sie sind dein Audit-Trail. Verliere sie und du verlierst Verantwortlichkeit.
• Backups sind nicht Backups bis getestet: Ein Backup das nicht wiederhergestellt werden kann ist wertlos. Teste vierteljährlich.
• Updates brechen Dinge gelegentlich: Automatisierte Updates sind essentiell, aber teste sie zuerst in Staging auf kritischen Systemen.

Operative Erkenntnisse

• Dokumentiere deine Änderungen: Härtung wird komplex. Dokumentiere warum jede Einstellung gewählt wurde sodass zukünftiger du versteht.
• Automatisiere alles: Manuelle Härtungsschritte erzeugen Inkonsistenzen. Nutze Ansible, Puppet, oder Configuration Management.
• Firewall-Regeln treiben auseinander: Ad-hoc hinzugefügte Regeln werden unverwaltbar. Halte sie in Versionskontrolle.
• Monitoring ohne Alerting ist Theater: Schöne Dashboards sind nutzlos wenn niemand sie liest. Richte Alerts auf die dich um 3 Uhr morgens wecken wenn nötig.

Open-Source-Projekte

Dieser Guide basiert auf branchenüblichen Open-Source-Tools:

• Linux — Freier und quelloffener Kernel und OS
• OpenSSH — Sichere Remote-Shell und Dateiübertragung
• Unattended Upgrades — Automatische Sicherheits-Updates
• UFW (Uncomplicated Firewall) — Einfach zu verwendender iptables Frontend
• Fail2ban — Dynamische Firewall-basierte Eindringlingsprävention
• logrotate — Log-Datei Rotation und Kompression
• AIDE — Advanced Intrusion Detection Environment für Datei-Integrität
• rsync — Schnelle inkrementelle Backup-Utility