Cours/Saison C3
Saison C38 modules

Saison C3. Sécurité système & réseau

Modules

C301️ C301. Introduction : Gouvernance, Outils & Bases RéseauC302C302. Contrôle d'accès et Sécurité Sans-Fil (ACL, NAC, WiFi)C303C303. DMZ, pare-feu & VPNC304C304. Détection, Prévention et SIEM (Suricata & Wazuh)C305C305. Sécurité Linux (Pare-feu & SSH)C306️ C306. PAM, Logs, Fail2ban & Port-KnockingC307C307. Reverse-proxy, Load-balancer, HTTPS & Anti-DDoSC308️ C308. SSO, IAM & WAF (Identités & Sécurité Web)

Objectif de la saison : Passer du principe "ça marche" au principe "c'est sécurisé". Jusqu'ici, on a construit les murs et posé les portes de l'infrastructure. Maintenant, on va installer les serrures, vérifier qui possède les clés et surveiller ce qui se passe.

🛡️ C301. Introduction : Gouvernance, Outils & Bases Réseau

Objectif du cours : Poser le cadre. La sécurité n'est pas qu'une affaire de configurations techniques ; c'est d'abord une question de règles (gouvernance), de surveillance (SOC/SIEM) et de maîtrise des vulnérabilités locales (Niveau 2).

1. Gouvernance et Normes : Le plan de l'architecte

La sécurité technique sans cadre revient à sécuriser au hasard, sans savoir "jusqu'où" aller ni pouvoir justifier ses choix.

  • Le rôle de la gouvernance : C'est ce qui donne la direction. Elle permet de définir qui décide, quoi protéger en priorité et comment on vérifie que c'est efficace.
  • La traduction sur le terrain : C'est grâce à la gouvernance qu'un professionnel des réseaux peut justifier la création d'une règle stricte de pare-feu, prioriser le déploiement de patchs ou structurer un plan d'action précis.
  • Les normes de référence :
    • ISO 27001 : Le standard international pour le management de la sécurité de l'information.
    • PCI DSS : Standard pour la protection des données bancaires.
    • RGPD / HIPAA : Protection des données personnelles et de santé.

2. L'Écosystème de Défense (Vocabulaire et Acronymes)

En cybersécurité, on part du principe qu'un incident finira par arriver : la question n'est pas "si", mais "quand". Il faut donc détecter vite et réagir proprement.

  • SOC (Security Operations Center) : C'est l'équipe de surveillance (les "gardiens"), humaine et technique, qui analyse les alertes 24/7.
  • SIEM (Security Information and Event Management) : Le "cerveau" central. C'est l'outil qui collecte, centralise et analyse tous les logs (des routeurs, switchs, serveurs) pour détecter des anomalies de comportement.
  • CTI (Cyber Threat Intelligence) : Le renseignement sur les menaces. Permet de connaître les techniques des attaquants pour mieux paramétrer les défenses.
  • EDR / XDR (Endpoint / Extended Detection and Response) : Des agents de sécurité très avancés (bien plus que de simples antivirus) qui surveillent les comportements suspects sur les machines (EDR) et sur l'ensemble du réseau/cloud (XDR).

3. Les Attaques Réseau de Niveau 2 (Couche Liaison)

C'est le cœur du champ de bataille pour l'infrastructure locale. Sécuriser les équipements de cœur de réseau est primordial pour éviter ces compromissions.

  • ARP Spoofing / Poisoning (Empoisonnement ARP) :

    • Le principe : L'attaquant envoie de faux messages ARP sur le réseau local pour associer son adresse MAC à l'adresse IP d'un autre équipement légitime (très souvent la passerelle par défaut/le routeur).
    • L'impact : Le trafic de la victime est redirigé vers l'attaquant, permettant une attaque de type de l'Homme du Milieu (Man-in-the-Middle) pour intercepter, modifier ou bloquer les communications.

  • VLAN Hopping (Saut de VLAN) :

    • Le principe : Une technique permettant à un attaquant de forcer l'envoi de paquets vers un VLAN auquel il ne devrait pas avoir accès.
    • Les méthodes : Cela se fait souvent en exploitant des ports switch mal configurés (qui négocient automatiquement un lien Trunk via le protocole DTP) ou via l'attaque du Double-Tagging (ajout de deux en-têtes 802.1Q).

🛠️ Ressources : Configurations Réseau

Pour se prémunir contre les attaques de Niveau 2 et segmenter proprement le trafic, une configuration stricte des commutateurs et du routage Inter-VLAN (Router-on-a-Stick) est vitale. Voici les commandes issues de la démonstration :

  • Configuration du Switch (Création VLANs et assignation des ports Access/Trunk)
enable
configure terminal

! Création des VLANs
vlan 10
 name INFORMATIQUE
 exit

vlan 20
 name COMPTABILITE
 exit

! Configuration des ports d'accès (utilisateurs finaux)
interface range fa0/1-2
 switchport mode access
 switchport access vlan 10
 exit

interface range fa0/3-4
 switchport mode access
 switchport access vlan 20
 exit

! Configuration du port Trunk (vers le routeur ou un autre switch)
interface fa0/24
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30,40,99
  • Configuration du Routeur (Routage Inter-VLAN / Router-on-a-Stick)
enable
configure terminal

! Activation de l'interface physique
interface g0/0
 no shutdown

! Configuration des sous-interfaces pour chaque VLAN
interface g0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.254 255.255.255.0
 exit

interface g0/0.20
 encapsulation dot1Q 20
 ip address 192.168.20.254 255.255.255.0
 exit

! Activation globale du routage IP (si nécessaire sur un commutateur L3, "ip routing")
ip routing

Challenge C301 : Segmentation VLAN & Contrôle d'accès (ACL)

📚 Ressources :

Retour en haut

🔑 C302. Contrôle d'accès et Sécurité Sans-Fil (ACL, NAC, WiFi)

Objectif : Sécuriser les accès au réseau, qu'ils soient filaires ou sans-fil. On apprend ici à filtrer le trafic (ACL), à authentifier les machines avant de les laisser entrer sur le réseau (802.1x / RADIUS) et à maîtriser l'évolution des chiffrements Wi-Fi.

