Je remet temporairement ma casquette de hacker

Suite au déferlement de nouvelles vulnérabilités de ces derniers mois, j’ai décidé de remettre temporairement ma casquette de hacker et d’en faire profiter StackX, l’offre d’infrastructure managée de ScalarX.

L’idée : obtenir un renforcement natif du modèle de sécurité tout en évitant de rendre invivable l’exploitation des clients.

Début des années 2000, j’ai conçu pour un opérateur Telecom US le système Manticore : un ensemble d’éléments et de mesures de sécurité destinés à renforcer la sécurité du système (Solaris) pour qu’il puisse être directement exposé. Quelque temps plus tard, j’ai porté la solution sur GNU/Linux, et c’est d’ailleurs par ce biais que j’en suis venu à jouer, de fil en aiguille, dans le game de l’infrastructure managée.

La situation est différente : Manticore venait se greffer sur un environnement « hostile » et non maîtrisé, sur les serveurs existants d’un client.

Je n’ai pas cette contrainte avec StackX. Je peux bâtir une défense en profondeur, cohérente avec l’architecture, exploitable en production, et toujours vérifiable localement, sans dépendance opaque à une plateforme externe.

J’ai terminé le gros du travail hier soir. Je finalise quelques outils spécifiques complémentaires en ce moment même.

Le durcissement repose sur plusieurs couches complémentaires.

Côté noyau : StackX bloque nativement plusieurs familles de modules qui n’ont pas d’usage sur nos plateformes managées et qui pourraient être impliquées dans des primitives d’exploitation.

Cela n’inclut pas seulement les modules concernés par Copy Fail ou Dirty Frag, mais aussi l’ensemble des familles que nous avons identifiées comme les plus à risque, plusieurs protocoles réseau rarement nécessaires, ainsi que plusieurs systèmes de fichiers legacy qui ne sont pas utilisés avec StackX.

Ce n’est ni une recompilation de noyau, bien que j’envisage toujours un noyau spécifique à terme uniquement sur ScalarCloud, ni un remplacement des correctifs éditeurs. C’est une mitigation native, lisible, réversible, et adaptée au contexte StackX. L’idée est également de pouvoir déployer de nouvelles mitigations encore plus rapidement avec un écosystème local déjà prévu pour.

Ce durcissement ne remplace ni les correctifs éditeurs, ni les mises à jour, ni l’observation continue. Il ajoute une couche de réduction de surface, de friction offensive et de limitation post-compromission.

D’autres paramètres ont été durcis ou restreints. La liste est longue, mais on peut notamment citer ptrace, BPF, les fuites d’informations kernel, dmesg, kptr, perf, la protection contre les classiques attaques hardlink, symlink et fifo, la désactivation de certains mécanismes dangereux ou inutiles dans le contexte StackX, ou encore une gestion durcie des user namespaces.

Concernant la couche MAC, j’ai privilégié SELinux à AppArmor, qui est le standard Debian, comme couche de contrôle d’accès obligatoire principale. Les environnements clients étant très variés, et certains ayant besoin d’environnements plus permissifs que d’autres, il fallait s’assurer de pouvoir conserver la compatibilité en préparant les contextes, les ports, les chemins et les règles nécessaires à StackX. Sur les installations qui le justifient, notamment les clients de l’offre Enterprise, il est possible d’obtenir une vraie barrière complètement adaptée au produit du client.

Les chemins StackX sont typés : espaces web clients, logs, scripts, données, secrets, ports non standards, services locaux. L’idée est de ne pas plaquer une politique générique sur une architecture spécifique, mais d’avoir une politique de sécurité qui comprend réellement comment StackX fonctionne.

Nous avons également renforcé par défaut les montages. Ce choix a demandé des adaptations sur certains services, par exemple OpenSearch, afin de ne pas casser le démarrage post-reboot de la JVM/JNA. C’était précisément l’objectif attendu : durcir sans fragiliser l’exploitation.

Les services applicatifs comme Redis, OpenSearch, MariaDB, Memcached ou PostgreSQL sont configurés avec une logique locale par défaut : bind loopback, pas d’exposition réseau inutile malgré les couches de firewall déjà présentes, mots de passe générés proprement, intégration dans les fichiers de livraison, monitoring, post-checks et scripts de maintenance.

Côté supervision, sxpostcheck, un outil interne, contrôle les états réels : configuration SELinux, LSM actifs, modules bloqués, paramètres kernel, services locaux, listeners, ports, réplications, sauvegardes, Redis, OpenSearch, PostgreSQL, VIP, DNS, cron, et plusieurs états StackX critiques.

Le monitoring SMS local a également été enrichi pour suivre les nouveaux services, éviter les faux positifs autant que possible, et continuer à être amélioré.

Nous avons aussi travaillé sur l’administration déléguée, un chantier déjà démarré il y a un moment pour des clients spécifiques. Certains outils StackX peuvent être utilisés via sudo par un compte d’administration client non-root dédié, mais avec des restrictions beaucoup plus strictes : commandes bornées, chemins maîtrisés, import/restauration encadrés, refus des opérations trop dangereuses, et réduction des possibilités de faire lire arbitrairement des fichiers.

L’idée est simple : déléguer ce qui peut l’être, sans transformer un wrapper d’administration en faille d’élévation de privilèges.

Enfin, tout reste local-first. StackX continue de privilégier des scripts Bash lisibles, des fichiers de configuration explicites, des logs locaux, des checks locaux, des mécanismes auditables par un administrateur système ou un agent. Pas de dépendance cloud imposée, pas de boîte noire, pas de sécurité déclarative impossible à relire.

Ce modèle augmente le coût d’exploitation d’une vulnérabilité, réduit la surface d’attaque, limite certaines possibilités post-compromission, et donne aux opérateurs des outils concrets pour vérifier l’état réel d’une machine.

StackX évolue tout en restant fidèle à sa philosophie : une infrastructure sobre, robuste, auditable, pensée pour des serveurs réels, des clients réels, et des contraintes de production réelles.

—
Christophe Casalegno (retrouvez tous mes réseaux sur : all.bo)