next up previous contents index
Next: C Protocoles applicatifs Up: B Réseaux IP avancés Previous: VIII Routage dynamique d'IP   Contents   Index

Subsections


IX Éléments de réseaux

1 Hôtes ou services virtuels

\includegraphics{fig.net.01.ps}
figure IX.01 -- Serveur(s) HTTP virtuel(s)

La machine B (d'adresse IP fixe ipB) héberge par exemple le service HTTP d'adresse ip ipWWW. Cette opération est rendue possible si le système d'exploitation de B autorise la notion d'alias IP.

Si les machines A, C et D exécutent également un serveur HTTP, elles peuvent potentiellement prendre le relais de la machine B, dès lors que l'adresse ipWWW aura été retirée de la machine B pour être reconfigurée sur l'une d'entres elles.

Cette opération peut se faire manuellement ou via un outil d'administration. Elle permet de faire transiter très rapidement des services d'une machine à une autre, sans rupture ou presque de la continuité. Vu des clients il s'agit toujours de la même machine, mais elle est virtuelle puisqu'elle n'existe pas physiquement.

Les systèmes d'exploitations modernes facilitent la construction de machines virtuelles. FreeBSD a un mécanisme très adapté nommé `` jailIX1 '', autrement dit une prison. C'est une version très améliorée de la primitive unix chroot. Les `` jails '' permettent de virtualiser à la demande les services puisqu'ils peuvent être démarrés ou stoppés à la demande.

Solaris 10, possède un mécanisme qui fonctionne de la même manière...Nommé `` zoneIX2 ''.

Aussi bien les zones de Solaris que les jails de FreeBSD peuvent utiliser des alias IP pour assurer leur autonomie sur le réseau, mais ces deux mécanismes manquent à ce jour d'une virtualisation complète de la stack IP qui leur permettrait d'avoir une route par défaut dans chaque instance virtuelle du système, ce qui les rendrait beaucoup plus indépendants de l'hôte hébergeur et autoriserait des configurations beaucoup plus souples.

La consolidation des hôtes A, B,C et D (et potentiellement en nombre bien plus grand encore) est possible de nos jours sur une seule machine. L'énorme montée en puissance des processeurs multi-cores et de l'évolution des architectures SMPIX3d'une part, et d'autre part la maturité des technologies de virtualisation des systèmes d'exploitationIX4

Cette opération permet d'éviter l'éparpillement des `` petits serveurs '' au profit de machines sur lesquelles on peut concentrer un effort de maintenance matérielle plus grand tout en réalisant même une économie d'échelle pour le matériel. Au niveau de la maintenance des systèmes d'exploitation l'effort d'administration reste le mêmes, puisque proportionnel au nombre d'instances en exploitation..

2 Tunnel IP

\includegraphics{fig.net.02.ps}
figure IX.02 -- Tunnel IP - Principe

Le tunnel permet d'encapsuler un protocole dans un autre de même niveau ou supérieur. Précédemment, page [*], nous avons déjà analysé l'encapsulation des couches de la pile Arpa selon une progression naturelle de fonctionnalités. Ici, si le principe d'encapsulation est conservé, la logique initiale de construction, elle, est bousculée. Par exemple on peut envisager d'encapsuler IP dans de multiple protocole autres qu'Ethernet, comme PPPIX5, IP, dans une couche de transport comme TCP, voire même dans une couche applicative comme HTTP. Ce dernier exemple peut paraître `` contre nature '' et pourtant cela fonctionne...

Construire un tunnel a un coût : d'une part celui de la perte d'espace de données dans le datagramme (il faut loger un ou plusieurs en-têtes supplémentaires et le MTU reste constant lui !) et d'autre part celui du traitement supplémentaire (décapsulation, analyse) engendré par l'ajout de ces nouveaux en-têtes.

En résumé, construire un tunnel se traduit par une perte d'espace pour les données dans les datagrammes et par une consommation accrue de cycles cpus pour traiter les en-têtes supplémentaires. Heureusement le gain en fonctionnalités pour le réseau est substanciel, comme les exemples qui vont suivre tâchent de l'illustrer !

Les tunnels qui transitent par une couche de transport sont gérés par une application (par exemple sshd ou httptunnel). Aussi le trafic de datagrammes remonte au niveau applicatif pour redescendre au niveau IP, ce qui a l'avantage de pouvoir être mis en \oeuvre par un utilisateur n'ayant pas nécessairement les droits de l'administrateurIX6, mais par contre, outre une consommation supplémentaire de cycles cpu et des changements de contexte inhérents à l'architecture logicielleIX7, a l'inconvénient d'être dédié à un seul port (par exemple celui d'une application non cryptée comme pop au travers une liaison ssh. Il faut noter que depuis la version 4.3 d'OpenSSH les tunnels sont possibles, non limités à un seul port)IX8.

Encapsuler IP dans IP a l'avantage de rester généraliste du point de vue des applications. Sur la figure IX.02 le tunnel IP encapsule donc de l'IP dans lui même. Pour les routeurs qui acheminent ce trafic il s'agit de datagrammes IP avec le type 4 (cf le fichier /etc/protocols au lieu des types 1 (icmp) 6 (tcp) ou 17 (udp) plus habituels.

2.1 Tunnel IP avec l'interface gif

La figure 
Romanchapter.03
illustre l'encapsulation d'IP dans IP grâce à l'usage du `` generic tunnel interface ''IX9. Il s'agit d'un pseudo-device (pas d'interface réel associé au device), qui permet d'encapsuler de l'IP (version 4 ou 6) dans de l'IP (version 4 ou 6)IX10.

