Wie DDoS-Schutz funktioniert: Einfach erklaert

Sie starten einen Minecraft-Server, bauen eine Spielerbasis auf, alles laeuft grossartig. Dann antwortet der Server eines Morgens einfach nicht mehr. Spieler beschweren sich ueber Timeouts. Die Konsole haengt. Ihr Hoster erwaehnt "ungewoehnlichen Traffic". Sie werden angegriffen.

Die erste Frage: "Wie schuetze ich mich dagegen?" Die zweite: "Wie funktioniert dieser Schutz ueberhaupt?"

Heute beantworten wir die zweite Frage. Ohne schwere Fachbegriffe, mit Analogien aus dem Alltag und konkreten Beispielen.

Was passiert bei einer DDoS-Attacke

Beginnen wir mit der Attacke selbst. DDoS bedeutet, dass Tausende (oder Millionen) Quellen gleichzeitig Traffic an Ihren Server senden. Das Ziel ist simpel: Bandbreite, CPU oder Arbeitsspeicher so ueberlasten, dass echte Spieler sich nicht verbinden koennen.

Stellen Sie sich ein Restaurant mit 50 Plaetzen vor. Normalerweise kommen 30-40 Gaeste - genug Platz fuer alle. Jetzt stellen Sie sich vor, jemand hat 5.000 Leute angeheuert, die gleichzeitig den Eingang blockieren. Echte Gaeste kommen physisch nicht rein. Die Kueche arbeitet, die Koeche kochen, aber niemand erreicht einen Tisch.

DDoS funktioniert genauso. Ihr Server laeuft, Minecraft ist gestartet, aber die Netzwerkleitung ist mit Muell-Traffic verstopft.

Schritt eins: DNS-Umleitung - die echte Adresse verstecken

Das Erste, was jeder DDoS-Schutz tut: die echte IP-Adresse Ihres Servers verbergen. Wenn der Angreifer Ihre tatsaechliche IP kennt, kann er Traffic direkt senden und jede Schutzschicht umgehen.

So funktioniert es: Sie aendern die DNS-Eintraege Ihrer Domain (zum Beispiel play.myserver.com), sodass sie nicht auf Ihren Server zeigen, sondern auf das Schutznetzwerk. Bei Minecraft ist das normalerweise ein SRV-Eintrag, der Spieler zum Filterknoten leitet.

Analogie: Anstatt Leuten Ihre Privatadresse zu geben, geben Sie ihnen die Adresse einer Sicherheitsfirma. Alle Post geht zuerst dorthin, wird geprueft, und nur echte Korrespondenz wird an Ihr Zuhause weitergeleitet.

Spieler gibt ein: play.myserver.com
DNS antwortet: "geh zu 104.167.24.XX" (Schutzadresse)
Spieler verbindet sich mit dem Filterknoten
Filter prueft und leitet an den echten Server weiter

Wichtiges Detail: Wenn jemand Ihre echte IP bereits kennt, hilft DNS-Umleitung allein nicht. Deshalb wird oft empfohlen, die Server-IP nach Aktivierung des Schutzes zu wechseln.

Schritt zwei: Scrubbing - sauberen Traffic von Muell trennen

Sobald der gesamte Traffic durch den Schutzknoten laeuft, beginnt der interessante Teil - das Scrubbing (englisch fuer "Reinigung").

Denken Sie ans Goldwaschen. Ein Goldgraeber nimmt eine Pfanne mit Sand und waescht ihn mit Wasser. Schmutz und Kiesel werden weggespuelt, Goldkoerner bleiben uebrig. Scrubbing funktioniert nach demselben Prinzip: Muell-Traffic wird ausgewaschen, und Pakete von echten Spielern kommen durch.

In der Praxis sieht das so aus:

Eingehender Traffic: 50 Gbps
  |
  [L3/L4 Filter] - verwirft 95% des Muells
  |
  Zwischentraffic: 2.5 Gbps
  |
  [L7 Filter] - prueft das Protokoll
  |
  Sauberer Traffic: 200 Mbps -> Ihr Server

