TP3.20 - Les ACL CISCO
TP3.20 - Les ACL CISCO
TP3.20 - Les ACL CISCO
Objectifs de ce TP
Nous allons nous plonger dans la base des ACLs. Comprendre leur but, leur fonctionnement et leur
utilisation. Nous verrons également en quoi ces dernières diffèrent des règles de flux classiques que
nous pourrions retrouver sur un pare-feu. Cette activité propose plusieurs scénarios de filtrage,
permettant de comprendre le fonctionnement des access-lists CISCO, appliquées aux interfaces de
routeur, en entrée et en sortie. Les 8 scénarios proposés permettent d’aborder successivement : les
access-lists standard, les access-lists étendues, le filtrage en fonction de la source et/ou de la
destination IP, le filtrage en fonction du protocole concerné (ICMP), du service demandé, de l’état
TCP.
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 1
Travail individuel – Durée 6h00
Partie cours
Les ACL (Access Control Lists), ou Listes de Contrôle d'Accès, sont des outils fondamentaux
pour gérer la sécurité et l'accès aux ressources réseau. Elles sont utilisées principalement dans
les routeurs et les pares-feux pour contrôler le trafic entrant et sortant.
1. Qu’est-ce qu’une ACL ?
Une ACL est une liste de règles qui spécifient quel trafic réseau est autorisé ou refusé. Chaque
règle est composée de critères, tels que les adresses IP source et de destination, les ports, les
protocoles… ainsi que d'une action à prendre : autoriser ou refuser. Les ACL peuvent être
utilisées pour contrôler le trafic à différents niveaux, du routage au filtrage du trafic sur un
pare-feu.
2. Types d’ACL
Il existe deux principaux types d’ACL :
a. ACL Standard : Ces ACL se basent généralement sur les adresses IP source.
Elles sont plus simples et sont couramment utilisées pour autoriser ou refuser
l'accès à certaines parties du réseau.
b. ACL Étendue : Ces ACL permettent de définir des règles plus complexes en
incluant des critères tels que les adresses IP source et de destination, les ports,
les protocoles, etc. Elles sont plus puissantes mais aussi plus complexes à
configurer.
3. Utilisations des ACL
Les ACL peuvent servir au filtrage du trafic réseau. Elles permettent ainsi de bloquer les
connexions non autorisées ou de limiter l’accès à certaines ressources.
Elles peuvent également servir au contrôle d’accès. En effet, elles peuvent être employées pour
définir qui peut accéder à un réseau ou à des services spécifiques.
Enfin, elles peuvent jouer un rôle de QoS (Quality of Services), ou Qualité de Services. Ces
dernières sont dans ce cas utilisées dans le but de prioriser le trafic en fonction de différents
critères.
4. Précautions à prendre
a. Les ACL sont sensibles à l'ordre des règles. Assurez-vous que vos règles sont
dans le bon ordre pour éviter les conflits.
b. Après la configuration, testez toujours vos ACL pour vous assurer qu'elles
fonctionnent comme prévu. Surveillez également leurs activités pour détecter
toute anomalie.
c. Tenez un registre de vos ACL avec des descriptions détaillées pour faciliter la
gestion future.
En conclusion, les ACL sont un outil essentiel pour garantir la sécurité et la gestion efficace
des réseaux. En comprenant comment elles fonctionnent et en les configurant correctement,
vous pouvez contrôler le trafic réseau de manière granulaire et protéger votre infrastructure
contre les menaces potentielles sans avoir recours à d’autres équipements, comme des pares-
feux par exemple.
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 2
Travail individuel – Durée 6h00
Pour réaliser ce TP, vous devrez posséder un compte chez CISCO et utiliser le logiciel
« CISCO Packet Tracer ». Assurez-vous d’avoir le logiciel sur votre poste, et d’être à l’aise
dans son utilisation.
Dans le cas contraire, n’hésitez pas à vous référer au cours d’apprentissage du logiciel.
Le fichier .pkt de ce TP est fourni par votre intervenant.
Vous disposerez de deux fichiers .pkt. L'un d'entre eux contient déjà les tables de routage
configurées, tandis que l'autre ne les inclut pas. Si vous souhaitez vous exercer à la configuration
des routes statiques, ou si vous trouvez cela amusant (ce qui est mon cas ), je vous recommande
de privilégier le fichier sans les tables de routage et de les configurer vous-même.
Je reste bien-sûr à votre disposition pour vous aider en cas de difficultés.
Présentation du contexte
Cependant, les administrateurs réseau de Capméga ont identifiés que certains de ces sites ne
contribuent pas de manière significative à la productivité de l'entreprise. Dans le but de renforcer la
sécurité de cette infrastructure réseau, vous serez chargé de mettre en place des Listes de Contrôle
d'Accès (ACL) pour restreindre l'accès à certains de ces sites. Cette démarche vise également à
préparer l’entreprise à une certification spécifique en matière de cybersécurité.
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 3
Travail individuel – Durée 6h00
Dans ce scénario 1, notre objectif est d'isoler l'entreprise Capméga du reste du monde tout en
permettant une communication entre les deux réseaux internes de l’entreprise (192.1692.1.0 /24
et 192.192.2.0 /24). Cela signifie que nous devrons mettre en place des règles ACL pour contrôler
strictement le trafic en provenance du reste du monde et l’interdire, tout en autorisant la
communication interne au sein de l'entreprise Capméga.
Mettez en place ces 2 règles de filtrage avec des ACLs standards. Effectuez des tests de bon
fonctionnement à l’issue de chaque règle. Alimentez régulièrement votre compte-rendu.
Un des atouts de CISCO Packet Tracer est son incroyable mode simulation. Ce mode
vous écrit noir sur blanc, couche par couche, ce que devient votre paquet, et comment
ce dernier est traité par les différents équipements.
N’hésitez donc pas à utiliser ce mode pour faire des constats intéressants. Pensez
également à n’appliquer que les filtres qui vous intéressent (ICMP généralement).
Partie cours
Pour la bonne exécution de cette tâche pratique et, de manière générale, il peut être nécessaire
à certains moments de modifier, d'annuler ou de supprimer une règle ACL. Pour ce faire, il
suffit d'ajouter l'instruction « no » devant la ligne que vous souhaitez annuler.
Exemple :
R1(conf)# no access-list 1
R1(conf)# interface Gig0/0
R1(conf-if)# no ip access-group 1 out
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 4
Travail individuel – Durée 6h00
Supprimez les ACLs que vous avez positionnées sur R1 Gig1/0 et R1 Gig2/0 (2) pour ne garder que
l’ACL positionnée sur R1 Gig0/0 (1).
Question 1 : Après la réalisation de ce scénario, le reste du monde peut-il malgré tout requêter les
réseaux de Capméga ? Justifiez votre réponse.
Le scénario 1 avait un intérêt limité : pourquoi connecter l'entreprise Capméga au reste du monde
si aucun poste ne peut communiquer avec elle ? On va donc passer à un cas de figure plus
intéressant.
Dans ce scénario 2, nos objectifs sont maintenant de faire une distinction entre les deux réseaux de
l’entreprise Capméga :
Mettez en place ces 2 règles de filtrage avec des ACLs standards. Effectuez des tests de bon
fonctionnement à l’issue de chaque règle. Alimentez régulièrement votre compte-rendu.
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 5
Travail individuel – Durée 6h00
Pensez à garder votre simulation la plus propre possible, en annulant les ACL
précédemment positionnées qui ne servent plus, où en ouvrant un nouveau fichier .pkt.
o Dans le cas de la première solution, pensez à numéroter vos nouvelles ACL avec
un nouveau numéro inutilisé, et à établir un registre d’ACLs clair.
o Dans le cas de la seconde solution, pensez à repositionner les ACLs utiles pour la
suite de ce TP.
Aucun support de la part de votre intervenant ne pourra être apporté, si vous n’avez pas
une connaissance claire de votre situation.
Avec ces différents jeux, le filtrage est efficace. En revanche, on autorise quand même des flux non
souhaités et finalement inutiles, puisque sans suite. La requête transite, consomme des ressources,
alors qu’elle ne recevra jamais de réponse.
Comme vous l’aurez sans doute deviné, cette 3ème solution ne pourra pas être une access-list
standard puisqu’elle filtre sur la destination.
Supprimez l’ACL que vous avez positionnée sur R1 Gig2/0 (2) pour ne garder que l’ACL sur R1
Gig0/0 (1).
Mettez en place cette 3ème solution avec une ACL étendue. Effectuez des tests de bon
fonctionnement. Alimentez régulièrement votre compte-rendu.
L’accès internet pour le réseau COBALT est universel. Nous souhaiterions maintenant interdire
l’accès à quelques sites.
1. De continuer d’autoriser le réseau COBALT à avoir accès au reste du monde, mais pas CIEL.
2. Supprimer l’accès depuis tous les réseaux de l’entreprise à quelques destinations, peu
recommandables : rose.com et violette.com
3. La communication entre les deux réseaux internes de l’entreprise devra rester possible.
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 6
Travail individuel – Durée 6h00
Supprimez l’ACL devant être supprimée de la situation précédente (ACL standard R1 Gig0/0).
Mettez en place ces 2 règles de filtrage avec des ACLs étendues. Effectuez des tests de bon
fonctionnement à l’issue de chaque règle. Alimentez régulièrement votre compte-rendu.
Question 2 : Étant donné que le filtrage peut fonctionner avec qu’une seule des 2 solutions ci-
dessus, quelle ACL choisiriez-vous, pour un environnement de production ? Justifiez votre réponse.
Après validation de votre réponse à la Question 2 par votre intervenant, supprimez l’ACL que
vous n’avez pas choisie à la Question 2.
4. SCÉNARIO 4 : Blacklister un PC
Dans ce scénario 4, l'utilisateur du PC ayant l'adresse IP 192.192.1.2 a été repéré en train d'utiliser
un logiciel de DDoS pour attaquer le serveur emeraude.com. Pour contrer cette menace, nous
allons prendre des mesures pour bannir cet utilisateur, en utilisant son adresse IP. Cependant, il est
important de noter que cette interdiction ne doit pas affecter tout le réseau 203.30.30.0, mais
uniquement le serveur emeraude.com.
Pour ce faire, nous allons mettre en place une liste d'accès (ACL) sur le Routeur 3 (R3) qui ciblera
spécifiquement l'adresse IP du PC spammeur (192.192.1.2) et bloquera son accès au serveur
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 7
Travail individuel – Durée 6h00
emeraude.com, tout en permettant aux autres dispositifs des réseaux de continuer à communiquer
sans restriction. Cela contribuera à isoler la menace sans affecter les autres utilisateurs du réseau.
Pistes de réflexions (comme je suis bon, je vous aide encore un petit peu… )
Par principe, on bloque généralement autant que possible le trafic le plus tôt possible, donc le plus
à l’extérieur possible. Rappelez-vous : ACL étendue = au plus proche de la source (ici, du
spammeur). Au moins le loup n’est pas du tout entré dans la bergerie !
Sauf que, dans notre cas, l’administrateur réseau d’émeraude a son mot à dire et ne peut
configurer uniquement l’interface du routeur qui le concerne.
Avec ces éléments, mettez en place ces 2 règles de filtrage avec des ACLs de votre choix. Effectuez
des tests de bon fonctionnement à l’issue de chaque règle. Alimentez régulièrement votre
compte-rendu.
Question 3 : Étant donné que le filtrage peut fonctionner avec qu’une seule des 2 solutions ci-
dessus, quelle ACL choisiriez-vous, pour un environnement de production ? Justifiez votre réponse.
Après validation de votre réponse à la Question 3 par votre intervenant, supprimez l’ACL que
vous n’avez pas choisie à la Question 3.
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 8
Travail individuel – Durée 6h00
Tout au long de ces 4 scénarios, vous avez rédigé beaucoup d’ACLs, sur beaucoup
d’interfaces, sur plusieurs routeurs. Il est temps de faire une petite pause et de prendre
plusieurs minutes afin de vérifier que ces dernières fonctionnent toutes, qu’il n’y en ait
pas des superflus, que le trafic réseau s’écoule bien comme vous le souhaitez et que
votre registre d’ACLs est à jour. On appelle ces actions : les tests de non-régression.
N’hésitez pas à passer par l’outil « simulation » de CISCO Packet Tracer afin d’effectuer
ces tests.
Par mesure de précaution, il serait généralement recommandé de vérifier que toutes les autres
communications fonctionnent correctement après avoir appliqué des modifications, ce qui
constitue un test de non-régression. Cependant, dans ce cas précis, étant donné que cette règle est
appliquée sur un nouveau routeur et sur une interface spécifique, les effets de bord sont peu
probables.
La principale vérification à effectuer est de s'assurer que le réseau EMERAUDE peut toujours
communiquer avec les serveurs ORANGE et COBALT, car c'est l'objectif de cette configuration. Tant
que cette communication est maintenue, les autres flux de données ne devraient pas être affectés
par cette règle spécifique.
Ce scénario 5 a pour objectif de vous faire découvrir les possibilités d'accès restrictif à certains
services en se basant sur le numéro de port. Il mettra également en évidence qu'il est important de
prendre en compte les effets de bord qui peuvent survenir, et que ces effets peuvent être
significatifs si l'on manque d'expérience ou si l'on omet de réaliser des tests de non-régression. Ce
scénario vous permettra donc d'explorer la granularité des contrôles d'accès en fonction des ports
et de comprendre l'importance de tester rigoureusement les changements apportés à la
configuration réseau pour éviter des impacts indésirables.
Il est préférable de filtrer dès l’entrée du routeur, pour éviter tout traitement inutile.
On pourra pour ce point tester qu’une communication FTP (TCP/21) ou ICMP échoue par exemple.
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 9
Travail individuel – Durée 6h00
5. D’autoriser toutes les communications (web notamment) des serveurs ORANGE vers le reste
du monde.
Indication : Par défaut, sous CISCO Packet Tracer le nom d’utilisateur / mot de passe
pour les serveurs munis d’un accès FTP est : cisco/cisco
Un ping est possible depuis un serveur ORANGE vers le serveur COBALT par exemple.
Une communication HTTP est possible depuis orange.com vers violette.com par exemple, et
réciproquement.
Une communication FTP est possible sur le serveur orange.com depuis n’importe où (sauf
depuis CIEL qui n’a pas accès au reste du monde).
Avec ces éléments, mettez en place toutes ces règles de filtrage avec des ACLs étendues.
Effectuez des tests de bon fonctionnement à l’issue de chaque règle. Alimentez régulièrement
votre compte-rendu.
Effectuez depuis rose.com (par exemple) une recherche web avec l’URL orange.com. Vous
faites ainsi d’une pierre, deux coups : vous testez à la fois le bon fonctionnement du flux
DNS et du flux HTTP.
Vérifiez l’absence de communication en FTP vers un serveur du réseau ORANGE.
Vérifiez la bonne communication HTTP depuis un serveur ORANGE vers le site
emeraude.com (par exemple).
Vous voyez avec cet exemple que ces tests de non-régression sont utiles, car la
connexion depuis ORANGE vers un serveur web situé sur un autre réseau, bien qu’elle
doive être autorisée dans le cahier des charges, échoue !
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 10
Travail individuel – Durée 6h00
Cette observation peut être expliquée assez simplement : lorsqu'une demande HTTP est envoyée
vers l'extérieur, elle n'est pas soumise à un filtrage. Cependant, la réponse HTTP, en revanche, est
bien filtrée, ce qui explique le timeout. Cela s'explique par le fait que la réponse sera envoyée vers
un port aléatoire lorsqu’elle rentrera de nouveau dans le réseau ORANGE, port qui ne correspondra
ni au port du service DNS ni à celui du service HTTP.
Partie cours
En combinant ces deux aspects, nous pouvons autoriser les réponses aux connexions
sortantes tout en bloquant efficacement les tentatives de connexion non sollicitées de
l'extérieur, offrant ainsi un niveau de sécurité adéquat.
Passez cette commande et effectuez un nouveau test de non-régression sur ce sujet. Alimentez
régulièrement votre compte-rendu.
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 11
Travail individuel – Durée 6h00
significatif sur le filtrage du trafic réseau, et la séquence dans laquelle ces règles sont définies est
cruciale pour déterminer quelles règles sont appliquées en priorité. Ce scénario vise à renforcer la
compréhension de ces concepts clés en matière de gestion des listes d'accès.
Certains employés disposent d'une adresse électronique chez violette.com. Au départ, nous ne
souhaitions pas leur accorder l'accès au site Web de violette.com en raison de certaines parties du
site jugées inappropriées. Cependant, nous avons finalement décidé d'autoriser les employés à
récupérer leurs courriels depuis ce site. Pour ce faire, nous allons devoir configurer des règles
d'accès spécifiques qui permettront l'accès au service de messagerie tout en limitant l'accès aux
autres parties du site. Cela nécessitera une gestion précise des listes d'accès pour atteindre ces
objectifs.
1. Le réseau COBALT aura accès au service de messagerie sur mail.violette.com mais pas aux
autres services.
2. Le réseau CIEL n’aura toujours pas accès au reste du monde.
3. Les protocoles de messagerie utilisés seront les protocoles POP3 (TCP/110) et SMTP
(TCP/25).
4. Trouvez et identifiez la ou les règles à modifier.
Vérifiez, avant toute modification, qu’aucun accès POP3 ou SMTP n’est possible sur le serveur
mail.violette.com. Normalement tout doit être interdit vers le serveur violette.com.
1. La règle d'autorisation pour le service de messagerie doit avoir la priorité sur la règle
d'interdiction actuelle concernant le réseau 202.20.20.0 /24. Par conséquent, cette règle
d'autorisation doit être positionnée en amont dans la liste d'accès.
2. La règle d'autorisation doit spécifier la source (192.192.1.0 /24) pour éviter d'autoriser le
réseau CIEL. Bien sûr, il serait possible de définir une règle d'interdiction spécifique pour le
réseau CIEL, mais il est souvent préférable de privilégier la simplicité lorsque cela est
possible.
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 12
Travail individuel – Durée 6h00
Partie cours
Si vous utilisez la commande « show access-lists », vous remarquerez un nombre de
« matches ». Même si cela n’a rien à voir avec Tinder, il est tout de même très intéressant d’en
parler.
Vous remarquerez aussi que même si nous n'avons pas créé la liste d'accès en spécifiant des
numéros de ligne, le système les a automatiquement numérotées en utilisant un incrément de
10, dans l'ordre d'exécution.
C'est cette numérotation croissante qui détermine l'ordre dans lequel les règles sont évaluées
et appliquées par le système. Chaque ligne s’appelle une ACE (Access Control Entry). Vous
l’aurez donc compris, une ACL est en fait une liste d’ACE. En comprenant cette numérotation,
nous pouvons mieux appréhender la séquence dans laquelle les règles sont traitées et ainsi
prendre des décisions de configuration plus éclairées.
Partie cours
Pour modifier une liste d'accès, vous avez deux options :
1. Vous pouvez redéfinir entièrement la liste en spécifiant les règles dans l'ordre
approprié, après avoir supprimé la liste d'accès existante.
2. Vous pouvez insérer de nouvelles règles dans la liste d'accès existante en indiquant un
numéro de ligne correspondant à l'endroit où vous souhaitez insérer la règle. Cette
approche vous permet de conserver l'ordre des règles existantes tout en ajoutant de
nouvelles règles à des positions spécifiques.
Il est également possible de redéfinir une liste en réorganisant automatiquement les numéros
de ligne si vous n'avez plus d'espace disponible pour les insertions.
Par exemple, la commande ip access-list resequence 130 10 10 permet de redéfinir
les règles de la liste d'accès 130 en incrémentant les numéros de ligne de 10 en 10.
Le premier « 10 » spécifie le point de départ, tandis que le deuxième « 10 » spécifie
l'incrément ou le « pas » entre les numéros de ligne.
Cela peut être utile pour réorganiser une liste d'accès existante sans avoir à tout reconfigurer
manuellement. Cette fonction n’est pas implémentée sous CISCO Packet Tracer.
Il est important de noter qu'il est inutile de réaffecter l'access-list à l'interface après sa
suppression, car la suppression de l'access-list ne supprime pas automatiquement son
affectation précédente à une interface. Cependant, si vous ne recréez pas l'access-list après sa
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 13
Travail individuel – Durée 6h00
suppression, l'association entre l'access-list et l'interface n'aura aucun effet, car il n'y aura pas
de règles à appliquer.
En d'autres termes, supprimer une access-list de l'interface ne supprime pas l'access-list elle-
même.
Pour que les règles de l'access-list soient prises en compte sur une interface, il est nécessaire
de recréer ou de réappliquer l'access-list sur cette interface après sa suppression.
Modifiez les règles de filtrage pour correspondre à ce cahier des charges. Effectuez des tests de
bon fonctionnement à l’issue de chaque règle. Alimentez régulièrement votre compte-rendu.
Pour vos tests, après avoir paramétré le client mail sur l’un des PC du réseau COBALT, tentez l’envoi
d’un mail à vous-même : [email protected], mot de passe : sucre
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 14
Travail individuel – Durée 6h00
7. SCÉNARIO 7 : Ping-pong
Ce scénario 7 offre l'opportunité de découvrir un autre type de règle spécifique au protocole ICMP
(Internet Control Message Protocol). Ces règles permettent de faire la distinction entre les requêtes
ICMP (ICMP Echo Request) et les réponses ICMP (ICMP Echo Reply). La gestion des règles ICMP est
particulièrement importante pour la sécurité et la gestion du réseau, car elle permet de contrôler
les types de requêtes ICMP autorisées ou bloquées, ce qui peut avoir un impact significatif sur la
disponibilité et la sécurité du réseau. Ce scénario vise à mieux comprendre comment configurer ces
règles ICMP pour répondre aux besoins spécifiques du réseau.
Chez COBALT, la stratégie consiste à se protéger contre les requêtes de ping ICMP entrantes, car
elles sont souvent utilisées comme une première tentative de recherche de failles par les hackers
sur les réseaux ciblés. Cependant, il est souhaitable de permettre l'envoi de requêtes de ping vers
l'extérieur, tout en autorisant les réponses à ces requêtes à revenir sans être bloquées. Cette
configuration permet de renforcer la sécurité du réseau en limitant les requêtes de ping entrantes
tout en maintenant la possibilité d'utiliser des requêtes de ping sortantes pour effectuer des
diagnostics ou des tests de connectivité.
Ajoutez ou modifiez les règles de filtrage pour correspondre à ce cahier des charges. Effectuez des
tests de bon fonctionnement à l’issue de chaque règle. Alimentez régulièrement votre compte-
rendu.
Les pings sortants continuent bien à être autorisés (sauf règles contraires
précédemment définies). En revanche, un ping à destination du réseau COBALT, en
provenance de emeraude.com est désormais bloqué.
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 15