TP3.20 - Les ACL CISCO

Rendu attendu
Un compte rendu au format .PDF, conforme à la

procédure de compte rendu, déposé sur le Google
Classroom à la date indiquée.
Il est conseillé de faire une lecture complète de ce

support, avant de commencer les actions.
Travail individuel – Durée 6h00
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.
Table des matières

Comprendre et utiliser une ACL............................................................................................................. 2
Présentation du contexte ...................................................................................................................... 3
1. SCÉNARIO 1 : Isolation de l’entreprise Capméga ........................................................................... 4
2. SCÉNARIO 2 : Accès distinctif entre les réseaux ............................................................................. 5
3. SCÉNARIO 3 : Accès restreint vers le web....................................................................................... 6
4. SCÉNARIO 4 : Blacklister un PC ....................................................................................................... 7
5. SCÉNARIO 5 : Accès restrictif aux services ORANGE....................................................................... 9
6. SCÉNARIO 6 : Modifications d’ACL................................................................................................ 11
7. SCÉNARIO 7 : Ping-pong ................................................................................................................ 15
8. SCENRAIO 8 BONUS : Récriture .................................................................................................... 15
TP 3.20 – MISE EN PLACE D’ACL SOUS CISCO PACKET TRACER. CPT V8.2.1 1
Comprendre et utiliser une ACL
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.
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
Aujourd'hui, l'entreprise « Capméga », spécialisée en conseil informatique, dispose d'un accès à

divers sites conformément au schéma ci-dessous. Cela inclut l'accès aux serveurs de l'entreprise
« Orange » ainsi qu'aux serveurs de l'hébergeur. La maquette réseau fournie est opérationnelle dans
son état actuel, avec une connectivité fonctionnelle entre tous les réseaux : le routage est effectif.
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é.
1. SCÉNARIO 1 : Isolation de l’entreprise Capméga
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.
2 solutions peuvent être envisagées :
1. Empêcher tout trafic sortant sur R1 Gig0/0.

2. Filtrer les accès entrants vers les réseaux de Capméga sur R1 Gig1/0 et R1 Gig2/0.
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.
Avant de commencer votre mission, assurez-vous des communications (ping) :
Entre le réseau COBALT et le réseau CIEL.

Entre le réseau CIEL et le réseau ORANGE.
Entre le réseau COBALT et rose.com (via le nom DNS ou l’adresse IP).
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
Tests de bon fonctionnement :
La communication entre COBALT et CIEL est toujours possible.

La communication entre les réseaux Capméga et le reste du monde est interdite.
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.
2. SCÉNARIO 2 : Accès distinctif entre les réseaux
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 :
1. Le réseau COBALT (192.192.1.0 /24) aura accès au reste du monde. Réciproquement, le

reste du monde aura accès au réseau COBALT.
2. Le réseau CIEL (192.192.2.0 /24) ne pourra toujours pas communiquer avec le reste du
monde.
3. La communication entre les deux réseaux internes de l’entreprise devra rester possible.
1. Autoriser en sortie de R1 Gig0/0 seulement ce qui provient du réseau COBALT.

2. Autoriser en sortie de R1 Gig2/0 uniquement ce qui provient du réseau COBALT.
Mettez en place ces 2 règles de filtrage avec des ACLs standards. Effectuez des tests de bon
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.
Voici une 3ème solution pouvant être envisagée :
3. Autoriser en entrée de R1 Gig0/0 que les paquets à destination du réseau COBALT.
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.
3. SCÉNARIO 3 : Accès restreint vers le web
L’accès internet pour le réseau COBALT est universel. Nous souhaiterions maintenant interdire
l’accès à quelques sites.
Dans ce scénario 3, nos objectifs sont :
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.
1. Interdire les accès sortants vers les destinations prohibées.

2. Interdire les accès entrants depuis les sites prohibés.
Rappel : La commande « show access-lists » dans le menu « enable » permet de

visualiser les ACL déjà présentes sur le routeur.
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
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.
L’accès à orange.com et emeraude.com est fonctionnel depuis le réseau COBALT.

