Raspberry Pi im IoT absichern: Eine praktische Härtungs-Checkliste

Um ein Raspberry-Pi-IoT-Gerät abzusichern, müssen Sie die einfachen Türen schließen, nach denen Angreifer suchen: Passwort-Logins, offene Ports, veraltete Pakete, Dienste mit root-Rechten und unverschlüsselter Datenverkehr. Diese Checkliste geht jede Ebene mit den genauen Befehlen für Raspberry Pi OS Bookworm durch und endet mit einer TLS-verschlüsselten MQTT-Verbindung, die überhaupt keine eingehenden Ports benötigt. Arbeiten Sie sie einmal durch und übernehmen Sie das Ergebnis in Ihr Image, damit jedes neue Gerät bereits gehärtet startet.

Bedrohungsmodell für einen Pi im Feld

Ein Pi-Gateway ist ein kleiner Linux-Server an einem Ort, den Sie nicht vollständig kontrollieren: im Netzwerk eines Kunden, in der Fertigungshalle, in einem Schaltschrank am Straßenrand. Die realistischen Bedrohungen sind nicht exotisch. Automatisierte Scanner probieren Standard- und schwache Passwörter über SSH aus. Ungepatchte Dienste werden über bekannte Schwachstellen angegriffen. Eine kompromittierte Anwendung mit root-Rechten übernimmt das ganze Gerät. Zugangsdaten in einem Skript landen in einem Git-Repository oder einem Support-Ticket. Unverschlüsselter MQTT-Verkehr wird in einem geteilten Netz mitgelesen oder verändert. Jemand mit physischem Zugang zieht die SD-Karte und liest sie aus.

Jeder Punkt der folgenden Checkliste zielt auf eine dieser Bedrohungen. Keiner erfordert spezielle Hardware. Für industrielle Umgebungen passt dieser Ansatz gut zu den Grundgedanken von IEC 62443 und den Anforderungen, die NIS2 und der EU Cyber Resilience Act an vernetzte Geräte stellen.

Die Checkliste im Überblick

1. Benutzerkonten

Aktuelle Raspberry-Pi-OS-Images werden nicht mehr mit dem alten Standardbenutzer pi und seinem Passwort ausgeliefert; Sie legen einen Benutzer im Raspberry Pi Imager oder beim ersten Start an. Wählen Sie einen nicht naheliegenden Benutzernamen und ein langes Passwort und verteilen Sie niemals ein Golden Image, bei dem alle Geräte dieselben Zugangsdaten teilen. Wenn Sie Images für eine Geräteflotte bauen, erzeugen Sie gerätespezifische Zugangsdaten bei der Provisionierung.

# prüfen, welche Konten sich anmelden können
grep -vE "nologin|false" /etc/passwd
# Passwort eines Kontos sperren, das nur Schlüssel nutzen soll
sudo passwd -l someuser

2. SSH nur mit Schlüsseln

Kopieren Sie Ihren öffentlichen Schlüssel auf den Pi, prüfen Sie, dass die Anmeldung damit funktioniert, und deaktivieren Sie dann die Passwort-Authentifizierung über eine Drop-in-Datei, damit Paket-Updates Ihre Änderung nicht überschreiben.

# auf Ihrer Workstation
ssh-keygen -t ed25519 -C "admin@workstation"
ssh-copy-id admin@gateway-01.local

# auf dem Pi
sudo tee /etc/ssh/sshd_config.d/10-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 3
EOF
sudo sshd -t && sudo systemctl reload ssh

Lassen Sie Ihre aktuelle Sitzung offen und testen Sie eine neue Anmeldung in einem zweiten Terminal, bevor Sie sie schließen. Brauchen Sie SSH auf ausgerollten Geräten gar nicht, deaktivieren Sie es mit sudo systemctl disable --now ssh und nutzen Sie ein Wartungsverfahren, das es vorübergehend aktiviert.

3. Firewall

Ein MQTT-Gateway baut nur ausgehende Verbindungen auf und braucht daher kaum eingehende Regeln. ufw hält die Konfiguration übersichtlich:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.10.0/24 to any port 22 proto tcp   # nur Management-Subnetz
sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

Ersetzen Sie das Subnetz durch Ihr Management-Netz. In strengeren Umgebungen setzen Sie auch ausgehend auf deny und erlauben nur DNS, NTP, Paketspiegel und Ihren MQTT-Broker auf Port 8883. Ergänzen Sie fail2ban, wenn SSH aus größeren Netzen erreichbar sein muss.

