%

Quelle sécurité offre par défaut une installation d'OpenBSD ?

Article publié, le et modifié le
9 minutes de lecture

Cet article contient 1869 mots.
Source brute de l'article :
Commit version : 9c0a93f

Description

Retrouvez ci-dessous la traduction EN → FR de l’article “What security does a default OpenBSD installation offer?”, écrit par Solène Rapenne.

Introduction

Dans ce texte, j’expliquerais ce qui rend OpenBSD sécurisé par défaut quand vous l’installez. Ce n’est pas une analyse de la sécurité, mais plutôt un guide pour vous aider à comprendre ce qui est fait pour qu’OpenBSD soit un environnement sécurisé. Le but est ce texte n’est pas de comparer OpenBSD à d’autres OS mais de vous dire ce que vous pouvez attendre honnêtement d’OpenBSD.

Il n’y a pas de sécurité sans modèle de gestion des menaces. Je considère toujours les cas suivants : un ordinateur volé à domicile, une attaque à distance qui essaye d’exploiter les services fonctionnant, un exploit au-travers des clients réseaux.

Gestion de la Sécurité

Voici une liste de fonctionnalités que je considère importante pour la sécurité du système d’exploitation. Bien que tous les éléments de la liste suivante ne sont pas à strictement parlé des fonctionnalités de sécurité, ils aident à obtenir un système strict qui empêche le logiciel de mal se comporter ou les risques inconnus.

Mon opinion relative à la sécurité n’est pas seulement de prévenir les attaques à distances de pénétrer le système, mais aussi d’empêcher les programmes ou les utilisateurs de rendre le système inutilisable.

Pledge / Unveil en espace utilisateur

Pledge et unveil sont souvent cités ensembles bien qu’ils puissent être utilisés indépendamment. Pledge est un système d’appels pour restreindre les permissions d’un programme au sein de son code source, permissions qui ne peuvent pas être annulées une fois l’appel à pledge. Unveil est un système d’appels qui cache tout le système de fichiers au processus excepté les chemins qui ne sont pas surveillés ; il est possible de choisir quelles permissions sont appliquées aux chemins.

Les deux sont de puissants outils de sécurité “chirurgicaux” mais ils requièrent quelques modifications dans le code source d’un programme, et les ajouter requiert une profonde compréhension de ce que fait le logiciel. Il n’est pas toujours possible d’interdire les appels systèmes d’un logiciel qui exige de faire presque tout ; un logiciel conçu avec la séparation des privilèges est un meilleur candidat pour l’ajout propre de pledge, ainsi chaque partie fait son travail.

Certains logiciels parmi les paquets prennent en charge pledge et/ou unveil, tel que Chromium ou Firefox, pour les plus connus.

Séparation des privilèges

La plupart des services du système de base d’OpenBSD fonctionnent selon le modèle de séparation des privilèges. Chaque part d’un démon est restreint au minimum requis. Un démon monolithique devrait lire, écrire des fichiers, accepter des connexions réseaux, envoyer des messages au système de journalisation, dans le cas d’une brèche de sécurité qui offre une énorme surface d’attaque. En séparant un service en de multiples parties, cela permet un contrôle plus fin de chacun des processus, et en utilisant les appels systèmes de pledge et unveil, il est possible de paramétrer les limites et de réduire hautement les dommages en cas où un processus est attaqué.

Synchronisation de l’Horloge

Le démon du serveur est démarré par défaut afin de synchroniser l’horloge avec des serveurs de temps. Un serveur TLS référant est utilisé pour interroger les serveurs de temps. Garder un ordinateur avec son horloge synchronisée est très important. Ce n’est pas réellement une fonctionnalité de sécurité mais vous ne pouvez pas être sérieux si vous utilisez un ordinateur sur le réseau qui n’ait pas son temps synchronisé.

Affichage X sans droits root

si vous utilisez le serveur X, il abandonne les privilèges à l’utilisateur _x11 ; le serveur est exécuté avec les droits d’un utilisateur sans privilèges au lieu de root, ainsi en cas de problèmes de sécurité cela empêche un attaquant d’accéder au-travers de bogues de X11 à plus qu’il ne devrait.

Ressources limitées

Les limites de ressources par défaut empêchent un programme d’utiliser trop de mémoire, d’ouvrir trop de fichier ou trop de processus. Bien que cela puisse empêcher que certains gros programmes de s’exécuter avec les paramètres par défaut, cela aide aussi à trouver les failles de descripteurs de fichiers, prévenant ainsi une bombe dérivée ou un simple démon de capturer toute la mémoire jusqu’au crash.

Authentique chiffrement de disque

Quand vous installez OpenBSD selon le mode de chiffrement complet de disque, tout sera verrouillé par une passphrase à l’étape du chargeur de démarrage, ainsi vous ne pouvez accéder au noyau ou à d’autres parties du système sans la passphrase.

W^X

La plupart des programmes dans OpenBSD n’ont pas l’autorisation de cartographier la mémoire avec un bit d’Exécution et d’Écriture en même temps (W^X signifie Écrire et/ou Exécuter), cela peut empêcher un interpréteur d’avoir sa mémoire et modifiée et exécutée. Certains paquets ne sont pas conformes à cela et doivent être liés à une bibliothèque spécifique qui contourne cette restriction ET doivent être utilisés depuis une partition ayant l’option de montage “wxallowed”.

Une seule source fiable de données aléatoires

Lorsque votre système requiert un nombre de données aléatoires (et c’est souvent le cas), OpenBSD fournit seulement une seule API pour obtenir ces données aléatoires, qui sont réellement aléatoires et ne peuvent être devinées. Un bon générateur de nombres aléatoires (RNG) est important pour de nombreuses exigences en matière de cryptographie.

