simplifier la sécurité interne avec les VRF

L'idée de cet article est d'aller un peu plus loin au niveau de l'isolation des flux des différentes zones sur un réseau en ajoutant une isolation de niveau 3 avec des VRFs.

Cette fonctionnalité est bien connue de certains architectes réseau/sécurité, mais trop peu souvent mise en place. L'idée est principalement d'apporter des cas d'usages, et un peu plus de précision sur l'utilité de cette isolation, qui permet également de simplifier la sécurité sur son réseau.

besoin initial

Nous utilisons régulièrement les VLAN (et plus particulièrement le private VLAN dans certains cas) pour faire de la sécurité de niveau 2, mais très souvent nous arrivons sur un routeur où la sécurité n'existe pas, ou est mal gérée (difficile d'avoir une sécurité adaptée, précise et évolutive avec des ACLs...). 

objectif

il faut donc isoler les flux de nos différentes zones afin d'aboutir sur un équipement de niveau 3 qui gère correctement la sécurité : un pare-feu.

Bien que le pare-feu soit très souvent utilisé pour les zones avec un périmètre d'accès différents (réseau publique, DMZs et réseaux internes), il est encore trop rarement utilisé pour séparer les différents zones du réseau interne. Nous pouvons rapidement identifier plusieurs catégories de zones :

• les serveurs
• les utilisateurs "bureautique"
• les invités
• les DMZ
• ...

Le principal problème est que nous avons de nombreux VLAN sur nos réseaux internes, et cela imposerai d'avoir une multitude d'interfaces (physiques ou logiques), ce qui amène une complexité importante dans la matrice des flux.

Pour cela, nous allons utiliser des VRF, qui sont des instances virtuelles de routage, qui permettent d'avoir une table de routage dédiée par instance, et par conséquent, une isolation de niveau 3. Dans leurs tables de routages distincts, chaque instance aura donc pour route par défaut le pare-feu. Nous pouvnos également imaginer d'avoir quelques ACLs dans ces VRFs de type "deny all" par exemple pour des réseaux invités (attention cependant à autoriser les flux de base, type DHCP, broadcast...)

voici un schéma explicatif

Nous pouvons voir ici qu'au sein d'une même VRF (les routeurs violets) toutes les communications sont possibles (si nous n'avons pas d'ACLs bien entendu), cependant nous avons un contrôle entre les différentes zones via le pare-feu. 

Nous préfererons bien sûr un pare-feu dédié pour le contrôle des flux internes et garder le pare-feu internet dédié aux zones exposés. Cependant l'exemple ci-dessus est plus simple à comprendre, et ajoute malgré tout un contrôle supplémentaire par rapport à un routage sans contrôle coté réseau interne.

intérêts

Nous aurons donc une isolation de niveau 3 de chaque "zone de sécurité" qui pourra contenir un grand nombre de VLAN si besoin (pour les clients notamment), avec un nombre limité d'interface connectée sur le pare-feu.

Le principal intérêt est d'isoler correctement ces différentes catégories de sous-réseaux, avec une politique différente par type de zone (invités, clients, serveurs...), et d'assurer un filtrage entre ces différentes catégories sans pour autant avoir un pare-feu avec tous les VLAN connectés.

Nous pouvons également envisager de créer une VRF invitée avec une sortie sur un portail captif (gestion des tickets, des flux autorisés, bande passante, contrôle antivirus...). Cela permet d'avoir une entrée unique quelque soit le média d'accès (réseau filaire ou wifi) pour contenir tous les invités et n'avoir qu'un seul point d'entrée sur son réseau (notamment avec l'arrivé de tous ces BYOD sauvages...).

inconvénients

Le principal inconvénient de cette architecture est que nous remontons tous nos flux vers le pare-feu, et cela nécessite d'avoir une capacité de traitement des flux important, et une interconnexion entre les routeurs et le pare-feu avec des débits importants.

Si vous avez une charge vraiment importante entre les différentes zones, il existe des pare-feu de type data-center, ou intégré en mode blade dans les routeurs qui sauront prendre en compte un gros volume de données.

En espérant vous avoir donné envie d'aller un peu plus loin sur la sécurité de votre LAN ;-)

Guillaume.

crédit photo : © alphaspirit - Fotolia.com