ajout CM3
This commit is contained in:
Francois Lesueur
@@ -31,7 +31,7 @@ Le programme prévisionnel est le suivant :
|
||||
* [CM2](cm2-piles.md) : Piles et protocoles de transport
|
||||
* S47 :
|
||||
* [TD3](td3-apache.md) : Apache/Tunnels/CMS 1/2
|
||||
* CM3 : Architecture réseau 1/2
|
||||
* [CM3](cm3-archi.md) : Architecture réseau 1/2
|
||||
* S48 :
|
||||
* [TD4](td3-apache.md) : Apache/Tunnels/CMS 2/2
|
||||
* CM4 : Architecture réseau 2/2
|
||||
|
||||
184
cm3-archi.md
Normal file
184
cm3-archi.md
Normal file
@@ -0,0 +1,184 @@
|
||||
CM3 + CM4 Architecture réseau et firewall - Notes de cours
|
||||
==========================================================
|
||||
|
||||
Programme
|
||||
=========
|
||||
|
||||
* L'objectif de la segmentation
|
||||
* Quelques exemples d'architecture
|
||||
* Le filtrage par pare-feu
|
||||
* Routage, filtrage, NAT, proxy
|
||||
|
||||
|
||||
Il était une fois les réseaux à plat
|
||||
====================================
|
||||
|
||||
* Naturellement, comme on l'a fait en TD : un subnet, tout le monde dedans !
|
||||
* Sauf que c'est en fait une mauvaise idée pour plein de raisons...
|
||||
* On va donc sous-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
|
||||
* Sous-division 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)
|
||||
Reference in New Issue
Block a user