Les 3 modes d'utilisation génériques décrits ci-avant illustrent les évolutions consécutives au développement tous azimuts de l'Internet. Comme les applications «natives» des services Internet (noms de domaines, courrier, forums, Web, etc.) sont intégrées dans le système libre GNU/Linux il est naturel qu'il occupe une place de choix sur les serveurs. Qu'en est-il de l'autre partie importante de ce système : le noyau ?
Les premières verions de la série 2.6 des noyaux stables sont sorties au début de l'année 2004. Une fois de plus, cette série marque une étape importante dans l'intégration des fonctions réseau [Kernel Traffic]. On y retrouve toutes les évolutions techniques majeures de l'Internet :
Les fonctions liées aux accès distants via le protocole PPP (Point to Point Protocol) ont été complétées pour offrir davantage de possibilités en matière de filtrage et d'aggrégation de canaux.
Les protocoles IPSEC, IPv6 et IPVS sont complètement intégrés aux noyaux de la série 2.6.xx.
Le contrôle du trafic, les priorités et les qualités de services sont documentées dans le guide Linux Advanced Traffic Control HOWTO. Toutes ces fonctions sont modulaires ; elles sont associées suivant les besoins exprimés par les politiques de routage.
Les réseaux virtuels (VLANs) et les fonctions des ponts réseau sont de plus en plus utilisés en haute disponibilité, redondance et sécurité.
Le contrôle d'accès par filtrage permet d'appliquer des règles sur les champs des couches liaison, réseau, transport et application. Les travaux les plus récents portent sur le filtrage de trames et sur le marquage des flux d'applications. La traduction des adresses source (SNAT) et destination (DNAT) fait partie intégrante des fonctions de filtrages de netfilter/iptables.
Les tunnels sur IP et notamment GRE, font aussi partie des fonctions du noyau Linux. Des exemples de configurations sont disponibles au chapitre 5 du Linux Advanced Traffic Control HOWTO. Ce type de fonction a évolué vers les réseaux privés virtuels (VPN) que l'on retrouve sous forme d'application, et non dans les fonctions du noyau.
Il est souvent difficile d'appréhender l'association des différentes fonctions réseau dans un noyau tel que Linux. Dans quelles conditions utilise-t-on le contrôle de trafic ou d'accès ?. La réponse est donnée avec le diagramme de transit d'un packet dans le noyau.
Jusqu'à présent, les systèmes Unix et les différentes distributions Linux ont conservé les «vénérables» commandes arp, ifconfig et route comme outils de configuration des interfaces réseau.
Compte tenu des évolutions listées ci-dessus, il est devenu très difficile de compléter ou d'adapter cet héritage. C'est pourquoi l'architecture réseau des noyaux de la série 2.4.xx a été complètement revue pour rendre les différents niveaux de configuration des interfaces plus accessibles. Cette nouvelle architecture implique la mise en place d'un nouvel outil de configuration : iproute2.
La commande ip sert à configurer les interfaces. La syntaxe de cette commande est fournie dans la documentation du paquet iproute ainsi que dans le guide Linux Advanced & Traffic Control HOWTO. Les options de cette commande comprennent les paramètrages :
des interfaces aux niveaux liaison et réseau,
des adresses en fonction des protocoles,
des entrées de table de routage,
des entrées de la base de données des politiques de routage,
des adresses et des tables de diffusion (multicast),
des tunnels.
La commande tc : (Traffic Control) sert à paramétrer le contrôle du trafic d'une interconnexion. Elle utilise les éléments suivants :
un choix de gestionnaires de mise en file d'attente par flux réseau,
un choix de règles de classification des paquets avant leur mise en file d'attente,
un choix d'ordonnanceurs pour la mise en forme du trafic sortie d'une interface.
L'ensemble des traitements réalisés avec l'association des commandes ip et tc est appelé politique de routage ou routing policy. Le noyau Linux possède un système de gestion de base de données de routage : RPDB ou Routing Policy DataBase management. Cette base de données travaille sur les champs suivants :
les adresses MAC source et destination,
les adresses IP source et destination,
le type de Service : TOS,
l'interface d'arrivée du paquet.
De plus, le traitement des protocoles du niveau transport peut être associé au système de filtrage des services. En fonction de tous ces paramètres, il existe quatre traitements ou policing possibles pour un paquet arrivant sur une interface :
prise de décision par filtre,
refus de mise en file d'attente,
abandon d'un paquet en file d'attente,
abandon d'un paquet en file d'attente lors de l'arrivée d'un nouveau paquet.
Tous ces mécanismes permettent d'affiner les traitements des flux réseau. Une fois la première étape de différenciation entre les flux passée, on peut individualiser les traitements : priorités, etc. C'est ainsi que l'on pourra garantir les services multimédias (données, son, vidéo) sur les réseaux hétérogènes.
Les services différenciés ou Differentiated Services ou encore Diffserv correspondent à une classification simple du trafic entrant dans un réseau ou à un conditionnement à la frontière de l'interconnexion réseau visée.
Le trafic conditionné est identifié par un champ DS ou un marquage du champ Type of Service (ToS) de l'en-tête de paquet IP. L'un des principes de base de la technique Diffserv veut que le marquage du trafic ait lieu sur les équipements d'extrémités du réseau. Sachant que ce travail de marquage est assez complexe et coûteux en temps de calcul, il vaut mieux limiter au maximum les répétitions. C'est donc sur les routeurs d'extrémités que ce marquage doit être effectué pour que les dispositifs à l'intérieur du réseau n'aient plus qu'à appliquer les classes de services CoS sur les flux identifiés.
L'application des services différenciés sur les composants existants de contrôle de trafic du noyau Linux n'a entraîné que des ajouts mineurs sur ces composants. Comme les mécanismes de classification des flux réseau sont complets, il ne manquait pratiquement que le support et les éléments nécessaires à la manipulation du champ DS. Le site Differentiated Services on Linux rassemble toutes les informations nécessaires à la mise en oeuvre de Diffserv sur les systèmes GNU/Linux.
L'article Linux and the Next Generation Internet décrit un exemple de configuration de ce type.
Une bonne qualité de service sur les réseaux actuels suppose une implantation correcte de deux fonctions : performance garantie et politiques de routage. Les politiques de routage sont utilisées pour affecter des ressources en priorité aux applications, aux groupes de travail ou aux serveurs. Avec l'augmentation constante du volume de trafic sur les réseaux, les garanties de performances sont obtenues en contrôlant la bande passante en fonction des politiques de routages. Le noyau du système GNU/Linux possède tous les éléments pour adapter les politiques (ou l'organisation) des groupes de travail aux politiques de routage de façon souple et dynamique.
Les options de contrôle du trafic ont pour but la mise en forme des flux réseau. Il existe plusieurs techniques pour contrôler l'accès à ces flux.
Il existe 2 modes opératoires pour la traduction d'adresses avec GNU/Linux :
La traduction d'adresses a d'abord été implantée de façon statique dans le paquet iproute2; à l'époque de la série 2.2.xx des noyaux Linux. La syntaxe est du type :
# iproute add nat 192.200.1.0/24 via 193.233.7.64
La page Linux IP NETWORK ADDRESS TRANSLATION rassemble toutes les références historiques sur ce mode de traduction statique.
La traduction d'adresses dynamique a connu un énorme succès grâce au MASQUERADING. C'est cette fonction qui permet de partager un accès réseau privé entre plusieurs hôtes à partir d'une seule adresse publique Internet. La syntaxe est du type :
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Cette fonction fait partie du système de filtrage réseau Linux qui comprend une partie noyau (kernelspace) appelée netfilter et une partie outil utilisateur (userspace) appelée iptables.
Avec l'arrivée des noyaux de la série 2.4.xx, la traduction d'adresses Linux a bénéficié d'un mécanisme de décision qui contrôle exactement les changements d'adresses avant ou après la décision de routage.
_____ _____
/ \ / \
PREROUTING -->[Routing ]----------------->POSTROUTING----->
\D-NAT/ [Decision] \S-NAT/
| ^
| |
| |
| |
| |
| |
--------> Local Process ------
Le diagramme ci-dessus est extrait du Linux 2.4 NAT HOWTO.
La traduction d'adresses sources (S-NAT) utilise
la chaîne POSTROUTING. Cette traduction correspond à une
utilisation du type routeur d'agence.
La traduction d'adresses destination (D-NAT)
utilise la chaîne PREROUTING. Associée aux règles de
filtrage présentées ci-après, elle permet une réécriture des adresses
suivant les services Internet (numéros de ports TCP/UDP source ou
destination) à traiter.
Avec le schéma ci-dessus, la syntaxe à appliquer sur le pare-feu avec traduction d'adresses destination pour le service Web est du type :
# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 \
-j DNAT --to 192.168.0.3:8080
L'ensemble du logiciel noyau et utilisateur du projet netfilter/iptables désigne le mécanisme de contrôle d'accès du noyau Linux. Il fixe les règles de transmission ou de séparation entre les connexions réseau.
Comparativement à IPChains, le système de filtrage de la génération précédente, netfilter/iptables est beaucoup plus complet et plus rigoureux (respect des RFCs) dans le codage des règles.
L'amélioration majeure est le suivi de connexion ou filtrage à l'aide de tables d'états (StateFul inspection). En conservant l'état d'une connexion, le mécanisme de filtrage est à même d'associer un serveur (adresse IP + numéro de port) à un client (adresse IP + numéro de port). Ainsi, on peut contrôler que les fenêtres, les numéros d'acquittement et de séquences correspondent bien à une transaction unique.
Une fois l'état d'une connexion TCP connu, on dispose de 3 politiques (ou choix) pour chaque règle de filtrage :
ACCEPT : accepter les paquets.
DROP : refuser les paquets sans en avertir l'émetteur.
REJECT : refuser les paquets en le signalant à l'émetteur en activant le bit RST dans le cas d'une connexion de transport TCP ou en émettant un paquet ICMP dans le cas d'une transaction UDP.
Une règle avec sa politique s'applique à une interface. Chaque interface dispose de 3 « chaînes » :
INPUT : les paquets sont filtrés à leur arrivée sur l'interface.
FORWARD : les paquets sont filtrés lors de la traversée de la machine. La règle est alors appliquée en entrée et en sortie.
OUTPUT : les paquets sont filtrés en sortant de l'interface.
_____
Entrée / \ Sortie
-->[Décision]--->|FORWARD|------->
[de routage] \_____/ ^
| |
v ____
___ / \
/ \ |OUTPUT|
|INPUT| \____/
\___/ ^
| |
---->Processus local ----
Le diagramme ci-dessus est extrait du Linux 2.4 Packet Filtering HOWTO.
Sans outils d'analyse, la définition des stratégies de contrôle et de filtrage serait « délicate » et toutes les fonctions présentées ci-dessus seraient difficiles à mettre en oeuvre. Il existe plusieurs projets complémentaires concernant les moyens d'analyse et de caractérisation des trafics réseau. Voici 2 exemples représentatifs :
Wireshark est un analyseur de réseau orienté transmission très complet qui permet de visualiser en détail l'ensemble de l'activité aux niveaux liaison, réseau, transport et application. Contrairement à ce que son nom semble indiquer, il ne se limite pas aux réseaux locaux Ethernet. On peut facilement isoler les connexions TCP au sein d'une capture.
ntop est un analyseur orienté services. Il collecte des statistiques sur l'utilisation des protocoles et des services Internet. C'est un outil unique pour la caractérisation des trafics.
Tous les outils et mécanismes présentés auparavant concourent au même résultat : la sécurisation des échanges. La confidentialité est un aspect particulier de la sécurisation. Il existe deux méthodes de chiffrage des transactions réseau.
Stunnel -- Universal SSL Wrapper est un outil de chiffrage SSL par service. Sa mise en oeuvre est redoutablement simple et efficace. L'utilisation de cet outil sur des liaisons bas débit est totalement transparente. Stunnel est parfait pour débuter dans la sécurisation des infrastructures réseau à moindre coût d'administration.
OpenSSH est un outil de chiffrage limité à certains flux/services : console, transfert de fichiers et tunnels dédiés. Cet outil assure la confidentialité des transactions de bout en bout, ce qui est très pratique tant que l'on n'a pas besoin de caractériser le trafic. En effet, comment distinguer un flux chiffré d'un autre ? ssh offre de nombreuses options de configuration dont le choix de l'algorithme de chiffrement qui permet d'optimiser le rapport débit de transmission/niveau de sécurité.
Le protocole IPSec sert à chiffrer la totalité du trafic au niveau réseau. Il est utilisable de bout en bout en mode transport ou entre routeurs en mode tunnel. C'est ce dernier mode de fonctionnement qui est, de loin, le plus intéressant. En mode tunnel, on conserve la visibilité sur ses réseaux locaux (caractérisation du trafic) et on assure la confidentialité en chiffrant tout le trafic à l'extérieur de son périmètre d'intervention (l'Internet).
Relativement aux systèmes *BSD, Linux a longtemps été considéré comme moins performant et/ou en retard. Les noyaux de la série 2.6.xx intègrent directement IPSec et les algorithmes de chiffrement associés. Cette intégration dans le noyau Linux est liée au protocole IPv6. C'est le résultat du travail effectué par l'équipe USAGI Project - Linux IPv6 Development Project.
Sous cette dénomination barbare se cache la solution de mise en oeuvre de réseaux privés virtuels la plus simple et certainement la plus efficace en termes de coûts d'installation et d'exploitation.
OpenVPN est un logiciel de réseau privé virtuel SSL complet fonctionnant aussi bien en mode transport qu'en mode tunnel. Il peut fonctionner en chiffrement symétrique en déposant la clé secrète manuellement à chaque extrémité. On obtient ainsi un excellent niveau de sécurité en un tournemain.
Virtual Tunnels over TCP/IP networks propose un autre système de tunnels entre routeurs.
![[Linux France logo]](./../../images/lf-petit.png)
Vous êtes ici :