# MarlinSpike, Documentation complète (français) > Le successeur maintenu, multi-utilisateur et web du GrassMarlin de la NSA. L'outil original est en fin de vie depuis 2017 ; CISA a divulgué CVE-2026-6807 (XXE en v3.2.1) le 28 avril 2026 sans correctif à venir. MarlinSpike reprend le rôle : atelier open source de topologie OT/ICS passif, captures en entrée, zéro paquet en sortie, atelier web multi-utilisateur pour les engagements OT partagés, avec inférence du niveau Purdue, empreintes fournisseurs, sévérité contextuelle pilotée par le contexte d'actifs, chasse aux IOC sur l'ensemble des rapports, matrice MITRE ATT&CK en direct, interface bilingue EN/FR, et artefacts de rapport JSON portables comme contrat moteur ↔ atelier. Source : https://grassmarlin.com/fr/llms-full.txt Index : https://grassmarlin.com/fr/llms.txt Site : https://grassmarlin.com/fr/ English: https://grassmarlin.com/llms-full.txt Ce fichier est la concaténation de chaque page de documentation publique. Les versions markdown par page sont aussi disponibles à `https://grassmarlin.com/fr/wiki/.md` et `https://grassmarlin.com/fr/.md`. --- # Site ## À propos de MarlinSpike *Source : https://grassmarlin.com/fr/about* _Cartographe de topologie OT/ICS passif et atelier d'analyste. Le GrassMarlin moderne, conçu pour les engagements partagés. Le noyau open-source derrière Fathom._ MarlinSpike est un cartographe de topologie OT/ICS passif et un atelier d'analyste. Le produit ingère des captures de paquets, ne renvoie aucun trafic dans l'environnement, et transforme les observations passives en topologie, inventaire d'actifs, constats de niveau intervenant et artefacts de rapport JSON portables. C'est le noyau open-source derrière Fathom, intentionnellement conçu comme un atelier web partagé plutôt que comme un client lourd mono-utilisateur. ## Filiation MarlinSpike reprend là où GrassMarlin s'est arrêté. Même premier principe, visibilité OT/ICS passive depuis les seules captures de paquets, mais reconstruit pour la façon dont les intervenants travaillent aujourd'hui : un atelier web partagé au lieu d'un client lourd mono-utilisateur, un contrat de rapport JSON portable au lieu d'une vue liée à la session, et un modèle d'extensibilité multi-couche qui accepte des moteurs Rust, des plugins Python et des packs de règles YAML. Ce n'est pas un fork ; c'est un successeur. Le produit est du code indépendant, une architecture conçue de zéro, et un alignement délibéré sur ce que GrassMarlin avait promis à l'origine à la communauté OT : analyse passive, couverture protocolaire neutre vis-à-vis des fournisseurs, et outillage qui respecte la réalité opérationnelle du terrain. Caractéristiques clés : Passif uniquement · Atelier multi-utilisateurs · Rapport JSON portable · Couverture protocolaire OT native · Open source ## Frontière produit MarlinSpike garde le moteur autonome et traite l'artefact de rapport généré comme la frontière de passage entre l'analyse de paquets et la revue en aval. ``` Projet → Scan → Rapport → Atelier → Triage ``` La voie d'installation privilégiée est un déploiement Docker Compose avec proxy inverse que plusieurs intervenants peuvent partager pendant une évaluation, une investigation d'incident ou un exercice sur table. ## Chaîne d'analyse en 5 stages Le pipeline d'analyse reste intentionnellement lisible : ingestion et validation, dissection protocolaire, construction de topologie, surface de risque et génération de rapport. - **Stage 1, Ingestion** : Validation du fichier de capture et extraction des métadonnées. - **Stage 2, Dissection** : Parsing des protocoles OT, découverte L2 et extraction des conversations. - **Stage 3, Topologie** : Graphe de noeuds et d'arêtes, placement Purdue, empreinte fournisseur, assignation des rôles. - **Stage 4, Risque** : Problèmes inter-zones, communications externes suspectes, balises C2, entropie DNS, mapping MITRE ATT&CK. - **Stage 5, Rapport** : Artefact JSON portable consommé par l'atelier et l'outillage en aval. ## Couverture protocolaire MarlinSpike est construit autour de la visibilité des protocoles industriels, puis l'enrichit du contexte de découverte réseau pour que les relations d'infrastructure ne soient pas perdues. **OT / ICS** : Modbus, EtherNet/IP, CIP, S7comm, DNP3, IEC 60870-5-104, OPC-UA, BACnet, PROFINET, HART-IP, FINS, GOOSE, MMS, OMRON **Couche 2 / découverte** : LLDP, CDP, STP, LACP, ARP, VLAN ## Support des standards Le discours public reste borné à ce que la plateforme expose réellement aujourd'hui. MarlinSpike supporte la revue orientée standards sans prétendre être une suite de conformité plus large. **IEC 62443**, Les recommandations de remédiation du Stage 4 sont formulées autour du support de remédiation orienté SR de l'IEC 62443 pour les classes de constats supportées. **MITRE ATT&CK**, Implémentation ATT&CK complète dans le flux de rapport, incluant les vues matricielles groupées par tactique, les sous-techniques, les mesures d'atténuation et les recommandations de réponse, pour les domaines ICS et Enterprise. **Purdue / ISA-95**, Le zonage ISA-95 et Purdue reste central pour la disposition de la topologie, le placement des actifs et la revue des communications inter-niveaux. ## Vue d'ensemble de l'architecture MarlinSpike est intentionnellement extensible pour les intervenants OT/ICS en activité, pas seulement pour les programmeurs systèmes. Trois surfaces d'extension formelles couvrent l'étendue de la personnalisation. **Moteurs Rust**, Composants face aux paquets et fortement orientés événements comme la DPI. Le substrat autonome `marlinspike-dpi` livre 34 dissecteurs de protocoles et est intégré à l'image Docker à une référence épinglée. **Plugins Python**, Analyse face au rapport, enrichissement et logique de triage. Le plugin MITRE ATT&CK, le plugin d'analyse ARP et le plugin APT vivent derrière cette surface et sont chargés par nom de module depuis l'environnement. **Packs de règles YAML**, Mappings déclaratifs, suppressions et politique locale. Les packs par défaut sont livrés sous `rules//base.yaml` ; surcharges par déploiement via variables d'environnement. Continuez avec le [wiki](/fr/wiki/) pour le déploiement, l'architecture et le contrat de rapport, ou allez aux [téléchargements](/fr/downloads/) pour le dépôt officiel et la voie de paquet. --- ## Téléchargements MarlinSpike *Source : https://grassmarlin.com/fr/downloads* _Dépôt officiel, archives source, voie de déploiement Docker et état actuel des binaires, en un seul endroit._ Cette page ne liste que les surfaces de distribution officielles de MarlinSpike avec de vrais liens. Vous devriez pouvoir trouver le dépôt, les instantanés source, la voie de déploiement et l'état actuel des binaires sans avoir à deviner quels canaux sont publics. ## MarlinSpike hébergé · cloudmarlin.com La voie la plus rapide pour utiliser MarlinSpike sans monter votre propre déploiement est la version hébergée sur [cloudmarlin.com](https://cloudmarlin.com). Même moteur, même atelier, sans pile Docker à installer. Inscrivez-vous, téléversez un pcap, travaillez le projet avec votre équipe. Le reste de cette page est pour l'auto-hébergement. ## Dépôt officiel Ce sont les principaux endroits publics pour parcourir le code, les notes d'installation et l'historique des versions. **Dépôt source** [disponible], Le dépôt GitHub public est la surface de code source canonique pour MarlinSpike, incluant la licence, les issues et l'historique du code. [https://github.com/eris-ot/marlinspike](https://github.com/eris-ot/marlinspike) **Docs et wiki** [disponible], Docs produit, guide de déploiement, notes d'architecture et références de versions. [/fr/wiki/](/fr/wiki/) **Guide d'installation** [disponible], Notes d'installation côté dépôt pour les opérateurs qui veulent les détails de configuration et d'environnement vérifiés. [INSTALL.md](https://github.com/eris-ot/marlinspike/blob/main/INSTALL.md) **Historique des versions** [disponible], Les notes de version du moteur et de l'interface web sont suivies dans le dépôt jusqu'à la publication de versions binaires taguées. [releases.md](https://github.com/eris-ot/marlinspike/blob/main/releases.md) ## Téléchargements source Si vous voulez MarlinSpike maintenant sans attendre des installeurs empaquetés, voici les surfaces de téléchargement officielles au niveau source et les dépôts de composants qui résolvent aujourd'hui. **Archive zip de la branche principale** [disponible], Téléchargez la branche principale actuelle en instantané zip quand vous voulez l'arborescence source directement. [Télécharger zip](https://github.com/eris-ot/marlinspike/archive/refs/heads/main.zip) **Tarball de la branche principale** [disponible], Récupérez la branche principale actuelle en archive source tar.gz pour les environnements Unix et les récupérations scriptées. [Télécharger tar.gz](https://github.com/eris-ot/marlinspike/archive/refs/heads/main.tar.gz) **Source du moteur DPI autonome** [disponible], Le moteur DPI Rust face aux paquets est publié séparément sous marlinspike-dpi pour les équipes qui veulent cette surface de parseur seule. [https://github.com/eris-ot/marlinspike-dpi](https://github.com/eris-ot/marlinspike-dpi) ## Paquets officiels MarlinSpike ne prétend pas encore livrer des artefacts natifs de gestionnaire de paquets. La surface de paquet officielle aujourd'hui est la voie de déploiement Docker vérifiée et les fichiers qui la soutiennent. **Déploiement Docker Compose** [disponible, voie officielle], La voie de paquet et d'installation actuellement supportée est la source plus Docker Compose pour les déploiements serveur et laboratoire. Voir les [docs de déploiement](/fr/wiki/deployment/). **docker-compose.yml** [disponible], Consultez le manifeste Compose vérifié utilisé comme déploiement de base pour l'application web et PostgreSQL. [Voir le fichier compose](https://github.com/eris-ot/marlinspike/blob/main/docker-compose.yml) **Recette de build Docker** [disponible], Inspectez le build Docker multi-stage qui compile les modules Python protégés et assemble l'image d'exécution. [Voir le Dockerfile](https://github.com/eris-ot/marlinspike/blob/main/Dockerfile) **Registres de paquets** [non publié], Aucun artefact de registre de paquet officiel Homebrew, apt, yum, winget, Chocolatey, MSI ou similaire n'est publié pour l'instant. ## Binaires officiels La surface de version est réelle et publique, mais les artefacts binaires n'y sont pas encore publiés. **Page des versions GitHub** [disponible], La surface de version officielle existe déjà sur GitHub, mais elle ne contient pas encore d'artefacts binaires tagués. [https://github.com/eris-ot/marlinspike/releases](https://github.com/eris-ot/marlinspike/releases) **Binaires autonomes** [non publié], Aucun binaire autonome public Linux, macOS ou Windows n'est publié aujourd'hui. La voie d'installation publique reste la source plus Docker. **Installeurs et paquets OS** [non publié], Aucun installeur desktop signé ni paquet natif OS n'est encore publié pour une installation directe sur l'hôte. **Sommes de contrôle et signatures** [non publié], Les fichiers de somme de contrôle et de signature ne sont pas encore publiés car il n'y a pas encore d'artefacts de version binaire publics à vérifier. ## Voie d'installation officielle Docker Compose est la voie de paquet publiée aujourd'hui. MarlinSpike est un atelier web partagé, donc le scénario d'installation supporté reste un clone Git plus Docker Compose sur un hôte de terrain, une VM temporaire, un serveur de laboratoire ou un système de staging interne derrière un proxy inverse. ``` git clone https://github.com/eris-ot/marlinspike.git cd marlinspike cp .env.example .env docker compose up -d --build ``` ## État public actuel Ce que vous pouvez et ne pouvez pas obtenir maintenant : - Dépôt officiel en ligne - Archives zip + tarball en ligne - Voie Docker officielle - Page des versions réelle - Pas encore d'actifs binaires - Pas encore d'artefacts de gestionnaire de paquets natifs Le wiki couvre le déploiement, l'architecture, le contrat d'artefact de rapport et la structure plus large du projet. Voir [/fr/wiki/](/fr/wiki/). --- ## GlassMarlin, Le successeur de GrassMarlin *Source : https://grassmarlin.com/fr/glassmarlin* _Un fichier. PCAP en entrée. Atelier de triage OT/ICS complet en sortie. Pas de Wireshark, pas de Python, pas de Docker, pas d'internet. Outillage défenseur-sur-portable pour les engagements où l'hôte n'a rien._ GlassMarlin est le successeur bureau de GrassMarlin. **Un fichier. PCAP en entrée. Atelier de triage OT/ICS complet en sortie. Pas de Wireshark requis. Pas d'installation Python. Pas de Docker. Pas d'internet. Pas de serveur d'équipe.** Outillage défenseur-sur-portable pour les engagements OT où l'hôte n'a rien. Dépôt source : [github.com/eris-ot/glassmarlin](https://github.com/eris-ot/glassmarlin). ## Filiation GrassMarlin était le cartographe de topologie OT publié par la NSA, que les défenseurs de terrain portaient en silence sur les portables d'engagement depuis des années. Il fonctionnait, jusqu'à ce qu'il ne fonctionne plus. Abandonné en 2017, lié à Java, mono-plateforme, plus maintenu. [CVE-2026-6807](https://nvd.nist.gov/vuln/detail/CVE-2026-6807) (avril 2026) l'a rendu activement dangereux à continuer d'utiliser. GlassMarlin reprend là où il s'est arrêté. Même utilité pour le défenseur, modernisée, multiplateforme, avec la pile complète risque + MITRE ATT&CK + IOC + baselines + extraction sub-PCAP en plus de la cartographie de topologie. Même esprit « déposez-le sur un portable ». Zéro dépendance externe. Filiation complète sur la [page de lignée GrassMarlin](/fr/wiki/heritage.md). ## Aucune dépendance externe. Point. Chaque dépendance vit à l'intérieur du binaire : - **Bundle natif par OS.** GlassMarlin.msi pour Windows. GlassMarlin.dmg pour macOS (signé, Gatekeeper-clean). GlassMarlin.AppImage pour Linux (tout hôte glibc 2.28+). - **Dissection PCAP pure-Rust.** Pas de libpcap, pas de Npcap, pas d'installation Wireshark, pas de `tshark`, pas d'`editcap`. `marlinspike-dpi` gère l'analyse et l'extraction de fenêtres temporelles nativement en Rust. - **Runtime Python intégré.** Embarqué via `python-build-standalone`. Pas de `pip install`, pas de venv, pas de Python système. - **SQLite embarqué, pas de serveur DB.** Tout ce que grassmarlin.com stocke dans Postgres, GlassMarlin le garde dans un fichier SQLite embarqué dans le répertoire de données utilisateur. - **Aucun internet requis, jamais.** Pas de télémétrie, pas de vérification de licence, pas de mise à jour MITRE au runtime. Le runtime ATT&CK et les packs de plugins sont cuits dans le binaire. Tourne en SCIF, en bunker, en avion. - **Exports prêts pour SIEM.** Chaque scan émet report.json + OCSF NDJSON + STIX 2.1 + règles Sigma + couche ATT&CK Navigator JSON, en plus de la vue d'atelier. ## Ce qu'il fait GlassMarlin est la pile de triage MarlinSpike entière sur un binaire, pas seulement de la topologie : - **Topologie + empreinte d'actifs.** Inférence du niveau Purdue, empreintes fournisseurs, détection de rôle d'actif. 30+ dissecteurs de protocoles OT : Modbus, S7, DNP3, IEC 60870-5-104, EtherNet/IP, OPC UA, BACnet, PROFINET, OMRON FINS, HART-IP, EtherCAT, Sparkplug B, IEC 61850 (MMS / GOOSE / SV), et plus. - **Constats de risque, mappés IEC 62443.** Communications inter-Purdue, ingénierie en clair, balises C2, communications externes suspectes, scans de ports, authentification manquante, OPC `SecurityMode=None`, écritures Modbus de sources inattendues, chacun avec mapping IEC 62443 SR et guidance de remédiation. - **Alignement MITRE ATT&CK.** Chaque constat mappé à des techniques (ICS + Enterprise). Vue d'atelier en matrice de tactiques. Export en un clic vers JSON de couche ATT&CK Navigator. - **Chasse aux IOC.** Collez un avis CISA, ingérez un bundle STIX, ou curaté à la main une liste. Scannez les nœuds, requêtes DNS, flux et payloads d'une capture contre IPs / domaines / SHA-256 / MD5 / MACs / OUIs. - **Baselines par actif + dérive.** Parcourt chaque capture que vous avez chargée et montre ce qui a changé pour un hôte donné, nouveaux pairs, nouveaux protocoles, nouveaux constats depuis la dernière fois, dérive de fournisseur / rôle / type d'équipement. - **Extraction sub-PCAP par fenêtre temporelle.** Faites glisser une plage sur la timeline de capture, extrayez ces paquets seuls comme sub-PCAP pour Wireshark. Le glissement est local, pas d'upload, pas de serveur. Pure Rust, pas d'`editcap`. ## GlassMarlin vs grassmarlin.com | Aspect | grassmarlin.com (web) | GlassMarlin (bureau) | |---|---|---| | Déploiement | Docker Compose, proxy inverse, volumes persistants | Un installeur signé par OS, runtime embarqué | | Modèle utilisateur | Multi-utilisateur avec authentification, projets par utilisateur | Mono-utilisateur, local uniquement | | OS cible | Conteneur Linux (tout hôte avec Docker) | Windows .msi, macOS .dmg, Linux .AppImage | | Outillage externe | tshark dans le conteneur, libpcap sur l'hôte | Aucun, dissection Rust, pas de Wireshark | | Base de données | Service PostgreSQL | SQLite embarqué, fichier unique | | Internet | Optionnel (export ATT&CK Navigator) | Jamais. Point. | | Moteur | Même moteur et plugins MarlinSpike | Même moteur et plugins MarlinSpike | | Artefact de rapport | JSON portable, examinable partout | JSON portable + OCSF + STIX + Sigma + ATT&CK Navigator | | Meilleur cas d'usage | Équipes d'engagement, hôtes de terrain partagés, serveurs de labo | Intervenant sur portable, hôtes air-gapped, SCIF, vols | ## Pour qui c'est fait L'outil local du défenseur. La chose que vous mettez sur le portable d'engagement. La chose que vous lancez sur un hôte air-gapped, en vol vers le site, dans le SCIF d'un vendeur, dans un bunker. Pas d'infrastructure. Pas d'internet. Pas de prep. - **Le portable d'engagement.** Mettez GlassMarlin sur le portable de l'évaluateur, volez sur site, travaillez les captures que l'opérateur OT vous tend. Aucune dépendance côté client à négocier avant que le travail commence. - **Air-gapped, SCIF, bunkers.** Hôtes sans internet, sans Docker, sans gestionnaire de paquets, et sans autorisation d'installer des runtimes tiers. GlassMarlin est un fichier : déposez-le sur une USB, ouvrez le PCAP, travaillez le projet. Packs ATT&CK / IEC 62443 / IOC cuits dedans, rien récupéré au runtime. - **Formation, tabletop, salles de classe.** Déposez GlassMarlin sur le partage AD ou la USB que vous avez distribuée à l'inscription. Vingt étudiants ont chacun leur propre MarlinSpike en 30 secondes. Pas de serveur à provisionner, pas de Docker à enseigner. ## Ce que GlassMarlin n'est pas - **Pas multi-utilisateur.** Pas de backends d'authentification, pas de scoping multi-tenant, pas d'URL partagée. Si deux analystes ont besoin de regarder le même projet, ils ouvrent chacun le fichier localement, ou ils le tirent dans un déploiement [grassmarlin.com](/fr/) pour la collaboration inter-engagement. - **Pas de capture en direct.** PCAP en entrée, atelier en sortie. Si vous avez besoin d'un capteur en direct qui parle à l'atelier d'équipe, c'est le sidecar `marlinspike-capd` côté serveur, pas sur le portable. - **Pas Wireshark.** GlassMarlin est la couche de triage OT par-dessus un PCAP (topologie, contexte d'actifs, alignement ATT&CK, constats) que Wireshark n'essaie délibérément pas d'être. Lisez avec Wireshark quand vous avez besoin des octets ; pilotez l'engagement avec GlassMarlin. ## Téléchargement · v0.1.1 Les installeurs signés pour les trois OS sont disponibles sur la page des versions GitHub. Chaque artefact est listé dans `SHA256SUMS` avec signatures GPG et OpenTimestamps fournies à côté de la version. **Windows (x86_64) :** - `.msi` (déploiements gérés) : [GlassMarlin_0.1.1_x64_en-US.msi](https://github.com/eris-ot/glassmarlin/releases/download/v0.1.1/GlassMarlin_0.1.1_x64_en-US.msi) - `.exe` (NSIS, installations à la main) : [GlassMarlin_0.1.1_x64-setup.exe](https://github.com/eris-ot/glassmarlin/releases/download/v0.1.1/GlassMarlin_0.1.1_x64-setup.exe) **macOS (Apple Silicon) :** - `.dmg` (signé et notarisé, Gatekeeper-clean) : [GlassMarlin_0.1.1_aarch64.dmg](https://github.com/eris-ot/glassmarlin/releases/download/v0.1.1/GlassMarlin_0.1.1_aarch64.dmg) - macOS Intel : prévu, pas encore livré. **Linux (x86_64) :** - `.AppImage` (tout hôte glibc 2.28+) : [GlassMarlin_0.1.1_amd64.AppImage](https://github.com/eris-ot/glassmarlin/releases/download/v0.1.1/GlassMarlin_0.1.1_amd64.AppImage) - `.deb` (systèmes gérés par apt) : [GlassMarlin_0.1.1_amd64.deb](https://github.com/eris-ot/glassmarlin/releases/download/v0.1.1/GlassMarlin_0.1.1_amd64.deb) **Vérifier :** - [SHA256SUMS](https://github.com/eris-ot/glassmarlin/releases/download/v0.1.1/SHA256SUMS) — sommes de contrôle de chaque artefact - [SHA256SUMS.asc](https://github.com/eris-ot/glassmarlin/releases/download/v0.1.1/SHA256SUMS.asc) — signature GPG - [SHA256SUMS.ots](https://github.com/eris-ot/glassmarlin/releases/download/v0.1.1/SHA256SUMS.ots) — preuve OpenTimestamps **Autres canaux :** - Toutes les versions (notes, versions antérieures) : [github.com/eris-ot/glassmarlin/releases](https://github.com/eris-ot/glassmarlin/releases) - Source : [github.com/eris-ot/glassmarlin](https://github.com/eris-ot/glassmarlin) - Même moteur, serveur d'équipe : [grassmarlin.com](/fr/) (ce site) - Même moteur, hébergé : [cloudmarlin.com](https://cloudmarlin.com) --- # Documentation ## Héritage *Source : https://grassmarlin.com/fr/wiki/heritage/* _Comment MarlinSpike hérite du rôle de GrassMarlin, ce que la NSA a publié en 2017, ce qui a cessé de fonctionner, pourquoi CVE-2026-6807 a forcé une succession, et ce qui a été conservé._ MarlinSpike est la continuation moderne de GrassMarlin. Cette page est le registre public de ce que cela signifie : ce qu'était GrassMarlin, pourquoi il a cessé d'être utilisable, et ce qui a été repris dans le successeur. ## Ce qu'était GrassMarlin GrassMarlin était un outil open source de cartographie réseau passive pour les systèmes de contrôle industriel (ICS), publié par l'Information Assurance Directorate de la NSA aux alentours de 2017 sur [github.com/nsacyber/GRASSMARLIN](https://github.com/nsacyber/GRASSMARLIN). C'était une application desktop Java qui lisait des captures de paquets (`.pcap`, `.pcapng`), ou du trafic en direct depuis une interface, et construisait une topologie réseau, identifiait les protocoles industriels, classifiait les équipements et faisait apparaître les relations de trafic. Pas de sondes, pas de scan actif, pas de transmission vers l'environnement. Pour une communauté habituée au compromis « soit vous restez sûr en ne touchant pas au réseau OT, soit vous obtenez de la visibilité en le scannant », GrassMarlin offrait une véritable troisième voie. C'était la bonne idée : neutre vis-à-vis des fournisseurs, passif uniquement, gratuit, et conscient des protocoles spécifiques à l'OT à une époque où la plupart des outils réseau traitaient le trafic industriel comme opaque. L'outil a été largement adopté par les équipes de sécurité ICS, les consultants en intervention et les propriétaires d'actifs faisant de la découverte réseau initiale dans des environnements de plant-floor segmentés où le scan actif n'était pas envisageable. ## Ce qui a changé entre 2017 et 2025 GrassMarlin n'a jamais été activement maintenu après les premières versions publiques. Le dépôt GitHub de la NSA a explicitement listé le projet comme en fin de vie depuis 2017. L'architecture desktop Java a vieilli : un client lourd mono-utilisateur ne convient pas à un monde où l'intervention OT est de plus en plus une activité d'équipe sur des hôtes d'engagement temporaires, où Docker est la voie d'installation par défaut, et où les rapports doivent pouvoir être consultés sur plusieurs machines sans réinstaller l'outil. La communauté d'intervention OT est passée à des ateliers web dans des espaces produit adjacents, mais le créneau open source, passif uniquement, neutre vis-à-vis des fournisseurs que GrassMarlin occupait est resté vide. Il n'y avait pas de successeur évident. Les opérateurs qui voulaient ce rôle exact ont continué à exécuter GrassMarlin sur des runtimes Java de plus en plus anciens, acceptant le compromis parce que l'alternative était rien. ## CVE-2026-6807 Le 28 avril 2026, CISA a publié l'avis ICSA-26-118-01 divulguant CVE-2026-6807, une vulnérabilité de divulgation d'information par entité externe XML (XXE) de sévérité moyenne dans GRASSMARLIN v3.2.1 (CWE-611). Des données de session conçues spécifiquement déclenchent une mauvaise gestion de l'entrée XML, ce qui peut entraîner une exposition involontaire d'informations sensibles depuis l'hôte. Du code de preuve de concept public est disponible. La NSA a confirmé dans sa réponse que le projet est en fin de vie depuis 2017 et ne recevra pas de correctif. Toutes les versions sont affectées. Les conseils de mitigation de CISA se résument à « cessez de l'utiliser ». Pour les équipes qui dépendaient du rôle que GrassMarlin remplissait, ce fut l'événement déclencheur. L'outil original ne peut plus être utilisé en toute sécurité. Le rôle doit toujours être rempli. ## Pourquoi MarlinSpike MarlinSpike était déjà en développement avant que le CVE n'arrive, l'architecture d'atelier d'intervention, le modèle multi-utilisateur, le contrat de rapport JSON portable, la couverture de protocoles OT-natifs, l'interface bilingue EN/FR, la lentille ATT&CK, la sévérité contextuelle pilotée par le contexte d'actifs, et le pipeline de chasse aux IOC étaient déjà conçus et livrés en v3.5.0. Ce que CVE-2026-6807 a rendu explicite, c'est que le rôle lui-même a besoin d'un successeur activement maintenu, moderne et multi-utilisateur. MarlinSpike reprend ce flambeau. Nous avons pris le domaine `grassmarlin.com` parce que nous nous engageons publiquement sur ce rôle, et pas seulement parce que nous livrons un produit qui se trouve avoir l'air similaire. Ce qui a été repris du design de GrassMarlin : - Analyse passive uniquement. Pas de sondes, pas de transmission, pas de scan actif. - Couverture des protocoles OT-natifs comme préoccupation de premier rang, pas comme arrière-pensée. - Neutre vis-à-vis des fournisseurs. Modbus, S7, DNP3, IEC 60870-5-104, CIP, MMS, GOOSE, BACnet, OPC UA, PROFINET, et plus. - Reconstruction de topologie à partir du trafic observé seul, inférence du niveau Purdue, empreintes fournisseurs, indices de rôle. - Gratuit et open source. AGPL-3.0. - Conscient des environnements plant-floor segmentés où le scan actif n'est pas sûr. Ce qui a changé : - Atelier web multi-utilisateur au lieu d'une application desktop Java mono-utilisateur. - Déploiement Docker Compose (1 cœur / 1 Go RAM) au lieu d'une installation JAR sur un poste de travail. - Artefacts de rapport JSON portables comme contrat moteur ↔ atelier, les rapports survivent à l'outil qui les a produits. - Maintenance active. Versions taguées. Moteur et interface web versionnés. Récupération en cours de scan. Limites de concurrence par tier. - Interface bilingue (English / Français). Sortie moteur consciente de la locale. L'architecture supporte plus de locales comme un dépôt de contenu, pas un projet d'ingénierie. - Sévérité contextuelle pilotée par le contexte d'actifs. MEDIUM sur un contrôleur de sécurité peut surclasser CRITICAL sur une imprimante quand le contexte est en place. - Chasse aux IOC sur l'ensemble des rapports d'un projet. Matrice MITRE ATT&CK en direct (ICS + Enterprise) issue de la sortie des plugins. - Mode HP-HMI pour les écrans muraux de salle de contrôle. Curseur temporel + extraction de sous-PCAP pour la boucle d'analyse. ## Parcours de migration Si vous utilisiez GrassMarlin : 1. Cessez d'exécuter v3.2.1 (ou toute version) compte tenu de l'avis CVE-2026-6807. 2. Continuez à utiliser votre pipeline de capture existant. Tout ce qui produisait des fichiers `.pcap` / `.pcapng` pour GrassMarlin fonctionne pour MarlinSpike sans changement, taps, ports SPAN, dumpcap, tshark. 3. Mettez en place MarlinSpike avec `docker compose up -d --build` (voir le guide de [démarrage](/fr/wiki/getting-started/)). Cinq minutes entre `git clone` et un atelier fonctionnel sur `127.0.0.1:5001`. 4. Téléversez vos captures. La chaîne d'analyse est exécutée comme un sous-processus par scan ; topologie, inventaire d'actifs et constats apparaissent dans l'atelier. 5. Partagez l'URL avec le reste de votre équipe d'engagement. Multi-utilisateur est le mode par défaut ; tout le monde travaille sur le même projet. Le côté sortie est matériellement différent : là où GrassMarlin produisait une vue en mémoire liée à la session desktop, MarlinSpike émet un artefact de rapport JSON portable. Ce rapport peut être examiné dans l'atelier MarlinSpike, archivé comme preuve, ou consommé par des outils en aval. Le rapport est le contrat. ## Reconnaissance Le crédit est dû. Le design de GrassMarlin était juste et sa publication était généreuse, l'Information Assurance Directorate de la NSA a publié le code source sous une licence ouverte à une époque où l'espace des outils de visibilité OT était dominé par des produits fermés, coûteux et liés à un fournisseur. Les choix architecturaux (passif uniquement, neutre vis-à-vis des fournisseurs, conscient de l'OT) ont porté les bonnes valeurs dans un artefact public que la communauté pouvait utiliser, étudier et apprendre. MarlinSpike hérite directement de ces valeurs. L'implémentation est un code indépendant avec une forme architecturale différente, mais le rôle et les principes sont continus avec ce que GrassMarlin a établi. Nous gérons un créneau que l'équipe originelle a ouvert. ## L'argumentaire architectural plus profond Cette page couvre ce qu'était GrassMarlin et comment MarlinSpike continue le rôle. L'argumentaire plus large sur *pourquoi* la défense OT devrait être souveraine par zone, compatible brownfield, et native du réseau segmenté vit sur [industrialindependence.org](https://industrialindependence.org). MarlinSpike, GlassMarlin et le Conversational Factory sont tous des implémentations de cet engagement architectural ; l'Industrial Independence Architecture est le principe qu'ils partagent. ## Références - Avis CISA : [ICSA-26-118-01](https://www.cisa.gov/news-events/ics-advisories/icsa-26-118-01) - CVE : [CVE-2026-6807](https://nvd.nist.gov/vuln/detail/CVE-2026-6807) (NVD) - Dépôt GrassMarlin original de la NSA : [github.com/nsacyber/GRASSMARLIN](https://github.com/nsacyber/GRASSMARLIN) - Source MarlinSpike : [github.com/eris-ot/marlinspike](https://github.com/eris-ot/marlinspike) - Industrial Independence Architecture : [industrialindependence.org](https://industrialindependence.org) --- ## Démarrage *Source : https://grassmarlin.com/fr/wiki/getting-started/* _Comprendre MarlinSpike rapidement, puis le lancer depuis la source, modèle produit, premières commandes et parcours documentaire._ MarlinSpike est une plateforme d'analyse réseau OT/ICS passive conçue pour un usage terrain partagé. Cette page vous donne le modèle produit, les premières commandes de déploiement et le parcours documentaire le plus court vers le reste du projet. **Passif uniquement**, Les captures de paquets entrent, et la plateforme ne transmet pas de paquets sur le réseau. **Atelier intervenant partagé**, Le modèle utilisateur normal est une surface web partagée pour l'équipe d'évaluation, pas un client desktop lourd. **Source plus Docker aujourd'hui**, La voie d'installation supportée actuelle reste la source en premier avec Docker Compose derrière un proxy inverse. ## Ce qu'est MarlinSpike MarlinSpike n'est pas qu'un parseur de paquets ni qu'un visualiseur de topologie. C'est une plateforme d'analyste déployable sur le terrain pour l'analyse réseau OT/ICS passive, qui transforme les fichiers de capture en topologie, contexte d'actifs, inférence de niveau Purdue, constats de risque, revue des communications externes suspectes et artefacts de rapport JSON portables. Les idées principales du produit, telles que décrites dans le README du projet, sont directes : - Analyse OT/ICS passive en premier. - Le successeur moderne de GrassMarlin : même premier principe de visibilité passive, reconstruit comme un atelier web partagé au lieu d'un client desktop mono-utilisateur. - Un modèle d'atelier partagé avec projets, uploads, scans, historique et revue. - Un contrat de rapport portable pour que l'analyse et la revue ne soient pas enfermées dans une seule session d'interface. ## Démarrage rapide La documentation du projet garde le parcours premier démarrage intentionnellement court. Clonez le dépôt, définissez les secrets dans `.env`, et lancez la stack Docker. ``` git clone https://github.com/eris-ot/marlinspike.git cd marlinspike cp .env.example .env docker compose up -d --build ``` Ouvrez l'application sur `http://127.0.0.1:5001` ou via votre proxy inverse. Au premier démarrage, MarlinSpike crée un utilisateur admin. Si `ADMIN_PASSWORD` est vide, un mot de passe aléatoire est généré et affiché dans les logs du conteneur. ## Flux de travail principal Le flux de travail qui apparaît tout au long de la documentation du projet est : 1. Créer ou choisir un projet. 2. Uploader ou sélectionner une capture. 3. Lancer un scan qui produit un artefact de rapport. 4. Examiner la topologie, les constats, l'inventaire et la dérive dans l'atelier. 5. Exporter ou archiver l'artefact de rapport JSON pour une utilisation en aval. L'artefact de rapport est la principale frontière de contrat. MarlinSpike peut le consulter dans l'atelier, mais le rapport est aussi conçu pour voyager avec l'équipe. ## Parcours documentaire Si vous êtes nouveau dans le projet, voici l'ordre de lecture recommandé après cette page : - **Opérateurs**, [Déploiement](/fr/wiki/deployment.md) : Variables d'environnement, Docker Compose, proxy inverse, volumes, mises à jour et attentes de sauvegarde. - **Analystes**, [Architecture](/fr/wiki/architecture.md) : La chaîne d'analyse en cinq stages, la couverture protocolaire, les sorties et le récit de détection aligné sur les standards. - **Développeurs**, [Famille de dépôts](/fr/wiki/repo-family.md) : Comment le dépôt suite se scinde en dépôts de composants faisant autorité pour le moteur, l'atelier, les plugins et les moteurs Rust. - **Extenseurs**, [Extensibilité](/fr/wiki/extensibility.md) : Où le nouveau travail appartient parmi les moteurs Rust, les plugins Python et les packs de règles YAML. La page de déploiement couvre l'histoire complète Docker, proxy inverse, volume de données, mise à jour, sauvegarde et hôte distant depuis les docs d'installation vérifiées. Références source : [README.md](https://github.com/eris-ot/marlinspike/blob/main/README.md) · [INSTALL.md](https://github.com/eris-ot/marlinspike/blob/main/INSTALL.md) --- ## Déploiement *Source : https://grassmarlin.com/fr/wiki/deployment/* _Déployez MarlinSpike comme un atelier Docker partagé avec proxy inverse, configuration, volumes persistants, mises à jour et capture live._ Les docs d'installation du projet sont très clairs sur le modèle opérationnel préféré : Docker Compose pour l'application et la base de données, un proxy inverse en façade, et un port d'application privé derrière. **Stack applicative**, Docker Compose avec le conteneur applicatif MarlinSpike plus PostgreSQL. **Modèle réseau**, Gardez l'application sur `127.0.0.1:5001` en interne et terminez TLS au niveau du proxy inverse. **Données avec état**, Le contenu utilisateur et la base de données vivent dans des volumes Docker persistants pour que les rebuilds ne les effacent pas. ## Déploiement Docker local Le flux d'installation vérifié est le point de départ normal pour un déploiement local, en laboratoire ou sur un hôte de terrain : 1. Copier `.env.example` vers `.env`. 2. Définir des valeurs robustes pour `DB_PASSWORD`, `SECRET_KEY` et `ADMIN_PASSWORD`. 3. Builder et démarrer la stack. 4. Vérifier les logs puis ouvrir l'application sur le port interne ou via votre proxy. ``` cp .env.example .env docker compose up -d --build docker compose logs -f app ``` Si `ADMIN_PASSWORD` est laissé vide, le premier démarrage génère un mot de passe admin aléatoire et l'affiche dans les logs du conteneur. ## Commandes courantes Le guide d'installation garde l'ensemble des opérations du jour 2 minimal : ``` docker compose ps docker compose logs -f app docker compose down docker compose restart app ``` ## Données persistantes MarlinSpike stocke l'état d'exécution dans des volumes Docker nommés pour qu'un rebuild ne supprime pas les uploads utilisateurs, les rapports ou la base de données. | Volume ou chemin | Rôle | |---|---| | `marlinspike-data` | Uploads, rapports, presets et soumissions archivées. | | `marlinspike-pgdata` | Données PostgreSQL. | | `/app/data/reports` | Artefacts de rapport générés à l'intérieur du conteneur applicatif. | | `/app/data/uploads` | Fichiers de capture uploadés. | | `/app/data/submissions` | Soumissions archivées. | | `/app/data/presets` | Stockage des captures preset. | ## Guide proxy inverse Les docs du projet recommandent de garder l'application liée à `127.0.0.1:5001` et de placer nginx, Caddy ou Traefik devant pour la terminaison TLS et l'ingress public. - Terminer TLS au niveau du proxy. - Ne transmettre que le port interne de l'application. - Garder l'application Flask liée en privé sauf si vous avez une raison délibérée de l'exposer directement. - Traiter le déploiement comme une surface d'équipe partagée plutôt que comme une application publique grand public. ## Mises à jour et sauvegardes Pour une mise à jour normale du code, tirez les dernières modifications et rebuildez les conteneurs : ``` git pull docker compose up -d --build ``` Avant les mises à jour majeures, sauvegardez la base de données et le volume de données : ``` docker compose exec db pg_dump -U marlinspike marlinspike > marlinspike.sql ``` Archivez aussi le contenu du volume de données ou du répertoire de données monté que votre déploiement utilise. ## Déploiement distant et capture live Le dépôt inclut un script générique `deploy.sh` pour le déploiement distant. Le schéma documenté est : ``` REMOTE=deploy@example-host ./deploy.sh ``` Pour le staging, les docs du projet mentionnent aussi `deploy-dev.sh`. La capture live est disponible via le sidecar optionnel `marlinspike-capd` (Linux uniquement). L'application web reste sans privilèges et communique avec capd via un socket unix ; capd détient `CAP_NET_RAW` et supervise `dumpcap` avec rotation en tampon circulaire. La page d'architecture explique pourquoi le déploiement ressemble à ça : atelier partagé, artefacts de rapport portables, analyse passive uniquement, et une séparation nette entre le traitement des paquets et la revue en aval. Voir [Architecture](/fr/wiki/architecture.md). Références source : [INSTALL.md](https://github.com/eris-ot/marlinspike/blob/main/INSTALL.md) · [docker-compose.yml](https://github.com/eris-ot/marlinspike/blob/main/docker-compose.yml) · [Dockerfile](https://github.com/eris-ot/marlinspike/blob/main/Dockerfile) --- ## Architecture *Source : https://grassmarlin.com/fr/wiki/architecture/* _La dissection de paquets, la topologie, le triage et le reporting restent intentionnellement séparés, chaîne en cinq stages, options DPI, couverture protocolaire et sorties._ L'architecture de MarlinSpike est construite autour d'un flux intervenant propre : entrée de capture passive, une chaîne d'analyse multi-stage lisible, un artefact de rapport portable, et un atelier partagé qui n'a pas à être propriétaire de chaque usage en aval. **Chaîne en cinq stages**, Ingestion, dissection, topologie, risque, puis rapport. **Frontière de rapport portable**, L'artefact de rapport est la frontière de passage entre l'analyse de paquets et la revue en aval. **UX terrain en premier**, L'atelier est conçu pour les engagements OT partagés, pas pour la manipulation générique de paquets. ## Frontière produit La valeur de MarlinSpike ne réside pas seulement dans le décodage de paquets. Le produit est la combinaison de l'analyse passive, de la reconstruction de topologie, du contexte d'actifs, des constats orientés intervenant et d'un atelier qui peut être partagé pendant un engagement en cours. La documentation du dépôt revient constamment sur la même frontière de contrat : - Le moteur reste capable de produire un artefact de rapport fini en mode headless. - L'artefact de rapport devient la frontière de passage entre l'analyse de paquets et la revue. - L'atelier web consomme ce rapport pour la collaboration, le triage, l'export et l'historique. - Les flux principaux restent utilisables sans rendre JavaScript obligatoire pour le parcours intervenant principal. ## Chaîne d'analyse en cinq stages L'architecture décrite dans le README se décompose en un pipeline simple : | Stage | Rôle | |---|---| | 1. Ingestion de capture | Valider `pcap` ou `pcapng`, extraire les métadonnées de base, et préparer l'entrée pour la dissection. | | 2. Dissection protocolaire | Parser les protocoles OT, les protocoles de découverte L2 et les conversations réseau. | | 3. Construction de topologie | Construire le graphe de noeuds et d'arêtes, inférer le placement Purdue, identifier les empreintes fournisseurs et assigner les rôles. | | 4. Surface de risque | Identifier les problèmes inter-zones, les communications externes suspectes, les balises C2, les anomalies d'entropie DNS et autres constats de niveau intervenant. | | 5. Rapport | Émettre l'artefact JSON portable que l'atelier et l'outillage en aval peuvent consommer. | ## Options DPI et stratification Le Stage 2 peut actuellement s'exécuter de deux façons : - Le chemin Python et tshark intégré dans `_ms_engine.py`. - Le chemin de dissection Rust externe via `marlinspike-dpi`. La documentation est explicite : le chemin Rust remplace le stage de dissection face aux paquets, pas l'ensemble du produit. La mise en forme de la topologie, la logique de triage et la construction du rapport restent au-dessus. ## Couverture protocolaire et surface de constats Les docs publics actuels décrivent MarlinSpike comme conscient de l'OT par défaut, avec une couverture pour des protocoles tels que Modbus, EtherNet/IP, S7, DNP3, PROFINET, OPC UA, BACnet, IEC 104, et les familles de découverte L2 comme LLDP, CDP, STP et LACP. Le récit de constats orienté intervenant est tout aussi important. Les docs du projet mentionnent des surfaces telles que : - Revue des communications inter-niveaux Purdue et inter-zones - Services en clair et chemins en écriture - Communications externes suspectes - Balises C2 et patterns de persistance de connexion - Indicateurs d'exfiltration DNS - Mappings MITRE ATT&CK sélectionnés et support de remédiation orienté SR de l'IEC 62443 ## Sorties et exports L'atelier est construit autour de bien plus qu'un simple graphe de topologie. Les docs listent ces surfaces de sortie comme étant de première classe : - Artefacts de rapport JSON portables - Revue de topologie et de relations - Inventaire d'actifs et contexte de services - Indicateurs C2 et constats de risque - Chemins d'export PDF, PNG et CSV depuis l'interface - Comparaison baseline vs dérive entre rapports Les docs famille de dépôts expliquent le dépôt suite, les dépôts de composants, le modèle subtree et l'état de transition actuel pour l'extraction du moteur et de l'atelier. Voir [Famille de dépôts](/fr/wiki/repo-family.md) et [Extensibilité](/fr/wiki/extensibility.md). Références source : [README.md](https://github.com/eris-ot/marlinspike/blob/main/README.md) --- ## Famille de dépôts *Source : https://grassmarlin.com/fr/wiki/repo-family/* _Un dépôt suite, plusieurs dépôts de composants ciblés, et une frontière d'artefact propre, le modèle subtree et l'état de transition actuel._ MarlinSpike passe d'un dépôt unique mixte vers une famille de dépôts où le dépôt suite vendore une combinaison connue pour fonctionner d'atelier, de moteur, de plugins et de moteurs Rust. **Dépôt suite**, Le dépôt marlinspike de niveau supérieur est la surface d'intégration pour les équipes qui veulent un seul clone. **Composants faisant autorité**, Le moteur, l'atelier, les plugins et les moteurs Rust ont chacun vocation à devenir faisant autorité dans leur propre dépôt. **Modèle subtree**, Le dépôt suite utilise git subtree, pas les sous-modules, pour vendorer les dépôts de composants. ## Modèle de dépôts | Dépôt | Rôle | |---|---| | `marlinspike` | Le dépôt suite, foyer d'intégration et option clone unique. | | `marlinspike-msengine` | Le dépôt du moteur d'analyse principal. Nom de package interne et CLI : `msengine`. | | `marlinspike-workbench` | L'interface web et la surface de collaboration qui lit les artefacts de rapport et peut optionnellement invoquer le moteur. | | `marlinspike-plugins` | Le monorepo de plugins Python pour les extensions consommatrices de rapports. | | `marlinspike-engines` | L'espace de travail de moteurs Rust pour les composants face aux paquets et fortement orientés événements. | ## Un seul clone pour tout Le dépôt suite vendore les dépôts de composants via `git subtree`. Les docs le présentent comme un compromis pratique : - Les utilisateurs gardent un comportement normal de `git clone`. - Les équipes évitent la charge de configuration des sous-modules git. - Les dépôts de composants peuvent garder leurs propres cycles de version. - Le dépôt suite peut épingler une combinaison connue pour fonctionner pour les opérateurs qui veulent toute la stack ensemble. ## Frontière de contrat L'artefact de rapport portable est la frontière de passage entre les composants : 1. `msengine` produit un artefact de rapport depuis le trafic capturé. 2. `marlinspike-workbench` consomme cet artefact pour la revue, le triage et la collaboration. 3. Les plugins Python consomment le même rapport fini et émettent des artefacts sidecar. 4. Les moteurs Rust peuvent produire des artefacts en amont ou des flux d'événements qui alimentent le moteur ou d'autres composants. L'atelier est intentionnellement utilisable même quand le rapport a été généré ailleurs et qu'aucun binaire de moteur local n'est présent. ## État de transition actuel Les docs reconnaissent honnêtement que le dépôt actuel contient encore le code du moteur et de l'atelier pendant que la scission se prépare. - Le dépôt racine `marlinspike` porte encore le code opérationnel du moteur et de l'interface Flask aujourd'hui. - Le premier préfixe subtree bootstrap est `msengine/`. - Jusqu'à la fin de la bascule, le `_ms_engine.py` racine reste la source opérationnelle du moteur. - Le script helper `scripts/sync-msengine-bootstrap.sh` copie en miroir le moteur opérationnel vers la copie subtree. ## Limites de propriété pour les contributeurs Les docs de contribution encouragent déjà les développeurs à penser en termes de futures frontières de composants, même avant que l'extraction soit terminée : - L'analyse face aux paquets, les observables et le travail CLI du moteur appartiennent à la frontière `msengine`. - Les routes Flask, les templates, l'auth, les projets et l'UX de revue de rapport appartiennent à la frontière `workbench`. - ATT&CK, IEC 62443, PERA et autres superpositions consommatrices de rapports appartiennent à la future frontière `plugins`. - Les parseurs Rust fortement orientés paquets appartiennent à la future frontière `engines`. Les docs d'extensibilité définissent comment les moteurs Rust, les plugins Python et les packs de règles YAML sont censés interagir avec l'artefact de rapport et entre eux. Voir [Extensibilité](/fr/wiki/extensibility.md) et [Contribution](/fr/wiki/contributing.md). Références source : [repo-family.md](https://github.com/eris-ot/marlinspike/blob/main/docs/repo-family.md) · [CONTRIBUTING.md](https://github.com/eris-ot/marlinspike/blob/main/CONTRIBUTING.md) · [COMPATIBILITY.md](https://github.com/eris-ot/marlinspike/blob/main/COMPATIBILITY.md) --- ## Extensibilité *Source : https://grassmarlin.com/fr/wiki/extensibility/* _Les moteurs Rust, les plugins Python et les packs de règles YAML ont chacun un rôle différent, les contrats d'extension formels et où appartient le nouveau travail._ Le contrat d'extensibilité existe pour éviter que le travail face aux paquets, la logique face aux rapports et le contenu de politique locale ne s'effondrent en un seul blob instable. **Moteurs Rust**, Parsing face aux paquets à haut débit, événements structurés et artefacts extraits. **Plugins Python**, Enrichissement face aux rapports, mapping, corrélation et superpositions côté intervenant. **Packs de règles YAML**, Mappings déclaratifs, suppressions et politique locale sans transformer la config en un autre langage. ## Principes partagés 1. L'artefact de rapport MarlinSpike portable reste la principale frontière de passage entre l'analyse de paquets et la revue en aval. 2. Les extensions optionnelles doivent s'exécuter en mode headless et ne doivent pas nécessiter Flask, un navigateur ou une connexion base de données. 3. Les sorties lisibles par machine doivent être déterministes et versionnées. 4. Le code face aux paquets ne doit pas prendre de décisions de politique locale. 5. Le code face aux rapports ne doit pas parser directement des captures de paquets brutes. 6. YAML doit rester déclaratif. ## Contrat des moteurs Rust Les moteurs Rust sont propriétaires du travail face aux paquets et fortement orienté événements : lire les captures, parser les protocoles, normaliser les transactions et émettre des observations ou artefacts structurés. Ils ne sont pas propriétaires du scoring final de topologie, du texte de constats orienté intervenant, du mapping ATT&CK, de la politique spécifique au site, ni du comportement de l'interface. ``` marlinspike-dpi --input --capture-id --output --pretty ``` Le contrat d'invocation minimal est simple : accepter un chemin de capture en entrée, accepter un identifiant de capture stable, écrire la sortie JSON vers un chemin spécifié par l'appelant, et retourner non-zéro en cas d'échec. ## Contrat des plugins Python Les plugins Python consomment un rapport JSON MarlinSpike fini et émettent un artefact sidecar pour l'enrichissement, la corrélation, le mapping ATT&CK, le mapping IEC 62443, la correspondance malware ou tout autre post-traitement. ``` python -m marlinspike_plugin_name \ --input-report \ --output ``` Le plugin ne doit pas muter le rapport d'entrée en place. L'artefact sidecar fait autorité, tandis qu'un rapport fusionné peut exister comme copie de commodité. ```json { "artifact_type": "plugin_output", "plugin_id": "marlinspike-plugin-name", "plugin_version": "0.1.0", "contract_version": 1, "summary": {}, "data": {}, "warnings": [] } ``` ## Contrat des packs de règles YAML Les packs de règles YAML sont la couche déclarative. Ils sont destinés aux mappings, surcharges locales, contrôles d'activation et de désactivation, et contenu de politique que les analystes peuvent avoir besoin d'ajuster sans réécrire du code pendant un engagement. Les docs sont explicites sur ce que YAML ne doit pas devenir : un langage de programmation général, une surface de parser cachée, ou un endroit pour enfouir une logique arbitraire qui appartient à un plugin. ## Règle de pouce pour le nouveau travail - Si ça consomme du `pcap` brut, des flux de paquets ou des événements de protocole en grand volume, ça appartient probablement à un moteur Rust. - Si ça consomme l'artefact de rapport MarlinSpike fini, ça appartient probablement à un plugin Python. - Si les analystes doivent pouvoir l'ajuster sans modification de code, ça appartient probablement à un pack de règles YAML. La page famille de dépôts montre comment ces surfaces d'extension s'alignent avec le dépôt suite et les futurs dépôts de composants faisant autorité. Voir [Famille de dépôts](/fr/wiki/repo-family.md) et [Contribution](/fr/wiki/contributing.md). Références source : [extensibility-contracts.md](https://github.com/eris-ot/marlinspike/blob/main/docs/extensibility-contracts.md) --- ## Presets *Source : https://grassmarlin.com/fr/wiki/presets/* _Le dépôt public ne livre pas de corpus PCAP tiers, mais MarlinSpike supporte les captures preset locales pour les laboratoires et les bibliothèques terrain réutilisables._ Cette page reflète la position honnête des docs du projet : les images publiques et le dépôt public n'embarquent pas de corpus tiers par défaut, mais les opérateurs peuvent quand même maintenir une bibliothèque de presets locale. **Pas de corpus embarqué dans le dépôt public**, Les docs preset indiquent explicitement que les corpus PCAP tiers ne sont pas embarqués publiquement. **Dossiers preset locaux supportés**, Vous pouvez créer vos propres dossiers de catégories sous `presets/` et y charger des captures locales. **Les uploads admin fonctionnent aussi**, Les équipes peuvent uploader des captures via l'interface de l'application après le déploiement. ## Politique de bibliothèque preset publique Le dépôt public n'embarque pas de corpus PCAP tiers. Cela garde la redistribution propre et évite de livrer des données de capture que le projet public ne devrait pas republier par défaut. Le même principe s'applique aux images publiques : les corpus locaux sont destinés à votre propre déploiement ou environnement de laboratoire, pas à quelque chose que le site public devrait laisser entendre est toujours inclus. ## Comment ajouter des presets locaux Le README preset vérifié donne un schéma simple : - Créez des dossiers de catégories sous `presets/`. - Ajoutez vos propres fichiers `.pcap`, `.pcapng` ou `.cap` localement. - Ou uploadez ces fichiers plus tard via l'interface admin après le déploiement. ``` presets/ site-a/ baseline-shift-a.pcapng site-b/ historian-incident.cap ``` ## Pourquoi ces fichiers restent locaux Les docs preset notent que les fichiers de capture preset sont ignorés à la fois par `.gitignore` et `.dockerignore`. Cela signifie qu'ils ne sont pas commités et ne sont pas intégrés dans les images publiques par défaut. C'est une séparation opérationnelle utile : - Le dépôt public reste propre et redistribuable. - Votre déploiement privé peut quand même maintenir une bibliothèque de captures reproductible pour la formation, les tests ou les démos. - Les équipes n'ont pas à exposer le trafic client ou des données tierces juste pour utiliser la fonctionnalité preset. ## Voies d'ingestion alternatives Vous n'avez pas besoin d'une bibliothèque preset intégrée pour utiliser MarlinSpike efficacement. Les docs du projet positionnent systématiquement la voie d'ingestion principale comme des uploads ou des captures alimentées dans l'atelier pendant un engagement. Utilisez les presets quand vous voulez une bibliothèque locale réutilisable. Utilisez les uploads quand vous voulez des captures terrain ad hoc, des fichiers d'incident ou des exports de laboratoire examinés immédiatement. La page de déploiement explique comment l'application stocke les uploads, les rapports et les données preset à l'intérieur des chemins d'exécution soutenus par Docker. Voir [Déploiement](/fr/wiki/deployment.md). Références source : [presets/README.md](https://github.com/eris-ot/marlinspike/blob/main/presets/README.md) · [README.md](https://github.com/eris-ot/marlinspike/blob/main/README.md) --- ## Contribution *Source : https://grassmarlin.com/fr/wiki/contributing/* _Gardez les modifications ciblées, respectez les frontières de gestion des données, et exécutez les vérifications locales avant d'ouvrir une PR._ Le guide de contribution est intentionnellement pragmatique : gardez les PRs petites, ne commitez pas de captures ni de secrets, et comprenez à quelle frontière de dépôt future votre modification appartient. **Modifications ciblées**, Les petites PRs sont plus faciles à réviser que les refactors larges. **Exécuter les vérifications locales**, Au minimum, exécutez la vérification de syntaxe Python avant d'ouvrir une PR. **Pas de données sensibles**, Ne commitez pas de captures, de secrets ou de détails d'environnement privés. ## Avant de commencer - Les issues ou petits fils de discussion sont les bienvenus pour les bugs, les lacunes de parseur, les problèmes d'interface et les améliorations de déploiement. - Gardez les modifications ciblées plutôt que de mélanger de nombreuses préoccupations sans rapport. - Évitez de commiter des captures privées, des secrets, des captures d'écran locales ad hoc ou des métadonnées d'outils locaux. - Les captures d'écran de documentation sous `docs/screenshots/` sont l'exception explicite à la règle sans capture d'écran. ## Notes de développement Les fichiers source canoniques mentionnés par le projet sont `_ms_engine.py`, `_auth.py`, `_models.py`, `_config.py` et `app.py`. Les shims de compatibilité tels que `auth.py`, `models.py` et `config.py` ne sont pas la principale source de vérité. Le guide de contribution renforce aussi le vocabulaire du projet : - Les moteurs Rust traitent le travail face aux paquets et fortement orienté événements. - Les plugins Python traitent l'analyse face aux rapports, l'enrichissement et la logique de triage. - Les packs de règles YAML traitent les mappings déclaratifs, les suppressions et la politique locale. ## Flux de la suite et helpers subtree Le dépôt suite garde des copies vendorées de composants dans des préfixes subtree. Les docs de contribution mentionnent des commandes helper pour travailler avec ce modèle : ``` ./scripts/update-subtrees.sh status ./scripts/sync-msengine-bootstrap.sh ``` Les préfixes subtree prévus sont `msengine/`, `workbench/`, `plugins/` et `engines/`. Aujourd'hui, `msengine/` est le premier vrai préfixe bootstrap. ## Vérifications locales Avant d'ouvrir une PR, les docs demandent aux contributeurs d'exécuter la vérification de syntaxe de base : ``` python3 -m py_compile app.py _auth.py _config.py _models.py _ms_engine.py ``` Si vous avez touché le subtree bootstrap du moteur, vérifiez aussi le point d'entrée du package en miroir : ``` PYTHONPATH=msengine python3 -m msengine --help ``` Si vous avez fait des modifications liées à Docker, le guide dit aussi de valider la stack localement : ``` docker compose up --build ``` ## Sécurité et gestion des données - Ne commitez pas de secrets, de fichiers `.env`, de credentials d'infrastructure ou de notes de déploiement internes. - Ne commitez pas de captures client ni de corpus PCAP tiers embarqués sauf si les conditions de redistribution sont explicitement documentées. - Si vous trouvez un problème de sécurité, signalez-le en privé avant d'ouvrir une issue publique. La page des versions suit les jalons récents du moteur, de l'interface et du visualiseur live pour que les contributeurs puissent voir où les changements majeurs ont déjà eu lieu. Voir [Versions](/fr/wiki/releases.md) et [Famille de dépôts](/fr/wiki/repo-family.md). Références source : [CONTRIBUTING.md](https://github.com/eris-ot/marlinspike/blob/main/CONTRIBUTING.md) --- ## Versions *Source : https://grassmarlin.com/fr/wiki/releases/* _Le moteur et l'interface web sont versionnés séparément, avec une piste live-viewer distincte, faits marquants récents et emplacement de l'historique complet._ Les docs de version vérifiées séparent les modifications du moteur de celles de l'interface web. Cela garde les versions d'analyse de paquets distinctes des mises à jour d'interface et d'atelier. **Version moteur actuelle**, v1.9.1, documentée le 26 février 2026. **Version interface web actuelle**, v1.9.0, documentée le 25 février 2026. **Piste live**, Un historique séparé est maintenu pour le visualiseur live et les modifications de la couche applicative orientées streaming. ## Modèle de versionnage Les docs de version du projet définissent un modèle de versionnage scindé : - La version du moteur suit les modifications de `_ms_engine.py`, le comportement tshark et le format de rapport. - La version de l'interface web suit `app.py` plus les templates et le comportement de l'interface. - Le document de version live suit la couche web et d'orchestration Docker pour les fonctionnalités live ou en streaming. ## Faits marquants récents du moteur | Version | Date | Faits marquants | |---|---|---| | `v1.9.1` | 26 février 2026 | Correction de classification d'infrastructure fournisseur pour les équipements Phoenix Contact et Innominate, plus rafraîchissement de démo. | | `v1.9.0` | 25 février 2026 | Fusion de noeuds L2 et support de la table MAC dans l'artefact de rapport et le visualiseur. | | `v1.7.0` | 24 février 2026 | Durcissement sécurité, travail majeur sur la mémoire et la scalabilité, file d'attente de scan séquentielle et valeurs tshark plus sûres par défaut. | | `v1.4.0` | 23 février 2026 | Analyse de ports cinq-tuples, détection C2, vérifications d'entropie DNS, ajouts de mapping ATT&CK et nouveaux champs de rapport. | ## Faits marquants récents de l'interface web | Version | Date | Faits marquants | |---|---|---| | `v1.9.0` | 25 février 2026 | Profils utilisateurs, limites d'upload par utilisateur, et nouvelles API de profil et contrôles de limites admin. | | `v1.8.2` | 25 février 2026 | Correction de bug limitant la visibilité des logs de scan aux utilisateurs admin. | | `v1.8.1` | 25 février 2026 | Versionnage initial séparé de l'interface web. | ## Piste live-viewer Le document de version live séparé capture les jalons pour la couche web live et le runtime de déploiement, incluant les ajouts du système de projets, la visualisation de diff et les mises à jour de topologie live. | Version | Date | Faits marquants | |---|---|---| | `v1.5.0` | 23 février 2026 | Système de projets, refonte du pipeline d'upload, archivage, stockage par projet et helpers de migration. | | `v1.4.0` | 23 février 2026 | Support du visualiseur pour l'analyse de ports et les indicateurs C2 liés à la sortie v1.4.0 du moteur. | | `v1.2.0` | 23 février 2026 | Visualiseur de diff de topologie et support du visualiseur de scan live. | ## Historique complet et sauvegardes Les docs de version du dépôt vont plus loin que ce résumé. Elles suivent aussi les instantanés de sauvegarde pour les jalons majeurs du moteur tels que `v1.7.0`, `v1.6.0`, `v1.4.0` et `v1.0.0`. Si vous avez besoin des notes de version exactes et des modifications ligne à ligne, utilisez les liens source ci-dessous. Références source : [releases.md](https://github.com/eris-ot/marlinspike/blob/main/releases.md) · [releases-live.md](https://github.com/eris-ot/marlinspike/blob/main/releases-live.md) · [GitHub Releases](https://github.com/eris-ot/marlinspike/releases) ---