Von 50 Gigabit pro Sekunde Angriffstraffic erreichen nur 200 Megabit legitimen Traffics Ihren Server. Der Rest wird auf verschiedenen Filterstufen verworfen.

L3/L4-Filterung: die erste Verteidigungslinie

L3 und L4 beziehen sich auf Schichten des Netzwerkmodells. L3 (Netzwerkschicht) befasst sich mit IP-Adressen. L4 (Transportschicht) befasst sich mit TCP/UDP-Ports und Verbindungen.

Filterung auf diesen Schichten ist am schnellsten. Sie arbeitet mit Paket-Headern, ohne in den Inhalt zu schauen. Was hier geprueft wird:

Rate Limiting. Eine einzelne IP-Adresse kann nicht 10.000 Pakete pro Sekunde senden, waehrend sie Minecraft spielt. Wenn doch - ist das kein Spieler. Blockieren.

Protokollvalidierung. Minecraft laeuft ueber TCP. Wenn UDP-Pakete auf Port 25565 ankommen, ist das definitiv kein Spieler. Verwerfen.

TCP-Handshake-Pruefung. Eine normale TCP-Verbindung beginnt mit einem Drei-Wege-Handshake: SYN - SYN-ACK - ACK. Viele Attacken (SYN Flood) senden nur SYN-Pakete ohne den Handshake abzuschliessen. Der Filter nutzt SYN Cookies oder einen SYN-Proxy, um zu pruefen, ob der Client tatsaechlich eine Verbindung aufbauen will.

Schwarze Listen. Bekannte Botnet-Adressen, Rechenzentren, aus denen nie echte Spieler kommen - alles wird am Eingang blockiert.

Analogie: Denken Sie an einen Tuersteher am Clubeingang, der prueft, ob Sie ein Ticket haben (TCP-Handshake), ob Sie auf der Sperrliste stehen, und ob Sie versuchen, durch die Wand statt durch die Tuer zu gehen (falsches Protokoll).

L7-Filterung: tiefe Inspektion

L7 ist die Anwendungsschicht. Hier schaut der Filter in die Pakete hinein und prueft, ob der Traffic tatsaechlich wie eine echte Minecraft-Sitzung aussieht.

Der Minecraft-Client kommuniziert mit dem Server ueber ein bestimmtes Protokoll. Bei der Verbindung sendet er ein Handshake-Paket mit Protokollversion, Serveradresse und Port. Dann folgt eine Login-Anfrage mit dem Spielernamen. All das folgt einem strengen Format.

Was der L7-Filter prueft:

Paketformat. Minecraft-Pakete haben eine definierte Struktur: Laenge, Paket-ID, Daten. Wenn ein Paket nicht dem Format entspricht, ist es gefaelscht.

Paketreihenfolge. Ein echter Client sendet zuerst einen Handshake, dann Login Start, dann wartet er auf die Serverantwort. Ein Bot koennte Pakete in falscher Reihenfolge oder zu schnell senden.

Protokollversion. Wenn Ihr Server auf 1.21 laeuft, aber ein Paket Version 1.7 mit verdaechtiger Struktur angibt - das rechtfertigt genauere Pruefung.

Verhaltensanalyse. Ein echter Spieler beginnt sich nach dem Verbinden zu bewegen und sendet Pakete mit einer bestimmten Frequenz. Ein Bot koennte sich verbinden und schweigen, oder Pakete nonstop fluten.

Paket von einem echten Spieler:
[Laenge: 16][ID: 0x00][Version: 769][Adresse: play.myserver.com][Port: 25565][Status: 2]
-> Format korrekt, durchlassen

Paket von einem Bot:
[Muell-Bytes][zufaellige Daten]
-> Format ungueltig, verwerfen

Challenge-Response: den Menschen hinter dem Client verifizieren

