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..
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 ![[*]](crossref.png)
,
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 
uvre 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.
Conceptuellement, il serait parfaitement possible d'utiliser,
par exemple, des adresses dans le
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. Un de ses interfaces réseaux peut être
surchargé avec une adresse dans cette classe C.
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.
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.
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
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.1Dst
IPB
192.168.2.200Code
ipencap(4)
icmp
Sur l'interface gif0
En-tête
Src
192.168.249.1Dst
192.168.2.200Code
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 !
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.
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 :
Ipsec (RFC 2401) est un assemblage de quatre protocoles :
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
(`` 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
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
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
figure IX.08 -- Association 4
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.
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.
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 :
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...
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.
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.
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
{tcp, IP Hôte A, port A, IP Hôte B, port B}
Pour la machine B
{tcp, IP Hôte B, port B, IP Hôte NAT, port A'}
Pour la machine NAPT
.
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é.
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.
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
figure 14 -- Configuration multiservices
4.3 NAPT sur un routeur CISCO
Voir en travaux pratiques...
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 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 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...
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 :
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.
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} }
}](img94.png)
Quelques considérations :
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
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.
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} }
}](img96.png)
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 !
Sans oublier :
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