Le but de cet exemple de tunnel est de montrer un routage de datagrammes issus d'un réseau privé, le 192.168.2.0/24 (RFC 1918), depuis la machine B (IPB), vers la machine A (IPA) et qui traverse un réseau public routé quelconque, non nommé sur la figure, de telle sorte que A soit intégrée au LAN 192.168.2.0/24.

  • Par hypothèse la machine A sait comment router vers le 192.168.2.0/24. Un de ses interfaces réseaux peut être surchargé avec une adresse dans cette classe C.

  • Le réseau 192.168.249.0/30 sert de réseau d'interconnexion entre les deux machines. Concrètement, il s'agit d'attribuer une adresse IP à chacun des pseudo-devices, qui ne soit pas déjà dans l'un des réseaux attachés à chacune des machines.

    Conceptuellement, il serait parfaitement possible d'utiliser, par exemple, des adresses dans le 192.168.2.0/24, mais l'auteur préfère l'usage d'un réseau d'interconnexion qui permet de bien séparer fonctionnellement les adresses IP qui constituent le tunnel en lui-même de celles qui sont amenées à l'emprunter.

    De plus, si on souhaite (et c'est une quasi obligation quand on utilise des tunnels) ajouter un filtrage IP sur la machine B, il est beaucoup plus aisé pour la conception des règles de filtrage de considérer l'origine des datagrammes ayant une adresse source dans le 192.168.2.0/24 uniquement derrière le filtre.

Examinons maintenant quelle pourrait être la configuration spécifique à ce tunnel, Sur la machine A :

ifconfig gif0 create
ifconfig gif0 inet tunnel IP(A) IP(B)
ifconfig gif0 inet 192.168.249.1 192.168.249.2 netmask 0xfffffffc
route add -net 192.168.2.0 192.168.249.2

Notez l'ajout de la route spécifique vers le réseau non directement raccordé. Puis, exécution des opérations symétriques sur la machine B :

ifconfig gif0 create
ifconfig gif0 inet tunnel IP(B) IP(A)
ifconfig gif0 inet 192.168.249.2 192.168.249.1 netmask 0xfffffffc

\includegraphics{fig.net.03.ps}
figure IX.03 -- Tunnel IP - cas concrêt

Notez que la première ligne de configuration précise la source et la destination réelle des datagrammes alors que la deuxième indique l'adresse locale et distante des extrémités du tunnel. C'est une écriture particulière, adaptée au pilote de l'interface gif0 pour la configuration des tunnels.

Sur la machine B, on peut voir le résultat de la configuration comme ça :

$ ifconfig gif0
gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280
    tunnel inet IP(B) --> IP(A)
    inet 192.168.249.2 -> 192.168.249.1 netmask 0xfffffffc
$ netstat -f inet -rn
...
192.168.249.1      192.168.249.2      UH          0     9779      -  gif0

Et sur la machine A (remarquez la plus petite valeur de MTU) :

$ ifconfig gif0
gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280
    tunnel inet IP(A) --> IP(B)
    inet 192.168.249.1 -> 192.168.249.2 netmask 0xfffffffc
$ netstat -f inet -rn
...
192.168.2.0/24     192.168.249.2      UGS         0       83   gif0
192.168.249.2      192.168.249.1      UH          1     8941   gif0

Enfin, si on examineIX11 sur les interfaces hme0 puis gif0 de B le passage des datagrammes d'un ping, envoyés depuis A vers 192.168.2.200, l'observation pratique rejoint la théorie : on retrouve bien sur l'interface du tunnel (gif0) l'en-tête 2, décapsulé de son en-tête 1. Le datagramme est alors disponible au niveau de la pile IP de B pour être routé (routage directIX12 ici) vers 192.168.2.200.

Le tableau qui suit résume le contenu des en-têtes observées :

Sur l'interface hme0
En-tête 1 En-tête 2
Src IPA 192.168.249.1
Dst IPB 192.168.2.200
Code ipencap(4) icmp
Sur l'interface gif0
En-tête
Src 192.168.249.1
Dst 192.168.2.200
Code icmp

Remarques :

Attention, les routeurs filtrants doivent être spécialement configurés pour laisser passer ce type de traficIX13. Les `` core gateway '' le laissent passer.

Il est intéressant de noter que le déploiement d'IPv6 est d'abord basé sur l'encapsulation de trames de la version 6 dans des trames de la version 4, en attendant que tous les routeurs soient capables de router IPv6 nativement.

Enfin pour conclure, est-il nécessaire de préciser que même encapsulés dans IP, nos datagrammes n'en sont pas moins lisibles par des yeux indiscrêts ? Pour s'en prémunir il nous faut examiner une technologie complétementaire... Dans le paragraphe suivant !

2.2 IPsec et VPN

IPsec est un protocole de sécurité inclus dans la couche IP elle-même. Il est défini dans la RFC 2401. Ce paragraphe aborde brièvement la question du point de vue du protocole et de sa place dans la pile Arpa, tout en laissant volontairement dans un certain flou les aspects liés à la cryptographie, clairement absents des objectifs de ce coursIX14.

2.2.1 IPsec dans quel but ?

IPsec est un point de passage obligé pour tout administrateur de réseau qui souhaite mettre en place une politique de sécurité. D'ailleurs, pour faire le lien avec le paragraphe qui précède, précisons qu'IPsec encapsulé dans IP (formellement, un tunnel) porte un nom, le VPN (`` Virtual Private Network '') ! Nous avons examiné comment un tunnel accroît l'étendue d'un réseau au travers d'autres réseaux. Ajouter Ipsec introduit, entre autres, une dimension de sécurité très utilisée pour relier des machines - ou des réseaux - physiquement localisés n'importe où il y a un accès IP, en réseaux virtuels sécurisés ! C'est pour cette raison qu'Ipsec est un artefact incontournable de la panoplie sécuritaire sur les réseaux.

Nous aurions pu conclure le chapitre sur IP page [*] par cette constatation que le protocole IP est lisible par tout le monde y compris par les indiscrêts et que quasiment n'importe quel `` bricoleur '' peut forger de faux datagrammes (`` fake datagrams '') pour empoisonner un réseau, voire détourner les services d'une machine. Ainsi, tout ce qui renforce la sécurité IP est une bonne chose, surtout à l'heure des réseaux `` wifi '' dont les limites de portée ne sont pas maîtrisables.

IPsec renforce la sécurité d'IP sur plusieurs points :

Confidentialité
Les données d'IP (protocole de transport et données applicatives) sont cryptées, donc normalement non inspectables avec tout outil d'analyse de réseau accessible sur le réseau lui-même.

Authentification
La source du datagramme ne peut être qu'un seul émetteur, et non un intermédiaire non prévu.

Intégrité
La totalité des données est protégée par une somme de contrôle (checksum), travail normalement dévolu à la couche de transport mais qui au niveau d'IP permet d'écarter tout datagramme qui aurait été modifié pendant son transport.

Dispositif `` anti-rejeux ''
pour éviter les attaques du type `` man-in-the-middle '' consistants à capturer un ou plusieurs datagrammes (cryptés) dans le but de les envoyer à nouveau pour bénéficier du même effet produit que l'envoi initial.

2.2.2 IPsec en résumé

Ipsec (RFC 2401) est un assemblage de quatre protocoles :

ESP
(`` Encapsulating Security Payload '') est défini par la RFC 2406. Il assure la confidentialité par l'usage d'algorithmes de cryptage comme `` DES '' (RFC 2405) , `` 3DES '' (RFC 2451), `` CAST-128 '' (RFC 2144) ou encore `` blowfish '' (RFC 2451), la liste n'est pas exhaustive... Il faut juste noter qu'il s'agit d'algorithmes basés sur l'existence un secret partagé (manuellement dans un fichier ou crée dynamiquement avec IKE, voir plus bas) entre les parties qui échangent des messages, et non sur l'échange d'une clef publique. Cette remarque a un impact sur la manière avec laquelle on doit les configurer !

AH
(`` Authentication Header '') est défini par la RFC 2402. Il assure l'authentification, c'est à dire qu'il cherche à certifier que les deux couches IP qui dialoguent sont bien celles qu'elles prétendent être, puis l'intégrité des données par le calcul d'un checksum. Il faut noter que ce dernier travail empiète largement sur les attributions de la couche de transport mais se justifie compte-tenu des exigences inhérentes au fonctionnement d'IPsec.

IPcomp
(`` IP payload compression '') sert à compresser les données avant de les crypter. Son action est rendue nécessaire pour tenter de compenser la perte de la place occupée par les en-têtes ajoutés. Bien entendu IPcomp peut être utilisé seul.

IKE
(`` Internet Key Exchange '') est défini par la RFC 2409. Ce protocole n'est pas formellement indispensable au bon fonctionnement d'IPsec mais lui apporte un mécanisme d'échange de clefs, au démarrage des échanges et au cours du temps. Ainsi la clef de chiffrement n'est plus définie de manière statique dans un fichier mais change continuellement au cours du temps, ce qui est meilleur du point de vue de la sécurité.

Du point de vue de l'administration système et réseau, la mise en place de ce protocole passe par l'usage d'un daemonIX15, par exemple racoon, et par une ouverture de port UDP (isakmp/500) supplémentaire dans le filtrage du réseau. Une négociation décrite dans la RFC 2409 se déroule entre les hôtes qui doivent dialoguer, ce qui peut entrainer une certaine latence au début des échanges.

Les 32 bits de l'adresse IP de destinationIX16 permettent théoriquement d'exprimer un adressage de type unicast ou multicast ou broadcast. Si ces cas de figures sont tous théoriquement possibles, les implémentations d'IPsec ne supportent que l'unicast. La conséquence est importante sur le déploiement d'IPsec, il est effectué `` point à point '' plutôt que généralisé pour tout un réseau.

Ce travail est inclus dans ce qui est nommé `` politique de sécurité '' dans la RFC 2401.

Pour AH comme pour ESP, l'ajout de données vient se placer entre l'en-tête IP et les données. Les deux protocoles peuvent être utilisés ensembles ou séparement, c'est un choix qui relève de la politique de sécurité. Pour en tenir compte, la négociation qui a lieu lors de l'établissement d'IPsec repose sur ce que la RFC appelle des SA (`` Security Association '').

Une SA est formellement un triplet unique constitué d'un index unique , le SPI

figure 
Romanchapter.04 -- En-têtes d'IPsec
\includegraphics{fig.net.04.ps}

(`` Security Parameter Index '') sorte de numéro d'identification IP supplémentaireIX17 inclus dans l'en-tête AH ou ESP, de l'adresse IP du destinataire et du protocole ESP ou d'AH. Si les deux protocoles doivent être utilisés, il faut négocier deux SAs.

2.2.3 Comment utiliser IPsec ?

Aux deux protocoles AH et ESP, s'ajoutent deux manières d'utiliser IPsec, soit directement d'une machine à une autre, on parle alors de `` mode transport '' soit encore en l'encapsulant dans un tunnel comme vu au paragraphe 2 page [*] et on parle de `` mode tunnel '', plus connu sous le vocable `` VPN ''.

La RFC 2401 indique que toute implémentation se réclamant d'IPsec doit supporter les 4 associations qui suivent.

La sécurité entre deux hôtes qui supporte IPsec, au travers l'Internet, en mode transport ou en mode tunnel. Les datagrammes peuvent avoir les structures suivantes :

Mode transport
[IP1][AH][Transport][Data]
[IP1][ESP][Transport][Data]
[IP1][AH][ESP][Transport][Data]
Mode tunnel
[IP2][AH][IP1][Transport][Data]
[IP2][ESP][IP1][Transport][Data]

figure IX.05 -- Association 1 \includegraphics{fig.net.05.ps}

Remarque : En mode tunnel pour ce premier cas il n'y a pas d'obligation du support d'AH et ESP simultanément. Quand ils sont appliqués tous les deux, il faut d'abord appliquer ESP, puis AH aux datagrammes.

figure IX.06 -- Association 2 \includegraphics{fig.net.06.ps}

Le mode tunnel est le seul requis ici. Nous avons donc une structure de datagramme qui a ces formes possibles :

Mode tunnel
[IP2][AH][IP1][Transport][Data]
[IP2][ESP][IP1][Transport][Data]

C'est la combinaison des deux premiers cas, on ajoute la sécurité entre les hôtes terminaux à celle déjà apportée par les routeurs.

La propagation du trafic de type ISAKMP (protocole IKE) au travers les routeurs est un plus.

figure IX.07 -- Association 3 \includegraphics{fig.net.07.ps}

figure IX.08 -- Association 4 \includegraphics{fig.net.08.ps}

Ce dernier cas est celui d'un poste isolé qui se raccorde par exemple à l'intranet de son entreprise via un modem ou un accès IP non sûr, et qui utilise un protocole non crypté comme AppleTalk, ou PoP, par exemple.

Le mode tunnel est seul requis entre l'hôte H1 et la passerelle G1. Ensuite, entre H1 et H2 on revient au premier cas.

2.2.4 Implémentation d'IPsec

L'implémentation d'IPsec sur les machines FreeBSD et NetBSd est issue du projet KAMEIX18 et est ainsi fortement lié au développement de la pile IPv6.

Les protocoles AH, ESP et IPcomp sont inclus dans le noyau directement. La gestion des clefs s'effectue via une commande externe, setkey qui pilote une table de gestion des clefs située elle aussi dans le noyau, grâce à des socket de type PF_KEY

Les clefs sont soit placées de manière semi-définitive dans le fichier de configuration d'ipsec lui-même (par exemple /etc/ipsec.conf soit confiée aux bons soins d'un programme externe qui se charge de les crée et de les propager à l'aide du protocole IKE. Quelques daemons savent faire cela, notamment racoon du projet KAME.

Si nous reconsidérons la figure IX.03 les machines A et B jouent le rôle des passerelles G1 et G2 de la figure IX.06association 2). Les fichiers de configuration IPsec (AH et ESP) pourraient être :

