Wenn die Kaffeemaschine das Netzwerk flutet.

Eine vernetzte Kaffeemaschine erzeugt rund ein Terabyte Datenverkehr in zehn Tagen. Eine Waschmaschine fällt durch Gigabytes an vermeintlichen Uploads auf. Hinter solchen Beobachtungen können Firmwarefehler, fehlerhafte Messungen oder kompromittierte Geräte stehen. Entscheidend ist, was tatsächlich über das Netzwerk übertragen wurde – und wohin.

Ein Terabyte Datenverkehr – aber wohin?

Anfang Oktober 2026 berichtete ein IT-Fachmann auf X über eine auffällige Keurig-Kaffeemaschine im Netzwerk seiner Eltern. Die Netzwerkverwaltung zeigte über einen Zeitraum von rund zehn Tagen mehr als 1.000 Gigabyte ausgehenden Datenverkehr. Die Maschine hatte dabei einen WLAN-Access-Point erheblich belastet.

Die zunächst naheliegende Vermutung: Ein Haushaltsgerät könnte ungewöhnlich große Datenmengen über das Internet übertragen haben.

Bei der anschließenden Untersuchung stellte der Betreiber jedoch fest, dass ein Großteil des Verkehrs offenbar innerhalb des lokalen Netzwerks geblieben war. Als mögliche Ursache vermutete er einen Softwarefehler. Eine veröffentlichte vollständige Paketanalyse, die Protokoll, Zieladressen und Ursache zweifelsfrei nachweist, liegt in den ausgewerteten Berichten nicht vor.

Die Größenordnung bleibt bemerkenswert: 1.000 Gigabyte in zehn Tagen entsprechen rechnerisch rund 9,3 Megabit pro Sekunde an kontinuierlichem Datenverkehr, sofern dezimale Einheiten verwendet und die Bytes gleichmäßig verteilt werden. Das ist ein Mittelwert, keine gemessene Spitzenlast.

Für einen Access-Point kann besonders Broadcast- oder Multicast-Verkehr problematisch sein. Je nach WLAN-Standard, Konfiguration und Übertragungsrate beanspruchen solche Frames überproportional viel Airtime.

Der Vorfall ist deshalb zunächst ein Hinweis auf eine erhebliche Netzwerkanomalie – kein belastbarer Nachweis für einen Datenabfluss oder eine Kompromittierung.

Ausgangsbericht bei Golem, 9. Oktober 2026

Warum eine Upload-Statistik noch keinen Datenabfluss beweist

Netzwerkmanagement-Systeme erfassen Verkehr an unterschiedlichen Messpunkten. Eine Anzeige mit der Bezeichnung „Upload“ bedeutet nicht zwangsläufig, dass Daten an einen externen Server gesendet wurden.

Entscheidend sind mindestens vier Fragen:

• Messpunkt: Erfasst der Zähler Frames am WLAN-Interface, IP-Verkehr eines Geräts, durch einen Router weitergeleitete Pakete oder tatsächlich übertragenes WAN-Volumen?
• Richtung: Beziehen sich Sende- und Empfangswerte auf die Perspektive des Clients, Access-Points oder Routers?
• Ziel: Gehen Pakete an lokale Unicast-Adressen, Broadcast- oder Multicast-Gruppen oder an Ziele außerhalb des eigenen Netzes?
• Zählweise: Werden Wiederholungen, Protokoll-Overhead, mehrere Schnittstellen oder erneut verarbeitete Pakete mitgezählt?

Eine fehlerhafte Implementierung kann beispielsweise zyklisch Discovery-Pakete erzeugen. Denkbar sind wiederholte mDNS-Ankündigungen, SSDP-Nachrichten, fehlgeschlagene Verbindungsversuche oder eine Firmware-Schleife.

Welche dieser Mechanismen im konkreten Kaffeemaschinenfall tatsächlich vorlag, ist nicht nachgewiesen.

Auch ein Vergleich der Zähler ist nur dann sinnvoll, wenn Zeitraum, Schnittstelle, Richtung und Einheit übereinstimmen. Eine hohe Client-Sendezählung und ein niedriger WAN-Upload sind kein Widerspruch, wenn ein erheblicher Anteil lokal verbleibt.

