Best Practices zur Serverabsicherung für dedizierte Server

Fang mit der Angriffsfläche-Bestandsaufnahme an

Bevor du irgendwas änderst, solltest du wissen, was gerade läuft:

# All listening ports

ss -tlnp

# Running services

systemctl list-units --type=service --state=running

# SUID/SGID files (privilege escalation candidates)

find / -perm /6000 -type f 2>/dev/null

# World-writable directories

find / -xdev -type d -perm -0002 2>/dev/null

Dokumentiere, wofür jeder offene Port und jeder laufende Dienst da ist. Wenn du nicht sofort sagen kannst, warum dieser Port offen ist, solltest du das als Erstes checken.

SSH-Sicherung

SSH ist der wichtigste Admin-Zugang auf Linux-Servern – und das Hauptziel für Brute-Force-Angriffe. Wenn du SSH sicher machst, schützt du dich vor dem häufigsten Angriffsweg, noch bevor du irgendwelche anderen Einstellungen änderst.

Bearbeite die Datei /etc/ssh/sshd_config und mach diese Einstellungen:

# Disable password authentication entirely

PasswordAuthentication no

ChallengeResponseAuthentication no

# Disable root login over SSH

PermitRootLogin no

# Use a non-standard port (reduces automated scan noise)

Port 2222

# Limit SSH to specific users

AllowUsers deploy_user admin_user

# Reduce authentication timeout window

LoginGraceTime 30

MaxAuthTries 3

# Disable legacy protocol features

Protocol 2

X11Forwarding no

AllowAgentForwarding no

AllowTcpForwarding no

# Keep-alive settings to terminate idle sessions

ClientAliveInterval 300

ClientAliveCountMax 2

Sobald die Passwortauthentifizierung deaktiviert ist, musst du dich mit einem Schlüssel authentifizieren. Mach dir mit ssh-keygen -t ed25519 Schlüssel auf deinem Rechner und kopier den öffentlichen Schlüssel in ~/.ssh/authorized_keys auf dem Server, bevor du die Passwörter deaktivierst.

Mach die Änderungen: systemctl restart sshd. Check, ob du dich noch mit dem Schlüssel verbinden kannst, bevor du deine aktuelle Sitzung beendest.

Die NIST Special Publication 800-123 gibt dir umfassende Tipps zur SSH-Konfiguration in Produktionsumgebungen, einschließlich wichtiger Managementpraktiken.

Firewall-Konfiguration mit nftables

Moderne Linux-Distributionen nutzen nftables als bevorzugtes Firewall-Framework. Ein minimaler Regelsatz für einen Webserver:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {

    chain input {

        type filter hook input priority 0; policy drop;

        # Accept established/related connections

        ct state established,related accept

        # Accept loopback

        iif lo accept

        # Accept ICMP (ping) - limit rate

        icmp type echo-request limit rate 5/second accept

        icmpv6 type echo-request limit rate 5/second accept

        # SSH on custom port

        tcp dport 2222 ct state new limit rate 10/minute accept

        # HTTP and HTTPS

        tcp dport { 80, 443 } accept

        # Log and drop everything else

        log prefix "Dropped: " drop

    }

    chain forward {

        type filter hook forward priority 0; policy drop;

    }

    chain output {

        type filter hook output priority 0; policy accept;

    }

}

Speichere die Datei unter /etc/nftables.conf und aktiviere sie: systemctl enable –now nftables. Die Standardrichtlinie ist „drop on inbound“ – nur ausdrücklich erlaubter Datenverkehr kommt durch.

Bei Servern mit cPanel cPanel seine eigenen Firewall-Regeln. Nutzt ConfigServer Security & Firewall (CSF), das sich in WHM einbinden lässt und eine Benutzeroberfläche für die Verwaltung der Regeln bietet, ohne cPanelbenötigten Ports zu überschreiben.

Benutzerkontoverwaltung

Jedes Benutzerkonto kann ein potenzieller Angriffsvektor sein. Achte besonders auf Folgendes:

Deaktiviere nicht genutzte Systemkonten: Schau in /etc/passwd nach Konten mit Login-Shells, die keine haben sollten. Setz ihre Shell auf /sbin/nologin:

usermod -s /sbin/nologin ungenutztes_Konto

Entferne unnötige sudo-Rechte: visudo, um /etc/sudoers zu überprüfen. Jede Zeile, die NOPASSWD sudo erlaubt, ist ein Weg, um Rechte zu erweitern, wenn das Konto gehackt wird. Verlang ein Passwort für alle sudo-Operationen in der Produktion.

Verwende rollenbasierte Benutzerkonten: Anwendungsdienste sollten als eigener dedizierter Systembenutzer mit minimalen Berechtigungen laufen. Der Webserver sollte nicht als Root laufen. MySQL sollte nicht als Root laufen. Erstelle anwendungsspezifische Benutzer:

useradd -r -s /sbin/nologin -d /var/www/app appuser

chown -R appuser:appuser /var/www/app

Überprüfe regelmäßig die letzten Anmeldungen: lastlog | grep -v Zeigt niemals Konten an, die zum Anmelden benutzt wurden. Konten, die du in dieser Ausgabe nicht erwartet hast, solltest du genauer anschauen.

Kernel-Härtung über sysctl

Ein paar Kernel-Parameter verringern die Angriffsfläche für Exploits auf Netzwerkebene:

# /etc/sysctl.d/99-hardening.conf

# Disable IP source routing (used in some spoofing attacks)

net.ipv4.conf.all.accept_source_route = 0

net.ipv4.conf.default.accept_source_route = 0

# Disable ICMP redirect acceptance

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

# Enable reverse path filtering (anti-spoofing)

net.ipv4.conf.all.rp_filter = 1

# Disable ping broadcasts

