Modèle de routage interne fort ou faible ?

Date :11 Juillet 2005

Publication: Article

Une discussion a eu lieu dans BugTraq début Mars, au sujet d'un aspect de la pile TCP/IP pour lequel les spécifications restent floues et permettent plusieurs interprétations.

Le point de départ de cette discussion est la publication d'un article, annonçant une " vulnérabilité dans la pile TCP/IP ". Les auteurs de l'article ont mis en évidence deux comportements anormaux, observés sur des systèmes pour lesquels la fonctionnalité de routage a été désactivée :

1. Considérons un serveur qui a un service ouvert sur l'interface loopback (127.0.0.1), afin d'offrir ce service aux programmes tournant sur la machine seulement. Il est pourtant possible, depuis une autre machine située sur le réseau local, de se connecter à ce service, sur cette interface (127.0.0.1), via l'interface réseau connectée au réseau local. Cette dernière effectue en effet un routage interne vers l'interface loopback.

2. Considérons un serveur disposant de deux interfaces réseaux(If1 et If2), reliées à deux réseaux différents(Rx1 et Rx2). Un service est ouvert, et son accès est restreint au premier réseau (Rx1) seulement (accès sur l'interface If1). Il est pourtant possible, depuis une machine située sur le second réseau (Rx2), de se connecter à ce service, sur l'interface If1, via l'interface If2. Cette dernière effectue en effet un routage interne vers l'interface If1.

Le premier comportement est effectivement non souhaitable et anormal.

La seconde " fonctionnalité " de routage interne implicite n'est pas à proprement parler une découverte, ni une vulnérabilité, de nombreux administrateurs l'utilisant pour mettre en oeuvre leur architecture réseau.

Ce comportement est appelé " routage interne faible ", par opposition au " routage interne fort " qui interdit le routage interne si les fonctionnalités de routage et de forwarding ont été désactivées sur le système.

Notons que cette faiblesse peut seulement être exploitée par un individu mal intentionné situé sur le réseau local de la machine cible, ce qui limite la criticité du problème (des serveurs en DMZ, ne comportant pas de machines non sûres, ne sont donc pas vulnérables).

Il n'est pas souhaitable de décréter que le routage interne faible soit supprimé des piles TCP/IP. Par contre, il est bel et bien intéressant de soulever ce problème, afin d'en tenir compte, en connaissance de cause, d'un point de vue sécurité.

Le danger sur les systèmes implémentant le modèle " faible " est de croire que chaque interface réseau se situe dans un domaine de sécurité différent, et donc de ne pas mettre en place des règles de filtrage.

La mise en place d'un filtrage adéquat (antispoofing sur la machine) est la meilleure solution à court terme pour les systèmes avec un modèle " faible " qui sont concernés par ce problème.

Suite à ces discussions dans BugTraq, des solutions sont à l'étude pour la plupart des systèmes. Mais cela ne passe pas forcément par un correctif qui rend le modèle plus "fort ", car une modification du modèle de routage peut entraîner des dysfonctionnements dans certains environnements, qui reposent sur le modèle " faible ". Idéalement, l'administrateur devrait pouvoir paramétrer son système et choisir le modèle à utiliser.

Ci-dessous, la liste des systèmes d'exploitation pour lesquels le modèle de routage interne a été discuté :

  • Systèmes avec routage interne faible :

    • NetBSD
    • OpenBSD
    • FreeBSD
    • Windows NT (probablement)
    • Linux 2.0, 2.2
    • Linux 2.4 (probablement)  

  • Systèmes avec routage interne fort :

    • non mentionné lors de la discussion 

  • Systèmes avec routage interne configurable :

    • Sun Solaris (un paramètre du kernel permet de choisir entre routage interne fort ou faible; le routage est faible par défaut).

Pour plus d'information :