Die forensisch relevante Frage lautet nicht zuerst, wie viele Gigabyte angezeigt werden, sondern welche Pakete an welchem Übergang tatsächlich beobachtet werden.

Drei weitere Erkenntnisse aus dokumentierten IoT-Fällen

1. LG-Waschmaschine: Auffälliger Verkehr, ungeklärte Ursache

Im Januar 2024 veröffentlichte der Besitzer einer vernetzten LG-Waschmaschine Routerstatistiken, nach denen das Gerät innerhalb eines Tages ungefähr 3,57 Gigabyte Upload und 96 Megabyte Download erzeugt haben sollte.

Die Zahlen führten zu Spekulationen über Telemetrie, eine mögliche Kompromittierung oder fehlerhafte Firmware.

Eine gesicherte Ursache ließ sich aus den öffentlich gezeigten Statistiken jedoch nicht ableiten. Auch Ungenauigkeiten der Traffic-Klassifizierung des Routers wurden diskutiert.

Der Fall zeigt ein grundsätzliches Problem: Ohne unabhängige Prüfung am WAN-Übergang, nachvollziehbare Zieladressen und Paketdaten lässt sich aus einer Herstellergeräte-Zuordnung kein konkreter Datenabfluss beweisen.

Bericht bei Golem, 16. Januar 2024

2. Mirai: Wenn IoT-Verkehr tatsächlich Teil eines Angriffs ist

Dass IoT-Geräte nicht nur versehentlich, sondern auch absichtlich schädlichen Netzwerkverkehr erzeugen können, zeigte das Mirai-Botnet 2016.

Angreifer infizierten unter anderem internetseitig erreichbare Router, Kameras und digitale Videorekorder. Ein wesentlicher Angriffsweg waren bekannte beziehungsweise voreingestellte Zugangsdaten.

Die kompromittierten Geräte konnten anschließend zentral für Distributed-Denial-of-Service-Angriffe gesteuert werden.

Die US-Behörde FBI beschrieb diese Vorgehensweise 2017 ausdrücklich als Beispiel für die Ausnutzung unzureichend geschützter IoT-Systeme.

Anders als bei der Kaffeemaschine handelte es sich hier um eine dokumentierte Angriffsklasse mit unautorisiert ausgeführten Netzwerkaktivitäten.

Der gemeinsame Nenner ist nicht die Datenmenge, sondern die Fähigkeit eines eingebetteten Geräts, außerhalb seines eigentlichen Funktionszwecks Netzwerkressourcen zu beanspruchen.

FBI / Internet Crime Complaint Center: IoT-Sicherheitswarnung, 2017

3. Wissenschaftliche Messungen: IoT-Verkehr ist von Gerätetyp und Cloud-Abhängigkeit geprägt

Eine Untersuchung von Huang und Kollegen stellte mit „IoT Inspector“ eine Methode zur Erhebung gekennzeichneter Netzwerkdaten real genutzter Smart-Home-Geräte vor.

Der Forschungsdatensatz umfasste nach Angaben der Autoren 44.956 Geräte aus 13 Kategorien und von 53 Herstellern. Untersucht wurden unter anderem veraltete TLS-Konfigurationen sowie Verbindungen zu Werbe- und Tracking-Domains.

Eine weitere Studie von Mazhar und Shafiq betrachtete Netzwerkverkehr in mehr als 200 Haushalten. Sie zeigte, dass Gerätefunktionen das Verkehrsvolumen und zeitliche Muster wesentlich beeinflussen und viele Geräte von vergleichsweise wenigen Cloud- und DNS-Diensten abhängig sind.

Solche Studien liefern keine allgemeingültige Obergrenze für zulässigen IoT-Traffic. Sie begründen aber einen wichtigen methodischen Ansatz: Auffälligkeiten müssen gegen ein nachvollziehbares Normalverhalten derselben Geräteklasse bewertet werden.

Huang et al.: IoT Inspector, 2019

Mazhar und Shafiq: Characterizing Smart Home IoT Traffic in the Wild, 2020

Was im Netzwerk technisch schieflaufen kann

Hinter ungewöhnlichem IoT-Datenverkehr stehen mehrere mögliche Fehler- und Angriffsklassen.

