Il y a quelques jours, dans ma note "Setup Fedora CoreOS avec LUKS et TPM", je disais :

Attention, j'ai découvert que cette méthode n'est pas sécurisée en cas de vol physique du serveur !

Si un attaquant boot depuis un autre disque avec le même firmware et le même kernel, il pourra extraire en clair la clé LUKS stockée dans le TPM 🫣.

source

Une solution pour traiter ce point faible est d'utiliser un pin éloigné physiquement du serveur qui l'utilise.

Le framework Clevis utilise le terme "pins" pour désigner les différents méthodes de déverrouillage d'un volume LUKS.

Origine du mot "pin" ?
Claude Sonnet 4.5 m'a expliqué que le terme "pin", qui se traduit par "goupille" en français, désigne la pièce mécanique qui bloque l'ouverture d'un cadenat.

Par exemple, dans un contexte self hosting dans un homelab, je peux héberger physiquement un serveur dans mon logement et le connecter à un pin sur un serveur Scaleway ou sur un serveur dans le homelab d'un ami.

Les pins distants, accessibles via réseau, sont appelés serveurs Network-Bound Disk Encryption.

Si le serveur Network-Bound Disk Encryption est configuré pour répondre uniquement aux requêtes provenant de l'IP de mon réseau homelab, en cas de vol du serveur, le voleur ne pourra pas récupérer le secret permettant de déchiffrer le volume LUKS.

Dans le playground install-coreos-iso-on-qemu-with-luks-and-tang, j'ai testé avec succès le déverrouillage d'un volume LUKS avec un serveur Network-Bound Disk Encryption nommé tang.

Pour être précis, dans la configuration de ce playground, deux pins sont obligatoires pour déverrouiller automatiquement le volume : un pin tang et un pin TPM2. Le nombre minimum de pins requis pour le déverrouillage est défini par le paramètre threshold.

clevis, qui permet de configurer les pins et de gérer la récupération de la passphrase à partir des pins, utilise l'algorithme Shamir's secret sharing (SSS) pour répartir le secret à plusieurs endroits.

Voici quelques scénarios de conditions de déverrouillage que clevis permet de configurer grâce à SSS :

• TPM2 ou Tang serveur 1
• TPM2 et Tang serveur 1
• Tang serveur 1 ou Tang serveur 2
• 2 parmi Tang serveur 1, Tang serveur 2, Tang serveur 3
• ...

Si les conditions ne sont pas remplies, systemd-ask-password demande à l'utilisateur de saisir sa passphrase au clavier.

---

