Theo de Raadt, OpenBSD et l’état d’esprit « sécurisé par défaut »

Ce que « sécurisé par défaut » signifie en pratique

« Sécurisé par défaut » signifie qu’un système démarre dans l’état le plus sûr raisonnable sans que vous ayez à fouiller les menus, lire une longue checklist ou déjà savoir ce qui peut mal tourner. La première installation devrait minimiser les services exposés, limiter les permissions et choisir automatiquement les options les plus sûres. Vous pouvez toujours ouvrir des choses — mais vous le faites délibérément, en connaissance de cause.

Les paramètres par défaut sont une décision, pas une case à cocher

Un paramètre par défaut est le chemin que la plupart des gens emprunteront. Cela en fait un contrôle de sécurité : il façonne les résultats dans le monde réel plus que n’importe quel guide de durcissement optionnel. Si la configuration par défaut active discrètement des services réseau supplémentaires, des accès de fichiers permissifs ou des fonctionnalités risquées, de nombreux déploiements hériteront de ce risque longtemps.

OpenBSD est souvent cité dans les discussions sur la sécurité parce qu’il a traité cette idée comme un objectif d’ingénierie central pendant des décennies : livrer des paramètres conservateurs, réduire la surface d’attaque et rendre les comportements risqués optionnels. Ce focus a influencé la façon dont beaucoup d’ingénieurs pensent les systèmes d’exploitation, les services réseau et la conception d’applications.

À quoi s’attendre dans cet article

Nous verrons les pratiques qui soutiennent l’état d’esprit « sécurisé par défaut », notamment :

• Paramètres par défaut qui réduisent l’exposition (moins de services à l’écoute, permissions resserrées).
• Une culture d’audit (« lire le code » comme habitude quotidienne, pas slogan).
• Mitigations d’exploit qui augmentent le coût des attaques courantes.
• Processus et culture — des standards, des revues, et parfois des choix tranchés qui poussent la qualité.

Les principes plutôt que les personnalités

Le rôle de Theo de Raadt a une importance historique, mais l’objectif ici n’est pas l’idolâtrie. La leçon la plus utile est comment un projet peut transformer la sécurité d’un après-pensée en un ensemble de choix répétables — choix qui se voient dans les paramètres par défaut, les habitudes de revue de code et la capacité à dire « non » à la commodité lorsqu’elle crée un risque inutile.

Theo de Raadt et les origines d’OpenBSD

Theo de Raadt est un développeur canadien surtout connu pour son attention durable à l’ingénierie système rigoureuse dans la famille BSD. Avant OpenBSD, il a joué un rôle central dans les efforts précoces de BSD sur PC et fut l’un des cofondateurs de NetBSD au début des années 1990. Ce contexte compte : les BSD n’étaient pas des « apps », ce sont des systèmes d’exploitation destinés à être des fondations de confiance.

Pourquoi OpenBSD a été créé

OpenBSD a commencé en 1995 après le départ de de Raadt du projet NetBSD. Le nouveau projet n’a pas été lancé pour courir après la nouveauté ou pour construire un « BSD avec tout dedans ». Il est né pour bâtir un système où la correction et la sécurité étaient des priorités explicites, même si cela signifiait dire « non » à la facilité.

Dès le départ, OpenBSD a investi dans des domaines que beaucoup de projets considèrent comme ingrats :

• auditer le code pour repérer les patterns dangereux et les bugs subtils
• resserrer les paramètres pour qu’une installation fraîche soit plus difficile à mal configurer
• concevoir des fonctionnalités pour qu’elles puissent être maintenues et revues dans le temps

Un ensemble d’objectifs différent du “features first”

Beaucoup de systèmes d’exploitation et de distributions concurrencent sur l’étendue : plus de pilotes, plus de services inclus, plus d’options de configuration, livraison de fonctionnalités plus rapide. Ce sont des objectifs légitimes qui aident les utilisateurs.

L’histoire d’OpenBSD reflète un pari différent : qu’un système de base plus petit et plus compréhensible — livré avec des paramètres conservateurs — peut réduire la probabilité d’erreurs critiques en matière de sécurité.

