Aller au contenu principal

ACL avancées — Cheat Sheet Cisco IOS

Trois mécanismes d'ACL qui vont au-delà du standard/étendu classique : les ACL réflexives (autoriser le retour d'un flux initié en interne, sans ouvrir tout le trafic entrant), les ACL temporelles (n'appliquer une règle qu'à certaines heures) et les object-groups (nommer des groupes d'IP/ports pour des ACL plus lisibles et maintenables). Pour les ACL standard/étendues de base, voir ACL standard et étendues.

ACL réflexives — autoriser le trafic retour dynamiquement​

Le problème qu'elles résolvent​

Une ACL entrante classique doit soit tout bloquer (aucun retour possible pour une connexion initiée depuis le LAN), soit ouvrir un port en permanence dans les deux sens (surface d'attaque inutile). Une ACL réflexive crée dynamiquement une entrée temporaire pour le trafic retour, calquée sur la connexion sortante observée — un premier niveau de fonctionnement "stateful" avec de simples ACL, sans pare-feu dédié.

ip access-list extended SORTANT
 permit tcp any any reflect REFLET-TCP
 permit udp any any reflect REFLET-UDP
 permit icmp any any

ip access-list extended ENTRANT
 evaluate REFLET-TCP
 evaluate REFLET-UDP
 deny ip any any

interface GigabitEthernet0/0
 ip access-group SORTANT out
 ip access-group ENTRANT in
  • reflect <nom> : à chaque paquet sortant qui correspond, crée une entrée temporaire miroir (IP/port inversés) dans la liste réflexive nommée.
  • evaluate <nom> : insère dynamiquement ces entrées temporaires dans l'ACL entrante — l'entrée disparaît automatiquement à la fin de la session (timeout TCP/UDP configurable via ip reflexive-list timeout).

:::note Différence avec une ACL établie (established) Le mot-clé established (sur une ACL étendue classique) ne vérifie que le bit ACK/RST TCP — il n'existe pas d'équivalent pour UDP/ICMP, et il peut être trompé par un paquet forgé avec ACK positionné. Les ACL réflexives suivent la session elle-même, plus robustes, et fonctionnent aussi pour UDP. :::

ACL temporelles — restreindre par plage horaire​

time-range HEURES-BUREAU
 periodic weekdays 8:00 to 18:00

time-range MAINTENANCE-WEEKEND
 periodic Saturday Sunday 0:00 to 23:59

ip access-list extended FILTRE-HORAIRE
 permit tcp 192.168.1.0 0.0.0.255 any eq 80 time-range HEURES-BUREAU
 permit tcp 192.168.1.0 0.0.0.255 any eq 443 time-range HEURES-BUREAU
 permit ip any any time-range MAINTENANCE-WEEKEND
 deny ip any any
  • periodic accepte des jours nommés (weekdays, weekend, ou une liste explicite comme Saturday Sunday) et une plage HH:MM to HH:MM.
  • L'horloge du routeur doit être fiable pour que time-range fonctionne correctement — voir la fiche NTP : une dérive d'horloge non détectée fait appliquer la règle au mauvais moment, silencieusement.

Object-groups — ACL nommées et maintenables​

Sans object-group (répétitif, difficile à maintenir)​

access-list 100 permit tcp any host 10.1.1.10 eq 80
access-list 100 permit tcp any host 10.1.1.10 eq 443
access-list 100 permit tcp any host 10.1.1.11 eq 80
access-list 100 permit tcp any host 10.1.1.11 eq 443

Avec object-group (une seule règle, groupes réutilisables)​

object-group network SERVEURS-WEB
 host 10.1.1.10
 host 10.1.1.11

object-group service PORTS-WEB
 tcp eq 80
 tcp eq 443

ip access-list extended ACL-OBJET
 permit object-group PORTS-WEB any object-group SERVEURS-WEB
 deny ip any any
  • Ajouter un serveur au groupe SERVEURS-WEB met à jour toutes les règles qui le référencent, sans toucher à l'ACL elle-même — le principal gain de maintenabilité par rapport à des lignes access-list répétées.
  • Les object-groups sont aussi la brique de base de la logique de filtrage du Zone-Based Firewall (class-map avec match access-group ou object-groups directement).

Édition d'une ACL nommée par numéro de séquence (bonne pratique générale)​

ip access-list extended ACL-OBJET
 show                         ! (en mode sous-commande) affiche les lignes avec leur numéro de séquence
 no 20                        ! supprime uniquement la ligne 20
 15 permit tcp any any eq 22  ! insère une nouvelle ligne entre 10 et 20

Toujours utiliser une ACL nommée (ip access-list extended <nom>) plutôt qu'un numéro seul : elle s'édite ligne par ligne via son numéro de séquence, alors qu'une ACL numérotée classique doit être entièrement retapée pour insérer une règle au milieu.

Vérification​

show ip access-lists                    ! toutes les ACL, avec compteurs de correspondance
show ip access-lists ACL-OBJET          ! détail d'une ACL nommée, séquences visibles
show object-group                       ! contenu des object-groups définis
show access-lists REFLET-TCP            ! entrées temporaires actives d'une liste réflexive

:::warning Pièges fréquents

  • Ordre d'évaluation : comme toute ACL Cisco, la première ligne qui correspond s'applique — une règle deny trop large placée avant un permit plus spécifique rend ce dernier inutile.
  • evaluate sans reflect correspondant : la liste réflexive doit être générée par une ACL de sortie active (ip access-group ... out) — sans trafic sortant qui matche reflect, la liste reste vide et evaluate ne laisse jamais rien passer.
  • time-range sans horloge fiable : voir la remarque NTP ci-dessus — une règle horaire sur un routeur dont l'horloge dérive de plusieurs minutes/heures s'applique au mauvais moment sans aucun message d'erreur. :::

📝 Tester ses connaissances

1. Quel problème résolvent les ACL réflexives par rapport à une ACL entrante classique ?

2. Pourquoi les ACL réflexives sont-elles considérées plus robustes que le mot-clé `established` ?

3. Quel est l'intérêt principal des object-groups dans une ACL ?

4. Pourquoi préférer une ACL nommée à une ACL numérotée classique ?