Cours d'introduction à TCP/IP

La machine B (d'adresse IP fixe ipB) héberge par exemple le service HTTP d'adresse IP WWW. 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 IP WWW aura été retirée de la machine B pour être reconfigurée sur l'une d'entre 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'exploitation modernes facilitent la construction de machines virtuelles. FreeBSD a un mécanisme très adapté nommé « jail(80) », 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é « zone(81) ».

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 multicores et de l'évolution des architectures SMP(82) d'une part, et d'autre part la maturité des technologies de virtualisation des systèmes d'exploitation(83)

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ême, puisque proportionnel au nombre d'instances en exploitation...

Le tunnel permet d'encapsuler un protocole dans un autre de même niveau ou supérieur. Précédemment, 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 multiples protocoles autres qu'Ethernet, comme PPP(84), IP, dans une couche de transport comme TCP, voire 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 entê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 entê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 CPU pour traiter les entêtes supplémentaires. Heureusement le gain en fonctionnalités pour le réseau est substantiel, 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 œuvre par un utilisateur n'ayant pas nécessairement les droits de l'administrateur(85), mais par contre, outre une consommation supplémentaire de cycles CPU et des changements de contexte inhérents à l'architecture logicielle(86), 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)(87).

Encapsuler IP dans IP a l'avantage de rester généraliste du point de vue des applications. Sur la figure VIII.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.

9-2-1. Tunnel IP avec l'interface gif▲

La figure VIII.03 illustre l'encapsulation d'IP dans IP grâce à l'usage du « generic tunnel interface »(88). Il s'agit d'un pseudodevice (pas d'interface réelle associée au device), qui permet d'encapsuler de l'IP (version 4 ou 6) dans de l'IP (version 4 ou 6)(89).

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. Une de ces interfaces réseau peut être surchargée 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 pseudodevices, 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 :

 

Sélectionnez

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 :

 

Sélectionnez

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

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 :

 

Sélectionnez

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

 

Sélectionnez

$ 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 examine(90) 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'entête 2, décapsulé de son entête 1. Le datagramme est alors disponible au niveau de la pile IP de B pour être routé (routage direct ici) vers 192.168.2.200.

Le tableau qui suit résume le contenu des entêtes observés :

• sur l'interface hme0

Entête 1		Entête 2
Src	IPA	192.168.249.1
Dst	IPB	192.168.2.200
Code	ipencap(4)	icmp

• sur l'interface gif0

Entê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 trafic(91). 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 indiscrets ? Pour s'en prémunir il nous faut examiner une technologie complémentaire... Dans le paragraphe suivant !

9-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 cours(92).

9-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 par cette constatation que le protocole IP est lisible par tout le monde y compris par les indiscrets 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 « antirejeux » : pour éviter les attaques du type « man-in-the-middle » consistant à 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.

9-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 entê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 daemon, 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 entraîner une certaine latence au début des échanges.

Les 32 bits de l'adresse IP de destination permettent théoriquement d'exprimer un adressage de type unicast ou multicast ou broadcast. Si ces cas de figure 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'entête IP et les données. Les deux protocoles peuvent être utilisés ensemble ou séparément, 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 (« Security Parameter Index ») sorte de numéro d'identification IP supplémentaire inclus dans l'entê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 SA.

9-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 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 :

 

Sélectionnez

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]

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.

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

 

Sélectionnez

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 à celles déjà apportées par les routeurs. La propagation du trafic de type ISAKMP (protocole IKE) au travers les routeurs est un plus.

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.

9-2-2-4. Implémentation d'IPsec▲

L'implémentation d'IPsec sur les machines FreeBSD et NetBSd est issue du projet KAME(93) 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 sockets 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 VIII.03 les machines A et B jouent le rôle des passerelles G1 et G2 de la figure VIII.06 (association 2). Les fichiers de configuration IPsec (AH et ESP) pourraient être :

Sur la machine A

 

Sélectionnez

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

 

Sélectionnez

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 :