Sur la machine A

spdadd IP(A) IP(B) any -P out ipsec \
     esp/tunnel/192.168.249.1-192.168.249.2/require \
     ah/tunnel/192.168.249.1-192.168.249.2/require;
spdadd IP(B) IP(A) any -P in  ipsec \
     esp/tunnel/192.168.249.2-192.168.249.1/require \
     ah/tunnel/192.168.249.2-192.168.249.1/require;

spdadd est une instruction de la commande setkey. Il faut définir sa politique de sécurité, c'est à dire ce que l'on souhaite en entrée (in), en sortie (out) puis un choix de protocole (esp, ah, ipcomp), un mode (tunnel ici) avec l'entrée et la sortie du tunnel, enfin un niveau d'usage (require ici indique que tous échanges doivent utiliser IPsec).

Sur la machine B

spdadd IP(B) IP(A) any -P out ipsec \
     esp/tunnel/192.168.249.2-192.168.249.1/require \
     ah/tunnel/192.168.249.2-192.168.249.1/require;
spdadd IP(A) IP(B) any -P in  ipsec \
     esp/tunnel/192.168.249.1-192.168.249.2/require \
     ah/tunnel/192.168.249.1-192.168.249.2/require;

La clef de cryptage ne figure pas dans ce fichier car l'exemple utilise IKE pour cela, à l'aide de l'outil racoon.

