Aller au contenu

(Cours/TP) Sécurisation du poste de travail

Programme

Jour 1

  • Passage du MOOC secnumacademie.gouv.fr de l'ANSSI : durée estimée de 6 à 8 heures (autonome ou semi-accompagné).

  • Retour d'expérience et échanges (en fin de journée ou début J2)

Jour 2

1) Débrief du MOOC et présentation récapitulative

  • Rappel des bonnes pratiques utilisateurs (mises à jour, MFA, vigilance) et introduction des bonnes pratiques côté infrastructure (limiter la surface d'attaque, chiffrement, moindre privilège, etc.).

  • Présentation des outils de sécurité (Antivirus, Pare-feu, Proxy inversé, EDR, IDS) et des principes clés (Zero Trust, Minimisation, Principe de Moindre Privilège, CID, Chiffrement, Journalisation, Sauvegarde 3-2-1).

2) Présentation du TP et contexte

  • Objectif : mettre en oeuvre concrètement les concepts (durcissement Windows, LUKS, SFTP chiffré, sauvegardes Restic, etc.).

  • Environnement : une VM Windows (poste de travail) et une VM Debian (sans GUI).

3) TP Sécurisation

  • Mise en pratique progressive : mises à jour, GPO Windows, chiffrement BitLocker, test antivirus EICAR, MFA, configuration d'un volume chiffré LUKS, gestion des permissions Linux, durcissement SSH, mise en place d'un serveur SFTP chiffré, sauvegardes Restic en local et vers S3, et pistes pour aller plus loin (Wazuh, Crowdsec, Lynis).

Cette progression permet de partir des bases (sécurisation du poste de travail) pour aller vers des configurations plus avancées, tout en consolidant les notions du MOOC.

Cours / présentation (slides)

Bonnes pratiques essentielles côté utilisateur

  • Utiliser des mots de passe complexes et uniques : évitez les mots de passe réutilisés ou simples à deviner, utilisez des gestionnaires de mots de passe et activez des facteurs d'authentification supplémentaires (2FA/MFA).

  • Maintenir ses postes à jour : installez régulièrement les mises à jour OS et applicatives.

  • La faille est humaine : soyez vigilant face au phishing et l'ingénierie sociale.

  • Attention dans les lieux publics / verrouiller son poste de travail : espionnage par le WiFi, clé USB, borne de recharge...

  • Ne partagez pas les secrets n'importe comment !

Système d'Information (SI)

  • Définition : un Système d'Information regroupe l'ensemble des ressources (humaines, matérielles, logicielles, données) nécessaires à la production, au traitement, à la gestion et à la circulation de l'information au sein d'une organisation. L'informatique occupe une place centrale dans le SI.

  • Objectif : soutenir les activités de l'entreprise, faciliter la prise de décision, améliorer l'efficacité des processus et assurer une disponibilité et une fiabilité maximales de l'information.

  • Enjeu Sécurité : protéger l'intégrité, la confidentialité et la disponibilité des données et des services offerts par le SI est essentiel face aux cybermenaces et aux risques internes.

Principe CID + A +T

Pourquoi CID + A + T ? Parce que la Confidentialité/Intégrité/Disponibilité protège l'information, l'Authenticité protège l'identité et la Traçabilité permet de détecter, enquêter et prouver.

  • Confidentialité : assurer que seules les personnes autorisées peuvent accéder aux informations.

  • Intégrité : garantir que les données n'ont pas été altérées ou falsifiées.

  • Disponibilité : veiller à ce que les données et les ressources informatiques soient accessibles lorsque nécessaires.

  • Authenticité : s'assurer de l'identité réelle d'un utilisateur, d'un système ou d'un service (comptes séparés admin/user, clés SSH, certificat TLS, etc.)

  • Traçabilité : savoir qui a fait quoi, quand et comment > les LOG !

Objectif : le modèle CID est un pilier fondamental de la sécurité de l'information, assurant que les actifs numériques sont protégés contre l'accès non autorisé, les modifications malveillantes et les interruptions de service.

Sauvegarde 3-2-1

  • Principe : conserver plusieurs copies de vos données pour assurer leur disponibilité et intégrité en cas d'incident.

  • Règle 3-2-1 :

3 copies de vos données au minimum ;

2 types de supports différents, les deux supports doivent être de technologies différentes pour éviter une défaillance commune (disques durs, NAS, SFTP, S3, bande, etc.) ;

1 copie hors-site (stockée dans un autre lieu physique ou dans le cloud).

  • Objectif : réduire le risque de perte totale en cas de sinistre (panne matérielle, vol, ransomware), garantir la résilience et faciliter la restauration rapide.

Principes fondamentaux de sécurité côté infrastructure

💡 Fil rouge pour toute cette partie : imaginez votre SI comme le siège d'une entreprise à sécuriser avec ses portes, ses badges, ses coffres, ses caméras, son PC sécurité. Chaque principe et chaque outil qui suit y trouve sa place, à la fin, vous aurez le plan complet du bâtiment. Exercice de synthèse possible en fin de TP : replacer chaque manipulation réalisée dans ce bâtiment !

Chiffrement (données et connexions)

  • Principe : protéger la confidentialité et l'intégrité des données en les rendant inexploitables sans la clé de chiffrement, qu'elles soient stockées ou en transit.

  • Objectif : empêcher la lecture ou la modification des données en cas de vol de matériel, d'intrusion ou d'interception réseau.

  • Exemple(s) d'application : les postes de travail et les serveurs stockent leurs données chiffrées (BitLocker, LUKS) et toutes les applications utilisent des connexions sécurisées (HTTPS/TLS, SSH) pour les échanges.

Analogie : le bâtiment

Les documents sont rangés dans des coffres-forts et le courrier interne circule sous pli scellé. Même un cambrioleur qui emporte tout repart avec des coffres qu'il ne peut pas ouvrir et des lettres qu'il ne peut pas lire.

Dans le TP

Les fichiers sont chiffrés avec BitLocker (Windows) et LUKS (Linux). Les transferts et sauvegardes passent par SFTP (SSH) et Restic, donc sont chiffrés sur le réseau.

