Geräte und Sensoren im Internet der Dinge (IoT) müssen mit dem Netzwerk und somit auch untereinander verbunden sein, damit sich ihre Daten nutzen lassen. Neben der großen Bandbreite an Sensoren, Aktoren und intelligenten Objekten, die das IoT ausmachen, gibt es auch eine Reihe verschiedener Verbindungsprotokolle. Diese betrachten wir zunächst hinsichtlich ihrer Spezifikation und Funktion, bevor wir uns anschließend daran machen, sie mit Wireshark zu untersuchen.

Das erste davon ist IEEE 802.15.4. Es liefert eine drahtlose Zugangstechnologie für kostengünstige Geräte mit niedriger Datenrate. Die IEEE-802.15.4-PHY- und MAC-Schichten bilden die Grundlage für mehrere Netzprotokoll-Stacks. Diese nutzen 802.15.4 auf der physikalischen und der Verbindungsebene, aber die oberen Schichten sind in der Regel sehr unterschiedlich. Einige der bekanntesten Protokolle, die auf 802.15.4 basieren, zeigt die Tabelle.

In nicht-eingeschränkten Netzwerken ist der Standard IEEE 802.11 (auch bekannt als Wi-Fi oder WLAN) die am meisten eingesetzte Funktechnologie. Dieser Standard ist eine wichtige drahtlose IoT-Zugangstechnologie, entweder für die Verbindung von Endpunkten wie Fog- Computing-Knoten, Sensoren mit hoher Datenrate und Audio- oder Videogeräten oder für die Bereitstellung von Wi-Fi-Backhaul-Infrastrukturen wie Wi-Fi-Mesh im Freien. Allerdings fehlt es dieser Technologie an Sub-GHz-Unterstützung für eine bessere Signalpenetration, einen geringen Stromverbrauch für batteriebetriebene Knoten und die Fähigkeit, eine große Anzahl von Geräten zu unterstützen.

Eine recht neue Drahtlostechnologie ist LoRaWAN (Low-Power Wide-Area). Sie ist optimiert für eine Zwei-Wege-Kommunikation mit großer Reichweite und niedrigem Stromverbrauch. Die "LoRa Layer 1 PHY"-Modulationstechnologie von Semtech ist von mehreren Chipsatz-Anbietern erhältlich. Zur Unterscheidung von der Modulation der physikalischen Schicht, die als LoRa bekannt ist, verwendet die LoRa Alliance den Begriff LoRaWAN, um auf ihre Architektur und ihre Spezifikationen zu verweisen, die die Ende-zu-Ende-LoRaWAN-Kommunikation und -Protokolle beschreiben.

Der wesentliche Unterschied zwischen der traditionellen Informationstechnologie (IT) und der Betriebstechnologie (OT) ist die Lebensdauer der zugrundeliegenden Technologien und Produkte. Alle neueren Betriebssysteme, von Allzweckcomputern und Servern bis hin zu eingebetteten Systemen, verfügen inzwischen über einen integrierten IPv4- und IPv6-Stack. Außerdem wurden die Protokolle für IoT-Anwendungen in vielen industriellen OT-Systemen aktualisiert, um auf Basis des IP-Protokolls arbeiten zu können. Während das Internetprotokoll der Schlüssel für ein erfolgreiches Internet der Dinge ist, erfordern die Beschränkungen in manchen Geräten und Netzwerken eine Optimierung auf verschiedenen Ebenen der IP-Architektur.

Die IP-Architektur bedingt, dass der Datentransport der höheren Schichten über Layer 2 (MAC-Protokoll) und Layer 1 (PHY-Layer) erfolgt. Das Modell für die Integration von IP in Protokolle der unteren Schichten nennt sich auch Adoption-Layer. 6LoWPAN ist die Abkürzung für "IPv6 over Low power Wireless Personal Area Network". Die 6LoWPAN-Arbeitsgruppe hat im RFC 4944 die im Paket-Header festgelegten Funktionen, wie beispielsweise Header-Kompression, Fragmentierung und Mesh-Adressierung, definiert.

IoT-Datenprotokolle dienen der Verbindung von IoT-Geräten mit geringem Stromverbrauch und ermöglichen eine Punkt-zu-Punkt-Kommunikation mit der Hardware auf der Benutzerseite, ohne dass eine Internetverbindung erforderlich ist. Die Konnektivität bei IoT-Datenprotokollen erfolgt über ein kabelgebundenes oder ein Funknetz. Einige der wichtigen IoT-Datenprotokolle sind:

- Message Queue Telemetry Transport (MQTT): Sammelt Daten von verschiedenen Geräten und hilft bei der Fernüberwachung. Es handelt sich um ein Subscribe/Publish-Protokoll, das auf Basis des TCP-Protokolls arbeitet, und unterstützt den ereignisgesteuerten Nachrichtenaustausch über drahtlose Netzwerke.

- Constrained Application Protocol (CoAP): Nutzt generell das User Datagram Protocol (UDP) und kann dadurch eine schnelle und sichere Kommunikation aufbauen. Es gehört zu den Nutzungsprotokollen für eingeschränkte Geräte. Vor allem bei geringen Bandbreiten und unzuverlässigen Verbindungen kann CoAP das richtige Protokoll sein, wenn IoT-Geräte untereinander kommunizieren sollen.

- Advanced Message Queuing Protocol (AMQP): Ein Software-Layer-Protokoll für eine nachrichtenorientierte Middleware-Umgebung, das Routing und Queuing ermöglicht. Es kommt für zuverlässige Punkt-zu-Punkt-Verbindungen zum Einsatz und unterstützt den sicheren Austausch von Daten zwischen den angeschlossenen Geräten und der Cloud.

- Machine-to-Machine-(M2M)-Kommunikationsprotokoll: Ein offenes Industrieprotokoll für die Fernverwaltung von IoT-Geräten.

- Lightweight M2M (LWM2M): Dient der Kommunikation zwischen Geräten in einer IoT-Infrastruktur. Das Protokoll eignet sich vor allem für Telemetrie und zur Verwaltung von Geräten im Internet of Things, wenn die Endgeräte keine hohe Leistung haben und wenig Energie verbrauchen sollen.

- Extensible Messaging and Presence Protocol (XMPP): Verwendet einen Push-Mechanismus, um Nachrichten in Echtzeit auszutauschen. Es zeigt den Verfügbarkeitsstatus der Geräte an, die Nachrichten senden oder empfangen.

- Data Distribution Service (DDS): Ein IoT-Datenprotokoll und API-Standard – typischerweise für die Übertragung von Daten in Echtzeitsystemen in einer verteilten Umgebung.

Beim Zusammenspiel aller hier vorgestellten Protokolle und der unterschiedlichen Hardware verschiedener Hersteller kommt es unweigerlich immer wieder zu Problemen. Oftmals erfordert die Fehleranalyse dann einen Blick auf das Netzwerk. Mit Wireshark [1] steht dafür eine außerordentlich leistungsfähige Open-Source-Software zur Verfügung. Dies gilt auch im OT-Bereich, wo Wireshark Kommunikationsströme aufzeichnet, darstellt und auswertet. Zum Mitschneiden des Datenverkehrs ist eine entsprechende Interface-Karte für das genutzte OT-Netzwerk notwendig. Oberhalb der Netzwerkkarte kommen die höheren Protokolle zum Einsatz. Wireshark unterstützt sogenannte Protokoll-Dissektoren (Dekoder) für eine Vielzahl unterschiedlicher Protokolle, nicht zuletzt alle gängigen Protokolle der TCP/IP-Familie.

Doch der IoT-Markt verhält sich derzeit ähnlich wie aus technologisch jungen Märkten bekannt und es gibt noch keine industrieseitige Einigung auf Standards. Alle Verkehrsströme, die Anwendungen im Netzwerk nicht über die üblichen Standard-Portnummern übermitteln, stellen Wireshark vor ein Problem. Und das Problem weitet sich aktuell noch aus, denn mit der wachsenden Anzahl von Komponenten, Anwendungen, Protokollen und Einsatzbereichen des IoT gelangen immer häufiger individuell angepasste oder proprietäre Protokolle ins Netzwerk.

So identifiziert Wireshark in der Grundeinstellung ein Protokoll automatisch anhand der Portnummer. Steht kein Protokoll-Dissektor für das genutzte Kommunikationsprotokoll beziehungsweise die Anwendung zur Verfügung, dann ist die Software nicht in der Lage, die Protokolle korrekt zu interpretieren und darzustellen. Die einfachste Abhilfe schafft ein Wire-shark-Plug-in vom jeweiligen Hersteller der Software. Diese lassen sich beispielsweise für die Protokolle ModbusTCP, Profinet und MQTT herunterladen.

Sollten keine Erweiterungen zur Verfügung stehen, können Sie eigene Dissektoren anlegen. Hierzu sind allerdings die Programmiersprachen C oder die Skriptsprache Lua erforderlich. Beispiele für die Nutzung von Dissektoren und Lua finden Sie unter [2]. Oft ist es auch hilfreich, wenn Sie nach benötigten Dissektoren in den Wireshark-Foren (zum Beispiel [3]) nachfragen. Oft hat ein Kollege bereits ein Lua-Script oder einen Dissektor geschrieben und stellt diesen kostenfrei zur Verfügung.