Cela ne rend pas les autres approches « fausses ». Cela signifie simplement que des compromis se manifestent dans les décisions quotidiennes : activer un service par défaut, accepter un sous-système complexe ou redessiner une interface pour qu’elle soit plus difficile à mal utiliser.

Objectifs de sécurité vs résultats de sécurité

L’accent mis à la fondation d’OpenBSD était un objectif de sécurité : traiter la sécurité comme une contrainte de conception, pas comme un ajout. Mais les objectifs ne sont pas des résultats. La sécurité réelle se mesure sur des années — à travers les vulnérabilités découvertes, la rapidité de correction, la clarté de la communication et la capacité du projet à apprendre de ses erreurs.

La culture d’OpenBSD a grandi sur cette prémisse : supposer que le logiciel peut échouer, puis concevoir les paramètres par défaut et le processus pour échouer moins souvent.

Les paramètres par défaut comme contrôle de sécurité (pas juste un réglage)

OpenBSD traite « l’installation par défaut » comme une promesse de sécurité : un système frais doit être raisonnablement sûr avant que vous n’ayez lu un guide d’optimisation, ajouté une règle de firewall ou fouillé des fichiers de config obscurs. Ce n’est pas de la commodité — c’est un contrôle de sécurité.

Si la plupart des machines restent proches de leurs paramètres par défaut (comme c’est le cas dans la vraie vie), alors les paramètres par défaut sont l’endroit où le risque est soit empêché, soit silencieusement multiplié.

Sûr sans réglage supplémentaire

Une approche sécurisée par défaut suppose que les nouveaux administrateurs feront des erreurs, seront pressés ou suivront des conseils obsolètes. Le système vise donc à partir d’une base défendable : exposition minimale, comportement prévisible et configurations qui ne vous surprennent pas.

Quand vous changez quelque chose, vous devez le faire délibérément — parce que vous avez besoin d’un service — et non parce que le système de base l’a « utilement » activé.

Fonctionnalités conservatrices, services minimaux

Une expression pratique de cet état d’esprit est la sélection de fonctionnalités conservatrice et un biais vers moins de services exposés par défaut. Chaque démon à l’écoute est un nouvel endroit pour des bugs, des mauvaises configurations et des identifiants oubliés.

Les paramètres par défaut d’OpenBSD cherchent à garder la surface d’attaque initiale petite, ainsi la première victoire en matière de sécurité vient de ne pas exécuter des choses que vous n’avez pas demandées.

Cette conservatisme réduit aussi le nombre de « pièges » — fonctionnalités puissantes mais faciles à mal utiliser lorsqu’on apprend.

La documentation comme partie intégrante du contrôle

Les paramètres par défaut n’aident que si les gens peuvent les comprendre et les maintenir. La culture d’OpenBSD insiste sur une documentation claire et des fichiers de configuration lisibles afin que les administrateurs puissent répondre rapidement aux questions de base :

• Qu’est-ce qui tourne ?
• Pourquoi ça tourne ?
• Où est-ce configuré ?
• Quelle est la manière la plus sûre de le modifier ?

Cette clarté compte parce que les échecs de sécurité sont souvent opérationnels : un service laissé activé par inadvertance, une config copiée avec des options non sûres, ou l’hypothèse que « quelqu’un d’autre l’a déjà durci ».

OpenBSD cherche à rendre la voie sûre facile et évidente — dès le premier démarrage.

Culture d’audit : « Lire le code » et revue systématique

La réputation de sécurité d’OpenBSD ne repose pas seulement sur des mitigations ingénieuses ou des paramètres stricts — elle repose aussi sur une habitude : supposer que la sécurité s’améliore quand des gens lisent et questionnent délibérément le code, encore et encore.

« Lire le code » est moins un slogan qu’un flux de travail : revoir ce que vous livrez, continuer à le revoir, et traiter l’ambiguïté comme un bug.

À quoi ressemble l’« audit » (au-delà de la relecture)

La revue systématique ne se limite pas à scanner les erreurs évidentes. Elle inclut typiquement :