Firmware- und Protokollfehler: Fehlerhafte Wiederholungslogik, Discovery-Schleifen oder missglückte Update-Prozesse können über längere Zeit Verkehr erzeugen, ohne dass Nutzdaten das Internet verlassen.

Fehlkonfigurationen und Netzwerkinteraktionen: Multicast-Verteilung, Discovery-Protokolle, fehlerhafte Adressauflösung oder ungünstige WLAN-Konfigurationen können kleine Fehler erheblich verstärken. Broadcast-Stürme entstehen nicht automatisch durch jedes IoT-Gerät; der konkrete Protokollpfad muss geprüft werden.

Cloud-Kommunikation und Telemetrie: Viele Geräte benötigen externe Dienste für Fernsteuerung, Konfigurationsabgleich, Updates oder Analysefunktionen. Verschlüsselte Verbindungen belegen dabei weder die Harmlosigkeit noch die Schädlichkeit der übertragenen Inhalte.

Kompromittierung: Ein Angreifer kann ein Gerät beispielsweise zum Scannen, zur Kommunikation mit einer Command-and-Control-Infrastruktur oder zur Beteiligung an DDoS-Angriffen missbrauchen. Ein auffälliges Verkehrsvolumen ist dafür ein Indikator, aber kein Beweis.

Diese Ursachen erfordern unterschiedliche Gegenmaßnahmen. Eine Firewall-Regel gegen externe Kommunikation beendet keinen lokalen Broadcast-Sturm. Ein Firmware-Neustart wiederum beseitigt nicht zwangsläufig eine bestehende Kompromittierung.

Vom auffälligen Zähler zur belastbaren Diagnose

Für Administratoren empfiehlt sich eine Untersuchung entlang des tatsächlichen Datenpfads.

1. Gerät und Messung verifizieren

MAC-Adresse, IP-Adresse, DHCP-Zuordnung, WLAN-Assoziation und möglichst den Gerätetyp dokumentieren. MAC-Adressen können randomisiert oder nachgebildet werden; die Zuordnung allein ist daher kein sicherer Identitätsnachweis.

Messzeitraum, Zählrichtung, Einheit und Datenquelle festhalten. Danach die Werte mit den Schnittstellenstatistiken des Routers und gegebenenfalls eines Switches vergleichen.

2. Lokalen Verkehr von WAN-Verkehr unterscheiden

An einem geeigneten Messpunkt wird geprüft, ob Pakete die lokale Routing-Grenze tatsächlich passieren. Flow-Daten oder Firewall-Logs können Ziele und Volumen eingrenzen.

Ein WAN-Zähler allein erlaubt allerdings nicht immer die sichere Zuordnung zu einem einzelnen Gerät, etwa bei gemeinsam genutzten Adressen, NAT oder fehlender Flow-Telemetrie.

3. Protokolle und Kommunikationspartner bestimmen

Eine zeitlich begrenzte Paketaufzeichnung kann zeigen, ob wiederholte Broadcasts, DNS-Abfragen, TCP-Verbindungsversuche oder TLS-Sitzungen dominieren.

Mit Wireshark oder tcpdump lassen sich Zeitmuster, Zieladressen, Paketgrößen und Wiederholungen untersuchen. Bei TLS-Verkehr bleibt der Anwendungsinhalt ohne weitere Voraussetzungen verborgen.

Eine vollständige Inhaltsentschlüsselung ist für eine erste Netzwerkanalyse normalerweise nicht erforderlich.

4. Veränderung kontrolliert testen

Ein Neustart, eine Firmware-Aktualisierung oder eine Änderung der Netzsegmentierung kann anschließend mit einem dokumentierten Vorher-Nachher-Vergleich bewertet werden.

Verschwindet die Anomalie nach einem Neustart, spricht das für einen veränderbaren Gerätezustand. Es beweist aber weder die genaue Fehlerursache noch die Abwesenheit von Schadsoftware.

Bei konkretem Verdacht auf einen Sicherheitsvorfall sollten benötigte Beweisdaten vor einem Reset gesichert werden, soweit dies technisch und organisatorisch möglich ist.

