Table des matières

4.3. Sécurisation de serveur

4.3. Sécurisation de serveur

Dans le cadre des travaux pratiques du cours, vous allez travailler avec un serveur virtuel (VPS) accessible publiquement. Cette accessibilité sur Internet entraîne des risques importants : de nombreuses attaques visent des machines vulnérables afin de les compromettre et de, selon les cas, voler des données confidentielles, rendre un service inaccessible, ou encore exploiter la machine-cible à d’autres fins malveillantes (vecteur d’attaque, minage de cryptomonnaie, … ).

Nous allons profiter de l’occasion pour mettre en pratique l’analyse de risques présentée en section 4.1.

4.3.1. Analyse de sécurité

Identification des biens

Dans le cas qui nous occupe, les biens à protéger sont au nombre de trois :

Le VPS lui-même
Les données hébergées sur le VPS.
Les services rendus par le VPS

Vulnérabilités et menaces

Sur le VPS

La particularité du VPS est qu’il est hébergé par un fournisseur de service, qui est lui-même responsable de la sécurité physique du serveur. Cette partie de l’analyse de risques ne nous concerne donc pas. Notez cependant que le fournisseur de service n’est pas infaillible, ce qui nous laisse tout de même avec une menace concrète d’indisponibilité du service.

Comme tout serveur nécessite des logiciels, à commencer par son système d’exploitation, il est vulnérable de par les failles de ces derniers, ce qui peut mener à diverses menaces : indisponibilité logicielle des services, contournement des contrôles d’accès, … Il importe donc de limiter au minimum requis les processus et services logiciels qui tournent sur ce serveur, afin de limiter la surface d’attaque (i.e. les vulnérabilités potentiellement exploitables par un attaquant).

Enfin, le VPS doit pouvoir communiquer avec l’extérieur : d’une part, pour pouvoir être configuré par vous-mêmes, et d’autre part, pour effectuer les services requis. On veillera donc à sécuriser, par une authentification et un chiffrement adéquat, toutes les communications.

Sur les données

Les données hébergées par votre VPS sont de deux types :

Les données de configuration des services, qui vous seront nécessaires pour démontrer vos réalisation dans le cadre du processus d’évaluation. Il importe que ces configurations restent disponibles et ne soient pas modifiées, pour que les services puissent tourner comme prévu.
Les données des services hébergés par vos VPS : données liées aux sites web, messages email des utilisateurs, … Même si, dans le cadre des labos, ces données sont fictives, il est essentiel de prendre l’habitude de les protéger en priorité. En plus des deux points mentionnés plus haut, il faudra également ici garantir la confidentialité : la fuite de mots de passe utilisateurs ou du contenu de leurs emails est une menace majeure!
Sur les services

Certains éléments liés au services tournant sur le VPS ont déjà été analysés au travers des deux points précédents, au niveau des vulnérabilités logicielles et au niveau des données. Il reste encore un aspect non pris en compte, concernant les communications : il importe que les services restent accessibles autant que possible aux utilisateurs. Or, une menace courante est l’attaque par déni de service : en submergeant un service de requêtes ou de messages, un attaquant peut le rendre indisponible.

Analyse des risques

Nous allons à présent reprendre les menaces identifiées plus haut et en déduire les risques qui en découlent.