1. Le Filtrage Réseau : Les ACL (Access Control Lists)

Les ACL sont la première ligne de défense sur un routeur ou un switch de niveau 3. Elles filtrent le trafic entrant ou sortant selon des règles définies.

  • ACL Standards : Elles filtrent uniquement en fonction de l'adresse IP source. Elles sont simples mais peu précises (généralement placées le plus près possible de la destination).
  • ACL Étendues : Elles filtrent en fonction de l'IP source, l'IP de destination, le protocole (TCP/UDP) et le numéro de port. Elles permettent un contrôle granulaire (généralement placées le plus près possible de la source).

Une ACL est une série de règles permettant de filtrer le trafic réseau en fonction de critères précis. Elles sont lues de haut en bas, et la première règle correspondante est appliquée.

  • Les 3 Règles d'Or des ACL

    • Le "Deny Any" implicite : À la fin de chaque ACL, il existe une règle invisible qui bloque tout ce qui n'a pas été explicitement autorisé.
    • L'ordre est crucial : Les règles les plus spécifiques (ex: autoriser un hôte précis) doivent être placées avant les règles générales (ex: bloquer un réseau entier).
    • Un par interface, un par sens, un par protocole : On ne peut appliquer qu'une seule ACL par interface, par direction (IN ou OUT) et par protocole (IPv4/IPv6).

  • Comparaison : Standard vs Étendue

    CaractéristiqueACL StandardACL Étendue
    Plage de numéros1 à 99100 à 199
    Critère de filtrageAdresse Source uniquementSource, Destination, Protocole (IP, TCP, UDP, ICMP) et Port
    Usage typiqueLimitation des accès administratifs (VTY)Filtrage précis entre les VLANs ou vers Internet
    PositionnementAu plus proche de la destinationAu plus proche de la source

  • Syntaxe et Logique des Commandes

    -Le Masque Générique (Wildcard Mask)

    C'est l'inverse du masque de sous-réseau. Pour un /24 (255.255.255.0), le wildcard est 0.0.0.255.

    • 0 = Le bit doit correspondre exactement.
    • 255 = On ignore la valeur du bit.

    -Exemples de commandes

    • Standard : access-list 10 permit 192.168.10.0 0.0.0.255
    • Étendue : access-list 110 permit tcp 192.168.10.0 0.0.0.255 host 192.168.99.10 eq 80

  • Méthodologie d'application (IN vs OUT)

    L'application se fait toujours par rapport au cœur du routeur :

    • IN (Entrée) : Le trafic arrive du réseau, "frappe" l'interface et le routeur l'analyse avant de décider de le router. C'est le plus efficace pour économiser les ressources du routeur.
    • OUT (Sortie) : Le trafic a déjà été routé et s'apprête à sortir de l'interface vers le réseau de destination.

  • Commandes de vérification indispensables

    • show access-lists : Affiche les règles et le nombre de paquets ayant matché chaque ligne.
    • show ip interface <nom> : Permet de voir quelle ACL est appliquée sur une interface spécifique.
    • clear access-list counters : Remet les compteurs de "matches" à zéro (utile pour de nouveaux tests).

2. NAC et 802.1x : Le Contrôle d'Accès Réseau

Le NAC (Network Access Control) est une approche globale pour sécuriser l'accès au réseau. Le protocole phare pour cela est le 802.1x.

  • Principe du 802.1x : Un appareil (PC) se branche sur une prise réseau (Switch). Le port du switch reste bloqué tant que l'utilisateur ou la machine ne s'est pas authentifié avec succès.

  • Les 3 acteurs du 802.1x :

    1. Le Supplicant : Le client (le PC) qui demande l'accès.
    2. L'Authenticator : Le Switch (ou la borne Wi-Fi) qui bloque le port et relaye la demande.
    3. Le Serveur d'Authentification (RADIUS) : Le serveur qui vérifie les identifiants (souvent en interrogeant un annuaire comme LDAP ou Active Directory) et donne le feu vert au Switch.

3. Sécurité Wi-Fi : Du WEP au WPA3

Les réseaux sans-fil sont particulièrement vulnérables car les ondes traversent les murs. Une mauvaise sécurité peut entraîner des intrusions, des vols de données ou le piratage d'appareils.

  • Le Cadre Légal : Attention, l'interception de communications et l'accès frauduleux à un système sont des délits pénaux (Article 323-1 en France : jusqu'à 2 ans de prison et 60 000€ d'amende). La démo en labo n'est pas une autorisation réelle.

  • L'évolution des protocoles :

    • WEP et WPA1 : Obsolètes et vulnérables, à fuir absolument.
    • WPA2 : Reste une base très solide s'il est bien configuré (avec un mot de passe fort).
    • WPA3 : La dernière évolution logique. Il protège beaucoup mieux contre les attaques par force brute (brute-force) et améliore le chiffrement sur les réseaux publics.

  • Personal vs Enterprise :

    • Personal (PSK) : Utilise un mot de passe partagé. Idéal pour les petits réseaux (WPA2/WPA3 Personal).
    • Enterprise (802.1x/RADIUS) : Chaque utilisateur a ses propres identifiants. Indispensable en PME/Entreprise (WPA2/WPA3 Enterprise).

🛠️ Ressources & Démos Techniques

Quelques configurations et commandes pour mettre en pratique ces concepts.

Installation d'un Annuaire LDAP (Base pour l'authentification)

L'annuaire LDAP va stocker nos utilisateurs.

sudo apt update
sudo apt install slapd ldap-utils -y
sudo dpkg-reconfigure slapd # Configurer le domaine (ex: example.com), MDB, mot de passe admin

# Création d'une Unité Organisationnelle (OU)
nano base_users.ldif
dn: ou=users,dc=example,dc=com
objectClass: organizationalUnit
ou: users

sudo ldapadd -x -D cn=admin,dc=example,dc=com -W -f base_users.ldif
Configuration 802.1x / RADIUS (Cisco)

Le Switch (192.168.1.1) interroge le serveur RADIUS (192.168.1.2) pour authentifier les PC.