4. Updates

Die meisten realen Kompromittierungen nutzen Schwachstellen aus, für die es längst Korrekturen gibt. Aktivieren Sie automatische Sicherheitsupdates und planen Sie regelmäßige Voll-Upgrades:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
sudo unattended-upgrade --dry-run --debug | tail -n 20

Beziehen Sie Ihre Python-Abhängigkeiten in die Routine ein. Pinnen Sie Versionen in einer requirements.txt, testen Sie Upgrades zunächst auf einem Gerät und rollen Sie sie dann auf die Flotte aus.

5. Ungenutzte Dienste deaktivieren

Jeder laufende Dienst muss gepatcht werden und ist ein mögliches Angriffsziel. Listen Sie auf, was aktiviert ist, und schalten Sie ab, was Ihr Gateway nicht braucht:

systemctl list-unit-files --state=enabled --type=service
sudo systemctl disable --now avahi-daemon cups 2>/dev/null
sudo systemctl disable --now bluetooth   # nur wenn Sie kein BLE nutzen

Auf Geräten ohne Bildschirm können Sie WLAN oder Bluetooth in der config.txt auch auf Hardware-Ebene mit dtoverlay=disable-wifi oder dtoverlay=disable-bt deaktivieren, wenn das Gerät nur Ethernet nutzt.

6. Minimale Rechte für Ihre Anwendung

Betreiben Sie den MQTT-Client als eigenen Systembenutzer ohne Login-Shell und nur mit den Gruppen, die er braucht (zum Beispiel gpio oder dialout). Lassen Sie ihn dann von systemd in einer Sandbox ausführen:

sudo useradd --system --home /opt/gateway --shell /usr/sbin/nologin gateway
sudo usermod -aG gpio gateway

[Service]
User=gateway
Group=gateway
EnvironmentFile=/etc/gateway/mqtt.env
ExecStart=/opt/gateway/.venv/bin/python -u /opt/gateway/gateway.py
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/lib/gateway
ProtectKernelTunables=yes
ProtectControlGroups=yes
RestrictSUIDSGID=yes

ProtectSystem=strict macht das gesamte Dateisystem für den Dienst schreibgeschützt – bis auf die Pfade, die Sie angeben. Ein kompromittiertes Skript kann so weder Systemdateien verändern noch sich dauerhaft einnisten. Mit systemd-analyze security gateway.service sehen Sie, welche weiteren Optionen infrage kommen. Die vollständige Unit inklusive Neustart-Richtlinien finden Sie unter Python-MQTT-Skript beim Booten starten.

7. Geheimnisse aus dem Code heraushalten

Speichern Sie Broker-Zugangsdaten in einer Umgebungsdatei, die nur für root lesbar ist (systemd liest sie, bevor es die Rechte abgibt):

sudo mkdir -p /etc/gateway
sudo tee /etc/gateway/mqtt.env > /dev/null <<'EOF'
MQTT_HOST=broker.connectmq.com
MQTT_PORT=8883
MQTT_USERNAME=YOUR_USERNAME
MQTT_PASSWORD=YOUR_PASSWORD
MQTT_CLIENT_ID=YOUR_CLIENT_ID
EOF
sudo chmod 600 /etc/gateway/mqtt.env

Halten Sie die Datei aus der Versionskontrolle und aus jedem Image heraus, das Sie weitergeben. Geht ein Gerät verloren oder wird es ausgemustert, widerrufen Sie seine Zugangsdaten auf Broker-Seite.

8. Die MQTT-Verbindung absichern

Einfaches MQTT auf Port 1883 überträgt Zugangsdaten und Daten im Klartext. Verwenden Sie TLS auf Port 8883. ConnectMQ-Broker präsentieren ein Let's-Encrypt-Zertifikat, dem der Pi über sein System-CA-Bundle bereits vertraut; Zertifikatsdateien sind also nicht nötig:

import os
import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=os.environ["MQTT_CLIENT_ID"])
client.username_pw_set(os.environ["MQTT_USERNAME"], os.environ["MQTT_PASSWORD"])
client.tls_set()                       # prüft Serverzertifikat und Hostnamen
client.connect(os.environ["MQTT_HOST"], int(os.environ["MQTT_PORT"]), keepalive=60)
client.loop_forever()

