Linux-Rootserver Absicherung: DDoS-Mitigation, nftables und Server-Hardening

Dedizierte Rootserver für Gaming-Netzwerke stellen attraktive Angriffsziele dar. Neben volumetrischen DDoS-Angriffen (Distributed Denial of Service) auf Netzwerkebene (SYN-Floods, UDP-Amplification) versuchen Angreifer regelmäßig, Backend-Ports von Minecraft-Instanzen direkt anzusprechen, um BungeeCord-Forwarding auszuhebeln oder administrative Schnittstellen (RCON, SSH) per Brute-Force zu kompromittieren.

Dieser Leitfaden beschreibt eine praxiserprobte Sicherheitsarchitektur für Debian 12 und Ubuntu 24.04 LTS, von der Kernel-Härtung über zustandsbehaftete nftables-Regelsätze bis zur Proxy-Isolation.

1. Grundlegendes Betriebssystem-Hardening (SSH & PAM)

Der administrative SSH-Zugang muss kompromisslos abgesichert werden. Passwort-basierte Authentifizierung und direkter Root-Login werden systemweit unterbunden:

# /etc/ssh/sshd_config.d/99-hardened.conf
Port 2222
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
AuthenticationMethods publickey
X11Forwarding no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Aktivieren Sie die Konfiguration nach einem Syntax-Test mit:

sshd -t && systemctl reload sshd

Ergänzend empfiehlt sich der Einsatz von Hardware-Sicherheitsschlüsseln (FIDO2 / WebAuthn) über moderne OpenSSH-Schlüsselpaare vom Typ ed25519-sk, um ein Entwenden privater Schlüsseldateien wirksam zu neutralisieren.

2. Linux-Kernel-Netzwerk-Tuning via sysctl

Der Standard-Netzwerk-Stack des Linux-Kernels ist auf Allzweck-Server optimiert und kapituliert rasch bei SYN-Floods. Mit folgenden Parametern in /etc/sysctl.d/99-security.conf härten Sie den TCP/IP-Stack:

# /etc/sysctl.d/99-security.conf
# Schutz vor SYN-Floods ohne Speichererschöpfung
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2

# IP-Spoofing und Source-Routing abwehren
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# ICMP-Smurf-Angriffe und Redirects unterbinden
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Time-Wait-Sockets zügig recyceln
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

Wenden Sie die Einstellungen ohne Neustart an:

sysctl --system

3. Hochperformante Firewall-Konfiguration mit nftables

nftables ersetzt die veraltete iptables-Architektur. Es kompiliert Paketfilterregeln in kompakten Kernel-Bytecode und minimiert Kontextwechsel drastisch. Folgendes Regelwerk isoliert den Server vollständig:

# /etc/nftables.conf
flush ruleset

table inet filter {
    # Ratelimit für neue Verbindungen
    set rate_limit_v4 {
        type ipv4_addr
        flags dynamic
        timeout 1m
        size 65535
    }

    chain input {
        type filter hook input priority filter; policy drop;

        # Bereits bestehende und verwandte Verbindungen zulassen
        ct state established,related accept

        # Ungültige Pakete sofort verwerfen
        ct state invalid drop

        # Loopback-Schnittstelle vollständig freigeben
        iif "lo" accept

        # ICMP (Ping) kontrolliert erlauben (Echo-Request limitiert)
        ip protocol icmp icmp type echo-request limit rate 5/second accept

        # Geänderter SSH-Port mit Brute-Force-Bremse
        tcp dport 2222 ct state new meter ssh_meter { ip saddr limit rate 6/minute } accept
        tcp dport 2222 drop

        # Minecraft-Proxy (Velocity) nach außen öffnen (z. B. Port 25565)
        tcp dport 25565 accept

        # Alle übrigen Ports bleiben geblockt (Drop by Policy)
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

Aktivieren und prüfen Sie den Regelsatz:

nft -c -f /etc/nftables.conf && systemctl enable --now nftables

4. Backend-Port-Isolation gegen BungeeCord-Bypasses

Ein gravierendes Sicherheitsrisiko in Netzwerken mit Velocity oder BungeeCord entsteht, wenn Backend-Server (z. B. Spigot/Paper auf Port 25566, 25567) an 0.0.0.0 gebunden sind. Angreifer verbinden sich dann unter Umgehung des Proxys direkt mit dem Backend-Port und können beliebige Benutzernamen ohne Authentifizierung übernehmen (IP-Forwarding-Spoofing).

Bindung an das Loopback-Interface

Konfigurieren Sie in allen server.properties der Backend-Instanzen zwingend:

server-ip=127.0.0.1
server-port=25566

Befinden sich Proxy und Backend auf separaten physischen Maschinen, binden Sie die Backend-Dienste ausschließlich an private IP-Adressen innerhalb eines verschlüsselten WireGuard-Netzwerks (10.8.0.x) und blockieren Sie Port 25566 auf der öffentlichen Netzwerkschnittstelle via nftables.

5. Reverse-Proxy-Architektur mit TCPShield

Bei volumetrischen Angriffen (z. B. DNS-Amplification mit 100 Gbit/s) ist die Netzwerkanbindung einzelner Rootserver überfordert. Ein Anycast-basierter Dienst wie TCPShield oder HAProxy schirmt die physische IP-Adresse vollständig ab.

1. DNS-Verwaltung: Der SRV- und A-Record Ihrer Domain (kirocloud.de) zeigt ausschließlich auf die Anycast-IPs von TCPShield.
2. Paketprüfung: Das globale Netzwerk von TCPShield terminiert den TCP-Handshake, blockiert illegitime SYN-Stürme und prüft das Minecraft-Handshake-Paket.
3. Absicherung des Backends: Konfigurieren Sie die Firewall Ihres Rootservers so, dass eingehende Verbindungen auf Port 25565 ausschließlich von den dokumentierten IP-Ranges von TCPShield akzeptiert werden:

# Ausschnitt für nftables: Nur TCPShield-Subnetze zulassen
set tcpshield_ips {
    type ipv4_addr
    flags interval
    elements = { 172.65.200.0/24, 172.65.201.0/24 }
}

tcp dport 25565 ip saddr @tcpshield_ips accept
tcp dport 25565 drop

Damit ist Ihre originäre Server-IP für Angreifer uneinsehbar und der Server gegen Bandbreitenüberlastung geschützt.