hostname SW1
aaa new-model
radius-server host 192.168.1.2 auth-port 1645 key password
aaa authentication dot1x default group radius 
dot1x system-auth-control

! Configuration d'un port d'accès authentifié
interface FastEthernet0/1
 description PC-1
 switchport mode access
 authentication port-control auto
 dot1x pae authenticator
Démo : Attaque sur un réseau Wi-Fi WEP

L'objectif est d'écouter le trafic (sniffing) pour capturer les paquets et casser la clé avec la suite aircrack-ng.

# 1. Passer la carte Wi-Fi en mode écoute (Monitor)
ifconfig wlx002401a26b93 down
iwconfig wlx002401a26b93 mode monitor
ifconfig wlx002401a26b93 up

# 2. Scanner les réseaux WEP environnants
airodump-ng --encrypt wep wlx002401a26b93

# 3. Cibler un réseau précis (BSSID) sur son canal (ex: canal 3) et enregistrer le trafic
airodump-ng -c 3 --bssid A2:63:91:9E:4D:41 -w /root/wep_simple wlx002401a26b93

# 4. Craquer la clé WEP à partir du fichier capturé (.cap)
aircrack-ng wep_simple-01.cap

# (Variante pour le WPA2 avec un dictionnaire de mots de passe comme rockyou)
aircrack-ng wpa_handshake.cap -w dictionary.txt

Challenge C302 : Authentification réseau avec RADIUS et LDAP / AD

📚 Ressources :

Retour en haut

🧱 C303. DMZ, pare-feu & VPN

Objectif : Isoler pour mieux protéger. La segmentation réseau est la base de toute architecture sécurisée. On apprend ici à exposer des services sur Internet (Web, VPN, Mail) tout en contenant le risque pour ne pas compromettre le réseau interne.

1. Le Concept de DMZ (Zone Démilitarisée)

Pour comprendre la DMZ, l'analogie du château fort est parfaite :

  • Le LAN (Réseau Local) : C'est le donjon au centre. Il abrite les données critiques et les utilisateurs internes.
  • La DMZ : C'est la cour extérieure. On y accueille les marchands et les visiteurs, mais sous haute surveillance.
  • Internet : C'est l'extérieur du château. Tout le monde y est, y compris les assaillants.

Le principe clé : On accepte que la DMZ soit plus exposée aux attaques. Cependant, si un attaquant compromet un serveur dans la DMZ, le donjon (LAN) reste protégé par un second niveau de filtrage. Règle absolue : Il ne doit jamais y avoir de route directe entre Internet et le LAN ! Un serveur Web ne doit jamais être placé directement dans le LAN.

2. Les Règles de Flux (Qui parle à qui ?)