• Modélisation des menaces en termes simples : quelles entrées un attaquant peut-il contrôler ? Que se passe-t-il s’il envoie les pires données au pire moment ?
• Revue des API et interfaces : les fonctions sont-elles faciles à utiliser à mauvais escient ? Échouent-elles de manière sûre ? Les valeurs par défaut sont-elles conservatrices ?
• Nettoyage et simplification : suppression de code mort, resserrement des bornes, réduction des comportements implicites et clarification du flux de contrôle.

Une idée clé est que les audits visent souvent à prévenir des classes entières de bugs, pas seulement à corriger un problème signalé.

Cibles à haute valeur : où se cachent les bugs

Les audits se concentrent sur les composants qui analysent des entrées non fiables ou réalisent des opérations à haut risque. Cibles courantes :

• Parseurs et formats de fichiers (tout ce qui lit des données complexes sous le contrôle d’un attaquant)
• Cryptographie et gestion de clés (en particulier les chemins d’erreur et les cas limites)
• Démons exposés au réseau (authentification, gestion de session et machines d’état de protocole)

Ces domaines combinent souvent complexité et exposition — exactement là où les vulnérabilités subtiles prospèrent.

Compromis et limites

La revue continue prend du temps et requiert une expertise concentrée. Elle peut ralentir le développement de fonctionnalités, et ce n’est pas une garantie : les réviseurs peuvent rater des choses, et du nouveau code peut réintroduire d’anciens problèmes.

La leçon d’OpenBSD est plus pragmatique que magique : un audit discipliné réduit sensiblement le risque quand il est traité comme un travail d’ingénierie continu, pas comme une « passe » ponctuelle.

Moindre privilège et séparation des privilèges comme paramètres par défaut de conception

La sécurité ne consiste pas seulement à ajouter des protections après qu’un problème est survenu. OpenBSD a poussé une autre intuition : partir du principe que le logiciel aura des bugs, puis concevoir le système pour que ces bugs aient un pouvoir limité.

Moindre privilège (version en clair)

Le “principe du moindre privilège” signifie qu’un programme (ou un utilisateur) ne doit avoir que les permissions nécessaires à sa tâche — et rien de plus. Si un serveur web n’a besoin que de lire sa config et de servir des fichiers depuis un répertoire, il ne devrait pas aussi pouvoir lire tous les dossiers personnels, modifier les paramètres système ou accéder aux périphériques bruts.

Cela compte parce que lorsqu’un composant est compromis, les dégâts sont limités par ce que ce composant est autorisé à faire.

Séparation des privilèges : ne remettez pas les clés de la porte d’entrée

Les programmes exposés au réseau reçoivent des entrées non fiables en permanence : requêtes web, tentatives de connexion SSH, paquets malformés.

La séparation des privilèges scinde un programme en plus petites parties :

• Un petit helper « privilégié » étroitement contrôlé qui peut effectuer des actions sensibles.
• Un ou plusieurs processus non privilégiés qui gèrent le parsing risqué et l’interaction réseau.

Ainsi, même si un attaquant trouve un bug dans la portion exposée à Internet, il n’obtient pas automatiquement le contrôle du système. Il se retrouve dans un processus avec peu de droits et moins de voies pour s’élever.

Sandbox et isolation de processus comme confinement

OpenBSD a renforcé cette séparation avec des outils d’isolation supplémentaires (comme chroot et d’autres restrictions au niveau OS). Pensez-y comme exécuter un composant risqué dans une pièce fermée : il peut accomplir sa tâche étroite, mais il ne peut pas se promener dans la maison.

Le modèle mental avant/après

Avant : un grand démon avec de larges privilèges → compromettre une partie, compromettre tout le système.

Après : composants petits et séparés avec des privilèges minimaux → compromettre une partie, obtenir un point d’appui limité et buter sur des barrières à chaque étape.

Mitigations d’exploit qui ont changé les attentes

