Massive Serverangriffe - was tun?

[nyxus]

Was normalerweise nicht ser Sinn eines Sinkholes ist. Das dient meist dazu unbenutzte IP-Bereiche anzukündigen um dort Angriffe oder sonstigen IP-Müll anzuziehen und ihn dann analysieren zu können. Sinkholes schmeißen den Traffic nicht weg.

Sie Routen den Traffic in ein Privates Netz oder in ein abgeschlossenes Netz wenn sie Ihn analysieren wollen. Wo wäre also das Problem DDoS Packete auch als IP-Müll zu klassifizieren und umzuleiten. Der ISP spart auf jeden Fall last auf anderen Routern und auch seinen eigenen. Vom Prinzip her ist es das einfachste der Welt.

Der Provider spart nicht unbedingt Last, er verlagert sie. Zum Zwecke der Analyse ist das ok, und natürlich kann man auch den Attack-Traffic ins Sinkhole leiten, aber das macht man auch nur wenn man den Traffic auch analysieren will. Nach der Analyse sollten halt die Gegenmaßnahmen eingeleitet werden. Und das könnte dann z.B. Blackholing sein. Blackholes sind etwas anderes als Sinkholes.

Sprich, du sagst deinem ISP das dein Server unter einem DDoS leidet und bittest sie (vielleicht mit einer Tabelle der IP Adressen) diese zu blockieren, dann werden sie nicht mehr zu Server durchgestellt, allerdings wird wahrscheinlich der Traffic weiterhin gezählt.

Es sollte nicht nur das Ziel geblockt werden, das wäre schwachsinn und du kannst da ja gleich shutdown -h now eintippen ;)

Bei "shutdown -h now" wird je nach Angriff der Traffic aber weiter durch das Provider-Netz fließen, was schon ein Unterschied zum Blackholing ist. Dabei wird der Traffic normalerweise am PE weggeschmissen.

A better alternative would be to use a sinkhole tunnel. A sinkhole tunnel is implemented at all possible entry points from which attacks can pass into the destination/attacked AS.
...
This IP address belongs to the /30 subnet assigned to the tunnel connecting the border router to the sinkhole router.

Der Nachteil dabei ist, daß der Traffic doppelt fließt, und das Sinkhole sehr performant ausgelegt sein sollte. Denn wenn das Ziel ist den Traffic trotzdem zum Endkunden weiterzutransportieren, dann sollte nichts verloren gehen. Ein einfacherer Weg das zu erreichen, der auch jetzt schon eingesetzt wird, ist RSPAN.

Desweiteren ist das ungefähr das, was diese Traffic-Filter machen. Nur, daß dabei der gesamte Kunden-Traffic zum Filter umgeleitet wird, aber nur der als "normal" klassifizierte Traffic zurückfließt.

Ein solches Blackhole sollte erst aufgesetzt werden, wenn der Traffic analysiert wurde. Das sind allerdings sachen die der ISP macht.

Ein Blackhole (!) *muß* aufgesetzt sein bevor der Angriff startet. Dafür müssen die Router umkonfiguriert werden. *Genutzt* werden sollte das Blackhole nur nach der Analyse, daß wirklich ein Angriff vorliegt. Auch das von Dir zitierte *Sinkhole* muß natürlich vorher schon konfiguriert sein wenn man es nutzen will um den Traffic zu analysieren.

Ein Glück aber auch ... Wink

route add 207.46.250.119 tunnel0 ;)

Solange Du das in Deinem eigenen Netz machst ist das ja ok. Aber wenn jeder ISP-Kunde automatisch beim Provider seine Mitbewerber blocken könnte fände ich das - naja, sagen wir mal "problematisch". Denn darauf zielt das

Sprich, du sagst deinem ISP das dein Server unter einem DDoS leidet und bittest sie (vielleicht mit einer Tabelle der IP Adressen) diese zu blockieren, dann werden sie nicht mehr zu Server durchgestellt,

ja ab. Und man würde bei einem Source-based-Blackholing auch nicht nur den Traffic zu dem angegriffenen Server sperren, sondern auch zu allen anderen Kunden des Providers. Bei einem echten Angriff wäre das evtl. sogar wünschenswert, aber manche würde garantiert auch versuchen sowas auszunutzen. Davon abgesehen: *Wenn* der Provider Sachen wie Blackholing/Sinkholing etc. schon eingerichtet hat, dann bemerkt er den Angriff ganz sicher auch bevor es der Kunde macht.

[lord_pinhead]

Bei "shutdown -h now" wird je nach Angriff der Traffic aber weiter durch das Provider-Netz fließen, was schon ein Unterschied zum Blackholing ist. Dabei wird der Traffic normalerweise am PE weggeschmissen.

Wenn es nach deiner Erklärung geht, kann ich meinen Server ja nicht mehr erreichen, also ist die Methode die du wahrscheinlich meinst sinnlos und man braucht da gar nicht erst die Arbeit machen und es einzurichten. Solches einrichten wäre also schwachsinn und ich brauch mir gar nicht den ärger machen bei meinem ISP anzurufen und das zu melden, das meinte ich damit ;)

Der Nachteil dabei ist, daß der Traffic doppelt fließt, und das Sinkhole sehr performant ausgelegt sein sollte. Denn wenn das Ziel ist den Traffic trotzdem zum Endkunden weiterzutransportieren, dann sollte nichts verloren gehen. Ein einfacherer Weg das zu erreichen, der auch jetzt schon eingesetzt wird, ist RSPAN.

Desweiteren ist das ungefähr das, was diese Traffic-Filter machen. Nur, daß dabei der gesamte Kunden-Traffic zum Filter umgeleitet wird, aber nur der als "normal" klassifizierte Traffic zurückfließt.