Un pare-feu ne sert à rien si les règles sont floues. Voici les standards de communication inter-zones :

  • 🌐 Internet → DMZ : Autorisé uniquement sur des services précis (ex: HTTP 80, HTTPS 443). Tout le reste est bloqué.
  • ⚠️ DMZ → LAN : C'est la règle la plus importante et elle doit être très limitée. On autorise uniquement ce qui est vital (ex: le serveur Web en DMZ a le droit de parler au serveur de Base de Données dans le LAN sur le port 3306). Jamais d'accès libre.
  • 🛠️ LAN → DMZ : Autorisé selon les besoins stricts (ex: port SSH 22 pour que l'administrateur gère le serveur, ou flux de monitoring).
  • 🌍 LAN → Internet : Généralement autorisé pour la navigation et les mises à jour, mais souvent filtré (proxy, inspection).
  • ⛔ Règle finale (Deny by default) : Source Any -> Destination Any = DENY. Si un flux n'est pas explicitement autorisé, il est bloqué.

3. NAT & Redirections de port

Pour exposer un service situé en DMZ vers l'extérieur, on utilise le DNAT (Destination NAT ou Redirection de port).

  • Le mécanisme : Lorsqu'une requête arrive d'Internet vers votre IP publique sur le port 443, le routeur la redirige vers l'IP privée de votre serveur en DMZ sur ce même port 443.
  • Attention : Une règle de NAT ne suffit pas. Elle doit toujours être accompagnée de la règle de pare-feu associée pour autoriser le flux.

4. L'outil : pfSense

Pour mettre tout cela en place, on s'appuie sur pfSense.

  • Avantages : C'est une solution open-source, gratuite, avec une interface web intuitive.
  • Fonctionnalités : Il est parfait pour créer des interfaces physiques/virtuelles (DMZ, LAN, WAN), configurer des règles d'isolation, créer des "Alias" (pour regrouper des IPs ou des ports et rendre les règles lisibles), et auditer les logs.

5. Rappels VPN (Réseaux Privés Virtuels)

(Rappel synthétique sur les VPN, qui sont typiquement des services exposés sur le pare-feu)

  • VPN Site-à-Site : Permet de relier deux réseaux distants (ex: le siège de l'entreprise et une agence) via un tunnel chiffré sur Internet. Pour les utilisateurs des deux sites, c'est comme s'ils étaient sur le même réseau local (LAN étendu). Les pare-feux (comme pfSense) se chargent de monter et maintenir le tunnel.
  • VPN Client-à-Site (Nomade) : Permet à un utilisateur distant (en télétravail ou en déplacement) de se connecter de manière sécurisée au réseau de l'entreprise. L'utilisateur installe un client logiciel (ex: OpenVPN, WireGuard) qui crée un tunnel vers le pare-feu de l'entreprise.

Challenge C303 :

  • Mise en place d'une zone DMZ isolée avec un serveur web, règles de pare-feu et redirection de port NAT.

  • Challenge VPN & Authentification Radius

📚 Ressources :

Retour en haut

🚨 C304. Détection, Prévention et SIEM (Suricata & Wazuh)

Objectif : Surveiller activement le trafic pour repérer ce qui passe au travers du pare-feu. On découvre comment analyser les paquets à la volée avec un moteur de détection (Suricata) et comment centraliser toutes les alertes de l'infrastructure dans un tableau de bord unique (Wazuh).

1. L'Analyse du Trafic : IDS vs IPS

Sur le réseau, on peut choisir d'être un simple observateur ou d'intervenir activement. Suricata est un moteur open-source de référence qui peut jouer les deux rôles.

💡 L'analogie de la boîte de nuit :

  • Le Pare-feu : C'est le physionomiste à la porte. Il vérifie l'invitation (le port/l'IP) et bloque ceux qui n'ont pas le droit d'entrer.
  • L'IDS : C'est la caméra de surveillance à l'intérieur. Elle observe les comportements bizarres, mais n'intervient pas.
  • L'IPS : C'est le videur à l'intérieur. S'il voit un comportement dangereux, il intervient et sort le perturbateur.
ModeFonctionnement sur le réseauAvantageInconvénient
IDS (Intrusion Detection System)Passif. Il écoute une copie du trafic (via un port miroir / SPAN), et génère uniquement des alertes.Aucun impact sur le réseau en cas de panne de l'IDS.Ne bloque rien, l'attaque passe.
IPS (Intrusion Prevention System)Actif (Inline). Il se place en coupure du flux. Le trafic doit le traverser. Il peut bloquer.Protection active et immédiate.Peut bloquer du trafic légitime (faux positif) ou créer un goulot d'étranglement.

2. Comment Suricata détecte-t-il une attaque ?

Suricata analyse les paquets réseau et les compare à un dictionnaire de signatures (des règles). Si le trafic correspond à une règle, il déclenche l'action prévue.

Une règle se divise en deux parties : le Header (Action, IP, Ports) et les Options (Ce qu'on cherche dans le paquet).

Exemple d'une règle type :

alert http any any -> any any (msg:"ET ATTACK_RESPONSE id check returned root"; content:"uid=0(root)"; sid:2100498; rev:7;)

Décryptage de la syntaxe :

  • Le Header (L'entête) :

    • alert : L'action à effectuer (peut aussi être drop en mode IPS, ou pass).
    • http : Le protocole réseau ciblé.
    • any any -> any any : Le sens du flux. Ici : IP Source Port Source -> IP Destination Port Destination (Tout le trafic vers tout le trafic).
      Note : On utilise souvent des variables comme $EXTERNAL_NET pour l'IP source et $HTTP_SERVERS pour la destination afin de cibler précisément.

  • Les Options (Le corps de la règle) :

    • msg : Le nom de l'alerte qui s'affichera dans les logs.
    • content:"uid=0(root)" : Le motif précis à chercher dans la charge utile (payload) du paquet.
    • sid:2100498 : Le Signature ID (l'identifiant unique de cette règle).
    • rev:7 : La version de la règle (pratique pour les mises à jour).

3. Le SIEM : La Tour de Contrôle (Wazuh)

Si l'on a 5 routeurs, 3 switchs, 10 serveurs et un IDS Suricata, analyser les logs un par un est impossible et provoque la "Fatigue des alertes" (trop d'alertes tuent l'alerte). C'est là qu'intervient le SIEM (Security Information and Event Management). Il collecte, normalise, corrèle les événements et lance des alertes de manière centralisée.

L'écosystème Wazuh (SIEM open-source) repose sur 3 briques :

ComposantRôlePorts standard
Wazuh Manager (Serveur)Le "cerveau". Reçoit les logs envoyés par les agents, décode les données et applique les règles de détection globales.1514, 1515, 55000
Wazuh IndexerLa "mémoire". Stocke et indexe les événements de manière très rapide (basé sur le moteur Elasticsearch/OpenSearch).9200
Wazuh DashboardL'interface. Le portail web d'investigation pour les analystes sécurité (basé sur Kibana/OpenSearch Dashboards).443

4. Architecture et Remontée des Logs (Le Workflow)

Pour que la détection soit efficace, le SIEM doit fusionner les événements purement réseaux (IDS) et les événements systèmes (OS).

  • L'Agent Wazuh : Installé sur les machines, il lit les événements locaux (journaux d'événements Windows, Syslog Linux, vérification d'intégrité des fichiers FIM, rootkits) et les transmet au serveur.
  • Le lien avec Suricata : Suricata génère un fichier de logs très détaillé au format JSON (eve.json). L'agent Wazuh est configuré pour lire ce fichier en temps réel et remonter les alertes réseau au SIEM.
       Sources                         SIEM Wazuh
    ┌──────────┐                   ┌──────────────────┐
    │ Suricata │──── eve.json ────>│  Wazuh Manager   │
    │  (IDS)   │   via agent       │        │         │
    └──────────┘                   │        ▼         │
                                   │  Wazuh Indexer   │
    ┌──────────┐                   │        │         │
    │  Win11   │──── syslog ──────>│        ▼         │
    │ (cible)  │   via agent       │ Wazuh Dashboard  │
    └──────────┘                   └──────────────────┘

Atelier C304 : Dans cet atelier, nous allons mettre en place une chaîne de détection et de supervision complète. L'idée est simple : un capteur réseau (Suricata) détecte les menaces, puis remonte ses alertes vers un SIEM centralisé (Wazuh) pour la visualisation et la corrélation. C'est exactement ce qu'on retrouve dans un SOC (Security Operations Center) en entreprise.

📚 Ressources :

Retour en haut

🧱 C305. Sécurité Linux (Pare-feu & SSH)

Objectif : Protéger le serveur de l'intérieur. On configure le pare-feu local (netfilter) en appliquant le principe du "Deny by default", et on blinde l'accès d'administration (SSH) en remplaçant les mots de passe vulnérables par de la cryptographie asymétrique.

1. Le Pare-feu Linux : La mécanique Netfilter

netfilter n'est pas une commande, c'est le moteur directement intégré au noyau Linux. C'est lui qui intercepte réellement les paquets.

A. Comment réfléchit Netfilter ?

Il fonctionne avec des chaînes (les zones de contrôle) et des actions.

  • Les 3 chaînes principales :

    • INPUT : Le trafic à destination du serveur lui-même (ex: un client web qui se connecte).
    • OUTPUT : Le trafic généré par le serveur vers l'extérieur (ex: le serveur télécharge une mise à jour).
    • FORWARD : Le trafic qui ne fait que transiter (si Linux agit comme un routeur).

  • Les 4 actions possibles :

    • ACCEPT : Laisse passer.
    • DROP : Jette le paquet silencieusement (idéal pour bloquer les scans de ports).
    • REJECT : Refuse mais renvoie un message d'erreur à l'expéditeur.
    • LOG : Garde une trace dans les journaux système.

netfilter

B. Les 3 Outils de configuration (Les interfaces)

Pour parler à netfilter, on utilise des outils en ligne de commande. Voici les commandes pratiques pour un cas classique : Bloquer tout, sauf SSH et le Web.

  • 1. iptables (Le standard historique, très verbeux mais incontournable en prod) :
iptables -P INPUT DROP # /!\ Coupe tout accès instantanément si tapé en premier !
iptables -A INPUT -s 192.168.1.100 -p tcp --dport 22 -j ACCEPT # SSH restreint à une IP admin
iptables -A INPUT -p tcp --dport 80 -j ACCEPT # Web (http)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT # Web Sécurisé (https)

# Afficher les règles actives avec statistiques
iptables -L -n -v

iptables ne sauvegarde rien sans la persistance

# Installer le paquet pour sauvegarder les règles iptables au redémarrage
apt install -y iptables-persistent

# Sauvegarder les règles pour qu'elles persistent après redémarrage
netfilter-persistent save
  • 2. nftables (Le remplaçant moderne, syntaxe propre et unifie IPv4/IPv6) :
nft add rule inet filter input tcp dport 22 accept
nft add rule inet filter input tcp dport { 80, 443 } accept

Il se configure dans un fichier /etc/nftables.conf

nano /etc/nftables.conf

# Afficher le ruleset actif
nft list ruleset

# Charger la configuration depuis le fichier
nft -f /etc/nftables.conf

# Sauvegarder le ruleset actuel dans le fichier de configuration
nft list ruleset > /etc/nftables.conf
  • 3. ufw (Uncomplicated Firewall - Surcouche simplifiée, parfait pour des besoins basiques) :
ufw default deny incoming
ufw allow from 192.168.1.100 to any port 22
ufw allow 80,443/tcp
ufw enable

# Afficher le statut d'UFW et toutes les règles actives
ufw status verbose

💡 Le conseil de survie réseau : L'erreur classique est de taper la commande de blocage par défaut (DROP) avant d'avoir autorisé le port 22... Résultat : on s'enferme dehors. L'astuce de pro : Lancer un script Cron qui réinitialise le pare-feu toutes les 5 minutes pendant qu'on fait nos tests. Si on se trompe, on attend 5 minutes et l'accès revient.

2. Hardening SSH : L'art de verrouiller la porte

Un serveur avec le port 22 ouvert sur Internet reçoit ses premières attaques par "brute-force" (test de milliers de mots de passe) en moins de 10 minutes. Le compte le plus ciblé est root.

A. La Cryptographie Asymétrique (Les Clés)

On supprime les mots de passe au profit d'une paire de clés.

  1. Génération (Sur le PC Admin) : L'algorithme ed25519 est le standard moderne.
ssh-keygen -t ed25519 -C "admin@nom_serveur"
  1. Envoi au serveur :
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@ip_du_serveur
  1. Les Permissions (Le piège !) : SSH est paranoïaque. Si le dossier contenant les clés sur le serveur est lisible par d'autres, SSH refuse la connexion silencieusement.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
B. Durcissement du fichier sshd_config

C'est ici que l'on verrouille le comportement du serveur (/etc/ssh/sshd_config). Voici une configuration durcie complète :

# --- Authentification ---
PermitRootLogin no              # Bloque la connexion directe du super-administrateur
PasswordAuthentication no       # Coupe le brute-force instantanément (les mots de passe sont refusés)
PubkeyAuthentication yes        # Oblige l'usage de la clé SSH

# --- Accès et Sécurité ---
AllowUsers admin deployer       # Liste blanche : seuls ces utilisateurs ont le droit d'utiliser SSH
Port 2222                       # Sécurité par obscurité : échappe aux bots basiques qui scannent le port 22
ClientAliveInterval 300         # Déconnecte les sessions inactives après 5 minutes (300 sec)
C. Le Workflow Zéro-Risque (Éviter de s'enfermer dehors)

Modifier sshd_config est très risqué. Voici la procédure stricte :

  1. Ouvrir deux terminaux connectés en SSH.
  2. Configurer et envoyer sa clé SSH.
  3. Tester la connexion par clé.
  4. Éditer sshd_config (couper le mot de passe) sur le Terminal 1.
  5. Vérifier la syntaxe (sudo sshd -t) et redémarrer le service (sudo systemctl restart sshd).
  6. NE SURTOUT PAS FERMER LE TERMINAL 1. Ouvrir un troisième terminal et tester la nouvelle connexion. En cas de problème de syntaxe ou de droits (ex: SELinux qui bloque la lecture de la clé), le Terminal 1 reste actif pour réparer.

💡 Tips : Pour oublier l'utlisation d'une clef SSH sur une IP (nouvelle VM etc message d'erreur : WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!) il faut utiliser ssh-keygen -R <IP_DE_LA_MACHINE>

Atelier C305 : Sécurisation d’un serveur Debian exposé sur Internet, durcissement minimal du système et restriction stricte des accès SSH.

📚 Ressources :

Retour en haut

🛡️ C306. PAM, Logs, Fail2ban & Port-Knocking

Objectif : Durcir l'authentification du système de manière globale (PAM), surveiller activement qui tente de rentrer (Logs), bloquer automatiquement les attaquants (Fail2ban/CrowdSec) et réduire la surface d'attaque en cachant les services (Port-knocking).

1. PAM (Pluggable Authentication Modules)

Sur Linux, de nombreux services ont besoin d'authentifier les utilisateurs (SSH, sudo, login local, su...). Sans PAM, chaque service aurait sa propre logique et ses propres failles . PAM unifie tout cela : c'est la "prise électrique standard" de l'authentification .

A. Les 4 phases de PAM

PAM ne fait pas que vérifier un mot de passe, il gère 4 étapes distinctes :

  1. auth : Vérifie l'identité (mot de passe, clé, biométrie...).
  2. account : Vérifie si le compte a le droit de se connecter (compte expiré ? heures autorisées ?).
  3. password : Impose des règles lors du changement de mot de passe (complexité).
  4. session : Prépare et nettoie l'environnement (montage de dossiers, quotas, logs).
B. Configuration et Syntaxe

Les fichiers de configuration se trouvent dans /etc/pam.d/ (un fichier par service : sshd, sudo, su...) . La syntaxe d'une règle est : type control module [arguments].

Les "Control Flags" (Comportements):

  • required : Le module doit réussir. S'il échoue, PAM continue quand même de lire les autres règles (pour ne pas indiquer à l'attaquant à quelle étape il a échoué) mais refusera l'accès à la fin.
  • requisite : Obligatoire. Si échec, PAM rejette l'accès immédiatement.
  • sufficient : Si ce module réussit, l'accès est accordé tout de suite (on ignore la suite).
  • optional : N'est pris en compte que si aucun autre module n'a donné de résultat.
C. Modules indispensables à connaître
  • pam_unix : Authentification locale classique (via /etc/shadow).
  • pam_faillock : Verrouille le compte après X échecs.
  • pam_pwquality : Impose la complexité des mots de passe.
  • pam_wheel : Restreint l'utilisation de su (devenir root) aux seuls membres du groupe wheel.

2. Audit et Logs de connexion (last / lastb)

Avant de se défendre, il faut comprendre les attaques. Un serveur exposé laisse des traces dans ses journaux.

  • last (Les succès) : Lit le fichier binaire /var/log/wtmp. Affiche l'historique des connexions réussies (qui, depuis quelle IP, quand, combien de temps).

  • lastb (Les échecs) : Lit le fichier binaire /var/log/btmp. Affiche l'historique des connexions échouées. Idéal pour repérer un brute-force en cours (ex: des dizaines d'échecs sur le compte root en quelques minutes) .

3. Défense Active : Fail2ban & CrowdSec

Lire les logs c'est bien, mais bloquer automatiquement les attaquants à 3h du matin, c'est mieux.

A. Fail2ban (Le classique) Fail2ban surveille les fichiers de logs en temps réel. S'il détecte trop d'échecs, il crée une règle de pare-feu (iptables/nftables) pour bannir l'IP .

  • Filter : Une expression régulière (regex) qui repère les lignes d'erreur dans les logs.

  • Jail (Prison) : Associe un filtre à des seuils et une action.

  • Configuration : On ne modifie jamais jail.conf (qui est écrasé aux mises à jour). On crée un fichier jail.local ou dans jail.d/ .

  • Paramètres clés :

    • maxretry = 5 : Nombre d'échecs tolérés.
    • findtime = 10m : Fenêtre de temps (5 échecs en 10 minutes).
    • bantime = 1h : Durée du bannissement.

B. CrowdSec (L'alternative moderne et collaborative) (Ajout hors-slides) Là où Fail2ban travaille seul dans son coin, CrowdSec est un IPS moderne, open-source, et collaboratif.

  • Le principe : Il analyse les logs (plus rapidement que Fail2ban car écrit en Go). Lorsqu'il détecte une attaque, non seulement il bloque l'IP localement, mais il la partage avec le réseau mondial de CrowdSec (CTI - Cyber Threat Intelligence).
  • L'avantage massif : Si un attaquant a déjà attaqué d'autres serveurs dans le monde, votre serveur le bloquera de manière préventive avant même qu'il ne tente de vous attaquer, grâce à la liste de blocage communautaire.
  • Architecture : Il sépare le moteur de détection (qui lit les logs) des "Bouncers" (les agents qui bloquent le trafic, applicables sur le Firewall, Nginx, WordPress, etc.).

4. Réduire l'exposition : Le Port-Knocking

Pourquoi laisser le port SSH (22) ouvert à tous les bots d'Internet ? Le principe du Port-Knocking est de fermer le port par défaut .

  • Le Concept : Le port n'existe pas pour l'extérieur. Pour l'ouvrir, vous devez "frapper" à la porte sur une séquence de ports précis (ex: ping le port 7000, puis 8000, puis 9000). Le pare-feu détecte la séquence secrète et ouvre le port 22 uniquement pour votre adresse IP .

  • L'outil : knockd. Configuré dans /etc/knockd.conf.

  • Les limites : C'est de la sécurité par obscurité. La séquence transite "en clair" sur le réseau. Un attaquant qui écoute le trafic pourrait la capturer et la rejouer.

  • L'évolution (SPA) : Pour pallier cela, on utilise le SPA (Single Packet Authorization) avec des outils comme fwknop. Au lieu d'une séquence de ports, on envoie un seul paquet réseau crypté contenant un jeton d'authentification .

💡 Le Conseil "Production" : Le Trio Gagnant

En entreprise, pour un serveur exposé de manière robuste, on combine 3 couches qui ne se remplacent pas, elles s'additionnent :

  1. Clés SSH (Mot de passe coupé) : Rends le brute-force mathématiquement impossible.
  2. Fail2ban / CrowdSec : Bannit les IP qui "polluent" les logs et s'acharnent inutilement, allégeant la charge du serveur.
  3. Port-knocking (ou SPA / VPN) : Rend le service SSH invisible aux scanners (comme Shodan), réduisant la surface d'attaque à zéro pour les non-initiés.

Atelier C306 : Sécurisation d'un serveur Linux contre les attaques par force brute avec Fail2ban et Knockd

📚 Ressources :

  • Exemple configurations PAM, Google Authenticator, last, lastb, fail2ban, knockd et crodwsec : ici
  • Documentation Crowdsec : https://doc.crowdsec.net/

Retour en haut

🌐 C307. Reverse-proxy, Load-balancer, HTTPS & Anti-DDoS

Objectif : Créer un point d'entrée unique et robuste pour une infrastructure web. On chiffre les échanges (HTTPS), on masque les serveurs internes (Reverse-proxy), on répartit la charge en cas de fort trafic (Load-balancer) et on protège les ressources contre la saturation malveillante (Rate-limiting & Anti-DDoS).

1. Chiffrement et Certificats (HTTPS & TLS)

Le HTTP brut fait transiter les données en clair sur le réseau (mots de passe, données sensibles), ce qui permet les attaques de l'homme du milieu (Man-in-the-Middle). Le protocole TLS (successeur de SSL) vient encapsuler et chiffrer ces données.

  • Le certificat TLS : Il garantit l'identité du serveur (il contient le nom de domaine, la clé publique, la signature d'une autorité de certification et une date d'expiration).

  • Types de certificats:

    • Auto-signé : Créé localement via openssl. Provoque un avertissement dans le navigateur (parfait pour du lab).
    • Let's Encrypt : Autorité de certification gratuite et automatisée (le standard actuel pour le web public).

  • L'outil Certbot : Il automatise l'obtention du certificat Let's Encrypt, modifie la configuration du serveur web (Nginx/Apache) pour l'appliquer, et gère le renouvellement automatique (qui a lieu tous les 90 jours).

2. Le Reverse-Proxy (L'intermédiaire)

Exposer directement tous ses serveurs web sur Internet est complexe (il faudrait un certificat par serveur) et peu sécurisé. Le Reverse-Proxy se place devant eux.

  • Analogie : C'est la réceptionniste d'un hôtel. Le client parle uniquement à la réception, qui relaie la demande au bon service. Le client ne voit jamais les "cuisines" (les serveurs back-end) .

  • La Terminaison TLS (L'avantage ultime) : Le client se connecte en HTTPS (chiffré) jusqu'au Proxy. Le Proxy déchiffre la requête et la transmet en HTTP (clair) aux serveurs internes.

    • Gain : Un seul certificat à gérer sur le proxy, et on allège le processeur (CPU) des serveurs back-end.

Configurations Types :

  • Nginx (Souvent préféré car plus léger et performant ) : Utilise la directive proxy_pass http://IP_BACKEND. Attention : Il faut passer les "headers" (proxy_set_header Host $host et X-Real-IP) sinon le back-end croira que toutes les requêtes viennent du proxy lui-même.

  • Apache : Utilise les directives ProxyPass, ProxyPassReverse et ProxyPreserveHost On .

3. Répartition de Charge & Haute Disponibilité (HAProxy)

Si un seul serveur reçoit 1000 clients, il sature. Un Load-Balancer (comme HAProxy) est un reverse-proxy dopé : il distribue le trafic sur une grappe de serveurs.

  • Algorithmes de répartition:

    • Round Robin : À tour de rôle (Serveur 1, puis 2, puis 3...).
    • Least Connections : Vers le serveur qui a le moins de travail en cours.
    • Source (IP Hash) : Un client donné retombera toujours sur le même serveur (utile pour garder une session active).

  • Health Checks (Haute Dispo) : HAProxy interroge les serveurs en permanence (ex: toutes les 5 secondes). Si un serveur ne répond plus, HAProxy le marque "DOWN" et l'exclut de la rotation automatiquement, évitant ainsi des erreurs aux utilisateurs.

  • Architecture HAProxy : Le fichier de configuration se divise en deux zones clés : frontend (la porte d'entrée qui écoute le client) et backend (les coulisses avec les serveurs réels) .

4. Résister aux attaques (DDoS & Rate-Limiting)

Le pare-feu réseau classique laisse passer le trafic web (port 80/443), il ne peut donc pas différencier un vrai client d'un botnet.

A. Attaques Niveau L4 (Ex: SynFlood)

  • Le principe : L'attaquant envoie des milliers de requêtes de connexion (SYN) avec des IP sources falsifiées, mais ne répond jamais à la suite (pas de ACK). La "table d'attente" du serveur se remplit et sature, bloquant les vrais clients .

  • La parade (OS) : On active les SYN Cookies dans le noyau Linux (sysctl -w net.ipv4.tcp_syncookies=1) pour contourner cette table. On peut aussi utiliser iptables/nftables (hashlimit) pour restreindre le nombre de requêtes SYN par seconde.

B. Attaques Niveau Applicatif L7 (Ex: HTTP Flood)

L'attaquant envoie des requêtes HTTP parfaitement formées (ex: spammer le formulaire de login) pour épuiser la RAM et le CPU.

  • La parade (Rate-Limiting) : On limite le nombre de requêtes autorisées par IP.

    • Sous Nginx : directive limit_req_zone.
    • Sous HAProxy : utilisation de stick-table.

  • La notion de "Burst" : Indispensable en production. Si on limite à 10 requêtes/sec, un vrai client chargeant une page avec beaucoup d'images sera bloqué à tort. Le burst autorise des pics ponctuels (ex: un pic de 20 d'un coup) avant de sévir.

  • Le serveur renverra alors l'erreur 429 Too Many Requests aux attaquants.

💡 Le Conseil "Production"

La défense est multicouche. Une seule technologie ne suffit pas pour un serveur très exposé. Le schéma idéal :

  1. L3/L4 : Pare-feu (Bloque les ports inutiles et limite les connexions TCP pures avec hashlimit).

  2. L7 : Reverse-Proxy (Rate-limiting, requêtes par IP via Nginx/HAProxy).

  3. Outils de test : Toujours valider vos limites avec un outil de stress-test comme ab (ApacheBench) ou siege pour vérifier que les attaquants reçoivent bien des erreurs 429 sans casser le site pour les autres.

Atelier C307 : Mise en place de HTTPS sur une ou plusieurs apps, de reverse-proxy et load-balancer avec Nginx, Apache et HAProxy. Durcissement, Mitigation DDoS, et rate-limiting

📚 Ressources :

Retour en haut

🛡️ C308. SSO, IAM & WAF (Identités & Sécurité Web)

Objectif : Sécuriser les accès utilisateurs en centralisant l'authentification via un Fournisseur d'Identité (SSO/IAM), et protéger les applications web contre les vulnérabilités du code (comme les injections SQL) grâce à un pare-feu applicatif (WAF) et un CDN.

1. IAM & SSO : La fin du cauchemar des mots de passe

Gérer 10 applications avec 10 comptes différents pour un même utilisateur est un désastre en matière de sécurité (mots de passe faibles, réutilisation, post-its sous le clavier).

  • IAM (Identity and Access Management) : C'est la gouvernance complète. L'IAM gère le cycle de vie de l'utilisateur (arrivée, modification de droits, départ) et centralise les rôles et les accès.
  • SSO (Single Sign-On) : C'est la fonctionnalité visible par l'utilisateur. Il s'authentifie une seule fois sur un portail central, et accède automatiquement à toutes les autres applications sans avoir à se reconnecter.
  • L'Architecture :
    • L'IdP (Identity Provider) : Le composant central (ex: Keycloak) qui vérifie l'identité et émet les "jetons" d'accès.
    • Le SP (Service Provider) : L'application (ex: Nextcloud, GLPI) qui délègue l'authentification à l'IdP et consomme le jeton.

2. Les Protocoles d'Authentification

Pour que l'application (SP) et le serveur d'identité (IdP) se comprennent, ils utilisent des protocoles standards.

  • SAML 2.0 : L'ancien standard, basé sur des échanges de fichiers XML. Il est lourd, mais reste la norme absolue dans les grandes entreprises (hôpitaux, banques).
  • OAuth 2.0 : Ce n'est pas un protocole d'authentification, mais un framework d'autorisation. Il permet de donner accès à des ressources sans donner son mot de passe (ex: "Autoriser l'application X à lire mes contacts").
  • OpenID Connect (OIDC) : C'est la couche moderne d'authentification construite par-dessus OAuth 2.0. Plus léger que SAML, idéal pour les applications web modernes et mobiles.
    • Le JWT (JSON Web Token) : C'est le format du "badge d'accès" émis par OIDC. Il est auto-contenu et signé cryptographiquement. L'application peut vérifier la validité du JWT sans même avoir besoin de recontacter l'IdP.

3. Les Outils : Keycloak & Authentik

Keycloak (développé par Red Hat) et Authentik sont les leaders open-source pour construire son propre IdP (Identity Provider). Ils gèrent OIDC, SAML, et peuvent se connecter à un annuaire existant (comme LDAP ou Active Directory).

Concepts clés (exemple Keycloak) :

  • Realm (Royaume) : Un espace isolé. Un serveur Keycloak peut héberger plusieurs Realms totalement indépendants (ex: un pour les employés, un pour les clients).
  • Clients : Ce sont les applications (SP) qui ont le droit de demander des authentifications au Realm.

⚙️ Durcissement (Hardening) de l'IdP :

Le serveur SSO devient la clé de voûte du réseau. S'il tombe, plus personne ne se connecte. Il faut le protéger :

  • Activer la Brute Force Detection (ex: bloquer après 5 échecs).
  • Gérer les Sessions (ex: déconnexion automatique après 30 min d'inactivité).
  • Imposer le MFA (Authentification multifacteur, ex: TOTP avec Google Authenticator).

4. Le WAF (Web Application Firewall)

Le pare-feu réseau (L3/L4) laisse passer les ports 80 et 443, il est donc aveugle face au contenu malveillant caché dans le trafic HTTP (injections SQL, failles XSS, traversée de répertoires - le fameux Top 10 OWASP).

Le WAF opère sur la couche 7 (Applicative). Il ouvre chaque requête HTTP, l'analyse, et la bloque si elle contient un motif d'attaque.

  • Fonctionnement par règles & score : Le WAF compare la requête à des milliers de signatures (ex: le mot clé UNION SELECT). Si le "score d'anomalie" dépasse un seuil, la requête est rejetée (erreur 403 Forbidden).

  • Les 2 Modes :

    1. Détection : Analyse et log, mais ne bloque rien. (Toujours commencer par là en production pour repérer les faux positifs).
    2. Prévention : Bloque activement le trafic malveillant.

  • L'outil On-Premise : ModSecurity

    • Le WAF open-source de référence, qui s'intègre directement dans Nginx ou Apache.
    • Il s'accompagne de l'OWASP CRS (Core Rule Set) : un dictionnaire maintenu par la communauté regroupant les règles bloquant les attaques connues.

5. CDN et Cloudflare (La solution Cloud)

Plutôt que d'installer un WAF localement (ce qui consomme beaucoup de CPU sur le serveur), on peut le déporter dans le Cloud via un service comme Cloudflare.

  • Le rôle du CDN (Content Delivery Network) : Un réseau de serveurs répartis mondialement. Il met en cache les fichiers statiques (images, CSS). Si un utilisateur japonais demande votre site hébergé à Paris, c'est le serveur CDN de Tokyo qui lui répondra, soulageant ainsi votre propre serveur.
  • Cloudflare (Proxy Cloud) : En modifiant les DNS pour pointer vers Cloudflare, Cloudflare agit comme un immense Reverse-Proxy mondial.
  • Avantages combinés :
    • Il encaisse les gigantesques attaques DDoS volumétriques.
    • Il fait office de WAF managé (il filtre les attaques HTTP avant même qu'elles n'atteignent votre pays).
    • Il réduit la charge de votre infrastructure (CDN).

💡 La "Big Picture" de la Saison 3 : La Défense en Profondeur

Pour clôturer cette saison réseau et sécurité, voici l'architecture idéale complète d'un paquet réseau qui arrive sur votre infra :

  1. Internet (La source du trafic).
  2. Cloudflare (CDN / Anti-DDoS / WAF Cloud) : Absorbe les térabits de trafic et filtre les injections grossières.
  3. Pare-feu Réseau (pfSense / Iptables) : Bloque les ports illégitimes et les IPs malveillantes (L3/L4).
  4. Reverse-Proxy Local (Nginx / HAProxy) : Gère le Rate-Limiting, termine le chiffrement TLS et masque la topologie interne.
  5. Serveur SSO (Keycloak) : S'assure que l'utilisateur est bien authentifié (MFA) avant qu'il ne touche aux données.
  6. L'Application (Back-end) : Valide la logique métier.

Atelier C308 : Déploiement d'un SSO Keycloak et intégration avec Vault, intégration d'une deuxième application (Nextcloud), et sécurité couche 7 avec WAF ModSecurity + OWASP CRS

📚 Ressources :

Retour en haut

Précédent

☁ Cloud

Suivant

📦 Conteneurs et orchestration