Contexte et objectifs

En 2026, des acteurs malveillants ont exploité des superviseurs de réfrigération exposés sur Internet en Europe, en s’appuyant sur des mots de passe par défaut et des firmwares non corrigés. Ils ont déclenché des cycles de dégivrage, perturbant la chaîne du froid. Coldframe répond à ce problème en proposant un honeypot qui se fait passer pour ces contrôleurs, notamment les modèles Danfoss AK‑SM 800A et Dixell XWEB EVO. L’objectif est d’enregistrer chaque connexion, chaque tentative d’authentification et chaque exploitation publique, sans jamais fournir de fonctionnalité réelle.

Architecture et empreinte technique

Le projet se résume à un unique fichier Python, sans dépendance externe au-delà de la bibliothèque standard. Deux « personas » reproduisent les empreintes observées sur le terrain : le persona Danfoss copie l’en‑tête nginx, l’ordre des en‑têtes HTTP, le titre de page « StoreView », TLS 1.2 uniquement et un certificat auto‑signé d’un an avec le CN DanfossSM800A. Le persona Dixell reproduit l’absence d’en‑tête Server, les en‑têtes de sécurité spécifiques et le flux de connexion /cgi-bin/login.lua. Chaque construction génère de nouvelles clés privées, garantissant l’unicité des certificats.

En option, un service Modbus TCP peut être activé, renvoyant des températures factices, des consignes et un registre de dégivrage. Le service reste désactivé par défaut, car les unités réelles n’utilisent Modbus que pour communiquer avec leurs propres contrôleurs de caisses.

Mécanismes de collecte et de sécurisation

Chaque requête correspond à une ligne JSON écrite sur stdout et dans events.jsonl. Un exemple d’événement d’essai de connexion :

{"ts": "2026-11-05T10:57:21.158+00:00", "persona": "danfoss", "proto": "http", "src_ip": "203.0.113.7", "src_port": 6782, "event": "login_attempt", "username": "admin", "password": "admin"}

Les tentatives exploitant les CVE connues (par ex. CVE‑2023‑25914, CVE‑2025‑41450, CVE‑2026‑25085) sont marquées d’un champ exploit. Le honeypot ne lance aucune commande, ne lit aucun fichier et ne transmet aucun trafic sortant ; les charges d’exploit sont simplement consignées puis rejetées.

Des garde‑fous limitent le volume par source, coupent les sockets inactifs après 30 s, tronquent les lignes excessives et neutralisent les séquences d’échappement terminal. Le journal tourne automatiquement lorsqu’il atteint une taille critique.

Déploiement, durcissement et limites

Coldframe s’exécute dans un conteneur Podman ou Docker. L’exemple suivant montre le lancement avec des options de sécurité :

podman run -d --name coldframe --restart=always \
  --read-only --cap-drop=ALL --security-opt no-new-privileges \
  --userns=auto --memory 128m --pids-limit 512 \
  -p 80:8080 -p 443:8443 \
  -v coldframe-logs:/logs:U \
  -e PERSONA=danfoss coldframe

Le conteneur fonctionne sous un UID non privilégié, dans son propre espace de noms utilisateur, avec un système de fichiers en lecture seule. Les ports exposés correspondent exactement à ceux attendus par le persona choisi, et le trafic sortant est limité à DNS et mises à jour du système.

Les limites du projet sont explicites : certaines routes statiques et la forme exacte des réponses XML ne sont pas publiques, donc Coldframe utilise des valeurs plausibles. De plus, les scanners cloud peuvent classer ces déploiements comme suspects, car les appareils industriels hébergés sur des serveurs publics sont rares.