Manche Schutzsysteme gehen weiter und fordern verbindende Clients aktiv heraus. Das nennt sich Challenge-Response - das System stellt eine "Herausforderung" und der Client muss korrekt antworten.

Fuer Minecraft kann das so funktionieren:

Handshake-Verifizierung. Der Schutz-Proxy gibt sich als Server aus und fuehrt den TCP-Handshake selbst durch. Wenn der Client nicht korrekt antwortet, wird die Verbindung nie an den echten Server weitergegeben.

Ping-Verifizierung. Vor der Freigabe kann das System pruefen, ob der Client Minecraft-Protokoll-Statusanfragen korrekt verarbeiten kann. Ein echter Client kann das; ein primitiver Bot nicht.

CAPTCHA. Im Web-Kontext (Kontrollpanel, Serverkarte) ist das die bekannte Captcha-Abfrage. Fuer Minecraft selbst kann es eine Lobby-Phase sein: Der Spieler wird mit einer temporaeren Welt verbunden, wo er eine einfache Aktion ausfuehren muss, bevor er zum Hauptserver weitergeleitet wird.

Reverse-Proxy-Architektur fuer Spieleserver

Sprechen wir nun darueber, wie all diese Teile zusammenpassen. Der zentrale architektonische Ansatz ist der Reverse Proxy.

Was ist das? Ein Reverse Proxy ist ein Server, der zwischen dem Internet und Ihrem echten Server steht. Jede Verbindung laeuft durch ihn. Fuer Spieler ist er transparent - sie wissen nicht einmal, dass sie sich nicht direkt verbinden.

Spieler -> [Internet] -> [Schutz-Proxy] -> [Ihr Server]
                            |
                            +-- Filterung
                            +-- Protokollpruefung
                            +-- Rate Limiting

Fuer Minecraft arbeitet der Reverse Proxy auf TCP-Ebene. Er nimmt eine Verbindung vom Spieler an, prueft die ersten Pakete, und wenn alles stimmt, oeffnet er eine Verbindung zum echten Server und beginnt, Daten in beide Richtungen weiterzuleiten.

Der Hauptvorteil: Ihr echter Server sieht Angriffstraffic ueberhaupt nicht. Er laeuft ruhig und verarbeitet nur verifizierte Verbindungen. Die Angriffslast liegt auf dem Schutzknoten, der dafuer gebaut ist.

GRE-Tunnel: wenn Sie Ihre eigene IP brauchen

Manchmal passt ein Reverse Proxy nicht. Vielleicht haben Sie ein komplexes Netzwerk-Setup, mehrere Server hinter einer IP, oder Sie brauchen volle Kontrolle ueber den Traffic. Dann kommen GRE-Tunnel zum Einsatz.

GRE (Generic Routing Encapsulation) ist ein "Tunnel" zwischen Schutzknoten und Ihrem Server. Er funktioniert so: Der Schutzknoten empfaengt allen Traffic, filtert ihn und verpackt dann den sauberen Traffic in GRE-Pakete und sendet sie an Sie. Ihr Server entpackt die GRE-Pakete und sieht die originalen Spieler-IP-Adressen.

Analogie: Stellen Sie sich einen gepanzerten Konvoi vor. Briefe (Pakete) werden in einen sicheren Container gelegt (GRE-Kapselung), ueber eine sichere Route transportiert (der Tunnel) und am Ziel fuer die Empfaenger ausgepackt.

Internet -> [Schutzknoten] --(GRE-Tunnel)--> [Ihr Server]
               |                                    |
           Filterung                         Entkapselung
           findet hier statt                 + Verarbeitung

Der Vorteil eines GRE-Tunnels: Ihr Server erhaelt die echten Spieler-IPs (nuetzlich fuer Bans und Geolokalisierung). Der Nachteil: zusaetzlicher Overhead und Konfiguration auf beiden Seiten.

Anycast: eine Adresse, viele Server

