MS MarlinSpike Passive OT/ICS Topology Workbench
Déploiement

Déployez MarlinSpike comme un atelier Docker partagé avec proxy inverse.

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-dataUploads, rapports, presets et soumissions archivées.
marlinspike-pgdataDonnées PostgreSQL.
/app/data/reportsArtefacts de rapport générés à l'intérieur du conteneur applicatif.
/app/data/uploadsFichiers de capture uploadés.
/app/data/submissionsSoumissions archivées.
/app/data/presetsStockage 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.

Besoin du modèle produit plus large derrière la voie d'installation ?

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.