• http://www.netbsd.org/Documentation/network/ipsec/.

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 proxys 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...

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 public. Le cas le plus général est lorsque le réseau public est l'internet lui-même, et le réseau privé celui d'une entité quelconque abonnée au service d'accès réseau d'un FAI, mais ce n'est pas une obligation conceptuelle.

Sur la figure 10, le réseau privé comporte plus d'hôtes que d'adresses IP fournies dans le réseau public. 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 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 public, qu'il peut assigner aux hôtes du réseau privé (C) qui initient une connexion vers le réseau public (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 public. 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 public, 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 simultané 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 public 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 entre une machine quelconque du réseau public et l'interface de R dans ce réseau et sur laquelle s'effectue le travail de translation (il a modification de l'entête, ce contre quoi justement IPSEC est censé nous protéger...). Le seul moyen dans ce cas de figure est de passer par l'usage d'un tunnel, comme vu paragraphe 2.

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

9-4-1. NAPT sur un routeur de type PC avec natd▲

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

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, voire 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 ?

9-4-1-1. Interactions entre natd et le noyau▲

L'usage de natd sur un PC est un travail consommateur de ressources CPU parce que 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 un socket en mode raw pour communiquer directement avec la couche IP :

 

Sélectionnez

divertInOut = socket (PF INET, SOCK RAW, IPPROTO DIVERT) ;

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

 

Sélectionnez

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é.

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

9-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 public 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 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 public, 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.

La configuration du natd pourrait être :

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

La machine R ne voit que la partie « publique » de la connexion :

 

Sélectionnez

natd -interface if ext -redirect address IP(S) 0.0.0.0

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

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

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

 

Sélectionnez

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

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.

La configuration NAPT pourrait ressembler à :

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

9-4-3. NAPT sur un routeur CISCO▲

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 innocent, 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éseau(96) !

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

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 parce qu'accessible à toutes les bourses...

Si les détails de mise en œuvre 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 FreeBSD(97). Il existe d'autres filtres, notamment ipf, encore une fois le principe reste toujours le même.

9-5-1. Filtrage IP sur un routeur CISCO▲

9-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'option IPFIREWALL est ajoutée dans le noyau. On peut également y adjoindre l'option IPFIREWALL VERBOSE pour le rendre bavard(98), ce qu'apprécient par-dessus tous les administrateurs réseau, 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 défaut /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éseau impliquées ;
• protocoles réseau 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 triviales.

Considérons un site simple, comme celui de la figure VIII.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.

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.

 

Sélectionnez

# --- Interface externe
oif="ed0"
onet="193.104.1.0"
omask="255.255.255.224"
oip="193.104.1.1"

# --- Interface interne
iif="ed1"
inet="193.104.1.224"
imask="255.255.255.224"
iip="193.104.1.225"

# --- Ne pas laisser passer le ??spoofing''
ipfw add deny all from ${inet}:${imask} to any in via ${oif}
ipfw add deny all from ${onet}:${omask} to any in via ${iif}

# --- Ne pas router les adresses de la RFC1918
ipfw add deny all from 192.168.0.0:255.255.0.0 to any via ${oif}
ipfw add deny all from any to 192.168.0.0:255.255.0.0 via ${oif}
ipfw add deny all from 172.16.0.0:255.240.0.0 to any via ${oif}
ipfw add deny all from any to 172.16.0.0:255.240.0.0 via ${oif}
ipfw add deny all from 10.0.0.0:255.0.0.0 to any via ${oif}
ipfw add deny all from any to 10.0.0.0:255.0.0.0 via ${oif}

# --- Laisser passer les connexions TCP existantes
ipfw add pass tcp from any to any established

# --- Permettre l'arrivée du courrier SMTP
ipfw add pass tcp from any to 193.104.1.228 25 setup

# --- Permettre l'accès au serveur HTTP
ipfw add pass tcp from any to 193.104.1.228 80 setup

# --- Rejetter et faire des logs de toutes les autres demandes de connexion
ipfw add deny log tcp from any to any in via ${oif} setup

# --- Permettre l'établissement des autres connexions (via $iif).
ipfw add pass tcp from ${inet}:${imask} to any setup in via ${iif}

