ORCA-SERV : serveur de développement distant et d'audit de sécurité

Objectifs

• Centraliser les dépôts, l'historique de travail et les agents de code sur une machine unique, accessible depuis tous mes postes.
• Supprimer les allers-retours Git imposés par un changement de poste en cours de session.
• Exécuter des audits de sécurité automatisés sur mes projets avant mise en production.
• Disposer d'un chemin d'accès privé et chiffré vers le serveur depuis chacun de mes équipements, sans dépendre d'une adresse fixe côté client.
• Ne laisser joignable depuis l'Internet que ce qui doit l'être. Atteint pour les services de l'hôte, pas encore pour les services lancés en conteneur.
• Monter en compétences sur l'administration Linux distante, la conteneurisation et les VPN mesh.

Architecture

ORCA-SERV tourne sur une instance Oracle Cloud qui ne sert qu'au développement : le site et la messagerie Kanyro sont restés sur leur VPS. Orca y tourne en mode serveur et orchestre les agents de code Claude Code et OpenCode, chaque tâche étant isolée dans son propre worktree Git ; à côté, Docker exécute Strix, dont les agents auditent les projets ciblés. Mes équipements et le serveur sont membres d'un même réseau privé maillé Tailscale, qui donne à chaque machine une adresse privée stable et chiffre les échanges de bout en bout. Le pare-feu de l'hôte fait de ce réseau un passage obligé : en entrée, il n'accepte que SSH et le trafic arrivant par l'interface Tailscale, et rejette tout le reste. Orca et les serveurs de développement ne sont donc joignables que par le réseau privé, même lorsqu'ils écoutent sur toutes les interfaces. Seule exception : les ports publiés par Docker, qui empruntent un autre chemin dans le noyau et échappent à ces règles.

Étapes de réalisation

Configurations

• Pare-feu hôte : le réseau privé devient un passage obligé

  La chaîne d'entrée accepte les connexions déjà établies, l'ICMP, la boucle locale, tout ce qui arrive par l'interface Tailscale et les nouvelles connexions SSH, puis rejette le reste. Qu'un service écoute sur toutes les interfaces ne suffit donc pas à le rendre joignable depuis l'Internet : il faut en plus qu'une règle l'autorise. La machine n'a par ailleurs aucune adresse IPv6 publique.

• Accès SSH

  Authentification par clé uniquement, mots de passe refusés, connexion directe en root interdite depuis le 14 septembre 2026 par un fichier dédié dans sshd_config.d. La configuration effective est contrôlée avec sshd -T après chaque modification, et le service est rechargé sans couper les sessions ouvertes.

• Ports publiés par Docker, hors du pare-feu hôte

  Un port publié par Docker est redirigé vers le conteneur avant d'atteindre la chaîne d'entrée : il traverse la chaîne de transfert, que Docker gère lui-même. Les règles du pare-feu hôte ne s'y appliquent donc pas, et certains conteneurs du serveur publient aujourd'hui des ports sur toutes les interfaces. Seul le filtrage réseau d'Oracle Cloud peut encore les bloquer.

• Isolation des tâches en worktrees Git

  Orca crée un worktree par tâche. Deux agents travaillant sur le même dépôt opèrent donc dans des répertoires de travail distincts, sur des branches distinctes, sans conflit d'index ni changement de branche subi par l'autre.

• Exécution de l'outil d'audit en conteneur

  Strix s'exécute dans un conteneur Docker, séparé du système hôte et de mes dépôts, et son port de contrôle n'est publié que sur la boucle locale. Le conteneur reçoit la cible à auditer et rend son rapport ; il ne dispose pas d'un accès permanent au reste de la machine.

Procédures

• Reprendre une session de travail depuis un autre poste

  Se connecter au réseau privé depuis l'équipement, rejoindre le serveur en SSH ou par l'application compagnon, et reprendre la tâche en cours. Le code, l'historique Git et l'état des agents restent sur le serveur : aucun commit de circonstance ni synchronisation préalable n'est nécessaire pour changer de machine en cours de travail.

• Lancer un audit de sécurité sur un projet

  Désigner la cible à Strix, qui enchaîne reconnaissance, tentatives d'exploitation et validation. L'outil ne se contente pas de repérer un motif suspect : il cherche à démontrer la vulnérabilité par une preuve de concept, ce qui écarte une partie des fausses alertes typiques des scanners classiques.

• Relever l'exposition réelle du serveur

  Lister les sockets en écoute et leur interface d'attachement, lire les règles de la chaîne d'entrée du pare-feu, puis lister les ports publiés par Docker, qui ne passent pas par cette chaîne. Un service n'est joignable depuis l'Internet que s'il écoute sur une interface publique et qu'aucune règle ne le bloque en chemin : il faut regarder les deux, jamais l'un sans l'autre.