Je n'ai pas trouvé d'image docker officielle de tang. Toutefois, j'ai trouvé ici l'image non officielle padhihomelab/tang (son dépôt GitHub : https://github.com/padhi-homelab/docker_tang).
Dans mon playground, je l'ai déployé dans ce docker-compose.yml.

---

J'ai trouvé la configuration butane de tang simple à définir (lien vers le fichier) :

  luks:
    - name: var
      device: /dev/disk/by-partlabel/var
      wipe_volume: true
      key_file:
        inline: password
      clevis:
        tpm2: true
        tang:
          - url: "http://10.0.2.2:1234"
            # $ docker compose exec tang jose jwk thp -i /db/pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw.jwk
            # pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw
            thumbprint: dx9dNzgs-DeXg0SCBQW5rb7WQkSIN1B8MIgcO6WxJfI
        threshold: 2 # TMP2 + Tang (or passphrase keyboard input)

La seule complexité que j'ai rencontrée est la méthode pour récupérer le paramètre thumbprint de l'instance tang.

Voici la méthode que j'ai utilisée :

$ docker compose exec tang jose jwk thp -i /db/pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw.jwk
pLWwUuLhqqFb-Mgf5iVkwuV4BehG9vzd2SXGMyGroNw

Autre difficulté, il faut ajouter les arguments kernel suivants pour activer l'accès réseau dès le début du process de boot afin de permettre à clevis d'accéder au serveur tang :

variant: fcos
version: 1.6.0
kernel_arguments:
  should_exist:
    - ip=dhcp
    - rd.neednet=1

---

J'ai intégré au README.md du playground une section nommée "How to switch from 2 required ping to 1 or the opposite?", pour documenter comment modifier à chaud la configuration clevis.
Par exemple pour changer de serveur tang ou modifier le nombre de pins nécessaires pour déverrouiller la partition chiffrée.

---

Il est conseillé d'activer le pin TPM2 en complément de tang pour éviter ce type d'attaque décrit par Claude Sonnet 4.5 :

Imaginons un admin malveillant dans ton entreprise :

• Il a accès physique aux serveurs
• Il a accès au réseau (donc au serveur Tang)
• Il clone un disque pendant la nuit
• Il essaie de le monter sur sa propre machine pour extraire des données

Tang seul : ❌ Il réussit
TPM + Tang : ✅ Il échoue

Claude Sonnet 4.5

---

À noter que l'instance tang ne contient pas la passphrase et ne voit jamais passer la passphrase via son API.
Voici les explications que m'a données Claude Sonnet 4.5 :

Tang ne stocke pas la passphrase secrète de chiffrement LUKS. C'est justement tout l'intérêt de cette solution !

Voici comment ça fonctionne :

Le principe de Tang + Clevis

1. Génération de clé dérivée : Clevis (le client) contacte le serveur Tang et récupère sa clé publique
2. Chiffrement avec la clé de Tang : Clevis utilise cette clé publique pour chiffrer la passphrase LUKS
3. Stockage local : La passphrase chiffrée est stockée localement dans l'en-tête LUKS du disque (pas sur le serveur Tang)
4. Déchiffrement au boot :

• La machine contacte Tang
• Tang utilise sa clé privée pour aider à déchiffrer
• La passphrase LUKS est reconstituée
• Le disque est déverrouillé

Ce que Tang sait et ne sait pas

• ❌ Tang ne connaît jamais votre passphrase LUKS
• ❌ Tang ne stocke rien concernant vos clés
• ✅ Tang fournit juste un service cryptographique (un oracle de déchiffrement)
• ✅ C'est un serveur sans état (stateless)

C'est du chiffrement asymétrique avec un mécanisme appelé "network-bound disk encryption" : le disque ne peut être déchiffré que si la machine peut contacter le serveur Tang sur le réseau.

Claude Sonnet 4.5

---

Voici quelques ressources supplémentaires au sujet des techniques de déverrouillage automatique des volumes LUKS :

• Fedora Magazine - Using Linux System Roles to implement Clevis and Tang for automated LUKS volume unlocking
• Conférence lors du FOSDEM 2017 : Securing Automated Decryption New Cryptography and Techniques
• Disk encryption: LUKS ( Linux Unified Key Setup) with Tang · Posts · Jeff’s note

Comme je l'ai dit dans cette précédente note, jusqu'il y a peu de temps, je ne m'étais jamais intéressé et j'avais même évité les technologies liées aux trusted computing.

Il y quelques jours, j'ai testé avec succès l'installation d'une Fedora CoreOS avec une clé de déchiffrement LUKS sauvegardée dans une puce TPM2 à l'aide de clevis.

Grâce à TPM, cette configuration évite de devoir saisir la clé de déchiffrement au moment du boot de l'OS.
Je trouve cette approche particulièrement pertinente sur une distribution CoreOS qui utilise zincati pour appliquer automatiquement les mises à jour de l'OS à des horaires définis (voir note à ce sujet).

---

Pour tester cette configuration, j'ai créé le playground install-coreos-iso-on-qemu-with-luks , qui me permet de tester localement l'installation dans une VM QEMU.
Pour émuler le TPM2, j'utilise swtpm et le BIOS UEFI Open source edk2-ovmf .

Dans ce test, j'ai choisi de créer et de chiffrer une partition pour stocker les données du dossier /var/, qui sur CoreOS est l'emplacement qui contient les données mutables (accessibles en écriture).

Voici la configuration butane de LUKS encryption avec les options TPM2 et clevis que j'ai utilisées (fichier complet) :

storage:
  disks:
    - device: /dev/nvme0n1
      wipe_table: false
      partitions:
        - number: 4
          label: root
          size_mib: 15000
          resize: true
        - number: 5
          label: var       <=== label
          size_mib: 0  # 0 = use all remaining space

  luks:
    - name: var            <=== label
      device: /dev/disk/by-partlabel/var
      wipe_volume: true
      key_file:
        inline: password
      clevis:
        tpm2: true
        
  filesystems:
    - path: /var
      device: /dev/mapper/var
      format: xfs
      wipe_filesystem: true
      label: var
      with_mount_unit: true

Je trouve le contenu de ce fichier de configuration assez simple et explicite.

---

J'ai ensuite créé un second playground install-coreos-iso-on-baremetal-with-luks.

L'installation automatique s'est déroulée sans problème sur un serveur baremetal.

J'ai testé la désactivation de TPM2 dans le BIOS : la console m'a alors demandé de saisir la clé manuellement. C'est plutôt pratique en cas de problème TPM, branchement du disque sur une autre machine…

La clé de chiffrement LUKS n'est pas stockée en clair dans le fichier ISO, il n'est donc pas nécessaire de sécuriser l'accès à ce fichier.

---

Attention, j'ai découvert que cette méthode n'est pas sécurisée en cas de vol physique du serveur !

Si un attaquant boot depuis un autre disque avec le même firmware et le même kernel, il pourra extraire en clair la clé LUKS stockée dans le TPM 🫣.

D'après mes recherches, la seule approche qui semble permettre à la fois la protection contre le vol physique et le reboot automatique serait d'utiliser clevis avec un serveur tang plutôt que le TPM.

Je compte tester cette configuration dans les prochaines semaines (depuis, cette note a été publiée : Setup Fedora CoreOS avec LUKS et Tang).

#JaiDécouvert le nom officielle de Evil maid attack (from "Is luks unlock with TPM2 more secure?").

#JaiDécouvert Cold boot attack (from "ArchWiki - Trusted Platform Module").

Comme beaucoup de libristes, en 2002, j'ai été effrayé par le projet Palladium de Microsoft.

Palladium (NGSCB) était une initiative Microsoft annoncée en 2002 pour créer une plateforme de "trusted computing" basée sur du matériel sécurisé (une puce TPM dédiée) contrôlant strictement quels logiciels pouvaient s'exécuter et quels périphériques étaient autorisés à communiquer avec le système. L'objectif était de permettre à Microsoft de certifier cryptographiquement l'intégrité de toute la chaîne matérielle et logicielle, depuis le démarrage de l'ordinateur jusqu'aux applications en cours d'exécution.

On imaginait des scénarios concrets comme une carte son qui refuserait de capturer de l'audio depuis une sortie protégée par DRM, ou une carte graphique qui bloquerait la capture d'écran de contenu vidéo protégé.

À cette époque, Microsoft était en position hégémonique écrasante sur le marché des ordinateurs personnels : MacOS d'Apple représentaient moins de 3% des parts de marché.
Palladium représentait concrètement une forme de totalitarisme numérique sous contrôle total de Microsoft et des ayants droit.

Pour la communauté du libre, cela signifiait concrètement que ce système pourrait empêcher l'exécution de systèmes d'exploitation libres, bloquer l'accès aux périphériques sans drivers signés par Microsoft, et conduire à une génération d'ordinateurs où Linux serait techniquement banni ou très difficile à installer.

Heureusement, les critiques venues de toutes parts , combinées aux accusations de monopole et aux risques antitrust, ont contraint Microsoft à faire marche arrière. Cela a abouti à la situation actuelle où le TPM est davantage orienté vers la sécurité que vers le DRM et la restriction des libertés des utilisateurs.

Cet épisode a eu des conséquences durables pour moi : depuis, dès que j'entendais parler de puce de sécurité ou de TPM, j'avais immédiatement une réaction de rejet, parce que cela évoquait pour moi vendor lock-in, restrictions et contrôle par Microsoft. Je n'ai jamais cherché à en savoir plus.

C'est seulement en septembre 2025, lors de mon exploration du filesystem fs-verity, que j'ai découvert que les fonctionnalités du TPM2 sont en réalité très intéressantes et peuvent servir des objectifs de sécurité légitimes, très bien supportées par Linux.

Mon objectif du weekend est d'avancer sur le Projet 34 - "Déployer un cluster k3s et Kubevirt sous CoreOS dans mon Homelab".

Je veux apprendre à configurer LUKS encryption sous CoreOS avec un démarrage automatique basé sur TPM2 via clevis.

Je veux aussi m'assurer qu'en cas de problème, je peux toujours monter la partition chiffrée en saisissant manuellement la clé secrète.

Dans l'article "Hetzner Considered Hostile: A PSA", j'ai découvert le terme anglais Threat actor et son article Wikipedia : Threat actor.

Qui peut être traduit en français par "acteurs malveillants ou "acteurs de menace".

#JaiDécouvert le site Formation DevOps | DevSecOps de Stéphane Robert. Énormément d'informations très bien catégorisées et en français !

J'ai parcouru la section Analyser le code ! et j'y ai découvert :

• Checkov
• Grype
• Trivy

Alexandre m'a partagé l'article "Linux : Enregistrer toutes les commandes saisies avec auditd" qui présente Linux Audit.

The Linux audit framework provides a CAPP-compliant (Controlled Access Protection Profile) auditing system that reliably collects information about any security-relevant (or non-security-relevant) event on a system. It can help you track actions performed on a system.

-- from

La norme de sécurité de l'industrie des cartes de paiement (Payment Card Industry Data Security Standard ou PCI DSS) est un standard destiné à poser les normes de la sécurité des systèmes d'information amenés à traiter et stocker des process ou des informations relatives aux systèmes de paiement.

Dans ce cadre, de nombreuses conditions sont à respecter afin d'être compatible avec cette norme. Parmi celles-ci, l'enregistrement des commandes et instructions saisies par les utilisateurs à privilèges sur un système.

-- from

D'après ce que j'ai compris, la fonctionnalité Linux Audit est implémentée au niveau du kernel.

Linux Audit permet de surveiller les actions effectuées sur les fichiers (lecture, écriture…) et les appels syscalls.

D'après ce que je comprends, Linux Audit est conçu à des fins de sécurité. Il semble peu adapté pour documenter les opérations réalisées sur un serveur dans le cadre d'un travail collaboratif.

#JaiDécouvert restic-exporter : « Prometheus exporter for the Restic backup system ».

#JaiLu L'option ControlMaster de ssh_config.

J'y ai découvert l'open ControlMaster de OpenSSH.

#JaiLu Google Authenticator - ArchWiki.

Code source de Google Authenticator PAM module : https://github.com/google/google-authenticator-libpam.

#JaiLu Securing A Linux Server.

J'ai trouvé cet article excellent.

J'y ai découvert :

• ipsum ;
• maltrail ;
• Scam-Blocklist
• blocklist-abuseipdb
• https://github.com/teler-sh/teler

J'ai un peu parcouru la documentation de OpenBao, #JaimeraisUnJour faire un POC de cet outil.

#JaiLu ces threads Lobster : Security best practices for small company, SSH Key Management Challenges and Requirements.

#JaiLu The SOC2 Starting Seven (from)

First: for us, SOC2 is about sales. You will run into people with other ideas of what SOC2 is about. Example: “SOC2 will help you get your security house in order and build a foundation for security engineering”. No. Go outside, turn around three times, and spit. Compliance is a byproduct of security engineering. Good security engineering has little to do with compliance. And SOC2 is not particularly good. So keep the concepts separate.

-- from

😉

Suite à cela, j'ai lu l'article Wikipédia sur System and Organization Controls.

This is not an instruction guide for getting SOC2-certified. Though: that guide would be mercifully short: “find $15,000, talk to your friends who have gotten certified, get referred to the credible auditor that treated your friends the best, and offer them the money, perhaps taped to the boom box playing Peter Gabriel you hold aloft outside their offices”.

-- from

😉

If there is one thing to understand about SOC2 audits, it’s: SOC2 is about documentation, not reality.

-- from

🙈

Puis ils vous remettront un questionnaire de 52 000 lignes appelé Liste de demandes d'informations (IRL), basé d'une manière occulte sur ce que vous leur avez dit que vous faisiez. Vous le remplirez. Vous aurez quelques réunions, puis vous leur enverrez un chèque. Le nom de votre entreprise figurera sur un rapport.

-- from

🙈

#JaiDécouvert Shibboleth.

PRs, Protected Branches, and CI/CD

Enable Protected Branches for your master/deployment branches in Github. Set up a CI system and run all your deploys through it. Require reviews for PRs that merge to production. Make your CI run some tests; it probably doesn’t much matter to your auditor which tests.

We probably didn’t even need to tell you this. It’s how most professional engineering shops already run. But if you’re a 3-person team, get it set up now and you won’t have to worry about it when your team sprawls and new process is a nightmare to establish.

-- from

J'implémente systématiquement ce workflow dès que je travaille en équipe. Cependant, je me demande à partir de combien de développeurs cela devient réellement pertinent. Avant de lire cet article, je pensais que cela valait la peine à partir de trois développeurs.
À noter que ma motivation première de mise en place de ce workflow n'est pas la sécurité, mais la fluidité de développement en équipe et d'éviter les bugs.

Centralized Logging

Sign up for or set up a centralized logging service. It doesn’t matter which. Pipe all your logs to it. Set up some alerts – again, at this stage, it doesn’t matter which; you just want to build up the muscle.

-- from

Pour cela, j'utilise Grafana avec Loki branché sur un Object Storage.

The AWS console is evil. Avoid the AWS console.

Instead, deploy everything with Terraform (or whatever the cool kids are using, but it’s probably still just Terraform). Obviously, keep your Terraform configs in Github.

C'est aussi l'une de mes premières motivations pour utiliser Terraform ! 😊

#JaiDécouvert Munki, MicroDMD, NanoMDM qui sont des MDM.

Web Application Firewalls: Most SOC2’d firms don’t use them, and most WAFs don’t work at all.

-- from

🙂

Endpoint Protection and AV: You have MDM and macOS/Windows full complement of security features and a way to force them enabled, you’re covered. AV software is a nightmare; avoid it while you can.

-- from

🙂

Alexandre m'a partagé OpenSCAP mais je n'ai pas encore pris le temps de l'étudier.

#OnMaPartagé ce projet https://pts-project.org/ :

The PiRogue Tool Suite is an open-source consensual digital forensic analysis and incident response solution that empowers organizations with comprehensive tools for network traffic analysis, mobile forensics, knowledge management, and artifact handling.

J'ai l'impression que c'est un outil lié à la sécurité informatique, mais après une première lecture de 2min, je ne comprends pas très bien ni son utilité ni son usage 🤔.

https://github.com/anchore/grype

https://www.checkov.io/

• [ ] https://github.com/bunkerity/bunkerweb

Date de création de cette note : 2024-10-11.

Quel est l'objectif de ce projet ?

Je souhaite implémenter et publier un projet de "référence", de type skeleton, dont la fonction est d'installer les éléments de base d'un serveur Ubuntu LTS sécurisé.

Comme point de départ, je peux utiliser mon repository poc-bash-ssh-docker-deployement-example et le faire évoluer.

Le script _install_basic_server_configuration.sh se contente d'installer Docker.

J'aimerais y intégrer les recommandations présentes dans l'excellent article "Securing A Linux Server".

J'aimerais, entre autres, ajouter les fonctionnalités suivantes :

• [x] Amélioration de la configuration de OpenSSH ;
• [x] Installation et configuration de ufw ;
• [x] Mise en place de ipsum ;
• [x] Installation et configuration de fail2ban ;
• [x] Système d'installation / suppression de clés ssh ;
• [x] En option : installation et configuration de node exporter ;
• [x] En option : installation et configuration de l'envoi des logs de journald et Docker vers Loki en utilisatant Promtail (installation et configuration de l'envoi des logs de journald vers Loki en utilisant Vector) ;
• [x] En option : installation de configuration de Grafana ; avec Grizzly configuration des dashboards
  • [x] des logs et
  • [x] metrics des serveurs