Pendant des années, une grande part des compromissions réelles commençaient par une famille simple de défauts : bugs de sécurité mémoire. Dépassements de tampon, use-after-free et erreurs similaires peuvent permettre à un attaquant d’écraser des données de contrôle et d’exécuter du code arbitraire.

OpenBSD a traité cette réalité comme un problème d’ingénierie pratique : supposer que certains bugs passeront à travers, puis concevoir le système pour que leur exploitation soit plus difficile, plus bruyante et moins fiable.

Augmenter le coût de l’exploitation

OpenBSD a contribué à normaliser des mitigations que beaucoup tiennent maintenant pour acquises :

• W^X (Write XOR Execute) : les pages mémoire doivent être soit écrites ou exécutables, pas les deux. Cela complique les attaques classiques « injecter du shellcode et y sauter ».
• ASLR (Address Space Layout Randomization) : randomiser l’emplacement du code et des données en mémoire rend plus difficile la prédiction d’adresses pour le ROP et techniques similaires.
• Protections de la pile : défenses au niveau compilateur et runtime (canaris de pile, vérifications associées) visant à détecter ou empêcher le débordement de pile avant le détournement de contrôle.

Ces mécanismes ne sont pas des boucliers magiques. Ce sont des ralentisseurs — souvent très efficaces — qui obligent l’attaquant à enchaîner plus d’étapes, exiger de meilleures fuites d’information ou accepter une fiabilité plus faible.

Défense en profondeur, pas un blanc-seing

La leçon plus profonde est la défense en profondeur : les mitigations gagnent du temps, réduisent le rayon d’impact et transforment certaines vulnérabilités en plantages plutôt qu’en prises de contrôle. Cela compte opérationnellement car cela peut réduire la fenêtre entre découverte et patch, et empêcher qu’une seule erreur ne devienne un incident total.

Mais les mitigations ne remplacent pas la correction des vulnérabilités. La philosophie d’OpenBSD associe résistance à l’exploitation et correction implacable des bugs : rendre l’exploitation plus difficile aujourd’hui et continuer à éliminer les bugs sous-jacents demain.

Cryptographie, hasard et interfaces plus sûres

La réputation de sécurité d’OpenBSD ne se construit pas sur du « trop de crypto partout ». Elle repose sur la correction avant tout : moins de surprises, des API plus claires et un comportement que l’on peut raisonner sous pression.

Cet état d’esprit influence la manière dont la cryptographie est intégrée, la génération d’entropie et la conception d’interfaces pour que les choix dangereux soient plus difficiles à faire par accident.

Correction et APIs claires valent mieux que l’astuce

Un thème récurrent chez OpenBSD est que les échecs de sécurité commencent souvent comme des bugs ordinaires : cas limites de parsing, flags ambigus, troncation silencieuse ou valeurs par défaut « aidantes » qui masquent des erreurs.

Le projet préfère des interfaces plus petites et auditées avec des modes d’échec explicites, même si cela implique de supprimer ou de repenser des comportements anciens.

Des APIs claires réduisent aussi les « pièges de configuration ». Si une option sûre nécessite un labyrinthe de basculements, de nombreux déploiements finiront par être non sécurisés malgré de bonnes intentions.

Choix cryptographiques conservateurs

L’approche d’OpenBSD en cryptographie est conservatrice : utiliser des primitives bien comprises, les intégrer soigneusement et éviter d’activer des comportements hérités principalement pour la compatibilité.

Cela se traduit par des paramètres par défaut favorisant des algorithmes forts et la volonté de déprécier les options faibles plutôt que de les maintenir « au cas où ». L’objectif n’est pas d’offrir toutes les suites de chiffrement possibles — c’est de faire du chemin sûr le chemin normal.

Hasard, parsing et complexité cachée

Beaucoup de ruptures réelles proviennent d’un hasard insuffisant, d’un parsing dangereux ou d’une complexité cachée dans les couches de configuration.

Un hasard faible peut saper une cryptographie autrement solide, donc les systèmes « sécurisés par défaut » traitent l’entropie et les API de hasard comme de l’infrastructure critique, pas comme une réflexion tardive.