# --- Permettre le trafic UDP/DOMAIN vers/depuis les serveurs DNS externes
ipfw add pass udp from any 53 to any 53

# --- Permettre le trafic NTP vers/depuis les serveurs de dates
ipfw add pass udp from any 123 to any 123

# --- Permettre le passage de tous les paquets ICMP
ipfw allow icmp from any to any

# --- Tout ce qui n'est pas explicitement autorisé est
# implicitement interdit (cf comportement par défaut d'ipfw).
ipfw deny ip from any to any

Quelques considérations :

• les règles sont parcourues de la première à la dernière, si aucune ne 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érieur 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 :

 

Sélectionnez

telnet 193.104.1.228

Il va obtenir le message :

 

Sélectionnez

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 :

 

Sélectionnez

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.228(99).

Dans cette partie nous examinons le cas de la configuration de la figure VIII.16, synthèse des figures VIII.13, VIII.14 et VIII.15.

C'est une configuration très employée du fait de la distribution parcimonieuse d'adresses IP par les fournisseurs d'accès.

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 :

# --- Interface externe
oif="ed0"
onet="193.104.1.0"
omask="255.255.255.224"
oip="193.104.1.1"

# --- Interface interne
iif="ed1"
inet="193.104.1.224
imask="255.255.255.224"
iip="193.104.1.225"
#
# --- Usage de 'natd' pour transformer tout ce qui passe sur l'interface
# "ed0" donc le subnet public.
ipfw add divert 8668 all from any to any via ${oif}

# --- Ne pas laisser passer le ??spoofing''
ipfw add deny all from ${inet}:${imask} to any in via ${oif}
ipfw add deny all from ${onet}:${omask} to any in via ${iif}

# --- Ne pas router les adresses de la RFC1918
ipfw add deny all from 192.168.0.0:255.255.0.0 to any via ${oif}
ipfw add deny all from any to 192.168.0.0:255.255.0.0 via ${oif}
ipfw add deny all from 172.16.0.0:255.240.0.0 to any via ${oif}
ipfw add deny all from any to 172.16.0.0:255.240.0.0 via ${oif}
ipfw add deny all from 10.0.0.0:255.0.0.0 to any via ${oif}
ipfw add deny all from any to 10.0.0.0:255.0.0.0 via ${oif}

# --- Laisser passer les connexions TCP existantes
ipfw add pass tcp from any to any established

# --- Permettre l'arrivée du courrier SMTP
ipfw add pass tcp from any to 193.104.1.228 25 setup

# --- Permettre le trafic TCP/DOMAIN
ipfw add pass tcp from any to 193.104.1.228 53 setup

# --- Permettre l'accès au serveur HTTP
ipfw add pass tcp from any to 193.104.1.228 80 setup

# --- Rejetter et faire des logs de tout autre demande de connexion
ipfw add deny log tcp from any to any in via ${oif} setup

# --- Permettre l'établissement des autres connexions (via $iif).
ipfw add pass tcp from ${inet}:${imask} to any setup in via ${iif}

# --- Permettre le trafic UDP/DOMAIN vers/depuis les 'forwarders'
ipfw add pass udp from any 53 to 193.104.1.228 53
ipfw add pass udp from 193.104.1.228 53 to any 53

# --- Permettre le trafic DTP/NTP
ipfw add pass udp from any 123 to 193.104.1.228 123
ipfw add pass udp from 193.14.1.228 123 to any 123

# --- Permettre le passage des paquets ICMP (ping, traceroute...)
ipfw add pass icmp from any to any via ${oif} icmptype 0,3,8,11
ipfw add pass udp from any 32768-65535 to any 32768-65535 out xmit ${oif}
ipfw add log icmp from any to any in recv ${oif}
ipfw add pass icmp from any to any via ${iif}

# --- Tout ce qui n'est pas explicitement autorisé est
# implicitement interdit (cf comportement par défaut d'ipfw).
ipfw deny ip from any to any

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 rerouter 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'aperçoit que la configuration n'a pratiquement pas changé fondamentalement hormis 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à subi 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 !

• 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.