Comprendre les ACL sur Cisco : ce que j’ai appris en pratiquant

 

Dernièrement, j’ai commencé à travailler sur les ACL (Access Control Lists) sur Cisco.

Au début, je pensais que c’était simplement quelques commandes permit et deny à apprendre. Mais en faisant des tests sur Packet Tracer, j’ai compris que le plus important n’est pas vraiment de mémoriser les commandes.

Il faut surtout comprendre comment le trafic circule dans le réseau et dans quel ordre le routeur vérifie les règles.

Dans cet article, je vais donc présenter ce que j’ai appris sur les ACL avec un exemple simple.

---

Une ACL, c’est quoi exactement ?

Une ACL est une liste de règles qu’on peut appliquer sur un routeur pour contrôler le trafic réseau.

En gros, on peut dire au routeur :

• ce trafic peut passer ;
• ce trafic doit être bloqué.

Par exemple, imaginons que j’ai un réseau :

192.168.1.0/24

et un serveur avec l’adresse :

10.0.0.10

Je peux décider d’autoriser les utilisateurs à accéder au serveur en HTTPS, mais de bloquer les connexions SSH.

C’est là que les ACL deviennent intéressantes.

---

ACL standard et ACL étendue

Il existe plusieurs types d’ACL, mais les deux types principaux que j’ai étudiés sont les ACL standard et les ACL étendues.

ACL standard

Une ACL standard travaille principalement avec l’adresse IP source.

Par exemple :

access-list 10 deny host 192.168.1.10
access-list 10 permit any

Ici, on bloque la machine :

192.168.1.10

puis on autorise toutes les autres.

C’est simple, mais ce type d’ACL est limité.

Si je veux dire :

je veux bloquer uniquement SSH vers un serveur précis

une ACL standard n’est pas suffisante.

---

Les ACL étendues

Les ACL étendues sont beaucoup plus intéressantes parce qu’on peut préciser plusieurs informations :

• l’adresse source ;
• l’adresse destination ;
• le protocole ;
• le port.

C’est ce type d’ACL que j’ai surtout utilisé pendant mes tests.

Prenons cette commande :

access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443

La première fois qu’on regarde cette commande, elle peut sembler assez compliquée.

Mais si on la découpe, elle devient beaucoup plus logique.

access-list 100

C’est simplement le numéro de l’ACL.

permit

On autorise le trafic.

tcp

On travaille avec le protocole TCP.

192.168.1.0 0.0.0.255

C’est notre réseau source.

host 10.0.0.10

C’est notre serveur destination.

Et finalement :

eq 443

veut dire que le port de destination doit être le port 443, donc HTTPS.

La commande veut donc simplement dire :

autoriser les machines du réseau 192.168.1.0/24 à accéder au serveur 10.0.0.10 en HTTPS.

Quand j’ai compris cette logique, les commandes ACL sont devenues beaucoup plus faciles à lire.

---

La wildcard mask

Une chose qui m’avait aussi un peu perturbé au début était la wildcard mask.

Par exemple, pour le réseau :

192.168.1.0/24

le masque classique est :

255.255.255.0

Mais dans une ACL Cisco, on utilise :

0.0.0.255

C’est la wildcard mask.

Une façon simple de la trouver est de faire :

255.255.255.255
-
255.255.255.0
=
0.0.0.255

Donc dans une ACL, on écrit :

192.168.1.0 0.0.0.255

et non :

192.168.1.0 255.255.255.0

Le subnetting aide donc beaucoup pour comprendre les ACL.

---

Mon exemple pratique

Pour pratiquer, j’ai utilisé le scénario suivant :

Réseau utilisateurs :
192.168.1.0/24

Serveur :
10.0.0.10

Je voulais obtenir ce résultat :

• HTTPS autorisé ;
• SSH bloqué ;
• SMTP bloqué uniquement pour un PC précis ;
• le reste du trafic autorisé.

---

Autoriser HTTPS

HTTPS utilise le port TCP 443.

J’ai donc créé cette règle :

