Selfnet Blog

Nov 30, 2020

How to DOS yourself

Deutsche Übersetzung weiter unten.

Maybe you have noticed it throughout last weekend - we had several issues with our network stability.

Friday we started upgrading software on several core routers. That's why we first thought the necessary reboots caused the problems. But the interruptions did not stop after the update was complete and even got worse.

A reason were several messages like this


or this

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

This caused lags, unresponsive and even unreachable devices. As we are using routing protocols to manage our traffic (OSPF and BGP) which require constant communication between the devices. As a result our devices can select the optimal path to send packets. So the unresponsive devices caused routing changes in the network protocols as the backups links took over.

As soon as the backup links took over the affected devices became reachable again and the routing changed back to the primary path. This repeated between 3 and 20 times and took between 30 seconds and 20 Minutes.

Finding the the Root Cause

The logs showed an activation of the devices DDoS-Protection measures, repeating messages like the ones above and dying OSPF- or BGP-connections.

The sporadic nature of this problem made it complicated to debug. You needed to be permanently present to notice the problem when it started and before it was over to run several commands to obtain log files and debug information.

First we thought there was a configuration difference between our two NAT servers, as the traffic was handled by one device when we started upgrading and by the other afterwards. But we could disregard this theory shortly after since the other device showed the same behaviour.

Another possible cause could have been the connection between the routers and the NAT servers but we were also able to verify that the setup was correct.

Directly after the incident started, it was more or less obvious for us the DDoS-Protection was just a symptom but not the cause. It was the same as with the Juriper-Bug. So we followed the same investigation pattern: Looking at the packets sent through the NAT when the lags started.

The result were a lot of packets to "", the public IPv4 NAT-Address for the wireless network we use at public events. Around 2.2% of the 3 seconds we took as a sample were directed to this IP. It was a mixture of UDP and a lot of NTP packets. This caused some concern. UDP could be explained with some former unknown - still active - access point. But there should be nobody using this IP for NTP updates.

So we looked at the source of the packets. Some were from a german vServer provider but the NTP-Packets originated mainly from China-Telecom... weird, why should they go around the globe to call us for a NTP update...

Solving the mystery

So now we wanted to verify it is legitimate traffic and found out: A simple ping to the public IPv4 Address returned with an error message "TTL expired" -- which should not happen in a local network...

Further lookups showed IP-Packets bouncing between our core routers (in the internal network) and the edge routers (in the external networks).

The edge routers sent the packets to our NAT (where they should go), but the NAT did not "translate" them. We expect those packets to be translated to the address of the host that opened the connection. Since there was no open connection, the packets should be dropped. But here, the NAT did forwrad the packets without translation. So an IPv4 packet arrived in our core network, that had a public IPv4 address as destination. Since we only use private address space inside the network, the routers have no route for this. So the packet gets forwarded in the direction of the default-route, which is: to the internet. So the packet gets sent back, though the NAT again. This time, the packet isn't expected to be translated, because it didn't originate inside our network and already has a public source address (from China Telecom). So our edge router receives the packet, and we start over. So these packets go back and forth, tens or maybe even hundrets of times, until their time-to-live expires.

To make matters worse all of that happened with 40 GBit/s between the devices while the packets still needed to be processed by the cores routing engine. So the "DDoS Violations" were correct, we DDoS'ed ourself with 40 GBit/s...

After this the pattern was clear to us: All IPs of our pool for internal SNAT (like the "Event" wireless network) were routed in a loop as the NAT did just forward them, even when there was no valid state from an internal IP.

So one packet from an external address was multiplied into (up to) 255 of them which were transmitted with 40 GBit/s between the devices. If you think about our observation before: We had 4000 Packets in 3 seconds. This times 255 translates to roughly a million packets in our internal network... Well, sounds reasonable the DDoS-Protection tried to protect the routing engine of the devices and it became unreachable.

But as the routing engine stopped responding, this caused the BGP- and OSPF-Sessions to die. This started a domino effect: Routing switched to the backup paths, other routers were impacted and when the first device became responsive again (since the load suddenly disappeared), the routing started to switch back to the primary connections - and caused the whole loop again.

The Fix

Finally we knew what we had to do: The packets that do not translate at the NAT should be dropped at the end of handling them.

The fix was applied yesterday around 9 p.m. and since then we haven't detect another larger disruption.

For the ultimate reason we can only speculate: * Was it the new Software? Is there a command or anything which is interpreted in a different way? * Did the reboot of our device change something? * Did somebody try to scan our network for vulnerabilities? * ...?

For now we can not say what is more likely. We can only say that our NAT was not configured in the correct way.

And the moral of the story? Do not trust your own NAT if you already have a history!

Thanks to all of our members who helped in any way to solve this problem. We also apologize to all users of our network, as it wasn't quite stable during the period of recognizing the bug and debugging it.

Do you want to participate in taking care of such problems in the future? For our network to run smoothly there are a lot of different things to do: management of the equipment (including buying new stuff and getting service), taking care of servers for the network or additional services, debugging problems like this or connecting new dormitories to our network.

If you want to volunteer, it doesn't matter if you are a pro or a starter: Selfnet offers the opportunity to learn everything required. If you are interested in technical stuff, programming, public relations, project management or anything else: We would be glad to welcome you in our team! Just visit our support hours (once the office hours are re-opened).

The Selfnet-Team

Deutsche Übersetzung

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


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.


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, 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 40GBit/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