Limitation de la surface d'attaque

  • Principe : réduire le nombre de services, ports, ressources numériques et physiques exposées afin de limiter les points d'accès potentiels.

  • Objectif : rendre plus difficile l'exploitation de failles en limitant les possibilités d'entrée pour un attaquant.

  • Exemple(s) d'application : fermer les ports non utilisés via le pare-feu et restreindre l'accès aux seuls services indispensables. Par exemple, un serveur web est placé derrière un reverse-proxy qui n'expose que les ports 80/443 et redirige le trafic, tandis que les services internes sont inaccessibles directement depuis Internet.

Analogie : le bâtiment

On mure les portes et fenêtres inutilisées, une porte verrouillée peut toujours être forcée, une porte murée n'existe plus. Moins il y a d'ouvertures, moins il y a de points à surveiller et à défendre.

Dans le TP

Le serveur Debian de sauvegarde n'expose que le port 2299 (SSH/SFTP) via le firewall UFW, tous les autres ports sont fermés.

Principe de Moindre Privilège

  • Principe : n'accorder aux utilisateurs, services et applications que les droits strictement nécessaires à leurs tâches.

  • Objectif : limiter l'impact d'une compromission en empêchant l'exploitation de privilèges excessifs.

  • Exemple(s) d'application : un technicien support peut réinitialiser des mots de passe, mais ne peut ni créer de comptes administrateurs ni accéder aux bases de données de production.

Analogie : le bâtiment

Le badge de chaque employé n'ouvre que les portes de son service, pas celles de la comptabilité ni de la salle des coffres. Si un badge est volé, le voleur reste cantonné à un périmètre limité.

Dans le TP

L'utilisateur travaille avec un compte standard et utilise un compte administrateur uniquement pour les actions nécessitant une élévation de privilèges.

Le Modèle Zero Trust

  • Principe : ne faire confiance à aucun utilisateur, appareil ou réseau par défaut, même à l'intérieur du SI. Le réseau interne et le VPN ne sont pas considérés comme des preuves de confiance.

  • Objectif : vérifier systématiquement l'identité, le contexte et les droits avant d'autoriser un accès quel que soit l'emplacement, l'appareil ou l'utilisateur. Qui ? Où ? Avec quoi ? Comment ?

  • Exemple(s) d'application : utiliser un fournisseur d'identité (IdP) avec 2FA/MFA et demander une validation systématique de l'identité lors de l'accès à une application interne.

Analogie : le bâtiment

On vérifie le badge à chaque porte, même pour le PDG, même s'il est déjà à l'intérieur, être entré dans le bâtiment ne prouve rien. (Limite de l'analogie : le " badge" Zero Trust vérifie aussi l'état de l'appareil et le contexte de connexion, pas seulement l'identité.)

Dans le TP

L'accès au compte Microsoft ou Google nécessite un MFA même depuis le poste de travail habituel.

Le Principe de Minimisation

  • Principe : n'utiliser et n'exposer que le strict nécessaire en termes de données, services, comptes et logiciels.

  • Objectif : réduire la surface de compromission et l'impact potentiel d'une attaque.

  • Exemple(s) d'application : les comptes inactifs sont supprimés et seules les applications nécessaires aux métiers sont installées sur les serveurs et les postes.

Analogie : le bâtiment

Un bureau vide ne peut pas être cambriolé, moins on stocke de dossiers, moins on garde de badges en circulation et moins on installe d'équipements, moins il y a à voler ou à saboter.

Dans le TP

SMBv1, LLMNR et les services Windows inutiles sont désactivés.

Traçabilité et journalisation

  • Principe : enregistrer et conserver les événements de sécurité afin de pouvoir reconstituer les actions effectuées sur le système.

  • Objectif : détecter les incidents, enquêter, prouver les actions et améliorer la sécurité.

  • Exemple(s) d'application : un SIEM centralise les logs des serveurs, pare-feu et applications afin d'identifier des comportements anormaux.

Analogie : le bâtiment

Le registre des entrées et les caméras : on ne bloque pas forcément, mais on peut toujours reconstituer qui est entré, quand, et ce qu'il a fait. Sans eux, impossible d'enquêter après un incident.

Dans le TP

Wazuh peut centraliser les logs (via ses agents ou Syslog) et Crowdsec détecte et bloque les comportements malveillants

Cloisonnement et segmentation

  • Principe : séparer les systèmes et les réseaux afin d'empêcher la propagation d'une compromission.

  • Objectif : limiter l'impact d'une attaque à une seule zone du SI.

  • Exemple(s) d'application : les serveurs et postes utilisateurs sont placés dans des réseaux distincts avec des règles de filtrage entre eux.

Analogie : le bâtiment

Les portes coupe-feu entre les ailes du bâtiment : un incendie qui se déclare dans un bureau ne consume pas tout l'immeuble. Chaque zone brûle ou est compromise seule.

Les outils de sécurité

Antivirus

  • Principe : analyse les fichiers et la mémoire du système à la recherche de logiciels malveillants (virus, trojans, ransomwares).

  • Objectif : prévenir, détecter et éliminer les menaces connues (base de signature) ou suspectes (analyse comportementale/heuristique) afin de protéger la machine et ses données.

  • Outil(s) FOSS : ClamAV (moteur antivirus pour Linux, Windows, macOS).

Analogie : le bâtiment

L'agent de sécurité qui patrouille dans les couloirs avec le trombinoscope des malfaiteurs connus (base de signatures) et du flair pour repérer les comportements louches, même sans photo (analyse heuristique/comportementale).

Firewall (Pare-feu) & WAF (Web Application Firewall)

  • Principe Pare-feu : filtrer le trafic réseau entrant et sortant selon des règles prédéfinies, bloquant les flux non autorisés.

  • Principe WAF : protéger les applications web en filtrant les requêtes HTTP(S) pour détecter et bloquer les attaques ciblant les vulnérabilités applicatives.

  • Objectif : réduire la surface d'attaque réseau et applicative, contrôler l'accès et empêcher les intrusions.

  • Outil(s) FOSS: iptables/UFW (Linux).

Analogie : le bâtiment

Le pare-feu est le portier à l'entrée qui filtre selon la liste d'invités : bonne porte, bon motif, sinon demi-tour. Le WAF est le vigile du guichet : il laisse entrer les visiteurs admis, mais vérifie en plus ce qu'ils disent au guichet pour bloquer les demandes piégées (injections, requêtes malveillantes).

