Online-Wahlkampf à la politnetz.ch
Saturday, 23. September 2006
Protokoll einer DDOS Attacke
von Fredy Künzler
Jetzt hat es uns auch mal erwischt. Seit Donnerstagabend ist ein Server eines Kunden unter starker DDOS Attacke (Distributed Denial of Service Attack). Das ist äusserst unangenehm und mit Nachtarbeit verbunden - doch davon später.
Was passiert: ein Botnet wählte sich die IP Adresse des Kunden als Ziel "zum abschiessen" aus. Diese Bots verursachen eine sehr hohe Zahl an ICMP Traffic, viel mehr als der Server jemals schlucken kann. Anders gesagt: die Bots pingen bis zum geht-nicht-mehr, mit dem Ziel, den Server in die Knie zu zwingen (Ping-of-Death).
Besagter Kundenserver macht im Normalbetrieb zwischen 4 und 10 Mbps Traffic. Zusammen mit ca. 30 anderen Servern war er an einem Cisco 7206VXR NPE-300 Router angeschlossen (ca. 80 Mbps Kapazität, FastE Ports), die Summe des Traffics aller Server an diesem Router war ca. 30 Mbps Outbound und vielleicht 5 Mbps Inbound. Also mehr als genügend Kapazität.
Durch die DDOS Attacke verfünfzigfachte sich der Inbound-Traffic quasi von einer Minute auf die andere. Der Router lief über seiner Kapazitätsgrenze, die Kundenserver waren offline. Dazu kam, dass ein STM-1 Link zum Init7-Backbone durch den hohen Inboundtraffic ebenfalls volle 155 Mbps abkriegte (Normalbetrieb ca. 30 bis 40 Mbps), was sich schlagartig auf schlechte Pingzeiten auswirkte. Einige Netze konnten aus dem Init7 Netz nicht mehr gut erreicht werden, und umgekehrt.
Hektik im NOC (der Chronist war zum Glück noch im Büro, trotz Feierabend). Weshalb plötzlich soviel Traffic, wer wird attakiert? Ist es ein Downstream-Kunde (gibt es immer mal wieder, unser Core Backbone hat es bisher locker weggesteckt)? Nach einiger Zeit war das Ziel der DDOS Attacke gefunden und vom Netz genommen, und das Zielnetz des Routers de-konfiguriert. Zumindest die nicht direkt betroffenen Kunden konnten aufatmen, nachdem einige Änderungen im Init7-Routing den Überlauf des STM-1 Links stoppten. Endlich Feierabend!
Anderntags stellten wir einige Analysen und Überlegungen an. Wie kriegen wir den Server wieder ans Netz? IP Adresse ändern? Keine gute Idee, das gibt bloss ein Katz-und-Mausspiel. Firewall? Noch dümmer. Wie soll eine handelsübliche Firewall mit soviel Traffic fertig werden, wenn sogar ein 7206VXR alle Viere von sich streckt? Filtern an den Backbone-Edges? Geht auch nicht vernünftig, weil die Attacke auf mehreren Edge Routern in unseren Backbone reinkommen. Einfach abwarten, bis sich das Botnet ein anderes Ziel in der weiten Welt sucht? Auch nicht praktikabel.
Hunderte von Bots, wenn nicht sogar mehr, auf der ganzen Welt verteilt. Man kann nicht einfach ein IP Filtering für jeden einzelnen Bot einbauen, da wären wir noch ewig dran. Ein Botnet ist wie eine Hydra, schlägt man ihr einen Kopf ab, wachsen zehn neue nach. Immerhin wissen wir inzwischen, dass die Attacke ein Traffic-Volumen von ca. 300 Mbps macht und in Wellen kommt.
Erst monitorten wir den DDOS Traffic auf den Zielserver mit Wireshark auf einem Monitor-Port des Cisco Switchs (wie man das macht steht bei nwlab.net). Dadurch finden wir raus, dass die Attacke tatsächlich auf ICMP beruht (und nicht auf UDP, wie erst angenommen) und die Bots keine regelmässige Struktur an IP Adressen aufweisen.
Schliesslich installieren wir einen zusätzlichen Gigabit Router (Cisco7301) nur für diesen einen Kunden. Die Trafficmessung ist sehr aufschlussreich (Kunde und alle IP Adressen / Hostnamen sind anonymisiert):
(Klick zum vergrössern)
Mit einem Policy-Routing bekommen wir schliesslich die Sache in den Griff. Der Kunden-Server ist wieder online, und der vorgeschaltete Cisco7301 sendet den ganzen DDOS ICMP Traffic zum Interface Null0. Die Konfiguration sieht so aus:
Vermutlich gäbe es noch andere Methoden, um die DDOS Attacke abzuwehren. Ob allerdings ein Rate-Limiting oder ein Packet-Filter ebenfalls so CPU-friendly mit dem Cisco ist, bezweifle ich sehr:
Ach ja: Storm-Control auf dem Switch ist ebenfalls nicht schlecht, immerhin kann man so die Auswirkungen auf Drittkunden einigermassen einschränken.
Und die Moral der Geschicht?
a) eine DDOS Attacke ist ein gutes Cisco Training
b) wir werden unsere Links noch mehr überdimensionieren müssen...
c) irgendeinem Skript-Kiddie war es wohl langweilig
d) den nächsten DDOS bitte anderswo, gell Sankt Florian
e) wegen der zweiten Nachtschicht hat der Chronist leider eine Veranstaltung von tanzinwinterthur verpasst
Jetzt hat es uns auch mal erwischt. Seit Donnerstagabend ist ein Server eines Kunden unter starker DDOS Attacke (Distributed Denial of Service Attack). Das ist äusserst unangenehm und mit Nachtarbeit verbunden - doch davon später.
Was passiert: ein Botnet wählte sich die IP Adresse des Kunden als Ziel "zum abschiessen" aus. Diese Bots verursachen eine sehr hohe Zahl an ICMP Traffic, viel mehr als der Server jemals schlucken kann. Anders gesagt: die Bots pingen bis zum geht-nicht-mehr, mit dem Ziel, den Server in die Knie zu zwingen (Ping-of-Death).
Besagter Kundenserver macht im Normalbetrieb zwischen 4 und 10 Mbps Traffic. Zusammen mit ca. 30 anderen Servern war er an einem Cisco 7206VXR NPE-300 Router angeschlossen (ca. 80 Mbps Kapazität, FastE Ports), die Summe des Traffics aller Server an diesem Router war ca. 30 Mbps Outbound und vielleicht 5 Mbps Inbound. Also mehr als genügend Kapazität.
Durch die DDOS Attacke verfünfzigfachte sich der Inbound-Traffic quasi von einer Minute auf die andere. Der Router lief über seiner Kapazitätsgrenze, die Kundenserver waren offline. Dazu kam, dass ein STM-1 Link zum Init7-Backbone durch den hohen Inboundtraffic ebenfalls volle 155 Mbps abkriegte (Normalbetrieb ca. 30 bis 40 Mbps), was sich schlagartig auf schlechte Pingzeiten auswirkte. Einige Netze konnten aus dem Init7 Netz nicht mehr gut erreicht werden, und umgekehrt.
Hektik im NOC (der Chronist war zum Glück noch im Büro, trotz Feierabend). Weshalb plötzlich soviel Traffic, wer wird attakiert? Ist es ein Downstream-Kunde (gibt es immer mal wieder, unser Core Backbone hat es bisher locker weggesteckt)? Nach einiger Zeit war das Ziel der DDOS Attacke gefunden und vom Netz genommen, und das Zielnetz des Routers de-konfiguriert. Zumindest die nicht direkt betroffenen Kunden konnten aufatmen, nachdem einige Änderungen im Init7-Routing den Überlauf des STM-1 Links stoppten. Endlich Feierabend!
Anderntags stellten wir einige Analysen und Überlegungen an. Wie kriegen wir den Server wieder ans Netz? IP Adresse ändern? Keine gute Idee, das gibt bloss ein Katz-und-Mausspiel. Firewall? Noch dümmer. Wie soll eine handelsübliche Firewall mit soviel Traffic fertig werden, wenn sogar ein 7206VXR alle Viere von sich streckt? Filtern an den Backbone-Edges? Geht auch nicht vernünftig, weil die Attacke auf mehreren Edge Routern in unseren Backbone reinkommen. Einfach abwarten, bis sich das Botnet ein anderes Ziel in der weiten Welt sucht? Auch nicht praktikabel.
Hunderte von Bots, wenn nicht sogar mehr, auf der ganzen Welt verteilt. Man kann nicht einfach ein IP Filtering für jeden einzelnen Bot einbauen, da wären wir noch ewig dran. Ein Botnet ist wie eine Hydra, schlägt man ihr einen Kopf ab, wachsen zehn neue nach. Immerhin wissen wir inzwischen, dass die Attacke ein Traffic-Volumen von ca. 300 Mbps macht und in Wellen kommt.
Erst monitorten wir den DDOS Traffic auf den Zielserver mit Wireshark auf einem Monitor-Port des Cisco Switchs (wie man das macht steht bei nwlab.net). Dadurch finden wir raus, dass die Attacke tatsächlich auf ICMP beruht (und nicht auf UDP, wie erst angenommen) und die Bots keine regelmässige Struktur an IP Adressen aufweisen.
Schliesslich installieren wir einen zusätzlichen Gigabit Router (Cisco7301) nur für diesen einen Kunden. Die Trafficmessung ist sehr aufschlussreich (Kunde und alle IP Adressen / Hostnamen sind anonymisiert):
(Klick zum vergrössern)
Mit einem Policy-Routing bekommen wir schliesslich die Sache in den Griff. Der Kunden-Server ist wieder online, und der vorgeschaltete Cisco7301 sendet den ganzen DDOS ICMP Traffic zum Interface Null0. Die Konfiguration sieht so aus:
!Das GigE0/1 Interface, woran der Kundenserver angschlossen ist, hat seit dieser Massnahme wieder ein normales Traffic-Verhalten:
interface GigabitEthernet0/0
ip address [ip address] [subnet]
ip verify unicast reverse-path
! [...]
ip policy route-map DDOSdrop
!
access-list 199 permit icmp any host [ip address Kundenserver]
!
route-map DDOSdrop permit 10
match ip address 199
set interface Null0
!
Vermutlich gäbe es noch andere Methoden, um die DDOS Attacke abzuwehren. Ob allerdings ein Rate-Limiting oder ein Packet-Filter ebenfalls so CPU-friendly mit dem Cisco ist, bezweifle ich sehr:
Ach ja: Storm-Control auf dem Switch ist ebenfalls nicht schlecht, immerhin kann man so die Auswirkungen auf Drittkunden einigermassen einschränken.
Und die Moral der Geschicht?
a) eine DDOS Attacke ist ein gutes Cisco Training
b) wir werden unsere Links noch mehr überdimensionieren müssen...
c) irgendeinem Skript-Kiddie war es wohl langweilig
d) den nächsten DDOS bitte anderswo, gell Sankt Florian
e) wegen der zweiten Nachtschicht hat der Chronist leider eine Veranstaltung von tanzinwinterthur verpasst
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
Ich war mal IRC-Operator und wir hatten auch mit einer solchen Attacke zu kämpfen.
Bald hatten wir die betreffenden IP's. Ich machte mich dran diese genauer zu analysieren.
Siehe da, die hatten alle kein Admin PW.
Also spazierte ich auf den Kisten rum und siehe da, ich fand das Botfile.
Ich dachte schon ich hätte das BotNet, doch leider war es ein anderes. Es hatte nichts mit unserem Attacker zu tun.
Die Suche ging weiter und wir konnten den Täter tatsächlich ausmachen.
Die Frage war natürlich, was man mit den Logs machen wollte.
Schlussendlich meldete sich der Gründer unseres Netzwerkes beim Angreiffer (war sozusagen die Konkurrenz)
Ein bisschen gutes zureden und die Attacken hörten auf.
Bald hatten wir die betreffenden IP's. Ich machte mich dran diese genauer zu analysieren.
Siehe da, die hatten alle kein Admin PW.
Also spazierte ich auf den Kisten rum und siehe da, ich fand das Botfile.
Ich dachte schon ich hätte das BotNet, doch leider war es ein anderes. Es hatte nichts mit unserem Attacker zu tun.
Die Suche ging weiter und wir konnten den Täter tatsächlich ausmachen.
Die Frage war natürlich, was man mit den Logs machen wollte.
Schlussendlich meldete sich der Gründer unseres Netzwerkes beim Angreiffer (war sozusagen die Konkurrenz)
Ein bisschen gutes zureden und die Attacken hörten auf.
lästig solche ddos attacken...meine letzte begegnung mit der spezies mensch, welche solche dinge aussführt, darf jetzt seine verursachten aufwände bei einer sozialen institution abarbeiten.
Fredy, wird in solch einem Fall der entstandene Traffic sowie der Arbeitsaufwand in Rechnung gestellt?
Man muss es von Fall zu Fall anschauen.
Wenn ein Server vom Kunden gehackt wird und seinerseits für DDOS Attacken missbraucht wird (also Outbound), dann scheint eine Rechnung angezeigt.
Für den Traffic (Inbound) werden wir nichts verrechnen, der Kunde kann ja nichts dafür. Als Massnahme dagegen könnte man ja einfach den Server abschalten und warten, bis sich das Botnet ein neues Ziel sucht.
Der Aufwand, um den Server trotz Beschuss online zu halten, kann man aber je nachdem schon in Rechnung stellen.
Wenn ein Server vom Kunden gehackt wird und seinerseits für DDOS Attacken missbraucht wird (also Outbound), dann scheint eine Rechnung angezeigt.
Für den Traffic (Inbound) werden wir nichts verrechnen, der Kunde kann ja nichts dafür. Als Massnahme dagegen könnte man ja einfach den Server abschalten und warten, bis sich das Botnet ein neues Ziel sucht.
Der Aufwand, um den Server trotz Beschuss online zu halten, kann man aber je nachdem schon in Rechnung stellen.
von Fredy Künzler Es scheint, als wäre der Computer von SF Meteo auch einer von 100 bis 150 Millonen, die bereits von Botnets übernommen worden sind, wie Vint Cerf (Google) am WEF behauptet hat (via Paperholic). Danke Reto fürs Bild. Gemäss BB
Aufgenommen: Jan 27, 23:57