DDoS - Was tun?

H

HerrAusragend

New Member
Es kommt nun schon fast täglich vor, dass gegen Abend für ca. eine halbe Stunde ein DDoS auf meinen vServer angewendet wird.
Ich hoste einen Teamspeak Server mit ca. 100 Usern online im Durchschnitt.
Den Umzug auf andere Hardware, oder einen komplett anderen Provider halte ich für sinnfrei, da die IP des Servers jederzeit einsehbar ist und somit das gleiche Spiel wohl wieder von vorne los gehen wird.

Einen Teamspeak Server anzumieten oder gar einen DDoS Schutz zu kaufen kommt für mich leider auch nicht in Frage.

Ich verstehe es einfach nicht, welchen Nutzen die Angreifer davon haben, und so langsam vergeht mir auch die Lust, obwohl ich mich sehr für das Thema Server und Hosting interessiere.

Kann man als "kleiner Mann am anderen Ende der Leitung" etwas dagegen aussetzen?
 
Inwieweit DDoS? Was sagt denn dein aktueller Anbieter dazu? Vlt ist ein wechsel der IP möglich. Ist ja auch durchaus im Interesse des Anbieters, dass die Angriffe aufhören.

Als vServer Besitzer sind deine Möglichkeiten da sehr begrenzt. Kommt aber auf die Art und die Bandbreite des Angriffs an.

Wenn da gar nichts zu machen ist, würde ich zu OVH wechseln. Die haben einen DDoS Schutz in allen Angeboten inklusive.
 
Gegen DDOS kannst du technisch fast nichts machen, denn selbst wenn deine Firewall alles filtern würde, wird einfach der Uplink weiter vorne überlastet.

Der Provider wird da meist nicht viel machen außer deine IP zu blackholen - dann bist du ganz offline.

Du bietest TS-Server/Channel kostenlos an? Da wird wohl jemand Konkurrenz loswerden wollen. IP-Wechsel bringt dann wohl nichts.
Hat es vorher Drohungen oder so gegeben? Falls da ein Deutscher hinter steckt und sich das ganze zurückverfolgen lässt, könnte man da theoretisch rechtlich vorgehen.
In der Praxis würde ich aber nicht dran glauben.
 
Vill. ist es kein DDOS oder DOS sondern einfach eine überlasstung des Hostsystems.
Da es ein VServer ist... kann es gut sein, das andere Kunden mehr Leistung brauchen als du... wurde leider nichts geschrieben wie der VServer realisiert wurde (welche Software zum Einsatz kommt).
Was schreiben die Logs?

MfG
 
HerrAusragend said:
Kann man als "kleiner Mann am anderen Ende der Leitung" etwas dagegen aussetzen?
Click to expand...

In Verbindung mit TeamSpeak Absolute NICHT's, die Erfahrung musste ich ebenfalls machen. Was bei Script Kiddies mit Bootern zieht ist Cloudflare. SRV Record auf die TeamSpeak Instanz und den Reverseproxy von Coudflare Aktivieren hilft bei den ganz "Dummen" aber ist auch keine Lösung schließlich kann man die IP auf dem TeamSpeak Server einsehen und notfalls mit Wireshark etc. ermitteln.

Filtern mit zb. Conntrack würde ich gar nicht erst versuchen je nach Kapazität der Angriffe ist das meist Kontra Produktiv...

Was du machen kannst habe ich ebenfalls getestet einen GRE Tunnel von einem OvH OpenVZ vServer zu deinem aktuellen Standort bauen und den Traffic über OvH Schicken die Filtern das erstaunlich Gut bei dir kommt von dem Datenmüll Nicht's mehr an ist durchaus Zielführend. Die Problematik ist die Tunnel Transparenz alle Client's auf dem TeamSpeak Server erscheinen dann mit der Tunnel Internen IP des Vorgeschalteten OvH vServer's ergo IP Ban's sind nicht mehr möglich und der Flood Schutz muss auch Deaktiviert werden sonst Löst er für ALLE aus etc.

Die einzige Anständige Lösung ist einen Hoster zu Wählen der in der Lage ist die Angriffe zu Filtern ohne den Ziel Server zu NULL Routen wie zb. OvH.