Reverse proxy (proxy inversé)

  • Principe : agit comme point d'entrée unique entre le client et le serveur, réceptionnant les requêtes avant de les transmettre aux serveurs internes.

  • Objectif : principe de minimisation, améliore les performances (mise en cache), répartit la charge, sécurise l'accès (certificats TLS, authentification) et masque la topologie interne.

  • Outil(s) FOSS : Nginx (serveur web et proxy inversé largement utilisé ou Traefik pour une approche plus dynamique).

Analogie : le bâtiment

L'accueil unique : les visiteurs ne circulent jamais dans les bureaux. L'hôtesse réceptionne chaque demande, la transmet au bon service et rapporte la réponse, personne à l'extérieur ne connaît le plan du bâtiment ni le nombre de bureaux derrière.

EDR (Endpoint Detection & Response) & XDR (Extended Detection & Response)

  • Principe et objectif EDR : Surveille et analyse l'activité des endpoints (postes, serveurs) pour détecter et contrer les menaces. Offre des capacités de réponse rapide (isolation de machine, quarantaine de fichier malveillant, arrêt de processus).

  • Évolution en XDR : Un XDR étend ce concept aux réseaux, applications, identités, et autres couches.

  • Outil(s) FOSS : Wazuh. À proprement parler, Wazuh n'est pas un EDR mais une plateforme SIEM/XDR open source, héritière du HIDS OSSEC. Via ses agents, elle offre des capacités proches d'un EDR avec surveillance d'intégrité des fichiers (FIM), détection de vulnérabilités, évaluation de configuration (SCA), réponse active (blocage d'IP, arrêt de processus) sans toutefois égaler la télémétrie comportementale fine des EDR commerciaux (CrowdStrike, SentinelOne, Defender for Endpoint...).

Analogie : le bâtiment

Un garde posté dans chaque bureau (l'agent sur chaque endpoint), capable de verrouiller la pièce s'il détecte une intrusion. Le XDR, c'est la coordination radio de tous les gardes avec les caméras et les alarmes : un incident vu depuis plusieurs angles à la fois.

IDS (Intrusion Detection System) & IPS (Intrusion Prevention System)

  • Principe et objectif IDS : Surveiller le trafic réseau ou les journaux système d'un hôte pour détecter des comportements anormaux. Identifier précocement les tentatives d'intrusion afin d'alerter l'équipe de sécurité, faciliter la réaction rapide (i.e. bannir l'IP, envoyer un captcha, bloquer l'action) et documenter l'attaque.

  • Un IDS détecte et alerte principalement.

  • Un IPS détecte et bloque activement les menaces.

  • Outil(s) FOSS : Snort, Suricata, Fail2ban et Crowdsec.

Analogie : le bâtiment

Le détecteur de mouvement : l'IDS déclenche l'alarme et prévient le PC sécurité (détection + alerte). L'IPS verrouille en plus automatiquement les issues (détection + blocage).

SIEM (Security Information & Event Management)

  • Principe : centralise et analyse les logs issus de multiples sources (serveurs, pare-feux, applications, EDR, IDS...) afin de détecter des menaces ou comportements anormaux.

  • Objectif : fournir une visibilité globale sur l'infrastructure, faciliter la corrélation d'événements et l'investigation des incidents, permettre une amélioration continue.

  • Outil(s) FOSS: Toujours Wazuh et c'est là son véritable coeur de métier !

Analogie : le bâtiment

Le PC sécurité central où convergent toutes les caméras, alarmes, registres et rapports des gardes. L'opérateur y croise les signaux, "un badge refusé au 3ème étage + une fenêtre ouverte au 2ème, à deux minutes d'intervalle", chaque événement est anodin isolément, c'est la corrélation qui révèle l'intrusion.

Transition vers le TP

Maintenant que nous avons revu ces concepts et bonnes pratiques, nous allons les mettre en application via un TP. Vous explorerez la configuration sécurisée d'une infrastructure (chiffrement, pare-feu, sauvegardes chiffrées, etc.). L'objectif est de passer de la théorie à la pratique en tirant parti de l'apprentissage du MOOC et en l'appliquant à des scénarios concrets sur nos VM Windows et Linux.

TP

Contexte et Objectifs

Vous disposez de deux machines virtuelles :

  • VM Windows 10/11 Pro

  • VM Debian (sans GUI)

Le but est de :

  • Maintenir le poste de travail à jour.
  • Tester et durcir la sécurité du poste de travail Windows (GPO, antivirus, BitLocker).
  • Mettre en place l'authentification forte (MFA) sur un service cloud.
  • Gérer les permissions et le chiffrement (LUKS) sur Linux.
  • Sécuriser le serveur Debian (pare-feu UFW, durcissement SSH...).
  • Installer un serveur SFTP chiffré et réaliser des sauvegardes selon la méthode 3-2-1 via l'outil Restic depuis Windows. Sauvegarder vers un Cloud S3 (Optionnel).
  • Aller plus loin en pratiquant des solutions VPN Zero Trust (Wireguard), SIEM/XDR (Wazuh), IDS (Crowdsec) et d'audit de sécurité (Lynis).

Etape 1 : Mises à jour de l'OS

Objectif : réduire les risques d'exploitation de vulnérabilités connues en maintenant les systèmes à jour.

Windows

1) Ouvrez Paramètres > Mise à jour et sécurité et appliquez les mises à jour.

2) Redémarrez si nécessaire.

Linux (Debian)

1) Mettez à jour le système : 

apt update
apt upgrade -y

2) Redémarrez la VM si un nouveau noyau est installé.

Cette première étape garantit une base logicielle à jour, réduisant le risque de vulnérabilités connues.

💡 Pourquoi commencer par là ? Parce que la majorité des attaques réussies exploitent des failles déjà connues et déjà corrigées par les éditeurs. Un système à jour ferme gratuitement des portes que les attaquants testent en premier.

Interro
  • Une mise à jour protège-t-elle contre une faille "zero-day" ? Pourquoi ?

Etape 2 : Gérer les politiques locales Windows (GPO locales) pour limiter les privilèges et renforcer la sécurité.