Grosse Schutznetzwerke nutzen eine Technologie namens Anycast. Die Idee ist einfach: Dieselbe IP-Adresse wird von mehreren Standorten weltweit ueber BGP (das Routing-Protokoll des Internets) angekuendigt.

Wenn ein Spieler in Deutschland sich mit Ihrem Server verbindet, geht sein Traffic automatisch zum naechsten Schutzknoten - zum Beispiel Frankfurt. Ein Spieler in Brasilien landet beim Knoten in Sao Paulo. Und Angriffstraffic aus Asien geht zum Knoten in Tokio.

Spieler (Berlin)  -------->  Knoten Frankfurt  ----->  Ihr Server
Spieler (Moskau)  -------->  Knoten Amsterdam  ----->  Ihr Server
Attacke (Shanghai) ------->  Knoten Tokio [BLOCKIERT]
Attacke (div. IPs) ------->  Verteilt auf alle Knoten

Das bringt zwei Vorteile:

1. Die Attacke wird verteilt. Statt 100 Gbps auf einen einzigen Punkt treffen, verteilt sich der Traffic auf Dutzende Knoten. Jeder Knoten bearbeitet nur einen Bruchteil - leicht zu bewaeltigen.

2. Weniger Latenz. Spieler verbinden sich mit dem naechsten Knoten, anstatt quer durch die Welt geroutet zu werden. Niedrigerer Ping, fluessigeres Gameplay.

Wie MineGuard funktioniert: das grosse Bild

Schauen wir uns an, wie das alles bei MineGuard konkret zusammenkommt.

Wenn Sie Ihren Server mit MineGuard verbinden, passiert Folgendes:

1. DNS-Einrichtung. Ihre Domain zeigt auf MineGuards Schutzknoten statt auf Ihren echten Server.

2. Eingangsfilterung. Der gesamte eingehende Traffic durchlaeuft ein mehrstufiges Filtersystem.

3. Proxying. Verifizierter Traffic wird an Ihren echten Server weitergeleitet. Fuer Spieler ist der Prozess voellig transparent - sie verbinden sich wie gewohnt.

4. Monitoring. Das System analysiert kontinuierlich Traffic-Muster und passt Filter in Echtzeit an.

Architektonisch umfasst MineGuards Schutzknoten mehrere Komponenten:

• Kernel-Level-Paketfilter (XDP/eBPF) - verwirft den groebsten Muell mit Leitungsgeschwindigkeit, noch bevor das Paket den Netzwerk-Stack erreicht
• TCP-Proxy - fuehrt den Handshake durch und validiert TCP-Verbindungen
• Protokollanalysator - zerlegt Minecraft-Pakete und prueft ihre Struktur
• Verhaltensengine - analysiert Verbindungsmuster und identifiziert Botnets

Was passiert, wenn eine Attacke trifft: Schritt fuer Schritt

Gehen wir ein konkretes Szenario durch. Ihr Server laeuft normal mit 100 Spielern online. Dann beginnt eine Attacke.

Sekunde 0-1. Der Angreifer startet ein Botnet. 50.000 Bots beginnen, Traffic an die IP Ihres Servers zu senden (die tatsaechlich MineGuards Schutzknoten ist). Eingehender Traffic springt von 200 Mbps auf 40 Gbps.

Sekunde 1-2. Der Paketfilter (XDP) erkennt den Traffic-Anstieg. Pakete mit ungueltiger Struktur, UDP-Floods auf einen TCP-Port, Pakete aus bekannten Botnet-Bereichen - alles wird sofort verworfen. 90% der Attacke sind innerhalb einer Sekunde weg.

Sekunde 2-5. Schlauere Bots, die TCP-Verbindungen versuchen, durchlaufen den TCP-Proxy. SYN Cookies filtern die aus, die den Handshake nie abschliessen. Von den verbleibenden 4 Gbps kommen nur tatsaechliche TCP-Verbindungen durch - etwa 500 Mbps.