access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443

Avec cette règle, les ordinateurs du réseau 192.168.1.0/24 peuvent accéder au serveur sur le port HTTPS.

---

Bloquer SSH

Ensuite, je voulais empêcher les utilisateurs de se connecter au serveur avec SSH.

SSH utilise le port :

22

J’ai donc ajouté :

access-list 100 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 22

À ce moment-là, j’avais donc :

access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443
access-list 100 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 22

HTTPS passe, mais SSH est bloqué.

---

Bloquer SMTP pour un seul PC

Après cela, j’ai voulu faire quelque chose d’un peu plus précis.

Je voulais empêcher uniquement le PC :

192.168.1.10

d'utiliser SMTP avec le serveur.

SMTP utilise normalement le port TCP 25.

J’ai donc utilisé :

access-list 100 deny tcp host 192.168.1.10 host 10.0.0.10 eq 25

On peut aussi trouver :

eq smtp

à la place de :

eq 25

Dans ce cas, les deux correspondent au même service.

Ce qui est intéressant ici, c’est que je ne bloque pas SMTP pour tout le réseau.

Je bloque seulement :

192.168.1.10

vers :

10.0.0.10

sur le port 25.

C’est exactement pour ce genre de situation que les ACL étendues sont utiles.

---

Une erreur que j’ai faite avec l’ordre des règles

C’est probablement la partie qui m’a le plus aidé à comprendre le fonctionnement des ACL.

À un moment, mon ACL ressemblait à ça :

access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443
access-list 100 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 22
access-list 100 permit ip any any
access-list 100 deny tcp host 192.168.1.10 host 10.0.0.10 eq 25

Je pensais que ma règle SMTP allait bloquer le trafic.

Mais ce n’était pas le cas.

Pourquoi ?

Parce que Cisco lit les règles de haut en bas.

Quand un paquet arrive sur :

permit ip any any

il est déjà autorisé.

Cisco ne continue pas jusqu’à la règle suivante.

Donc cette règle :

deny tcp host 192.168.1.10 host 10.0.0.10 eq 25

ne pouvait plus bloquer le trafic concerné.

Il fallait simplement changer l’ordre :

access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443
access-list 100 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 22
access-list 100 deny tcp host 192.168.1.10 host 10.0.0.10 eq 25
access-list 100 permit ip any any

Cette erreur m’a permis de retenir une chose importante :

Dans une ACL, l’ordre des règles compte énormément.

Une règle très générale comme :

permit ip any any

doit normalement être placée après les règles spécifiques si on veut que celles-ci soient prises en compte.

---

Le deny implicite

Il y a aussi une autre chose importante que je ne connaissais pas avant : le deny implicite.

À la fin d’une ACL, Cisco considère automatiquement qu’il existe :

deny ip any any

même si cette ligne n’est pas affichée dans notre configuration.

Par exemple, si j’écris seulement :

access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443

cela ne signifie pas :

HTTPS est autorisé et tout le reste continue normalement.

Cela signifie plutôt :

HTTPS → autorisé
Tout le reste → refusé

C’est une chose qu’il ne faut vraiment pas oublier.

C’est pour cette raison que, dans mon exemple, j’ajoute à la fin :

access-list 100 permit ip any any

car je veux autoriser le reste du trafic.

---

Appliquer l’ACL sur une interface

Créer les règles ne suffit pas.

Il faut aussi appliquer l’ACL sur une interface du routeur.

Par exemple :

interface g0/0
ip access-group 100 in

Ici, l’ACL 100 est appliquée en entrée sur l’interface g0/0.

Au début, in et out peuvent facilement créer de la confusion.

Personnellement, la méthode que je trouve la plus simple est d’imaginer que je suis à la place du routeur.

Si le paquet arrive dans le routeur par cette interface :

in

S’il quitte le routeur par cette interface :

out

Par exemple :

PC -------- Router -------- Server
         G0/0     G0/1

Quand le PC envoie un paquet au serveur, le paquet entre dans le routeur par G0/0 et sort ensuite par G0/1.