net.ipv4.icmp_echo_ignore_broadcasts = 1

# Log martian packets (packets with impossible source addresses)

net.ipv4.conf.all.log_martians = 1

# Disable IPv6 if not in use

net.ipv6.conf.all.disable_ipv6 = 1

# Kernel pointer hiding

kernel.kptr_restrict = 2

kernel.dmesg_restrict = 1

Mach das mit sysctl -p /etc/sysctl.d/99-hardening.conf.

Dateisystem-Sicherheit

Richte die richtigen Berechtigungen für sensible Verzeichnisse ein:

chmod 750 /root

chmod 644 /etc/passwd

chmod 640 /etc/shadow

chmod 600 /etc/ssh/sshd_config

Mount-Optionen, die das Risiko einer Rechteausweitung verringern:

Bearbeite die Datei /etc/fstab, um noexec, nosuid und nodev zu den Partitionen hinzuzufügen, die keine ausführbaren Dateien haben sollen:

/dev/sdb1 /var/tmp ext4 defaults,noexec,nosuid,nodev 0 2

Überprüfe die Dateiintegrität mit AIDE: AIDE (Advanced Intrusion Detection Environment) erstellt eine Datenbank mit Datei-Prüfsummen und kann dich warnen, wenn sich Dateien unerwartet ändern. Starte es mit „aide –init“ und führe dann „aide –check“ regelmäßig oder über cron aus. Wenn sich System-Binärdateien, Bibliotheken oder Konfigurationsdateien unerwartet ändern, könnte das ein Zeichen für einen Angriff sein.

Software- und Paketverwaltung

Halte deine Pakete auf dem neuesten Stand: Nicht gepatchte Schwachstellen im Kernel, OpenSSL, glibc und anderen Systembibliotheken sind nach schwachen Anmeldedaten der häufigste Weg, um Server zu kompromittieren.

# CentOS/AlmaLinux/Rocky Linux

dnf update --security -y

# Ubuntu/Debian

apt-get upgrade -y

Sicherheitsupdates automatisch machen: Mit dnf-automatic (RHEL-Familie) oder unattended-upgrades (Debian-Familie) kann man so einstellen, dass Sicherheitspatches automatisch installiert werden, während größere Versionsupgrades manuell überprüft werden.

Überprüfe installierte Pakete: Lösche Pakete, die zum Testen installiert und nie wieder entfernt wurden. Jedes installierte Paket ist eine potenzielle Schwachstelle. Mit „rpm -qa“ (RHEL) oder „dpkg -l“ (Debian) kannst du alles aufgelistet bekommen, was installiert ist.

Entferne Entwicklungswerkzeuge von Produktionsservern: Compiler, Debugger und Tools zum Erstellen von Paketen haben auf Produktionsservern nichts zu suchen. Ein Angreifer, der sich eingeschränkten Zugriff verschafft, kann sie nutzen, um Exploit-Code zu kompilieren. Lös gcc, make und ähnliche Tools auf, falls sie vorhanden sind.

Intrusion Detection und Protokollüberwachung

Fail2Ban checkt Logdateien und sperrt IPs, die verdächtig aussehen – wie zum Beispiel wiederholte fehlgeschlagene SSH-Anmeldungen, Nginx und andere Anzeichen von Missbrauch. Fail2Ban kann über den Paketmanager auf allen gängigen Linux-Distributionen installiert werden und funktioniert mit jedem Logdateiformat.

Zentralisierung von Protokollen: Wenn du Protokolle an einen Remote-Syslog-Server schickst, hast du immer noch einen Prüfpfad, selbst wenn der Server gehackt wird und die lokalen Protokolle gelöscht werden. rsyslog unterstützt Remote-Protokollierung von Haus aus. Wenn dein Team schon einen ELK-Stack (Elasticsearch, Logstash, Kibana) oder einen verwalteten Protokollaggregationsdienst nutzt, konfiguriere einfach die rsyslog.conf des Servers so, dass sie an den zentralen Empfänger weiterleitet.

Monarx-Malware-Erkennung: Das Premier Care-Paket von InMotion hat Monarx, eine Malware-Erkennungs-Engine, die Dateien scannt und speziell für Webhosting-Umgebungen entwickelt wurde. Monarx findet Web-Shell-Uploads, bösartige PHP-Injektionen und Kryptowährungs-Miner – die häufigste Malware, die auf Linux-Server im Webhosting abzielt. Es läuft auf Kernel-Ebene, ohne die Leistung wie bei herkömmlichen Antiviren-Lösungen zu beeinträchtigen.

Regelmäßige Audits planen

Die Absicherung bei der Bereitstellung wird mit der Zeit schwächer, wenn sie nicht regelmäßig überprüft wird. Leg einfach einen vierteljährlichen Überprüfungszyklus fest, der Folgendes abdeckt:

• Überprüfe die offenen Ports anhand der aktuellen App-Anforderungen.
• Überprüfe die Benutzerkonten und die SSH-authorized_keys für alle Benutzer.
• Überprüfe die AIDE-Integritätsdatenbank auf unerwartete Dateiänderungen.
• Überprüfe die sudo-Berechtigungen und lösche alle, die nicht mehr gebraucht werden.
• Installiere alle Sicherheitspatches, die nicht automatisch installiert wurden.
• Überprüfe die Fail2Ban- und Firewall-Protokolle auf Änderungen bei den Angriffsmustern.

Die Server mit den besten Sicherheitsbilanzen sind nicht die, die einmal gesichert und dann vergessen wurden. Es sind die, bei denen jemand regelmäßig die Arbeit überprüft.

Weiterführende Literatur: DDoS-Schutzstrategien für dedizierte Infrastruktur | Zero-Trust-Sicherheit auf Bare Metal