Raspberry Pi als brein van je smarthome

Naast authenticatie, dus alleen gewenste gebruikers toelaten, heb je autorisatie nodig voor een goede beveiliging van je smarthome: bepalen welke gebruikers wat mogen doen. Je wilt niet dat elke gebruiker alles met alle apparaten of software in je smarthome kan aanvangen.

In het configuratiebestand settings.js van Node-RED stel je bij individuele gebruikers hun permissies in bij de string permissions. * betekent dat de gebruiker, bijvoorbeeld de beheerder, alles mag, read dat de gebruiker alleen leesrechten heeft. Je kunt ook specifiekere rechten geven voor elk van de api-endpoints. De api-documentatie van elk endpoint legt uit welke permissies nodig zijn. Zo kun je met flows.read de configuratie van de huidige flow bekijken en met flows.write diezelfde configuratie wijzigen.

In Mosquitto gebeurt autorisatie met een access-control list-, of acl-bestand. Daarnaar verwijs je in mosquitto.conf:

acl_file /mosquitto/config/acl

In dit bestand bepaal je voor elke gebruiker op welke topics hij kan inschrijven en op welke topics hij kan publiceren. Wil je bijvoorbeeld de gebruiker admin lees- en schrijftoegang tot alle topics geven, dan is de acl:

user admin
topic #

Het is een goed idee om voor elk domoticaprogramma dat van je MQTT-broker gebruikmaakt, een gebruiker aan te maken in Mosquitto en een bijbehorende acl met permissies aan te maken. Als je bijvoorbeeld 'bt-mqtt-gateway' alleen gebruikt om data van Bluetooth LE-sensoren naar je MQTT-broker te sturen, geeft de volgende acl die permissies en niet meer:

user bt-mqtt-gateway
topic write bt-mqtt-gateway/#

Voor een programma als rtl_433, dat draadloze sensors uitleest, doe je dan hetzelfde. Als je dan in Node-RED een dashboard hebt gemaakt dat de temperatuurgegevens van al deze sensors toont, laat dit dan verbinding maken met de MQTT-broker door middel van gebruikersnaam 'dashboard' en geef het deze acl:

user dashboard
topic read bt-mqtt-gateway/+/+/temperature
topic read rtl433/+/+/+/temperature_C

Overigens kunnen deze acl’s in Mosquitto ook dynamisch aangepast worden met een beveiligingsplug-in. Een ander belangrijk punt is dat je het best zoveel mogelijk netwerkcommunicatie versleutelt

Versleutelde verbindingen

Een ander belangrijk punt in de beveiliging van je smarthome is dat je het best zoveel mogelijk netwerkcommunicatie versleutelt, doorgaans via TLS. Hiermee voeg je niet alleen encryptie toe, maar ook authenticatie van de server: het TLS-certificaat dat de server je toont, geeft je garanties dat je verbinding maakt met de juiste server.

In het eenvoudigste geval maak je gewoon een self-signed certificate aan, maar het is netter om je eigen certificaatautoriteit, of CA, aan te maken en daarmee het certificaat van je server te ondertekenen. Als je dan het CA-certificaat toevoegt aan de lijst met vertrouwde CA’s van je webbrowser en/of besturingssysteem, krijg je geen waarschuwing.

Vooral als je meer dan één server in je smarthome gebruikt, is het handiger om met een CA te werken; anders moet je elk van die certificaten toevoegen aan de lijst met vertrouwde certificaten en dat op al je apparaten die toegang tot die servers nodig hebben.

Er zijn diverse manieren om een certificaatautoriteit aan te maken en er servercertificaten mee te ondertekenen. Het kan rechtstreeks met OpenSSL-opdrachten, of met een tool als mkcert of step-ca. Die laatste is een heuse ACME-compatibele certificaatautoriteit. Smallstep, de ontwikkelaar van step-ca, heeft instructies gepubliceerd om automatisch certificaten aan te vragen en te vernieuwen in Caddy, Nginx, Apache en Traefik.

MKCert certificaat

Met mkcert maak je eenvoudig een CA en TLS-certificaten aan voor je interne netwerk.

Certificaten gebruiken

Heb je eenmaal een CA en certificaat voor je server, dan is het een kwestie van dit certificaat gebruiken in de gewenste software. Sla de root-CA, de sleutel en het certificaat bijvoorbeeld op in een directory 'containers/certificates' en koppel deze in je Docker-containers als read-only volume.

Voor Node-RED doe je dat bijvoorbeeld door - ./containers/certificates:/etc/ssl/private:ro aan de volumes in je Docker Compose-bestand toe te voegen. Dan commentarieer je in het begin van het configuratiebestand settings.js var fs = require("fs"); uit en zoek je daarna naar Https. Daar voer je dan het volgende in om naar de sleutel en het certificaat te verwijzen en HTTP-verkeer automatisch naar Https door te verwijzen:

https: {
key: fs.readFileSync('/etc/ssl/private/key.pem'),
cert: fs.readFileSync('/etc/ssl/private/cert.pem')
},

requireHttps: true,

Voor Mosquitto werkt dit net zo. Koppel de certificaten in een volume met - ./containers/certificates:/mosquitto/config/certs:ro in het Docker Compose-bestand. Verander bij de poorten ook - "1883:1883" in - "8883:8883", de standaardpoort voor Mqtts (MQTT over TLS). In je mosquitto.conf verwijs je dan naar de root-CA, de sleutel en het certificaat met:

listener 8883
cafile /mosquitto/config/certs/rootCA.pem
keyfile /mosquitto/config/certs/key.pem
certfile /mosquitto/config/certs/cert.pem

Als je nu bijvoorbeeld in Node-RED een ‘mqtt in’-node aanmaakt en dan een MQTT-broker toevoegt, kies je bij de verbindingseigenschappen poort 8883. Verzeker je ervan dat je dezelfde hostname invult als de hostname waarvoor je het TLS-certificaat hebt aangemaakt. Schakel dan ook TLS in en voeg een nieuwe TLS-configuratie toe. Upload daar je CA-certificaat. In het tabblad Security vul je de vereiste combinatie van gebruikersnaam en wachtwoord in.

Node Red mqtt broker