Finger in the net
Blog d'administration réseau
Generic selectors
Exact matches only
Search in title
Search in content
Created by potrace 1.10, written by Peter Selinger 2001-2011

Les Access-list (ACL) CISCO

Finger In The Net
Extrait : "Access-list = Liste d'accès ! Imaginez que vous organisez une soirée privée et que vous ne voulez pas donner l'accès à cette soirée à tout le monde ! Vous allez faire quoi ? - Créer une liste d'invitée. - Placer un agent de sécurité devant la porte avec votre liste."

C’est quoi une ACL ?

  • ACL = Access Control List
  • Access-list = Liste d’accès !

Pour mettre en place des ACL, il faut créer une access-list ET l’appliquer quelque part. Imaginez que vous organisez une soirée privée et que vous ne voulez pas donner l’accès à cette soirée à tout le monde ! Vous allez faire quoi ?

  • Créer une liste d’invitées.
  • Placer un agent de sécurité devant la porte avec votre liste.

Vous allez donner la consigne suivante à votre agent de sécurité :

Voici ta liste. Pour l’appliquer, rien de plus simple, tu regardes ligne par ligne !!!

Les Access-list (ACL) CISCO 1

  • Éric DUBOIS en BasketACCEPTÉ.
  • Homme seul en Costard + CravateACCEPTÉ.
  • Femme en BasketREFUSE.
  • L’équipe de Rugby en BasketREFUSÉ.
  • Homme seul en Chaussure de ville ? REFUSÉ.

Dans notre cas c’est exactement pareil ! on va

  • Créer une access-list.
  • Mettre cette access-list en place pour qu’elle puisse être active !

Ce cours va porter trois grands chapitres :

  • Création d’une Acess-list.
  • Ajouter des règles de flux.
  • Mise en place d’une access-list.
Chapitre 1

Création d'une Access-list

Il existe deux grandes familles d’access-list :

  • Standard (Standard) – Filltrage via l’adresse IP Source.
  • Extended (Étendue) – Filltrage via l’IP, le port, le protocole et pleins d’autres choses.

Sachant qu’il est possible de créer plusieurs access-list sur un même équipement, il va nous falloir les identités. Comment ?

  • Soit par des Nombres (Numbered).
  • Soit par des Noms (Named).

Il existe donc 4 types d’access-list :

  • Standard Numbered = Standard numéroté de 1 à 99 et de 1300 à 1999.
  • Extended Numbered = Étendue Numérotée. de 100 à 199 et de 2000 à 2699.
  • Standard Named = Standard Nommée.
  • Extented Named = Étendue nommée.
Différents type d'access-list
Différent type d’access-list

Créer une access-list

Comme nous l’avons vu plus haut, vous avez le choix entre 4 types d’access-list :

Access-list Standard Numbered

R1(config)# access-list <1-99> <1300-1999>
ou
R1(config)# ip access-list standard <1-99> <1300-1999>

A vous de choisir un numéro compris entre 1 à 99 ou de 1300 à 1999.

Access-list Standard Named

R1(config)# ip access-list standard [WORD]

Access-list Extended Numbered

R1(config)# access-list <100-199> <2000-2699>
ou
R1(config)# ip access-list extended <100-199> <2000-2699>

A vous de choisir un numéro compris entre 100 à 199 ou de 2000 à 2699.

Access-list Extended Named

R1(config)# ip access-list extended [WORD]

Quelle est la différence entre access-list et ip access-list ?

La réponse :

  • access-list est l’ancienne méthode.
  • ip access-list est la nouvelle méthode.

La commande access-list :

  • Oblige à spécifier le numéro de l’access-list à chaque fois que l’on rajoute une règle de filtrage.
  • Supporte que les access-list Numbered. (Numérotée).

Exemple :

R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255
R1(config)# access-list 1 permit host 192.168.2.1

La commande ip access-list :

  • Nous fais rentrer dans un sous-menu nous permettant de rajouter directement les règles de filtrage sans rappeler le numéro de l’access-list.
  • Supporte les access-list Numbered (Numérotée) et Named (Nommée).
  • Permet de rajouter des règles de filtrages entre deux lignes après avoir créé une access-list.

Exemple :