L’accès à violette.com et rose.com n’est pas fonctionnel depuis le réseau COBALT.
Les communications entre les réseaux d’entreprise sont toujours possibles.
Depuis le réseau CIEL, aucun accès externe n’est possible.
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
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… )
Il faut choisir si l’ACL se positionne en entrée de R3 Gig0/0 ou en sortie de R3 Gig3/0 :

▪ Si on la met sur R3 Gig0/0, il faut une ACL étendue pour filtrer à la fois sur la source
et la destination.
▪ Si on la met sur R3 Gig3/0, comme elle ne concerne que le serveur, il nous faut
également une ACL étendue.
Il faut choisir si l’ACL s’applique en entrée ou en sortie :
▪ Si on la positionne sur R3 Gig0/0, il faut la mettre en entrée, donc « in ».
▪ Si on la positionne sur R3 Gig3/0, il faut la mettre en sortie, donc « out ».
Il faut que toutes les autres communications restent autorisées :
▪ Premièrement, interdire l’adresse bannie.
▪ Deuxièmement, autoriser toute autre communication, avant l’interdiction implicite
finale.
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.
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.
5. SCÉNARIO 5 : Accès restrictif aux services ORANGE
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.
Le réseau ORANGE étant un datacenter sensible, il nous est demandé :
1. D’autoriser le protocole DNS destiné au serveur DNS (UDP/53).

2. D’autoriser le protocole HTTP destiné au serveur web (TCP/80).
3. De positionner ce filtrage en entrée sur l’interface R2 Gig0/0.
Il est préférable de filtrer dès l’entrée du routeur, pour éviter tout traitement inutile.
4. Bloquer tous les autres accès depuis l’extérieur.
On pourra pour ce point tester qu’une communication FTP (TCP/21) ou ICMP échoue par exemple.
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
Vérifications à effectuer avant la mise en place du filtrage :
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).
En invite de commande, il est possible d'utiliser le symbole « ? » à tout moment pour

obtenir la liste des commandes disponibles ou la liste des mots-clés utilisables pour
compléter une commande en cours.
Cette fonctionnalité est utile pour explorer les options et les commandes disponibles
dans le système et pour obtenir de l'aide contextuelle lorsque vous effectuez des
opérations de configuration ou d'administration.
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 !
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
La solution repose sur l'état TCP pour les requêtes TCP.
Plus précisément, voici comment cela fonctionne :

1. Une requête sortante établit toujours une connexion TCP. Par conséquent, si nous
pouvons accepter les réponses qui correspondent à un état « established », c'est-à-dire
à une connexion déjà initiée, cela résout notre problème.
Cela tombe bien, les access-lists sont conçues précisément pour gérer ce type de
scénario !
2. Une tentative de connexion depuis l'extérieur ne sera pas acceptée, car elle se traduira
par une demande de synchronisation (SYN), et par conséquent, l'état TCP ne sera pas
« established » pour cette connexion. Cela signifie que les connexions entrantes non
sollicitées seront bloquées par les access-lists, renforçant ainsi la sécurité du réseau.
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.
Voici la commande (à adapter à votre contexte !) :
On autorise tout flux TCP, pourvu que l’état soit « established ».
R2(conf)# access-list <id> permit tcp any any established
Passez cette commande et effectuez un nouveau test de non-régression sur ce sujet. Alimentez
régulièrement votre compte-rendu.
6. SCÉNARIO 6 : Modifications d’ACL
Ce scénario 6 offre l'opportunité d'étudier la modification d’ACL déjà en place, en y intégrant de

nouvelles règles. Il permet également de mieux comprendre l'importance de l'ordre des règles au
sein de cette liste. L'ajout de nouvelles règles dans une access-list existante peut avoir un impact
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.
L'analyse du cahier des charges nous conduit à deux conclusions importantes :
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.
Rappel : La commande « show access-lists » dans le menu « enable » permet de

visualiser les ACL déjà présentes sur le routeur.
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.
Ce nombre de « matches » entre parenthèses indique combien de fois un flux a été en