Enfin, un excellent document de configuration se trouve sur le site du projet NetBSD :

3 Proxy

\includegraphics{fig.net.09.ps}
figure IX.09 -- Proxy

Le propos d'un proxy est de concentrer le trafic réseau via une seule machine pour toute une variété de protocoles (telnet, http, smtp, ...). Il existe des proxy spécialisés sur tel ou tel protocole, qui effectuent donc des tâches potentiellement très complexes (par exemple squid pour http) ou très généraux et donc moins performants sur chaque protocole (cf nat au paragraphe suivant).

Tout le trafic réseau qui passe par un proxy s'y arrête pour en repartir. Les conditions de ce `` rebond '' peuvent être paramètrées par des règles d'accès, ce qui en fait un élément utile en sécurité des réseaux (voir la RFC 1919).

Section en chantier, précisions en cours...

4 Translation d'adresses

La pénurie d'adresses IP est à l'origine du besoin de translation des adresses. Son principe se trouve décrit dans la RFC 1631.

Un tel dispositif se situe généralement à la frontière entre un réseau de type privé et un autre de type publique. Le cas le plus général est lorsque le réseau publique est l'internet lui-même, et le réseau privé celui d'une entité quelconque abonnée aux services d'accès réseau d'un FAI, mais ce n'est pas une obligation conceptuelle.