Objectif : encadrer les comportements utilisateurs et limiter les privilèges afin de réduire les erreurs humaines et l'impact d'une compromission, conformément au principe de moindre privilège.

💡 Une GPO (stratégie de groupe) est un ensemble de règles que Windows applique automatiquement à la machine et aux utilisateurs : c'est le règlement intérieur du poste. Ici nous travaillons sur les GPO locales d'un poste isolé ; en entreprise, ces mêmes règles sont déployées de façon centralisée sur tout le parc via Active Directory.

1) Ouvrez l'outil Éditeur de stratégie de groupe locale gpedit.msc.

2) Définir une politique de mot de passe stricte (complexité et longueur minimale) : Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies de comptes > Stratégie de mot de passe.

3) Activer une bannière d'avertissement de sécurité au démarrage : Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité > Ouverture de session interactive : titre du message pour les utilisateurs essayant de se connecter et Ouverture de session interactive : contenu du message pour les utilisateurs essayant de se connecter.

4) Configurer le principe de moindre privilège en créant un compte utilisateur standard et en testant qu'il ne peut pas installer d'applications ou modifier les paramètres système sans demande d'élévation.

Interro
  • Quelle différence y a-t-il entre une GPO locale et une GPO de domaine ? Laquelle rencontrerez-vous le plus souvent en entreprise, et pourquoi ?

Etape 3 : Principe de limitation de la surface d'attaque sur le poste de travail Windows

Objectif : diminuer le nombre de points d'entrée exploitables en désactivant les services et fonctionnalités inutiles ou dangereuses, conformément au principe de limitation de la surface d'attaque.

💡 Chaque service actif est une porte de plus dans le bâtiment : même verrouillée, elle peut être forcée. Un service désactivé, c'est une porte murée : elle ne peut plus être attaquée du tout.

1) Désactiver les application/fonctionnalités Windows non utilisées, dangereuses (e.g. LLMNR / NetBios) ou obsolètes (e.g. SMBv1).

2) Vérifier que seuls les services indispensables au fonctionnement du poste sont activés (via services.msc), désactiver au moins deux services inutiles.

Ce n'est pas de la théorie : l'histoire de WannaCry

En mai 2017, le ransomware WannaCry a paralysé en quelques jours des centaines de milliers de machines dans 150 pays : hôpitaux britanniques contraints d'annuler des opérations, usines Renault à l'arrêt, entreprises bloquées... Son vecteur de propagation ? Une faille de SMBv1, un protocole obsolète encore activé par défaut sur d'innombrables postes, alors que le correctif Microsoft existait depuis deux mois.

Deux gestes de ce TP auraient suffi à s'en protéger : appliquer les mises à jour (étape 1) et désactiver les protocoles obsolètes (cette étape).

Interro
  • Pourquoi désactive-t-on SMBv1 alors qu'il "fonctionne encore" très bien pour partager des fichiers ?

Etape 4 : Test de l'antivirus sur Windows (EICAR)

Objectif : vérifier l'efficacité des mécanismes de détection afin de garantir l'intégrité du poste de travail face aux logiciels malveillants.

C'est quoi EICAR ?

EICAR est une chaîne de caractères totalement inoffensive, définie par un standard de l'industrie : tous les éditeurs d'antivirus se sont engagés à la détecter comme s'il s'agissait d'un virus.

C'est l'équivalent d'un faux colis suspect utilisé pour tester un portique de sécurité : le portique doit sonner, sans qu'il y ait le moindre danger réel. Cela permet de valider qu'un antivirus est actif et fonctionnel sans jamais manipuler de vrai malware.

1) Renseignez la chaine de caractères suivante sur la première ligne d'un fichier de texte X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* et sauvegardez le sous eicar.com.

2) Windows Defender devrait immédiatement détecter le fichier et le mettre en quarantaine.

3) Vérifiez l'efficacité de l'antivirus. Vous pouvez consulter le détail de la détection dans Sécurité Windows > Protection contre les virus et menaces > Historique de protection.

Etape 5 : Chiffrement des données sur Windows avec BitLocker

Objectif : assurer la confidentialité des données stockées localement afin qu'elles restent inexploitables en cas de vol ou de perte du matériel.

💡 Sans chiffrement, un attaquant qui vole un disque (ou démarre le poste sur une clé USB) lit toutes les données, quel que soit le mot de passe de session Windows. Le mot de passe protège la session, pas le disque. Le chiffrement, lui, rend le disque illisible sans la clé.

1) Après avoir ajouté un disque à votre VM Windows, créez un volume sur la VM Windows Z:.

2) Activez BitLocker sur ce volume.

3) Sauvegardez la clé de récupération.

4) Placez des fichiers sensibles sur ce volume Z: dans le répertoire z:\data\

Etape 6 : Chiffrement d'un volume sur Linux avec LUKS

Objectif : protéger durablement les données du serveur par le chiffrement, garantissant la confidentialité même en cas d'accès non autorisé au support de stockage.

💡 LUKS est l'équivalent Linux de BitLocker. Pour visualiser la suite, le fichier conteneur est un coffre-fort, cryptsetup open revient à composer la combinaison (le coffre se déverrouille), le montage revient à ouvrir la porte pour accéder au contenu, et démonter + fermer le volume revient à refermer le coffre. Sans la combinaison, son contenu n'est plus qu'une masse de données illisibles.

Prérequis : S'assurer que cryptsetup est installé 
apt install -y cryptsetup

1) Créez un fichier conteneur (un "disque virtuel") :

Adaptez la taille à vos besoins. Ici, 500 Mo en exemple.

dd if=/dev/urandom of=/srv/sftp_volume.img bs=1M count=500
Cette commande crée un fichier rempli d'entropie aléatoire, ce qui rend le chiffrement plus sûr.

Alternative

Vous pouvez ajouter un disque à votre VM plutôt que d'utiliser un fichier conteneur. Dans ce cas, vous utiliserez le point de montage de votre disque que vous aurez préalablement formaté (ex. /dev/sdb1)

2) Initialisez LUKS sur ce fichier : 

cryptsetup luksFormat /srv/sftp_volume.img

Confirmez et entrez un mot de passe solide lorsque demandé.

3) Ouvrez le volume chiffré : 

cryptsetup open /srv/sftp_volume.img sftp_luks

