Sowohl im privaten als auch im unternehmerischen Umfeld ist das Einsatzszenario LAN-externer IoT Sensoren (bzw. Aktoren; gerne auch in hoher Stückzahl) häufig anzutreffen. Damit diese mit einem im LAN befindlichen MQTT-Broker kommunizieren können, muss folglich eine Zugriffs-Regel in der Firewall geschaltet werden; im Falle einer Fritzbox ist dies leicht mittels einer Freigabe umzusetzen; unter "Internet/Freigaben" kann man den Zugriff passend spezifizieren.

Beispiel für einen auf Port 1883 / nas1 lauschenden MQTT-Broker:

Damit ist eine Zugriffsmöglichkeit geöffnet.

Leider ist ein solcher Zugriff komplett ungeschützt; insbesondere können leicht die unverschlüsselt übertragenen MQTT-Zugriffpasswörter bzw. -Token ausgespähnt werden. Sie sollten sich in diesem Fall also nicht wundern, wenn Lichter unerwartet an- und ausgehen; die Rolladen ein Eigenleben entwickeln und die Heizungsanlage plötzlich auf Hochtouren läuft.

Kurz: Ohne Verschlüsselungs-, Authentifizierungs- und (!) Autorisierungskonzept (insbesondere mittels Access Control Lists (ACLs)) sollte keine Firewallöffnung durchgeführt werden!

Das sollte sich von selbst verstehen denken Sie? Von wegen! Schauen Sie man auf Shodan nach, wie viele MQTT-Broker (auch von Unternehmen und Organisationen) Sicherheitsprobleme haben! Besonders erschreckend sind dabei Zugriffsmöglichkeiten auf das System(!)-Topic $SYS.

Nachdem der MQTT-Broker also entsprechend konzeptionell abgesichert ist und via TLS (mindestens 1.2; besser 1.3) über den Port 8883 kommuniziert, dann kann man die Freigabe entsprechend in der Fritzbox spezifizieren.

Leider gibt es dabei eine Herausforderung: Verschlüsselung (TLS) ist teuer! Das MQTT Protokoll selber ist sehr ressourcen-schonend ausgelegt; meist fliessen nur eine dutzend Byte an Nutzlast (Bytes, UTF8-Strings, JSON-Content). TLS macht daraus schnell einige Kilobyte! Insbesondere für Batterie/Akku-betriebene IoT Sensoren kann das unschön kurze Wartungszyklen bedeuten!

Selbstverständlich muss man sich Zertifikate erzeugen (lassen), diese aktuell halten, etc.

Daher als Ausblick einige Denkanstösse: Wenn die Sensoren schon LAN / Standort-extern liegen müssen: Warum dann nicht LoRaWAN ins Auge fassen? Dieses WAN ist für energieeffiziente und AES verschlüsselte Kommunikation ausgelegt. Die LoRaWAN Gateways (also die Verbinder zur TCP/IP Internet MQTT-Welt) können z.B. mittels HiveMQ an MQTT-Broker angebunden werden.

Interessanterweise kann man mit den LoRa-Modems dann auch gleich ein krisensicheres, autarkes OpenSource-Meshnetz aufbauen: Meshtastic.

In sehr vielen Fällen sind die anzubindenden IoT Sensoren und Aktoren allerdings grundsätzlich in WLAN Reichweite und am Stromnetz angeschlossen. Warum dann nicht ein oder mehrere virtuelle IoT WLAN Netzwerke aufspannen? Dazu kann beispielsweise die Linux-basierte Router-Firmware OpenWRT dienen. Durch eine Vielzahl von Plugins/Paketen wird man von der doch sehr eingeschränkten Funktionalität der Fritzbox Standard-Firmware befreit. Vielleicht sucht bei Ihnen eine alte Fritzbox, z.B. eine 7362 SL eine neue Aufgabe? Der Autor dieser Zeilen hat ein solches System im Einsatz: Ein virtuelles Netz für IoT-Geräte (Schalter, LED-Leisten, etc.) ohne Cloudzwang und ein separates virtuelles Netz für die Amazon-Cloud. Die Amazone soll schliesslich nicht alles wisssen!

Zu den Themen MQTT, Kafka, Prometheus/Grafana und Kubernetes bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:

Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.