Cas pratiques sécurité reseau

Contexte : Des employés doivent accéder aux ressources internes de l'entreprise depuis l'extérieur du réseau local. Actuellement, certains services internes sont exposés directement sur Internet. Le Problème : Vous devez sécuriser l'accès distant sans exposer les serveurs internes publiquement. Contraintes : Mettre en place un accès via VPN chiffré. L'authentification doit être obligatoire pour tous les utilisateurs. Les ressources internes ne doivent plus être accessibles directement depuis Internet. Livrable attendu : Définir une architecture VPN simple incluant tunnel chiffré, mécanisme d'authentification et règles de filtrage limitant l'accès aux seules ressources autorisées.

Contexte : Un serveur d'administration possède un service SSH accessible depuis n'importe quelle adresse IP. Le Problème : Le port 22 est ouvert publiquement, augmentant le risque d'attaques par brute force. Configuration actuelle : PORT 22 OPEN TO 0.0.0.0/0 Contraintes : Restreindre l'accès SSH à une plage IP interne spécifique. Mettre en place une règle bloquant les connexions répétées suspectes. Aucun impact sur l'administration légitime. Livrable attendu : Corriger la configuration réseau afin de limiter strictement l'accès SSH et réduire la surface d'attaque.

Contexte : Une application interne échange des données sensibles entre deux serveurs via HTTP non chiffré. Le Problème : Les communications circulent en clair sur le réseau interne, ce qui peut permettre l'interception des données. Configuration actuelle : http://internal-service.local Aucun chiffrement n'est activé. Contraintes : Vous devez activer HTTPS avec un certificat valide. Les connexions HTTP doivent être redirigées vers HTTPS. L'intégrité et la confidentialité des données doivent être garanties. Livrable attendu : Mettre en place TLS correctement et forcer l'utilisation de connexions sécurisées pour toutes les communications entre serveurs.

Contexte : L'équipe sécurité constate qu'aucune journalisation des connexions réseau n'est activée sur les équipements critiques. Le Problème : Il est impossible d'identifier l'origine d'une connexion suspecte ou d'analyser un incident. Contraintes : Activer une journalisation des connexions entrantes et sortantes sur le pare-feu. Les logs doivent inclure IP source, destination et port. La performance du système ne doit pas être impactée de manière significative. Livrable attendu : Mettre en place une configuration de journalisation réseau basique permettant la détection et l'analyse d'événements suspects.

Contexte : Des scans de ports répétés ont été détectés sur l'infrastructure exposée à Internet. Le Problème : Le pare-feu ne possède aucun mécanisme simple de limitation ou de détection des tentatives de scan. Contraintes : Mettre en place un mécanisme basique de limitation de connexions ou de blocage temporaire après plusieurs tentatives suspectes. La disponibilité des services légitimes ne doit pas être affectée. Livrable attendu : Ajouter une règle ou configuration simple permettant de réduire l'impact des scans automatisés et d'améliorer la posture de sécurité réseau.