Im Endeffekt ist es einfach traurig das es Dienste Gibt die für lächerliche 5-10Euro Pro Monat mit 10Gbps aufwärts Angriffe ausführen und die Angreifenden SERVER nicht von Netz genommen werden...

Viel Glück hoffe dir helfen meine Erfahrungen der Letzen Wochen Weiter.

Edit:

Wenn du einen Kulten Hoster hast was bei einem vServer denke ich sowieso weg fällt könntest du ihn Bitten die Anbindung höher zu Setzen als die Netzwerkkarte deines Server's dann müsste der "Dreck" effektiv Filterbar sein bis zu einem gewissen Punkt kommt wieder auf die Angriff's Stärke an.

Für Konterere Infos wäre es gut zu wissen wie du Angegriffen wirst UDP, SYN, oder der bastard Spoofed SYN.
 
Last edited by a moderator:
Ich hab das Problem so "eingedämmt" indem ich einfach bei IP-Projects ein Sophos UTM Gateway davor gebucht hab.

Ich finde diese Teile sind relativ genial, haben ein intelligentes Anti-DDos und IPS mit im Bauch. Hast dann gleichzeitig auch ne anständige Firewall davor etc.

Das kann dir (zumindest den meisten) ärger ersparen...
 
Dazu muss ich allerdings aus eigener Erfahrung sagen dass die Sophos UTM mehrere Probleme hat oder hatte
a) bei mehreren Angriffstypen mit Fragmentierung bricht sie bereits bei nur wenigen Mbit/s ein. Dann dampft der unterliegende Linux-Kernel
b) Traffic wird (oder zumindest wurde) nicht korrekt über alle Interface balanced was bei größeren Angriffen starke IRQ-Probleme verursacht

Unter dem Strich waren wir in der Lage mit einer Intel e1000, iptables und Kernel-Konfiguration durchschnittlich höhere Angriffe zu überleben als was die (virtuelle) Sophos unterstützen konnte.
 
Also ich habe auch bereits Erfahrungen jedoch den Hardware Appliances gemacht, die lassen sich nicht so leicht aus der Fassung bringen...

Wobei d4f, ich muss dir Recht geben, das war auf jeden Fall mal ein defizit, der mittlerweile meiner Einschätzung nach behoben ist.

Ich denke mal, dass es eine gewisse Mischung macht ;)
 
Da helfen nur IPTables, gute Scripte, eine extrem hohe Anbindung (wenigstens punktuell), welche Spielraum zum Traffic Filtern bringt und man ist bis zu einer gewissen Grenze vor DDoS Attacken geschützt.
 
Und dazu die passende Netzwerkhardware :)

//Edit: Du hast ne Nachricht zwecks DDoS Protection

d4f said:
Dazu muss ich allerdings aus eigener Erfahrung sagen dass die Sophos UTM mehrere Probleme hat oder hatte
a) bei mehreren Angriffstypen mit Fragmentierung bricht sie bereits bei nur wenigen Mbit/s ein. Dann dampft der unterliegende Linux-Kernel
b) Traffic wird (oder zumindest wurde) nicht korrekt über alle Interface balanced was bei größeren Angriffen starke IRQ-Probleme verursacht

Unter dem Strich waren wir in der Lage mit einer Intel e1000, iptables und Kernel-Konfiguration durchschnittlich höhere Angriffe zu überleben als was die (virtuelle) Sophos unterstützen konnte.
Click to expand...

Wir nutzen zur DDoS Abwehr mehrere HP Server mit jeweils Octacore CPU, 16GB Ram und ne spezielle Solarflare Dualport 10G Karte mit OpenOnload, wodurch wir je System deutlich weniger Interrupts verarbeiten müssen. Davor ein Force10 Router mit entsprechender Linecard Bestückung (aktuell 2x 8x 10G).

Den DDoS Traffic messen wir mit sflow, verarbeiten die Traffic Pattern über eine eigens entwickelte Software und aktivieren automatisch das Rerouting auf unsere Cloud. Soweit funktioniert das richtig gut, ein Node verkraftet zwischen 18-19Gbit DDoS Traffic bei ca. 15-20mpps und sollte damit einiges mehr als ne Sophos Firewall schaffen - preislich bewegt sich das vermutlich im selben Rahmen :)
 
