Au cours de cette expérimentation, nous serons amenés à faire communiquer des réseaux réalisés séparément.
Commencez par mettre en place ce qui est décrit par ce schéma.

Il ne s'agit que de réutiliser les outils et commandes du précédent sujet.
Toutefois, l'interface D/eth0 n'est reliée à aucun de vos switches ; elle doit être reliée à un switch préalablement préparé par l'encadrant de séance sur son poste de travail (dont il vous précisera le nom). $ ./machine.py D teacher:9999 9991 9992 9993 ↵

Afin de simplifier la manipulation, les machines A, B et C sont les seules représentantes de leur sous-réseau d'appartenance mais il faut imaginer qu'elles pourraient être bien plus nombreuses.
Ces mêmes machines doivent toutes avoir une route par défaut par l'interface de D qui leur correspond ; le routeur D doit bien entendu être autorisé à retransmettre les paquets IP qui ne lui sont pas destinés.
Remarquez que la machine C est dans un sous-réseau 193.100.XX.0/24.
Pour XX vous utiliserez le numéro qui termine le nom de votre poste de travail (9 sur laurier9, 12 sur menthe12, 23 sur poivre23, 17 sur thym17...) ; cette distinction est indispensable afin qu'il n'y ait pas de confusion/collision entre les réseaux réalisés par chacun.
Le même numéro XX doit servir dans l'attribution de l'adresse IP 20.0.0.XX à l'interface D/eth0 ; cette liaison spéciale est dite “point-à-point”. [D]~# ip addr add 20.0.0.XX peer 20.0.0.254 dev eth0 ↵ Une telle liaison n'est censée relier que deux interlocuteurs (pas tout un sous-réseau) ; ici l'adresse 20.0.0.254 représente le fournisseur d'accès à l'Internet.
Le routeur D doit lui-même avoir une route par défaut par 20.0.0.254.
Dans ces conditions, les réseaux des différents participants à l'expérimentation considèrent le routeur de l'encadrant de séance comme un représentant de l'ensemble des routeurs de l'Internet qui, de proche en proche, savent atteindre chacun de ces réseaux.

Prêtez une très grande attention à la désignation des switches, machines, interfaces réseau et à l'attribution des adresses IP et des routes.
En effet, la moindre incohérence produirait probablement un comportement inattendu difficile à analyser.

Avant de passer à la suite, il faudra impérativement vérifier les communications suivantes (avec ping -R) :

Vous avez dû remarquer que jusqu'alors nous utilisions essentiellement des adresses IP de la forme 192.168.???.???.
De telles adresses sont dites “privées”, c'est à dire que chacun sur son site (ou à son domicile) peut en faire l'usage qu'il veut sans que ça n'ait la moindre influence sur le reste de l'Internet.
Même si par habitude beaucoup de personnes utilisent la forme d'adresse privée 192.168.???.???, il en existe d'autres qui sont tout aussi librement utilisables.

Dans le réseau que nous venons de préparer, figurent pour la première fois des adresses IP “publiques” : 193.100.???.??? et 20.0.0.???.
De telles adresses ne peuvent pas être choisies librement ; elles sont forcément réservées/attribuées par le fournisseur d'accès à l'Internet✍.
La distinction entre les adresses IP “privées” et “publiques” ne repose sur aucune contrainte technique mais n'est qu'affaire de convention :

En l'état, nous n'avons fait aucune intervention explicite sur les routeurs pour interdire l'usage des adresses IP privées en dehors du réseau de chacun.
Tentez alors de communiquer (avec ping) entre votre machine A et la machine C d'un autre participant à l'expérimentation (synchronisez-vous pour effectuer ce test à plusieurs).
En utilisant l'outil tcpdump au niveau des diverses interfaces réseau des routeurs des deux sites, vous devriez constater que le paquet ICMP-echo-request issu de A traverse bien votre routeur D vers “l'extérieur” mais qu'il se perd ensuite.
De toutes façons, s'il atteignait sa destination, le paquet ICMP-echo-request qui devrait être produit en retour serait destiné à une adresse privée qui existe très probablement sur plusieurs sites ; il n'y aurait alors aucune raison de le délivrer à l'un plutôt qu'à un autre.