\includegraphics{fig.net.10.ps}
figure IX.10 -- R translate dynamiquement des couples (adresse IP, numéro de port)

Sur la figure 10 le réseau privé comporte plus d'hôtes que d'adresses IP fournies dans le réseau publique. Pour pouvoir se développer en s'affranchissant de cette contrainte, l'usage de la translation d'adresses et de ports -- NAT et PAT, ou encore NAPT comme `` Network Address Port Translation '' -- est incontournable parce que le réseau privé est bâti avec des adresses non routables (cf page [*]) de la RFC 1918, potentiellement illimitées à l'échelle d'une entité privée, même grande...

R dispose de quelques adresses (un pool d'une adresse au minimum) routables sur le réseau publique, qu'il peut assigner aux hôtes du réseau privé (C) qui initient une connexion vers le réseau publique (S). Cette assignation peut être dynamique ou statique.

Un datagramme qui part de C vers S a une adresse source non exploitable sur le réseau publique. R maintient une table, si C n'est pas déjà associé à une adresse routable du pool alloué à R, celui-ci lui en attribue une et modifie à la volée l'adresse source du datagramme, de telle sorte que le retour de S puisse être routé convenablement jusqu'à R. Puis R modifie l'adresse de destination du datagramme pour lui donner l'adresse de C, sur le réseau privé.

Si on fait l'hypothèse que la plupart des hôtes du réseau privé n'établissent pas simultanément des connexions vers le réseau publique, le pool d'adresses publiques peut rester beaucoup plus petit que le nombre d'hôtes du réseau privé. Mais cette hypothèse est fragile considérant les besoins toujours plus grands d'accéder à l'information répartie.

Ce premier mécanisme se complète alors d'un second qui est le NAPT. En plus de traduire l'adresse IP à la volée, R attribue également un numéro de port différent. Ce dispositif autorise l'usage simultanné d'une même adresse IP publique par des milliers d'hôtes du réseau privé.

Le fonctionnement de la translation d'adresse et de port engendre une propriété intéressante pour R : il ne laisse passer aucun paquet du réseau publique vers le réseau privé qui ne soit pas la réponse à une sollicitation venue du réseau privé, c'est donc en standard un fonctionnement à sens unique. Cette propriété peut être remise en question, voir le paragraphe 4.2.

Enfin, du fait du changement d'adresse source à l'aller puis d'adresse de destination au retour du datagramme, le NAPT rend impossible l'usage d'IPSEC (page [*]) entre une machine quelconque du réseau publique et l'interface de R dans ce réseau et sur laquelle s'effectue le travail de translation (il a modification de l'en-tête, ce contre quoi justement IPSEC est sensé nous protéger...). Le seul moyen dans ce cas de figure est de passer par l'usage d'un tunnel, comme vu paragraphe 2 (page [*]).

Tous les routeurs modernes ont les fonctions de translation d'adresses et de ports incluses dans leurs fonctionnalités standards.

4.1 NAPT sur un routeur de type PC avec natd

Natd est l'outil logiciel libre bien connu des administrateurs réseaux. Il fonctionne selon le modèle de la figure 11IX19.

\includegraphics{fig.net.11.ps}
figure IX.11 -- Machine NAPT en routeur

Dans la figure 11, la machine `` NAPT '' est par hypothèse configurée en routeur. Elle représente la route par défaut pour la machine A.