#	Menace	Probabilité	Impact	Estimation du risque	Contre-mesures
1	Indisponibilité du VPS suite à un problème chez le fournisseur (implique également #5 et #6)	Faible	Très élevé : Les services et données sont inaccessibles et éventuellement irrécupérables	Moyen	- VPS de backup chez un autre fournisseur et plan de basculement d’urgence - Backups des config et données
2	Exploitation de faille dans le système d’exploitation	Fort	Fort : Possibilité de gain d’accès root à la machine => fuite de données, risque d’indisponibilité, de détournement, …	Fort	- Mises à jour fréquentes du système d’exploitation
3	Exploitation de faille dans les logiciels applicatifs.	Fort	Fort : Idem que pour #2	Fort	- Mise à jour des logiciels - Suppression des logiciels non utilisés
4	Accès non autorisé sur le VPS à cause d’une vulnérabilité d’authentification ou d’une attaque brute-force	Fort	Fort : accès à un utilisateur non privilégié, voire root sur la machine	Fort	- Supprimer l’accès distant à l’utilisateur root - Utiliser de l’authentification forte (mot de passe fort, par clé, ou MFA) - Utiliser un service de prévention d’intrusion comme Fail2Ban
5	Perte des configurations du VPS	Moyen	Assez fort dans le cadre du cours : vous perdez tout votre travail	Moyen	- Backup des données, par ex. sur un repo Github.
6	Perte des données utilisateurs (services)	Fort	Faible dans le cadre de ce cours, très élevé dans une situation réelle.	Faible / Fort selon la situation	- Backup des données
7	Fuite des données utilisateurs (services)	Fort	Faible dans le cadre de ce cours, très élevé dans une situation réelle.	Faible / Fort selon la situation	- Chiffrement des communication - Politique d’authentification forte
8	Indisponibilité d’un service à cause d’une attaque par déni de service	Fort	Fort	Fort	- Infrastructure anti-ddos chez le fournisseur du VPS.

Cette analyse de risques nous donne une “todo-list” à réaliser pour sécuriser votre VPS. Vous constaterez qu’elle est assez proche de ce qui est préconisé sur le site du fournisseur du VPS.

4.3.2. Détails des contre-mesures

Préparation d’un basculement en urgence chez un autre fournisseur

Imaginons que, la veille d’une grosse évaluation, le fournisseur de VPS tombe en panne.

Il n’y a pas vraiment de contre-mesure qui permette de se prémunir contre cette menace de manière proactive, à moins de louer un second VPS chez un autre fournisseur et de s’assurer qu’il est, à tout moment, configuré de manière identique au premier. Dans le contexte du cours, cette contre-mesure est clairement superflue. Il vous reste donc à prévoir une procédure de réaction en cas d’attaque, à savoir un “Disaster Recovery Plan”. Vous pouvez réfléchir aux éléments suivants :

De quoi auriez-vous besoin comme documentation pour pouvoir rétablir le bon fonctionnement de votre VPS et de ses services?
Combien de temps vous faudra-t’il pour rétablir le fonctionnement des services (Recovery Time Objective) ? Est-il suffisant pour être prêt pour l’évaluation? Comment pourriez-vous le raccourcir (ex : automatisation) ?

Backup des données et config

Les risques #1, #5 et #6 nous indiquent la nécessité de mettre en place des backups pour sauvegarder les données et les configurations. Il reste à déterminer où stocker les backup, et à quelle fréquence les réaliser.

Pour l’endroit : un lieu de stockage découplé du stockage primaire est recommandé.

Pour les configurations, un repository Github est une bonne idée dans le cadre de ce cours : il vous servira comme outil de versionning des configs en plus que comme sauvegarde… et vous devrez de toute façon en utiliser un pour mettre vos configs à disposition des enseignants dans le cadre de l’évaluation.
Pour les données, il faut mettre en place un script de sauvegarde automatisé à destination d’un lieu de stockage séparé. Il peut s’agir d’une copie sur un de vos ordinateurs persos, ou d’une copie dans un dossier en ligne chez un autre fournisseur que le fournisseur primaire.

Pour la fréquence, dans le cas des configurations, avec l’utilisation d’un repo Github, la question ne se pose pas : si vous travaillez systématiquement en pushant vos configs sur Github puis en effectuant des git pull depuis votre VPS, vous êtes assurés d’avoir toujours une copie de vos configs sur le repo.

Pour le backup des données, on peut partir de la notion de RPO : Recovery Point Objective. Quelle est la quantité/durée de données acceptable ? Par exemple, si on accepte de perdre maximum une heure de données client, il faudra effectuer des backups de manière horaire. Dans votre situation, avec des données fictives, votre objectif ne sera bien entendu pas très élevé.

Mises à jour des logiciels

La contre-mesure principale pour éviter les vulnérabilités logicielles #2 et #3 est de mettre à jour l’OS et les logiciels fréquemment. Sous Linux, cela s’effectue simplement :

apt update
apt upgrade

Attention que ces mises à jour doivent être répétées régulièrement pour que cela ait du sens. Une fréquence hebdomadaire est probablement raisonnable dans le cadre des labos. Attention néanmoins de vous assurez que vos backup soient à jour en cas de souci de mise à jour!

Suppression des logiciels superflus

Pour limiter le nombre de failles logicielles dans les applicatifs (#3), l’idéal est encore… d’éviter les applicatifs. La suppression des logiciels et services superflus est une étape importante de la sécurisation du serveur.

Pour détecter les logiciels qui tournent sur votre serveur ou sont à l’écoute sur un port public, utilisez les outils classiques ps,netstat et nmap. Le gestionnaire de services systemd peut également vous indiquer les éléments qu’il contrôle avec systemctl list-units. N’oubliez pas que, pour supprimer un service de systemd, il faut l’arrêter mais également le désactiver (systemctl disable <unit>) pour éviter qu’il redémarre automatiquement au démarrage.

Authentification forte

Pour ce qui concerne les accès aux VPS (menace #4), ils s’effectuent a priori uniquement via ssh(à moins que vous n’ayez l’idée saugrenue d’installer et d’utiliser telnet… ). SSH permet le chiffrement des communications, mais également l’authentification à la fois du serveur et du client. Pour cette dernière, néanmoins, différentes authentifications sont possibles, et certaines sont moins robustes que d’autres (ex : mot de passe). Or, en cas de franchissement du contrôle d’accès, un attaquant peut exploiter un compte utilisateur sur le système, voire carrément le compte root.

Il est donc recommandé de configurer son serveur SSH de la manière suivante :

Désactivation de l’accès SSH à l’utilisateur root (il faut d’abord se connecter avec un utilisateur non privilégié, puis effectuer une élévation de privilège)
Activation de l’authentification SSH par clé plutôt que par mot de passe (cfr chapitre suivant)
Désactivation de l’authentification par mot de passe (assurez-vous au préalable que l’étape précédente est validée, au risque de perdre complètement l’accès au VPS! )

Pour l’authentification liée aux services, cela devra s’effectuer au cas par cas, lors de leur mise en place. Nous n’en parlerons pas ici.

Utilisation de Fail2Ban

Une authentification forte permet de limiter les attaques sur l’authentification. Un autre outil complémentaire pour limiter certains types d’attaque (brute-force) est Fail2Ban. Cette application se base sur l’analyse des logs des services pour identifier des tentatives de connexion répétées, identifier l’IP source et la bannir pour interrompre l’attaque. Il peut être utilisé avec différents services comme SSH, FTP, Apache,…

Fail2Ban est clairement indiqué pour la sécurisation de votre VPS, en commençant par le service SSH. Vous pourrez rajouter ultérieurement d’autres services à sa configuration.

Chiffrement des échanges

Pour garantir la confidentialité des échanges de données (menace #7), il faut se baser sur le chiffrement des communications. Pour votre accès distant, SSH fournit normalement un chiffrement adéquat. Pour les autres communications, il faudra que vous configuriez par vous-même le chiffrement des communications propre à chaque service, généralement en utilisant TLS. Dans le cadre des services Web, cela signifie la mise en oeuvre du HTTPS, avec des certificats adéquats. Nous y reviendrons.

Prévention des DoS

La lutte contre les attaques par déni de service n’est pas simple. Fail2Ban est déjà une première barrière intéressante, mais néanmoins, en cas d’attaque par déni de service distribué (DDoS), il ne pourra vraisemblablement pas détecter et bannir toutes les sources d’attaque. La mitigation des DDoS doit en général se faire au niveau des fournisseurs d’accès. Dans le cas de notre VPS, nous nous reposerons donc sur l’infrastructure anti-DDoS fournie par le fournisseur.

4.3.3. Gestion de la sécurité sur le long terme

En plus de la mise en place des contre-mesures de sécurité ci-dessus dès le début du semestre, il faudra vous assurez, de manière régulière, du bon fonctionnement des contre-mesures mises en place.

En plus des tâches récurrentes déjà identifiées plus haut :

les mises à jour logicielles régulières,
les backups de données (idéalement automatisées),

il vous faudra penser régulièrement à faire une vérification rapide de l’état de votre VPS :

Vérification des logs,
Vérification qu’il n’y a pas de service ou de logiciel superflu qui tourne, ou de port ouvert à mauvais escient (systemctl, ps, netstat, nmap, …),
Vérification de l’état du système (normalement affiché lorsque vous vous connectez) : espace disque, mémoire, CPU, …
…

Assurez-vous également de bien documenter (par ex. sur le wiki de votre repo) toutes vos procédures et configuration, afin de pouvoir les appliquer en cas de souci.