
Docker Compose auf dem VPS: Webserver, Datenbank & Reverse Proxy richtig betreiben
Praxisnaher Guide für Docker Compose auf dem VPS: Webserver, Datenbank, Reverse Proxy, TLS, Backups, Updates und Sicherheit richtig planen und betreiben.
Die Bedrohungslage für Linux-Server hat sich in den letzten Jahren dramatisch zugespitzt. Cyberkriminelle nutzen zunehmend automatisierte Tools, um verwundbare Systeme zu identifizieren und innerhalb von Sekunden zu kompromittieren. Ein ungehärteter Server ist im Grunde genommen eine offene Tür, durch die Angreifer ungehindert eindringen können.
Linux Server Hardening umfasst eine Vielzahl von Maßnahmen, die darauf abzielen, die Angriffsfläche des Systems zu minimieren. Dazu gehören das Deaktivieren unnötiger Dienste, die Konfiguration von Firewalls, die Implementierung von Intrusion Detection Systems und die regelmäßige Aktualisierung von Software. Jede dieser Maßnahmen trägt dazu bei, die Sicherheit des Servers zu erhöhen.
Besonders im geschäftlichen Kontext kann ein kompromittierter Server verheerende Folgen haben. Datenverlust, Reputationsschäden und rechtliche Konsequenzen sind nur einige der möglichen Risiken. Daher ist es ratsam, Hardening-Maßnahmen als integralen Bestandteil der IT-Sicherheitsstrategie zu betrachten.
Die gute Nachricht ist, dass Linux von Haus aus über zahlreiche Sicherheitsfunktionen verfügt. Durch gezielte Konfiguration und den Einsatz bewährter Best Practices lässt sich ein hohes Sicherheitsniveau erreichen, ohne die Funktionalität des Servers wesentlich einzuschränken.
Bevor Sie mit der eigentlichen Härtung beginnen, sollten Sie sicherstellen, dass Ihr System auf dem neuesten Stand ist. Veraltete Software enthält häufig bekannte Sicherheitslücken, die von Angreifern ausgenutzt werden. Ein effektives Patch-Management ist daher die Grundlage jeder Sicherheitsstrategie.
Bei Debian-basierten Distributionen wie Ubuntu verwenden Sie den folgenden Befehl, um das System zu aktualisieren:
sudo apt update && sudo apt upgrade -y
sudo apt dist-upgrade -y
sudo reboot
Für RHEL-basierte Systeme wie CentOS oder Rocky Linux lautet der Befehl entsprechend:
sudo dnf update -y
sudo dnf install -y dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
Automatische Updates sind ein zweischneidiges Schwert. Sie bieten zwar einen besseren Schutz vor bekannten Schwachstellen, können aber auch zu Kompatibilitätsproblemen führen. In Produktionsumgebungen empfiehlt es sich oft, Updates zunächst in einer Testumgebung zu validieren, bevor sie auf produktive Systeme ausgerollt werden.
Konfigurieren Sie zusätzlich unattended-upgrades für automatische Sicherheitsupdates auf Ubuntu-Systemen. Damit stellen Sie sicher, dass kritische Patches zeitnah eingespielt werden, auch wenn Sie das System nicht regelmäßig manuell warten.
SSH (Secure Shell) ist der primäre Zugangsweg zu Linux-Servern und gleichzeitig eines der häufigsten Angriffsziele. Brute-Force-Angriffe auf SSH sind an der Tagesordnung und können binnen weniger Stunden Millionen von Passwortkombinationen durchprobieren. Eine grundlegende Härtung von SSH ist daher absolut notwendig.
Die wichtigste Maßnahme ist der Wechsel von Passwort-Authentifizierung auf schlüsselbasierte Authentifizierung. Generieren Sie zunächst ein starkes SSH-Schlüsselpaar auf Ihrem lokalen Computer:
ssh-keygen -t ed25519 -a 100 -C "admin@server"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
Bearbeiten Sie anschließend die SSH-Konfigurationsdatei auf dem Server unter /etc/ssh/sshd_config und deaktivieren Sie die Passwort-Authentifizierung:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers ihr_benutzername
Starten Sie den SSH-Dienst neu, um die Änderungen zu übernehmen. Zusätzlich empfiehlt sich die Implementierung von fail2ban, einem Tool, das wiederholt fehlgeschlagene Anmeldeversuche erkennt und die entsprechenden IP-Adressen temporär sperrt.
Erwägen Sie auch den Wechsel des Standard-Ports von 22 auf einen weniger offensichtlichen Port. Dies bietet zwar keinen echten Schutz, reduziert aber die Anzahl automatisierter Angriffe erheblich und kann die Log-Dateien entlasten.
Eine gut konfigurierte Firewall ist das Rückgrat jeder Server-Sicherheit. Sie kontrolliert den ein- und ausgehenden Netzwerkverkehr und kann unerwünschte Verbindungen effektiv blockieren. Linux bietet verschiedene Firewall-Lösungen, wobei UFW (Uncomplicated Firewall) und iptables die bekanntesten sind.
UFW ist besonders bei Ubuntu-Nutzern beliebt, da es eine vereinfachte Syntax bietet. Aktivieren Sie UFW und konfigurieren Sie grundlegende Regeln:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
Für komplexere Szenarien oder wenn Sie maximale Kontrolle benötigen, ist iptables die richtige Wahl. Hier ein Beispiel für eine grundlegende iptables-Konfiguration:
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -j DROP
Speichern Sie die iptables-Regeln dauerhaft mit iptables-persistent oder dem jeweiligen Paket Ihrer Distribution. Andernfalls gehen die Regeln nach einem Neustart verloren. Die folgende Tabelle zeigt die wichtigsten Firewall-Befehle im Vergleich:
| Aktion | UFW | iptables |
|---|---|---|
| Status anzeigen | ufw status | iptables -L |
| Port erlauben | ufw allow 80 | iptables -A INPUT -p tcp --dport 80 -j ACCEPT |
| Port ablehnen | ufw deny 3306 | iptables -A INPUT -p tcp --dport 3306 -j DROP |
| Regeln zurücksetzen | ufw reset | iptables -F |
Testen Sie Ihre Firewall-Konfiguration stets in einer separaten Sitzung, bevor Sie sich vom Server abmelden. Eine fehlerhafte Konfiguration kann Sie komplett aussperren und einen physischen Zugriff auf den Server erforderlich machen.
Jeder laufende Dienst auf einem Server stellt potenziell eine Sicherheitslücke dar. Das Prinzip der minimalen Angriffsfläche besagt, dass nur die Dienste aktiv sein sollten, die tatsächlich benötigt werden. Überprüfen Sie daher regelmäßig, welche Services auf Ihrem System laufen.
Listen Sie alle aktiven Dienste auf, um einen Überblick zu erhalten:
systemctl list-units --type=service --state=active
ss -tulpn
Deaktivieren Sie nicht benötigte Dienste mit den folgenden Befehlen:
sudo systemctl stop dienstname
sudo systemctl disable dienstname
sudo systemctl mask dienstname
Besondere Aufmerksamkeit sollten Sie diesen Diensten widmen, die häufig standardmäßig aktiviert sind, aber selten benötigt werden:
| Dienst | Funktion | Empfehlung |
|---|---|---|
| telnet | Unsicherer Remote-Zugang | Sofort deaktivieren |
| ftp | Unsicherer Dateitransfer | Durch SFTP ersetzen |
| rsh/rlogin | Veraltete Remote-Dienste | Deaktivieren |
| avahi-daemon | mDNS-Service | Deaktivieren, wenn nicht benötigt |
| bluetooth | Bluetooth-Support | Auf Servern deaktivieren |
Prüfen Sie auch offene Ports, die nicht durch eine Firewall-Regel abgedeckt sind. Der Befehl ss -tulpn zeigt Ihnen alle aktiven Netzwerkverbindungen und die zugehörigen Prozesse. So können Sie unerwünschte Listener identifizieren und schließen.
Denken Sie daran, dass die Deaktivierung von Diensten Auswirkungen auf abhängige Anwendungen haben kann. Testen Sie Änderungen daher in einer sicheren Umgebung, bevor Sie sie produktiv einsetzen.
Selbst die beste Härtung kann nicht garantieren, dass ein Server niemals kompromittiert wird. Daher ist es wichtig, ein zuverlässiges System zur Erkennung von Eindringlingen und zur Überwachung der Systemaktivitäten zu implementieren. So können Sie im Ernstfall schnell reagieren.
AIDE (Advanced Intrusion Detection Environment) ist ein bewährtes Tool zur Überwachung von Dateiänderungen. Installieren und initialisieren Sie es wie folgt:
sudo apt install aide
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo aide --check
Für die Echtzeit-Erkennung von Angriffen empfiehlt sich fail2ban. Konfigurieren Sie es so, dass es SSH-Anmeldeversuche überwacht und verdächtige IPs blockiert:
sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Erstellen oder bearbeiten Sie /etc/fail2ban/jail.local und fügen Sie eine SSH-Sektion hinzu:
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600
Zentralisieren Sie Ihre Logs, indem Sie einen Syslog-Server einrichten oder Cloud-basierte Lösungen wie Grafana Loki oder Elastic Stack verwenden. So können Sie Anomalien leichter erkennen und forensische Analysen durchführen. Audit-Regeln mit auditd ergänzen das Monitoring und protokollieren sicherheitsrelevante Systemereignisse.
Eine durchdachte Benutzer- und Rechteverwaltung ist ein weiterer Eckpfeiler der Server-Sicherheit. Jeder Benutzer sollte nur die minimal notwendigen Rechte besitzen, um seine Aufgaben zu erfüllen. Dieses Prinzip minimiert die Auswirkungen kompromittierter Konten.
Erstellen Sie für jeden Administrator ein eigenes Konto und vermeiden Sie die gemeinsame Nutzung von root-Zugriffen. Verwenden Sie sudo für administrative Aufgaben und protokollieren Sie alle sudo-Aktivitäten:
sudo useradd -m -s /bin/bash admin1
sudo passwd admin1
sudo usermod -aG sudo admin1
Konfigurieren Sie sudo mit visudo und beschränken Sie die Rechte granular:
Defaults log_input, log_output
Defaults iolog_dir=/var/log/sudo-io/%{user}
admin1 ALL=(ALL) ALL
admin2 ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
Setzen Sie sichere Passwortrichtlinien mit PAM-Modulen um. Die folgende Konfiguration in /etc/pam.d/common-password erzwingt starke Passwörter:
password requisite pam_pwquality.so retry=3 minlen=12 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1
Überprüfen Sie regelmäßig die Liste der Benutzer mit root-Rechten und entfernen Sie nicht mehr benötigte Konten. Auch ungenutzte Systemkonten wie games oder news sollten deaktiviert werden. Setzen Sie zudem Datei-ACLs gezielt ein, um granulare Zugriffsrechte zu vergeben, wo dies erforderlich ist.
Der Linux-Kernel bietet eine Vielzahl von Parametern, die das Sicherheitsverhalten des Systems beeinflussen. Durch gezielte Anpassungen der Sysctl-Einstellungen können Sie die Netzwerksicherheit erhöhen und verschiedene Angriffsvektoren erschweren.
Bearbeiten Sie /etc/sysctl.conf oder erstellen Sie eine neue Datei in /etc/sysctl.d/ mit folgenden empfohlenen Einstellungen:
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.log_martians = 1
Wenden Sie die Änderungen mit sudo sysctl -p an. Diese Einstellungen aktivieren Reverse-Path-Filterung, deaktivieren Quellrouting und schützen vor SYN-Flood-Angriffen.
Für maximale Sicherheit können Sie zusätzlich SELinux oder AppArmor aktivieren. Diese Mandatory Access Control-Systeme schränken die Fähigkeiten von Prozessen ein und verhindern, dass kompromittierte Anwendungen Schaden anrichten. AppArmor ist in Ubuntu standardmäßig enthalten und einfacher zu konfigurieren als SELinux.
Überwachen Sie Kernel-Logs regelmäßig auf verdächtige Aktivitäten. Das Kommando dmesg --level=err,warn zeigt Ihnen kritische Kernel-Meldungen an, die auf Sicherheitsprobleme hinweisen können.
Manuelle Härtung kann zeitaufwändig und fehleranfällig sein. Glücklicherweise gibt es eine Reihe bewährter Tools und Frameworks, die den Prozess automatisieren und standardisieren. Diese Tools helfen dabei, konsistente Sicherheitskonfigurationen über mehrere Server hinweg zu gewährleisten.
Lynis ist eines der umfassendsten Security-Auditing-Tools für Linux. Es führt eine detaillierte Analyse des Systems durch und gibt konkrete Empfehlungen:
sudo apt install lynis
sudo lynis audit system
Das CIS Benchmarks-Framework bietet standardisierte Sicherheitsrichtlinien, die regelmäßig aktualisiert werden. Diese Benchmarks decken eine Vielzahl von Aspekten ab, von der Benutzerverwaltung bis hin zur Netzwerkkonfiguration. Viele Compliance-Frameworks wie PCI-DSS oder HIPAA bauen auf diesen Empfehlungen auf.
Für die automatisierte Konfigurationsverwaltung haben sich Ansible, Puppet und Chef etabliert. Mit diesen Tools können Sie Härtungskonfigurationen als Code definieren und auf beliebig vielen Servern ausrollen. Hier ein Ansible-Beispiel für die SSH-Härtung:
- name: SSH hardening
lineinfile:
path: /etc/ssh/sshd_config
regexp: "{{ item.regexp }}"
line: "{{ item.line }}"
loop:
- { regexp: '^PermitRootLogin', line: 'PermitRootLogin no' }
- { regexp: '^PasswordAuthentication', line: 'PasswordAuthentication no' }
- { regexp: '^X11Forwarding', line: 'X11Forwarding no' }
notify: restart sshd
Kommerzielle Lösungen wie Tenable Nessus oder Qualys bieten umfassende Schwachstellenscans und Compliance-Checks. Diese Tools sind besonders in größeren Umgebungen sinnvoll, in denen manuelle Audits nicht mehr praktikabel sind.
Keine Sicherheitsstrategie ist vollständig ohne ein durchdachtes Backup-Konzept. Selbst der am besten gehärtete Server kann durch Hardwaredefekte, menschliches Versagen oder gezielte Angriffe kompromittiert werden. Regelmäßige Backups sind Ihre letzte Verteidigungslinie.
Die 3-2-1-Backup-Regel hat sich als Industriestandard etabliert: Bewahren Sie drei Kopien Ihrer Daten auf, auf zwei verschiedenen Medientypen, mit mindestens einer Kopie an einem externen Standort. Diese Strategie schützt vor den meisten Ausfallszenarien.
Für Linux-Server stehen verschiedene Backup-Tools zur Verfügung. BorgBackup ist eine moderne, deduplizierende Backup-Lösung mit Verschlüsselung:
borg init --encryption=repokey /backup/repository
borg create /backup/repository::montag-$(date +%Y-%m-%d) /home /etc /var/www
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /backup/repository
Automatisieren Sie Ihre Backups mit Cron oder systemd-Timern. Testen Sie regelmäßig die Wiederherstellung, um sicherzustellen, dass Ihre Backups tatsächlich funktionieren. Ein nicht getestetes Backup ist im Ernstfall wertlos.
Cloud-basierte Backup-Lösungen wie AWS S3 Glacier, Backblaze B2 oder Hetzner Storage Box bieten geografische Redundanz zu moderaten Kosten. Verschlüsseln Sie Ihre Backups stets, sowohl während der Übertragung als auch im Ruhezustand. Speichern Sie die Verschlüsselungsschlüssel getrennt von den Backup-Daten, um einen gleichzeitigen Verlust zu verhindern.
Die einmalige Implementierung von Sicherheitsmaßnahmen reicht nicht aus. Bedrohungen entwickeln sich ständig weiter, neue Schwachstellen werden täglich entdeckt. Daher ist kontinuierliche Überwachung und regelmäßige Aktualisierung der Sicherheitsmaßnahmen unerlässlich.
Implementieren Sie ein Security Information and Event Management (SIEM)-System, um Logs zentral zu sammeln und auszuwerten. Open-Source-Lösungen wie Wazuh bieten umfassende Funktionen zur Bedrohungserkennung und Compliance-Überwachung.
Planen Sie regelmäßige Sicherheitsaudits ein, mindestens quartalsweise. Überprüfen Sie dabei nicht nur die technischen Maßnahmen, sondern auch die organisatorischen Prozesse. Werden Updates zeitnah eingespielt? Werden neue Benutzer nach dem Prinzip der geringsten Rechte angelegt? Werden ausgeschiedene Mitarbeiter zeitnah aus dem System entfernt?
Halten Sie sich über aktuelle Sicherheitshinweise auf dem Laufenden. Das CERT-Bund, das Bundesamt für Sicherheit in der Informationstechnik (BSI) und Mailinglisten wie full-disclosure bieten wertvolle Informationen über neue Bedrohungen. Abonnieren Sie zudem die Security-Announcements Ihrer Distribution.
Dokumentieren Sie alle Sicherheitsmaßnahmen und -vorfälle in einem Security-Information-Register. Diese Dokumentation hilft nicht nur bei Audits, sondern auch dabei, aus Vorfällen zu lernen und die Sicherheitsstrategie kontinuierlich zu verbessern. Compliance mit Standards wie ISO 27001, BSI-Grundschutz oder CIS Controls erfordert eine lückenlose Dokumentation aller relevanten Sicherheitsprozesse.
Die Bedrohungslage für Linux-Server hat sich in den letzten Jahren dramatisch zugespitzt. Automatisierte Scanner prüfen innerhalb von Sekunden nach Veröffentlichung einer neuen SSH-Instanz, ob bekannte Schwachstellen ausnutzbar sind. Botnetze wie Mirai-Varianten, Cryptominer und Ransomware-Akteure nutzen Schwachstellen in CVEs, die teilweise nur Stunden alt sind, gezielt aus. Laut aktuellen Berichten entfallen über 70 % der exponierten Webserver auf Linux, was die Plattform zum bevorzugten Ziel macht.
Eine durchdachte Security-Baseline reduziert die Angriffsfläche nachweislich um den Faktor 10 bis 100. Das BSI, das NIST (CIS Benchmarks) und die ENISA empfehlen in ihren aktuellen Leitfäden einen defense-in-depth-Ansatz, der auf mehreren unabhängigen Schichten aufbaut: Minimale Installation, gehärtete Konfiguration, kontinuierliches Monitoring und automatisierte Compliance-Prüfungen.
Für 2026 kommt erschwerend hinzu, dass KI-gestützte Angriffs-Tools Schwachstellen in Echtzeit analysieren und ausnutzen können. Klassische "Patchen am Monatsende"-Strategien sind damit obsolet. Server müssen bereits im Auslieferungszustand über automatisierte Härtungs-Profile (z. B. via Ansible, Cloud-Init oder Image Bake) abgesichert werden, sodass keine Klartext-Fenster im Deployment-Zyklus entstehen.
| Bedrohungsvektor | Häufigkeit 2025 | Erforderliche Härtung |
|---|---|---|
| SSH-Brute-Force | Sehr hoch | Key-only, Fail2ban, Port-Knock |
| Log4j/Log4Shell-Klasse | Mittel | SCA, EOL-Software aussortieren |
| Kernel-Exploits (Dirty Pipe, etc.) | Mittel | Live-Patching, minimales Kernel-Modulset |
| Container-Escape | Hoch | User-Namespaces, seccomp, AppArmor |
| Supply-Chain (apt/rpm) | Steigend | Reproducible Builds, sigstore/cosign |
SSH ist der mit Abstand am häufigsten angegriffene Dienst auf Linux-Servern. Die Standardkonfiguration von OpenSSH ist zwar funktional, aber für den produktiven Einsatz im Internet ungeeignet. Eine gehärtete Konfiguration beginnt mit der Deaktivierung von Passwort-Logins und der Erzwingung von ed25519-Schlüsseln mit hoher Entropie.
Zusätzlich sollte der SSH-Dienst auf einen nicht-standardisierten Port verlegt werden. Auch wenn dies "Security through Obscurity" ist, reduziert es die Anzahl der automatisierten Login-Versuche um bis zu 99 %. Wichtiger ist jedoch die Konfiguration von MaxAuthTries, LoginGraceTime und MaxSessions, um Ressourcen- und DoS-Angriffe zu mitigieren.
Moderne SSH-Härtung umfasst 2026 auch die Integration von FIDO2/Hardware-Tokens (z. B. YubiKey) via [email protected]. Diese Methode ist resistent gegen Phishing und bietet kryptographisch starke Authentifizierung. Ergänzend sollten SSH-Certificates statt statischer authorized_keys-Dateien genutzt werden, was das Lifecycle-Management in größeren Umgebungen drastisch vereinfacht.
# /etc/ssh/sshd_config.d/00-hardening.conf
Protocol 2
Port 51222
AddressFamily inet
PermitRootLogin no
MaxAuthTries 3
MaxSessions 2
LoginGraceTime 30
PermitEmptyPasswords no
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding local
PermitUserEnvironment no
ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 30
AllowGroups sshusers
KexAlgorithms [email protected],[email protected]
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]
Subsystem sftp internal-sftp
Während iptables jahrelang der De-facto-Standard war, setzen aktuelle Distributionen wie Debian 12+, Ubuntu 24.04 LTS, RHEL 9 und Fedora 41+ auf nftables als Nachfolger. nftables bietet eine vereinheitlichte Syntax, bessere Performance durch Set-basierte Verarbeitung und native Unterstützung für moderne Protokolle wie QUIC oder WireGuard.
Eine sichere Default-Deny-Policy ist die Grundlage jeder Härtung. Eingehender Traffic sollte standardmäßig verworfen werden, explizite Freigaben erfolgen ausschließlich für notwendige Dienste. Besonderes Augenmerk verdient ausgehender Traffic: Cryptominer und Backdoors kommunizieren häufig über Port 443 zu vermeintlich legitimen Domains. Eine Whitelist bekannter Update-Server reduziert dieses Risiko erheblich.
WireGuard als VPN-Lösung ersetzt zunehmend IPsec und OpenVPN, da es mit 4.000 Zeilen Code (vs. 600.000 bei OpenVPN) eine minimalere Angriffsoberfläche bietet. Die Konfiguration erfolgt über wg-quick oder wg-dynamic und ist in nftables-Regeln einfach zu integrieren. Für Management-Zugriffe empfiehlt sich der Aufbau eines WireGuard-Tunnels, der den öffentlichen SSH-Port komplett vom Internet abschirmt.
# /etc/nftables.conf
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
ct state invalid drop
iif lo accept
ip protocol icmp icmp type { echo-request, echo-reply } limit rate 4/second accept
ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert } accept
udp dport 51222 ip saddr @mgmt_v4 accept comment "SSH"
tcp dport { 80, 443 } accept comment "Web"
log prefix "nftables-drop: " flags all counter drop
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
oifname "eth0" ip daddr @blocked_domains counter drop
}
}
set mgmt_v4 {
type ipv4_addr
flags interval
elements = { 10.0.0.0/8, 192.168.0.0/16 }
}
Das root-Konto sollte niemals direkt verwendet werden. Stattdessen erfolgt privilegierter Zugriff ausschließlich über einen dedizierten administrativen Account mit sudo-Rechten, der per SSH-Key und idealerweise 2FA authentifiziert wird. Die sudo-Konfiguration sollte über /etc/sudoers.d/-Drop-In-Dateien versioniert und nicht direkt in der Hauptdatei gepflegt werden.
Jeder Dienst erhält einen eigenen Systembenutzer mit /sbin/nologin als Login-Shell. Dienste wie nginx, postgres oder redis sollten unter keinen Umständen als root laufen. Moderne Distributionen setzen dies bereits per Default um, ältere Installationen müssen manuell nachgehärtet werden. Capabilities (z. B. CAP_NET_BIND_SERVICE) erlauben es, nur die minimal nötigen Privilegien zu gewähren, statt vollständige root-Rechte zu vergeben.
Für sensible Aktionen empfiehlt sich die Integration von sudo mit Logging nach journald oder einem SIEM. Die Aktivierung von log_input, log_output und compress_io in der sudoers-Datei ermöglicht eine vollständige Audit-Nachvollziehbarkeit, ohne das Passwort im Klartext zu speichern.
# /etc/sudoers.d/01-admin
Defaults log_input, log_output
Defaults compress_io
Defaults !visiblepw
Defaults always_set_home
Defaults env_reset
Defaults secure_path = "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults timestamp_timeout=5
Defaults passwd_timeout=1
%sudo ALL=(ALL:ALL) ALL
# Service-User mit eingeschränkten Rechten
www-data ALL=(nginx) NOPASSWD: /usr/sbin/nginx -s reload
backup ALL=(root) NOPASSWD: /usr/bin/restic backup
Der Linux-Kernel bietet eine Vielzahl von Netzwerk- und Sicherheits-Parametern, die in /etc/sysctl.d/ konfiguriert werden. Eine gehärtete sysctl-Konfiguration schützt vor IP-Spoofing, SYN-Floods, Source-Routing-Angriffen und ungewollten ICMP-Redirects. Diese Einstellungen sind Distributions-übergreifend und seit Jahren stabil, werden aber in der Default-Konfiguration vieler Distributionen aus Kompatibilitätsgründen zu lasch ausgeliefert.
Kernel Self-Protection-Projekt (KSPP) und das grsecurity-Patchset haben über die Jahre viele Härtungsoptionen in den Mainline-Kernel gebracht. Dazu zählen kernel.randomize_va_space=2 (ASLR), kernel.dmesg_restrict=1 (verhindert Informationslecks über dmesg) und kernel.kptr_restrict=2 (versteckt Kernel-Zeiger). Auch fs.protected_hardlinks und fs.protected_symlinks sollten aktiviert sein, um TOCTOU-Angriffe zu erschweren.
Für Container-Workloads empfiehlt sich zusätzlich user.max_user_namespaces=0 (oder eine Whitelist via apparmor), um User-Namespace-basierte Container-Escapes zu verhindern. Diese Einstellung muss jedoch mit der genutzten Container-Runtime (Docker, Podman, containerd) abgestimmt werden, da diese intern auf User-Namespaces angewiesen sind.
# /etc/sysctl.d/99-hardening.conf
# IP-Spoofing-Schutz
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# ICMP-Redirects deaktivieren
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# Source-Routing deaktivieren
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
# SYN-Flood-Schutz
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
# Senden/Empfangen von IP-Weiterleitungen deaktivieren
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0
# Kernel-Informationen einschränken
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.randomize_va_space = 2
# Filesystem-Schutz
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
# BPF JIT nur falls benötigt
net.core.bpf_jit_harden = 2
# Magic SysRq stark einschränken
kernel.sysrq = 176
Discretionary Access Control (DAC), das klassische Unix-Rechtesystem mit Owner/Group/Other, reicht für moderne Sicherheitsanforderungen nicht aus. Mandatory Access Control (MAC) ergänzt es um zentrale, vom Administrator definierte Regeln, die auch root einschränken. Die zwei relevanten Implementierungen im Linux-Ökosystem sind SELinux (RHEL, Fedora, CentOS Stream, AlmaLinux, Rocky) und AppArmor (Debian, Ubuntu, SUSE, openSUSE).
SELinux arbeitet mit Type Enforcement und ist hoch granular, aber auch komplex. Die Standard-Policies von RHEL sind mittlerweile so ausgereift, dass die meisten Workloads ohne Anpassungen funktionieren. Im Fehlerfall bieten audit2why und audit2allow wertvolle Diagnosewerkzeuge. Für benutzerdefinierte Anwendungen empfiehlt sich der sepolicy generate-Generator, der ein Grundgerüst für eine eigene Policy erstellt.
AppArmor setzt auf Path-basierte Profile, die leichter zu verstehen und zu schreiben sind als SELinux-Rules. Die Profile liegen in /etc/apparmor.d/ und können im complain- oder enforce-Modus betrieben werden. Für produktive Workloads ist Enforce der richtige Modus, während der Complain-Modus ausschließlich für die initiale Profil-Entwicklung genutzt werden sollte. Distributions wie Ubuntu Server liefern für viele Daemons bereits fertige Profile aus, die nur aktiviert werden müssen.
# AppArmor-Profil für nginx (Auszug)
#include <tunables/global>
profile /usr/sbin/nginx flags=(attach_disconnected) {
#include <abstractions/base>
#include <abstractions/nginx>
capability dac_override,
capability setuid,
capability setgid,
network inet tcp,
network inet6 tcp,
file /etc/nginx/** r,
file /var/log/nginx/** w,
Titel: Linux Server härten – Security-Baseline 2026
I need to create comprehensive German SEO content about Linux server hardening for 2026. Let me think about what topics to cover:
1. Grundlagen & Bedrohungsmodell
2. SSH-Härtung
3. Firewall-Konfiguration
4. Benutzer- und Rechteverwaltung
5. Kernel-Parameter (sysctl)
6. Automatisierte Updates
7. SELinux/AppArmor
8. Audit & Logging
9. Härtungs-Tools (Lynis, CIS-CAT)
10. Checkliste 2026
Let me write this in detailed German.
Docker Compose auf dem VPS: Webserver, Datenbank & Reverse Proxy richtig betreiben
Praxisnaher Guide für Docker Compose auf dem VPS: Webserver, Datenbank, Reverse Proxy, TLS, Backups, Updates und Sicherheit richtig planen und betreiben.