Warum deine Dedicated Servers einfrieren: Die Realität der Unreal Engine Server DDoS Protection

Jeder Multiplayer-Game-Entwickler fürchtet den plötzlichen, unerklärlichen Server-Freeze. Deine Dedicated Instance läuft einwandfrei bei einer stabilen 30 Tick rate, und dann, ohne Vorwarnung, kommt die gesamte Simulation zum Stillstand. Spieler erleben Rubber-banding auf der Map, RPCs gehen verloren und Momente später beendet der fatale Connection timeout das Match. Du gibst vielleicht instinktiv deinem neuesten Movement replication Code oder einer komplexen Physikberechnung die Schuld, aber wenn deine Player base wächst, ist die Realität oft viel bösartiger: Deine Infrastruktur ist das Opfer einer koordinierten Distributed Denial of Service (DDoS) Attacke.

Aktuelle Berichte aus der Unreal Engine Entwickler-Community zeigen einen massiven Anstieg an organisierten DDoS Attacken auf Game-Server, was besonders groß angelegte Modi wie Battle Royale und benutzerdefinierte Creative-Instanzen betrifft. Diese Angriffe überlasten den Network processing thread des Servers vollständig, was zu schwerem Lag, globaler Desynchronisation und schließlich zu Hard crashes führt.

Für Indie-Entwickler und AA-Studios ist die Implementierung einer robusten Unreal Engine Server DDoS Protection nicht länger optional – sie ist eine zwingende Voraussetzung für jedes Live-ops Spiel. In dieser technischen Analyse untersuchen wir, wie diese Angriffe den Unreal Engine Netcode manipulieren, wie man einen bösartigen Flood von normalen schlechten Netzwerkbedingungen unterscheidet und welche konkreten Schritte du unternehmen kannst, um die Infrastruktur deines Spiels zu härten.

Die Anatomie eines Unreal Engine Server Crashs

Um zu verstehen, wie du deinen Server schützen kannst, musst du zuerst verstehen, wie Unreal Engine eingehenden Netzwerk-Traffic verarbeitet. Unreal nutzt ein benutzerdefiniertes UDP-basiertes Protokoll, das vom NetDriver verwaltet wird. Da UDP verbindungslos ist, kann jeder Client im Internet Pakete an den offenen Port deines Servers senden, ohne einen formellen Handshake.

Layer 4 Volumetric Floods vs. Layer 7 Application Attacks

Die meisten Server-Crashs werden durch eine von zwei Arten von Netzwerkangriffen verursacht:

1. Volumetric UDP Floods (Layer 4): Dies ist ein Brute-Force-Angriff. Ein Botnet bombardiert die öffentliche IP-Adresse und den Port deines Servers mit Gigabyte an Garbage UDP-Paketen pro Sekunde. Die Network Interface Card (NIC) des Servers und der Network stack des Betriebssystems sind vollständig gesättigt. Bevor Unreal Engine überhaupt die Chance bekommt, die Pakete anzusehen, geht der zugrunde liegenden Maschine die Bandwidth aus oder die CPU-Interrupts steigen so stark an, dass legitimer Spieler-Traffic komplett verworfen wird.

2. Application-Layer Exhaustion (Layer 7): Diese Angriffe sind viel heimtückischer. Anstatt wahllosen Müll zu senden, nutzt der Angreifer Packet capture Tools oder modifizierte Game-Clients, um korrekt formatierte Unreal Engine Connection-Requests (wie NMT_Hello oder NMT_Login Pakete) oder gezielten schweren RPC Spam zu senden. Der NetDriver akzeptiert diese scheinbar gültigen Pakete und übergibt sie dem Game thread zur Verarbeitung. Die Server-CPU schnellt auf 100 % hoch, während sie versucht, Tausende von gefälschten Login-Handshakes zu parsen, nicht existierende Session-Tickets zu validieren oder Speicher für komplexe String-Parameter in replizierten Funktionen zu reservieren. Da dieser Traffic für eine Standard-Firewall identisch mit legitimen Spieleraktivitäten aussieht, umgeht er den grundlegenden DDoS Schutz. Dies lässt die Server Tick rate sofort einbrechen, was das extreme Teleportieren und die Rollback-Effekte verursacht, die Spieler direkt vor dem Absturz erleben.