Contexte : Un audit interne révèle qu'un serveur critique est exposé avec une règle de filtrage excessive. Le Problème : La configuration actuelle autorise tout le trafic entrant. Configuration actuelle : ALLOW ALL FROM ANY TO ANY Cette règle ouvre tous les ports et tous les services. Contraintes : Vous devez restreindre l'accès uniquement aux ports nécessaires (443 pour le public et 22 pour l'administration). Le port 22 doit être accessible uniquement depuis 10.0.0.5. Aucun service inutile ne doit rester exposé. Livrable attendu : Corriger la configuration en mettant en place des règles précises, ordonnées et conformes aux bonnes pratiques de sécurité réseau.

Contexte : Votre entreprise vient de mettre en production un serveur hébergeant une application web accessible depuis Internet. Par défaut, toutes les connexions entrantes sont autorisées. Le Problème : Vous devez réduire la surface d'attaque en configurant un pare-feu simple qui limite l'accès uniquement aux services nécessaires. Contraintes : Seuls les ports 80 (HTTP) et 443 (HTTPS) doivent être accessibles publiquement. L'accès SSH doit être limité à l'adresse IP 192.168.1.10. Tout autre trafic entrant doit être bloqué. Aucune solution matérielle externe n'est autorisée. Livrable attendu : Proposer un ensemble de règles de pare-feu respectant le principe du moindre privilège et sécurisant efficacement le serveur.

Contexte : Les postes invités connectés au Wi-Fi de l'entreprise peuvent accéder aux serveurs internes. Le Problème : Il est nécessaire d'isoler le réseau invité pour éviter tout accès aux ressources internes sensibles. Contraintes : Mettre en place un VLAN ou une segmentation équivalente. Les invités doivent uniquement avoir accès à Internet. Aucun accès aux serveurs internes ne doit être possible. Livrable attendu : Proposer une configuration simple permettant d'isoler le réseau invité et de bloquer tout accès aux ressources internes.

Contexte : Les serveurs internes peuvent actuellement initier des connexions sortantes vers n'importe quelle destination Internet. Le Problème : En cas de compromission, un serveur pourrait communiquer librement avec un serveur malveillant externe. Contraintes : Vous devez limiter les connexions sortantes uniquement aux services nécessaires (ex : mises à jour système et API partenaires). Toute autre connexion doit être bloquée. Livrable attendu : Définir une politique de filtrage sortant simple réduisant les risques de communication non autorisée vers l'extérieur.

Contexte : Tous les postes de travail et serveurs de l'entreprise sont actuellement sur le même segment réseau. Le Problème : En cas de compromission d'un poste, l'attaquant pourrait accéder librement aux serveurs critiques. Contraintes : Vous devez proposer une segmentation basique séparant au minimum les postes utilisateurs, les serveurs applicatifs et les serveurs d'administration. Les flux entre segments doivent être contrôlés. Livrable attendu : Définir un schéma simple de segmentation réseau avec des règles de filtrage précises limitant les communications inter-segments.

Contexte : Votre entreprise possède un réseau plat où postes utilisateurs, serveurs applicatifs et bases de données cohabitent sur le même segment. Le Problème : En cas de compromission d'un poste utilisateur, un attaquant peut atteindre directement les serveurs critiques. Contraintes : Mettre en place au minimum trois VLAN (utilisateurs, serveurs applicatifs, bases de données). Les flux doivent être strictement contrôlés via un pare-feu inter-VLAN. Les bases de données ne doivent accepter que les connexions provenant des serveurs applicatifs. Livrable attendu : Proposer un schéma de segmentation détaillé avec règles de filtrage précises entre les zones et justification des flux autorisés.

Contexte : Le réseau Wi-Fi invité et le réseau interne partagent la même infrastructure sans séparation stricte. Le Problème : Les utilisateurs du Wi-Fi invité peuvent atteindre certaines ressources internes sensibles. Contraintes : Mettre en place une isolation complète via VLAN distinct et règles de pare-feu bloquant tout accès aux serveurs internes. Seul l'accès Internet doit être autorisé pour les invités. Livrable attendu : Définir une configuration réseau garantissant l'isolation totale entre Wi-Fi invité et réseau interne.

Contexte : Un audit révèle que tous les ports d'un switch d'accès sont actifs et permettent la connexion libre de tout équipement. Le Problème : Aucun contrôle d'accès réseau n'est appliqué, ce qui facilite l'introduction d'équipements non autorisés. Contraintes : Mettre en place un contrôle d'accès basé sur l'adresse MAC ou une authentification 802.1X. Les postes légitimes ne doivent pas être impactés. Livrable attendu : Définir une configuration sécurisée des ports du switch limitant l'accès aux équipements autorisés uniquement.

Contexte : Un service exposé publiquement subit de nombreuses tentatives de connexion répétées. Le Problème : Aucun mécanisme réseau ne limite le nombre de tentatives par adresse IP. Contraintes : Mettre en place un mécanisme de rate limiting ou de blocage temporaire après plusieurs tentatives échouées. La disponibilité du service légitime ne doit pas être impactée. Livrable attendu : Configurer une protection réseau permettant de limiter efficacement les tentatives de force brute tout en maintenant l'accessibilité du service.

Contexte : Un routeur d'entreprise utilise des règles NAT pour publier certains services internes vers Internet. Le Problème : Une règle NAT mal configurée expose un serveur interne non prévu. Configuration actuelle : NAT ANY -> 192.168.1.20 ALL PORTS Tous les ports du serveur interne sont accessibles publiquement. Contraintes : Seul le port 443 doit être publié. Les autres ports doivent rester inaccessibles depuis Internet. Aucun impact sur le service HTTPS existant. Livrable attendu : Corriger la règle NAT afin de limiter strictement les ports exposés et réduire la surface d'attaque.

Contexte : Un scan de sécurité révèle que votre serveur web accepte encore des versions obsolètes de TLS. Le Problème : TLS 1.0 et 1.1 sont activés, exposant le serveur à des vulnérabilités connues. Configuration actuelle : TLSv1 enabled TLSv1.1 enabled TLSv1.2 enabled Contraintes : Désactiver les versions obsolètes tout en maintenant la compatibilité moderne. Les suites cryptographiques faibles doivent être supprimées. Livrable attendu : Proposer une configuration TLS sécurisée limitant les protocoles et suites aux standards actuels robustes.

Contexte : Plusieurs applications internes doivent être exposées sur Internet via un point d'entrée unique. Le Problème : Les applications sont actuellement publiées directement, chacune avec sa propre configuration réseau. Contraintes : Mettre en place un reverse proxy central avec terminaison TLS. Les applications internes ne doivent pas être directement accessibles depuis Internet. Les journaux d'accès doivent être activés. Livrable attendu : Proposer une architecture sécurisée utilisant un proxy inverse et définir les règles de filtrage et de redirection associées.

Contexte : Les postes utilisateurs peuvent interroger n'importe quel serveur DNS public, ce qui complique la surveillance des requêtes sortantes. Le Problème : En cas d'infection, un poste compromis pourrait communiquer avec un serveur malveillant via DNS. Contraintes : Forcer l'utilisation d'un serveur DNS interne sécurisé. Bloquer les requêtes DNS sortantes directes vers Internet. Mettre en place un filtrage des domaines malveillants. Livrable attendu : Proposer une architecture DNS sécurisée incluant redirection obligatoire, filtrage et journalisation des requêtes.

Contexte : L'entreprise souhaite améliorer sa capacité de détection d'intrusion sur son réseau interne. Le Problème : Aucun système ne surveille actuellement les flux réseau pour détecter des comportements anormaux. Contraintes : Déployer un IDS capable d'analyser le trafic réseau sans bloquer les flux. Les alertes doivent inclure l'adresse IP source, destination et le type d'anomalie détectée. L'impact sur les performances doit rester minimal. Livrable attendu : Proposer une architecture simple d'IDS incluant positionnement réseau, type d'analyse (signature ou comportementale) et mécanisme d'alerte.

Contexte : Les serveurs internes peuvent établir des connexions vers Internet sans restriction spécifique. Le Problème : En cas de compromission, un serveur pourrait exfiltrer des données vers un serveur externe. Contraintes : Mettre en place un filtrage sortant basé sur liste blanche des destinations autorisées. Les mises à jour système et API partenaires doivent rester accessibles. Livrable attendu : Définir une politique de filtrage sortant détaillée limitant strictement les destinations et ports autorisés.

Contexte : Deux sites distants échangent des données sensibles via une liaison opérateur non dédiée. Le Problème : Les communications ne sont pas chiffrées et pourraient être interceptées. Contraintes : Mettre en place un tunnel IPsec site-à-site avec authentification forte. Assurer la redondance en cas de panne d'un lien. Maintenir la performance des échanges. Livrable attendu : Concevoir une architecture IPsec détaillant négociation IKE, paramètres de chiffrement et mécanisme de supervision du tunnel.

Contexte : Plusieurs services publics (web, API, messagerie) doivent être exposés sur Internet. Le Problème : Les services sont actuellement hébergés sur le même segment que les serveurs internes critiques. Contraintes : Mettre en place une DMZ dédiée avec filtrage strict entre Internet, DMZ et réseau interne. Inspection obligatoire du trafic entrant et sortant. Journalisation centralisée. Livrable attendu : Proposer une architecture DMZ détaillée incluant segmentation physique ou logique, règles de filtrage précises et justification des flux autorisés.

Contexte : Votre entreprise possède plusieurs sites interconnectés ainsi que des ressources cloud accessibles via VPN traditionnel. Le modèle actuel repose sur la confiance implicite une fois connecté au réseau interne. Le Problème : Vous devez concevoir une architecture réseau basée sur le principe Zero Trust où aucun segment n'est considéré comme sûr par défaut. Contraintes : Authentification forte obligatoire pour chaque accès aux ressources. Micro-segmentation des workloads. Contrôle d'accès basé sur l'identité et le contexte. Journalisation centralisée des flux. Aucun accès implicite lié à la localisation réseau. Livrable attendu : Proposer une architecture détaillée incluant micro-segmentation, contrôle d'accès dynamique, inspection du trafic et stratégie de supervision continue.

Contexte : Une application web critique subit des pics de trafic suspects provoquant des interruptions de service. Le Problème : Aucune protection spécifique contre les attaques DDoS applicatives n'est en place. Contraintes : Mettre en place une protection combinant filtrage réseau, limitation de débit et éventuellement un service de mitigation externe. Maintenir la disponibilité des utilisateurs légitimes. Livrable attendu : Proposer une stratégie de défense contre DDoS incluant filtrage en amont, rate limiting et surveillance continue.

Contexte : Votre entreprise possède une connectivité multi-homed avec plusieurs fournisseurs d'accès. Le Problème : La configuration actuelle accepte des annonces BGP sans filtrage strict. Configuration actuelle : ACCEPT ALL ROUTES FROM PEER Cela expose le réseau à un risque de route hijacking. Contraintes : Mettre en place un filtrage basé sur les préfixes autorisés et validation RPKI si disponible. Maintenir la redondance multi-opérateurs. Livrable attendu : Corriger la configuration BGP afin de limiter les annonces acceptées et renforcer la sécurité du routage externe.

Contexte : Un audit révèle qu'un attaquant ayant compromis un poste utilisateur a pu atteindre un serveur sensible situé dans un autre VLAN. Le Problème : Les règles inter-VLAN sont trop permissives. Configuration actuelle : ALLOW VLAN_USERS -> VLAN_SERVERS ANY PORT Cette règle permet un mouvement latéral complet. Contraintes : Restreindre les flux aux seuls ports applicatifs nécessaires. Interdire toute communication directe vers les bases de données. Maintenir la disponibilité des services métiers. Livrable attendu : Corriger les règles inter-VLAN afin de bloquer les mouvements latéraux tout en conservant les flux applicatifs légitimes.

Contexte : Un proxy sortant permet aux utilisateurs d'accéder à Internet. Un audit révèle qu'il autorise le tunneling non contrôlé. Le Problème : La configuration actuelle autorise CONNECT vers n'importe quelle destination et port. Configuration actuelle : ALLOW CONNECT ANY:ANY Cela peut permettre l'exfiltration de données via des canaux non surveillés. Contraintes : Restreindre les ports autorisés (443 uniquement). Activer journalisation détaillée. Bloquer destinations non approuvées. Livrable attendu : Corriger la configuration du proxy afin de limiter strictement le tunneling et réduire les risques d'exfiltration.

Contexte : Des comportements suspects ont été observés sur le réseau interne, suggérant une attaque ARP spoofing. Le Problème : Les switches ne disposent pas de mécanismes de protection contre l'empoisonnement ARP. Contraintes : Activer des mécanismes comme Dynamic ARP Inspection (DAI) et DHCP Snooping. Aucun impact sur les équipements légitimes. Maintenir la stabilité du réseau. Livrable attendu : Configurer des protections réseau empêchant les attaques ARP spoofing et documenter les mesures mises en place.

Contexte : L'entreprise souhaite empêcher tout équipement non conforme (non patché, antivirus absent) d'accéder au réseau interne. Le Problème : Actuellement, tout appareil connecté physiquement au réseau obtient un accès complet. Contraintes : Déployer une solution NAC intégrée au réseau. Vérification de conformité des postes avant attribution d'accès. Isolement automatique des équipements non conformes. Livrable attendu : Proposer une architecture NAC détaillant mécanisme d'authentification, vérification de conformité et gestion des accès dynamiques.

Contexte : L'entreprise souhaite détecter et bloquer en temps réel les attaques réseau sophistiquées sur un lien Internet à fort débit. Le Problème : Le réseau ne dispose actuellement que d'un pare-feu basique sans inspection approfondie du trafic. Contraintes : Déployer un IDS/IPS capable d'inspection en profondeur (DPI) sans dégrader significativement la performance. Intégration avec un système SIEM central. Gestion des faux positifs obligatoire. Livrable attendu : Concevoir une architecture IDS/IPS incluant positionnement réseau, stratégie de détection, mécanisme de blocage automatique et supervision centralisée.