---

Vérifier si l’ACL fonctionne

Une commande très utile pour vérifier une ACL est :

show access-lists

Par exemple, on peut obtenir :

Extended IP access list 100

10 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443 (16 match(es))

20 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 22 (24 match(es))

30 deny tcp host 192.168.1.10 host 10.0.0.10 eq smtp

40 permit ip any any

Les match(es) sont intéressants parce qu’ils permettent de voir si du trafic a réellement rencontré une règle.

Par exemple :

(24 match(es))

sur la règle SSH signifie que des paquets ont bien essayé de passer par cette règle.

Cela peut aider lorsqu’une configuration ne fonctionne pas comme prévu.

---

Les ports que j’utilise le plus dans mes tests

Pour les ACL, il est aussi utile de connaître quelques ports classiques.

Service	Port
FTP	21
SSH	22
Telnet	23
SMTP	25
DNS	53
HTTP	80
HTTPS	443

Il n’est pas nécessaire de connaître tous les ports existants, mais ceux-là reviennent souvent dans les exercices réseau.

---

La méthode que j’utilise maintenant

Quand je dois créer une nouvelle règle ACL, j’essaie de ne pas commencer directement par la commande.

Je me pose d’abord quelques questions :

Qui envoie le paquet ?

Par exemple :

192.168.1.10

Vers quelle machine ?

10.0.0.10

Quel protocole est utilisé ?

TCP

Quel service ?

SSH

Donc port :

22

Est-ce que je veux l’autoriser ou le bloquer ?

Dans cet exemple :

deny

Je peux ensuite construire :

access-list 100 deny tcp host 192.168.1.10 host 10.0.0.10 eq 22

Je trouve cette méthode beaucoup plus simple que d’essayer de mémoriser toute la syntaxe directement.

---

Configuration finale de mon exemple

Au final, mon ACL ressemble à ceci :

Router> enable
Router# configure terminal

Router(config)# access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443

Router(config)# access-list 100 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 22

Router(config)# access-list 100 deny tcp host 192.168.1.10 host 10.0.0.10 eq 25

Router(config)# access-list 100 permit ip any any

Puis je peux appliquer l’ACL :

Router(config)# interface g0/0
Router(config-if)# ip access-group 100 in

Et pour vérifier :

Router# show access-lists

---

Ce que je retiens des ACL

Après avoir pratiqué les ACL, je trouve que la syntaxe n’est finalement pas la partie la plus difficile.

Les points que je dois surtout retenir sont :

• une ACL est lue de haut en bas ;
• dès qu’une règle correspond au paquet, Cisco arrête la recherche ;
• il existe un deny ip any any implicite à la fin ;
• une ACL standard travaille surtout avec l’adresse source ;
• une ACL étendue peut utiliser la source, la destination, le protocole et les ports ;
• host représente une seule machine ;
• any représente n’importe quelle adresse ;
• in et out dépendent du sens du trafic par rapport à l’interface du routeur.

Et surtout, avant d’écrire une ACL, il faut comprendre le trafic que l’on veut contrôler.

Conclusion

Les ACL sont une notion importante dans l’administration réseau et la sécurité.

Elles permettent de contrôler les communications entre plusieurs réseaux, machines ou services.

Au début, les commandes peuvent sembler compliquées, surtout avec les wildcard masks, les ports et les directions in et out.

Mais après quelques tests sur Packet Tracer, j’ai remarqué qu’il suffit surtout de suivre la logique :

Source
↓
Destination
↓
Protocole
↓
Port
↓
Permit ou Deny
↓
Interface et direction

L’erreur que j’ai faite avec permit ip any any m’a aussi permis de comprendre quelque chose d’essentiel : avec les ACL, une petite erreur dans l’ordre des règles peut complètement changer le comportement du réseau.

La prochaine étape pour moi sera d’utiliser les ACL dans une architecture plus complète avec plusieurs VLANs et différents niveaux d’accès entre les utilisateurs et les serveurs.