Une documentation précise

OpenBSD est fournit avec une documentation complète dans ses pages de manuels. On doit pouvoir configurer entièrement son système en utilisant seulement les pages de manuels. Les pages de manuels sont fournis parfois avec des sections CAVEATS ou BUGS ; il est important de bien faire attention à ces sections. Il est mieux de lire la documentation et de comprendre ce que cela fait avant de configurer un système au lieu de suivre un anonyme texte obsolète disponible sur Internet.

IPSec et Wireguard à l’intérieur

Si vous avez besoin de paramétrer un VPN, vous pouvez utiliser nativement les protocoles IPSec ou Wireguard, sans aucun autre paquet requis.

Sécurité de la mémoire

OpenBSD a de nombreuses mesures de sécurités à-propos de l’allocation de la mémoire et empêchera son utilisation après libération ou un usage très agressif de mémoire non sûre, souvent sources de crash pour certains logiciels fournis en tant que paquets puisqu’OpenBSD est très strict sur l’utilisation de la mémoire que vous faites. Cela aide à trouver les utilisations abusives de la mémoire et à arrêter les mauvais comportements logiciels.

Compte root dédié

Lorsque vous installez le système, un compte root est créé et son mot de passe est demandé, puis vous créez un utilisateur qui sera membre du groupe “wheel”, permettant de basculer l’utilisateur vers root avec le mot de passe de root. doas (l’équivalent sudo d’OpenBSD) n’est pas configuré par défaut. Avec l’installation par défaut, le mot de passe root est requis pour toute interaction root. Je pense qu’un compte root dédié qui peut être journalisé sans l’usage de doas ou sudo est mieux qu’une mauvaise configuration de doas ou sudo permettant ainsi de faire des choses seulement si vous connaissez le mot de passe utilisateur.

La plus petite surface d’attaque réseau

Les seuls services qui pourraient être activés dès l’installation, écoutant sur le réseau, sont OpenSSH (demandé lors de l’installation, avec par défaut sur yes), dhclient (si vous choisissez dhcp) et slaacd (si vous utilisez IPv6 en configuration automatique).

Swap chiffrée

Par défaut, la swap d’OpenBSD est chiffrée, ce qui signifie que si la mémoire des programmes est envoyée vers la swap, nul ne pourra la déchiffrer plus tard.

SMT désactivé

Dû fait d’un très grand nombre de failles de sécurité sur SMT (tel que l’HyperThreading), l’installation par défaut désactive les cœurs logiciels afin de prévenir toutes fuites de données.

Microphone et Webcam désactivés

Avec l’installation par défaut, les microphones et webcam ne peuvent actuellement rien enregistrer excepté du bruit blanc à moins que vous configuriez sysctl pour cela.

Maintenance, sorties et mises à jour fréquentes

L’équipe d’OpenBSD publie une nouvelle version tous les six mois, et seules les deux dernières versions reçoivent les mises à jours de sécurité. Cela permet de mettre à jour sans douleur ; le processus de mise à jour est constitué de petites étapes deux fois par an, ce qui aide à garder l’ensemble du système à jour. Cela évite la crainte d’une mise à jour massive, de ne jamais la faire et je considère que c’est un énorme bonus de sécurité. La plupart des OpenBSD fonctionnent sur les versions les plus récentes.

Signify : chaîne de confiance

L’installateur, les archives et les paquets sont signés en utilisant les clés publiques et privées de signify. Les installations d’OpenBSD sont fournies avec les versions de clés de la version courante et n+1 afin de vérifier l’authenticité des paquets. Une clé est utilisée seulement six mois et de nouvelles clés sont reçues à chaque nouvelle sortie permettant de construire une chaîne de confiance. Les clés Signify sont très petites et sont publiées dans de nombreux médias afin de permettre une double vérification si vous avez besoin de vous assurer de cette chaîne de confiance.

Les Paquets

Alors que la plupart des éléments précédents concernaient le système de base ou le noyau, les paquets ont également quelques astuces à offrir.

chroot par défaut quand disponible

La plupart des démons qui sont disponibles offrent une fonctionnalité de chroot qui sera activée par défaut. Dans certaines circonstances, tel que pour le serveur web Nginx, le logiciel est patché par l’équipe OpenBSD afin d’activer chroot qui n’est pas une fonctionnalité officielle.

Des utilisateurs dédiés aux services

La plupart des paquets qui fournissent un serveur crée aussi un utilisateur dédié exactement à ce service, permettant la séparation des privilèges en cas de problèmes de sécurité dans le service.

L’installation d’un service ne l’active pas

Lorsque vous installez un service, celui-ci n’est pas activé par défaut. Vous allez devoir configurer le système pour l’activer au démarrage. Il y a un unique fichier /etc/rc.conf.local qui peut être utilisé pour voir ce qui est actif au démarrage, qui peut être manipulé par l’utilisation de la commande rcctl. Forcer l’utilisateur à activer les services oblige l’administrateur système à être pleinement attentif à ce qui est exécuté dans le système, ce qui est un bon point pour la sécurité.

Conclusion

La plupart des “fonctionnalités de sécurité” vues devraient être considérées comme de bonnes pratiques et non pas comme des fonctionnalités. Beaucoup des bonnes pratiques suivantes pourraient être facilement mises en œuvre : Limiter les ressources utilisateurs, réduire les privilèges des démons, être strict dans l’utilisation de la mémoire, fournir une bonne documentation, démarrer le strict minimum requis de services et fournir à l’utilisateur une installation par défaut propre qui peut être personnalisé plus tard.

Il y a aussi de nombreuses autres fonctionnalités qui ont été ajoutées, que je ne comprend pas pleinement ; je préfère laisser au lecteur le soin d’en prendre connaissance.