IoT-Segmentierung: Was sie leistet – und was nicht

Ein eigenständiges IoT-VLAN mit restriktiven Firewall-Regeln reduziert die erreichbaren Systeme eines Geräts. Das ist besonders in Unternehmen mit Netzwerkdruckern, Kameras, Zutrittskontrolle, Gebäudeautomation oder vernetzter Produktion relevant.

Eine wirksame Segmentierung umfasst mehr als eine separate VLAN-ID:

• Inter-VLAN-Regeln: Verbindungen zu administrativen Systemen, Servernetzen und Clients nur bei dokumentiertem Bedarf zulassen.
• Internet-Egress: Zielports und notwendige Kommunikationsbeziehungen begrenzen, soweit sie zuverlässig bekannt sind.
• Layer-2-Kontrollen: Broadcast- und Multicast-Verhalten beobachten; gegebenenfalls Client-Isolation, Storm-Control und geeignete WLAN-Einstellungen einsetzen.
• Monitoring: Unerwartete Kommunikationspartner, ungewöhnliche Übertragungsmuster und dauerhaft hohe Airtime-Auslastung erkennen.
• Gerätelebenszyklus: Firmwarestände, Hersteller-Support, Updates und Austauschplanung dokumentieren.

Die technische Grenze ist wichtig: Ein VLAN trennt zunächst Layer-2-Broadcast-Domänen. Es begrenzt nicht automatisch die Kommunikation innerhalb desselben Segments. Und ein Gerät, das innerhalb seines zugewiesenen WLANs massiv Airtime belegt, kann den Funkbetrieb weiterhin beeinträchtigen.

Zusätzliche Firewall-Regeln müssen deshalb mit Kontrollen auf WLAN- und Switching-Ebene zusammengedacht werden.

Welche Anforderungen sich wissenschaftlich begründen lassen

Das National Institute of Standards and Technology beschreibt in NIST IR 8259A eine grundlegende Sammlung technischer Sicherheitsfähigkeiten für IoT-Geräte.

Dazu gehören Geräteidentifikation, sichere Konfiguration, Datenschutz, logische Zugriffsbeschränkungen, Softwareaktualisierungen und Informationen über den Sicherheitszustand.

Die NIST-Empfehlungen sind keine pauschale Zertifizierung aller Geräte. Sie dienen als Ausgangspunkt, um je nach Einsatzumgebung geeignete Anforderungen zu definieren.

Für die Beschaffung und den Betrieb lässt sich daraus eine konkrete Fragestellung ableiten: Kann ein Gerät nachvollziehbar identifiziert, eingeschränkt, aktualisiert, überwacht und bei Problemen sicher außer Betrieb genommen werden?

NIST IR 8259A: IoT Device Cybersecurity Capability Core Baseline

Meine Einordnung

Der Fall der Kaffeemaschine ist weniger ein Beleg für massenhafte Datensammlung als ein Beispiel für die begrenzte Aussagekraft aggregierter Netzwerkstatistiken.

Die LG-Waschmaschine zeigt, wie schnell ungewöhnliche Zählerstände ohne ausreichende Messmethodik interpretiert werden. Mirai belegt dagegen, dass kompromittierte IoT-Geräte tatsächlich als Infrastruktur für Angriffe dienen können. Die wissenschaftlichen Verkehrsstudien zeigen zudem, wie stark Gerätefunktionen, externe Dienste und Implementierungsdetails das Netzwerkverhalten prägen.

Für die Praxis ergibt sich daraus eine klare Priorität: Nicht jedes IoT-Gerät braucht eine aufwendige forensische Dauerüberwachung. Jedes vernetzte Gerät braucht aber einen begründeten Kommunikationsbedarf, angemessene Zugriffsgrenzen und eine Möglichkeit, Abweichungen zu erkennen.

Der entscheidende Prüfpunkt: Wenn ein Gerät morgen ungewöhnlichen Traffic erzeugt – können Sie nachweisen, ob es lediglich sein eigenes Netzwerksegment belastet, externe Dienste kontaktiert oder tatsächlich Daten über Ihre Internetanbindung überträgt?

Erst diese Unterscheidung macht aus einem auffälligen Zählerstand eine belastbare technische Bewertung.