• [x] En option : installer et configurer apticron pour envoyer un message dans les logs dès qu'un package de sécurité doit être installé.
  • [x] Génération d'une alerte Grafana si une mise à jour de sécurité doit être installé
• [x] En option : envoie de notification sur smartphone en cas d'alerte Grafana, via ntfy
• [ ] En option : installation et configuration de Linux Audit ;

Le repository doit présenter cette installation :

• [x] via Vagrant
• [ ] sur un Virtual machine Scaleway avec Terraform

Repository de ce projet :

• basic_ubuntu_server_install_playground

Ressources :

• poc-bash-ssh-docker-deployement-example
• "Securing A Linux Server"

https://fr.wikipedia.org/wiki/Norme_de_sécurité_de_l'industrie_des_cartes_de_paiement

https://fr.wikipedia.org/wiki/OpenSSH

https://complianceascode.readthedocs.io/en/latest/manual/user/01_introduction.html

Site web : https://people.redhat.com/sgrubb/audit/

GitHub : https://github.com/linux-audit/audit-userspace

https://fr.wikipedia.org/wiki/Fail2ban

https://manpages.debian.org/bookworm/apticron-systemd/apticron.1.en.html

https://github.com/stamparm/ipsum

Daily feed of bad IPs (with blacklist hit scores).