Entrez le mot de passe défini précédemment. Un périphérique mappé apparaît dans /dev/mapper/sftp_luks. Linux crée automatiquement un périphérique virtuel lorsqu'un volume chiffré est déverrouillé. Le répertoire /dev représente les périphériques du système (réels ou virtuels) et n'est pas destiné à stocker des données. Nous allons donc formater ce périphérique (étape 4) puis le monter dans le répertoire /mnt/sftp_luks afin de rendre les données accessibles (étape 5).

4) Formatez le périphérique virtuel

mkfs.ext4 /dev/mapper/sftp_luks

5) Montez le volume : 

mkdir /mnt/sftp_luks
mount /dev/mapper/sftp_luks /mnt/sftp_luks

Vérifiez l'accès :

ls -l /mnt/sftp_luks

Vous devriez obtenir un répertoire vide prêt à accueillir des données chiffrées.

6) Pour démonter et fermer le volume : 

umount /mnt/sftp_luks
cryptsetup close sftp_luks

À ce stade, vous avez un conteneur chiffré fonctionnel. Ce volume sera réouvert et monté avant la création du serveur SFTP (Étape 10).

Montage automatique
  • Ajouter cette ligne au fichier /etc/fstab pour un montage automatique au démarrage de la machine :
/dev/mapper/sftp_luks /mnt/sftp_luks ext4 defaults,nofail,x-systemd.device-timeout=10 0 2
  • Ajoutez une entrée dans /etc/crypttab pour déverrouiller le disque chiffré au démarrage de la machine : 
sftp_luks /srv/sftp_volume.img none luks
Interro
  • Question piège : BitLocker et LUKS protègent-ils vos données contre un ransomware qui s'exécute pendant que votre session est ouverte et le volume monté ? Contre quoi protègent-ils exactement ?

Etape 7 : Authentification forte (MFA)

Objectif : renforcer l'authenticité des accès aux services cloud en ajoutant un facteur d'authentification supplémentaire au-delà du mot de passe et appréhender l'usage d'une application d'authentification.

💡 Le MFA combine plusieurs natures de preuves : quelque chose que vous savez (mot de passe), que vous possédez (smartphone) ou que vous êtes (biométrie). Un mot de passe volé par phishing ne suffit alors plus à l'attaquant, il lui manque le second facteur.

1) Sur un compte cloud Microsoft, Google ou autre que vous possédez, activez la double authentification.

2) Installez l'application 2FAS sur votre smartphone.

3) Scannez le code QR et testez la connexion.

4) Générez des codes de secours et stockez les dans votre gestionnaire de mot de passe (e.g. Keepass, Passbolt).

Interro
  • Lors d'un phishing classique, quel facteur d'authentification l'attaquant vole-t-il ? Lequel lui échappe grâce au MFA ?

Etape 8 : Gestion des droits et permissions sur Linux

Objectif : appliquer le principe de moindre privilège en contrôlant finement les accès aux ressources afin de limiter l'impact d'une erreur ou d'un compte compromis.

1) Créez un répertoire sensible : 

mkdir /srv/data
Donnez-lui un accès restreint au propriétaire uniquement : 

chmod 700 /srv/data

Avec chmod 700, seul le propriétaire a les droits de lecture, d'écriture et d'exécution.

💡 Sur un répertoire, le droit d'exécution (x) a un sens particulier, c'est le droit d'entrer dans le répertoire pour en atteindre le contenu. C'est pourquoi 700 (et non 600) est le réglage habituel pour un répertoire privé, sans le x, même son propriétaire ne pourrait plus y accéder.

1) Testez l'accès avec un utilisateur non autorisé.

Créez un utilisateur de test (sans privilèges) : 

adduser user-test

Changez d'utilisateur : 

su - user-test

Essayez d'accéder au répertoire /srv/data : 

ls /srv/data

Vous devriez avoir un message "Permission denied".

Repassez en utilisateur root ou sudo :

su -

3) Ajustez le propriétaire et les permissions (chown, chmod)

Changez le propriétaire du répertoire : 

chown user-test:user-test /srv/data

Désormais, user-test est propriétaire du répertoire.

Conservez les permissions restreintes au seul propriétaire : 

chmod 700 /srv/data
Maintenant, seul le propriétaire (user-test) pourra lire, écrire et entrer dans le répertoire, et personne d'autre n'y aura accès (à l'exception de root, qui n'est pas concerné par les permissions classiques).

Vérifiez l'effet de ces changements :

ls -ld /srv/data
Vous verrez un détail des permissions, du propriétaire et du groupe.

Grâce à ces manipulations, vous comprenez comment les permissions (chmod), le propriétaire et le groupe (chown) permettent de mettre en oeuvre le principe de moindre privilège, garantissant que chaque utilisateur n'a accès qu'aux ressources dont il a besoin.

Interro
  • Pourquoi root n'est-il pas concerné par un chmod 700 ? Qu'est-ce que cela implique pour la protection du compte root lui-même ?

Etape 9 : Sécurisation du serveur Linux (pare-feu UFW et durcissement accès SSH)

Objectif : apprendre à utiliser SSH et UFW. Contrôler et restreindre l'accès au serveur en réduisant son exposition réseau, renforçant ainsi la confidentialité, la disponibilité et la traçabilité des accès.

Lien avec le modèle CID + A + T

La sécurisation de l'accès SSH illustre directement le modèle CID + A + T :

  • Confidentialité : les échanges SSH/SFTP sont chiffrés.

  • Intégrité : les commandes et fichiers ne peuvent pas être modifiés à l'insu des utilisateurs.

  • Disponibilité : le pare-feu limite les attaques pouvant rendre le service indisponible.

  • Authenticité : l'accès par clé SSH garantit l'identité de l'utilisateur.

  • Traçabilité : chaque connexion et commande est enregistrée dans les logs système.

Règle d'or avant de toucher à SSH

Lorsque vous modifiez la configuration SSH d'un serveur, gardez toujours votre session SSH actuelle ouverte et testez la nouvelle configuration depuis un second terminal. Si la nouvelle configuration est cassée, la session existante vous permet de corriger. Dans ce TP, la console de la VM vous sauvera en cas d'erreur... mais sur un serveur distant en production, une erreur dans sshd_config peut signifier la perte définitive de l'accès. C'est un réflexe métier à acquérir dès maintenant !