Sekunde 5-10. Bots, die den TCP-Handshake gelernt haben, stehen jetzt vor der Minecraft-Protokoll-Pruefung. Sie muessen ein korrektes Handshake-Paket, ein ordentliches Login-Paket senden und auf Serveranfragen antworten. Die meisten Bots koennen das nicht. Der Traffic faellt auf 50 Mbps, und das sind fast ausschliesslich echte Spieler.

Sekunde 10+. Verhaltensanalyse erledigt die letzten Bots. Wenn ein Bot sich verbindet, aber ungewoehnlich verhaelt (bewegt sich nicht, uebergeht erwartete Pakete, verbindet sich 100 Mal pro Minute von derselben IP) - wird er abgeschnitten.

Ergebnis. Der Angreifer gibt Geld fuer ein Botnet aus, generiert 40 Gbps Traffic, und auf Ihrem Server - passiert nichts. 100 Spieler spielen weiter, vielleicht mit einer kaum merklichen Pinerhoehung von ein paar Millisekunden. Hoechstwahrscheinlich werden sie nicht einmal bemerken, dass eine Attacke stattfand.

Warum man nicht einfach alle verdaechtigen IPs blockieren kann

Ein verbreiteter Irrtum: "Lasst uns einfach alle boesen IPs bannen." Das Problem:

1. Botnets nutzen echte Geraete. Das sind infizierte Computer und Router gewoehnlicher Menschen. Ihre IP-Adressen stammen von normalen Privatanbieter-ISPs. Blockieren Sie ein ganzes Subnetz und Sie treffen echte Spieler aus derselben Stadt.

2. IPs rotieren. Ein Botnet aus 50.000 Maschinen kann Hunderttausende verschiedene IP-Adressen durchlaufen. Blockieren Sie eine Charge und die naechste erscheint.

3. Angreifer passen sich an. Moderne Botnets probieren verschiedene Angriffsmethoden und wechseln automatisch, wenn eine nicht funktioniert.

Deshalb arbeitet effektiver Schutz nicht nur mit IP-Listen, sondern analysiert auch das Traffic-Verhalten in Echtzeit.

Einschraenkungen von DDoS-Schutz: was Sie wissen sollten

Kein Schutz ist perfekt. Hier eine ehrliche Liste der Einschraenkungen:

Erhoehte Latenz. Ein Proxy zwischen Spieler und Server ist ein zusaetzlicher Hop. Normalerweise 1-5 ms, aber fuer manche Spieler zaehlt das.

Schuetzt nicht von innen. Wenn der Angreifer bereits auf Ihrem Server ist (Plugin-Exploit, kompromittiertes Panel) - externer DDoS-Schutz hilft nicht.

IP-Leaks. Wenn Ihre echte IP bekannt wird (vergessen zu verstecken, taucht in Logs auf, jemand findet sie ueber Shodan) - kann der Angreifer direkt zuschlagen und den Schutz umgehen.

Falsch-Positive. Aggressive Filter koennen gelegentlich legitime Spieler blockieren. Guter Schutz erlaubt es, die Empfindlichkeit einzustellen.

Zusammenfassung

DDoS-Schutz ist kein magischer "Sicher machen"-Knopf. Es ist ein mehrstufiges System, das:

• Die echte IP-Adresse Ihres Servers verbirgt
• Allen Traffic ueber DNS-Umleitung aufnimmt
• Muell auf L3/L4 filtert (IP-Adressen, Protokolle, Rate Limiting)
• Das Minecraft-Protokoll auf L7 prueft
• Challenge-Response zur Client-Verifizierung nutzt
• Nur sauberen Traffic an Ihren Server ueber Proxy oder GRE-Tunnel weiterleitet
• Anycast zur Lastverteilung nutzt

Jede Schicht entfernt ihren Anteil an Muell, und nur echter Spiel-Traffic erreicht Ihren Server. Genau so funktioniert jeder serioeser DDoS-Schutz - MineGuard eingeschlossen.