Mise en situation
Vous êtes responsable d’un serveur qui devra progressivement offrir différents services accessibles sur un réseau.
Au début de l’activité, chaque participant reçoit une machine virtuelle Debian Server minimale, sans interface graphique et avec très peu de logiciels installés ou configurés.
Tous les serveurs se trouvent initialement sur le même réseau local, avec les systèmes utilisés pour générer les attaques.
Durant l’activité, différentes activités réseau normales, suspectes et malveillantes seront générées.
Vous ne connaîtrez pas nécessairement à l’avance :
- le type d’attaque;
- sa provenance;
- le service ciblé;
- sa fréquence;
- les outils utilisés;
- le moment où l’attaque commencera.
Votre objectif sera de maintenir vos services fonctionnels tout en étant capable de :
1. Objectifs de l’activité
Cette activité a pour objectif de développer une approche pratique de la cybersécurité défensive.
Vous devrez progressivement apprendre à :
- découvrir l’état initial d’un serveur;
- identifier les services et les ports exposés;
- analyser les connexions réseau;
- capturer et analyser du trafic;
- consulter et interpréter des journaux;
- identifier des comportements suspects;
- déterminer la provenance d’une activité;
- différencier une activité normale d’une activité potentiellement malveillante;
- réduire la surface d’attaque;
- configurer un pare-feu local;
- protéger automatiquement certains services;
- segmenter une infrastructure;
- utiliser pfSense comme pare-feu;
- configurer du NAT et du Port Forwarding;
- déployer des services avec Docker;
- utiliser un reverse proxy;
- analyser des requêtes HTTP/HTTPS;
- choisir le niveau approprié pour bloquer une attaque;
- vérifier qu’une protection fonctionne réellement.
2. Infrastructure du laboratoire
L’infrastructure sera hébergée sur Proxmox.
Chaque participant disposera de son propre environnement virtuel.
L’accès distant au laboratoire sera réalisé à l’aide d’un VPN tel que Tailscale.
L’environnement utilisera principalement :
- Tailscale;
- Proxmox;
- Debian Server;
- pfSense;
- Docker;
- Nginx Proxy Manager;
- différents outils Linux d’analyse et de sécurité.
Tailscale servira principalement de moyen d’accès distant et administratif au laboratoire.
Le réseau utilisé pour les scénarios de cybersécurité sera distinct de cet accès administratif.
3. Environnement initial
Chaque participant commence avec :
1 VM Debian Server
La machine possède :
- aucune interface graphique;
- très peu de logiciels supplémentaires;
- aucune solution de sécurité particulière;
- un service accessible sur le réseau.
Tous les serveurs Debian sont initialement placés sur le même réseau local que les systèmes générant les attaques.
Il n’y a initialement aucun pfSense entre les attaquants et les serveurs.
4. Méthode d’analyse
Lorsqu’une activité suspecte apparaît, évitez de bloquer immédiatement une adresse simplement parce qu’elle génère beaucoup de trafic.
Essayez plutôt de suivre la méthode suivante :
1 – Observer
Qu’est-ce qui se passe?
2 – Identifier
Quelle machine, adresse IP, application ou service est impliqué?
3 – Comprendre
Pourquoi cette activité est-elle normale ou suspecte?
4 – Protéger
Quelle mesure permet de limiter l’activité malveillante?
5 – Vérifier
La protection fonctionne-t-elle réellement?
Le service légitime fonctionne-t-il toujours?
5. Règles de l’activité
Chaque décision défensive doit pouvoir être expliquée.
Avant de bloquer une source ou de modifier une configuration, vous devriez idéalement pouvoir répondre aux questions suivantes :
- Qu’est-ce que j’ai observé?
- Pourquoi est-ce suspect?
- Quelle est la source probable?
- Quel service est ciblé?
- Quelle protection ai-je mise en place?
- Pourquoi ai-je choisi cette protection?
- Comment ai-je vérifié son efficacité?
Une solution qui bloque l’attaque mais qui empêche également les utilisateurs légitimes d’utiliser le service n’est pas considérée comme une solution complète.
6. Accès distant avec Tailscale
Les participants pourront accéder à l’environnement à distance grâce à Tailscale.
Vous devriez être capable de :
- installer Tailscale;
- connecter votre ordinateur au VPN;
- identifier les machines disponibles;
- comprendre les adresses IP Tailscale;
- tester la connectivité;
- accéder aux ressources autorisées du laboratoire.
Tailscale constitue principalement le réseau d’accès administratif.
Les scénarios d’attaque se déroulent dans les réseaux virtuels du laboratoire.
Cela permet notamment de conserver un accès administratif lorsque vous modifiez les règles de pare-feu ou la configuration réseau de votre environnement.
7. Préparation recommandée
Avant l’activité, il est recommandé de réviser ou d’expérimenter les technologies suivantes.
Tailscale
- installation;
- connexion au VPN;
- identification des machines;
- connectivité entre les hôtes.
Proxmox
- accès à l’interface Web;
- démarrage et arrêt d’une VM;
- console d’une VM;
- interfaces réseau virtuelles;
- configuration réseau d’une VM.
Debian / Linux
- commandes Linux;
- utilisateurs et permissions;
- services;
- SSH;
- processus;
- interfaces réseau;
- journaux système.
Réseau
- IPv4;
- sous-réseaux;
- TCP et UDP;
- ports;
- routage;
- passerelle par défaut;
- DNS;
- HTTP et HTTPS;
- NAT.
pfSense
- interfaces WAN et LAN;
- règles de pare-feu;
- NAT;
- Port Forwarding;
- consultation des logs;
- analyse du trafic autorisé et bloqué.
Docker
- images;
- conteneurs;
- ports;
- volumes;
- réseaux;
- logs.
Outils d’analyse
Familiarisez-vous avec certains outils comme :
D’autres outils pourront être installés et découverts pendant l’activité.
8. Architecture finale
À la fin de l’activité, votre environnement pourra ressembler à ceci :
Cette architecture permet d’observer et de protéger une même activité à plusieurs niveaux :
pfSense
Trafic réseau, IP, ports, règles et connexions bloquées.
Debian
Connexions, processus, pare-feu local et journaux système.
Docker
Conteneurs, réseaux, ports et journaux.
Nginx Proxy Manager
Requêtes HTTP/HTTPS, IP sources, URL, codes HTTP et User-Agent.
Application
Erreurs, authentification et événements propres au service.
9. Objectif final
À la fin de l’activité, vous devriez être capable de partir d’un serveur Debian minimal directement exposé sur un réseau hostile et de construire progressivement une infrastructure plus sécurisée.
Mais l’objectif principal n’est pas simplement d’installer pfSense, Docker, Fail2ban ou un reverse proxy.
L’objectif est de développer une méthode de travail permettant de comprendre ce qui se passe avant d’agir.
Une bonne défense ne consiste pas uniquement à bloquer une attaque.
Elle doit permettre de continuer à offrir le service aux utilisateurs légitimes tout en réduisant les risques associés aux activités malveillantes.
10. Phase 1 – Découverte de votre serveur
Avant de protéger une machine, vous devez comprendre son fonctionnement et son état actuel.
Analysez votre serveur afin de déterminer notamment :
- ses interfaces réseau;
- ses adresses IP;
- sa passerelle;
- sa table de routage;
- les ports en écoute;
- les services actifs;
- les processus associés;
- les connexions actuellement établies;
- les utilisateurs présents;
- les journaux disponibles.
Vous devrez être capable de répondre à la question :
Quelle est actuellement la surface d’attaque de mon serveur?
Vous êtes libre d’installer les outils nécessaires.
Exemples :
Cette liste n’est pas exhaustive.
11. Phase 2 – Analyse du réseau
Différentes activités commenceront progressivement à apparaître sur le réseau.
Certaines seront parfaitement normales.
D’autres pourront être suspectes ou malveillantes.
Votre objectif sera de déterminer ce qui se passe.
Vous devrez notamment tenter de répondre aux questions suivantes :
Qui communique avec mon serveur?
Quelle est l’adresse IP source?
Quel port est utilisé?
Quel service est ciblé?
À quelle fréquence les connexions apparaissent-elles?
Les connexions réussissent-elles?
Que montrent les paquets réseau?
Que montrent les journaux?
S’agit-il d’une activité normale, d’un scanner automatisé ou d’une attaque?
12. Phase 3 – Réduction de la surface d’attaque
Une fois votre serveur analysé, vous devrez commencer à le sécuriser.
Vous pourrez notamment :
- désactiver les services inutiles;
- fermer les ports inutiles;
- configurer
ufwounftables; - limiter les sources autorisées;
- sécuriser les services exposés;
- améliorer la journalisation;
- installer Fail2ban;
- détecter les tentatives répétées de connexion.
Règle importante
Bloquer complètement le réseau n’est pas une solution.
Les services demandés doivent continuer à fonctionner pour les utilisateurs légitimes.
L’objectif est de réduire la surface d’attaque sans rendre le service inutilisable.
13. Phase 4 – Ajout de pfSense
L’architecture sera ensuite modifiée.
Votre serveur Debian ne sera plus directement exposé au réseau d’attaque.
Vous devrez configurer et comprendre :
- l’interface WAN;
- l’interface LAN;
- l’adressage du réseau interne;
- les règles de pare-feu;
- le NAT;
- le Port Forwarding;
- les journaux pfSense.
Vous devrez être capable d’identifier si un trafic est :
- reçu par pfSense;
- autorisé;
- bloqué;
- redirigé vers votre serveur.
14. Phase 5 – Serveur Web, Port Forwarding et Nginx Proxy Manager
Votre serveur Debian devra maintenant offrir un service Web accessible depuis le réseau externe.
Vous devrez installer et configurer Apache sur votre serveur Debian.
Une page Web devra être créée et rendue accessible avec Apache.
Vous devrez ensuite installer Nginx Proxy Manager dans Docker.
Nginx Proxy Manager deviendra le point d’entrée pour les connexions HTTP et HTTPS vers votre serveur Web.
Vous devrez enregistrer votre serveur Web Apache dans Nginx Proxy Manager afin que les requêtes reçues soient redirigées vers Apache.
Le chemin d’une requête Web deviendra donc :
Vous devrez configurer le Port Forwarding dans pfSense afin de permettre au trafic HTTP et HTTPS d’atteindre Nginx Proxy Manager.
Principe général :
Vous devrez vérifier que votre page Web est accessible depuis le réseau externe.
15. Phase 6 – Surveillance des logs de Nginx Proxy Manager
Une fois votre page Web accessible, vous devrez commencer à surveiller les communications avec votre serveur.
Un outil personnalisé d’analyse des logs vous sera fourni.
Cet outil permet de surveiller et d’analyser les fichiers de logs générés par Nginx Proxy Manager.
Il permettra notamment d’observer les échanges entre les clients et vos serveurs Web.
Vous pourrez utiliser l’outil pour analyser notamment :
- les adresses IP sources;
- les requêtes HTTP;
- les méthodes utilisées;
- les URL demandées;
- les codes de réponse HTTP;
- les User-Agent;
- la fréquence des requêtes;
- les erreurs générées;
- les ressources demandées;
- les comportements répétitifs.
L’objectif est de commencer à comprendre ce qui se passe devant votre serveur Web à partir des informations contenues dans les logs de Nginx Proxy Manager.
16. Phase 7 – Activités normales et activités suspectes
À partir de cette étape, différentes activités commenceront à apparaître dans les logs de votre serveur Web.
Certaines activités seront parfaitement normales.
D’autres pourront provenir de robots, de scanners automatisés ou d’activités potentiellement malveillantes.
Vous ne saurez pas nécessairement à l’avance quelle activité est normale et laquelle représente une attaque.
Votre travail sera d’utiliser les informations présentes dans les logs de Nginx Proxy Manager pour tenter de comprendre ce qui se passe.
Vous devrez notamment tenter de répondre aux questions suivantes :
- Quelle adresse IP génère les requêtes?
- Quelles ressources sont demandées?
- À quelle fréquence?
- Les ressources demandées existent-elles réellement?
- Quels codes HTTP sont retournés?
- Le même comportement est-il répété?
- Quel User-Agent est utilisé?
- Le comportement ressemble-t-il à celui d’un utilisateur normal?
- Le comportement ressemble-t-il à celui d’un robot ou d’un scanner automatisé?
- Est-ce une activité potentiellement malveillante?
Une adresse IP qui génère beaucoup de trafic n’est pas automatiquement malveillante.
Vous devrez utiliser plusieurs informations présentes dans les logs avant de prendre une décision.
17. Phase 8 – Filtrage basé sur l’analyse des logs
Après avoir identifié une activité suspecte, vous devrez déterminer comment la limiter ou la bloquer.
Votre décision devra être basée sur les observations effectuées dans les logs de Nginx Proxy Manager.
Le processus devient donc :
Selon la situation, le filtrage pourra être appliqué à différents niveaux de l’infrastructure.
Vous pourrez notamment intervenir dans :
- pfSense;
- le pare-feu du serveur Debian;
- Nginx Proxy Manager;
- Fail2ban;
- le serveur Web;
- l’application elle-même.
Le choix devra dépendre du type d’activité observée.
Vous devrez être capable d’expliquer :
- ce que vous avez observé dans les logs;
- pourquoi vous considérez cette activité comme suspecte;
- quelle source ou quel comportement vous souhaitez filtrer;
- où vous avez appliqué le filtrage;
- pourquoi vous avez choisi ce niveau;
- comment vous avez vérifié que le filtrage fonctionne.
Après chaque modification, vous devrez continuer à surveiller les logs afin de vérifier que :
- l’activité malveillante est effectivement limitée ou bloquée;
- les utilisateurs légitimes peuvent toujours accéder au service;
- la mesure de protection ne génère pas de nouveaux problèmes.
18. Phase 9 – Choisir où intervenir
Une activité suspecte a été identifiée.
Il faut maintenant déterminer où appliquer la protection.
Plusieurs possibilités peuvent exister :
Vous devrez choisir le niveau approprié selon la situation.
Il ne suffit pas de bloquer une adresse IP.
Vous devez être capable d’expliquer pourquoi la protection est appliquée à cet endroit de l’infrastructure.
19. Phase 10 – Défense progressive
Les attaques pourront évoluer pendant l’activité.
Une protection efficace contre une attaque ne fonctionnera pas nécessairement contre la suivante.
Vous pourrez progressivement ajouter des mécanismes comme :
- Fail2ban;
- règles pfSense;
- filtrage IP;
- limitation du nombre de requêtes;
- IDS/IPS;
- Suricata;
- CrowdSec;
- centralisation des logs;
- tableaux de bord;
- surveillance réseau;
- surveillance des applications;
- alertes.
Vous êtes libre d’utiliser d’autres outils si vous êtes capable de justifier leur utilisation.