Néanmoins, il serait souhaitable que les postes ayant des adresses privées puissent malgré-tout interagir avec des machines de l'Internet✍.
Pour atteindre un tel objectif, nous avons besoin de donner des consignes au système d'exploitation du routeur D afin qu'il effectue une traduction des adresses sources (SNAT). [D]~# iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j SNAT --to-source 20.0.0.XX ↵ Peu importe la forme compliquée de la commande✍, elle indique au firewall qu'il faut traduire (modifier à la volée) les adresses IP sources des paquets IP provenant de la plage indiquée lorsque ces paquets sortiront par l'interface eth0.
Nous précisons notamment que c'est l'adresse IP de l'interface D/eth0 qui remplacera l'adresse IP source d'un paquet subissant cette traduction✍.
Bien entendu, le firewall garde en mémoire les traductions qu'il effectue pour les paquets sortants et réalise les traductions réciproques (sur l'adresse IP destination) lorsque les réponses à ces paquets reviennent.

Reprenez alors la tentative de communication entre votre machine A et une machine C d'un autre participant.
Écoutez attentivement les interfaces eth0 et eth1 de votre routeur D afin d'observer les traductions d'adresses à l'aller comme au retour.
Du point de vue de l'extérieur de votre réseau (la machine C distante), c'est comme si votre routeur D était à l'origine de la communication, alors qu'à l'intérieur de votre réseau la machine A semble communiquer directement avec son interlocuteur.
Vous pouvez comparer cette nouvelle situation à celle de votre machine B qui, elle, n'est pas concernée par cette traduction d'adresses sources✍.

L'intérêt de la traduction d'adresses sources (SNAT) est double :

La machine C a volontairement été placée dans une plage d'adresses publiques afin qu'elle soit accessible depuis l'Internet.
Le sous-réseau regroupant les services qui sont directement accessibles depuis l'extérieur est usuellement désigné par DMZ (“zone démilitarisée”).
Ce sous-réseau demande une attention très particulière car, contrairement aux postes en adresses privées qui sont inaccessibles, les postes en DMZ sont directement exposés aux tentatives d'actions malveillantes issues de l'Internet.
Il convient donc de sécuriser ces postes particulièrement exposés ainsi que leur sous-réseau.

Une première démarche consiste à décorréler les adresses publiques visibles depuis l'Internet des adresses privées effectivement utilisés par ces machines.
En effet, les actions malveillantes commencent généralement par une cartographie du réseau pour en détecter les vulnérabilités : le fait de brouiller les pistes rend cette démarche plus difficile.
Commençons alors par modifier les adresses de notre DMZ pour qu'elles correspondent au sous-réseau privé 192.168.30.0/24. [D]~# ip addr del 193.100.XX.1/24 dev eth3 ↵ [D]~# ip addr add 192.168.30.1/24 dev eth3 ↵ [C]~# ip addr del 193.100.XX.2/24 dev eth0 ↵ [C]~# ip addr add 192.168.30.2/24 dev eth0 ↵ Attention, après reconfiguration de la machine C, il faudra lui indiquer à nouveau sa route par défaut par D/eth3 ; vérifiez alors que vos machines A et B communiquent toujours correctement avec C.

La machine C n'est donc plus directement accessible depuis “l'extérieur”.
Pour rendre cet accès à nouveau possible, nous avons besoin de donner des consignes au système d'exploitation du routeur D afin qu'il effectue une traduction des adresses destinations (DNAT, redirection d'adresses). [D]~# iptables -t nat -A PREROUTING -d 193.100.XX.2 -j DNAT --to-destination 192.168.30.2 ↵ Peu importe la forme compliquée de la commande✍, elle indique au firewall qu'il faut traduire (modifier à la volée) les adresses IP destinations selon l'adresse privée indiquée lorsque des paquets IP seront destinés à l'adresse publique choisie.
Nous précisons la paire d'adresses IP publique et privée à notre convenance selon notre configuration.
Bien entendu, le firewall garde en mémoire les traductions qu'il effectue pour les paquets entrants et réalise les traductions réciproques (sur l'adresse IP source) lorsque les réponses à ces paquets sont produites.

