Du schreibst, dass Provider untereinander nur mit BGP reden und kommst daher zu dem (falschen) Schluss, dass es keinen übergreifenden Mechanismus gibt. Auch wenn die Provider untereinander sich mit BGP koordinieren, bleiben die DiffServ-Informationen im IP-Header (DS-Field) ja erhalten. Die werden imHeader normal mitgeroutet, auch wenn ein Router in der Tat dazwischen in deinem QoS-Modell keine Rolle spielt. Wobei wir möglicherweise an diesem Punkt uns missverstehen, denn ich habe gesagt, dass die Gegenstelle (z.B. Bot-Rechner) kein QoS können muss. Aber jeder Backbonerouter dazwischen weiss was mit DSCP anzufangen, auch wenn er es selbst nicht umsetzen oder modifizieren muss. Dein Ziel ist es nun, den Wert im DS-Feld bei den entsprechenden Paketen zu setzen, in deinen Aussenroutern kannst du das zügig selbst machen, da man in solchen Umgebungen meist welche hat, die PBR unterstützen. Jetzt muss man nun noch möglichst seine Carrier dazu bringen (dazu kommen wir gleich), dies ist aber nur dann notwendig, wenn die Zuleitungen vom Carrier dicht sind. (Meistens ist dies aber auch nicht der Fall, da für erfolgreiche DDoS-Attacken meist viele kleine Pakete ausreichen, besonders da die Angreifer vermehrt in tiefere Schichten gehen, um z.B. über korrupte Anfragen den Server unter Last zu setzen.)
Blutschlumpf schrieb:
In der Theorie mag deine These teilweise funktionieren, die Praxis entspricht aber exakt Variante #1.
Meine "These" ist das was wir in der Praxis machen und damit keine These mehr. Und in der Praxis machen wir nicht Variante #1. Was natürlich nicht zwingend bedeutet, dass es alle Einrichtungen und Unternehmen so handhaben müssen, aber jeder der auf IT-Dienste angewiesen ist und es dabei um große Summen geht, macht sich darüber Gedanken und trifft Maßnahmen.
Und keine größeren Provider die das unterstützen (von ner manuellen ACL auf Support-Anfrage mal abgesehen).
Für meinen Heimanschluss kann ich sicherlich nix machen, auf Arbeit habe ich die Rufnummern unserer Carrier mit denen ich dann einfach mich abstimme, telefoniere.
Womit wir wieder bei den Prozessabläufen wären, die mit solchen Übungen wie in der News geübt werden sollen.
Zudem verkennst du, dass nicht ein Provider reicht der dir als Kunde die Möglichkeit gibt Traffic gezielter als per Destination-IP zu droppen oder anders zu priorisieren. Mal angenommen da gibt es den ein oder anderen (was die Ausnahme darstellen dürfte), dann verlagerst du das Problem nur an dessen Außenanbindungen.
Das ist richtig. Aber es verbessert dennoch deine Situation und die des Carriers. Denn dein erstes Ziel ist es, bei dir die Netzlast zu verringern und Kollateralschaden bei anderen Diensten zu vermeiden. Die Erreichbarkeit des eigentlich angegriffenen Dienstes für alle Clients weltweit ist dagegen nur sekundär. Zuerst erhältst du die Arbeitsfähigkeit deines Unternehmens oder deiner Einrichtung. Danach analysierst du die Art des Angriffes und baust dir aus verschiedenen Ansätzen eine Methode zusammen, mit der auch der Dienst möglichst wieder erreichbar wird, sofern der Angriff noch anhält oder es sich abzeichnet, dass er sich wiederholt.
Weil du bei einer gut gemachten Attacke nicht zwischen gut und schlecht unterscheiden kannst. Heute flooded in der Regel keiner mehr stupide mit einer einzigen un-gespoften Source auf die IP des Ziels. Spätestens wenn sekündlich ne Millionen Pakete von Random-Sources mit Syn-Flag verteilt auf mehrere Ziele ankommen, wirst du Probleme bekommen da zwischen nem Verbindungsversuch eines Surfers und bösem Traffic zu unterscheiden.
Hier kannst du mit Baselining arbeiten. Wenn von einer normalen IP üblicherweise x Anfragen kommen, wirst du sehen dass bei einer DDoS-Attacke von sehr vielen Adressen Anfragen kommen deren Anzahl messbar größer als x ist. Auch wenn ein Botnetz in mehrere Millionen geht, eine Liste mit einer solchen Anzahl ist automatisiert erstellbar. Denn jeder Angreifer muss nur einmalerfasst werden, egal wieviele Mio Pakete er sendet. Ein Ansatz: sinngemäß wird von jeder IP gedroppt, wo mehr Anfragen als üblich kommen. Das schafft deinem Server wieder Luft und führt dazu, dass er vermehrt sinnvolle Anfragen abarbeitet. Der Botnetzbetreiber müsste jetzt seine Bots mit geringerem Volumen anfragen lassen, um durchzukommen. Da kommst du dann aber schon wieder auf einem üblichen Level an, der durch deine Dimensionieung abgedeckt sein muss.
Ja, mit modernen Routern allein kommt man hier nicht weiter. Hier benötigst du spezielle Appliances und Konzepte. z.B:
http://www.cisco.com/en/US/prod/col.../ps5888/prod_white_paper0900aecd8011e927.html
Wenn z.B. der DDoS-Traffic auf die LoadBalancer-IP deines Webauftrites gerichtet ist, leitest du den Traffic mit Dest-IP des LoadBalancers per PBR über die Systeme, die den DDoS auswerten und übereifrige Source-IPs droppen. Es wäre ja zweckfrei, auch den Traffic an andere IPs ebenfalls darüber zu leiten, die nicht Teil des DDoS-Angriffs sind und man will die Teile ja auch nicht unnötig belasten.
Und ? Das Ziel des Angriffs (also Webserver xy) wäre damit ausgeschaltet und das Ziel des Angreifers erreicht. DU erreichst also maximal Schadensbegrenzung, also status quo.
Wie gesehen nicht ganz: ich erreiche im ungünstigesten Fall "nur" Schadenbegrenzung, aber maximal im besten Fall wieder einen normal verfügbaren Dienst.
Blutschlumpf schrieb:
Wenn weltweit x Clients Datenraten erzeugen die höher sind als meine Anbindungen über die ich deren Daten entgegennehme, dann müssen bereits die Provider und Carrier droppen.
Das sag ich doch, genau da ist der Punkt an dem der Angreifer faktisch gewonnen hat.
Wenn bei einer Attacke es also zu einer Saturation einer Zuleitung kommt - was nicht oft der Fall ist, wir reden hier schliesslich über Szenarien mit x0-GBit-Verbindungen - ist wie gesagt die Änderung der Klassifikation ein Ansatz. Ja, der angegriffene Server ist dann aus einigen Netzen nicht erreichbar, das ist aber wie gesagt nur dein Sekundärziel. Wenn die Angreifer die Leitungen nicht saturieren können, kannst du in der Summe mit der richtigen Strategie den Dienst auch nach aussen voll verfügbar halten.
Nochmal: es geht hier nicht darum, das "netzübergreifend automatisiert DDoS" geblockt wird. Denn wenn es das gäbe, bräuchte auch die EU diese Übung nicht. Hier geht es darum, zuerst den Schaden einzudämmen und dann den Dienst möglichst wieder verfügbar zu machen auch wenn die Attacke noch läuft. Genauso wie man dabei manchmal erfolgreich ist, ist man logischerweise manchmal auch nicht erfolgreich. In den Heise-Ticker schaffen es aber meist nur die nicht erfolgreichen Abwehr-Versuche, die dann sich logischerweise auf die User drausen auswirken. Denn wenn du erfolgreich bei Eindämmung und Abwehr bist, versuchst du unter dem Radar zu bleiben, um nicht noch mehr loszutreten.
Auch wenn es für die Diskussion unerheblich ist, nebenbei:
Auch wenn es makaber klingen mag: Solange ein ddos die eigene Infrastruktur nicht überlastet, bedeutet das mehr Traffic und oft damit auch mehr Einnahmen (Flat-Tarife sind in der Providerlandschaft nicht sehr verbreitet).
Richtig ist, dass Carrier untereinander abrechnen, sofern sich kein Gleichgewicht zwischen eingehendem und ausgehendem Trafic einstellt. Falsch ist das mit den Flat-Tarifen, zumindest in dem Segment hier. Wir buchen unsere Schnittstellen alle zu Pauschalpreisen. 10Gig/s Anschlüsse kosten zwar durchaus sechstellig pro Jahr, aber so oder so ergeben sich keine Mehreinnahmen für den Netzbetreiber durch zuviel Traffic, im Gegenteil sogar: wenn er durch die unnötig hohe Netzlast SLAs verpasst, kostet das ihn sogar Geld. Auch kleinere Geschwindigkeiten sind zu Pauschal-Preisen buchbar. Das ist aber schon seit einigen Jahren so. Früher wurde Traffic noch abgerechnet. Jetzt ist für Unternehmen die Vorhersehbarkeit der Kosten deutlich wichtiger.
:
