Applique une ACL réseau Cisco dans Packet Tracer

L’idée reçue

« Une ACL Cisco et un pare-feu nftables font la même chose, seule la syntaxe change. »

Non. Une ACL IPv4 classique examine des champs du paquet et applique une décision ordonnée. Elle ne remplace pas le suivi d’état d’un pare-feu stateful. La leçon 18 montrera précisément cette différence avec conntrack.

01Place l’ACL dans le fil rouge

Réutilise la topologie déjà travaillée :

VLAN 10  ADMINISTRATION  10.50.10.0/24
VLAN 20  UTILISATEURS    10.50.20.0/24
VLAN 30  SERVICES        10.50.30.0/24

DNS de laboratoire      10.50.30.53
application web         10.50.30.31:8080
administration serveur  10.50.30.31:22

Exigence synthétique SORIA Distribution :

1. les utilisateurs peuvent interroger le DNS de laboratoire ;
2. les utilisateurs peuvent atteindre l'application TCP/8080 ;
3. les utilisateurs ne doivent pas administrer le serveur en SSH ;
4. les autres flux issus du VLAN utilisateurs ne sont pas autorisés par cette politique ;
5. le VLAN administration n'est pas filtré par cette ACL utilisateur.

Aucune adresse ni topologie de production SORIA n’est utilisée.

02Distingue standard et étendue sans apprendre une liste de numéros

Une ACL standard décide principalement à partir de l’adresse source. Elle convient lorsque l’exigence ne demande pas de distinguer destination, protocole ou port.

Une ACL étendue peut préciser notamment :

source
destination
protocole IP
type de trafic TCP/UDP/ICMP
port source ou destination lorsque pertinent

Ici, l’exigence distingue DNS, HTTP de laboratoire et SSH vers des destinations précises. Une ACL étendue est donc le bon outil pédagogique.

Choisir « étendue » n’est pas une préférence de syntaxe. C’est une conséquence directe de ce que la politique doit distinguer.

03Comprends la logique « premier match »

Une ACL est parcourue dans l’ordre. Dès qu’une entrée correspond au paquet, la décision de cette entrée s’applique et les suivantes ne sont plus évaluées.

Imagine cette mauvaise séquence :

10 permit ip 10.50.20.0 0.0.0.255 any
20 deny tcp 10.50.20.0 0.0.0.255 host 10.50.30.31 eq 22

La ligne 20 ne peut pas bloquer le SSH des utilisateurs : le paquet a déjà correspondu à la ligne 10.

Réécris mentalement la politique avant de saisir des commandes :

spécifique avant général
besoin métier avant syntaxe
vérification après application

04Comprends le deny implicite avant de toucher l’interface

À la fin d’une ACL IPv4 existe une décision implicite de refus pour ce qui n’a correspondu à aucune autorisation.

Cela signifie qu’une ACL contenant uniquement :

permit tcp USERS -> APP:8080

n’autorise pas automatiquement le reste. Tout trafic non correspondant finit par être refusé.

Avant d’appliquer l’ACL, réponds donc à cette question :

Quels flux nécessaires ne sont pas encore explicitement autorisés ?

Le deny implicite est utile pour une politique restrictive, mais il peut aussi provoquer une coupure si l’ACL est appliquée avant d’avoir recensé tous les flux nécessaires.

05Traduis le plan d’adressage en wildcard masks

Pour un /24 :

masque réseau : 255.255.255.0
wildcard ACL   : 0.0.0.255

Le VLAN utilisateurs devient donc :

10.50.20.0 0.0.0.255

Et pour une machine précise, utilise host :

host 10.50.30.31
host 10.50.30.53

Ne transforme pas le wildcard en exercice de mémorisation. Il doit correspondre au périmètre réellement autorisé.

06Crée l’ACL avant de l’appliquer

Sur le routeur de laboratoire :

Router> enable
Router# configure terminal
Router(config)# ip access-list extended USERS-IN
Router(config-ext-nacl)# 10 permit udp 10.50.20.0 0.0.0.255 host 10.50.30.53 eq 53
Router(config-ext-nacl)# 20 permit tcp 10.50.20.0 0.0.0.255 host 10.50.30.31 eq 8080
Router(config-ext-nacl)# 30 deny tcp 10.50.20.0 0.0.0.255 host 10.50.30.31 eq 22
Router(config-ext-nacl)# end

Observe l’ACL avant toute liaison avec une interface :

Router# show ip access-lists USERS-IN

Explique chaque ligne en français avant de poursuivre.

La règle 30 rend le refus SSH visible et documentable. Les autres flux non autorisés restent couverts par le deny implicite de fin de liste.

07Choisis le sens à partir du trajet du paquet

Dans cette maquette, l’ACL concerne les paquets qui entrent dans le routeur depuis le VLAN utilisateurs.

Si le VLAN 20 est porté par une sous-interface de type :

GigabitEthernet0/0.20

applique l’ACL en entrée :

Router# configure terminal
Router(config)# interface gigabitEthernet0/0.20
Router(config-subif)# ip access-group USERS-IN in
Router(config-subif)# end

Vérifie ensuite :

Router# show ip interface gigabitEthernet0/0.20
Router# show running-config interface gigabitEthernet0/0.20

Si ta maquette utilise un équipement de couche 3 ou un autre nom d’interface, adapte le nom, pas le raisonnement.

Pour décider entre in et out, dessine une flèche :

poste VLAN20 -> interface VLAN20 du routeur -> décision de routage -> interface de sortie
                 ^
                 |
              ACL in

« In » et « out » se lisent du point de vue de l’interface de l’équipement, pas du point de vue de l’utilisateur.

08Teste d’abord ce qui doit fonctionner

Depuis un poste du VLAN 20, vérifie au minimum :

DNS vers 10.50.30.53 / UDP 53     -> doit réussir
TCP vers 10.50.30.31:8080          -> doit réussir

Dans Packet Tracer, utilise les outils disponibles dans la version du simulateur : requête DNS, navigateur, client TCP ou service équivalent.

Ne valide pas une ACL uniquement avec un ping si la politique porte sur des services TCP ou UDP précis.

Puis observe :

Router# show ip access-lists USERS-IN

Les compteurs des entrées utilisées doivent évoluer si l’image IOS simulée les expose.

09Effectue les tests négatifs

Depuis le même poste utilisateurs :

SSH vers 10.50.30.31:22             -> doit échouer
flux non explicitement autorisé      -> doit échouer

Depuis le VLAN administration, vérifie séparément que la politique utilisateur ne s’applique pas par erreur à ce trafic.

Le résultat attendu doit être formulé avant le test :

source
destination
protocole / port
décision attendue
décision observée
entrée ACL concernée ou deny implicite

10Compare explicitement ACL et pare-feu stateful

Dans cette leçon :

ACL Cisco classique
- évalue des critères de paquet ;
- suit l'ordre des entrées ;
- s'arrête au premier match ;
- possède un deny implicite ;
- dépend de son placement et de son sens ;
- ne doit pas être assimilée automatiquement à un suivi de connexion.

Dans la leçon 18 :

nftables stateful
- utilise conntrack ;
- peut identifier established/related ;
- autorise explicitement les paquets de retour selon l'état de connexion ;
- exprime une politique de pare-feu avec contexte d'état.

Un mot comme established peut exister dans certaines syntaxes ACL TCP, mais cela ne transforme pas une ACL classique en modèle conntrack équivalent au pare-feu stateful étudié ensuite.

11Panne contrôlée — l’ordre ou le placement est faux

L’évaluateur choisit une seule variante :

A — une règle trop générale est placée avant le refus SSH ;
B — l'ACL est appliquée dans le mauvais sens ;
C — l'ACL est appliquée sur la mauvaise interface ;
D — un wildcard élargit ou réduit le périmètre attendu.

Symptôme :

« Après la mise en place du filtrage, un flux interdit passe encore ou un flux nécessaire ne fonctionne plus. »

Méthode imposée :

1. reproduire le symptôme ;
2. identifier le trajet réel du paquet ;
3. lire l'ACL dans l'ordre ;
4. vérifier l'interface et le sens d'application ;
5. relever les compteurs disponibles ;
6. formuler une cause unique ;
7. effectuer une correction bornée ;
8. refaire tests positif et négatif.

Commandes de preuve possibles :

show ip access-lists
show ip interface INTERFACE
show running-config interface INTERFACE
show running-config | section ip access-list

12Prépare un rollback borné

Avant modification, conserve :

show ip access-lists USERS-IN
show running-config interface gigabitEthernet0/0.20

Pour retirer uniquement l’application de cette ACL de l’interface :

Router# configure terminal
Router(config)# interface gigabitEthernet0/0.20
Router(config-subif)# no ip access-group USERS-IN in
Router(config-subif)# end

Vérifie ensuite que l’association a disparu avant toute autre action.

Ne supprime pas toutes les ACL du routeur pour annuler une seule modification.

Si le rollback exige aussi la suppression de l’objet de laboratoire, fais-le seulement après avoir prouvé qu’il n’est plus attaché à une interface :

Router# configure terminal
Router(config)# no ip access-list extended USERS-IN
Router(config)# end

13Constitue la preuve BTS

Remets au minimum :

1. matrice de flux métier ;
2. schéma indiquant où l'ACL est appliquée ;
3. justification standard vs étendue ;
4. ACL ordonnée ;
5. preuve interface + sens ;
6. au moins deux tests positifs ;
7. au moins deux tests négatifs ;
8. compteurs ou sorties show disponibles ;
9. diagnostic de la panne contrôlée ;
10. correction bornée ;
11. rollback prévu ;
12. limite de la conclusion.

Limite à écrire explicitement :

Cette preuve valide une ACL IPv4 stateless dans une maquette Cisco de laboratoire.
Elle ne prouve pas une politique de pare-feu stateful complète, une inspection applicative, ni la sécurité globale de l'équipement.

Challenge autonome

Pars d’une matrice de flux, pas d’une liste de commandes

Reçois une nouvelle matrice source/destination/service. Construis l’ACL sans recopier l’exemple, choisis son placement et son sens, annonce les résultats attendus, exécute les tests positifs et négatifs puis démontre avec les sorties d’observation pourquoi la politique est correcte.

✓Ce que tu retiens

Une ACL fiable commence par une politique de flux lisible. L’ordre est significatif, le premier match décide, le deny implicite ferme ce qui n’est pas autorisé et le placement détermine quels paquets sont réellement évalués. Une ACL classique n’est pas un substitut silencieux au pare-feu stateful étudié avec nftables.