En synchronisation avec un autre participant à l'expérimentation, vérifiez que votre machine C est bien accessible de “l'extérieur” grâce à l'adresse publique choisie.
Écoutez notamment les interfaces eth0 et eth3 de votre routeur D afin d'observer les traductions d'adresses à l'aller comme au retour.
Du point de vue de l'extérieur de votre réseau, c'est comme si votre machine C avait l'adresse IP publique choisie, mais il n'en est rien !
D'ailleurs, si depuis votre machine C vous tentez de joindre une adresse IP publique d'un autre participant, vous vous retrouverez dans la situation de la machine B.
Votre DMZ, désormais en adresses privées, ne peut pas décider de quitter votre site ; elle se contente de répondre aux sollicitations.
Cette propriété est extrêmement intéressante en terme de sécurité car les actions malveillantes visent souvent à se propager depuis des sites infestés✍.
Dans ces conditions, même si votre machine en DMZ est corrompue, elle ne pourra émettre aucun trafic vers le reste du monde.

Un autre intérêt très appréciable de la décorrélation entre les adresses publiques visibles et les adresses privées effectivement utilisées tient dans la souplesse offerte en terme de reconfiguration.
Nous pouvons séparer notre DMZ en de multiples sous-réseaux (pour des raisons de sécurité), ou au contraire regrouper sur une seule machine des services qui en apparence fonctionnent sur plusieurs (pour des raisons de disponibilité du matériel par exemple).
Vis-à-vis de l'extérieur, ces détails d'architecture sont invisibles, ce qui nous autorise à les modifier à tout moment, et pour quelque raison que ce soit, sans que ce ne soit perceptible.

La traduction DNAT précédente concernait une machine dans sa globalité mais il est possible d'être beaucoup plus précis.
[D]~# iptables -t nat -A PREROUTING -d 193.100.XX.3 -p tcp --dport 80 -j DNAT --to-destination 192.168.30.2:8080 ↵ Avec cette commande nous associons le port TCP 80 d'une nouvelle adresse IP publique au port 8080 de notre machine C.
Toujours en synchronisation avec un autre participant, démarrez un serveur TCP simpliste sur votre machine C [C]~# ncat -lp 8080 ↵ et sollicitez-le depuis un poste externe à votre réseau. [distant A]~# ncat 193.100.XX.3 80 ↵ afin que les saisies au clavier de part et d'autre soient échangées entre ces deux interlocuteurs.
Écoutez encore les interfaces eth0 et eth3 de votre routeur D afin d'observer les traductions d'adresses et de ports à l'aller comme au retour.
Le poste distant a l'illusion de dialoguer avec un serveur TCP sur le port 80 de la nouvelle adresse IP publique choisie, mais le serveur est situé à nouveau sur notre unique machine C et utilise un tout autre port.
D'ailleurs, cette nouvelle adresse IP publique ne répond même pas à l'outil ping ; la communication n'est autorisée que pour le service désigné très précisément (TCP sur le port 80).

Si nous ne pouvions pas disposer de la plage d'adresses IP publiques 193.100.XX.0/24✍, mais uniquement de la seule adresse IP publique sur l'interface externe du routeur✍ nous aurions pu, malgré tout, exposer des services en DMZ selon le même procédé DNAT. [D]~# iptables -t nat -A PREROUTING -d 20.0.0.XX -p tcp --dport 80 -j DNAT --to-destination 192.168.30.2:8080 ↵ Reprenez alors l'expérimentation précédente (dialogue en TCP sur le port 80 depuis une machine A distante) en visant cette fois-ci l'adresse publique 20.0.0.XX.
C'est cette solution qui est utilisée pour “ouvrir des ports” sur les boîtiers offrant l'accès à l'Internet domestique.

La distinction entre adresses IP publiques et privées ainsi que les moyens de traduction d'adresses vus précédemment permettent déjà de distinguer des communications autorisées ou non.
Pour un ajustement plus fin des trafics autorisés ou interdits, le firewall permet de prendre en compte des règles de filtrage.

La stratégie la plus prudente en matière de filtrage consiste à indiquer au firewall qu'il doit, par défaut, bloquer tout le trafic.
Il restera ensuite à autoriser explicitement, par des règles spécifiques, les quelques communications correspondant aux cas d'utilisation attendus.
Commençons par exprimer le comportement par défaut. [D]~# iptables -t filter -P INPUT DROP ↵ [D]~# iptables -t filter -P OUTPUT DROP ↵ [D]~# iptables -t filter -P FORWARD DROP ↵ Qu'il s'agisse d'un paquet IP adressé au routeur (INPUT), émanant du routeur (OUTPUT) ou traversant le routeur (FORWARD), il sera détruit (DROP) sauf si une autre règle vient explicitement contredire ce choix✍.
Vérifiez qu'en l'état aucune communication n'est plus possible entre vos machines A, B, C ou D✍.