Natd convertit les adresses IP à la volée. Un datagramme voit ses adresses sources (et éventuellement de destination, voir plus loin) changer dynamiquement. Examinons en détail les composantes d'une connexion établie depuis A vers B, donc lors d'un trafic `` sortant '' vis à vis de R.

Pour la machine A

  • La machine A s'adresse directement à la machine 193.104.112.163 en utilisant son routeur par défaut.

  • L'utilisateur de la machine A `` voit '' la connexion soit la forme :
    {tcp, IP Hôte A, port A, IP Hôte B, port B}

Pour la machine B

  • La machine B voit une connexion arriver en provenance de `` NAPT ''.

  • La machine B n'a pas connaissance de la machine A, elle dialogue avec la machine NAPT selon :
    {tcp, IP Hôte B, port B, IP Hôte NAT, port A'}

Pour la machine NAPT

  • La machine NAPT a connaissance des 2 réseaux, elle translate dynamiquement les adresses et les ports dans les deux sens.

  • La machine NAPT fait le travail d'un proxy transparent pour la couche 3 ISO puisque chaque connexion s'y arrête puis en repart sans configuration particulière de la part de l'administrateur de A ou de B.

  • La translation (ou `` IP masquerading '') s'effectue dynamiquement selon l'adresse demandée.

  • La translation d'adresse s'effectue pour les datagrammes qui traversent l'interface if_ext. Le dialogue entre cette machine et les autres machines du réseau `` privé '', via l'interface if_int ne fait pas l'objet d'une translation d'adresse.

  • La situation de la machine A est plutôt celle d'un poste client car non vu de l'extérieur de son réseau. Être serveur est toutefois possible comme il l'est expliqué avec l'usage de natd au paragraphe [*].

4.1.1 Interactions entre natd et le noyau

L'usage de natd sur un PC est un travail consommateur de ressources cpu parceque les datagrammes font l'objet de deux recopies et de deux changements de contexte supplémentaires : ils sont traités par un processus qui s'exécute en mode utilisateur. Sur la figure 12 le processus natd ouvre une socket en mode raw pour communiquer directement avec la couche IP :

divertInOut = socket (PF_INET, SOCK_RAW, IPPROTO_DIVERT);

Le noyau IP, muni du mécanisme adéquat IX20 redirige tout le trafic entrant et sortant d'un interface réseau, vers un numéro de port convenu à la configuration, par exemple le port 6668, à ajouter dans /etc/services :

natd 6668/divert # Network Address Translation socket

Natd lit tous les datagrammes et ne retient pour traitements que ceux qui sont à destination du port dédié.

\includegraphics{fig.net.12.ps}
figure 12 -- Interactions entre natd et le noyau de FreeBSD

Compte tenu du fichier de configuration, les adresses IP des datagrammes ainsi que les numéros de ports sont reécrits et reinjectés dans le noyau IP qui les traite comme d'autres datagrammes (routage, filtrage...).


4.2 Translation d'adresses vers le réseau privé

Les figures qui précèdent ne concernent que les connexions sortantes du réseau privé, mais on peut envisager l'inverse. Bien entendu vu du réseau publique on ne voit que les adresses du pool attribué au routeur R. Le mécanisme de translation de port permet éventuellement de ventiler les connexions entrantes vers une ou plusieurs machines privées. Le critère discriminant est le numéro de port demandé.

On distingue deux attitudes, soit tout le flux entrant est redirigé sur une seule machine, soit il est est effectué en fonction du port, donc du service demandé.

La littérature appelle ce cas le `` static nat ''. À l'insu des utilisateurs de la machine `` NAPT '' du réseau publique, tout le trafic IP (c'est ainsi qu'il faut comprendre l'adresse IP 0.0.0.0) est renvoyé sur la machine S, et celle-ci n'est pas `` visible '' du réseau public.

\includegraphics{fig.net.13.ps}
figure IX.13 -- `` Static Nat ''

La configuration du natd pourrait être :

natd -interface if_ext -redirect_address IP(S) 0.0.0.0

La figure 14 nous montre un exemple de trafic éclaté en fonction du service demandé, ce qui permet une gestion beaucoup fine des ressources du réseau.

Une demande de connexion de l'hôte distant R sur la machine NAT et au port 80 va être réacheminée vers la machine interne HTTP et sur le port que l'on souhaite, par exemple 8080.

Même remarque pour les deux autres services présentés.

La machine HTTP voit la connexion en provenance de la machine R sous sa forme exacte :

{tcp, IP Hôte R, Port R, IP Hôte HTTP, 8080}

La machine R ne voit que la partie `` publique '' de la connexion :

{tcp, IP Hôte R, Port R, IP Hôte NAT, 80}

La configuration NAPT pourrait ressembler à :

            #
            # Configuration multiservices
            #
            redirect_port tcp http:8080 80
            redirect_port tcp smtp:25 25
            redirect_port tcp dns:domain domain
            redirect_port udp dns:domain domain

\includegraphics{fig.net.14.ps}
figure 14 -- Configuration multiservices

4.3 NAPT sur un routeur CISCO

Voir en travaux pratiques...

5 Filtrage IP