R1(config)# ip access-list standard ACL_LINE_VTY
R1(config-std-nacl)# permit 192.168.1.0 0.0.0.255
R1(config-std-nacl)# permit host 192.168.2.1

Conclusion :

  • Privilégiez les access-list Named : Un nom est plus parlant qu’un numéro.
  • Privilégiez les ip access-list : elles sont plus simples à gérer.
Chapitre 2

Les règles de flux d'une access-list

Created by potrace 1.10, written by Peter Selinger 2001-2011
Réservé aux membres
du site
Pour débloquer l'ensemble des cours de la plateforme
Chapitre 3

Configuration d'une access-list standard

Commençons par un petit exemple d’access-list standard :

ip access-list standard LINE_VTY
 remark ***** LAN Admin réseau *****
 permit 10.10.10.0 0.0.0.255
 remark ** Serveur de sauvegarde **
 permit host 10.10.20.1
 permit host 10.10.20.2
 remark *********** LOG ***********
 deny any log

De quoi est composée une règle de flux :

ip access-list standard LINE_VTY
 [Action] [Adresse IP Source]

Action

  • Permit (autorise le flux).
  • Deny (Drop le flux).
  • Remark (mets un commentaire).

Adresse IP

  • any (tout le monde)
  • host X.X.X.X (Adresse IP)
  • X.X.X.X 0.0.0.255 (Adresse réseau)
R1(config)# ip access-list standard LINE_VTY
R1(config-std-nacl)# permit ?
 
 A.B.C.D   Address to match        ! Une adresse réseau 
 any       Any source host         ! Tout le monde
 host      A single host address   ! Une adresse IP

Que se passe-t-il quand vous voulez matcher une adresse réseau ?

R1(config-std-nacl)# permit 192.168.10.0 ?
 
  A.B.C.D  Wildcard bits           ! Mettre le masque réseau en Wildcard

Il faut spécifier le Wildcard mask.

Hop-hop-hop-hop-hop-hop !!!! Wildcard mask ??? C’est quoi ça ?

Wildcard = Masque inversé.

  • Un masque de 255.255.255.0 nous donnera un wildcard de 0.0.0.255.
  • Un masque de 255.255.0.0 nous donnera un wildcard de 0.0.255.255.
  • Un masque de 255.0.0.0 nous donnera un wildcard de 0.255.255.255.

Comment j’ai fait ?

J’ai utilisé la formule suivante : Wildcard = 255 – Masque.

Mais pourquoi les wildcard ? à quoi ca sert ? nous n’aurions pas pu mettre simplement la valeur de notre masque ?

Pour répondre à cette question, je vous invite à jeter un coup d’oeil sur l’article Wildcard. Mais pas pour le moment …. Je vous conseille de bien maîtriser les access-list afin de comprendre la plus-value qu’apportent les Wildcard.

Created by potrace 1.10, written by Peter Selinger 2001-2011
Réservé aux membres
du site
Pour débloquer l'ensemble des cours de la plateforme
Chapitre 4

Configuration d'une access-list étendue

Created by potrace 1.10, written by Peter Selinger 2001-2011
Réservé aux membres
du site
Pour débloquer l'ensemble des cours de la plateforme
Chapitre 5

Configuration d'une access-list réflexive

Created by potrace 1.10, written by Peter Selinger 2001-2011
Réservé aux membres
du site
Pour débloquer l'ensemble des cours de la plateforme
Chapitre 6

Appliquer une ACL

Created by potrace 1.10, written by Peter Selinger 2001-2011
Réservé aux membres
du site
Pour débloquer l'ensemble des cours de la plateforme
Chapitre 7

Conclusion

Created by potrace 1.10, written by Peter Selinger 2001-2011
Réservé aux membres
du site
Pour débloquer l'ensemble des cours de la plateforme
Merci de votre attention

Sur le même thème

Merci de votre soutien et de votre fidélité ! Ce site existe grâce à vous et je ne vous remercierais jamais assez !

Noël NICOLAS

Expert Réseau
11 ans d’expérience
CCNP Routing and Switching
Fondateur du site FingerInTheNet

Comments (10)

Félicitations ! Quelques questions.

1 – Dans la section “ACL réflexive”, je suis un peu confus au sujet de ACL_DYN_CLT-SRV. Est-ce que cette ACL est crée automatiquement par l’IOS, à partir du moment où on spécifie “reflect” ?

