Cette catégorie d'interconnexion est apparue consécutivement au développement de l'Internet. L'Internet a d'abord été perçu comme un fantastique moyen de travail coopératif entre équipes de recherche universitaires et ensuite entre sociétés commerciales. Relativement aux lignes spécialisées, le coût d'interconnexion du réseau des réseaux est toujours très attractif. L'enthousiasme des premiers temps s'est très vite estompé face à la multiplication des comportements malveillants. Les modes d'interconnexion évoluent donc vers des fonctions de contrôle d'accès et de confidentialité dans les échanges.
On reprend ici les éléments définis dans la définition du Périmètre de contrôle d'accès.
La notion de contrôle d'accès regroupe plusieurs traitements :
Le filtrage
La qualité de service
La traduction d'adresses
Ces traitements utilisent les mêmes composants du système.
|
Le document Kernel Packet Traveling Diagram aide à distinguer les fonctions de contrôle de trafic des fonctions de filtrage.
![[Note]](images/note.png)
|
Utilisation avec GNU/Linux |
|---|---|
|
Le vocabulaire GNU/Linux parle de contrôle de trafic (traffic control) plutôt que de qualité de service. Le noyau Linux intègre un jeu de fonctions génériques utilisables pour tous les traitements. Voir la version française du LARTC : HOWTO du routage avancé et du contrôle de trafic sous Linux |
Pour une introduction complète sur le fonctionnement du contrôle de trafic, consulter le document Linux Traffic Control - Next Generation.
Voici une présentation des composants systèmes extraite des documents de référence sur le contrôle de trafic.
Les paquets entrants sont examinés pour être :
directement transmis au réseau ; sur une autre interface si la machine est un routeur ou un pont,
transférés vers les couches supérieures de la pile de protocole ; vers les protocoles UDP ou TCP de la couche transport.
Les couches hautes peuvent aussi générer leurs propres données et les passer aux couches basses pour des traitements tels que l'encapsulation, le routage et éventuellement la transmission.
Ce composant comprend la sélection de l'interface de sortie, la sélection du prochain saut (pont, routeur ou commutateur), l'encapsulation, etc.
Une fois tous les traitements précédents effectués, c'est à ce niveau que le contrôle de trafic intervient.
Parmi les fonctions du contrôle de trafic, on trouve plusieurs types de décisions :
Décision de mise en file d'attente (queueing) ou d'abandon d'un paquet si une limite de taille ou de débit a été atteinte.
Décision sur l'ordre d'émission des paquets en fonction des priorités sur les types de flux.
Décision sur le délai d'attente avant émission dans le cas où le débit de sortie a été limité.
Une fois que le contrôle de trafic a libéré un paquet pour qu'il soit émis, le pilote d'interface réseau le prend et l'envoie sur le réseau.
L'échange d'information sur le contrôle de trafic se fait par l'intermédiaire du marquage des paquets. Dans le cas des Services Différenciés (Differentiated Services [ Differentiated Services on Linux]) on utilise le champ TOS de l'en-tête de paquet IP ou un champ spécifique appelé DS Field spéficié par le document RFC2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.
|
|
Utilisation avec GNU/Linux |
|---|---|
|
Les options de sélection des composants du contrôle de trafic implantés dans le noyau Linux sont accessibles à partir des options réseau. Le paquet iproute contient les outils utilisateurs de configuration. |
Le filtrage reprend l'utilisation des composants présentés ci-avant. Le rôle du filtrage n'est pas de mettre en forme le trafic réseau entre deux points mais de décider si un paquet doit être transmis ou non. Dans le cas du système GNU/Linux, le filtrage sert aussi à la traduction d'adresses. Il s'agit alors de décider vers quel hôte ou quel réseau un paquet doit être transmis.
Depuis l'origine, le filtrage sur les noyaux Linux est basé sur la notion de chaîne. Avant d'aborder les chaînes créées par l'utilisateur, un paquet doit toujours passer par au moins une des trois chaînes qui correspondent aux composants présentés ci-avant.
INPUT pour les paquets entrant dans le système,
FORWARD pour les paquets entrant et sortant du système,
OUTPUT pour les paquets sortant du système.
Voici le synoptique fourni par Rusty Russel dans la section Comment les paquets traversent les filtres du Linux 2.4 Packet Filtering HOWTO.
_____
Incoming / \ Outgoing
-->[Routing ]--->|FORWARD|------->
[Decision] \_____/ ^
| |
v ____
___ / \
/ \ |OUTPUT|
|INPUT| \____/
\___/ ^
| |
----> Local Process ----
(c)2000 Rusty Russell
Les traitements effectués sur les paquets à partir des trois chaînes de base sont eux-mêmes implantés sous forme de chaînes :
Le paquet est accepté et continue sa traversée du système.
Le paquet est abandonné sans aucune notification.
La traversée de la chaîne est enregistrée par le système.
Le paquet est rejeté avec notification.
Retour au traitement de la chaîne précédente.
Le paquet est redirigé vers un traitement défini par l'utilisateur. Il s'agit avant tout de pouvoir ajouter de nouveaux traitements spécifiques.
Le filtrage s'applique en spécifiant les éléments suivants :
Adresses IP source et/ou destination (ex. 192.168.100.2/24).
Protocoles (ex. TCP, UDP, ICMP).
Interface (ex. eth0).
Fragments acceptés ou non.
Extensions TCP sur les champs de l'en-tête (SYN, ACK, FIN, RST,URG, PSH) ainsi que sur les ports source et destination.
Extensions UDP sur les ports source et destination.
Extension ICMP sur le type.
Adresses MAC source et/ou destination (ex. 00:60:08:91:CC:B7).
Limite du nombre des demandes enregistrées par seconde (détection des attaques DoS et SYNflood).
Propriétaire du paquet généré sur le système.
Cette fonction est essentielle pour tracer les échanges de de paquets pour chaque «communication» TCP, UDP et ICMP entre 2 hôtes. L'analyse est réalisée à l'aide d'indicateurs d'état (State Match).
Le paquet crée une nouvelle connexion.
Le paquet appartient à une connexion existante.
Le paquet est associé à une connexion sans appartenance (ex. Erreur ICMP ou Donnée FTP).
Le paquet ne peut pas être identifié.
Déterminer une politique de sécurité nécessite une réflexion approfondie. Il n'existe pas de solution «clé en main» en matière de sécurité réseau. Autre difficulté, il est extrêmement difficile de mesurer l'efficacité réelle d'une politique de sécurité (système de filtrage). On peut cependant dégager deux principes d'application du filtrage.
Cette approche est la plus rigoureuse. Seul le trafic réseau explicitement autorisé peut traverser l'équipement d'extrémité filtrant. De cette façon, on limite le trafic à surveiller (celui que l'on a autorisé) et on se protège contre les défauts de sécurité même inconnus.
Cette approche interdit le trafic potentiellement dangereux. De cette façon, on ne limite que le trafic identifié comme générateur de problèmes de sécurité.
De façon pragmatique, on utilise les deux principes de filtrage en fonction de son niveau de «maîtrise» de l'interconnexion réseau. Suivant la distribution des périmètres on peut appliquer une hiérarchie dans la politique sécurité.
Plus le périmètre est petit, plus l'identification du trafic réseau est facile. Il est donc possible d'appliquer le premier principe, le plus rigoureux, sur les réseaux d'agence ou les périmètres départementaux. Ceci revient à dire qu'il faut appliquer le niveau de sécurité le plus élevé au plus près du réseau à protéger
A l'inverse, identifier la totalité des trafics possibles à l'échelle d'un périmètre d'interconnexion de campus est souvent une gageure. Le responsable de la sécurité réseau s'attirera les foudres de la quasi-totalité des utilisateurs s'il cherche à exercer un contrôle trop strict sur un trafic qu'il ne peut pas identifier complètement. En effet, trop de sécurité peut entraver le bon fonctionnement des applications dont les utilisateurs ont légitimement besoin. C'est donc le second principe qui convient le mieux aux réseaux d'interconnexion.
![[Linux France logo]](./../../images/lf-petit.png)
Vous êtes ici :