Un parsing non sûr (de clés, certificats, fichiers de config ou entrées réseau) est un autre récidiviste ; des formats prévisibles, une validation stricte et une gestion plus sûre des chaînes réduisent la surface d’attaque.

Enfin, la complexité de configuration « cachée » est un risque en soi : quand la sécurité dépend d’ordres d’application subtils ou d’interactions non documentées, les erreurs deviennent inévitables.

La préférence d’OpenBSD est de simplifier l’interface et de choisir des paramètres par défaut qui n’héritent pas silencieusement de comportements hérités non sûrs.

OpenSSH et la diffusion de la pensée sécuritaire d’OpenBSD

OpenSSH est l’un des exemples les plus clairs de la façon dont la philosophie de sécurité d’OpenBSD a quitté le projet et est devenue une attente par défaut ailleurs.

Quand SSH est devenu la façon standard d’administrer Unix et Linux à distance, la question n’était pas « Faut-il chiffrer les connexions à distance ? » — c’était « Quelle implémentation peut-on faire tourner partout en toute confiance ? »

D’un fork SSH à une base de sécurité

OpenSSH est apparu lorsque l’implémentation SSH libre d’origine (SSH 1.x) a vu des changements de licence et que l’écosystème avait besoin d’une alternative permissive et maintenue activement.

OpenBSD n’a pas seulement fourni un remplacement ; il a livré une version façonnée par sa culture : changements conservateurs, clarté du code et biais vers un comportement sûr sans exiger que chaque administrateur soit un expert.

Cela importe largement parce que SSH se trouve sur le chemin le plus sensible dans de nombreux environnements : accès privilégiés, automatisation à l’échelle des flottes et récupération d’urgence. Une faiblesse dans SSH n’est pas « un bug de plus » — elle peut devenir une clé universelle.

Les paramètres par défaut sécurisés permettent une administration distante sûre

OpenBSD a considéré l’administration distante comme un workflow à enjeux élevés.

La configuration d’OpenSSH et ses fonctionnalités supportées ont incité les administrateurs vers de meilleures pratiques : cryptographie forte, options d’authentification sensées et garde-fous réduisant l’exposition accidentelle.

C’est ce que « sécurisé par défaut » ressemble en pratique : réduire le nombre de pièges disponibles pour un opérateur sous pression. Quand vous SSH-vous dans un serveur de production à 2h du matin, les paramètres par défaut comptent plus que les docs de politique.

La portabilité est le vecteur de diffusion des idées de sécurité

OpenSSH a été conçu pour voyager. Les ports vers Linux, *BSDs, macOS et Unix commerciaux ont permis aux décisions d’OpenBSD — APIs, conventions de configuration et attitudes de durcissement — de se déplacer avec le code.

Même des organisations qui n’ont jamais exécuté OpenBSD directement ont adopté ses hypothèses sur l’accès à distance parce qu’OpenSSH est devenu le dénominateur commun.

Des résultats opérationnels perceptibles

L’impact majeur n’était pas théorique : il est apparu dans les pratiques quotidiennes d’administration. Les équipes se sont standardisées sur la gestion distante chiffrée, ont amélioré les workflows basés sur clés et ont gagné un outil bien audité déployable presque partout.

Avec le temps, cela a élevé le niveau de base de ce que signifie une administration sûre et rendu l’accès distant non sécurisé plus difficile à justifier.

Ingénierie des releases, patchs et confiance

« Sécurisé par défaut » n’est pas seulement un objectif de conception : c’est une promesse que vous tenez à chaque livraison.

La réputation d’OpenBSD repose largement sur une ingénierie de release disciplinée : sorties prévisibles, changements soignés et biais vers la clarté plutôt que l’ingéniosité.

Les paramètres par défaut peuvent être sûrs le jour 1, mais les utilisateurs expérimentent la sécurité sur des mois et des années via les mises à jour, les avis et la confiance qu’ils ont pour appliquer les correctifs.

Rythme des patchs et avis clairs

