Netcup down
- Thread starter virtual2
- Start date
BGP ist aber da...
Letztes Update vor 13min
Code:
flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I*> 5.45.96.0/20 (gateway vom provider) 350 50 33891 3.932 iLetztes Update vor 13min
Laut Tiscali Routeserver ist die Route über Core-Backbone zu Netcup seit 00:41 massiv am flappen
Komisch, dass die Netcup Mitarbeiter das nicht bemerken. Normalerweise müsste das Monitoring dort mittlerweile ununterbrochen bimmeln.
Habe hier 6ms via Core-Backbone RZ2. Normal ist das nicht, id.R. liegt die Latenz bei rund 0,7ms.
Naja, ICMP wird *normalerweise* per Software geroutet, nicht per Hardware (ASICs). Das zeigt sich dann halt auch in der Latenz, wenn die CPU des jeweiligen Routers recht viel zu tun hat
Trotzdem kann ich die Aussage so nicht unterschreiben. Vielleicht sind auch die Router die Routingtable neu am berechnen? Immerhin 400000 routen mit 2 Upstreams wären das 2x400'000 routen was schon einiges ist... Nicht alle setzen auf Hardware Routing mit ASIC ;-) Aber kann das nicht beurteilen da ich ned weiss was die im Einsatz haben...
Last edited by a moderator:
Genau kann man`s ohne Zugriff auf die Router nicht sagen
Ich denke mal, dass sich von Netcup hier sicherlich bald jemand melden wird, was genau los war Laut Tiscali Routeserver ist die Route über Core-Backbone zu Netcup seit 00:41 massiv am flappen
Komisch, dass die Netcup Mitarbeiter das nicht bemerken. Normalerweise müsste das Monitoring dort mittlerweile ununterbrochen bimmeln.
Woher nimmst du die Basis für diese Aussage?
[netcup] Felix
New Member
Guten Morgen,
leider kam es letzte Nacht zu einem DDoS-Angriff mit massiver Bandbreite und einer daraus resultierenden schlechten Erreichbarkeit unserer Infrastruktur in Nürnberg. Bis wir die betroffenen IP-Adressen ausfindig machen und sperren konnten, kam es zu einem sogenannten BGP-Flapping, was zu einer Gesamtausfallzeit von ca. einer Stunde führte.
Warum auf netcup-status.de keine entsprechende Meldung zu sehen war prüfen wir aktuell. Ich vermute das die zwei Mitarbeiter die zu der späten Stunde den Ausfall bearbeitet haben so stark mit der Ausarbeitung einer Lösung beschäftigt waren, dass sie vergessen haben netcup-status.de zu bearbeiten. Als verantwortlicher Geschäftsführer der netcup GmbH bitte ich dafür um Entschuldigung. Das ist kein zufriedenstellender Zustand und hier müssen wir uns definitiv verbessern.
DDoS-Angriffe nehmen insgesamt zu. Dieses beobachten nicht nur wir, sondern auch andere ISP. Wir sind uns dieses Problem bewusst und arbeiten bereits an Lösungen:
+ Sehr kurzfristig werden wir einen weiteren 10 GBit/s-Uplink in Betrieb nehmen. Die Verträge dafür wurden bereits am Freitag unterzeichnet.
+ Wir sind dabei unsere Software die Angriffe erkennt zu verbessern. Gerade bei dem hier beschriebenen Angriff hat es zu lange gedauert (mehrere Minuten) bis klar war, welche IP-Adressen gesperrt werden müssen.
+ Kontinuierlich rüsten wir nicht nur unsere Uplinks auf, sondern auch unser internes Backbone. Uns ist bewusst das dieses immer größere Bandbreiten verarbeiten können muss.
Am Montag werden wir uns bzgl. solcher DDoS-Attacken, Lösungsansätze und interne Arbeitsabläufe beraten. Wir werden Sie in unseren News über jede Verbesserung die wir Ihnen anbieten können informieren.
Bei Fragen stehe ich Ihnen selbstverständlich gerne zur Verfügung.
Mit freundlichen Grüßen
Felix Preuß
leider kam es letzte Nacht zu einem DDoS-Angriff mit massiver Bandbreite und einer daraus resultierenden schlechten Erreichbarkeit unserer Infrastruktur in Nürnberg. Bis wir die betroffenen IP-Adressen ausfindig machen und sperren konnten, kam es zu einem sogenannten BGP-Flapping, was zu einer Gesamtausfallzeit von ca. einer Stunde führte.
Warum auf netcup-status.de keine entsprechende Meldung zu sehen war prüfen wir aktuell. Ich vermute das die zwei Mitarbeiter die zu der späten Stunde den Ausfall bearbeitet haben so stark mit der Ausarbeitung einer Lösung beschäftigt waren, dass sie vergessen haben netcup-status.de zu bearbeiten. Als verantwortlicher Geschäftsführer der netcup GmbH bitte ich dafür um Entschuldigung. Das ist kein zufriedenstellender Zustand und hier müssen wir uns definitiv verbessern.
DDoS-Angriffe nehmen insgesamt zu. Dieses beobachten nicht nur wir, sondern auch andere ISP. Wir sind uns dieses Problem bewusst und arbeiten bereits an Lösungen:
+ Sehr kurzfristig werden wir einen weiteren 10 GBit/s-Uplink in Betrieb nehmen. Die Verträge dafür wurden bereits am Freitag unterzeichnet.
+ Wir sind dabei unsere Software die Angriffe erkennt zu verbessern. Gerade bei dem hier beschriebenen Angriff hat es zu lange gedauert (mehrere Minuten) bis klar war, welche IP-Adressen gesperrt werden müssen.
+ Kontinuierlich rüsten wir nicht nur unsere Uplinks auf, sondern auch unser internes Backbone. Uns ist bewusst das dieses immer größere Bandbreiten verarbeiten können muss.
Am Montag werden wir uns bzgl. solcher DDoS-Attacken, Lösungsansätze und interne Arbeitsabläufe beraten. Wir werden Sie in unseren News über jede Verbesserung die wir Ihnen anbieten können informieren.
Bei Fragen stehe ich Ihnen selbstverständlich gerne zur Verfügung.
Mit freundlichen Grüßen
Felix Preuß
d4f
Kaffee? Wo?
Ich will eure Anstrengung ja nicht schlecht reden aber in Zeiten wo man 30Gbs Angriffskapazität im Monats-"Abo" zu kaufen kriegt ist das Bereitstellen eines 10Gbs Uplink als DDoS-Puffer doch etwas mau.
Laut Prolexic ist der Durchschnitt von Angriffen im dritten Quartal zwar "nur" etwa 3Gbs gewesen aber mit den fallenden Preisen und Masse an ungeschützten DNS/Chargen-Hosts ist Bandbreite so schnell weg...
Finde ich gut, dass hier direkt der GF von Netcup ein Statement abgibt - sowas sieht man nicht immer
Meist nicht mal. Ich habe Angriffe gesehen, die haben einfach wie wild Pakete produziert, die auf Sourceports gingen (das hört sich komisch an, war aber so) - mit ein bisschen iptables/ebtables gefrickel und einem ordentlichen Uplink kein Problem.
Da es offensichtlich zu lange gedauert hat das Problem in den Griff zu bekommen. Sobald ein so großer Angriff läuft, schicke ich die IP des Kunden in`s Blackholing oder teile den Transit Partnern mit, dass Sie das /32 nicht mehr routen sollen - das hilft alles nix.
Meist nicht mal. Ich habe Angriffe gesehen, die haben einfach wie wild Pakete produziert, die auf Sourceports gingen (das hört sich komisch an, war aber so) - mit ein bisschen iptables/ebtables gefrickel und einem ordentlichen Uplink kein Problem.
Da es offensichtlich zu lange gedauert hat das Problem in den Griff zu bekommen. Sobald ein so großer Angriff läuft, schicke ich die IP des Kunden in`s Blackholing oder teile den Transit Partnern mit, dass Sie das /32 nicht mehr routen sollen - das hilft alles nix.
Last edited by a moderator: