LoRaWAN-Sicherheitsüberwachung mit dem Teltonika RUT240 – Direkterfassung und Analyse von LoRa-Funksignalen am Laptop

Autor: DerSchneider

Einleitung

Das Internet der Dinge (IoT) kommuniziert zunehmend über energieeffiziente Langstrecken-Funktechnologien. LoRaWAN (Long Range Wide Area Network) hat sich dabei als Standard etabliert – von Smart Metern über Landwirtschaftssensoren bis hin zu industriellen Anlagen. Doch mit der Verbreitung wächst auch die Angriffsfläche. Wer sein eigenes LoRaWAN-Netzwerk betreiben oder fremde Signale in der Umgebung auf Abhörversuche prüfen möchte, steht vor einer Herausforderung: Die meisten kommerziellen LoRaWAN-Gateways sind für den Betrieb mit Cloud-Diensten optimiert, nicht für die direkte, manipulationssichere Erfassung von Rohsignalen.

Der Teltonika RUT240, ein robuster industrieller 4G/LTE-Router mit LoRaWAN-Erweiterung, bietet hier einen unkonventionellen, aber äußerst effektiven Weg. Statt ihn als Gateway in ein Netzwerk einzubinden, lässt er sich per Ethernet-Kabel direkt an einen Laptop anschließen – als dedizierter LoRa-Sniffer. Mit einem eigenen Python-Skript können alle empfangenen LoRaWAN-Pakete in einer CSV-Datei gespeichert werden, ohne dass eine Entschlüsselung der Nutzdaten erfolgt. Dies ist keine Schwäche, sondern ein Sicherheitsmerkmal: Es ermöglicht die lückenlose Überwachung der Funkaktivität, ohne in die Privatsphäre der rechtmäßigen Nutzer einzugreifen.

Dieser Artikel beleuchtet die historische Entwicklung von LoRa, die technischen Details des direkten Sniffings, Sicherheitskontroversen um Rohdaten-Erfassung und gibt eine praxistaugliche Bauanleitung für die direkte Laptop-Verbindung des RUT240.

Hauptteil

1. Historischer Kontext: Vom militärischen Spread Spectrum zum IoT-Standard

Die Ursprünge von LoRa liegen in der Chirp Spread Spectrum (CSS)-Technologie, die in den 1940er Jahren für militärische Radarsysteme entwickelt wurde. CSS nutzt frequenzmodulierte Impulse („Chirps“), um Signale über ein breites Frequenzband zu verteilen – robust gegen Störungen und Abhörversuche. Das französische Unternehmen Cycleo (später von Semtech übernommen) commercialisierte die Technik ab 2010 für die zivile IoT-Kommunikation.

2015 gründete sich die LoRa Alliance, um den LoRaWAN-Protokollstack zu standardisieren. Anders als konkurrierende Technologien wie NB-IoT (zellulär) oder Sigfox setzt LoRaWAN auf ein offenes, nicht lizenziertes Frequenzband (868 MHz in Europa, 915 MHz in den USA). Jeder kann ein Gateway betreiben – eine demokratische, aber auch sicherheitstechnisch herausfordernde Eigenschaft.

Die ursprüngliche Sicherheitsarchitektur von LoRaWAN (Version 1.0) basierte auf zwei Verschlüsselungsebenen: einem eindeutigen Device-spezifischen AppSKey für die Nutzdaten und einem NwkSKey für die Netzwerk-Metadaten. Die Annahme war, dass Endgeräte nur mit autorisierten Gateways kommunizieren. Doch die Praxis zeigte: Ein böswilliger Betreiber eines handelsüblichen Gateways kann alle LoRaWAN-Frames in Reichweite mitschneiden – die Verschlüsselung schützt nur den Inhalt, nicht die Existenz der Kommunikation.

2. Das Teltonika RUT240 – Mehr als ein Router

Das RUT240 ist primär als industrieller 4G-Router konzipiert, der Ethernet, WiFi und optional LoRaWAN kombiniert. Die Hardware basiert auf einem Qualcomm-Chipset, das LoRa über eine Mini-PCIe-Karte (z.B. von Microchip oder Semtech) einbindet. Seine Stärken:

• Robuste Metallgehäuse, erweiterter Temperaturbereich (-40 °C bis +75 °C)
• Zwei Ethernet-Ports mit separaten Subnetzen
• Integrierter Paket-Forwarder (Semtech UDP-Protokoll)
• Webinterface mit detaillierten LoRaWAN-Logs

Typischerweise wird das RUT240 als Gateway in ein bestehendes Netzwerk eingebunden, wo es die LoRa-Pakete an einen Network Server (z.B. ChirpStack, The Things Network) weiterleitet. Für unsere Zwecke nutzen wir jedoch eine „Point-to-Point“-Konfiguration: Das Gateway sendet die Rohdaten direkt per UDP an einen angeschlossenen Laptop – ohne Router, ohne Internet, ohne Cloud.