Lors de la découverte des traductions SNAT et DNAT, nous avons remarqué que le firewall mémorisait les transformations qu'il effectuait dans une direction afin de produire l'effet réciproque sur les paquets IP correspondants dans la direction opposée.
Il en est de même en ce qui concerne le filtrage ; le firewall mémorise les propriétés des paquets IP qu'il laisse circuler afin de prendre des décisions lorsque des paquets apparentés se présentent.
À l'aide de cette règle, [D]~# iptables -t filter -A FORWARD -m state --state ESTABLISHED -j ACCEPT ↵ nous indiquons que, si nous avons décidé de laisser circuler un paquet (ce qui n'est pas encore le cas), alors les paquets suivants qui sont apparentés à cette communication désormais établie (réponse, suite de l'échange) seront implicitement autorisés à circuler eux-aussi.

Dès lors, nous pouvons ajouter une règle qui autorise enfin quelques communications à s'établir. [D]~# iptables -t filter -A FORWARD -s 192.168.10.0/24 -i eth1 -j ACCEPT ↵ Nous décidons ici que toutes les machines du sous-réseau où se trouve la machine A✍ sont autorisées à communiquer sans restriction.
Nous imaginons effectivement que ce sous-réseau rassemble un ensemble de services à usage interne qui sont dignes de confiance✍.
Remarquez qu'au delà d'indiquer la plage d'adresses source, nous précisons également l'interface depuis laquelle un tel paquet doit parvenir au routeur.
Cette précaution empêche une malversation consistant à produire de “faux” paquets depuis un autre sous-réseau afin de traverser le firewall.
Vérifiez alors avec ping que A peut bien atteindre B et C, et que les réponses reviennent.
Toutefois, les machines B et C ne sont pas autorisées à joindre spontanément A ; ceci illustre la distinction effectuée par le firewall entre l'établissement d'une communication et le suivi d'une communication établie.

Autorisons maintenant notre machine C en DMZ à être jointe sur son port TCP 8080.
[D]~# iptables -t filter -A FORWARD -d 192.168.30.2 -p tcp --dport 8080 -j ACCEPT ↵ En synchronisation avec un autre participant à l'expérimentation, vérifiez que sa machine A distante✍ parvient à joindre le serveur de notre machine C✍. [C]~# ncat -lp 8080 ↵ [distant A]~# ncat 193.100.XX.3 80 ↵ Remarquez que la seule communication autorisée pour la DMZ est la réaction à cette sollicitation.
Nous avions déjà signalé l'importance d'empêcher la DMZ d'accéder spontanément à “l'extérieur”.
Grâce au filtrage, nous allons encore plus loin dans la démarche sécuritaire en empêchant la DMZ d'accéder spontanément aux autres parties de notre réseau.
En effet, si une machine en DMZ venait à être corrompue, il serait très dommageable qu'elle puisse relayer des actions malveillantes vers l'intérieur de notre réseau.

Imaginons maintenant que les machines du sous-réseau où se trouve la machine B✍ sont des postes de travail auxquels nous n'accordons qu'une confiance modérée✍.
Nous souhaitons toutefois leur offrir un accès limité à l'Internet.
Commençons alors par simuler sur la machine A (de confiance) un proxy HTTP✍. [A]~# ncat -lp 3128 --proxy-type http ↵ Bien entendu, il faut autoriser les machines autour de B à y accéder sur son port spécifique (3128 en TCP ici). [D]~# iptables -t filter -A FORWARD -s 192.168.20.0/24 -i eth2 -d 192.168.10.2 -p tcp --dport 3128 -j ACCEPT ↵ Une nouvelle fois, nous sommes très précis quant à l'origine et la destination du trafic que nous autorisons.

En synchronisation avec un autre participant à l'expérimentation, il faut lancer un serveur HTTP sur sa machine C distante. [distant C]~# python -m http.server 8080 ↵ Il ne reste plus qu'à le solliciter depuis notre machine B en utilisant un client HTTP qui utilise les services du proxy. [B]~# http_proxy=http://192.168.10.2:3128/ curl http://193.100.XX.3/ ↵ Vous devriez constater que le serveur HTTP distant reçoit bien un requête relayée par le proxy et que client obtient bien du proxy la réponse formulée par le serveur distant.