2 – Ce que la conclusion dit “Une ACL se place toujours au plus près de la source”, ce n’est pas ce que j’avais appris sur les ACLs. J’avais appris que “l’ACL standard doit être très proche de la cible” et “l’ACL étendue doit être très proche de la source”.

3 – Une différence important entre l’ACL Standard et l’ACL est étendue est que l’ACL Standard ne peut être édité qu’en bloc (si on veut corriger l’ACL, il faut l’enlever au complet et la rééditer) ; alors que l’ACL Étendue permet d’éditer règle par règle, en utilisant des numéros de règle.

4 – Ça serait utile d’ajouter les précisions suivantes :

– Quand un paquet est reçu sur le port, les règles sont évaluées du haut ver le bas.
– Dès que le paquet match une règle de l’ACL, l’évaluation des règles s’arrête.
– À la fin de toutes les règles, le “deny all” est implicite.

Salut KayouMT !

J’ai enfin fini de mettre à jour cet article 🙂

Pour répondre à tes questions :

1 –

– Dès qu’un flux est matché par notre access-list ACL_CLIENTS_VERS_SERVEUR, une règle de filtrage temporaire autorisant la réponse à cette requête vas être créer de manière dynamique dans l’ACL_SERVEUR_VERS_CLIENTS.

– Lorsque la réponse à la requête est passé par l’access-list reflexive, cette règle de flux sera supprimée.

2 – J’ai dit en conclusion qu’une access-list ce met au plus près de la source car cela évite que des paquets non autorisé ne soit routé et circule pour rien ! Après cela dépend du contexte. Je pense qu’il est difficile de sortir des règles de bonne usage des ACL. Pour les access-list standard, on va souvent les utiliser pour les line VTY, le SNMP et pleins d’autres !! Elles représentent vraiment un dernier rempart de sécurité ! Personnellement je vais en amont bloquer toutes les connexions SSH venant du WAN (Au plus proche de la source) et je vais mettre un dernier rempart de sécurité sur ma line VTY pour les demandes de connexion interne. Je n’ai pas envie que ces demandes de connexion traverse tout mon réseau pour rien 🙂

3 et 4 – J’ai rajouté tout ça dans l’article, effectivement c’est important de précisé ça 🙂

Encore merci à toi pour ta contribution et pour ton aide !

Merci beaucoup pour les réponses, Noel.

C’est OK pour 3 et 4. Sur 3, tu fais bien de me corriger. C’est “ip access-list” (et non l’ACL étendu) qui offre les avantages que j’ai cités.

Sur 1 ; il y a encore une petite confusion. ACL_CLIENTS_VERS_SERVEUR et ACL_SERVEUR_VERS_CLIENTS sont définis dans R1, mais sont configurés sur une interface de SW_D_01. À ma connaissance ; une ACL est locale à un routeur (ou une switch).

Sur 2 ; dans les livres de CCNA, les règles sont très claires. Ils disent pratiquement tous ce qui est dit dans le blog suivant : http://www.ccnablog.com/acls-access-control-lists-part-i/.

– For the extended type of ACLs, you should place them closest to the source of the traffic.

– Standard ACLs do not look at the destination address, therefore, you should place them closest to the destination network that you are filtering packets to.

C’est avec grand plaisir d’échanger avec quelqu’un d’aussi pointilleux que moi 🙂

– Pour la 1 (ACL reflexive) , tu as entièrement raison. Faute de frappe 🙂

– Pour la 2 …. Cela va peut être paraître choquant mais je ne suis pas tout à fait d’accord avec ce qui est dit. Je ne trouve pas pertinent de dire et faire apprendre cette règle aux gens car la mise en place d’une access-list se doit d’être intellect.

Petit cas de figure :

– J’ai un Switch ACCESS de niveau 2.
– Je décide que mon Vlan EQUIPEMENT_RESEAU est le Vlan 40.
– Je met l’adresse IP de mon switch sur l’interface vlan 40 de ce dernier.
– Toutes les autres interfaces Vlans (Clients / Serveurs / Voip / ect … ) sont sur mon coeur de réseau.

Je peux tout à fait filtrer les connexions SSH au niveau de mon coeur de réseau avec une acl étendu !!

Ce type de configuration est très courant .

