Wie man sich selbst per DOS angreift

Wie man sich selbst per DOS angreift

Eventuell hat es der ein oder andere am Wochenende mitbekommen: Wir hatten einige Probleme was die Stabilität der Verbindungen im Netzwerk anging.

Am Freitag hatten wir einige Software-Upgrades auf unseren Core-Routern durchgeführt, weshalb wir dies erst auf die neue Software und die Neustarts im Netz schoben. Doch die Ausfälle hörten auch nach dem Abschluss der Arbeiten nicht auf.

Der Grund waren einige Meldungen unserer Core-Geräte wie diese

vaih-core-1 dc-pfe: PANIC PANIC PANIC PANIC PANIC PANIC

oder auch diese

vaih-core-2 fpc0 SCHED: Thread 24 (PIC Periodic) ran for 1914 ms without yielding

Bei dem Betrieb der Geräte äußerte es sich dabei so, dass diese stockten, nicht mehr reagierten und dann teilweise auch nicht mehr erreichbar waren. Das führte dann wiederum dazu, dass das Routing im Netzwerk auf die Backup-Wege umschwenkte.

Kurz danach war das Gerät dann wieder erreichbar und das Routing schwenkte wieder auf die Hauptleitungen. Das ganze wiederholte sich dann teilweise 3-20 mal über eine Zeitspanne von teilweise nur 30 Sekunden bis 20 Minuten.

Ursachenforschung

In den Logs sah man teilweise die DDOS-Protection anschlagen, wiederholende Meldungen wie die oben und sterbende OSPF-/BGP-Prozesse.

Problematisch war das sehr sporadisch Auftreten des Problems, was die Fehlersuche nicht so einfach machte, da man dauerhaft am Gerät sein musste um während einer Unterbrechung noch Befehle abzusetzen oder Log-Dateien auszulesen, bevor diese wieder vorbei war.

Anfangs war eine Vermutung, dass es eine Diskrepanz zwischen unseren beiden NAT-Servern gibt, da vor den Systemupgrades der Traffic über das eine Gerät ging, danach über das andere. Dies wurde kurz danach aber bereits widerlegt, da auch das andere Gerät die Probleme zeigte.

Da dies nicht die Ursache war ein weiteres mögliches Problem die Verbindung zwischen den Routern und dem NAT, aber auch das konnte ausgeschlossen werden.

Von Beginn an war relativ klar, dass die aktivierte DDOS-Protection nur ein Symptom und nicht die eigentliche Ursache war, da es bei dem Juriper-Bug ähnlich aussah. Also haben wir wie bei jenem Bug auf dem NAT die Pakete die weitergeleitet wurden mal angesehen als sich ein weiterer Ausfall ankündigte.

Das Ergebnis waren viele Pakete an event.selfnet.de, die öffentliche IPV4 NAT-Adresse für u.a. das Event-WLAN. Insgesamt 2,2% bei den knappen 3 Sekunden die wir uns ansahen. Die Pakete bestanden aus UDP Paketen mit kaum Inhalt und relativ viel NTP. Das machte uns schon etwas stutzig. UDP könnte man sich eventuell noch erklären wenn irgendwo das WLAN noch aktiv wäre, auch wenn kein Event ist, aber NTP-Anfragen sollten da nicht aktiv hin geleitet werden.

Also haben wir uns angesehen, wo die Pakete herkamen. Einige Pakete kamen von einem vServer-Anbieter in Deutschland und die NTP-Pakete hauptsächlich von der China-Telecom. Hmmm… komisch, wieso sollten die bei uns NTP machen wollen…

Des Rätsels Lösung

Daraufhin wollten wir verifizieren, ob der Traffic überhaupt legitim ist und stellten fest, dass ein Ping an die öffentliche IP mit der Meldung “TTL expired” zurück kam. Das sollte im lokalen Netzwerk eher nicht so sein…

Beim weiteren Betrachten fiel dann auf, dass die IP-Pakete zwischen unseren Core-Routern (dem internen Netz) und den Edge-Routern (dem externen Netz) Ping-Pong spielten.

