Was tun, wenn dein Dienst von einem DDoS-Angriff getroffen wird

2. September 2026

Sonstiges

Die Abwehr ist bei allen Diensten bereits aktiv und arbeitet, ohne dass du etwas anfordern musst: Der Schutz von RedHosting arbeitet zweistufig – das GC-Netzwerk fängt Volumenangriffe mit bis zu 20 Tbps Kapazität ab, bevor der Traffic unsere Infrastruktur erreicht, und eine A10-Appliance am Netzrand filtert, was nicht volumenbasiert ist und eine reine Volumenprüfung passieren würde.

In dieser Anleitung geht es um die andere Hälfte: deinen Teil. Erkennen, dass es ein Angriff ist, entscheiden, was zu tun ist, und es nicht aus Reflex schlimmer machen.

1. Ist es wirklich ein Angriff?

Nicht jeder Ausfall ist ein Angriff, und wer normale Überlastung als Angriff behandelt, lenkt die Diagnose in die falsche Richtung. Die Anzeichen, die beides unterscheiden:

Anzeichen	Angriff	Normale Überlastung
Beginn	Plötzlich, innerhalb von Sekunden	Allmählich, mit der Nutzung
Herkunft des Traffics	Viele IPs ohne erkennbares Publikumsmuster	Die üblichen
Zusammenhang mit einem Ereignis	Keiner, oder direkt nach einem öffentlichen Streit	Werbung, Aktion, Stoßzeit
Inhalt der Verbindungen	Wiederholend, ohne etwas abzuschließen	Normale Anfragen, nur sehr viele
CPU und Arbeitsspeicher	Normal, aber das Netzwerk ist ausgelastet	Steigen mit dem Traffic

Der letzte Punkt ist der aufschlussreichste: Bei echter Überlastung arbeitet die Maschine; bei einem Volumenangriff ist sie untätig, und ausgelastet ist der Weg zu ihr.

2. Was zu tun ist, der Reihe nach

Notiere die Uhrzeit. Halte fest, wann es anfing, auf die Minute ungefähr. Ohne das wird die Suche im Log später zur Schatzsuche.
Starte nicht immer wieder neu. Ein Neustart stoppt keinen Angriff, und die Maschine ist mehr mit Hochfahren beschäftigt als mit Ausliefern.
Eröffne früh ein Ticket, mit IP, Uhrzeit und deinen Beobachtungen. Je früher das Team den Live-Traffic sieht, desto leichter lässt sich der Filter auf das Muster genau dieses Angriffs einstellen.
Sichere, was du kannst, aus dem Anwendungslog und der Ausgabe von ss -tn state established oder Vergleichbarem. Mit diesem Material lässt sich die Regel später anpassen.
Informiere deine Community, wenn es ein Gameserver ist. Schweigen während eines Ausfalls schadet dem Ruf mehr als der Ausfall selbst.

⚠️Was nicht funktioniert: IPs von Hand sperren. In einem verteilten Botnetz wechseln die Quellen ständig, und die Liste wächst schneller, als du sie pflegen kannst. Tragfähig sind Regeln nach Traffic-Muster; IP für IP ist ein Kampf gegen Windmühlen.

3. Entscheidungen, die häufig anstehen

Situation	Empfohlene Entscheidung	Risiko, wenn ignoriert
Verbindungsspitze direkt nach einem Ereignis	Limit vorübergehend erhöhen und Herkunft beobachten	Legitime Spieler oder Kunden sperren
Viele kurze Verbindungen, die nichts abschließen	Nach Signatur und Takt filtern, nicht nach IP	Zustandstabelle der Firewall erschöpfen
Auffällige Anfragen an einen Hilfsdienst	Port isolieren und Angriffsfläche verkleinern	Teilausfall des ganzen Systems
Angriff kommt immer zur gleichen Uhrzeit	Muster an den Support geben für eine dauerhafte Regel	Jede Woche erneut manuell abwehren

