Documentation projet infrastructure sécurisée : L’objectif de ce projet est de déployer une infrastructure d’entreprise en appliquant certaine mesure de sécurité afin de fournir un SI répondant à des critères DIC (disponibilité, intégrité, confidentialité). L’infrastructure devra répondre aux critères suivants : - Le domaine du SI sera m2i.lab Le domaine sera résolu par du DNS en interne Une PKI pour la gestion des certificats interne et externe sera mise en place La haute disponibilité du réseau sera assurée par les protocoles CARP, XMLRCP ET PFSYNC via 2 pares feux en failover (OPNsense ou DYNFI) Un serveur DHCP diffusant dans le LAN pour les clients Un serveur WEB (Apache2) en HTTPS sera déployé afin d’assurer la confidentialité du trafic vers l’intranet Un niveau de sécurité haut concernant les méthodes d’authentification et de communication sera mis en place Une segmentation en sous réseaux sera implémentée avec filtrage de trafic stricte via firewall comprenant : ➢ Un réseau WAN pour l’accès internet ➢ Un réseau LAN pour les clients ➢ Un réseau SRV pour les serveurs ➢ Un réseau ADM pour le management des serveurs ➢ Un réseau SYNC pour la synchronisation des pares-feux Schéma logique de la topologie réseau déployée Documentation technique : Topologie du réseau : L’architecture réseau du SI est conforme à cette topologie : - Réseau WAN Réseau LAN en 192.168.200.0/24 Réseau SRV en 192.168.100.0/24 Réseau ADM en 172.17.0.0/16 Réseau SYNC en 172.16.0.0/30 DNS : Le service DNS sera assuré par les firewalls qui serviront de « resolver » pour l’ensemble du domaine mais également vers l’extérieur. L'implémentation de DNSSEC dans notre infrastructure DNS va renforcer la sécurité au niveau de la résolution interne. DNSSEC répond principalement au critère de sécurité de l'intégrité des données. Il assure que les réponses fournies par le système de noms de domaine (DNS) sont authentiques et n'ont pas été altérées ou falsifiées durant leur transit sur Internet. Cela prévient efficacement des attaques telles que le « DNS spoofing » et le « cache poisoning », où des attaquants pourraient rediriger nos utilisateurs vers des sites frauduleux via des attaque « Man in the middle ». Le DNS rebind Check est également activé. Il fonctionne en bloquant les réponses DNS qui dirigent les utilisateurs vers des adresses IP privées potentiellement malveillantes. PKI : Une PKI assure la gestion des autorités de certification et les certificats. Une autorité de certification interne permet de générer et d’authentifier tous les certificats interne aux SI. Celle-ci est ensuite importée dans les navigateurs/systèmes d’exploitation des clients. Ceci permettra de ne pas habituer nos utilisateurs à cliquer sur « accepter le risque » tout en ayant des certificats gratuits pour notre SI interne. Elle pourra également gérer les certificats délivrés par de réelle autorité de certification en cas de besoin. Haute disponibilité du réseau / Cluster de pares feux : Celle-ci se ferai via 3 protocoles différents et nécessaires à une réelle haute disponibilité : Le protocole CARP qui est un protocole d’agrégation d’interface via une interface virtuelle (VIP) Chaque réseau nécessitant de la haute disponibilité se voit attribué une IP d’agrégation virtuelle : - Le WAN pour la disponibilité d’internet Le LAN Le réseau SRV Le protocole PFsync qui permet de synchroniser l’état actuel des connexions en cours et ainsi assure un basculement cohérent et le maintien des connexions en cours en cas de perte d’un pare feu. Le protocole XMLRCP qui permet la synchronisation entre les 2 pares feux via la transmission de fichier de configuration XML. L’ensemble du trafic de synchronisation des pares feux passe par un réseau dédié et isolé (SYNC) en notation CIDR /30 afin de restreindre le nombre de machines possibles au sein de celui-ci. DHCP : Le serveur DHCP distribue des IP aux machines clientes dans le LAN. Sa plage d’adresse est actuellement de 192.168.200.150 à 192.168.200.200 au vu du petit nombre de machine dans notre SI. Si besoin d’augmenter la plage il faudra faire attention à la machine d’administration qui a une IP fixe en 192.168.200.1 et éventuellement ajouter un bail statique. Serveur WEB intranet : Le serveur WEB est hébergé dans le réseau SRV et ne réponds que sur son IP dans celui-ci en HTTPS. Son certificat est fourni par la PKI et sa résolution se fait par nos DNS internes via son url « web.m2i.lol » Il utilise le protocole TLVv1.2 au minimum et les ciphers recommandés en termes de sécurité Sécurité de l’infrastructure : Concernant la sécurité du SI, différents points sont à prendre en compte et à appliquer. 1. L’administration de l’infra : Ne se fait que via le réseau ADM, qui est un réseau isolé dans lesquels toutes les machines d’administration et les machines à administrer sont présente. Ce réseau est en 172.17.200.0/16, cependant le sous réseau de celui-ci sera à réévaluer car nous n’avons pas forcement la nécessité d’avoir autant d’adresse disponible. Aucun protocole d’administration (SSH, RDP, VNC, telnet…) n’est et ne dois être autorisé à transiter depuis les autres sous réseaux du SI. 2. Les méthodes, algorithmes de chiffrement et de hashage : Elles doivent être hautement sécurisés et se baser sur des méthodes/algorithmes robuste. Méthode de transport : SSL est proscrit et TLSv1.2 au minimum doit être utilisée (1.3 préférable) Ciphers : Les algorithmes de chiffrement et de hashage utilisés doivent répondre aux exigences de sécurité en vigueur : Voici un exemple de recommandations actuelles en termes de sécurité pour openssl (24/11/2023) https://ciphersuite.info/cs/?software=openssl&sort=sec-desc 3. Administration des machines en ssh : Concernant le ssh, certaines règles sont appliquées aux serveurs et doivent être respecter pour toute nouvelle implémentation de connexion vers une machine : - Ecoute seulement dans le réseau ADM pour SSHD - Pas de root login - Authentification par clé privées/publiques seulement pour des utilisateurs restreints - Utilisation des ciphers et des types/algorithme de clés recommandées - Aucun autre mode d’authentification accepté (challenge/response, mdp, PAM) - Pas d’activation du X11Forwarding si pas nécessaire (interface graphique) - Pas d’accès au fichier rhosts - Pas de permission de tunnel ssh si pas nécessaire - Si machine sensible, utiliser le pare feu local des serveurs pour n’autoriser que les machines d’administration 4. Administration des firewalls : Les firewalls répondent au URL fw1.m2i.lol et fw2.m2i.lol. Les règles suivantes sont en place concernant l’administration de ceux-ci : - Toute modification doit être effectuer sur le pare feu 1 (fw1.m2i.lol) car sa configuration est répliquée sur le pare feu de secours. - L’administration des firewalls (en interface graphique + SSH) ne se fait que depuis les machines d’administration (Alias pour les regrouper) et règle de pare-feu + configuration sont mis en place pour cela. - La sécurité HSTS est en place pour empêcher le basculement en HTTP une fois la connexion établie. - Le compte root est désactivé sur le GUI des firewalls et un compte nominatif est créé pour chaque intervenant. 5. Règles de sécurité du trafic : Principe du moindre privilège en vigueur, on bloque tout et on autorise seulement ce qui est nécessaire. Pas de « ANY » dans les règles de pare-feu. On autorise spécifiquement la ou les IP sur le ou les protocoles nécessaires et a destination de la bonne cible.
