Eingehenden Traffic begrenzen? Ist das möglich?

[trollolol]

Heyho ihr lieben,

Ich benötige mal Hilfe von richtig erfahrenen Serveradmins. Es kann sein das ich mit meinem Anliegen hier falsch bin, aber ein Versuch ist es dennoch wert. Vielleicht bekomme ich mein derzeitiges Problem geregelt.

Ich betreibe neben unserer Webseite einen kleineren Teamspeak Server. Dieser ist in den letzten Tagen Opfer mehrerer Volumetric Attacks geworden. Im Schnitt sind so pro Sekunde zwischen 60 und 70 MB/s eingehend eingegangen. Das hat den Server logischerweise in die Knie gezwungen. Ich weiß auch das es momentan einige Tsserver betrifft, und es keinen 100%igen Schutz gegen solche Attacken gibt.

Mein Hoster wirbt mit DDoS Schutz, aber ich glaube das Volumetric Attacks da wohl nicht darunter zählen.

Meine Idee ist, den eingehenden Traffic auf eine bestimmte Bandbreite zu beschränken. Die Fragen die sich hier auftun: Lohnt sich das überhaupt? Schieße ich mir damit möglicherweise ins Knie? Wenn ich den eingehenden traffic beschränke, sagen wir mal auf 500 kb/s ist natürlich die Grenze schnell erreicht, so daß User gedroppt werden könnten. Ich hoffe ihr wisst auf was ich hinaus will. Und wie sollte ich, wenn die Idee gut ist, das ganze bewerkstelligen? Am besten mit Boardmitteln. Eingesetzt wird ein Cloudserver mit 1 CPU und 2GB RAM mit Debian 12.2.

Vielen Dank im voraus.

[OlliTheDarkness]

Moin,
dass wird so nichts.
Softsite wirst da kein großen Erfolg haben.
Sowas sollte Hardwaremässig vor dem Server erfolgen oder über eine FW Appliance VM, wo der Traffic vor deinem Server durch muss.

Die TS Server haben doch eine Möglichkeit zur Bandbreitenbegrenzung ?! oder greift die nur fürs Filetransfer ?

Vieleicht (wäre ein Bordmittel) hilft dir Trickle auch weiter, durchfuchsen musst dich da ggf. leider selbst.

Man könnte sich auch mit WS, F2B etc. selbst was bauen um den Traffic zu überwachen und ggf. einzugreifen.
Allerdings würde das denk ich deinen Aufwand / Nutzen Faktor übersteigen.

Davon ab , dass der Cloudserver dafür etwas schwachbrüsstig wäre ^^

Im übrigen zählen Volumetric Attacks durchaus zur Klasse der DDOS Angriffe.

[Tobi]

Das spielt keine Rolle.

Selbst wenn es dir gelänge die Bandbreite für einzelne Clients zu beschränken, käme dein Angreifer eben mit 1000 statt 100 Bots. Jede Reaktion erzeugt hier eine Gegenreaktion.

Meine aktuelle Empfehlung ist:
Die komplette IP Range von AWS und Hetzner per Firewall sperren. Dann ist schon gewaltig Ruhe aufm Server.

[Daniel]

Hallo,

was ist es denn explizit für Traffic?
Ich vermute, es handelt sich entweder um dns/ntp oder einfach nur "irgendwelchen" anderen udp Traffic.
Wenn dies dann bekannt ist, einfach mal ein Ticket beim Hoster eröffnen und fragen ob der den jeweiligen Ports/Protokolle verwerfen kann oder manuell die IPs von deinem Server über die Mitigation schickt.

Wenn nicht, wäre es auf jeden Fall ratsam mittels "iptables" in Kombination mit "ipset" ausschließlich Traffic
aus der DACH-Region (Deutschand/Österreich/Schweiz) bzw. deiner Zielgruppe freizugeben.
Alles andere -> DROP. Unter Umständen läuft der Angriff zwar weiter und erhöht die Last, 70 MB/s sind für so einen vServer durchaus ordentlich, je nach Hardware und Art des Angriffs aber auch machbar mit Einschränkungen.

Bei den meisten Hostern ist der Traffic unlimited, sofern es dich nicht weiter stört und keine Beeinflussung auf deinen Server ist - einfach "laufen lassen". Stört es den Hoster z.B. wegen Beeinflussung anderer Kunden auf dem Hostsystem, dann sollte er in dem Falle von selbst den Traffic mitigieren - erst Recht wenn damit offen geworben wird.

Wird der teamspeak service direkt selber mit udp beschossen, so kannst du versuchen mit einem zeitlich begrenzten kurzen tcpdump dir die Eigenheiten der Pakete anschauen und ggf. ähnliche Pakete, welche vom regulären Traffic abweichen spezifisch verwerfen. Beispiel: fragmentierte Pakete, spezifische Länge, source Ports.