Als Beispiel für eine Analyse mit Wireshark verwenden wir einen MQTT-Monitor, um ein "Topic" von einem MQTT-Broker zu abonnieren und zu veröffentlichen. MQTT ist ein offenes Netzwerkprotokoll für Machine-to-Machine-Kommunikation, das die Übertragung von Telemetriedaten in Form von Nachrichten zwischen Geräten ermöglicht – trotz hoher Verzögerungen oder beschränkter Netzwerke. Für die Interpretation der so gesammelten Daten kommt Wireshark zum Einsatz, was uns erlaubt, jeden Schritt des Prozesses zu analysieren und die übermittelten Datenpakete zu untersuchen.

Eine MQTT-Verbindung besteht zwischen einem Client und einem Broker und niemals direkt mit einem anderen Client. Die Verbindung wird durch einen CONNECT-Befehl eingeleitet, den der Client an den Broker sendet. Die einmal aufgebaute Verbindung bleibt so lange offen, bis der Broker einen Disconnect-Befehl vom Client erhält.

Dabei lohnt ein Blick in die Details des Verbindungsbefehls: Die "Header-Flags" enthalten Informationen über den Typ des MQTT-Kontrollpakets, während die "Connect-Flags" Parameter liefern, die das Verhalten der MQTT-Verbindung festlegen. Sie geben das Vorhandensein oder Fehlen von Feldern in der Nutzlast an und sind in sieben Bits aufgeteilt:

- Clean Session (Bit 1): Dieses zeigt dem Broker an, ob der Client eine dauerhafte Verbindung aufbauen möchte oder nicht. Ist das Flag auf "true" gesetzt, ergibt sich eine "Clean Session", bei der die Abonnements beim Trennen der Verbindung entfernt werden. Steht es auf "false", ist eine dauerhafte Verbindung möglich, bei der die Abonnements bestehen bleiben und die Nachrichten beim erneuten Verbinden mit hoher QoS geliefert werden.

- Will-Flag (Bit 2). Ist Teil der MQTT-Funktion "Last will and testament" (LWT). Ist dieses Flag gesetzt, bedeutet dies, dass bei Annahme der Connect-Anfrage eine Will-Nachricht auf dem Server gespeichert werden muss. Eine Will-Nachricht wird verwendet, um andere Clients über die Trennung der Verbindung zu benachrichtigen. Trennt der Client die Verbindung, sendet der Broker diese Information im Namen des Clients.

- Will-QoS (Bit 3 und 4): Bezeichnen die QoS-Stufe der Veröffentlichung der Will-Nachricht.

- Will-Retain (Bit 5): Steht dieser Parameter auf "0", muss der Server die Will-Nachricht als nicht-aufbewahrte Nachricht veröffentlichen, bei einer "1" passiert das Gegenteil.

- Benutzername und Passwort (Bit 6 und 7): Sind diese Felder aktiv, liefern sie die Crendentials. MQTT erlaubt das Senden von Benutzernamen und Passwort zur Authentifizierung eines Clients und zur Autorisierung. Das Passwort wird im Klartext übermittelt, wenn es nicht zusätzlich verschlüsselt ist.

Darüber hinaus findet sich in einer MQTT-Verbindung der Keep-Alive-Timer. Er verrät, ob sich ein MQTT-Client im Netz befindet – wobei der Client regelmäßig Ping-Anfragen an den Broker sendet. Der Broker antwortet mit einer Ping-Antwort. Und als letzte relevante Daten zeigen sich in der MQTT-Verbindung die Clientkennung und die Nutzdaten.

Die Connect-Bestätigung des Brokers umfasst dann Header-Flags mit Informationen über den Typ des MQTT-Steuerpakets und das "Session Present" (Bit 0 des CONNACK-Bytes ist das Session Present Flag). Dieses Flag zeigt an, ob der Broker über eine bestehende dauerhafte Sitzung des Clients aus früheren Interaktionen verfügt. Das CONNACK-Paket enthält keine Nutzdaten. Schließlich zeigt sich noch der Return Code mit folgenden Rückgabewerten und Antworten

- 0: Connect Accepted

- 1: Connect Refused (nicht akzeptiertes Protokoll)

- 2: Connect Refused (Identifier abgelehnt)

- 3: Connect Refused (Server ist nicht verfügbar)

- 4: Connect Refused (Probleme mit den Credentials)

- 5: Connect Refused (nicht autorisiert)

