Quelques consignes de sécurité

Nous allons bientôt « ouvrir des ports » sur notre serveur. Ca veut dire quoi ouvrir des ports ? Ca veut dire que nous allons exposer nos services au Big Bad Web.

Contrairement à la vie réelle régie par des lois, protégée par une police, … le Big Bad Web ressemble plutôt à une jungle, dans laquelle chaque utilisateur peut être attaqué par d’autres, de manière isolée ou organisée. En effet, les lois n’existent pas sur le Web, pas plus que la police, puisqu’un terminal situé en Ouzbékistan peut attaquer un serveur costaricain en l’espace de quelques millisecondes, éventuellement en passant en rebond sur un serveur hongkongais pour brouiller les traces.

Qui plus est, et c’est moins connu, la configuration des serveurs exposés à internet est publique. En effet, des services tels que shodan.io ou censys.com parcourent en permanence l’ensemble des adresses IP pour détecter les configurations et les exposer. Si votre serveur a des vulnérabilités, elles seront immédiatement détectées par ces services et exposées aux yeux de tous. Il suffira ensuite à des acteurs malveillants de quelques requêtes pour identifier ces vulnérabilités et de quelques lignes de commande pour les exploiter.

La première préoccupation de l’auto-hébergeur doit donc être la sécurité de son système, avant même de se poser la question des services qu’il envisage d’héberger. Cet article vise à vous donner quelques lignes de conduite avant de passer à l’action.

Les principales règles que nous développerons seront les suivantes :

• comprendre ce que l’on fait,
• durcir son système,
• maintenir toujours son serveur à jour,
• mettre en place un guichet (proxy inverse),
• sécuriser ses mots de passe,
• bannir les acteurs malicieux,
• compartimenter ses applications.

Comprendre ce que l’on fait

Nous avons commencé la mise en place de certains services (un partage Samba et un VPN). Au tout début, nous n’avions qu’une connaissance limitée de Linux et une faible compréhension des actions que nous menions. De ce fait, nous n’avions pas vraiment d’idée des risques pris. C’est pour cela que je ne vous ai pas proposé d’ouvrir des services au public, mais que nous nous sommes limités à les exposer via un VPN. Nous avons ouvert un port très spécifique, limitant notre surface d’attaque à une application de sécurité, le VPN.

Lors de l’exposition de services au public, nous pourrons comparer notre système à une banque : avant d’en ouvrir les portes, il nous faudra garantir sa sécurité. Et pour cela, il nous sera nécessaire de comprendre ce que nous faisons. Ainsi, nos premiers pas étaient plus destinés à nous familiariser à l’environnement Linux. J’espère que vous avez continué à jouer avec votre serveur car c’est le meilleur moyen d’apprendre, et donc de sécuriser votre installation.

Durcir son système

Rappelez-vous : lorsque nous avons mis en place le système sur notre Pi, nous avons changé le port SSH et nous avons mis en place un échange de clés. Ces actions visaient à durcir notre système, et notamment à sécuriser l’accès au SSH. En effet, une personne qui gagnerait l’accès au SSH pourrait rapidement s’approprier notre serveur, ses traitements et ses données. Nous allons donc poursuivre nos actions de durcissement du système.

Vous noterez que l’application d’installation du système sur Raspberry Pi nous a demandé dès le départ de définir un nom d’utilisateur et un mot de passe, afin de ne pas nous permettre de démarrer avec un profil par défaut. Nous devons le faire pour l’ensemble de nos applications, a minima toutes celles qui seront accessibles par le web. La première action, basique, sera de supprimer dans la mesure du possible les comptes par défaut sur les applications que nous allons installer. Plus de compte admin mais des comptes personnalisés. Et surtout, plus de mot de passe par défaut mais des mots de passe eux aussi personnalisés.

Ensuite, nous devrons choisir les services que nous exposons aux vilains acteurs du Web. En clair, certains services ont vocation à être présentés à nos utilisateurs. Ce n’est pas le cas de tous nos services. Par exemple, l’accès SSH n’intéresse pas spécialement un utilisateur final. On peut y accéder de l’extérieur à partir d’une connexion VPN, donc inutile d’installer une application web pour cela. Nous distinguerons systématiquement les applications que nous exposons à l’extérieur et celles auxquelles nous nous réservons l’accès, soit au sein de notre réseau local, soit via un accès VPN.

Maintenir toujours son serveur à jour

Un bon vieux dicton d’informaticien consiste à dire que la sécurité est un processus et non un produit. Ce sont des termes recherchés pour dire qu’on ne se contente pas de mettre en place un dispositif de sécurité que l’on peut gentiment laisser vivre, mais qu’il faut l’administrer en permanence. Apprentis auto-hébergeurs surchargés, passez votre chemin !

