Im Mai 2003 brüllte ein einziger Zeitserver der University of Wisconsin–Madison unter einer Last, die er nie hätte sehen dürfen: Hunderttausende Netgear-Router auf der ganzen Welt fragten ihn im Sekundentakt nach der Uhrzeit. Schuld war kein Angriff, sondern ein simpler Programmierfehler – eine fest einprogrammierte IP-Adresse. Die Geschichte zeigt, wie aus einer harmlosen Funktion versehentlich eine verteilte Überlastung wird.
Aufgeschrieben hat den Fall der Netzwerk-Ingenieur Dave Plonka von der UW–Madison. Sein Bericht vom 21. August 2003 ist bis heute ein Lehrstück darüber, was passiert, wenn massenhaft billige Geräte dieselbe Voreinstellung teilen.
Erst einmal: Was macht NTP?
Damit Computer, Router und Smart-Home-Geräte eine korrekte Uhrzeit haben, gleichen sie ihre Uhr über das Network Time Protocol (NTP) mit Zeitservern im Internet ab – über UDP-Port 123. Einfache Geräte nutzen die abgespeckte Variante SNTP (Simple NTP). Das ist völlig normal und harmlos – solange sich ein Gerät höflich verhält: Es fragt einen per Hostnamen erreichbaren Server (idealerweise einen ganzen Pool) nur alle paar Minuten bis Stunden ab und wartet nach einem Fehler geduldig, statt sofort erneut anzuklopfen.
Der Fehler: eine IP-Adresse, fest im Code
Die betroffenen Netgear-Router (unter anderem RP614 und RP614v2, MR814, DG814, HR314 und RO318) machten gleich drei Dinge falsch. Ihr eingebauter SNTP-Client:
- hatte eine feste Server-IP im Code: alle Geräte fragten stur
128.105.39.11ab – genau den Serverntp1.cs.wisc.eduder Uni Wisconsin, ohne Hostnamen, ohne Ausweichmöglichkeit; - nutzte einen festen Quellport: UDP-Port
23457– wodurch sich die Geräte später zwar leicht identifizieren ließen, das Grundproblem aber nicht kleiner wurde; - fragte viel zu aggressiv: im Sekundentakt, bis endlich eine Antwort kam. Erst danach schaltete es auf größere Abstände (je nach Modell eine Minute bis 24 Stunden) um.
Solange der Server antwortete, beruhigten sich die Geräte. Antwortete er nicht – etwa weil er gerade überlastet war –, hämmerten Hunderttausende Router gleichzeitig jede Sekunde weiter. Ein Teufelskreis, der sich selbst am Leben hielt.
Die Flut
Am 14. Mai 2003 gegen 8 Uhr morgens explodierte der Datenverkehr. Statt der üblichen rund 40.000 Pakete pro Sekunde des gesamten Campus prasselten zeitweise mehr als 250.000 Pakete pro Sekunde und über 150 Megabit/s allein an SNTP-Anfragen herein. Netgear bezifferte die Zahl der ausgelieferten betroffenen Geräte später auf 707.147; die Uni zählte an manchen Tagen über 500.000 einzelne Clients – und das war wegen NAT vermutlich noch zu niedrig gegriffen. Hätten alle Geräte gleichzeitig angefragt, wären theoretisch bis zu 700.000 Pakete/s (426 Mbit/s) möglich gewesen.
Detektivarbeit mit strings
Zunächst war unklar, woher die 76 Byte großen UDP-Pakete kamen. Auffällig war der immer gleiche Quellport 23457. Über befreundete Universitäten, in deren Netzen verdächtige Adressen lagen, ließen sich die Absender schließlich als Netgear-MR814-Router identifizieren. Den Beweis lieferte die Firmware selbst: Mit dem simplen Kommandozeilen-Werkzeug strings zog Plonka lesbare Zeichenketten aus den Firmware-Dateien – und fand darin die hart einprogrammierte Adresse 128.105.39.11 schwarz auf weiß.
Wie der Fall gelöst wurde
Der Weg zu Netgear war zäh: Auf die erste E-Mail Mitte Juni 2003 folgte erst nach 23 Tagen eine automatische Antwort. Der Durchbruch kam per Anruf – ein Support-Direktor bestätigte den Fehler –, danach bildete sich ein 15-köpfiges Prüfteam aus Netgear-Mitarbeitern, Uni-Personal und unabhängigen Fachleuten. Die reparierte Firmware änderte das Verhalten grundlegend:
- Anfragen erst, wenn ein DNS-Server konfiguriert ist – keine feste IP mehr;
- Auflösung von
time-a.netgear.comundtime-b.netgear.comim 10-Minuten-Takt, also über Netgears eigene Infrastruktur; - ein Zeitserver wird erst kontaktiert, wenn die Namensauflösung geklappt hat;
- zwischen Wiederholungen liegen 10 Minuten, und nach 5 Versuchen gibt das Gerät auf.
Parallel schaltete die Uni die Anfragen zunächst am Netzrand ab und prüfte größere Lösungen (etwa einen per BGP verteilten Anycast-Zeitdienst). Zwischen Netgear und der UW–Madison wurde zudem eine – vertraulich gehaltene – Einigung ausgehandelt.
Warum das kein Einzelfall blieb
Plonkas Bericht nennt selbst einen Parallelfall: In Australien fluteten rund 85.000 SMC-Router den Zeitserver der Forschungsorganisation CSIRO mit zweimal pro Minute wiederholten Anfragen. Das Muster wiederholte sich: 2006 legten hart einprogrammierte Adressen in D-Link-Firmware unter anderem den Zeitserver eines dänischen Betreibers lahm – wieder mit anschließendem Vergleich.
Die Konsequenz zog die Internet-Gemeinde auf zwei Ebenen. Erstens als Norm: Der von Plonka mitverfasste RFC 4085 von 2005 trägt den sprechenden Titel „Embedding Globally-Routable Internet Addresses Considered Harmful“ – das Einbetten fester öffentlicher IP-Adressen in Geräte gilt seither ausdrücklich als schädlich. Zweitens praktisch: Das NTP-Pool-Projekt bietet Herstellern eigene „Vendor Zones“ an – ein rotierender Verbund vieler Server, den ein Gerät per Hostnamen anspricht, statt einen einzelnen Rechner zu belagern.
Was Hersteller – und du – daraus lernen
- Nie eine einzelne fremde IP-Adresse fest ins Gerät brennen. Hostnamen und einen Server-Pool verwenden.
- Höflich abfragen: große Intervalle, zufällige Verzögerung (Jitter) und echtes Backoff nach Fehlern – niemals im Sekundentakt weiterhämmern.
- Wer viele Geräte ausliefert, richtet eine eigene Zeitserver-Infrastruktur ein oder nutzt eine NTP-Pool-Vendor-Zone – mit Erlaubnis des Betreibers.
- Für Nutzerinnen und Nutzer: Router-Firmware aktuell halten. Genau solche Fehler werden per Update behoben.
Der Fall ist über 20 Jahre alt – und heute relevanter denn je. Im Zeitalter von Milliarden billiger IoT-Geräte kann eine einzige unbedachte Voreinstellung im Firmware-Image ausreichen, um wildfremde Server unbeabsichtigt in die Knie zu zwingen. Netgears Router waren dabei nie böswillig – sie taten nur, exakt und millionenfach, was jemand ihnen einprogrammiert hatte.
Quelle: Dave Plonka, „Flawed Routers Flood University of Wisconsin Internet Time Server“ (UW–Madison, 2003) · RFC 4085 · NTP Pool – Information for Vendors.