Die Diagnose: Böswillig oder nur schlechter Netcode?

Bevor du annimmst, dass dein Server angegriffen wird, musst du katastrophale Replication-Bugs ausschließen. Wenn ein einzelner Client eine Endlosschleife von RPC-Calls auslöst, kann dies eine Layer 7 DDoS imitieren. Bevor du in Panik verfällst, solltest du deine Crash-Logs und Metriken prüfen. Wenn du massive Spitzen bei der Memory allocation, aber geringen Netzwerk-Traffic siehst, hast du es möglicherweise mit einem Replication-Problem zu tun – für Hilfe dazu schau dir unseren Guide Zero Ping Spikes Complete Freeze The Ultimate Uefn Server Crash Fix Protocol an.

Wenn jedoch dein externes Monitoring zeigt, dass der eingehende Traffic von einer Basislinie von ~50 Mbps auf 5 Gbps ansteigt, oder wenn deine Server-Logs Tausende von LogNet: NotifyAcceptingConnection Meldungen von eindeutigen IP-Adressen innerhalb von Sekunden anzeigen, hast du es mit einem koordinierten Angriff zu tun.

Härtung deines Netcodes: Implementierung von Connection Throttling in C++

Während echtes Volumetric DDoS Mitigation auf Infrastruktur-Ebene stattfinden muss (was wir gleich behandeln), kannst du deinen Unreal Engine Server vor Layer 7 Application Exhaustion schützen, indem du aggressives Rate Limiting direkt in deinem AGameModeBase implementierst.

Durch das Überschreiben der PreLogin-Funktion kannst du Verbindungsversuche abfangen, bevor der Server einen vollständigen APlayerController erstellt und den teuren Prozess startet, den Spieler in die Welt zu laden.

Hier ist eine robuste C++ Implementierung, um schnelle Verbindungsversuche von bösartigen IP-Adressen zu drosseln:

// In YourGameMode.h
#pragma once

#include "CoreMinimal.h"
#include "GameFramework/GameModeBase.h"
#include "YourGameMode.generated.h"

UCLASS()
class YOURGAME_API AYourGameMode : public AGameModeBase
{
    GENERATED_BODY()

public:
    virtual void PreLogin(const FString& Options, const FString& Address, const FUniqueNetIdRepl& UniqueId, FString& ErrorMessage) override;

private:
    // Maps to track connection attempts per IP
    TMap<FString, int32> ConnectionAttempts;
    TMap<FString, float> LastConnectionTime;

    // Configuration limits
    const int32 MaxAttemptsPerMinute = 4;
    const float LockoutTimeSeconds = 60.0f;
};

// In YourGameMode.cpp
#include "YourGameMode.h"
#include "Engine/World.h"

void AYourGameMode::PreLogin(const FString& Options, const FString& Address, const FUniqueNetIdRepl& UniqueId, FString& ErrorMessage)
{
    // Always call super first to handle native bans and base logic
    Super::PreLogin(Options, Address, UniqueId, ErrorMessage);

    // If an error was already generated (e.g., server full), exit early
    if (!ErrorMessage.IsEmpty())
    {        return;
    }

    // The Address string usually arrives in the format "IP:Port"
    FString ClientIP;
    FString PortStr;
    if (!Address.Split(TEXT(":"), &ClientIP, &PortStr))
    {        ClientIP = Address; // Fallback if no port is appended
    }

    float CurrentTime = GetWorld()->GetTimeSeconds();

    // Check if this IP is currently in our tracking map
    if (LastConnectionTime.Contains(ClientIP))
    {        float TimeSinceLastAttempt = CurrentTime - LastConnectionTime[ClientIP];
        
        // If they are connecting too fast and have exceeded the attempt limit
        if (TimeSinceLastAttempt < LockoutTimeSeconds && ConnectionAttempts[ClientIP] >= MaxAttemptsPerMinute)
        {            ErrorMessage = TEXT("Connection rate limit exceeded. Please wait 60 seconds.");
            UE_LOG(LogGameMode, Warning, TEXT("DDoS Mitigation: Rejected rapid connection attempt from %s."), *ClientIP);
            return;
        }

        // If the lockout window has passed, reset their counter
        if (TimeSinceLastAttempt >= LockoutTimeSeconds)
        {            ConnectionAttempts[ClientIP] = 0;
        }    }

    // Increment the attempt counter and update the timestamp
    int32 Attempts = ConnectionAttempts.FindOrAdd(ClientIP, 0);
    ConnectionAttempts[ClientIP] = Attempts + 1;
    LastConnectionTime.Add(ClientIP, CurrentTime);

    UE_LOG(LogGameMode, Log, TEXT("Connection validation passed. Attempt %d from %s"), ConnectionAttempts[ClientIP], *ClientIP);
}

