ACL Cisco : contrôle du trafic réseau

Une ACL (Access Control List) est une liste ordonnée de règles qui autorisent ou refusent des paquets selon leurs caractéristiques : adresses, protocole, ports. Sur un routeur ou un commutateur de niveau 3, les ACL servent à filtrer le trafic entre réseaux, mais aussi à sélectionner du trafic pour d'autres fonctions : NAT, QoS, restriction des accès d'administration, filtrage de routes.

Objectif : écrire, placer et vérifier des ACL Cisco correctes, en évitant les pièges classiques (ordre des règles, refus implicite, masques génériques).

Fonctionnement général

• Les règles (ACE, Access Control Entries) sont évaluées de haut en bas.
• La première règle qui correspond s'applique ; les suivantes sont ignorées.
• Toute ACL se termine par un refus implicite (deny any), invisible dans la configuration : un paquet qui ne correspond à aucune règle est rejeté.
• Une ACL s'applique à une interface, dans un sens (in ou out), et une seule ACL par interface, par sens et par protocole (IPv4, IPv6).

Conséquence du refus implicite : une ACL qui ne contient que des règles deny bloque tout le trafic. Il faut au moins une règle permit.

Le masque générique (wildcard)

Les ACL utilisent un masque générique plutôt qu'un masque de sous-réseau :

• un bit à 0 signifie « ce bit doit correspondre » ;
• un bit à 1 signifie « ce bit est indifférent ».

Pour un réseau, le masque générique est l'inverse du masque de sous-réseau : on le calcule par 255.255.255.255 − masque.

Le calculateur de sous-réseau IPv4 affiche le masque générique de chaque préfixe.

ACL standard et étendues

Les ACL nommées sont préférables aux ACL numérotées : elles sont lisibles et permettent d'insérer ou de supprimer une règle précise grâce aux numéros de séquence.

Pourquoi ces règles de placement ?

• Une ACL standard ne connaît que la source : placée près de la source, elle bloquerait cette source vers toutes les destinations. On la place donc près de la destination.
• Une ACL étendue est précise : placée près de la source, elle rejette le trafic indésirable avant qu'il ne consomme de la bande passante sur le réseau.

Exemple 1 : ACL standard pour l'administration

Limiter les connexions SSH au routeur au réseau d'administration :

R1(config)# ip access-list standard ACL-VTY-ADMIN
R1(config-std-nacl)# remark Acces SSH depuis le reseau d'administration uniquement
R1(config-std-nacl)# permit 10.10.99.0 0.0.0.255
R1(config-std-nacl)# deny any log
R1(config-std-nacl)# exit
R1(config)# line vty 0 15
R1(config-line)# access-class ACL-VTY-ADMIN in

Le deny any log explicite est équivalent au refus implicite, mais il journalise les tentatives refusées et rend la règle visible.

Exemple 2 : ACL étendue entre VLAN

Scénario : le VLAN 10 (utilisateurs, 10.10.10.0/24) doit pouvoir joindre le serveur web 10.10.20.80 en HTTPS et les serveurs DNS 10.10.20.53–54, mais rien d'autre dans le VLAN 20 (serveurs). L'accès à Internet reste autorisé.

SW-CORE(config)# ip access-list extended ACL-VLAN10-IN
SW-CORE(config-ext-nacl)# remark --- Services autorises vers les serveurs ---
SW-CORE(config-ext-nacl)# 10 permit tcp 10.10.10.0 0.0.0.255 host 10.10.20.80 eq 443
SW-CORE(config-ext-nacl)# 20 permit udp 10.10.10.0 0.0.0.255 host 10.10.20.53 eq domain
SW-CORE(config-ext-nacl)# 21 permit udp 10.10.10.0 0.0.0.255 host 10.10.20.54 eq domain
SW-CORE(config-ext-nacl)# 30 permit tcp 10.10.10.0 0.0.0.255 host 10.10.20.53 eq domain
SW-CORE(config-ext-nacl)# 31 permit tcp 10.10.10.0 0.0.0.255 host 10.10.20.54 eq domain
SW-CORE(config-ext-nacl)# 40 permit udp 10.10.10.0 0.0.0.255 eq bootpc any eq bootps
SW-CORE(config-ext-nacl)# remark --- Interdire le reste du reseau interne ---
SW-CORE(config-ext-nacl)# 50 deny ip 10.10.10.0 0.0.0.255 10.0.0.0 0.255.255.255 log
SW-CORE(config-ext-nacl)# remark --- Acces Internet ---
SW-CORE(config-ext-nacl)# 60 permit ip 10.10.10.0 0.0.0.255 any
SW-CORE(config-ext-nacl)# exit
SW-CORE(config)# interface Vlan10
SW-CORE(config-if)# ip access-group ACL-VLAN10-IN in