Rufen Sie in der Produktion niemals tls_insecure_set(True) auf; das deaktiviert die Hostnamenprüfung und macht TLS wirkungslos. Achten Sie auf die korrekte Uhrzeit, denn die Zertifikatsprüfung schlägt fehl, wenn der Pi mit falschem Datum startet und NTP noch nicht synchronisiert hat. Verwenden Sie für jedes Gerät eigene Zugangsdaten: Bei ConnectMQ sind Client IDs an die ausgegebenen Zugangsdaten gebunden, und wiederholt fehlgeschlagene Logins von einer Adresse führen zur IP-Sperre. Der Leitfaden Python MQTT mit TLS behandelt Zertifikatsoptionen ausführlicher, und die Best Practices für MQTT-Sicherheit decken die Broker-Seite ab. Da das Gerät nur ausgehend verbindet, bleibt die Firewall aus Schritt 3 geschlossen.

Denken Sie daran, dass der öffentliche MQTT-Broker für jeden lesbar ist. Er dient nur zum Testen; produktive Geräte gehören auf einen privaten Broker.

9. Monitoring

Auch ein gehärtetes Gerät muss beobachtet werden. Prüfen Sie journalctl -u ssh auf unerwartete Anmeldungen, publizieren Sie Zustands- und Sicherheitsereignisse (fehlgeschlagene SSH-Versuche, Dienstneustarts, unerwartete Reboots) auf ein MQTT-Topic und alarmieren Sie bei Auffälligkeiten. Ein gespeichertes Last-Will-Status-Topic meldet Ihnen sofort, wenn ein Gerät offline geht – das kann das erste Anzeichen einer Manipulation sein.

10. Physische Sicherheit

Wer den Speicher entnehmen kann, kann alles darauf lesen, auch Zugangsdaten. Verwenden Sie ein abschließbares Gehäuse, ziehen Sie bei Geräten auf Compute-Module-Basis das Booten vom internen Speicher in Betracht, deaktivieren Sie ungenutzte USB- und HDMI-Schnittstellen, wo Ihre Hardware das erlaubt, und behandeln Sie jedes Gerät, das sich außerhalb Ihrer Kontrolle befand, als nicht vertrauenswürdig, bis es neu aufgesetzt wurde. Die Raspberry-Pi-Dokumentation erklärt die relevanten Konfigurationsoptionen.

Diese Schritte ergänzen sich gut mit den Tipps zur Zuverlässigkeit des Raspberry Pi und bilden gemeinsam die Basis für jedes Gateway, das mit dem Raspberry Pi MQTT-Tutorial entsteht.

Sicher verbinden mit ConnectMQ

Ein gehärtetes Gerät verdient einen Broker, der für die Produktion gebaut ist. ConnectMQ ist ein verwalteter MQTT-Broker mit TLS auf Port 8883, sicherem WebSocket auf Port 8084, gerätespezifischen Zugangsdaten und Flood-Schutz. Legen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker an, ohne Kreditkarte, und verbinden Sie Ihren ersten gehärteten Pi in wenigen Minuten über TLS.

Häufig gestellte Fragen

Muss ich auf dem Raspberry Pi Ports für MQTT öffnen?

Nein. Ein MQTT-Client verbindet sich ausgehend mit dem Broker, daher braucht der Pi für MQTT keine eingehenden Ports. Erlauben Sie eingehendes SSH, wenn überhaupt, nur aus vertrauenswürdigen Management-Netzen.

Ist Port 1883 jemals akzeptabel?

Nur für lokale Tests mit unkritischen Daten. Alles, was ein nicht vertrauenswürdiges Netz durchquert, sollte TLS auf Port 8883 nutzen, damit Zugangsdaten und Payloads verschlüsselt sind.

Sollte jedes Gerät eigene MQTT-Zugangsdaten haben?

Ja. Eindeutige Zugangsdaten erlauben es, ein einzelnes verlorenes oder kompromittiertes Gerät zu sperren, ohne den Rest der Flotte anzufassen, und sie machen Logs aussagekräftig.

Hilft Festplattenverschlüsselung auf einem Raspberry Pi?

Sie schützt die Daten, wenn der Speicher gestohlen wird, doch das Gerät muss sich dann beim Booten ohne anwesende Person entsperren können – auf einem Pi ist das schwer sicher umzusetzen. Für die meisten Gateways ist es praktikabler, möglichst wenige Geheimnisse zu speichern und widerrufbare Zugangsdaten zu nutzen.