The PostgreSQL Audit Extension (pgAudit) provides detailed session and/or object audit logging via the standard PostgreSQL logging facility.

The goal of the pgAudit is to provide PostgreSQL users with capability to produce audit logs often required to comply with government, financial, or ISO certifications.

Page GitHub : https://github.com/pgaudit/pgaudit

https://en.wikipedia.org/wiki/Uncomplicated_Firewall

https://github.com/aquasecurity/trivy

https://github.com/topics/hardening

Émulateur TPM.

Dépôt GitHub : https://github.com/stefanberger/swtpm

Article Wikipedia : https://en.wikipedia.org/wiki/Evil_maid_attack

tang est un serveur Network-Bound Disk Encryption léger et sans état.

Dépôt GitHub : https://github.com/latchset/tang

Voir aussi TPM, LUKS, clevis.

tang est un projet créé par Red Hat, dans l'équipe The latchset Organization.

Le framework Clevis utilise le terme "pins" pour désigner les différents méthodes de déverrouillage d'un volume LUKS.

Origine du mot "pin" ?
Claude Sonnet 4.5 m'a expliqué que le terme "pin", qui se traduit par "goupille" en français, désigne la pièce mécanique qui bloque l'ouverture d'un cadenat.

Cliquez ici pour voir la liste des pins supportées par Clevis.