Wobei das Mirrorn von Traffic auf den Port von RSPAN eigentlich genau das ist was man vorher mit umwegen gemacht wird. Sobald ich ein Blackhole aufsetze und Sourcebased Routing verwende, hab ich eigentlich genau soetwas wie RSPAN, ein paar Details ausgenommen. Das einrichten auf einem Monitorport wäre das schwierigste ohne RSPAN, aber möglich.

Das mit "vorher aufsetzen" ist jetzt die Frage, meinst du das aufsetzen des Zielnetzes? Dann ja, aber ein Provider wird kaum von sich aus den DDoS erkennen. Bei sowas muss ich die Leute ja immer mit der Nase drauf stoßen weil die nicht tausende von Rechner überwachen können. Das blockieren des Traffics anderer netze wäre dabei ein Kollateralschaden in meinen Augen, den andere Provider müssen auch reagieren wenn Ihnen das gemeldet wird. Das erkennen einer Wurmflut z.b. wäre ebenfalls ein Einsatzgebiet zum analysieren, zusammen mit Honeypots und IDS systemen. Wenn ein Kunde jetzt eine absolut verseuchte Kiste ins Netz bringt, gefährdet er andere einfach mit.

Man müsste auch nicht jeden Traffic in ein Blackhole umleiten, man könnte Filterregeln an Routern verwenden, um z.b. Kontaktaufnahme mit bestimmten Servern zu unterbinden damit ein Wurm sich kein Update holt. Wäre besser als einfach nur den Account auf den Updateservern zu löschen. Als man den Schutz vor IP Spoofing eingeführt hat, hat sicherlich auch jeder gesagt es sei unmöglich umzusetzen. Heute bekomm ich kein gespooftes Packet mehr ins Netz. Jedenfalls in Deutschland ;)

[nyxus]

Wenn es nach deiner Erklärung geht, kann ich meinen Server ja nicht mehr erreichen, also ist die Methode die du wahrscheinlich meinst sinnlos und man braucht da gar nicht erst die Arbeit machen und es einzurichten. Solches einrichten wäre also schwachsinn und ich brauch mir gar nicht den ärger machen bei meinem ISP anzurufen und das zu melden, das meinte ich damit ;)

Eigentlich ging es mir dabei nur darum, daß "shutdown -h" und blackholing *nicht* gleichzusetzen ist. Da war keine Wertigkeit drin weil Dir als Kunde normalerweise auch keine Wahlmöglichkeit gegeben ist. Runterfahren kannst Du die Kiste, Blackholing anstoßen aber nur der Provider.

Der Nachteil dabei ist, daß der Traffic doppelt fließt, und das Sinkhole sehr performant ausgelegt sein sollte. Denn wenn das Ziel ist den Traffic trotzdem zum Endkunden weiterzutransportieren, dann sollte nichts verloren gehen. Ein einfacherer Weg das zu erreichen, der auch jetzt schon eingesetzt wird, ist RSPAN.

Desweiteren ist das ungefähr das, was diese Traffic-Filter machen. Nur, daß dabei der gesamte Kunden-Traffic zum Filter umgeleitet wird, aber nur der als "normal" klassifizierte Traffic zurückfließt.

Wobei das Mirrorn von Traffic auf den Port von RSPAN eigentlich genau das ist was man vorher mit umwegen gemacht wird.

??? Was hat man früher mit Umwegen gemacht?

Sobald ich ein Blackhole aufsetze und Sourcebased Routing verwende, hab ich eigentlich genau soetwas wie RSPAN, ein paar Details ausgenommen. Das einrichten auf einem Monitorport wäre das schwierigste ohne RSPAN, aber möglich.

Du bringst laufend Blackholing und Sinkholing durcheinander:

Sinkhole: Traffic wird im Netz umgeleitet und an einen Router/PC gesendet, der die Daten dann analysieren kann. Beim Tunneled Sinkhole kann der Traffic nach der Analyse zum Kunden weiterfließen.
Blackhole: Der Traffic wird so früh wie möglich (in der Regel am PE-Router) weggeschmissen um ihn *nicht* weitertransportieren zu müssen.

RSPAN ist wenn überhaupt also nicht mit Blackholing vergleicbar, sondern mit getunneltem Sinkholing. Und Sinkholes betreibt man normalerweise auch Destination-based.

Das mit "vorher aufsetzen" ist jetzt die Frage, meinst du das aufsetzen des Zielnetzes? Dann ja, aber ein Provider wird kaum von sich aus den DDoS erkennen.

Sowohl für Blackholing, als auch für Sinkholing müssen die Router umkonfiguriert werden um es überhaupt nutzen zu können. Das kann man nicht machen wenn der Angriff schon läuft weil das keine Änderung ist, die man "mal eben so" machen kann. Wenn es erstmal konfiguriert ist, dann kann es sehr einfach genutzt werden. Und ein guter Provider (und einer, der sich schon mit solchen Sachen beschäftigt würde ich heute noch nicht zum Standard zählen) wird auch sein Monitoring entsprechend eingerichtet haben und einen richtigen Angriff selbst erkennen.

Man müsste auch nicht jeden Traffic in ein Blackhole umleiten, man könnte Filterregeln an Routern verwenden, um z.b. Kontaktaufnahme mit bestimmten Servern zu unterbinden damit ein Wurm sich kein Update holt.

Man kann vieles, aber *das* kann man im ISP-Netz normalerweise nicht. Hast Du mal in einem richtigen Netz einen change-Management-prozess durchlaufen? Filterregeln zu ändern ist eine Konfigurationsänderung (genau wie beim konfigurieren von RSPAN für nur einen Kunden). Black- und Sinkholing ist eine reine Routingänderung die bei weitem nicht so fehleranfällig ist wie eine Konfigänderung im Produktivnetz.