Brocas Christophe

Dans cet article, nous réfléchirons aux besoins de sécurité auxquels nos serveurs devront répondre. Il sera d’ailleurs plus question d’architecture que de serveur personnel. Pourquoi cela ? Car nos besoins vont à coup sûr évoluer dans le temps. L’approche la plus pérenne sera donc de mener une réflexion basée sur des services et non sur un serveur unique. Nous allons aussi nous attacher à assurer la résilience de nos services de base. Nos choix d’architecture auront pour objectif de pouvoir mieux détecter, contrer et éventuellement réparer les dommages causés par une attaque informatique. Nous pourrons par exemple restaurer nos services si un attaquant réussissait à prendre le contrôle du serveur. Notre plan de bataille commencera par la définition des grandes lignes de notre infrastructure, puis par la sélection de nos fournisseurs. Nous déploierons ensuite le serveur avec un premier palier de sécurisation système.

Nos serveurs présentent désormais une surface d’attaque réseau maîtrisée et une sécurisation système d’un niveau cohérent avec notre modèle de menaces. De même, le service SSH tournant sur ces serveurs est configuré de manière optimisée. Nous pouvons donc être relativement sereins si nos adversaires sont d’un niveau intermédiaire. Et si malgré toutes ces protections, une attaque comme un rançongiciel réussissait ? Et bien dans ce cas-là, pour l’instant, notre infrastructure serait particulièrement vulnérable. Aucune sauvegarde externalisée. Pas de centralisation des traces. Une supervision sécurité inexistante. Remédions à cette situation afin d’élever le niveau de maturité de la sécurité de notre infrastructure.

Maintenant que notre serveur principal est déployé et que nous y avons appliqué un premier niveau de sécurisation système, occupons-nous de sa sécurisation réseau. Nous allons détailler en quoi les attaques réseau sont primordiales dans notre modèle de menace. Comme nous le verrons, l’accès distant est le risque principal qui guette nos serveurs. Nous allons mettre en œuvre une sécurité en profondeur et les mesures de protection réseau en seront une de ses dimensions importantes.

2020 aura été une année marquante pour nos vies et nos sociétés. Il aura fallu se réinventer, trouver des solutions à des situations exceptionnelles. Dans les entreprises, l'Éducation ou la Santé, la mobilisation des ressources informatiques aura été maximale. Nos infrastructures auront ployé, tangué, parfois presque craqué, mais au final, cela aura tenu.

Notre infrastructure est désormais stable et sécurisée tant au niveau système que réseau. Nous allons pouvoir étudier de manière un peu approfondie un logiciel particulier : OpenSSH. Ce démon réseau nous permet de nous connecter en toute sécurité sur nos serveurs via le protocole SSH. Son développement a commencé il y a plus de 20 ans chez nos amis d’OpenBSD. La liste de ses fonctionnalités est d’une longueur impressionnante. Nous allons en parcourir ensemble quelques-unes qui, je l’espère, nous permettront d’améliorer tant notre sécurité que notre productivité quotidienne.

Ces dernières années, les programmes de bug bounty et la recherche de vulnérabilités libre ont augmenté notablement le nombre de failles trouvées sur les services en ligne. Une fois la vulnérabilité trouvée, le chercheur en sécurité essaie en général de contacter l'équipe sécurité du service en ligne pour lui signaler le problème. Et là, cela peut devenir un véritable casse-tête, car rien n'était jusqu'à maintenant normalisé et documenté. Voyons comment la proposition du fichier security.txt a amélioré la situation et ce qu'il faut mettre en place de votre côté pour bien traiter ces remontées.

Les logiciels de sécurité peuvent être complexes à comprendre et lourds à mettre en œuvre. Cela peut nous freiner dans l’usage et le déploiement d'architectures sécurisées. Mais le logiciel WireGuard veut nous réconcilier avec les solutions de sécurité. Il a pour but de créer un accès VPN performant entre deux machines et ne propose que peu de choix de configuration. En effet, son développeur, Jason A. Donenfeld a pris le parti de n'implémenter qu'un jeu restreint de protocoles cryptographiques, tous à l'état de l'art, et de ne fournir à l'utilisateur qu'une simple interface réseau. Ces choix permettent de masquer beaucoup de la complexité sous-jacente du VPN derrière cette abstraction. Et en plus de cette simplicité de configuration, WireGuard affirme aussi apporter un haut niveau de performance. Je vous propose de vérifier ensemble si cette promesse est bien tenue !

Nombre d'entre vous se sont sûrement déjà frottés à l'usage d'un gestionnaire de mots de passe. La plupart d'entre eux proposent une expérience utilisateur basée sur une interface graphique et des services en ligne assurant la sauvegarde et la synchronisation des mots de passe entre vos machines. Jason A. Donenfeld, développeur noyau et chercheur en sécurité, a souhaité développer une autre expérience utilisateur tournée pour sa part vers la philosophie Unix : tous les mots de passe seront stockés dans des fichiers, leur organisation sera faite au sein de répertoires et leur manipulation se fera au travers d'une commande unique. Une approche KISS (Keep It Stupid Simple) comme beaucoup d'entre vous l’apprécie, je pense. Partons à la découverte de Pass !

L'accès à votre courrier électronique se fait souvent via un webmail au travers de votre navigateur préféré. Ce webmail vous est le plus souvent proposé par votre fournisseur de courrier électronique. Il présente très fréquemment des limitations et une ergonomie non adaptée à vos usages. D'autre part, tout accès via webmail à votre boîte aux lettres vous empêche de communiquer de manière chiffrée (ou signée) avec vos correspondants. Nous allons remédier ensemble à ces inconvénients en utilisant deux logiciels libres. Et ce sans se priver de la sécurité et de la fiabilité que procure l’hébergement de sa messagerie par un fournisseur de services professionnel.