3. Direkte Verbindung – Netzwerkfrei LoRa mitschneiden

3.1 Topologie und IP-Konfiguration

Die folgende Tabelle zeigt die beiden praktikablen Verbindungsarten:

Beide Varianten benötigen keine aktive DHCP-Konfiguration – feste IPs am Laptop-Adapter verhindern automatische Router-Suche.

3.2 Konfiguration des RUT240 (Webinterface)

Nach dem Aufruf von http://192.168.1.1 (oder .2.1) navigiert man zu Services → LoRaWAN → Packet Forwarder. Entscheidend ist die Einstellung:

• Server-Adresse: die feste IP des Laptops (z.B. 192.168.1.100)
• Server-Port: 1700 (Standard)
• Protokoll: Semtech UDP (nicht MQTT oder ChirpStack)
• Gateway-ID: automatisch aus der Hardware abgeleitet (kann notiert werden)

Wichtige Sicherheitsanmerkung: Im Sniffer-Betrieb empfiehlt es sich, im RUT240 alle anderen Dienste (WiFi Access Point, Mobilfunk, DHCP-Server) zu deaktivieren – das Gateway soll ausschließlich LoRa-Frames auf den Laptop spiegeln.

4. Software-Implementierung: Passives Sniffing mit Python

Das Herzstück ist ein UDP-Paket-Empfänger auf dem Windows-Laptop. Das folgende Skript (ausführbar unter Python 3.8+) speichert alle eingehenden LoRaWAN-Frames in einer semikolonseparierten CSV-Datei. Es entschlüsselt keine Nutzdaten – nur die Header (DevAddr, FCnt, FPort, RSSI, SNR, Frequenz) werden extrahiert.

python

import socket, csv, json, base64
from datetime import datetime

CSV_FILE = "lorawan_log.csv"
HEADER = ["Timestamp", "GatewayID", "RSSI", "SNR", "Freq_MHz", "DevAddr", "FCnt", "FPort", "Payload_Size", "Raw_Hex"]

with open(CSV_FILE, "w", newline='') as f:
    csv.writer(f, delimiter=';').writerow(HEADER)

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(("0.0.0.0", 1700))
print("Listening on port 1700 (UDP) ...")

while True:
    data, _ = sock.recvfrom(1024)
    if data[0] != 0x02:  # nur PUSH_DATA (0x02) verarbeiten
        continue
    gateway_id = data[1:3].hex().upper()
    json_str = data[12:].decode('utf-8')
    rxpk = json.loads(json_str)["rxpk"]
    for p in rxpk:
        raw = base64.b64decode(p["data"])
        dev_addr = raw[1:5].hex().upper()  # Bytes 1-4: DevAddr
        fcnt = (raw[7] << 8) | raw[6]       # Little-Endian Frame Counter
        fport = raw[8] if len(raw) > 8 else 0
        with open(CSV_FILE, "a", newline='') as f:
            csv.writer(f, delimiter=';').writerow([
                datetime.utcnow().isoformat(),
                gateway_id, p.get("rssi", -999), p.get("lsnr", 0),
                p.get("freq", 0), dev_addr, fcnt, fport,
                len(raw), raw.hex()
            ])
        print(f"Packet from {dev_addr} | FCnt={fcnt} | RSSI={p.get('rssi')} dBm")

4.1 Erfasste Sicherheitsparameter

Die CSV speichert folgende Metadaten, die für eine Sicherheitsanalyse essenziell sind:

5. Kontroversen und rechtliche Rahmenbedingungen

Die passive Erfassung von LoRaWAN-Signalen ist ein zweischneidiges Schwert. Einerseits erlaubt sie Betreibern, die eigene Netzwerksicherheit zu überprüfen (z.B. ob unbefugte Geräte senden oder ob Replay-Angriffe stattfinden). Andererseits kann jeder mit einem handelsüblichen LoRa-Gateway die Kommunikation aller Geräte in Reichweite mitschneiden – selbst wenn die Nutzdaten verschlüsselt sind, bleiben die Metadaten (Absender, Zeitpunkt, Paketgröße, ungefährer Standort) im Klartext.

In Deutschland regelt § 148 TKG (Telekommunikationsgesetz) das Abhören nicht öffentlicher Telekommunikation. LoRaWAN wird jedoch meist als „nicht öffentlich“ im Sinne des Gesetzes betrachtet, wenn es sich um ein geschlossenes Netzwerk handelt. Das Mitschneiden fremder Pakete ohne Einwilligung ist grundsätzlich verboten – mit Ausnahme der eigenen Geräte oder bei berechtigtem Sicherheitsinteresse (z.B. durch den Netzbetreiber). Der hier beschriebene Sniffer dient daher zur Überwachung des eigenen LoRaWAN-Netzes oder zum Nachweis von Störsendern im eigenen Umfeld (nach Abstimmung mit der Bundesnetzagentur).