[trollolol]

Moin,
dass wird so nichts.
Softsite wirst da kein großen Erfolg haben.
Sowas sollte Hardwaremässig vor dem Server erfolgen oder über eine FW Appliance VM, wo der Traffic vor deinem Server durch muss.

Die TS Server haben doch eine Möglichkeit zur Bandbreitenbegrenzung ?! oder greift die nur fürs Filetransfer ?

Vieleicht (wäre ein Bordmittel) hilft dir Trickle auch weiter, durchfuchsen musst dich da ggf. leider selbst.

Man könnte sich auch mit WS, F2B etc. selbst was bauen um den Traffic zu überwachen und ggf. einzugreifen.
Allerdings würde das denk ich deinen Aufwand / Nutzen Faktor übersteigen.

Davon ab , dass der Cloudserver dafür etwas schwachbrüsstig wäre ^^

Im übrigen zählen Volumetric Attacks durchaus zur Klasse der DDOS Angriffe.

Das habe ich mir fast gedacht. Der Aufwand ist viel zu hoch. Das Problem ist ja "nur" das einem die Leute wegrennen :/

Das spielt keine Rolle.

Selbst wenn es dir gelänge die Bandbreite für einzelne Clients zu beschränken, käme dein Angreifer eben mit 1000 statt 100 Bots. Jede Reaktion erzeugt hier eine Gegenreaktion.

Meine aktuelle Empfehlung ist:
Die komplette IP Range von AWS und Hetzner per Firewall sperren. Dann ist schon gewaltig Ruhe aufm Server.

Da ich bei dem großen H bin, würde ich mir wahrscheiunlich auch wieder selbst ins Knie schießen, da ich mehere Server laufen habe, die alles mit dem TS verbunden sind

Aber AWS könnte vielleicht schon was bringen.

[trollolol]

Hallo,

was ist es denn explizit für Traffic?
Ich vermute, es handelt sich entweder um dns/ntp oder einfach nur "irgendwelchen" anderen udp Traffic.
Wenn dies dann bekannt ist, einfach mal ein Ticket beim Hoster eröffnen und fragen ob der den jeweiligen Ports/Protokolle verwerfen kann oder manuell die IPs von deinem Server über die Mitigation schickt.

Mein Hoster hat mir gerade mitgeteilt, das es eingehende UDP Attacken, vermutlich auf dem TS Standardport sind. Da aber ausgerechnet der Standardport UDP benötigt, wäre es doof diesen zu sperren.

Ich habe auf Dein anraten jetzt mal ein Ticket aufgemacht, ob die die IP von mir manuell mitigieren können. Mehr wie nein sagen können die nicht. Wobei H mir auch mitgeteilt hat, das es keinen Layer 7 Schutz gibt :/

[Tobi]

Verbunden ist nicht gleich verbunden.
Die Frage ist ob die anderen Hetzner Server ungefragt Anfragen an deinen Server stellen.

Außerdem kannst du eigene Server von der Sperre natürlich ausnehmen.

Aber frage dich selbst: warum sollte ein fremder Hetzner Server deinen Server kontaktieren wollen? Bei TS würde man typischerweise Dial-In IPs erwarten. Vorzugsweise aus dem eigenen Sprachraum.

[trollolol]

Da hast du wohl recht. Ich werde mich mal mit nem anderen Anbieter zusammensetzen und gucken ob die mir besseres anbieten können. Wobei, H hatte ich noch nie Ausfälle

[Tobi]

KeyWeb ist immer eine Empfehlung wert!
Bereits ab 13 EUR inklusive KeyHelp PRO!

https://www.keyweb.de/de/bestellen?type=rvs&id=VS-S

[trollolol]

KeyWeb ist immer eine Empfehlung wert!
Bereits ab 13 EUR inklusive KeyHelp PRO!

https://www.keyweb.de/de/bestellen?type=rvs&id=VS-S

Sehr gut . Ich brauch für den Teamspeak einen komplett nackten Server .

@all:

Mir ist noch ne Idee gekommen: der TS läuft ja auf 1 CPU mit 2 GB RAM. Der RAM ist nicht das Problem, der hat nix damit tun und Popelt sich in der Nase. Aber zu den Zeitpu kten des Angriffs war die CPU Last bei 2.22. Wenn ich mir jetzt 2 CPU oder 4 CPU Upgrade mache sollte es doch eigentlich funktionieren, oder?

H hat mir im übrigen geantwortet:

Code: Select all

Wenn wir eine Mitigation für Ihren Server ausführen, nach welchen Kriterien sollen wir erwünschten von unerwünschten Datenverkehr unterscheiden? Welche Verbindung zu Ihrem Server ist dann valide?