Remarques :

• l'ACL est appliquée en entrée sur la SVI du VLAN 10, au plus près de la source ;
• les deux serveurs DNS .53 et .54 ne forment pas un bloc aligné : un couple 10.10.20.52 0.0.0.1 couvrirait .52 et .53, pas .54. D'où deux règles host par protocole. Vérifiez toujours qu'un masque générique couvre exactement les adresses voulues ;
• la règle 40 autorise les requêtes DHCP des clients (le relais ip helper-address sur la SVI les traite) ;
• les réponses des serveurs vers le VLAN 10 ne sont pas filtrées par cette ACL, car elle n'est appliquée qu'en entrée sur la SVI du VLAN 10 ;
• les numéros de séquence permettent d'insérer une règle plus tard (15 permit …) ou d'en supprimer une (no 20).

Sur les plateformes qui le prennent en charge, des groupes d'objets (object-group network, object-group service) permettent de regrouper adresses et ports pour alléger ce type de liste.

Le mot-clé established

Une ACL étendue peut autoriser le trafic TCP « de retour » avec le mot-clé established, qui correspond aux segments portant les drapeaux ACK ou RST :

permit tcp any 10.10.10.0 0.0.0.255 established

Ce n'est pas un véritable suivi d'état : un attaquant peut forger des segments avec ces drapeaux. Pour un filtrage avec état sur un routeur Cisco, il faut utiliser le pare-feu basé sur les zones (ZBFW) ou un pare-feu dédié.

ACL IPv6

ipv6 access-list ACL6-VLAN10-IN
 permit tcp 2001:db8:acad:10::/64 host 2001:db8:acad:20::80 eq 443
 permit icmp any any nd-na
 permit icmp any any nd-ns
 deny ipv6 2001:db8:acad:10::/64 2001:db8:acad::/48 log
 permit ipv6 2001:db8:acad:10::/64 any
interface Vlan10
 ipv6 traffic-filter ACL6-VLAN10-IN in

Les ACL IPv6 utilisent des préfixes (pas de masque générique), et contiennent des autorisations implicites pour la découverte des voisins (NS/NA) avant le refus implicite final. Si vous ajoutez votre propre deny ipv6 any any log en fin de liste, ces autorisations implicites ne s'appliquent plus : ajoutez alors explicitement les règles NDP, comme dans l'exemple.

Vérifier

show access-lists
show ip access-lists ACL-VLAN10-IN
show ip interface Vlan10 | include access list
show running-config | section access-list

Les compteurs de correspondance ((152 matches)) montrent quelles règles sont utilisées. Une règle à zéro correspondance depuis longtemps est peut-être inutile — ou masquée par une règle plus large placée avant elle. clear ip access-list counters remet les compteurs à zéro avant un test.

Modifier une ACL sans couper le trafic

Avec une ACL nommée, on modifie ligne par ligne grâce aux numéros de séquence. Ne supprimez pas l'ACL entière pendant qu'elle est appliquée à une interface : selon les plateformes, une ACL vide appliquée peut tout autoriser ou tout bloquer. Préparez la nouvelle version sous un autre nom, puis remplacez l'association sur l'interface.

Travaillez à distance avec un filet de sécurité (reload in 10) lorsque vous modifiez une ACL qui pourrait couper votre propre accès.

Erreurs courantes

• Oublier le refus implicite et bloquer tout le trafic.
• Masque générique erroné (masque de sous-réseau saisi à la place, bloc non aligné).
• Ordre incorrect : une règle large placée avant des règles précises.
• ACL standard placée près de la source.
• Appliquer l'ACL dans le mauvais sens (in/out) ou sur la mauvaise interface.
• Bloquer le DHCP ou le DNS en oubliant ces flux.

Conclusion

Une ACL juste se construit en trois questions : quel trafic (règles précises, masques génériques corrects), dans quel ordre (du plus spécifique au plus général, en pensant au refus implicite), et où (interface et sens). Utilisez des ACL nommées, commentées et numérotées, et vérifiez-les avec les compteurs. Pour un filtrage avec état et une politique complète, voir Pare-feu : règles de filtrage et bonnes pratiques.

Références

• Cisco — Security Configuration Guide: Access Control Lists (IOS XE)
• Cisco — Configure Commonly Used IP ACLs
• RFC 4890 — Recommendations for Filtering ICMPv6 Messages in Firewalls