Ein Client sendet eine Subscribe-Anfrage an einen MQTT-Broker, um relevante Nachrichten zu erhalten. Diese umfasst Header-Flags mit Informationen über den Typ des MQTT-Kontrollpakets und einen "Message Identifier" als Kennung zwischen einem Client und einem Broker zur Identifizierung einer Message in einem Nachrichtenfluss. Dies ist vor allem für QoS größer als Null relevant. Auch finden sich in der Nachricht "Topic and QoS Level", denn jedes Abonnement enthält sowohl einen Themenfilter als auch eine QoS-Stufe. Schließlich enthält die Nutzlast (Payload) eine Liste von Abonnements. Ein Payload ist in einem Subscribe-Paket obligatorisch.

Der MQTT-Broker bestätigt das Abonnement, indem er mit einer SUBACK-Meldung (Subscribe Acknowledgement) eine Bestätigung an den Client zurücksendet. In dieser findet sich erneut ein Header-Flag mit Informationen über den Typ des MQTT-Kontrollpakets. Dazu gesellt sich der "Message Identifier", der für eine Nachricht mit QoS größer als Null relevant ist und ansonsten dem Identifier der Subscribe-Nachricht entspricht. Auch sendet der MQTT-Broker einen Rückgabecode (Return Code) für jedes Topic/ QoS-Paar, das in der Subscribe-Nachricht empfangen wurde:

- 0: Success, Maximum-QoS ist 0

- 1: Success, Maximum-QoS ist 1

- 2: Success, Maximum-QoS ist 2

- 128: Fehler

Eine Publish-Nachricht erfolgt, sobald ein MQTT-Client mit dem Broker verbunden ist und er Nachrichten veröffentlichen kann. Auch diese Nachricht besteht wieder aus verschiedenen Teilen, die Sie zur Analyse kennen sollten. Zunächst treffen wir erneut auf ein Header-Flag mit Informationen über den Typ des MQTT-Kontrollpakets. Es folgt das DUP-Flag mit den möglichen Werten 0 und 1 (0 zeigt den ersten Versuch, dieses Publish-Paket zu senden, 1 eine Wiederholung dieses Vorgangs). Die QoS-Stufe bestimmt den Grad der Sicherheit einer Nachricht und steht das Retain-Flag auf 1, muss der Server die Meldung und ihre QoS speichern, damit er zukünftige Abonnements, die dem Thema entsprechen, bedienen kann. Wird ein Publish-Paket an einen abonnierenden Client gesendet, muss der Server das Retain-Flag auf 1 setzen, wenn ein neues Abonnement vorliegt. Eine 0 bedeutet hier, das das Paket zu einem bestehenden Abonnement passt – unabhängig davon, ob das Flag beim Empfang der Nachricht gesetzt war.

Weiterhin liefert die Publish-Nachricht den "Topic Name" als UTF-8-Zeichenkette, die auch Schrägstriche enthalten kann, wenn sie hierarchisch strukturiert sein muss. Eine Veröffentlichungsnachricht muss ein Thema enthalten, das der Broker für eine themenbasierte Filterung verwendet. Auf diese Weise sendet der Broker Nachrichten an Clients, die sich für das Thema angemeldet haben. Ebenfalls findet sich die "Message", die zusammen mit dem Topic (das die eigentlichen zu übertragenden Daten enthält) die Nutzlast darstellt. Da MQTT datenunabhängig ist, lässt sich die Nutzlast je nach Anwendungsfall strukturieren.

Die Disconnect-Nachricht ist das letzte Kontrollpaket, das der Client an den Broker sendet. Dadurch wird eine saubere Trennung der Verbindung durch den Client initiiert. Hier findet sich erneut ein Header-Flag mit Informationen zum Typ des MQTT-Kontrollpakets, jedoch keine Nutzlast.

Die Keep-Alive-Funktion stellt sicher, dass die Verbindung offen ist und der Client und der Broker miteinander verbunden sind. Ist die Verbindung hergestellt, übermittelt der Client das Keep-Alive-Zeitintervall (in Sekunden) an den Broker. Den Keep-Alive-Flow halten PINGREQ- und PINGRESP-Nachrichten (Ping Request und Ping Response) aufrecht. Der Client sendet den Ping Request an den Broker, um anzuzeigen, dass er noch aktiv ist, obwohl dieser keine weiteren MQTT-Kontrollpakete gesendet hat.

Bis Protokoll- und Netzstandards im IoT-Bereich ausführlich definiert sind, muss sich der IT-Verantwortliche weiterhin seine Testwerkzeuge selber programmieren oder zusammenstellen. Zwar bietet Wireshark heute bereits für einige IoT-Protokolle Möglichkeiten zur Dekodierung in der Analyse, ist jedoch darauf angewiesen, dass die Wireshark-Community weitere OT-Protokolle zur Verfügung stellt.