Vous aurez remarqué qu’à chaque fois que nous avons installé une nouvelle application, nous avons commencé par placer les commandes :

sudo apt update

sudo apt upgrade

Ces commandes constituent une hygiène de votre serveur. Elles permettent de tenir son serveur à jour et ainsi de parer aux failles de sécurité qui ont récemment été découvertes et corrigées. Faut-il passer ces commandes tous les jours, toutes les semaines ou une fois par mois ? A vous de voir, mais n’oubliez pas de les passer. Par ailleurs un redémarrage du serveur est nécessaire de temps en temps pour prendre en compte les modifications du noyau :

sudo reboot

L’utilitaire checkrestart permet le cas échéant de savoir quels services actifs nécessitent un redémarrage pour être mis à jour. Il peut être installé via le paquet debian-goodies. Néanmoins je vous conseille de redémarrer régulièrement votre serveur, une fois par mois ou par trimestre.

Lorsque nous aurons installé Docker, nous verrons également que les images Docker doivent être mises à jour régulièrement, mais cela viendra avec un prochain article.

Mettre en place un guichet (proxy inverse)

Revenons à la métaphore de la mise en place d’une banque. Lorsque nous l’ouvrirons, nous ne voudrons pas que les clients entrent et puissent se promener librement dans la banque, aller à la salle des coffres, discuter avec les employés du back-office, etc. Nous voudrons mettre en place un guichet, avec des guichetiers chargés de contrôler leur identité, de prendre en compte leurs demandes et de les relayer le cas échéant vers le back-office.

Eh bien c’est exactement ce que nous allons faire avec la mise en place d’un proxy inverse. Si l’on considère que notre richesse est constituée de nos données et traitements, nous ne voulons pas que les utilisateurs y accèdent librement. Nous allons donc mettre en place un outil qui va vérifier les droits d’accès des utilisateurs à nos services (identification, authentification), puis prendre en compte leurs demandes et leur restituer les résultats. Tous les flux d’information devront systématiquement passer par cet intermédiaire (à quelques exceptions près pour des services spécifiques tels que serveurs de courriels par exemple).

Sécuriser ses mots de passe

La gestion des mots de passe est souvent un véritable casse-tête : soit nous mettons en place de vrais mots de passe, robustes et différents pour chaque service, et nous n’avons aucune chance de tous les retenir, soit nous prenons un mot de passe simple pour tous nos services. Mais dans ce cas, si ce mot de passe est compromis (fuite sur le web par exemple), nous risquons tous nos accès simultanément. De la même manière un mot de passe aisé à retenir est généralement tout aussi aisé à craquer. C’est pourquoi je vous invite à mettre en place un gestionnaire de mots de passe, qui vous permettra de générer des mots de passe forts et de les stocker pour y accéder facilement. Nous verrons dans un prochain article la mise en œuvre de Vaultwarden.

Bannir les acteurs malicieux

Sur internet, les attaques sont permanentes dès lors que l’on expose un service. Il est donc indispensable de se protéger des acteurs malicieux. Nous avons déjà réduit considérablement les risques avec les mesures que nous avons définies. Mais n’oublions pas par exemple qu’il est possible de tester des milliers de mots de passe en quelques minutes. Ainsi, plus nous laissons de temps à un attaquant pour essayer de pénétrer nos systèmes, plus il est probable qu’il arrive à forcer nos dispositifs de sécurité. A cet effet, nous allons mettre en place un système de détection d’intrusion, c’est-à-dire une application qui va observer l’ensemble de nos services et identifier si des acteurs externes essaient de les pénétrer sans autorisation. Dans ce cas, ils banniront les adresses IP de ces acteurs pour une durée donnée, évitant qu’à force de tentatives, ces acteurs réussissent à entrer. Dans l’exemple bancaire que nous avons pris, il s’agit d’un agent de sécurité posté à l’entrée de notre banque et qui en garde l’accès.

Compartimenter ses applications

Dernier conseil sur la sécurité de notre dispositif : mettons en place un cloisonnement entre nos différentes applications. De cette manière, même si l’une d’entre elles est compromise, les autres ne seront pas touchées. Ce mode de fonctionnement sera induit par la mise en place de Docker, et par sa sécurisation, comme nous le verrons dans un prochain article.

---

Si vous avez apprécié cet article, n’hésitez pas à laisser à son auteur un petit commentaire : il l’encouragera à le maintenir et à le développer.