• Modifier la configuration SSH sans se couper l'accès

  Vérifier d'abord qu'un compte non root dispose d'une clé et des droits sudo, et qu'il est bien celui utilisé dans les journaux de connexion. Écrire la directive dans un fichier de sshd_config.d, valider la syntaxe avec sshd -t, recharger le service plutôt que le redémarrer, puis contrôler la valeur effective avec sshd -T.

Environnement

• Instance Oracle Cloud sous Ubuntu 24.04, administrée à distance
• Machine dédiée au développement, distincte du VPS Hostinger qui héberge le site et la messagerie Kanyro
• Pare-feu hôte iptables : en entrée, seuls SSH et le réseau privé passent
• Tailscale, réseau privé maillé reliant le serveur, le PC de travail, le PC portable, le smartphone et le NAS
• Orca, environnement d'orchestration d'agents de code, exécuté en mode serveur
• Claude Code et OpenCode, agents de développement pilotés depuis Orca
• Docker Engine pour l'exécution des outils en conteneur
• Strix, agents autonomes d'audit de sécurité applicative, exécutés en conteneur

Technologies

• Linux
• Ubuntu
• VPN
• Docker
• Git

Tests réalisés

Tests à renseigner. Champ tests[] : { title, body }, protocole et résultat attendu.

Résultats obtenus

• Environnement de développement persistant : le changement de poste en cours de session ne demande plus aucune manipulation Git.
• Accès au serveur depuis chacun de mes équipements par le réseau privé maillé, avec une adresse privée stable et des échanges chiffrés de bout en bout.
• Outil d'audit de sécurité opérationnel en conteneur, appliqué à un premier projet réel.
• Administration de l'hôte limitée à SSH par clé sans root et au réseau privé ; service inutile désactivé.
• Écart identifié et documenté : les ports publiés par Docker contournent le pare-feu hôte.
• Documentation du projet rédigée dans un dépôt dédié : présentation, architecture, pile technique, analyse de sécurité et pistes d'amélioration.

Difficultés rencontrées et solutions apportées

• Une fiche fausse dans les deux sens

  La première version de cette fiche décrivait un serveur ouvert, sans pare-feu, dont SSH et Orca étaient joignables depuis l'Internet. Le relevé a montré l'inverse pour l'hôte : un pare-feu est actif et ne laisse passer que SSH et le réseau privé. L'erreur venait d'une lecture des ports en écoute sans lecture des règles de filtrage. La leçon est la même que dans l'autre sens : une écoute sur 0.0.0.0 ne dit rien à elle seule, il faut suivre le paquet jusqu'au bout.

• Docker contourne le pare-feu

  Le pare-feu hôte filtre la chaîne d'entrée, mais un port publié par Docker est traité avant, par redirection vers le conteneur. Un service lancé en conteneur avec un port publié sur toutes les interfaces est donc ouvert, quelles que soient les règles d'entrée. La correction consiste à publier ces ports sur la boucle locale ou l'adresse du réseau privé, ou à filtrer dans la chaîne DOCKER-USER prévue à cet effet.

• Durcir l'accès sans se l'enlever

  Interdire la connexion en root ou restreindre un service peut couper le seul accès au serveur, ou la session de travail en cours : Orca est lui-même le processus parent des agents qui administrent la machine. Chaque changement a donc été précédé d'une vérification du chemin d'accès réel (compte utilisé, clés présentes, origine des connexions) et suivi d'un contrôle de la configuration effective.

• Un outil d'audit est lui-même un risque

  Strix exécute des tentatives d'exploitation. Installé directement sur le système, il aurait fait courir au serveur les risques qu'il est censé détecter ailleurs. Le déployer en conteneur a été la première décision prise à son sujet, avant même le premier audit.

• Calibrer l'outil avant de lui faire confiance

  Lancer un audit automatisé sur un projet exposé sans savoir ce que l'outil rapporte réellement n'aurait pas eu de sens. Le premier passage a donc été fait sur Kanyro, dont je connais la surface d'attaque en détail, afin de pouvoir juger la pertinence des résultats avant d'élargir l'usage.

Bilan

ORCA-SERV est le projet qui a le plus changé ma façon de travailler : le poste de développement n'est plus une machine mais un service auquel je me connecte, et un contrôle de sécurité est devenu une étape possible avant livraison plutôt qu'une intention. C'est aussi le projet où j'ai le plus appris sur la différence entre ce qu'on croit et ce que la machine fait. J'ai d'abord décrit un serveur ouvert en ne regardant que les ports en écoute ; en lisant aussi le pare-feu, l'hôte s'est révélé fermé, et c'est Docker, que je considérais comme un facteur d'isolation, qui ouvre un chemin de contournement. Les mesures restantes sont identifiées : publier les ports des conteneurs sur la boucle locale ou le réseau privé, vérifier le filtrage d'Oracle Cloud, limiter les tentatives de connexion SSH et superviser la disponibilité.

Liens