diff --git a/README.md b/README.md index 64af419..b01232e 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ Une large part des séances pratiques sera réalisée sur la plateforme MI-LXC ( * [TD4.1](td4.1-mail.md) SMTP, POP, IMAP * S5 : - * CM5 Firewall (complément en ligne : [Filtrage et surveillance réseau](https://github.com/flesueur/srs/blob/master/cm3-filtrage.md)) + * CM5 Archi réseau et firewall (complément en ligne : [ANSSI](https://www.ssi.gouv.fr/administration/guide/definition-dune-architecture-de-passerelle-dinterconnexion-securisee/) (chapitre 2)) * TD5.1 IPTables * TD5.2 Architecture réseau * S6 : diff --git a/cm5-archi.md b/cm5-archi.md new file mode 100644 index 0000000..7786a86 --- /dev/null +++ b/cm5-archi.md @@ -0,0 +1,189 @@ +CM5 Architecture réseau et firewall - Notes de cours +==================================================== + +Programme +========= + +* L'objectif de la segmentation +* Quelques exemples d'architecture +* Le filtrage par pare-feu + + +Il était une fois les réseaux à plat +==================================== + +* Naturellement, comme on l'a fait dans les TD successifs : un subnet, tout le monde dedans ! +* Sauf que c'est en fait une mauvaise idée pour plein de raisons... +* On va donc sub-diviser en sous-réseaux au niveau IP + +Raisons humaines +---------------- + +* Un réseau s'administre, donc doit se comprendre +* Le cerveau humain a ses limites (sisi) +* Besoin de cartographier, décomposer pour s'y repérer +* Besoin d'une certaine autonomie/indépendance entre les parties pour maîtriser la gestion de chacune au quotidien +* Subdivision en sous-réseaux logiques au niveau IP +* Par exemple géographiques (bâtiments, services, filiales, ...) + +Exemple : +* Partant d'un réseau /16 + * public (adresses globales) : 134.214.0.0/16 (allant donc de 134.214.0.0 à 134.214.255.255) + * ou privé (adresses locales) : 192.168.0.0/16 (allant donc de 192.168.0.0 à 192.168.255.255) +* Découpage en + * 255 réseaux /24 : 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, ..., 192.168.255.0/24 + * ou 16 réseaux /20 : 192.168.0.0/20, 192.168.16.0/20, 192.168.32.0/20, ... (oui, c'est déjà plus compliqué !) + * ou ... + * _Les séparations sur les octets (les '.'), c'est le plus simple ; mais la notation CIDR permet les frontières plus fines_ + + +Raisons réseau +-------------- + +* La couche "Liaison", typiquement Ethernet en-dessous d'IP, n'a pas une scalabilité infinie +* Broadcast ARP, tables ARP (hôtes, switchs) +* IP fait aussi du broadcast, sur cette notion de segment Ethernet +* Tout ceci est du trafic réseau "non-métier", coût bande passante et calcul +* Besoin de structurer/factoriser la notion de route avec du routage logique : IP + + +Exemple : + +* Ethernet, adresses MAC hétérogènes, une table complète, non adapté à un grand nombre d'identifiants +* IP, addresses IP homogènes, notion de route unique vers un ensemble de machines, passe à l'échelle du nombre d'identifiants + + +Raisons sécurité +---------------- + +* La raison directrice aujourd'hui (à mon sens). Pourquoi ? + * Parce que les autres raisons sont déjà rentrées dans les mœurs + * Parce qu'elle va plus loin et donc, en quelque sorte, inclue les besoins des précédentes + * Parce que je suis biaisé !? +* Limiter la propagation d'une attaque -> Avoir des points de limitation et de contrôle +* Principe du moindre privilège (des utilisateurs, des machines) -> Limiter les accès +* Segmentation fonctionnelle selon les rôles/les besoins de réseau/service des machines +* Et il s'avère que tout ceci se conçoit au niveau IP +* L'objectif est ainsi de brider les possibilités d'un attaquant par les équipements de confiance au niveau réseau + +Exemples de "patrons de segmentation" +===================================== + +La segmentation va avoir pour but de découper son SI en zones isolées afin de : + +* Diminuer la surface d'attaque sur chaque zone + * Une zone est un ensemble homogène (en terme de sensibilité, d'exposition, de type de service, ...) + * Des règles générales limitent l'accessibilité de l'ensemble des machines +* Compliquer le passage d'une zone à l'autre + * Les zones ont des expositions différentes + * Les zones ont des sensibilités différentes + * Souvent, exposition <> sensibilité + * Prévenir la compromission d'une zone sensible à partir d'une zone exposée +* Un bon guide de l'ANSSI [ici](https://www.ssi.gouv.fr/administration/guide/definition-dune-architecture-de-passerelle-dinterconnexion-securisee/). + + +Modèle historique (**proscrit** mais on le trouve encore...) +------------------------------------------------------------ + +Modèle périmétrique à 3 zones pour limiter la surface d'attaque (les services/machines exposés) : + +* WAN : le monde extérieur +* DMZ : zone tampon, perdable sans mettre en péril le SI, les services très exposés ouverts sur le WAN (exposés => sensibilité la plus faible possible) +* LAN : les services internes, les postes de travail, tout à plat + +Flux : + +* WAN -> DMZ : spécifiques +* WAN -> LAN : aucun ! +* DMZ -> LAN : aucun ! +* LAN -> DMZ, DMZ -> WAN : un peu de filtre mais c'est le sens des communications attendues +* (évidemment les réponses passent dans l'autre sens) + +Par contre, une fois mis un pied dans le réseau, c'est fini... Ex ransomware ou [Paf TV5Monde](https://www.sstic.org/2017/presentation/2017_cloture/) + + +Modèle moderne : segmentation +----------------------------- + +* Parfois appelé le modèle de l'aéroport (des zones publiques, des contrôles successifs, chaque zone plus sécurisée demande des contrôles supplémentaires) +* Généralisation du concept de DMZ à n segments +* Considérer que l'attaquant est ou sera là, le limiter dans ses actions une fois entré +* Une logique de dissocier l'exposition de la sensibilité (les zones exposées peu sensibles, les zones sensibles peu exposées) +* Un élément de réponse face aux attaques à n sauts, aux ransomwares, ... + +Exemple : + +* WAN : le monde extérieur +* Des zones de serveurs : + * DMZ externe : les services ouverts sur l'extérieur + * DMZ interne : les services internes +* Des zones de postes de travail, liées aux besoins métiers : + * Des zones très peu privilégiées (secrétariat, compta, DIRECTION) + * Des zones de développeurs (qui déploient du code sur des sites interne par exemple) + * ... +* Une zone de postes particuliers : les administrateurs, très privilégiés, donc on limite au maximum l'exposition (minimum de postes, règles strictes) + +Entre chaque paire de zones : +* Limiter les flux +* S'assurer de grader les zones / empêcher les passages vers du plus privilégié +* Toujours ouvert à l'intérieur d'une même zone, pas de contrôle ici. + + +Vers le zero-trust ? +-------------------- + +* Trouver le bon compromis entre la maintenabilité (pas trop de zones) et la précision (une zone par machine) +* La mode va vers le zero-trust, mais c'est aujourd'hui plus une philosophie et/ou du marketing qu'une réalité +* Aucun accès par défaut (donc, quelque part, pas de zones), ouverture de chaque flux sur droits spécifiques à chaque fois (SSO+++) +* On imagine vite la complexité de mise en place +* Ex Google + + +Cas particuliers +---------------- + +* Authentification centralisée : + * Comment la rendre accessible à la DMZ ? Elle n'est pas perdable et est sensible ! + * Proxy ou miroir poussé depuis l'interne + +* VPN : + * Chemin WAN -> DMZ externe -> zone interne, c'est mal ! + * Vrai casse-tête en particulier avec toutes les ouvertures post-confinement + * Nécessaire, à réfléchir et limiter par utilisateur (un comptable ne doit pas avoir le même accès qu'un développeur) + * Dur ! + + + +Quel outillage technique ? +========================== + +(V)LAN +------ + +* LAN (physique) premier élément : + * Un brin réseau Ethernet + * Les LAN sont reliés par des routeurs au niveau IP -> Filtrage ! +* La séparation physique est coûteuse et peu souple : + * Un grand LAN unique + * Des VLAN administrés + * Un VLAN spécifié pour chaque prise réseau + * On revient sur la logique du LAN + + +Pare-feu (_Firewall_) +--------------------- + +* Ouverture d'une liste de services contrôlés, diminution de la surface d'attaque, matrice de flux +* Couche IP +* Simplification (donc avec perte) : 1 service = 1 port +* Système de règles +* Une règle : (Interface_src, IP_src, Port_src, IP_dst, Port_dst, Interface_dst) (essentiellement) +* Filtre uniquement entre des (V)LAN, lorsque le routage IP doit être fait +* Exemple de règle +* Ex [iptables](https://fr.wikipedia.org/wiki/Iptables)/[nftables](https://fr.wikipedia.org/wiki/Nftables) + + +Ce qu'on va faire en TD +======================= + +* TD5.1 IPTables, SSH, segmentation