M3102/cm5-archi.md

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 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)


Ce qu'on va faire en TD
=======================

* TD7 IPTables, segmentation
ajout cm5-archi 2021-11-26 12:18:05 +01:00			`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...`
update cm5 2022-06-19 08:59:27 +02:00			`* On va donc sous-diviser en sous-réseaux au niveau IP`
ajout cm5-archi 2021-11-26 12:18:05 +01:00
			`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`
update cm5 2022-06-19 08:59:27 +02:00			`* Sous-division en sous-réseaux logiques au niveau IP`
ajout cm5-archi 2021-11-26 12:18:05 +01:00			`* 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`
			`=======================`

update cm5 2022-06-19 08:59:27 +02:00			`* TD7 IPTables, segmentation`