1) Installez et configurez ufw :

ufw default deny incoming
ufw default allow outgoing
# Autorisation temporaire du port 22, en attendant le changement de port SSH
ufw allow 22/tcp
ufw enable

💡 La logique est celle du moindre privilège appliqué au réseau, on interdit tout en entrée par défaut (deny incoming), puis on ouvre uniquement, une à une, les portes nécessaires.

2) Créez le groupe ssh-users et ajoutez-y votre utilisateur :

groupadd ssh-users
usermod -aG ssh-users votre_user

✋ Cette étape doit impérativement être faite avant d'activer la directive AllowGroups ci-dessous : sinon, plus aucun utilisateur ne serait autorisé à ouvrir une nouvelle connexion SSH !

3) Modifiez la configuration SSH pour changer le port SSH (e.g. Port 2299) et autoriser seulement les membres du groupe ssh-users. Le fichier de configuration principal pour SSH est /etc/ssh/sshd_config mais une meilleure pratique est de créer un fichier personnalisé dans le répertoire /etc/ssh/sshd_config.d.

Pour le créer, ouvrez-le avec un éditeur de texte en tant que root, par exemple : 

nano /etc/ssh/sshd_config.d/hardening.conf

Et renseignez les paramètres suivants :

# Pour que SSH écoute sur le port 2299 en lieu et place du port 22 par défaut :
Port 2299

# Interdire la connexion directe en root :
PermitRootLogin no

# Authentification réservée aux membres du groupe ssh-users :
AllowGroups ssh-users

✋ Dans les fichiers de configuration SSH, les commentaires (#) doivent être sur leur propre ligne, un commentaire placé en fin de ligne, après une directive, provoque une erreur de configuration.

Après avoir effectué les modifications, sauvegardez le fichier et quittez l'éditeur de texte. Pour que les changements prennent effet, rechargez le service SSH :

systemctl reload ssh

Pour afficher les paramètres actifs et vérifier la bonne prise en compte de vos paramètres, vous pouvez utiliser la commande suivante :

sshd -T

4) Adaptez le firewall ufw en conséquence : autorisez le nouveau port, puis retirez l'exception du port 22 :

ufw allow 2299/tcp
ufw delete allow 22/tcp

💡 Notez la logique : on ne "bloque" pas le port 22, on retire son exception. C'est la politique par défaut (default deny incoming) qui referme la porte. Piège classique à connaître : un ufw deny 22/tcp ajouté après la règle allow 22/tcp existante serait sans effet, car UFW évalue les règles dans l'ordre et s'arrête à la première correspondance. Vérifiez vos règles et leur ordre avec :

ufw status numbered

5) Testez la connexion SSH sur le nouveau port ssh votre_user@IP_DU_SERVEUR -p 2299 (qui doit réussir) et le port 22 ssh votre_user@IP_DU_SERVEUR (qui doit échouer). Vous devez tester la connexion depuis votre VM Windows via le client ssh natif de Windows depuis Powershell.

Cette première phase durcit l'accès au serveur et limite la surface d'attaque. A ce stade, l'authentification se fait encore par login/mot de passe mais sur un port non standard. Cela ne remplace pas une authentification forte mais permet de réduire les scans automatiques et les attaques par brute-force non ciblées.

Interro (débat !)
  • Changer le port SSH est-il une véritable mesure de sécurité ? Argumentez pour et contre (indice : cherchez "sécurité par l'obscurité et "1883 principe de kerchoffs").

Etape 9b : Authentification SSH par clé

Objectif : renforcer l'authenticité en remplaçant le mot de passe par une clé cryptographique et réduisant les risques liés aux fuites de mots de passe.

💡 Une paire de clés SSH fonctionne comme une serrure et sa clé physique. La clé publique, déposée sur le serveur, est la serrure (elle peut être vue de tous sans risque), la clé privée, qui ne quitte jamais votre poste, est la seule à pouvoir l'ouvrir. Contrairement à un mot de passe, elle ne peut être ni devinée par brute-force, ni interceptée par phishing.

1) Sur le poste client, générez une paire de clés SSH :

ssh-keygen

2) Copiez la clé publique sur le serveur en vous identifiant avec login / mot de passe:

ssh-copy-id votre_user@IP_DU_SERVEUR -p 2299

3) Désactivez l'authentification par mot de passe sur le serveur, en modifiant le fichier de configuration créé à l'étape 9 :

# Pour que SSH écoute sur le port 2299 en lieu et place du port 22 par défaut :
Port 2299

# Interdire la connexion directe en root :
PermitRootLogin no

# Authentification réservée aux membres du groupe ssh-users :
AllowGroups ssh-users

# Interdire l'authentification par mot de passe :
PasswordAuthentication no

# Autoriser l'authentification par clé :
PubkeyAuthentication yes

✋ Attention à l'ordre des opérations : la clé publique doit être copiée sur le serveur (point 2) avant de désactiver l'authentification par mot de passe, sous peine de vous enfermer dehors !

4) Rechargez le service SSH :

systemctl reload ssh

5) Testez la connexion SSH :

ssh votre_user@IP_DU_SERVEUR -p 2299

La connexion ne fonctionne désormais qu'avec une clé SSH, ce qui protège efficacement contre le vol de mots de passe et les attaques par brute-force.

Interro
  • Pourquoi peut-on publier sa clé publique sans aucun risque, alors qu'un mot de passe rendu "public" serait catastrophique ?

Message clé à retenir

Changement de port = réduction du bruit automatisé

Clé SSH = authentification forte et ciblée

Etape 10 : Installation et configuration du serveur SFTP sur Linux (chiffré avec LUKS)

Objectif : fournir un service de transfert de fichiers sécurisé et cloisonné, assurant la confidentialité, l'intégrité et la traçabilité des échanges. Le service SFTP (Secure File Transfer Protocol) permet de transférer des fichiers de manière sécurisée entre un client et un serveur via une connexion chiffrée SSH.

Port SSH 22

Qui dit connexion SSH, dit port 22...que vous avez modifié à l'étape 9 ! 😉

1) Installez openssh-server (si non présent).

2) Créez un utilisateur dédié sftpuser, sans accès shell.