Warum dieser Code wichtig ist

Diese Implementierung verfolgt die IP-Adresse jeder eingehenden Anfrage. Wenn eine einzelne IP versucht, sich innerhalb eines 60-Sekunden-Fensters mehr als viermal zu verbinden, lehnt der Server die Verbindung in PreLogin aktiv ab. Eine Verbindung hier abzulehnen ist für die CPU wesentlich günstiger, als der Engine zu erlauben, einen Actor zu spawnen, initiale Zustände zu replizieren und den Spieler dann zu kicken. Dieser einfache Codeblock kann den Unterschied ausmachen, ob dein Server einen Layer 7 Script-Kiddie-Angriff übersteht oder vollständig einfriert.

Tuning der Unreal Engine Netzwerk-Konfiguration

Zusätzlich zur C++ Logik enthält deine DefaultEngine.ini Datei mehrere kritische Konfigurationsparameter. Diese auf den Standardwerten zu belassen, ist eine massive Sicherheitslücke. Wenn ein Angreifer deinen Server flutet und deine Bandwidth Limits unbegrenzt sind, wird der Server versuchen, alles zu verarbeiten, was die CPU sofort ans Limit bringt.

Du musst strikte Obergrenzen für deinen Netzwerk-Traffic festlegen. Öffne deine DefaultEngine.ini und wende diese Härtungslimits auf den IpNetDriver an:

[/Script/Engine.Player]
; Limit maximum connection speed to 10 MB/s to prevent single-client bandwidth exhaustion
ConfiguredInternetSpeed=10485760
ConfiguredLanSpeed=10485760

[/Script/OnlineSubsystemUtils.IpNetDriver]
; Maximum data rate allowed per client (in bytes). 100kb/s is usually plenty for an FPS.
MaxClientRate=100000
MaxInternetClientRate=100000

; Cap the server tick rate to ensure predictable CPU load.
NetServerMaxTickRate=30

; Aggressively drop unresponsive clients. Defaults are often too long (60s+).
ConnectionTimeout=15.0
InitialConnectTimeout=15.0

; How often the server expects a keep-alive ping.
KeepAliveTime=0.2

; Limit the number of ports the server will try to bind to upon startup.
MaxPortCountToTry=512

Durch die Reduzierung des ConnectionTimeout auf 15.0 Sekunden bereinigt dein Server schnell halb-offene oder tote Verbindungen, die durch eine DDoS Attacke erzeugt wurden, und gibt Speicher sowie Netzwerk-Slots für legitime Spieler frei.

Das Infrastruktur-Problem: Man kann nicht blockieren, was bereits angekommen ist

Die oben beschriebenen C++ Throttling- und INI-Konfigurationen schützen dich vor Application-layer Exhaustion, aber sie haben eine fatale Schwachstelle bei Layer 4 Volumetric Attacks: Sobald dein Unreal Engine Server entscheidet, das Paket zu verwerfen, wurde die Bandwidth bereits verbraucht.

Wenn ein Angreifer ein 10 Gbps Botnet auf deinen Server richtet und dein Hosting-Provider nur ein 1 Gbps Network interface bereitstellt, spielt es keine Rolle, wie optimiert dein C++ Code ist. Die Leitungen zu deinem Server sind physisch verstopft. Legitimer Spieler-Traffic kommt nicht mehr durch.

Die Abwehr von Layer 4 Angriffen erfordert eine Verteidigungsstrategie auf Infrastruktur-Ebene.

Der Do-It-Yourself-Ansatz