Ja, welche Verbindungen sind dann valide? Rein theoretisch ja alle, bis auf die die hohen eingehenden traffic jenseits der 10 MB verursachen.

[Daniel]

Hallo,

die "load" setzt sich nicht nur aus der CPU-Auslastung zusammen. In Verbindung mit Angriffen wird je nach Art des eigehenden Traffics der Kernel vom System selbst weiteres Arbeiten am System verhindern. Problematisch sind dann die Interrupts. Hier hilft dann auch die Firewall vom System nicht mehr denn diese ist Bestandteil des Kernels und kann unter Umständen die Interrupts weiter in die Höhe treiben. Abhilfe schafft hier vorgelagerte Hardware.

Bisher ist offenbar noch unbekannt "was" hier direkt angegriffen wird. Eine Vermutung auf den Zielport oder überhaupt das Protokoll macht die Umsetzung eines potentiellen Filters für dich bzw. unseren Marktbegleiter unmöglich.

Mitigation funktioniert hier nicht auf Zuruf "alles über 10 MB/s". Es werden global für die Netzsegmente Schwellwerte festgelegt und ausgewertet.
Anhand von Paketraten, Protokollen, Ziel/Quellports, Bandbreite, Flags, Fragmentierungen, etc.
Werden die Schwellwerte nicht erreicht, weil Traffic mit 1-30 MB/s pro IP-Adresse im RZ/ISP Umfeld nunmal nicht selten sind, wird auch nichts gefiltert.
Auch Paketraten im mittleren bis hohen 5-stelligen Bereichen sind oft legitim.

Daher auch die korrekte Frage von dem Kollegen, was explizit unterschieden werden soll. Eine Anmerkung: Es ist in der Praxis untypisch, dass hier auf Wunsch unzählige verschiedener ACLs implementiert werden - daher solltest du im Vorfeld bereits wissen, was "gefiltert" bzw. zugelassen werden soll.
Hierzu bitte meine Hinweise vom "Di 14. Nov 2023, 13:21" beachten.
Vielleicht kannst du das Problem auch mit den daraus gewonnen Erkenntnissen auch auf deinem Server selbst mit Bordmitteln lösen.

https://ipset.netfilter.org/ipset.man.html - hints: hash:net
https://www.ipdeny.com/ipblocks/ - hints: DACH (möglicherweise?)
https://ipset.netfilter.org/iptables.man.html - hints: hitcount, limit, limit-burst, connlimit, --log-prefix, -J LOG, length, source-ip, source-ports
https://www.tcpdump.org/manpages/tcpdump.1.html

Code: Select all

tcpdump -G 5 -W 1 -w /root/tcpdump-%Y-%m-%d_%H.%M.%S -n -i INTERFACE

(für export in whireshark)
bzw.

Code: Select all

timeout 5 tcpdump -n -i INTERFACE

[trollolol]

Bisher ist offenbar noch unbekannt "was" hier direkt angegriffen wird. Eine Vermutung auf den Zielport oder überhaupt das Protokoll macht die Umsetzung eines potentiellen Filters für dich bzw. unseren Marktbegleiter unmöglich.

Mitigation funktioniert hier nicht auf Zuruf "alles über 10 MB/s". Es werden global für die Netzsegmente Schwellwerte festgelegt und ausgewertet.
Anhand von Paketraten, Protokollen, Ziel/Quellports, Bandbreite, Flags, Fragmentierungen, etc.
Werden die Schwellwerte nicht erreicht, weil Traffic mit 1-30 MB/s pro IP-Adresse im RZ/ISP Umfeld nunmal nicht selten sind, wird auch nichts gefiltert.
Auch Paketraten im mittleren bis hohen 5-stelligen Bereichen sind oft legitim.

Das ist ja das Problem. Hier liegt die Vermutung nahe, das es auf dem TS Standardport zu Traffic Attacken kam. Aber wie gesagt, nur eine Vermutung. Das gleiche das Du im 2ten Abschnitt geschrieben hast, hat mir auch H so mitgeteilt.

Ich fürchte nur fast, dass es bei anderen Anbietern mit einem DDoS Schutz auch nicht anders aussieht, also kann ich auch bei H bleiben. Deswegen meine Idee, einfach mehr Cores auf den Server zu mieten. Aber wenn das auch nix bringt, dann ist der Aufwand/Nutzen Faktor für mich eher kontraproduktiv.

Ich bedanke mich für Euren Einsatz und Hilfe und besonders für die ausführlichen Informationen und Hilfestellungen von Daniel, mit der ich mich, wenn mal mehr Zeit verfügbar ist, annehmen werde.