Cybersécurité

Analyser les risques, auditer les vulnérabilités et mettre en œuvre des solutions de sécurité périmétrique et interne.

Apprentissages Critiques - Niveau 2 :
➥ Mettre en œuvre un système d'information sécurisé

AC34.01 | Participer activement à une analyse de risque pour définir une politique de sécurité

Gouvernance et Conformité (Référentiel ANSSI)

Pour structurer la sécurité du Système d'Information (SI), j'ai adopté une approche formelle basée sur le Guide d'hygiène de l'ANSSI. J'ai réalisé un audit complet comparant l'architecture existante aux recommandations officielles :

  • Élaboration de la PSSI : Rédaction de la Politique de Sécurité des Systèmes d'Information définissant les règles de complexité des mots de passe, la gestion des comptes à privilèges et la journalisation des événements.
  • Classification des Actifs : Cartographie des ressources critiques (Serveur DNS, Base de données utilisateurs) pour définir des zones de confiance distinctes (Admin, Production, Service).

Analyse des Menaces et Tests d'Intrusion (Pentest)

J'ai validé la robustesse de cette politique par une phase offensive (Red Teaming) visant à exploiter les vulnérabilités potentielles avant leur correction :

  • Scénarios d'Attaque : Simulation d'attaques Man-in-the-Middle et de DNS Spoofing via l'outil Bettercap pour démontrer les risques d'interception de trafic non chiffré.
  • Scan de Vulnérabilités : Utilisation de Nmap (nmap -sS -p-) pour auditer la surface d'attaque exposée et vérifier l'efficacité du filtrage des ports non essentiels.
AC34.02 | Mettre en oeuvre des outils avancés de sécurisation d'une infrastructure du réseau

Architecture de Sécurité Périmétrique (Cisco ASA)

J'ai déployé une sécurité en profondeur reposant sur des pare-feux Cisco ASA (Adaptive Security Appliance) pour contrôler hermétiquement les frontières du réseau :

  • Zoning et Security Levels : Implémentation d'une politique de sécurité basée sur des niveaux de confiance stricts : Inside (niveau 100) pour le LAN, Outside (niveau 0) pour le WAN, et DMZ (niveau 50) pour les serveurs exposés.
  • Inspection Dynamique (DPI) : Configuration de l'inspection protocolaire via le Modular Policy Framework (MPF). J'ai défini des policy-map pour analyser la conformité des flux applicatifs (HTTP, DNS, ICMP) et rejeter les paquets malformés.

Segmentation et Filtrage Granulaire

Au sein du réseau local, j'ai renforcé l'isolation pour empêcher les mouvements latéraux en cas de compromission :

  • Listes de Contrôle d'Accès (ACL) : Application du principe de moindre privilège avec des ACL étendues (ex: access-list VLAN20_30_BLOCK). Cela interdit par défaut toute communication entre les VLANs Production et Service, n'autorisant que les flux d'administration légitimes.
  • Haute Disponibilité : Mise en place du protocole HSRP (Hot Standby Router Protocol) avec authentification et préemption (standby priority 110) pour assurer la redondance de la passerelle par défaut.
AC34.03 | Sécuriser les systèmes d'exploitation et les services

Durcissement des Services Web et Applicatifs (Hardening)

J'ai sécurisé la couche applicative en durcissant les configurations du serveur Web Nginx et de l'application Python/Flask contre les attaques OWASP Top 10 :

  • Sécurité HTTP : Configuration de Nginx en Reverse Proxy avec enforcement TLS 1.3 et ajout d'en-têtes de sécurité stricts : Strict-Transport-Security (HSTS), X-Content-Type-Options: nosniff et X-Frame-Options: SAMEORIGIN.
  • Protection de l'Authentification : Développement de mécanismes défensifs incluant un CAPTCHA JavaScript, le hachage des mots de passe via PBKDF2 (bibliothèque Werkzeug) et la protection contre le Brute-Force avec Fail2Ban.

Intégrité de l'Infrastructure (DNSSEC)