Eine aktuelle Debatte entzündet sich an der Frage, ob LoRaWAN-Gerätehersteller verpflichtet werden sollten, feste DevAddr und unveränderliche Frame Counter zu implementieren – derzeit können viele Geräte nach einem Neustart den Frame Counter zurücksetzen, was Replay-Angriffe vereinfacht.

6. Praxisbeispiel: Auswertung der CSV-Datei in Excel

Nach einem Tag Sniffing (z.B. in einer industriellen Halle mit 50 LoRa-Sensoren) enthält die CSV tausende Zeilen. Mit Excel-Pivot-Tabellen können folgende Anomalien schnell erkannt werden:

1. Replay-Angriffserkennung:
   Formel = WENN(UND(DevAddr=A2; FCnt=A1); "Replay"; "OK") – doppelte FCnt-Werte pro Gerät sind verdächtig.
2. Unbekannte DevAddr:
   Eine Hilfstabelle mit autorisierten Adressen erlaubt den Abgleich über SVERWEIS.
3. RSSI-Ausreißer:
   Ein Boxplot (Excel 2016+) visualisiert ungewöhnlich niedrige RSSI-Werte, die auf Abschattung oder aktive Störung hindeuten.

7. Zukunftsperspektiven: KI-gestützte Angriffserkennung

Die große Menge an erfassten LoRa-Metadaten ist ideal für Machine-Learning-Modelle. Aktuelle Forschungsarbeiten (z.B. von der Universität Bremen, 2023) nutzen Random Forest und LSTM-Netzwerke, um aus RSSI/SNR-Zeitreihen Jammer oder Replays mit über 95% Genauigkeit zu erkennen. Das hier vorgestellte CSV-Log kann direkt als Trainingsdatensatz dienen.

Ein weitere Entwicklung ist der LoRaWAN-Sniffer-as-a-Service – Cloud-basierte Systeme, die Gateways von Drittanbietern (z.B. Helium Network) für Sicherheitsaudits nutzen. Die direkte Laptop-Lösung bleibt jedoch die manipulationssicherste Variante, da sie keine externe Netzwerkverbindung benötigt.

Fazit und Ausblick

Der Teltonika RUT240 eignet sich hervorragend als dedizierter LoRaWAN-Sniffer, wenn man ihn direkt per Ethernet-Kabel an einen Laptop anschließt. Mit einem einfachen Python-Skript lassen sich alle empfangenen Rohdaten in einer CSV-Datei speichern – ohne Cloud, ohne Internet und vor allem ohne Entschlüsselung der Nutzdaten. Dies ermöglicht eine passive Sicherheitsüberwachung, die weder in die Privatsphäre Dritter eingreift noch selbst zur Angriffsfläche wird.

Die historische Entwicklung von LoRa zeigt, dass Sicherheit oft ein nachträglicher Gedanke war – noch heute kämpfen Entwickler mit schwacher Schlüsselverwaltung und replizierbaren Frame Counters. Für Betreiber kritischer Infrastrukturen ist daher eine eigene Überwachung unerlässlich. Die hier beschriebene kostengünstige Lösung (RUT240 ca. 200–300 €, plus ein beliebiger Laptop) setzt keine tiefen Netzwerkkenntnisse voraus und kann innerhalb einer Stunde aufgesetzt werden.

In Zukunft werden automatisierte Erkennungssysteme auf Basis von KI die Analyse der CSV-Logs übernehmen – die Datenbasis ist bereits heute vorhanden. Wer sein LoRaWAN-Netzwerk schützen möchte, sollte nicht auf die Hersteller warten, sondern selbst zum Sniffer greifen.

Quellen

1. LoRa Alliance, LoRaWAN Link Layer Specification 1.0.4, 2020.
2. Teltonika Networks, RUT240 User Manual v1.8, 2023.
3. Semtech Corporation, SX1302 Datasheet – LoRa Gateway Baseband Processor, 2021.
4. Bundesnetzagentur, Frequenznutzungsbestimmungen für SRD (Short Range Devices), Amtsblatt 2022.
5. Neumann, J.; Schmidt, K. (Universität Bremen), Machine Learning based Intrusion Detection for LoRaWAN, in: Proceedings of the 12th International Conference on the Internet of Things (IoT 2023), S. 45–52.
6. TKG (Telekommunikationsgesetz) vom 23. Juni 2021 (BGBl. I S. 1858), § 148 – Schutz des Fernmeldegeheimnisses.