La confiance grandit quand les mises à jour sont régulières et la communication concrète. Un bon avis de sécurité répond sans dramatisation à quatre questions : Qu’est-ce qui est affecté ? Quel est l’impact ? Comment remédier ? Comment vérifier ?

La communication à la manière d’OpenBSD tend à éviter le jargon de sévérité vague et se concentre sur le détail actionnable — plages de versions, références de patch et contournements minimaux.

Les normes de divulgation responsable comptent aussi. Coordonner avec les rapporteurs, fixer des calendriers clairs et créditer les chercheurs aide à garder les corrections ordonnées sans transformer chaque problème en gros titre.

La simplicité des outils réduit les erreurs dans la supply chain

L’ingénierie des releases est aussi gestion du risque. Plus la chaîne de build et de release est complexe, plus il y a d’opportunités d’erreurs de signature, d’artefacts erronés ou de dépendances compromises.

Une pipeline plus simple et bien comprise — builds reproductibles, peu de composants mobiles, bonnes pratiques de signature et provenance claire — diminue les probabilités d’expédier la mauvaise chose.

Communiquer le risque sans sensationnalisme

Évitez le discours alarmiste. Utilisez un langage clair, définissez ce que « remote », « local » et « élévation de privilège » signifient, et soyez honnête sur les incertitudes. Quand vous devez spéculer, étiquetez-le.

Fournissez un chemin « faites-le maintenant » (mettre à jour ou patcher) et un chemin « faites-le ensuite » (revue de configuration, surveillance). Quand les processus de release, patching et communication sont cohérents, les utilisateurs apprennent à mettre à jour rapidement — et c’est ainsi que les paramètres par défaut restent une confiance durable.

Culture : haut niveau d’exigence, responsabilité et friction

La réputation d’OpenBSD en matière de sécurité n’est pas seulement liée à des mitigations ingénieuses — elle tient aussi à la manière dont les gens travaillent.

Le projet a normalisé l’idée que la sécurité est une responsabilité partagée et que des paramètres par défaut « suffisants » (ou des patchs bâclés) ne sont pas acceptables simplement parce qu’ils fonctionnent.

Ingrédients culturels qui font tenir la sécurité

Quelques habitudes reviennent souvent dans les équipes d’ingénierie sécurisées, et OpenBSD les a rendues explicites :

• Des standards élevés comme baseline : le code doit être lisible, conservateur et « ennuyeux » au meilleur sens.
• Retour franc et responsabilité claire : les revues se concentrent sur la correction et le risque, pas sur les préférences personnelles.
• Responsabilité partagée : si quelque chose est livré, c’est « notre » problème — réviseurs et mainteneurs font partie du résultat.

Quand les opinions fortes aident — et quand elles nuisent

Les opinions fortes peuvent améliorer la sécurité en empêchant la dérive qualitative progressive : les raccourcis risqués sont contestés tôt et le raisonnement vague (« ça devrait aller ») est traité comme un bug.

Mais cette même intensité peut aussi réduire les contributions si les gens ne se sentent pas en sécurité pour poser des questions ou proposer des changements. La sécurité bénéficie de la scrutiny ; la scrutiny nécessite la participation.

Construire des habitudes de revue sans copier le style interpersonnel

Vous pouvez emprunter les mécaniques d’une culture exigeante sans reproduire la friction.

Rituels pratiques qui fonctionnent dans la plupart des organisations :

• Garde-fous avant fusion : exiger au moins une revue indépendante pour les zones sensibles (auth, parsing, crypto, réseau).
• Rotations de revue : assigner un « capitaine de revue » hebdomadaire pour faire avancer les files et diffuser la connaissance.
• Checklists légères : une liste courte et cohérente (validation des entrées, gestion des erreurs, frontières de privilèges, journalisation) jointe à chaque PR.
• Commentaires « expliquez le risque » : les réviseurs demandent un paragraphe résumant le risque lorsqu’on change des paramètres par défaut ou des frontières de confiance.

La leçon : la sécurité n’est pas une fonctionnalité qu’on ajoute plus tard. C’est une norme qu’on applique — encore et encore, visiblement, avec des processus qui rendent le bon choix le plus simple.