PandoraBox est une borne libre de décontamination de clés USB, une « station blanche » : on insère une clé, la borne analyse chaque fichier avec plusieurs moteurs de détection, affiche les fichiers dangereux sur son écran tactile, puis les supprime quand l'utilisateur touche l'écran. La nouvelle version est une réécriture complète. Elle ne dépend plus du projet Pandora du CIRCL et elle est distribuée sous forme d'image système durcie, construite à partir de Debian 13. Le code est sous licence GPL-3.0 et le boîtier imprimable en 3D sous licence CERN-OHL-S v2.
Pourquoi une borne de décontamination
Les clés USB restent une porte d'entrée courante dans des systèmes d'information par ailleurs bien protégés. Les personnes changent d'organisation, utilisent des ordinateurs qui ne sont pas surveillés et vont sur des réseaux isolés. La borne de décontamination vérifie les objets avant qu’ils arrivent au poste de travail.
PandoraBox propose une solution ouverte, que tout le monde peut vérifier, pour remplacer les bornes du commerce. PandoraBox s’adresse aux lieux qui demandent plus de sécurité, comme les hôpitaux, les usines ou les bureaux de l’État. Elle tourne sur un petit ordinateur reconditionné avec un écran tactile, et fonctionne sans réseau.
Plus de détail sur cette nouvelle version dans la seconde partie de la dépêche.
Sommaire
Une version entièrement réécrite.
La première version de PandoraBox s'appuyait sur Pandora du CIRCL pour analyser les fichiers. La nouvelle version repart d'une base propre et ne garde que ce qui fonctionnait : la machine à états, la détection USB avec pyudev, la quarantaine et l'interface curses du mode administrateur.
Les principaux changements :
- les appels à
pypandorasont remplacés par une chaîne de moteurs de détection intégrée ; - le moteur Comodo, qui n'est plus maintenu sous Linux, disparaît ;
- le diaporama d'images (
fim) laisse la place à une vraie interface graphique tactile ; - les clés sont montées en lecture seule par la borne elle-même, avec des options de montage durcies ;
- les journaux passent au JSON structuré ;
- la borne n'est plus un logiciel à installer sur un système existant, mais une image système complète.
Plusieurs moteurs de détection
Chaque fichier passe par plusieurs moteurs complémentaires :
- MalwareBazaar propose des empreintes SHA-256 de logiciels malveillants connus.
- Le service CIRCL Hashlookup aide à repérer les fichiers connus grâce à un filtre de Bloom.
- ClamAV : antivirus, y compris dans les archives
- YARA-X : YARA Forge
- Heuristiques : programmes déguisés en documents (double extension, type réel différent de l'extension), PDF avec JavaScript ou actions de lancement
La borne a un mode « fail closed » : si la borne ne peut pas analyser tout le fichier, comme pour une archive protégée par mot de passe, un fichier trop gros ou une erreur dans un moteur, la borne ne dit jamais que le fichier est sûr. Chaque partition de la clé est analysée, et une partition illisible (chiffrée, système de fichiers inconnu) rend la clé « non vérifiée ».
Rien n'est supprimé sans l'utilisateur : les fichiers dangereux sont listés à l'écran, copiés dans la quarantaine de la borne, puis retirés de la clé seulement après un appui sur l'écran. Chaque analyse donne un rapport JSON.
Une image système durcie
La clé USB pose un risque car la clé USB est vue comme un objet dangereux. Les moteurs d'analyse risquent d'être piratés. L'image est construite avec mkosi à partir des paquets Debian 13, et ne contient que ce qui sert à analyser :
- chaîne de démarrage vérifiée : Secure Boot avec la clé de l'image enrôlée à la place de celles de Microsoft, image noyau unifiée (UKI) signée, système de fichiers racine EROFS en lecture seule protégé par dm-verity, noyau en mode lockdown ;
- périphériques USB filtrés : USBGuard n'autorise que le stockage de masse, ce qui bloque les clés qui se font passer pour un clavier (BadUSB), et les pilotes réseau USB, Wi-Fi et Bluetooth sont retirés de l'image ;
-
aucune session : pas de compte, pas de programme
login, pas de menu de démarrage ; - un bac à sable par moteur : chaque moteur tourne dans son propre processus, avec bubblewrap, un utilisateur dédié sans privilèges, un filtre seccomp et aucun accès réseau. Un moteur compromis par un fichier piégé ne peut pas falsifier le résultat d'un autre ;
- pare-feu et réglages du noyau inspirés des recommandations de l'ANSSI pour les systèmes GNU/Linux. Lynis donne un indice de durcissement de 73, sans avertissement.
L'interface graphique est dessinée avec Pillow directement dans le framebuffer, sans serveur d'affichage ni navigateur.
Mises à jour signées et maintenance sans session
La borne fonctionne hors ligne par défaut. Tout ce qui la modifie arrive signé :
- Les signatures : le logiciel vérifie un jeu de signatures signé Ed25519 à chaque démarrage. Il s'installe depuis une clé USB de mise à jour, qui n'est jamais analysée, ou en ligne avec le profil
onlinede l'image. Sans jeu valide, la borne n'analyse rien. Un jeu plus ancien est refusé ; - Le système accepte les mises à jour A/B avec
systemd-sysupdate, par clé USB ou en ligne. La nouvelle version est écrite dans l'emplacement libre, et après 3 démarrages ratés, systemd-boot revient à la version précédente ; - journaux : une clé de maintenance signée récupère les journaux de la borne (journal systemd, noyau, USBGuard, matériel) sans ouvrir de session et sans rien modifier.
Une borne en ligne peut aussi envoyer ses journaux à un SIEM (Wazuh, Elastic, Graylog, Splunk) en syslog RFC 5424 ou en JSON, sur TLS. En ligne, seuls le service de mise à jour, l'export SIEM et NTP peuvent sortir à travers le pare-feu. La borne elle-même n'a toujours pas accès au réseau.
Matériel et interface
La borne de référence est un Lenovo ThinkCentre M720q Tiny reconditionné (Core i5-9400T, 6 cœurs), avec un écran tactile Waveshare de 7 pouces (1024x600). L'image fonctionne sur tout ordinateur x86_64 UEFI, avec 2 Go de mémoire au minimum. Le boîtier de bureau s'imprime en 3D en une seule pièce.
L'interface est pensée pour le tactile, sans bouton : attente d'une clé, progression de l'analyse, liste des fichiers dangereux, appui n'importe où sur l'écran pour nettoyer, puis résultat. Chaque organisation peut y mettre son logo, ses couleurs, ses textes et sa langue (français et anglais fournis).
L'image est testée de bout en bout dans une machine virtuelle QEMU/KVM. Le test démarre l'image avec Secure Boot, insère des clés USB émulées (vfat, exFAT, NTFS, ext4), vérifie le verdict de chaque moteur, le nettoyage, les mises à jour et le retour à la version précédente.
État du projet
Le projet est en développement actif. L'analyse marche bien. L'image durcie fonctionne comme attendu. L'interface tactile répond comme il faut. Les mises à jour passent sans souci. L'export SIEM est validé. Le matériel de référence a permis de tout vérifier.
Une limite importante reste à lever : l'image et les jeux de signatures ne sont signés pour l'instant qu'avec des clés de développement, générées sur la machine qui construit l'image. Les clés de publication du projet et leur stockage ne sont pas encore définis.
Les prochaines étapes de la feuille de route :
- analyse des macros Office avec
oletoolset des exécutables aveccapa; - désarmement et reconstruction de contenu (CDR) avec Dangerzone ;
- serveur central facultatif : inventaire des bornes, rapports, état des signatures ;
- modèle de menace documenté, fuzzing des points d'entrée et audit de sécurité externe ;
- correspondance avec les exigences NIS2 et ISO 27001 (mesure 7.10 « Supports de stockage »).
Essayer et contribuer
Il suffit de Docker pour construire l'image et la tester dans une machine virtuelle :
git clone https://github.com/sourcentis/pandora-box.git
cd pandora-box
image/build.sh # construit l'image
image/build-test.sh && image/vm.sh test # la teste dans une machine virtuelleLes contributions sont les bienvenues : retours d'expérience sur d'autres matériels, règles de détection, traductions de l'interface, revue de sécurité. Les vulnérabilités se signalent selon la politique de sécurité.
Aller plus loin
- Le projet sur GitHub (489 clics)
- Documentation (80 clics)
- Feuille de route (32 clics)
- Guide d'installation (85 clics)
# Flexibilité dans les moteurs utilisés
Posté par Astaoth . Évalué à 4 (+2/-0).
Projet intéressant, qui répond à un problème toujours présent dans les structures, tout comme Mercator et Deming.
Pour ajouter plus de variété dans les scans, est-il possible d'ajouter des moteurs antiviraux complémentaires, ou est-ce que la solution est peu flexible pour ca ? Par exemple je suis dans une structure qui doit avoir plus de 5 EPP/EDR différents (différents environnements, scopes, et usages), peut-on les y intégrer facilement ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Flexibilité dans les moteurs utilisés
Posté par didierb . Évalué à 8 (+7/-0).
Oui, c'est prévu dès la conception. La Pandora-Box repose sur une architecture de moteurs en plugins : chaque moteur implémente une interface commune (un fichier en entrée, un verdict en sortie : sain, suspect, malveillant, erreur, ignoré). ClamAV, YARA-X, MalwareBazaar ou Hashlookup sont des plugins comme les autres. Ajouter un moteur supplémentaire revient donc à écrire un petit connecteur, sans toucher au cœur du projet. Les moteurs tournent en parallèle, et une politique d'agrégation configurable décide du verdict final (par exemple, un seul moteur positif suffit à bloquer).
Pour les antivirus commerciaux, c'est faisable dès que l'éditeur fournit sous Linux un scanner à la demande, en ligne de commande ou via un démon/SDK. Plusieurs éditeurs le proposent. Il faudra en revanche vérifier que la licence autorise l'usage sur une borne. Un plugin générique « commande externe », configurable sans écrire de code, serait une bonne piste pour faciliter ce type d'intégration.
Pour les EDR, c'est plus délicat. Leur valeur tient surtout à l'analyse comportementale et à la télémétrie remontée vers leur console, alors qu'une borne fait de l'analyse statique de fichiers, hors ligne. Beaucoup d'EDR n'exposent d'ailleurs pas de scan à la demande exploitable. Installer plusieurs agents propriétaires irait aussi à l'encontre des principes du projet : image minimale, durcie, sans réseau, avec chaque analyseur isolé dans une sandbox. La bonne approche serait d'intégrer le moteur de scan de l'éditeur plutôt que l'agent EDR complet.
Si tu as des produits précis en tête, n'hésite pas à ouvrir une issue sur GitHub : ça m'aidera à prioriser les connecteurs. Les contributions sont évidemment les bienvenues !
# Voir aussi USBSAS
Posté par cg . Évalué à 8 (+6/-0).
Super projet !
J'en profite pour mentionner un autre projet qui ressemble, sans être identique : le "sas USB" développé par l'équipe sécu du CEA.
On trouve le code source sous GPL 3 sur GitHub : https://github.com/cea-sec/usbsas .
# USB NoFuture
Posté par Philippe F (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 16 octobre 2026 à 13:12.
Dans ma (grosse et internationale) boite, l'USB mass storage est maintenant désactivé sur tous les ordinateurs. Si tu veux un fichier, passe par teams, le mail ou le système interne d'échange de gros fichiers.
C'est légèrement chiant, parfois des développeurs doivent demander des exceptions. Mais je pense que c'est la bonne approche.
Il y a 5 ans, ils nous avaient mis une borne à l'accueil pour nettoyer nos clés USB, tout comme PandoraBox. Au bout de deux mois, le truc ne marchait plus du tout. Victime d'un malware peut-être ? Plus probablement d'une mise à jour ou non-mise à jour ratée.
[^] # Re: USB NoFuture
Posté par didierb . Évalué à 9 (+8/-0).
Désactiver l'USB mass storage sur les postes, c'est effectivement la bonne approche, et c'est ce que je recommande aussi quand c'est possible. Mais même dans une organisation qui l'applique, il reste des cas où la clé USB est incontournable :
La borne ne remplace pas la politique de blocage, elle traite les exceptions qu'on ne peut pas éviter.
Quant à ta borne qui ne marchait plus au bout de deux mois, c'est exactement le problème que je veux résoudre avec la nouvelle version : image système en lecture seule avec
dm-verity, mises à jour atomiques A/B (si la mise à jour échoue, on revient à la version précédente), et mises à jour de signatures signées, y compris hors ligne pour les bornes isolées. Une borne qu'on installe et qu'on oublie, c'est une borne qui finit par ne plus servir. L'objectif est qu'elle reste fonctionnelle sans qu'un admin doive passer la voir tous les mois.[^] # Re: USB NoFuture
Posté par Franck Routier (Mastodon) . Évalué à 6 (+7/-2).
C'est sûr, c'est drôlement plus "secure" de filer toutes ses données à Microsoft / WeTransfer / Google / … !
[^] # Re: USB NoFuture
Posté par Philippe F (site web personnel) . Évalué à 2 (+0/-0).
On les files que à Microsoft. Pour les gros fichiers, le système de transfert est interne, c'est déjà pas si mal. Et tous les fichiers offices sont chiffrés par une clé dédiée à ma boite, qui nous protège des fuites de données. Sauf évidemment chez Microsoft qui gère ladite clé…
[^] # Re: USB NoFuture
Posté par octane . Évalué à 4 (+2/-0).
donc le fichier "gros_virus.exe" ne passe plus par clé USB, mais par email? C'est intéressant comme concept.
Vraie question: que le fichier arrive par une clé USB ou un email (ou dl depuis un dropbox quelconque), il n'y a pas un antivirus/EDR qui s'intercale? Et pourquoi l'AV de l'un est meilleur/ moins bon que l'autre?
[^] # Re: USB NoFuture
Posté par Philippe F (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 16 octobre 2026 à 17:52.
Ca fait une grosse différence que ça passe par mail ou par le chat, car il y a plusieurs anti-virii actifs qui moulinent les fichier avant d'autoriser leur délivrance. Contrairement à la clé USB où l'antivirus risque d'arriver trop tard, après que l'utilisateur a double-clické sur le fichier "NE ME CLIQUEZ PAS SVP.docx" .
Sans parler des clés qui prennent le contrôle presque sans intervention de l'utilisateur.
[^] # Re: USB NoFuture
Posté par octane . Évalué à 3 (+1/-0).
oui, enfin l'AV analyse le fichier lors du double clic, puis pendant l'exec. Un peu comme un AV de messagerie qui analyse le fichier. Sous windows il y a des minifilters qui peuvent intervenir lors de l'ouverture du fichier.
des infos là dessus? Ca m'intéresse.
[^] # Re: USB NoFuture
Posté par didierb . Évalué à 2 (+1/-0).
Recherche USB Rubber Ducky
[^] # Re: USB NoFuture
Posté par octane . Évalué à 3 (+1/-0).
c'est un clavier, donc. Présenté sous la forme d'une clé usb, mais un clavier.
[^] # Re: USB NoFuture
Posté par flavien75 . Évalué à 2 (+1/-0).
Avec les périphériques "composites", rien n'empêche de créer un périphérique qui intègre à la fois le clavier et le stockage.
Dans ce cas, ce n'est pas juste un clavier.
Les vrais naviguent en -42
# Usage de l'IA ?
Posté par sigmate . Évalué à 4 (+5/-1).
Bonjour,
Merci beaucoup pour ce projet que je vais tester avec intérêt très prochainement car il me semble idéal pour un scénario d'usage sur lequel je planche.
En parcourant le dépôt, je crois deviner l'utilisation de l'IA (au moins partiellement) dans le cycle de développement de votre projet. Si tel est bien le cas, que pensez-vous d'ajouter une mention dans la documentation pour apporter un peu de transparence sur cet aspect ? Permettez-moi de préciser : je parle bien ici de développement assisté par l'IA et certainement pas de vibe coding. Et je ne souhaite certainement pas non plus ouvrir un débat polémique sur l'usage de l'IA. Je pensais simplement à quelques lignes pour expliquer à quels endroits se situe l'assistance produite par l'IA, quel(s) modèle(s) sont à l'œuvre, comment cela est-il accepté dans les contributions ou non, etc.
Un grand merci renouvelé pour cette initiative.
[^] # Re: Usage de l'IA ?
Posté par didierb . Évalué à 5 (+4/-0).
Merci pour ton message et pour l’intérêt que tu portes au projet. N’hésitez pas à faire un retour une fois vos tests réalisés, je serai curieux de connaître tes scénarios d’usage.
Pour répondre à votre question : oui, l’IA fait partie des outils utilisés dans le cycle de développement. Il serait d’ailleurs difficile de prétendre le contraire. Aujourd’hui, plus aucun projet hébergé sur GitHub n’y échappe vraiment, que ce soit par l’éditeur, les outils d’analyse ou les services de la plateforme elle-même.
Dans le cas de ce projet, l’IA est utilisée principalement pour la vérification et la validation du code : relecture, détection d’erreurs, de failles potentielles ou d’incohérences. Les choix d’architecture, les décisions de conception et la responsabilité du code publié restent les miens. Chaque modification est relue et comprise avant d’être intégrée, et il en va de même pour les contributions externes : ce qui compte, c’est que le contributeur maîtrise et assume ce qu’il propose, quel que soit l’outil qui l’a aidé à l’écrire.
En revanche, je ne citerai pas les modèles ou agents utilisés : je ne souhaite faire la publicité d’aucun outil d’IA dans ce projet, d’autant que ces outils évoluent très vite et qu’une telle liste serait rapidement obsolète.
# Filesystem monté par Linux ?
Posté par zerodeux (site web personnel) . Évalué à 2 (+1/-0).
Je ne vois pas de mention d'utilisation de Fuse ou UserModeLinux, est-ce utilisé ? Car si le filesystem des clés USB est monté directement via le kernel, je ne donne pas cher à la survie de l'appliance… Je rappelle que le modèle de menace "une image de filesystem est mal formée/corrompue" et explicitement exclu par les dévs de Linux.
Par ailleurs une décontamination qui ne reformate pas le filesystem de la clé me semble louper à la fois un vecteur d'attaque majeur et une mesure de contournement simple et efficace.
[^] # Re: Filesystem monté par Linux ?
Posté par didierb . Évalué à 2 (+1/-0). Dernière modification le 19 octobre 2026 à 18:14.
Bien vu sur les deux points. Les clés sont aujourd’hui montées par le noyau (lecture seule, noexec, seuls vfat/exfat/ntfs3/ext4 acceptés, racine dm-verity), ce qui limite les dégâts sans régler le problème : j’ajoute à la roadmap le montage via FUSE ou lklfuse dans le bac à sable des moteurs, voire dans une micro-VM jetable. Quant au reformatage, je l’ajoute en option : on recrée le système de fichiers et on n’y réécrit que les fichiers sains, pour que le poste suivant ne monte plus une structure fournie par l’attaquant.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.