Architecture réseau et positionnement des solutions IDS / IPS¶

1. Objectif du cours¶

Analyser une infrastructure réseau pour identifier les points de déploiement stratégiques d'IDS/IPS et concevoir des architectures sécurisées (on‑premise, multi‑site, cloud) tout en maîtrisant risques, coûts et exploitation.

2. Notions et définitions essentielles¶

Point de convergence / point de passage obligé : emplacement où transite un grand nombre de flux (passerelles Internet, interconnexions de sites, trunk VLAN).
DMZ : zone tampon entre réseau interne et Internet hébergeant services exposés.
Segmentation / micro‑segmentation : division du réseau en zones avec politiques spécifiques ; la micro‑segmentation isole au niveau application/serveur.
Déploiement en ligne (inline) : sonde placée sur le chemin actif du trafic (peut bloquer).
Déploiement hors bande (passif/TAP) : sonde reçoit copie du trafic, n'interrompt pas la production.
Agents virtuels / services natifs cloud : composants installés sur ressources cloud pour compenser la perte de visibilité réseau physique.
Meta‑surveillance : surveillance des sondes IDS/IPS elles‑mêmes (intégrité, heartbeat, logs).

3. Fonctionnement et principes¶

Cartographie préalable obligatoire : inventaire équipement, extraction VLAN, traçage des flux réels pour repérer carrefours stratégiques.
Priorisation : positionner sondes sur peu de points de convergence permet une couverture maximale à moindre coût.
Adaptation au contexte : choisir inline si réaction automatique et critique (finance, santé) ; hors bande si continuité de service prioritaire (production industrielle).
Segmentation pour réduire le bruit et limiter les mouvements latéraux : DMZ, zones Dev/Test/Prod distinctes ; micro‑segmentation pour isoler R&D ou bases sensibles.
En cloud, le périmètre disparaît : utiliser services natifs + agents + SIEM central pour corrélation multi‑environnements.
Protéger les sondes : un IDS compromis peut masquer des attaques, modifier règles ou logs ; il faut durcir et surveiller les sondes comme des actifs critiques.

4. Commandes et manipulations¶

Nmap : découverte automatique (ping sweep puis scans de ports) pour identifier hôtes et services.
Lansweeper (ou équivalent) : inventaire automatisé via SNMP/WMI pour construire une base d'équipements.
Netstat / TCPView : observation des connexions actives locales pour tracer communications réelles.
Wireshark : capture et analyse détaillée du trafic réseau pour examiner protocoles et contenus (si déchiffré).
Outils d'orchestration : Ansible, Terraform, Illumio — déploiement/maintien des politiques de micro‑segmentation et automatisation.
Services cloud natifs : Azure Security Center, AWS GuardDuty, GCP Security Command Center — détection et analyses spécifiques au fournisseur.
SIEM central : collecte et corrélation des logs/alertes provenant des sondes et services cloud.
Remarque : le cours présente ces outils et leur rôle ; il ne fournit pas de scripts détaillés.

5. Sécurité et bonnes pratiques¶

Durcissement hôte IDS/IPS : installation d'un OS minimal, suppression des packages/services non nécessaires, pare‑feu local restrictif, logs d'administration détaillés, vérification d'intégrité des fichiers critiques.
Gestion SSH : restreindre accès aux IP admin, utiliser clés, fenêtres d'accès limitées, bastion SSH recommandé.
Principe du moindre privilège : comptes dédiés pour services et rôles clairement séparés (analyste, admin, auditeur). Ne pas exécuter les services en root.
Politique de mises à jour différenciée : correctifs OS critiques planifiés, signatures détecteurs automatisées, mises à jour majeures testées en qualification.
Isolation réseau des sondes : interfaces dédiées pour capture, administration et alertes ; pas d'accès direct à Internet ; DMZ de sécurité pour équipements de surveillance.
Meta‑surveillance : centraliser logs, vérifier intégrité des règles, mettre en place heartbeat/process monitoring et alertes en cas d'arrêt ou modification non autorisée.

6. Points essentiels à retenir pour le TSSR¶

Commencer toute démarche par la collecte de la documentation réseau et l'inventaire des équipements.
Identifier les points de convergence (passerelles Internet, interconnexions, trunks VLAN) pour optimiser le positionnement des sondes.
Choisir inline vs hors bande selon criticité métier et tolérance à l'impact sur la production.
Segmenter le réseau (et envisager micro‑segmentation) pour réduire les faux positifs et détecter les mouvements latéraux.
En cloud, combiner agents virtuels, services natifs et centralisation SIEM pour retrouver visibilité et corrélation.
Traiter IDS/IPS comme actifs critiques : durcissement, isolation, mises à jour et surveillance continue.
Prévoir redondance HA (actif‑actif ou actif‑passif) selon les besoins 24/7 et contraintes de maintenance.
Documenter précisément les flux autorisés pour faciliter détection d'anomalies.
Automatiser la gestion de politiques (Ansible/Terraform/Illumio) pour cohérence et évolutivité.
Tester régulièrement (exercices de simulation) la cohérence de la surveillance hybride.

7. Tableau récapitulatif¶

Approche	Avantage principal	Inconvénient
Déploiement en ligne (inline)	Blocage et réaction immédiate	Risque d'impact sur disponibilité si mal géré
Déploiement hors bande (TAP)	Aucun impact sur production	Pas de blocage automatique, réaction manuelle
Micro‑segmentation	Réduction massive des mouvements latéraux	Complexité de mise en œuvre et d'orchestration
Agents virtuels cloud	Visibilité granulaire des workloads	Gestion/scale des agents et maintenance
Services natifs cloud	Intelligence et détection globale du fournisseur	Risque de dépendance au fournisseur (lock‑in)

8. Vérifications pratiques¶

Validation terrain : sessions avec équipes locales pour confirmer la cartographie automatique.
Vérifier que le SIEM central collecte bien les logs/alertes des sondes et services cloud.
Contrôler l'intégrité des règles et fichiers critiques via hachage et alertes en cas de modification.
Surveiller les heartbeats/processus des sondes et déclencher alerte si arrêt.
Exécuter exercices de simulation d'incident pour tester corrélation multi‑environnements et procédures.
Confirmer séparation des interfaces (surveillance vs administration) et absence d'accès direct Internet depuis les sondes.

9. Flashcards Anki¶

Quelle est la première étape méthodologique pour cartographier une infrastructure réseau ? :: Collecter la documentation réseau existante et dresser un inventaire des équipements
Qu'est‑ce qu'une DMZ dans ce cours ? :: Une zone tampon entre le réseau interne et Internet hébergeant services exposés
Quelle différence principale la micro‑segmentation apporte‑t‑elle ? :: Elle crée des zones très granulaires, parfois par application ou serveur
Pourquoi le déploiement inline est‑il choisi pour certains environnements critiques ? :: Pour permettre une réaction automatique et le blocage immédiat des attaques
Pourquoi la surveillance réseau traditionnelle est‑elle problématique en cloud ? :: On ne contrôle pas l'infrastructure physique et ne peut pas intercepter le trafic de manière traditionnelle
Quel rôle joue un SIEM dans une stratégie hybride ? :: Centraliser et corréler les logs/alertes issus des sondes et services cloud pour vision unifiée
Citez une stratégie pour surveiller les flux chiffrés sans inspecter le contenu : :: Analyser les métadonnées (durée, volume, destinations, horaires)
Quelle mesure réseau fondamentale protège les sondes IDS/IPS ? :: Isolation réseau avec interfaces dédiées pour surveillance, administration et alertes
Nommer une pratique recommandée pour l'accès SSH aux sondes : :: Restreindre aux IP admin, utiliser clés cryptographiques et bastion SSH
Quelle mesure permet de détecter une modification non autorisée des règles IDS ? :: Vérification d'intégrité par hachage et alertes en cas de modification