Sécurité IoT MQTT et firmware : tutoriel durcissement 2026

Lecture : 14 minutes · Niveau : avancé · Mise à jour : avril 2026

⚠️ Disclaimer : Toute opération d’audit (Shodan, scan, OTA) ne s’applique qu’à votre propre infrastructure ou avec autorisation écrite. Pour audit pro de tiers, voir pentesting éthique pour PME.

Tutoriel pratique pour durcir un déploiement IoT : MQTT en TLS avec authentification + ACL fines, firmware signé pour OTA sécurisé, segmentation VLAN du réseau IoT, audit avec Shodan, monitoring de comportement anormal. Lab : votre propre installation Raspberry Pi + ESP32 du cluster IoT précédent.

Voir aussi → IoT pratique et sécurité pour PME, ESP32 + MQTT : tutoriel pratique, Raspberry Pi serveur domestique.

1. Modèle de menace IoT

Acteurs / motivations :
– Botnet operators (Mirai successors) → recrutement appareils mal sécurisés
– Cybercriminels → entrée vers le SI principal via IoT mal segmenté
– Étatiques → surveillance / sabotage (rare en PME)
– Insider → vol de données via accès physique

Surfaces d’attaque IoT typiques :
1. Mots de passe par défaut non changés
2. Firmware obsolète avec CVE connues
3. MQTT non chiffré sniffable sur Wi-Fi
4. Exposition Internet sans nécessité (Shodan le voit)
5. Réseau plat = un capteur compromis voit tout
6. OTA non signé = injection firmware malveillant
7. Communication non authentifiée = un faux capteur peut publier
8. Données en clair sur le filesystem ESP32

Approche défense en profondeur : chaque couche faillible doit avoir au moins une autre couche derrière.

2. MQTT en TLS avec certificats

Sur le Raspberry Pi : générer une CA + certificat serveur.

mkdir -p ~/mqtt-certs && cd ~/mqtt-certs

# 1. CA (autorité de certification)
openssl genrsa -out ca.key 2048
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \
  -subj "/CN=PME-IoT-CA"

# 2. Serveur
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr \
  -subj "/CN=mqtt.pme.local"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 3650