adduser --shell /usr/sbin/nologin sftpuser

💡 Le shell /usr/sbin/nologin applique le principe de moindre privilège. sftpuser pourra transférer des fichiers, mais jamais ouvrir un terminal ni exécuter de commandes sur le serveur. En cas de compromission de ce compte, l'attaquant reste enfermé dans le service SFTP.

3) Configurez un chroot SFTP.

C'est quoi un chroot ?

Un chroot, c'est comme mettre un utilisateur ou un programme dans une boîte où il ne voit et n'accède qu'à ce qui est dans cette boîte, sans pouvoir toucher au reste du système.

Il permet de créer un environnement isolé et sécurisé. Bien qu'il ne fournisse pas une isolation complète comme les conteneurs modernes, il reste une solution efficace pour de nombreux cas d'utilisation, notamment pour restreindre l'accès des utilisateurs ou sécuriser des services comme SFTP.

Dans le contexte d'un serveur SFTP :

  • L'utilisateur est chrooté dans un répertoire spécifique (ex. /mnt/sftp_luks).

  • Cela signifie qu'il ne peut naviguer qu'à l'intérieur de ce répertoire et ne peut pas accéder au reste du système de fichiers.

  • La configuration SSH permet d'appliquer cette restriction via des options comme ChrootDirectory.

Créez le répertoire SFTP dans le volume chiffré à l'étape 6 et monté dans le répertoire /mnt/sftp_luks :

mkdir -p /mnt/sftp_luks/sftpuser

Changez les permissions pour sécuriser l'accès :

chown root:root /mnt/sftp_luks
chmod 755 /mnt/sftp_luks

mkdir -p /mnt/sftp_luks/sftpuser/uploads
chown sftpuser:sftpuser /mnt/sftp_luks/sftpuser/uploads

💡 Ce n'est pas un choix arbitraire. Pour des raisons de sécurité, sshd refuse un chroot si le répertoire racine n'appartient pas à root ou s'il est modifiable par d'autres utilisateurs. C'est pourquoi /mnt/sftp_luks reste la propriété de root (en 755) et seul le sous-répertoire uploads est accessible en écriture à sftpuser. Une erreur ici est la cause n°1 des chroots SFTP qui "ne marchent pas".

4) Mettre à jour la configuration SSH pour forcer le SFTP interne et chrooter l'utilisateur dans le volume chiffré.

Ouvrez le fichier de configuration SSH :

nano /etc/ssh/sshd_config

Ajoutez ou modifiez les lignes suivantes :

Subsystem sftp internal-sftp

Match User sftpuser
    ChrootDirectory /mnt/sftp_luks
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

5) Rechargez ssh (systemctl reload ssh) et testez la connexion SFTP depuis Windows avec un client (WinSCP, FileZilla), en pensant bien à renseigner le port 2299.

6) Vérifiez la sécurité.

  • Volume chiffré monté : Assurez-vous que les fichiers sont inaccessibles si le volume LUKS est démonté.

  • Permissions : Vérifiez que sftpuser ne peut accéder qu'à son répertoire upload :

ls -ld /mnt/sftp_luks /mnt/sftp_luks/sftpuser /mnt/sftp_luks/sftpuser/uploads
  • Test final avec démontage du volume :
umount /mnt/sftp_luks
cryptsetup close sftp_luks

Les fichiers ne seront plus accessibles tant que le volume n'est pas déverrouillé et remonté.

7) Vous disposez désormais d'un serveur SFTP sécurisé et chiffré !

Interro
  • Que se passe-t-il si sftpuser tente une connexion SSH classique (ssh sftpuser@IP -p 2299) ? Testez, puis expliquez quels mécanismes de la configuration l'en empêchent.

Etape 11 : Sauvegardes Restic depuis Windows vers le serveur SFTP Linux

Objectif : garantir la disponibilité et la résilience des données en mettant en place des sauvegardes chiffrées et versionnées conformes à la règle 3-2-1.

Pourquoi Restic ?

Restic chiffre les sauvegardes côté client, avant même leur envoi sur le réseau. Conséquence importante : même si le serveur SFTP était compromis, l'attaquant ne récupérerait que des données illisibles sans le mot de passe du dépôt. C'est une illustration directe du modèle CID : confidentialité (chiffrement client), intégrité (chaque bloc est vérifié) et disponibilité (snapshots versionnés et dédupliqués, qui permettent de remonter dans le temps, par exemple à un état antérieur à un ransomware).

Aidez-vous de cette ressource : https://blog.stephane-robert.info/docs/cloud/outils/restic/

1) Installez Restic sur Windows.

2) Depuis PowerShell, acceptez une première fois la clé d'hôte du serveur (Restic s'appuie sur le client OpenSSH de Windows, qui doit connaître le serveur) :

sftp -P 2299 sftpuser@IP_DU_SERVEUR

Répondez yes à la question sur l'empreinte du serveur, puis quittez avec exit.

3) Initialisez un dépôt Restic sur le serveur SFTP créé à l'étape 10. Vous pouvez aussi créer un dépôt local si votre serveur SFTP n'est pas fonctionnel.

restic -r "sftp://sftpuser@IP_DU_SERVEUR:2299//sftpuser/uploads/backup_repo" init

Un mot de passe de dépôt vous est demandé. C'est lui qui protège vos sauvegardes, conservez-le précieusement (gestionnaire de mots de passe !). Sans lui, les sauvegardes sont définitivement irrécupérables.

✋ Deux subtilités dans cette URL : le port non standard impose la forme sftp://... (et non sftp:...), et comme sftpuser est chrooté dans /mnt/sftp_luks, le chemin est exprimé depuis sa racine à lui : //sftpuser/uploads/backup_repo et non //mnt/sftp_luks/sftpuser/uploads/backup_repo.

4) Sur Windows, sauvegardez le contenu du répertoire z:\data depuis le volume BitLocker vers le dépôt Restic sur le serveur SFTP :

restic -r "sftp://sftpuser@IP_DU_SERVEUR:2299//sftpuser/uploads/backup_repo" backup Z:\data

5) Testez la restauration sur Windows pour s'assurer du bon fonctionnement (restic snapshots pour lister, restic restore pour restaurer).