Si on suis cette règle du CCNA, le fait de mettre une ACL standard sur les line VTY de nos équipements n’à aucune utilité … Pour moi il faut OBLIGATOIREMENT mettre une ACL sur les Line VTY ! Ça prend deux lignes dans la conf et rien en ressources physique en vue du trafic.

Je suis allé voir dans le CCNP SWITCH et ROUTE. Ils ne reprennent pas cette règles d’utilisation … Du moins je ne l’ai pas retrouvé.

Aujourd’hui les access-list standard ne sont utilisé uniquement pour les protocoles qui ne supporte pas les access-list étendu (Line VTY, SNMP ou autre …. De mémoire ils ne les supporte pas mais je ne mettrait pas ma main à coupé non plus … à vérifier ).

Dans ce cas , ma phrase « Une ACL se place toujours au plus près de la source » est encore moins valable ….

Je pourrais mettre un truc de ce style :

Une access-list prévu pour filtrer le flux de donnée (Data Plane) se place au plus près de la source et les access-list prévu pour protéger un service particulier présent dans la Management Plane se place directement sur le service à protéger. Le fait de filtrer le flux de donnée ne doit pas empêcher de sécurisé notre managment plane.

Mais j’ai peur de semer plus de troubles qu’autre chose … Qu’en pense tu ?

Le top ce serait de faire un article regroupant toutes les utilités que peut avoir une ACL :

– Pour la QOS
– Pour les Class-Map
– Pour le filtrage
et pleins d’autre !!

Salut Noel.

Je te remercie pour la correction du point 1. Je le testerai dans un lab, quand je vais avoir un peu plus de temps.

Concernant le point 2 ; je ne pense pas que ça soit une bonne idée que tu écrives un nouvel article pour ça. Il faut évidemment éviter “de semer plus de troubles”. En réalité, il n’y a pas de contradiction entre ce que tu dis et ce que le CCNA dit. C’est simplement que vous ne l’abordez pas sous le même angle. Toi, tu développes les différentes problématiques qu’on peut régler avec l’Étendu ou le Standard. Tandis que le CCNA a suggéré simplement l’emplacement idéal où placer l’ACL (selon que tu optes pour l’Étendu ou pour le Standard).

Si tu comptes développer un peu plus le sujet, tu pourrais t’inspirer du chapitre 35 du document suivant : https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf.pdf. Tu peux être plus précis que le document en séparant le sujet sur 4 articles :

– Introduction à ACL (article actuel)
– ACL pour sécuriser le Management Plane
– ACL pour sécuriser le Data Plane
– ACL pour sécuriser le Control Plane

Bonne continuation.

Re-Salut.

J’ajoute un point-5 et non des moins importants. Le schéma “Mise en évidence des ACL réflexive” aurait, selon moi, besoin de beaucoup d’améliorations.

L’enjeu ici, selon moi, ce n’est pas l’activation (ou la désactivation) du firewall sur le PC. L’enjeu c’est l’activation des Reply ICMP dans une Switch ou Routeur. De ce fait ; il est important que tu mettes le Routeur (ou le Switch) entre les deux PCs.

Pour exprimer la problématique de l’ACL réflexive, les deux PCs doivent être prêts à traiter des ICMP Request/Reply. Les exceptions doivent donc être mises en place, de facto, sur le Firewall des 2 PCs, pour laisser passer les ICMP Request/Reply.

L’enjeu selon moi est de montrer que pour que la Switch (ou le Routeur) envoie au PC1 un Reply, l’ACL Réflexive doit être activée.

Ça serait aussi utile de faire deux schémas séparés :

– Avant l’activation de l’.ACL réflexive.
– Après l’activation de l’.ACL réflexive.

Je crois que type d’ACL est surtout pertinent pour des équipements comme ASA (Adaptive Security Appliance). Je présume que pour ce type d’équipements, il y une “ACL implicite” qui bloque certains protocoles ? Il faut donc demander une exception, en activant l’ACL Réflexive.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

17 − 15 =

Ebook - Guide de configuration CISCO

Réservé aux abonnées

Spécial abonnée

La boutique
des geeks

1 mois d'abonnement offert pour chaque commande !

Offre de lancement

Les nouveautés du
mois de janvier 2O22

1 mois d'abonnement offert pour chaque commande !

Offre de lancement