Pour contrer les attaques par empoisonnement de cache DNS, j'ai déployé une chaîne de confiance cryptographique complète :

  • Signature de Zone : Signature de la zone societe2.pepiniere.rt sur Windows Server (AD) avec des clés asymétriques (KSK 2048 bits et ZSK 1024 bits).
  • Validation : Vérification de la propagation des enregistrements DNSKEY et RRSIG via PowerShell (Resolve-DnsName -DnssecOk), garantissant l'authenticité des réponses DNS.
AC34.04 | Proposer une architecture sécurisée de système d'information

Interconnexion de Sites Sécurisée (VPN IPsec)

Pour relier le Siège et la Succursale via un réseau non sûr, j'ai conçu un tunnel chiffré garantissant la confidentialité et l'intégrité des données en transit :

  • Tunneling Site-à-Site : Configuration d'un VPN IPsec sur l'interface Tunnel0. J'ai utilisé des paramètres cryptographiques robustes pour la phase IKE et le chiffrement des données.
  • Routage Sécurisé : Déploiement du protocole OSPF (Zone 0) à travers le tunnel pour assurer une convergence dynamique du réseau sans exposer la topologie interne sur le WAN public.

Durcissement des Équipements Réseau

La sécurité physique et logique des équipements d'infrastructure (Routeurs, Switchs) a été renforcée pour prévenir les accès non autorisés :

  • Administration Sécurisée (AAA) : Désactivation totale du protocole Telnet (texte clair) au profit de SSHv2. Chiffrement des mots de passe locaux (service password-encryption) et définition de privilèges administrateurs (niveau 15).
  • Sécurité de Niveau 2 : Activation de fonctionnalités de protection sur les commutateurs, telles que le Port Security pour limiter les adresses MAC par port et le DHCP Snooping pour empêcher l'injection de serveurs DHCP malveillants.

Projet de référence : SAE4.Cyber.01 - Sécuriser un système d’information

Accéder aux fichiers Voir le projet

SAE 4.Cyber.01 - Architecture Multi-Sites Sécurisée

Audit, conception et déploiement d'une infrastructure réseau et applicative résiliente face aux cybermenaces, basée sur les recommandations de l'ANSSI.

1. Architecture et Topologie

Le projet repose sur une topologie Siège/Succursale interconnectée par un tunnel VPN IPsec. L'objectif était de transformer un réseau "plat" et vulnérable en une forteresse numérique.

  • Matériel : 3 Routeurs, 2 Switchs de niveau 3, 2 Firewalls Cisco ASA.
  • Service Visé : Assurer la disponibilité des services Web et DNS en DMZ tout en protégeant les postes de travail du LAN interne.
Topologie Réseau Siège/Succursale avec DMZ et VPN
Architecture réseau sécurisée : Topologie Siège/Succursale avec DMZ et Tunnel VPN

2. Implémentation du Filtrage (Cisco ASA)

La sécurité périmétrique est assurée par deux pare-feux Cisco ASA configurés avec une politique de zonage stricte :

  • Segmentation par Niveaux de Sécurité : Définition des zones Inside (Level 100), Outside (Level 0) et DMZ (Level 50) pour cloisonner les flux.
  • Inspection Deep Packet (DPI) : Utilisation de Modular Policy Framework (MPF) pour inspecter dynamiquement les protocoles (HTTP, DNS, ICMP) et prévenir les attaques applicatives.
  • Filtrage ACL : Règles strictes interdisant le trafic initié depuis la DMZ vers le réseau interne (Inside) pour bloquer les mouvements latéraux.
Schéma des règles de filtrage sur Cisco ASA
Matrice de filtrage et segmentation des zones de sécurité (ASA)

3. Sécurisation de l'Infrastructure DNS (DNSSEC)