Last edited by a moderator:
Wir nutzen zur DDoS Abwehr mehrere HP Server mit jeweils Octacore CPU, 16GB Ram und ne spezielle Solarflare Dualport 10G Karte mit OpenOnload, wodurch wir je System deutlich weniger Interrupts verarbeiten müssen.
Click to expand...
Erinnert leicht an Cloudflare's Setup: http://blog.cloudflare.com/a-tour-inside-cloudflares-latest-generation-servers
Aktuell reicht mir das InterruptThrottleRate der Intel Pro1000 Karten welche nur bei vollem Buffer oder angegebenem Zeitintervall Interrupts schicken. Irgendwall soll aber auch mal Intel's DPDK genauer angeschaut werden, was das Gegenstück zu Solarflare's OpenOnload ist - generell regelt das RZ aber eh bereits ab bevor die Interrupt-Rate ein Problem ist.
 
d4f said:
Erinnert leicht an Cloudflare's Setup: http://blog.cloudflare.com/a-tour-inside-cloudflares-latest-generation-servers
Aktuell reicht mir das InterruptThrottleRate der Intel Pro1000 Karten welche nur bei vollem Buffer oder angegebenem Zeitintervall Interrupts schicken. Irgendwall soll aber auch mal Intel's DPDK genauer angeschaut werden, was das Gegenstück zu Solarflare's OpenOnload ist - generell regelt das RZ aber eh bereits ab bevor die Interrupt-Rate ein Problem ist.
Click to expand...

Von Intel NICs halte ich seit einiger Zeit Abstand, wir hatten damit unter hoher Last (Synflood mit 6mpps je Node) massivste Probleme. Nebenher bekommen wir die Solarflare NICs zu einem besseren Preis...

Und ja, das Setup ähnelt dem von Cloudflare - CF nutzt Anycast, wir nutzen Route Loadbalancing um den Traffic gleichmäßig auf die Filter zu verteilen. Prinzipiell könnte man das noch weiter auf die Spitze treiben und mehrere Filter POPs einrichten und Anycast konfigurieren - Bandbreiten jenseits x * 100Gbit zu filtern, wäre damit auch kein Thema mehr, vorrausgesetzt man kann die Commitments und die Uplinks bezahlen :D

Accelerated blackholed die angegriffene Ziel IP doch nur? Oder deployen die inzwischen auch gleich ACLs auf Ihren Routern, welche UDP Traffic auf bestimmten Source- / Destination Ports filtern? Die großen Bandbreiten jenseits 10Gbit kriegt man damit zwar in den Griff, Synfloods im Gigabit Bereich mit mehreren mpps jedoch wohl kaum...
 
In dem Sinne nicht, stimmt. Es ist klug eingesetzt aber eine sehr günstige "Vorstufe" einer tatsächlichen Filterung von bösem Traffic und reicht zumindest bislang stressfrei aus, obwohl es immer mal wieder Attacken im Bereich von 10-20 GBit/s gibt, was ja nun auch nicht ganz wenig ist.

Bei betroffenen Systemen werden entsprechend viele A-Records im DNS mit einer sehr niedrigen TTL hinterlegt, wobei eine Eigenentwicklung noch vor Nullrouting angegriffene IPs automatisch rausnimmt. Attacken, die niedrige Bandbreite haben aber anderweitig "Probleme" erzeugen (sei es durch absurd hohe PPS oder fragmentierte UDP-Pakete und ähnlich böse Sachen), können immer auf dem Zielsystem mit 1-3 Intel-NICs per iptables gefiltert werden.

So erreichen wir auch bei heftigeren Attacken allenfalls Hänger von ca. einer Minute, und dann ist wieder Ruhe.

Ergänzung: Wenn man nur auf dem Zielsystem filtern kann, empfiehlt es sich, Traffic bei Erkennung einer Attacke mitzuschneiden. So kann man bei Notwendigkeit im Nachhinein seine Regeln verbessern. Das ist aber zumindest bei uns seltenst notwendig, meistens wird mit den erwähnten 10-20 GBit/s eine IP "abgeschossen" und dann kommt nichts mehr.
 
You must log in or register to reply here.
Back
Top