💡Tipp: Bitte bei einem echten Vorfall im Ticket um einen Bericht mit Uhrzeit, Traffic-Spitze und angewandtem Filtertyp. Mit diesem Verlauf lässt sich die Regel vor dem nächsten Ereignis anpassen, statt wieder bei null zu reagieren.

4. Die Angriffsfläche vor dem nächsten Mal verkleinern

Die Hälfte der Arbeit passiert, wenn gar kein Angriff läuft.

Eine Prüfung, die sich vierteljährlich lohnt

✓Bestandsaufnahme der offenen Ports. Jeder offene Port, den niemand nutzt, ist geschenkte Angriffsfläche.

✓Hilfsdienste nicht öffentlich erreichbar – Datenbank, Admin-Panel, interne API. Sie brauchen kein offenes Internet.

✓Externes Monitoring, außerhalb unseres Netzes, um die Verfügbarkeit unabhängig zu bestätigen.

✓Ein Runbook für Vorfälle mit fertigen Nachrichten für die Community. Eine Mitteilung mitten im Ausfall zu schreiben, geht schief.

✓Plugins und Module überprüfen: Jedes, das du nicht nutzt, ist grundlos exponierter Code.

✓Server-IP nicht öffentlich machen, wenn eine Schicht davor liegt – die Ursprungs-IP zu veröffentlichen umgeht den Schutz.

5. Was wir schon erledigen und du nicht einrichten musst

Zweistufige Abwehr bei allen Produkten – Minecraft, Hytale, VPS, dedizierte Server, Websites und Bots –, im Preis inbegriffen.
Abfangen von Volumenangriffen im Netzwerk, bevor sie die Bandbreite deines Servers verbrauchen.
Proaktives Monitoring rund um die Uhr.
Anpassbare Firewall und Zugang nur für autorisierte Spieler bei Gameservern.

Kennzahlen und Funktionsweise der beiden Stufen findest du unter redhosting.com.br/protecao.

Während eines Vorfalls

WhatsApp +55 11 98833-3902 ist der schnellste Kanal, rund um die Uhr, auf Portugiesisch, Englisch, Spanisch und Deutsch. Tickets unter financeiro.redhosting.com.br. Laufende Wartungen und Störungen stehen unter redhosting.com.br/status.

Häufige Fragen

Muss ich DDoS-Schutz dazubuchen? +

Nein. Die Abwehr ist bei allen Diensten inklusive, zweistufig: das GC-Netzwerk mit bis zu 20 Tbps Kapazität und eine A10-Appliance am Rand des RedHosting-Netzes. Details unter redhosting.com.br/protecao.

Woran erkenne ich, ob es ein Angriff oder nur Überlastung ist? +

Am aussagekräftigsten ist das Verhältnis von CPU und Netzwerk. Bei echter Überlastung arbeitet die Maschine und die Ressourcen steigen mit dem Traffic; bei einem Volumenangriff ist die Maschine untätig, und ausgelastet ist der Weg zu ihr.

Soll ich die angreifenden IPs sperren? +

Das bringt nichts. In einem verteilten Botnetz wechseln die Quellen ständig, und die Liste wächst schneller, als du sie pflegen kannst. Tragfähig sind Regeln nach Traffic-Muster.

Stoppt ein Neustart des Servers den Angriff? +

Nein. Er verschlimmert es sogar: Die Maschine ist mehr mit Hochfahren beschäftigt als mit Ausliefern.

Was schreibe ich während eines Angriffs ins Ticket? +

IP, ungefähre Startzeit und deine Beobachtungen. Je früher das Team den Live-Traffic sieht, desto leichter lässt sich der Filter auf das Muster genau dieses Angriffs einstellen.

Was kann ich vor dem nächsten Angriff tun? +

Die Angriffsfläche verkleinern: ungenutzte Ports schließen, Hilfsdienste aus dem offenen Internet nehmen, externes Monitoring betreiben und die Ursprungs-IP nicht veröffentlichen, wenn eine Schicht davor liegt.