Wenn du eigene Dedicated Bare-metal Server oder Standard-EC2-Instanzen betreibst, musst du manuell eine Mitigation-Pipeline aufbauen. Dies beinhaltet typischerweise:

1. Einrichten eines Reverse Proxy: Du darfst die tatsächliche IP deines Unreal Engine Servers nicht öffentlich machen. Du musst den Traffic über einen UDP Proxy leiten (wie NGINX mit dem stream Modul oder HAProxy). Dies fügt zwar Latenz hinzu, erlaubt es dir aber, die wahre IP der Instanz zu verbergen.
2. Konfigurieren von iptables/nftables: Du musst strikte Firewall-Regeln schreiben, um fragmentierte UDP-Pakete zu verwerfen und Verbindungen pro IP auf Kernel-Ebene zu begrenzen.
3. Kauf von Enterprise Mitigation: Du musst teure Enterprise-Routing-Dienste (wie AWS Shield Advanced oder Cloudflare Magic Transit) erwerben, um bösartigen Traffic zu bereinigen, bevor er dein Rechenzentrum erreicht.

Der Aufbau einer solchen resilienten, Proxy-basierten Architektur erfordert Fleet Manager, Load Balancer und komplexe Routing-Tabellen – locker 4-6 Monate spezialisierte DevOps Arbeit. Für ein Indie-Studio ist das eine enorme finanzielle und zeitliche Belastung.

Dem DevOps-Dilemma entkommen

Genau das ist der Infrastruktur-Albtraum, den Backend-as-a-Service Plattformen lösen sollen. Mit horizOn ist diese gehärtete Backend-Infrastruktur bereits vorkonfiguriert.

Anstatt Monate mit iptables zu verbringen, verwaltet unsere Plattform das Edge network für dich. Deine Game-Instanzen sind hinter einer Enterprise-Grade Routing-Schicht geschützt, die bösartigen Layer 4 und Layer 7 Traffic automatisch erkennt und verwirft, bevor er überhaupt deinen Unreal Engine Server-Thread erreicht. Das bedeutet, deine Tick rate bleibt stabil und deine legitimen Spieler bleiben verbunden.

4 Best Practices für Indie-Entwickler unter Beschuss

Unabhängig davon, ob du deinen eigenen Mitigation-Stack baust oder dich auf eine verwaltete Infrastruktur verlässt, solltest du diese Sicherheitsprinzipien befolgen:

1. Server-IPs niemals direkt an Clients weitergeben: Wenn ein Spieler deine Server-IP über Wireshark sehen kann, kann der Angreifer das auch. Nutze einen Matchmaking-Service, der Verbindungen vermittelt oder Session-Tickets nutzt.

2. Strikte Session-Validierung implementieren: Lass Clients sich nicht nur durch Kenntnis von IP und Port verbinden. Verlange ein kurzlebiges kryptografisches Token (wie ein JWT). Validiere dieses Token sofort in PreLogin. Dies stellt sicher, dass Angreifer dein Rate Limiting nicht einfach durch IP-Rotation umgehen können.

3. Server Tick rate begrenzen: Lass NetServerMaxTickRate nicht unbegrenzt laufen. Fixiere den Wert (z. B. auf 30 Hz), um sicherzustellen, dass CPU-Reserven für unerwartete Traffic-Spitzen frei bleiben.

4. Den Network Edge überwachen, nicht nur die Engine: Engine-Logs sagen nichts über verworfene Pakete an der Firewall aus. Du benötigst Metriken für die eingehende Bandwidth (InBytes) auf Betriebssystem-Ebene. Ein plötzlicher Anstieg des UDP-Traffics ohne entsprechende Spielerzahlen ist dein primärer Indikator für einen Volumetric Attack.

Der Schutz deines Multiplayer-Spiels ist ein Wettrüsten. Durch aggressives Rate Limiting, gehärtete Konfigurationen und eine Infrastruktur, die schlechten Traffic am Edge verwirft, stellst du sicher, dass deine Spieler dein Spiel genau so erleben, wie du es entworfen hast.

Bereit, dich nicht mehr um Sunucuinfrastruktur zu kümmern? Teste horizOn kostenlos.

---

Quelle: [VERY CRITICAL] Organized DDoS Attacks Causing Server Crashes