conformité avec une règle donnée. Cette information est très précieuse pour vérifier l'efficacité
et l'utilité des règles dans une liste d'accès. En examinant le nombre de « matches » pour
chaque règle, on peut évaluer si ces règles sont effectivement appliquées et si elles
correspondent aux besoins de sécurité ou de gestion du réseau.
Cette analyse permet d'identifier les règles qui sont rarement ou jamais utilisées, ce qui peut
conduire à une optimisation de la liste d'accès en supprimant les règles inutiles ou en les
ajustant pour mieux répondre aux besoins du réseau.
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
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 : sirop@violette.com, mot de passe : sucre
Figure 1 - Configuration du client mail
Figure 2 - Vérification du bon fonctionnement
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.
Vérifiez que le test depuis 192.192.1.2 vers emeraude.com est autorisé.

Vérifiez que le test depuis emeraude.com vers 192.192.1.2 est bloqué.
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é.
8. SCENRAIO 8 BONUS : Récriture

Ouvrez un nouveau fichier .pkt vierge d’ACL (le fichier .pkt téléchargé au début de ce TP).
Réécrivez l’intégralité de ces ACL en ACL nommées. Bien-sûr, aidez-vous du travail que vous venez
d’effectuer.

TP3.20 - Les ACL CISCO

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TP3.20 - Les ACL CISCO

Transféré par

Droits d'auteur :

Formats disponibles

Rendu attendu

Un compte rendu au format .PDF, conforme à la

Il est conseillé de faire une lecture complète de ce

Table des matières

Comprendre et utiliser une ACL

Aujourd'hui, l'entreprise « Capméga », spécialisée en conseil informatique, dispose d'un accès à

1. SCÉNARIO 1 : Isolation de l’entreprise Capméga

2 solutions peuvent être envisagées :

1. Empêcher tout trafic sortant sur R1 Gig0/0.

Avant de commencer votre mission, assurez-vous des communications (ping) :

Entre le réseau COBALT et le réseau CIEL.

Tests de bon fonctionnement :

La communication entre COBALT et CIEL est toujours possible.

2. SCÉNARIO 2 : Accès distinctif entre les réseaux

1. Le réseau COBALT (192.192.1.0 /24) aura accès au reste du monde. Réciproquement, le

2 solutions peuvent être envisagées :

1. Autoriser en sortie de R1 Gig0/0 seulement ce qui provient du réseau COBALT.

Voici une 3ème solution pouvant être envisagée :

3. Autoriser en entrée de R1 Gig0/0 que les paquets à destination du réseau COBALT.

3. SCÉNARIO 3 : Accès restreint vers le web

Dans ce scénario 3, nos objectifs sont :

2 solutions peuvent être envisagées :

1. Interdire les accès sortants vers les destinations prohibées.

Rappel : La commande « show access-lists » dans le menu « enable » permet de

Tests de bon fonctionnement :

L’accès à orange.com et emeraude.com est fonctionnel depuis le réseau COBALT.

Il faut choisir si l’ACL se positionne en entrée de R3 Gig0/0 ou en sortie de R3 Gig3/0 :

5. SCÉNARIO 5 : Accès restrictif aux services ORANGE

Le réseau ORANGE étant un datacenter sensible, il nous est demandé :

1. D’autoriser le protocole DNS destiné au serveur DNS (UDP/53).

4. Bloquer tous les autres accès depuis l’extérieur.

Vérifications à effectuer avant la mise en place du filtrage :

En invite de commande, il est possible d'utiliser le symbole « ? » à tout moment pour

Tests de bon fonctionnement :

La solution repose sur l'état TCP pour les requêtes TCP.

Plus précisément, voici comment cela fonctionne :

Voici la commande (à adapter à votre contexte !) :

On autorise tout flux TCP, pourvu que l’état soit « established ».

R2(conf)# access-list <id> permit tcp any any established

6. SCÉNARIO 6 : Modifications d’ACL

Ce scénario 6 offre l'opportunité d'étudier la modification d’ACL déjà en place, en y intégrant de

L'analyse du cahier des charges nous conduit à deux conclusions importantes :

Rappel : La commande « show access-lists » dans le menu « enable » permet de

Ce nombre de « matches » entre parenthèses indique combien de fois un flux a été en

Figure 1 - Configuration du client mail

Figure 2 - Vérification du bon fonctionnement

Tests de bon fonctionnement :

Vérifiez que le test depuis 192.192.1.2 vers emeraude.com est autorisé.

8. SCENRAIO 8 BONUS : Récriture

Vous aimerez peut-être aussi