Le propos du filtrage IP est d'appliquer des règles de filtrage à un flux de datagrammes IP afin de prendre une décision qui est le plus souvent binaire : laisser passer ou ne pas laisser passer avec en option de conserver une trace de passage (des logs).

Par son usage on cherche à protéger un site ou une machine d'un flux de datagrammes pour lesquels on suspecte que tous ne sont pas envoyés par des utilisateurs bienveillants. Le filtre s'efforce d'éliminer le trafic indésirable à partir de considérations à priori, mais il ne représente pas la panacée en matière de sécurité sur les réseaux, autrement dit il ne faut pas penser qu'un filtre IP suffit à règler tous les problèmes de sécurité d'un site ou d'un hôte.

En effet, à partir du moment où le filtre laisse passer certains datagrammes, même à priori innocents, une porte est ouverte au détournement de l'usage initial du service offert. Dans ces conditions il faut se rendre à l'évidence : il n'y a pas de sécurité absolue sur le réseauIX21 !

Dans la littérature, un routeur filtrant est nommé `` FireWall '', qu'il faut traduire en `` pare-feux ''.

Le filtrage IP est une caractéristique essentielle de tout routeur digne de ce nom !

Il est aussi possible de faire du filtrage IP avec les Unix libres, c'est cette approche qui est choisie dans les paragraphes qui suivent parcequ'accessible à toutes les bourses...

Si les détails de mise en \oeuvre diffèrent d'une implémentation à une autre, le fond du problème reste le même. L'implémentation choisie ici est ipfw, le filtre natif de FreeBSDIX22. Il existe d'autres filtre, notamment ipf, encore une fois le principe reste toujours le même.

5.1 Filtrage IP sur un routeur CISCO

Voir en travaux pratiques...

5.2 Le cas d'ipfw de FreeBSD

Le filtre IP en question est implémenté dans le noyau, il est activé dès lors que l'options IPFIREWALL est ajoutée dans le noyau. On peut également y adjoindre l'option IPFIREWALL_VERBOSE pour le rendre bavardIX23, ce qu'apprécient par dessus tout les administrateurs réseaux, soucieux d'avoir une connaissance précise de la nature du trafic sur leurs réseaux...

Le filtre est un module du noyau, chargé au démarrage, et qui se paramètre à l'aide de la commande ipfw. Celle-ci est utilisée dans les scripts de démarrage pour dicter au noyau les règles de filtrage, lues dans un fichier nommé par defaut /etc/rc.firewall. les scripts de démarrage pour dicter au noyau les règles de filtrage,

Établir des règles de filtrage IP sous-entend avoir une connaissance exhaustive de tous les éléments qui s'y rattachent :

  • Nom des interfaces réseaux impliquées
  • Protocoles réseaux employés (tcp, udp, icmp,...)
  • Protocoles applicatifs autorisés (smtp, domain, http...)
  • Adresses IP, numéro de ports, masque de sous-réseaux
  • Sens du trafic par rapport aux interfaces ci-dessus

Il est assez aisé de mettre en place un filtrage simple, par contre cette opération peut devenir complexe dès lors qu'on utilise des protocoles applicatifs compliqués, mettant en jeux une stratégie d'utilisation des ports et des adresses non triviale.

Considérons un site simple, comme celui de la figure IX.15. La machine C accède depuis l'extérieur à la machine S, protégée par le filtrage IP activé sur la machine R, qui agit donc en tant que routeur filtrant.

\includegraphics{fig.net.15.ps}
figure IX.15 -- Configuration simple de filtrage

Adaptons-y les règles du modèle de base, extraites du fichier /etc/rc.firewall de la configuration standard d'une machine FreeBSD récente (c'est un script shell). L'examen de ces règles nous permet de découvrir la nature du trafic autorisé ou non.

\framebox[15cm][l]{
\parbox[l]{15cm} {
\begin{center}
\includegraphics{regles_1.eps}
\end{center} }
}

Quelques considérations :

  • Les règles sont parcourues de la première à la dernière, si aucune convient, l'action par défaut consiste à bloquer le trafic (peut être changée).

  • Dès qu'une règle convient, elle est appliquée et le filtrage s'arrête.

  • Le filtrage IP consomme des ressources cpu, donc pour améliorer les performances il vaut mieux placer en tête de liste les règles employées le plus couramment.

Il faut remarquer que la machine 193.104.1.228 est visible depuis l'extérieure et utilise une adresse officiellement routée.

Une tentative d'accès sur un service non autorisé se traduit par un message d'erreur (syslogd). Par exemple supposons que l'utilisateur de la station `` C '' exécute la commande suivante :

telnet 193.104.1.228

Il va obtenir le message :

telnet: Unable to connect to remote host: Connection timed out

Tandis que l'administrateur du réseau 193.104.1.0 va constater la tentative d'intrusion par le message :

ipfw: 3310 Deny TCP Adr.IP Hôte C:2735 193.104.1.228:23 in via ed0

Par contre, si l'intrusion consiste à détourner l'usage du service SMTP, l'administrateur du réseau 193.104.1.0 ne verra rien par ce biais puisque l'accès SMTP est autorisé sur la machine 193.104.1.228IX24