# 3. Permissions Mosquitto
sudo cp ca.crt server.crt server.key /etc/mosquitto/certs/
sudo chown mosquitto:mosquitto /etc/mosquitto/certs/*

Configuration Mosquitto (/etc/mosquitto/conf.d/tls.conf) :

# Désactiver port non chiffré pour Internet (garder local pour ESP32 si besoin)
listener 1883 192.168.1.20    # uniquement bind LAN
allow_anonymous false
password_file /etc/mosquitto/passwd

# Port TLS
listener 8883 0.0.0.0
cafile   /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile  /etc/mosquitto/certs/server.key
require_certificate false      # true pour mTLS (mutual TLS)

sudo systemctl restart mosquitto

Tester :

mosquitto_pub -h mqtt.pme.local -p 8883 \
  --cafile ca.crt -t test -m "secure" -u capteur1 -P motdepasse

ESP32 en MQTT-S : voir code dans ESP32 + MQTT tutoriel — utiliser WiFiClientSecure avec setCACert(ca_cert_pem).

3. Authentification + ACL Mosquitto

Mosquitto ACL restreint quel utilisateur peut publier/souscrire à quel topic.

/etc/mosquitto/acl.conf :

# capteur1 ne peut publier que sous son propre topic
user capteur1
topic write entrepot/zone-A/+

# capteur2 idem
user capteur2
topic write entrepot/zone-B/+

# dashboard peut tout lire
user dashboard
topic read entrepot/#

# admin peut tout
user admin
topic readwrite #

/etc/mosquitto/conf.d/local.conf :

acl_file /etc/mosquitto/acl.conf

sudo systemctl restart mosquitto

Test ACL :

# capteur1 essaie de publier ailleurs → bloqué
mosquitto_pub -h localhost -t entrepot/zone-B/temp \
  -m "fake" -u capteur1 -P motdepasse
# Côté Mosquitto log : ACL denying access

Bonne pratique : un user MQTT par capteur, un mot de passe unique fort, ACL strictes.

4. Firmware signé pour ESP32

ESP32 supporte Secure Boot v2 + Flash Encryption pour empêcher firmware malveillant.

Génération clé :

espsecure.py generate_signing_key --version 2 secure_boot_signing_key.pem

Build avec ESP-IDF :

# menuconfig → Secure Boot → enable
idf.py menuconfig
# Security features → Enable hardware Secure Boot
# Sign binaries with key

idf.py build
idf.py flash
# La première flash écrit la clé dans eFuse — irréversible

⚠️ Activation eFuse irréversible. Tester en lab d’abord, jamais sur production sans plan.

Alternative simple Arduino : firmware non signé mais transmis via OTA chiffré + check hash SHA-256 côté server avant flash.

// Vérifier hash SHA-256 du firmware téléchargé avant flash
#include "mbedtls/sha256.h"
// ... hash le buffer reçu, comparer avec hash distribué OOB ...

5. OTA sécurisé

Risques OTA non sécurisé :
– Firmware injecté par MITM
– Rollback vers version vulnérable
– Attaquant pousse firmware crypto-mining

Approche sécurisée :

HTTPS pour le serveur OTA (pas HTTP)
Certificat CA validé côté ESP32 (setCACert)
Hash SHA-256 du firmware vérifié avant flash
Rollback protection (refuser version < celle actuelle)
Signature firmware (Secure Boot v2)

#include <HTTPUpdate.h>

void update_check() {
  WiFiClientSecure client;
  client.setCACert(server_cert_pem);

  HTTPUpdate.setLedPin(LED_BUILTIN, LOW);
  t_httpUpdate_return ret = HTTPUpdate.update(client,
    "https://ota.pme.local/firmware/v1.2.3.bin",
    "v1.2.0",  // version actuelle pour rollback check
    [](int progress, int total) {
      Serial.printf("OTA: %d%%\n", (progress * 100) / total);
    });

  switch (ret) {
    case HTTP_UPDATE_FAILED:
      Serial.printf("Update failed: %s\n", HTTPUpdate.getLastErrorString());
      break;
    case HTTP_UPDATE_NO_UPDATES:
      Serial.println("No updates available");
      break;
    case HTTP_UPDATE_OK:
      Serial.println("Update OK, rebooting");
      break;
  }
}

Côté serveur : héberger firmware sur HTTPS Nginx avec Let’s Encrypt + endpoint qui sert un manifest version.json :

{
  "version": "1.2.3",
  "url": "https://ota.pme.local/firmware/v1.2.3.bin",
  "sha256": "abc123..."
}

6. Segmentation VLAN du réseau IoT

Un IoT compromis ne doit pas pouvoir parler au LAN principal.

Setup réseau type :

Internet
   │
   ▼
[Routeur principal]
   │
   ├── VLAN 10 LAN  (192.168.10.0/24) → laptops, tels, serveurs internes
   ├── VLAN 20 IoT  (192.168.20.0/24) → capteurs ESP32, caméras
   └── VLAN 30 GUEST (192.168.30.0/24) → visiteurs

Règles firewall (pf, OpenWRT, Mikrotik) :
– VLAN 20 → VLAN 10 : DENY (sauf flow particulier vers Pi serveur)
– VLAN 20 → Internet : ALLOW (limité aux URLs OTA)
– VLAN 10 → VLAN 20 : ALLOW (admin)
– VLAN 30 → VLAN 10/20 : DENY

Sur OpenWRT (exemple) :

# Créer VLAN 20 IoT
uci set network.iot=interface
uci set network.iot.proto='static'
uci set network.iot.ipaddr='192.168.20.1'
uci set network.iot.netmask='255.255.255.0'
uci commit

# Firewall : zone iot avec output forward limité
uci add firewall zone
uci set firewall.@zone[-1].name='iot'
uci set firewall.@zone[-1].network='iot'
uci set firewall.@zone[-1].forward='REJECT'
uci commit firewall
/etc/init.d/firewall restart

Wi-Fi dédié IoT : SSID séparé bound au VLAN 20.

7. Détecter exposition Internet (Shodan)

Vérifier que vos appareils ne sont PAS exposés :

# Trouver IP publique de votre PME
curl -s ifconfig.me
# 41.x.y.z

# Sur shodan.io (compte gratuit ok) :
# Recherche : "ip:41.x.y.z"
# → liste des services exposés depuis votre IP

Avec API Shodan (paid):

import shodan
api = shodan.Shodan("VOTRE_CLE")

# Audit IP publique de la PME
info = api.host("41.x.y.z")
print(f"Open ports: {info['ports']}")
for s in info['data']:
    print(f"  {s['port']}: {s['product']} {s.get('version','')}")

Filtres Shodan utiles pour audit IoT :
– port:1883 : MQTT exposé sans TLS
– port:8883 : MQTT-S
– product:Mosquitto
– country:SN (Sénégal)
– org:"VotreEntreprise"

Si vous trouvez vos appareils exposés : firewall + NAT immédiats, audit complet, vérifier breach.

8. Monitoring trafic anormal

Un capteur compromis génère typiquement du trafic anormal : volume inhabituel, destinations inconnues, scans réseau.

Sur le Raspberry Pi (script Python simple) :

# anomaly_monitor.py
import paho.mqtt.client as mqtt
from collections import defaultdict
from time import time

WINDOW = 60  # secondes
THRESHOLD = 100  # messages / minute / device

counts = defaultdict(list)

def on_message(client, userdata, msg):
    device = msg.topic.split('/')[1]  # entrepot/[zone]/...
    now = time()
    counts[device].append(now)
    counts[device] = [t for t in counts[device] if now - t < WINDOW]

    if len(counts[device]) > THRESHOLD:
        alert(device, len(counts[device]))

def alert(device, rate):
    print(f"[!] ALERT: {device} → {rate} msg/min (threshold {THRESHOLD})")
    # → notification WhatsApp / email

c = mqtt.Client()
c.username_pw_set("dashboard", "...")
c.on_message = on_message
c.connect("localhost", 1883)
c.subscribe("entrepot/#")
c.loop_forever()

Solutions plus complètes :
– Suricata ou Zeek : IDS réseau analysant tout le trafic VLAN IoT
– Fail2ban + log Mosquitto : ban IP qui spam authentification
– Grafana alerting sur métriques anormales

9. Hardening filesystem ESP32

Problème : un attaquant avec accès physique peut dumper la flash et lire les credentials Wi-Fi, MQTT, certificats.

Solutions :

Flash Encryption (eFuse, irréversible) :

idf.py menuconfig
# Security features → Enable Flash Encryption (release mode)
idf.py flash monitor

Stockage credentials chiffrés dans NVS :

#include "nvs_flash.h"
#include "nvs.h"

nvs_handle_t h;
nvs_open("secrets", NVS_READWRITE, &h);
nvs_set_str(h, "wifi_pass", "MotDePasse");
nvs_set_str(h, "mqtt_token", "abc123xyz");
nvs_commit(h);
nvs_close(h);

NVS chiffré si Flash Encryption activée.

Désactiver UART en production :

// Empêcher dump via UART
Serial.end();

⚠️ Dump physique de flash reste possible avec équipement spécialisé (ChipWhisperer, etc.). Pour environnements très critiques : modules ESP32 avec eFuse Flash Encryption release mode + boîtiers anti-tamper.

10. Plan de réponse à incident IoT

Indicateurs de compromission :
– Volume MQTT anormal sur un device
– Connexions vers IP/domaine inconnu
– Modification fichier ou comportement bizarre
– Alerte Shodan / threat intelligence

Procédure :

Isoler : couper Wi-Fi VLAN IoT (ou unplug Pi en dernier recours)
Préserver : capture mémoire / dump flash si possible
Analyser : logs Mosquitto + journal Pi
Patcher : appliquer firmware corrigé (OTA si infra OTA non compromise)
Communiquer : utilisateurs internes, cdp.sn si données personnelles compromises
Retex : documenter pour amélioration

Préparation :
– Inventaire à jour des appareils (modèle, firmware, position)
– Procédure de mise à jour rapide testée
– Backup config Mosquitto + ACL
– Contact CERT-CDP (Sénégal) ou équivalent local
– Plan de communication client en cas de fuite

FAQ

Mes capteurs ESP32 supportent-ils tous TLS ?

ESP32 oui (RAM suffisante). ESP8266 marginal (RAM limite, certificat large peut faire planter). Pour ESP8266 : utiliser certificat client minimal (256 bits) ou bascule réseau local non chiffré + segmentation forte.

Faut-il rotation des mots de passe MQTT ?

Pour PME standard : annuelle suffit si pas de breach détecté. Pour environnement à enjeu : trimestrielle. Automatiser via Ansible ou script Python qui regénère + push aux capteurs via OTA.

mTLS (mutual TLS) ou TLS simple ?

TLS simple suffit pour la majorité (serveur authentifié, client par mot de passe). mTLS (client présente aussi un certificat) pour environnements très sensibles. mTLS plus complexe à gérer (PKI, distribution certificats, révocation).

Comment auditer mon parc IoT existant ?

1) Inventaire : nmap scan VLAN IoT, lister modèles/firmwares. 2) CVE check : rapprocher firmwares avec CVE bases (NVD, vendeur). 3) Audit configs : mots de passe, services, expositions. 4) Audit Shodan IP publique. 5) Pentest si enjeu majeur (voir pentesting éthique pour PME).

Combien coûte une bonne sécurité IoT ?

Marginal en matériel : quelques heures de config + certificats Let’s Encrypt gratuits. Le coût réel est en temps (audit régulier, mises à jour, monitoring). Compter 0.5-1 jour-homme par mois pour une infra 50 capteurs.

Que faire en cas de compromission d’un firmware fabricant ?

Si le vendeur a un patch : OTA dès dispo. Si vendeur ne supporte plus : changer matériel (un IoT non maintenu est un passif sécurité). En attendant : isoler VLAN, monitoring renforcé, désactiver fonctionnalités non utilisées.

Comment former mes équipes à la sécurité IoT ?

Sensibilisation initiale (1h) sur risques basiques, ateliers techniques pour devs/ops (1 jour), revue trimestrielle des incidents. Ressources : OWASP IoT Top 10, ANSSI guides IoT, formations payantes SANS SEC511.

Y a-t-il une norme IoT à suivre ?

ETSI EN 303 645 : référentiel européen consumer IoT (mots de passe par défaut interdits, mises à jour, etc.). NIST 8259 : guidelines fabricants IoT. OWASP IoT Top 10 : checklist développeur. À venir : Cyber Resilience Act EU avec exigences contraignantes.

Articles liés (cluster IoT)

Voir aussi : Pentesting éthique pour PME, Cybersécurité PME Sénégal : guide complet.

Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.