Le service DNS (BIND/Windows), hébergé dans le VLAN Admin, est une cible critique pour les attaques de type Cache Poisoning. J'ai implémenté le protocole DNSSEC pour garantir l'intégrité et l'origine des données.

  • Signature de Zone : La zone societe2.pepiniere.rt a été signée numériquement en utilisant l'algorithme RSA/SHA-256.
  • Gestion des Clés (KSK/ZSK) : Déploiement d'une infrastructure à deux clés pour renforcer la sécurité :
    • Key Signing Key (KSK) : Clé longue de 2048 bits pour signer les clés de zone.
    • Zone Signing Key (ZSK) : Clé de 1024 bits pour signer les enregistrements de ressources (RRsets).
  • Validation et Tests d'attaque :
    • Vérification via PowerShell avec la commande Resolve-DnsName ... -DnssecOk qui confirme la présence des enregistrements RRSIG et DNSKEY.
    • Test de résilience face à une attaque de DNS Spoofing lancée avec Bettercap. L'attaque a échoué ("Echec temporaire dans la résolution"), prouvant que le client rejette les réponses falsifiées non signées.
Capture d'écran de validation DNSSEC sur Windows Server
Preuve de validation DNSSEC : Présence des enregistrements RRSIG

4. Sécurisation Web Avancée (Nginx & Flask)

La protection des services Web hébergés en DMZ a été traitée en profondeur, en sécurisant à la fois le serveur frontal et l'application backend :

  • Reverse Proxy Nginx Durci :
    • Terminaison SSL/TLS avec certificats X.509 et restriction aux protocoles TLSv1.2 / TLSv1.3.
    • Injection d'en-têtes de sécurité : HSTS (Max-Age 1 an), X-Frame-Options: SAMEORIGIN (Anti-Clickjacking) et X-XSS-Protection.
    • Masquage des versions (server_tokens off) pour limiter la reconnaissance.
  • Protection Applicative (WAF & Code) :
    • Développement d'un Captcha dynamique en JavaScript pour bloquer les bots sur les formulaires d'authentification.
    • Hachage sécurisé des mots de passe utilisateurs via la bibliothèque Werkzeug.security (SHA-256).
    • Mise en place de Fail2Ban (Jail [nginx-http-auth]) pour bannir les IPs après 3 échecs de connexion (Brute-Force).
Redirection HTTPS forcée et cadenas de sécurité
Durcissement Web : HTTPS forcé et certificat TLS valide

5. Conformité ANSSI & Gouvernance

La démarche de sécurisation s'est appuyée sur le Guide d'hygiène informatique de l'ANSSI. J'ai réalisé un audit de conformité complet :

  • Matrice de Conformité : Création d'un tableur croisant les règles du guide ANSSI (gestion des accès, mises à jour, journalisation) avec les mesures appliquées sur le projet.
  • Définition de la PSSI : Élaboration des règles de la Politique de Sécurité des Systèmes d'Information, imposant notamment la séparation des tâches et la centralisation des logs.
Extrait de la matrice de conformité ANSSI
Tableau de conformité vis-à-vis du guide d'hygiène de l'ANSSI

6. Validation par Tests d'Intrusion (Pentest)

Pour valider l'efficacité des mesures défensives, j'ai mené une campagne de tests offensifs (Red Teaming) :

  • Attaque MITM & DNS Spoofing : Tentative d'empoisonnement DNS avec l'outil Bettercap. Résultat : Échec de l'attaque grâce à la validation DNSSEC.
  • Reconnaissance : Scan de ports via Nmap (nmap -sS -p-). Résultat : Seuls les ports 80/443 sont visibles, confirmant l'efficacité du filtrage ASA.
  • Injection SQL : Tests d'injection sur le formulaire de login Flask (OR 1=1--). Résultat : Bloqués par l'utilisation de requêtes paramétrées (cursor.execute) dans le code Python.
Terminal Kali Linux avec exécution de Bettercap et Nmap
Phase de Pentest : Scan de ports et tentative d'attaque Man-in-the-Middle

Rapport Détaillé du projet

Rapport : SAE 4.cyber.01 - Sécuriser un système d'Information

Mon parcours académique et mes expériences en milieu professionnel détaillés dans un document de synthèse.

Consulter le Rapport Technique (PDF)

Rapport : Sécuriser un SI

Affichage optimisé pour mobile.

Ouvrir le Rapport