💡 Une sauvegarde qui n'a jamais été restaurée est une sauvegarde hypothétique. En entreprise, les tests de restauration réguliers font partie intégrante de la stratégie de sauvegarde.

Cette étape complète la protection des données en créant des sauvegardes distantes, chiffrées et versionnées.

Interro

  • En quoi une sauvegarde versionnée (snapshots) protège-t-elle contre un ransomware, là où une simple synchronisation de fichiers (type Drive/OneDrive) échoue ?

  • Pourquoi le mot de passe du dépôt Restic ne doit-il surtout pas être stocké sur le serveur SFTP lui-même ?

Etape 12 (Optionnel) : Sauvegarde Restic vers un cloud S3 (Infomaniak)

Objectif : renforcer la résilience globale en ajoutant une sauvegarde hors site, protégeant les données contre les sinistres majeurs conformément à la règle 3-2-1.

1) Configurez un compte Swiss Backup sur Infomaniak (essai gratuit).

2) Créez un bucket S3 depuis l'interface Infomaniak https://www.infomaniak.com/fr/support/faq/2546/creer-un-emplacement-s3-sur-swiss-backup

3) Récupérez les informations nécessaires

  • Access Key : Votre clé d'accès.
  • Secret Key : Votre clé secrète.
  • Endpoint : L'URL spécifique à votre emplacement Swiss Backup
  • Nom du bucket : Le nom de votre bucket S3.

4) Renseignez les identifiants S3 dans des variables d'environnement (Restic les lit automatiquement), puis initialisez le dépôt et sauvegardez : 

$env:AWS_ACCESS_KEY_ID = "VOTRE_ACCESS_KEY"
$env:AWS_SECRET_ACCESS_KEY = "VOTRE_SECRET_KEY"

restic -r s3:https://ENDPOINT/NOM_DU_BUCKET init
restic -r s3:https://ENDPOINT/NOM_DU_BUCKET backup Z:\data

5) Testez la restauration depuis le bucket S3.

Vous ajoutez une couche de redondance et de résilience grâce au stockage dans le cloud (sauvegarde 3-2-1)

💡 Faites le bilan 3-2-1 : les données originales sur le volume BitLocker (copie 1), le dépôt Restic sur le serveur SFTP (copie 2, support différent) et le dépôt S3 dans le cloud (copie 3, hors site). La règle est respectée !

Pour aller plus loin

  • SIEM/XDR Open Source Wazuh :

Mettre en place Wazuh (serveur + agent) pour centraliser et analyser les logs, détecter des anomalies, et disposer d'une console de monitoring de la sécurité.

https://youtube.com/playlist?list=PLn6POgpklwWoCKf3PDJYT2ihAd0hPZ0uM&si=83JTyJgedI9afmOs

  • IDS Crowdsec :

Installer Crowdsec sur la VM Debian pour détecter et éventuellement bloquer les comportements malveillants via une base collaborative de scénarios. Vous pourrez simuler une attaque brute force SSH.

https://doc.glaztech.cloud/1_crowdsec/

  • Audit Linux avec Lynis :

https://blog.stephane-robert.info/docs/securiser/durcissement/lynis/

Installez Lynis (apt install lynis) et exécutez un audit : 

lynis audit system

Analysez le rapport pour identifier des améliorations de la sécurité du serveur Linux.

  • Accès sécurisé aux VM via un réseau privé chiffré (NetBird)

NetBird est une solution open source de réseau privé chiffré basée sur WireGuard (VPN Zero Trust).

Objectif : Créer un réseau privé sécurisé entre la machine hôte, la VM Windows et la VM Debian. Dans le TP, NetBird permet d'administrer les VM directement depuis la machine hôte, via un tunnel chiffré, sans ouvrir de ports SSH ni modifier le réseau de virtualisation (pas de carte bridge ou host-only, juste du NAT).

Principe : Chaque machine rejoint un réseau privé NetBird après authentification. Les communications sont chiffrées de bout en bout. Les règles d'accès définissent qui peut accéder à quoi.

Bénéfices sécurité : Aucun port SSH exposé sur le réseau local ou Internet. Accès basé sur l'identité (Zero Trust). Chiffrement fort des connexions (WireGuard). Réduction de la surface d'attaque.

Exemple d'usage : La machine hôte accède au serveur Debian en SSH via son IP privée NetBird. Les règles NetBird autorisent uniquement l'hôte vers VM Debian (SSH) et vers la VM Windows.

Dans un contexte entreprise, ce type de solution remplace progressivement les VPN classiques.

https://docs.netbird.io/

Auto-évaluation - Compétences visées (RNCP36501)

Avant de considérer cet atelier comme acquis, vérifiez que vous savez faire et expliquer chacun des points suivants. Ils correspondent aux compétences du référentiel TSR que vous pouvez être ammener à démontrer devant un jury.

  • [ ] Je sais maintenir un poste et un serveur à jour et expliquer pourquoi c'est la première ligne de défense (BC01 - 1.2.2)
  • [ ] Je sais appliquer le principe de moindre privilège sous Windows (GPO, compte standard) et sous Linux (chmod, chown, groupes) (BC02 - 2.4.2)
  • [ ] Je sais vérifier le bon fonctionnement d'un antivirus avec EICAR
  • [ ] Je sais chiffrer un volume avec BitLocker et avec LUKS, et expliquer contre quelles menaces le chiffrement au repos protège (et ne protège pas)
  • [ ] Je sais mettre en place une authentification forte (MFA) et expliquer les facteurs d'authentification
  • [ ] Je sais durcir un accès SSH (port, groupes, clés) et administrer un serveur à distance (BC02 - 2.5.2)
  • [ ] Je sais configurer un pare-feu UFW selon une logique " tout interdire, n'autoriser que le nécessaire " (BC04 - 4.5.1, 4.5.3)
  • [ ] Je sais mettre en place un serveur SFTP chrooté sur un volume chiffré
  • [ ] Je sais installer et configurer un outil de sauvegarde, réaliser une sauvegarde et tester une restauration (BC04 - 4.3.2, 4.3.3)
  • [ ] Je sais expliquer la règle 3-2-1 et montrer comment le TP la respecte (BC04 - 4.3.1)
  • [ ] Je sais relier chaque manipulation du TP à un principe du modèle CID + A + T