Home › Cisco › Access-list « réflexive »

Access-list « réflexive »

Posted on Publié dans Cisco, La pratique, Routing Étiquetté avec , , , , , , , ,

Lorsque l’on veut protéger un réseau du trafic venant de l’extérieur, on est souvent confronté  au problème suivant : « Comment prévoir ce qui peut/devrait pouvoir passer ? ». D’un point de vue général, la politique la plus sécuritaire consiste à bloquer tout trafic par défaut et n’autoriser que le strict nécessaire, mais cela devient vite difficile à gérer si on ne veut pas trop brider les communication provenant de l’intérieur du réseau.

Il existe plusieurs méthodes pour gérer au mieux cette situation:

  • Le filtrage sur base des flags TCP (un segment tcp entrant n’ayant pas le flag ACK activé ne peut pas être originaire de l’intérieur, …), l’inconvénient majeur, c’est qu’il n’est pas possible d’en faire de même pour le protocole UDP.
  • Le filtrage par Access-list réflexive, ce que nous allons voir ici, qui consiste à générer une ACL dynamiquement en fonction du trafic sortant afin d’autoriser temporairement le retour.
  • Les « Zone-Based Firewall » qui se basent sur le principe de définition de zones et de création de règles d’une zone à une autre (la méthode la plus moderne).
Voyons ce qu’il en est pour les ACL réflexives …

La topologie

Un LAN internet (192.168.0.0/24) est connecté à Internet par l’intermédiaire de R2 qui est configuré pour faire du NAT overload.
R1 a une route par défaut qui pointe vers R2, R2 une route par défaut vers R3. R3 ne connait que 80.0.0.0/30.

Objectif

Configurer R2 de sorte qu’il n’autorise les paquets provenant d’Internet à l’unique condition qu’ils correspondent à une « conversation » initiée depuis le LAN interne.

Méthode générale

  1. Configurer une ACL définissant le trafic autorisé à sortir (LAN vers Internet) en spécifiant l’ACL dynamique à peupler.
  2. Appliquer cette ACL sur une interface.
  3. Créer un ACL correspondant au trafic autoriser à entrer où l’on fait évaluer l’ACL dynamique.
  4. Appliquer cette ACL en sens inverse de l’ACL pour le trafic sortant.

Considération dans le cas présent

Le NAT ne nous facilite pas la vie. Il faut garder en mémoire que l’opération du NAT (modification de l’adresse source du paquet) est effectuée avant le filtrage. Dés lors si on n’y prête pas attention on risque fort de ne pas arriver à identifier correctement le trafic.
Dés lors il faut commencer par se fixer une base de travail, à savoir, à quel moment le filtrage aura lieu. Si on le fait sur l’interface de R2 côté LAN, on devra tenir compte des adresses locales, si on filtre à la sortie de l’interface côté publique, il faudra traiter les données en fonction de l’adresse utilisée par le NAT.
Pour la configuration, on filtrera la trafic côté LAN de R2. L’avantage majeur est que l’on peut distinguer les adresses privées, l’inconvénient c’est que le routeur effectuera l’opération de routage même si les paquets termineront à la poubelle juste après.

Configuration

Commençons par créer l’ACL autorisant le trafic sortant:
R2(config)#ip access-list extended ACL-L2W
R2(config-ext-nacl)#permit ip 192.168.0.0 0.0.0.255 any reflect ACL-REFLECTED
R2(config-ext-nacl)#exit
ACL-L2W (Lan to Wan) sera l’ACL que l’on appliquera sur l’interface côté LAN de R2 en « input ». On y autorise le traffic ip (n’importe quel protocole) provenant de 192.168.0.0/24 vers n’importe quelle direction.
L’instruction reflect indique au routeur qu’il devra créer une règle réflexive (correspondant au trajet inverse) dans l’access-list dynamique ACL-REFLECTED.
Créons maintenant l’ACL qui filtrera le trafic entrant et que l’on appliquera de nouveau sur l’interface LAN de R2 mais cette fois en « output ».
R2(config)#ip access-list extended ACL-W2L
R2(config-ext-nacl)#evaluate ACL-REFLECTED
R2(config-ext-nacl)#exit
ACL-W2L (Wan to Lan) ne contient ici qu’une seule instruction, evaluate ACL-REFLECTED, qui indique au routeur qu’il doit utiliser les règles cntenues dans l’ACL ACL-REFLECTED. Pour ceux qui ont des notions de programation, cela reviendrait à faire un « include » en PHP par exemple.
Il reste maintenant à appliquer ces deux ACL sur l’interface LAN (Fa0/0 dans le cas présent) de R2.
R2(config)#int fa0/0
R2(config-if)#ip access-group ACL-L2W in
R2(config-if)#ip access-group ACL-W2L out

Vérification

Commençons par vérifier si R1 arrive bien à communiquer avec R3, cela devrait fonctionner puisqu’il génèrerait des paquets provenant de 192.168.0.10 à destination de 80.0.0.1, ce qui correspond à la clause « permit » de ACL-L2W.
R1#ping 80.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 80.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/38/52 ms
R1#
A priori tout va bien … vérifions le fonctionnement des ACLs…
R2#sh access-lists
Standard IP access list 1
    10 permit 192.168.0.0, wildcard bits 0.0.0.255 (5 matches)
Extended IP access list ACL-L2W
    10 permit ip 192.168.0.0 0.0.0.255 any reflect ACL-REFLECTED (5 matches)
Reflexive IP access list ACL-REFLECTED
 permit icmp host 80.0.0.1 host 192.168.0.10 (5 matches) (time left 286)
Extended IP access list ACL-W2L
    10 evaluate ACL-REFLECTED
R2#
L’access-list 1 est utilisée ici pour le NAT, elle n’est utile pour la vérification. Ce qui nous intéresse ici, c’est l’ACL-L2W … « 5 matches » … les 5 paquets icmp générés par le ping sont bien passés et ont été traités correctement par l’ACL. Mieux encore … l’ACL-REFLECTED contient une règle qui correspond au traffic correspondant à la réponse de R3 au ping de R1: des paquets ICMP en provenance de 80.0.0.1 à destination de 192.168.0.10.

Quelques remarques

  • Comme je l’ai dit un peu plus haut, le NAT est assez gênant dans le sens où il nous impose de travailler en in et out du même côté de R2. Si les ACLs étaient appliquées du côté WAN de R2, il aurait fallu remplacer la règle « permit ip 192.168.0.0 0.0.0.255 ….  » par « permit ip host 80.0.0.2 any … « , puisqu’à la sortie de l’interface WAN de R2, l’adresse source des paquets est remplacée par l’adresse configurée sur son interface WAN.
  • Point important … l’utilisation d’access-list réflexive ne peut se faire que dans des access-list étendues.
  • Il est tout à fait possible de mélanger des règles statiques avec une ou plusieurs instructions « evaluate », il faut juste garder en tête qu’une ACL s’exécute séquentiellement, règle après règle, par ordre de séquence. Les règles contenues dans l’ACL évaluées seront donc exécutées comme si elles étaient définies à cet endroit dans l’ACL.
  • En l’absence de NAT, il vaut clairement mieux appliquer l’ACL autorisant le trafic sortant côté interne en input, et l’ACL filtrant le trafic entrant côté extérieur en « input » également. Cela évite au routeur de traiter des paquets qui ne sont pas autorisés.

6 Comments on “Access-list « réflexive »”

  6. quelques petites fautes de frappe § « Considération dans le cas présent »
    dans les dernières lignes ^^