Der Edge-Router schickte die IP-Pakete zum NAT (wo sie ja auch hin sollten), das NAT hat diese aber nicht “übersetzt” auf eine interne IP aber schickte es trotzdem weiter und der Core schickte das ganze wieder zurück zum NAT, da die IP ja durchs NAT musste.

Und das ganze mit 40 GBit/s wobei die IP-Pakete zum Routing an die Routing-Engine weitergeleitet werden mussten. Im Endeffekt war das mit dem “DDOS-Violations” also schon richtig, wir haben unsere Router selbst mit 40 GBit/s gedost…

Daraufhin ist das Muster auch deutlich erkennbar geworden: Alle IPs aus dem Bereich für die internen SNAT-Dienste (wie eben das Event-WLAN) wurden im Kreis geschickt, da das NAT diese einfach weiterleitete, wenn es keinen passenden State von intern gab, zu den man die Anfrage zurück übersetzen könnte.

Damit wurde aus einem IP-Paket von extern eben bis zu 255 die mit 40 GBit/s zwischen den Geräten hin und her flogen. Wenn man nun noch bedenkt dass es in dem kurzen Zeitraum den wir uns ansahen knapp 4000 solcher IP-Pakete von extern waren kommt man auf etwa eine Million IP-Pakete intern… Irgendwo verständlich, dass dann der DDOS-Schutz anspringt und die Routing-Engine nicht mehr erreichbar ist.

Das die Routing-Engine der Geräte nicht mehr erreichbar war sorgte dann letztendlich dafür, dass die OSPF- und BGP-Sessions ausliefen. Das sorgte dann dominomäßig dafür dass dann im Routing viel umgestellt wurde und teilweise das Problem einfach den nächsten Router traf. Wenn die Routing-Engine wieder erreichbar war, gings wieder zurück auf Ursprung und wenn dann immernoch so viele IP-Pakete da waren, waren wir wieder am Anfang des Kreises und alles begann von neuem.

Der Fix

Nachdem wir dies erkannt hatten konnten wir die Pakete die nicht zum NAT passen am Ende der NAT-Regeln einfach verwerfen.

Dieser Fix wurde gestern Abend ~21 Uhr eingespielt und seitdem konnte wir keine weiteren großen Ausfälle feststellen.

Über die Ursache kann man nun nur spekulieren:

• War die neue Software schuld? Wird irgendwas anders interpretiert?
• Hat der Neustart der Geräte etwas ausgelöst?
• Hat jemand versucht herauszufinden ob unser Netz verwundbar ist?
• …?

Momentan kann man hier denke ich keine genauere Aussage treffen als die, dass letztendlich unser NAT falsch konfiguriert war.

Und die Moral von der Geschicht? Trau deinem eigenen NAT nicht!

Wir danken hiermit allen Mitgliedern, die bei der Fehlersuche und Problemlösung beteiligt waren. Auch wollen wir uns bei den Mitgliedern entschuldigen, die während dieser Zeit nicht auf die übliche Stabilität des Wohnheimnetzwerks zählen konnten.

Möchtest du in Zukunft bei Selfnet mitmachen und dich ehrenamtlich um solche und andere interessante technische Dinge kümmern? Um das Wohnheimsnetz ordentlich zu betreiben gibt es viele verschiedene Dinge zu tun: Verwaltung der Hardware (inkl. Neukauf von Hardware und mit dem Hersteller bezüglich Service arbeiten), Verwaltung von Servern und anderen Netzwerkdiensten, Analyse von Problemen oder neue Wohnheime an das Wohnheimnetzwerk anschließen.

Wenn du mitmachen möchtest geht es nicht um Vorwissen. Wichtiger ist es Spaß zu haben und noch etwas sinnvolles/praktisches neben dem Studium zu tun. Wenn du dich für Technik, Softwareentwicklung, Öffentlichkeitsarbeit, Projektmanagement oder vieles andere interessierst: Wir freuen uns dich bei uns begrüßen zu dürfen! Besuche einfach eine unserer Sprechstunden, (sobald diese wieder stattfinden.).

Das Selfnet-Team