6 Exemple complet

Dans cette partie nous examinons le cas de la configuration de la figure IX.16, synthèse des figures
Romanchapter.13,
Romanchapter.14 et
Romanchapter.15. C'est une configuration très employée du fait de la distribution parcimonieuse d'adresses IP par les fournisseurs d'accès.

\includegraphics{fig.net.16.ps}
cm figure IX.16 -- Translation d'adresse et filtrage IP

Le propos est de mettre en place un routeur filtrant effectuant en plus la translation d'adresses IP. La juxtaposition des deux services induit peu de changements dans la configuration des règles de filtrage.

Commençons par les règles de filtrage :

\framebox[15cm][l]{
\parbox[l]{15cm} {
\begin{center}
\includegraphics{regles_2.eps}
\end{center} }
}

Dans le principe l'hôte 193.104.1.228 n'est plus visible de l'extérieur, les services sont en apparence hébergés par la machine R qui se charge de re-router les datagrammes en modifiant dynamiquement l'adresse de destination.

Dans l'ordre des opérations, la translation d'adresses est effectuée avant le filtrage IP. Ce sont donc des adresses IP modifiées qui sont introduites dans les règles de filtrage !

Terminons avec la configuration de natd. Voici le contenu du fichier /etc/natd.conf pour cette situation :

                    redirect_port tcp 193.104.1.228:80 80
                    redirect_port tcp 193.104.1.228:25 25
                    redirect_port tcp 193.104.1.228:53 53
                    redirect_port udp 193.104.1.228:53 53
                    redirect_port udp 193.104.1.228:123 123

Où l'on s'apperçoit que la configuration n'a pratiquement pas changé fondamentalement ormis par l'introduction de la règle :

ipfw add divert 6668 all from any to any via ${oif}

Qui indique au filtre que tout ce qui provient de l'interface `` oif '' est à lire sur le port 6668, donc a déjà subit la translation d'adresse avant d'être soumis au filtrage IP. Ainsi une demande de connexion sur le port 25 de la machine 193.104.1.1 sera transformée en une demande de connexion sur le port 25 de la machine 193.104.1.228, qui est autorisé.

Pour l'utilisateur de la station `` C '' la machine 193.104.1.228 n'est plus visible, seule la machine d'adresse 193.104.1.1 semble cumuler tous les services !


7 Bibliographie

RFC 1631
`` The IP Network Address Translator (NAT). '' K. Egevang & P. Francis. May 1994. (Format: TXT=22714 bytes) (Status: INFORMATIONAL)

RFC 1918
`` Address Allocation for Private Internets. '' Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J.de Groot & E. Lear. February 1996. (Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status: BEST CURRENT PRACTICE)

RFC 1825
``  Security Architecture for the Internet Protocol. '' R. Atkinson. August 1995. (Format: TXT=56772 bytes) (Obsoleted by RFC2401) (Status: PROPOSED STANDARD)

RFC 2364
`` PPP Over AAL5. '' G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format: TXT=23539 bytes) (Status: PROPOSED STANDARD)

RFC 2401
`` Security Architecture for the Internet Protocol. '' S. Kent, R. Atkinson. November 1998. (Format: TXT=168162 bytes) (Obsoletes RFC1825) (Updated by RFC3168) (Status: PROPOSED STANDARD)

RFC 2402
`` IP Authentication Header. '' S. Kent, R. Atkinson. November 1998. (Format: TXT=52831 bytes) (Obsoletes RFC1826) (Status: PROPOSED STANDARD)

RFC 2406
`` IP Encapsulating Security Payload (ESP). '' S. Kent, R. Atkinson. November 1998. (Format: TXT=54202 bytes) (Obsoletes RFC1827) (Status: PROPOSED STANDARD)

RFC 2409
`` The Internet Key Exchange (IKE). '' D. Harkins, D. Carrel. November 1998. (Format: TXT=94949 bytes) (Status: PROPOSED STANDARD)

RFC 2516
`` A Method for Transmitting PPP Over Ethernet (PPPoE). '' L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. February 1999. (Format: TXT=32537 bytes) (Status: INFORMATIONAL)

RFC 3168
`` The Addition of Explicit Congestion Notification (ECN) to IP. '' K. Ramakrishnan, S. Floyd, D. Black. September 2001. (Format: TXT=170966 bytes) (Obsoletes RFC2481) (Updates RFC2474, RFC2401, RFC0793) (Status: PROPOSED STANDARD)

RFC 1919
`` Classical versus Transparent IP Proxies ''. M. Chatel. March 1996. (Format: TXT=87374 bytes) (Status: INFORMATIONAL)

Sans oublier :

  • W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols - Addison-Wesley

  • `` Firewalls and Internet Security '' - William R. Cheswick, Steven M. Bellovin - Addison-Wesley 1994.

  • `` Building Internet Firewalls '' - D. Brent Chapman and Elizabeth D. Zwicky - O´ Reilly - 1995. Steven M. Bellovin - Addison-Wesley 1994.


next up previous contents index
Next: C Protocoles applicatifs Up: B Réseaux IP avancés Previous: VIII Routage dynamique d'IP   Contents   Index
Fran├žois Laissus 2009-02-27