Lorsque vous quittez votre maison le matin, vous fermez (probablement) les portes derrière vous. Dans un scénario normal, seules les personnes qui ont les clés pour déverrouiller votre porte devraient avoir accès à votre maison. Nous faisons cela pour des raisons de sécurité. De la même manière, nous pouvons vouloir contrôler qui/quoi a accès à différentes parties de notre réseau et l’une des façons de le faire est d’utiliser des listes de contrôle d’accès (ACL).
Dans cet article, nous allons faire une plongée en profondeur dans les ACL applicables au contrôle d’accès au réseau. Nous examinerons la structure d’une ACL, la façon dont les ACL sont traitées, et aussi la façon d’appliquer les ACL configurées. De plus, pour rendre cet article aussi pratique que possible, nous allons considérer une étude de cas où nous configurons des ACL sur un appareil Cisco IOS. Les connaissances de cette étude de cas peuvent être appliquées sur des appareils d’autres fournisseurs.
Note : Les ACL ne sont pas seulement utiles à des fins de filtrage ; elles trouvent également une application dans d’autres domaines comme la configuration de la traduction d’adresses réseau (NAT), la correspondance entre les routes à annoncer/accepter dans les protocoles de routage dynamique, le routage basé sur des politiques, et bien d’autres encore. En outre, les ACL ne sont pas limitées au réseau car elles sont également utilisées dans d’autres systèmes tels que les systèmes de fichiers pour contrôler l’accès aux fichiers/objets.
Listes de contrôle d’accès
Qu’est-ce qu’une liste de contrôle d’accès ?
Comme le dit l’expression, une liste de contrôle d’accès (ACL) est une liste qui contrôle l’accès. Cela signifie que, lorsqu’elles sont utilisées pour le contrôle d’accès au réseau, les ACL déterminent quels hôtes sont autorisés (ou non) à accéder à d’autres périphériques/destinations. Cela se fait généralement sur une base par paquet, ce qui signifie que chaque paquet est vérifié par rapport à l’ACL pour déterminer s’il faut autoriser ou refuser ce paquet.
Note : Les ACL peuvent être utilisées pour vérifier différents champs dans un paquet, notamment la couche 2 (par exemple les adresses MAC), la couche 3 (par exemple les adresses IPv4), la couche 4 (par exemple le numéro de port TCP), etc. Dans cet article, nous limiterons notre discussion à la couche 3+. En outre, la plupart des ACL sont considérées comme » sans état « , ce qui signifie que chaque paquet d’un flux est considéré seul, contrairement au filtrage avec état qui garde la trace de l’état d’une connexion.
Structure des ACL
Comme nous l’avons déjà dit, une ACL est une liste, ce qui signifie que c’est une liste de quelque chose. En termes techniques, nous disons qu’une ACL est une liste d’entrées de contrôle d’accès (ACE), chaque entrée contenant des critères de correspondance pour un paquet particulier.
Sur la base de cette description, une ACL peut être décomposée en deux parties principales :
- Identification de l’ACL qui est généralement un nom ou un numéro. Comme nous le verrons plus tard, les ACL peuvent également être identifiées par leur type.
- Un nombre d’entrées de contrôle d’accès qui sont généralement identifiées par des numéros séquentiels.
Entrées de contrôle d’accès (ACE)
Les ACE constituent la majeure partie d’une ACL, chaque ACL contenant une à autant d’entrées autorisées par un périphérique particulier. Sans prêter attention au type spécifique d’une ACL, une ACE est composée des éléments suivants :
- Une identification qui est généralement un numéro de ligne. Par exemple, la première ACE de l’ACL configurée sur un routeur Cisco IOS a un numéro de ligne de 10 par défaut ; la suivante a un numéro de ligne de 20 ; et ainsi de suite.
- Une action à effectuer pour un paquet qui correspond à l’entrée. Généralement, il s’agit de « permit » ou « deny ».
- Dans certains cas, les informations de protocole et de port à faire correspondre dans un paquet. Par exemple, un ACE peut correspondre à tout le trafic IP tandis qu’un autre ACE ne correspond qu’au trafic HTTP.
- La source à mettre en correspondance. Il s’agit généralement de l’adresse (IP) de la source du paquet. Il peut s’agir d’une adresse unique, d’une plage d’adresses, d’un sous-réseau ou même de n’importe quelle adresse.
- La destination à mettre en correspondance. Il s’agit généralement de l’adresse (IP) de la destination du paquet. Il peut s’agir d’une adresse unique, d’une plage d’adresses, d’un sous-réseau, ou même de n’importe quelle adresse.
Ne perdez pas de vue que les composants source et destination des ACE sont subjectifs, selon la direction du paquet. Considérez le diagramme ci-dessous :
Il existe deux scénarios que nous pouvons considérer du point de vue du routeur, R1 :
- Si PC1 initie une communication vers PC2 (par ex.g. ping de PC1 à PC2), la source du trafic est 192.168.1.100 tandis que la destination est 192.168.2.200.
- Si PC2 initie une communication vers PC1 (par exemple, ping de PC2 à PC1), la source du trafic est 192.168.2.200 tandis que la destination est 192.168.1.100.
Traitement des ACL
Lorsqu’un paquet est vérifié par rapport à une ACL, les règles de traitement suivantes s’appliquent :
- Les ACE d’une ACL sont vérifiées dans l’ordre de haut en bas. Cela signifie que l’ACE #10 sera vérifiée avant l’ACE #20.
- Si un paquet ne correspond pas à une ACE, il est vérifié par rapport à l’entrée suivante dans l’ACL.
- Si un paquet correspond à une ACE, les vérifications par rapport à l’ensemble de l’ACL s’arrêtent et l’action spécifiée sur l’ACE correspondante est appliquée au paquet.
- Si un paquet ne correspond à aucune entrée d’une ACL, la plupart des implémentations d’ACL refuseront/refuseront ce paquet car il existe une entrée de refus implicite à la fin de chaque ACL.
Prenons un exemple pour comprendre ces règles de traitement. Imaginons que nous ayons une ACL avec les entrées suivantes :
- Seq #1 : Permettre ICMP de 192.168.1.100 à 192.168.2.200
- Seq #2 : Refuser ICMP de toute source vers toute destination
- Seq #3 : Permettre le trafic HTTP de 192.168.1.100 vers toute destination
- Seq #4 : Autoriser le trafic HTTPS de 192.168.1.0/24 vers toute destination
Q1 : Qu’arrivera-t-il à un paquet ping de 192.168.1.100 à 192.168.2.200 ?
A1 : Comme le ping est basé sur ICMP, le paquet de 192.168.1.100 à 192.168.2.200 sera autorisé car il correspond à l’ACE avec la Seq #1.
Q2 : Qu’arrivera-t-il à un paquet ping de 192.168.1.50 à 192.168.2.200 ?
A2 : Le paquet sera vérifié par rapport à l’ACL en commençant par la Seq #1. Comme il ne correspond pas à cette entrée, l’entrée suivante (Seq #2) sera vérifiée. Cette entrée refuse ICMP de toute source vers toute destination. Puisqu’il s’agit d’un paquet ping (c’est-à-dire ICMP) et que la source est qualifiée de » any » et que la destination est également qualifiée de » any « , le paquet sera refusé.
Q3 : Qu’arrivera-t-il à un paquet HTTPS de 192.168.1.50 à 41.1.1.1 ?
A3 : Ce paquet ne correspondra pas aux trois premières entrées de l’ACL. Cependant, il correspondra à la 4e entrée parce que c’est un paquet HTTPS, avec une source qui est contenue dans le sous-réseau 192.168.1.0/24, et une destination qualifiée de « any ». Par conséquent, ce paquet sera autorisé.
Q4 : Que se passera-t-il pour un paquet HTTP de 192.168.1.50 à 41.1.1.1?
A4 : Ce paquet ne correspondra à aucune entrée dans cette ACL (seule 192.168.1.100 est autorisée à envoyer du trafic HTTP). Par conséquent, il sera refusé en supposant que la règle « implicit deny » s’applique à cette ACL.
Application des ACL
De même qu’il est inefficace d’installer un verrou sur votre porte et de quitter la maison sans verrouiller la porte, configurer des ACL sans les appliquer est également inutile. Lorsqu’elles sont utilisées pour le contrôle/filtrage d’accès au réseau, les ACL sont généralement appliquées sur les interfaces des périphériques, des périphériques tels que les routeurs, les commutateurs multicouches, les pare-feu, etc.
Généralement, une ACL peut être appliquée dans deux directions sur une interface :
- Entrée : Cela s’applique aux paquets entrant dans l’interface
- Sortie : Cela s’applique aux paquets sortant de l’interface
Parce que comprendre dans quel sens appliquer les ACL peut être difficile, prenons un exemple. Dans l’image ci-dessous, PC1 est connecté à l’interface Fa0/0 de R1 tandis que PC2 est connecté à l’interface Fa0/1 de R1.
Maintenant, imaginez que nous voulons appliquer une ACL sur R1 de telle sorte que seul le trafic ping (ICMP) de PC1 à PC2 soit autorisé ; où pouvons-nous appliquer cette ACL ?
- Premièrement, nous pouvons appliquer cette ACL sur l’interface Fa0/0 dans la direction entrante. Ceci parce que le trafic ping de PC1 à PC2 arrivera dans R1 depuis son interface Fa0/0.
- Alternativement, nous pouvons appliquer cette ACL sur l’interface Fa0/1 dans la direction sortante. C’est parce que le trafic ping de PC1 à PC2 sortira de R1 par son interface Fa0/1.
Introduction : Quelque chose que j’ai appris il y a quelque temps et qui peut aider à la compréhension des directions ACL est de vous imaginer comme un routeur. Levez-vous et tendez vos bras le long de votre corps comme si vous formiez une croix : le trafic entrant de vos doigts dans votre corps est entrant tandis que le trafic allant de votre corps à vos doigts est sortant.
Étude de cas : ACL sur les appareils Cisco IOS
Sur les appareils Cisco IOS, il existe deux types d’ACL (au minimum) :
- Les ACL standard qui correspondent uniquement à l’adresse source
- Les ACL étendues qui peuvent correspondre à une combinaison de protocoles, d’adresses source/destination, de ports source/destination, d’options, etc.
Note : Cisco dispose d’autres types de listes de contrôle d’accès telles que les listes de contrôle d’accès basées sur le temps, les listes de contrôle d’accès réflexives, les listes de contrôle d’accès dynamiques, etc. Cependant, ceux-ci dépassent le cadre de cet article.
Quel que soit le type, les ACL sur les appareils Cisco IOS peuvent être nommées (par exemple, « TESTACL ») ou numérotées (par exemple, 100). Notez que si vous utilisez des ACL numérotées, il existe des plages de numéros particulières pour les ACL standard et étendues.
Lorsque vous spécifiez les adresses de source et de destination sur une ACL dans la configuration de Cisco IOS, vous utilisez quelque chose appelé un Masque également connu sous le nom de masque inverse ou de masque Wildcard. Au niveau de base, le masque de remplacement est simplement le masque de sous-réseau inversé, c’est-à-dire que les 1 deviennent 0 et les 0 deviennent 1. Par exemple, le masque joker correspondant au masque de sous-réseau 255.255.255.0 est 0.0.0.255.
Pour le masque joker, 0 signifie « doit correspondre » tandis que 1 est un bit « indifférent ». Par exemple, un réseau 10.1.1.0 avec un masque de remplacement de 0.0.0.3 correspondra au trafic des adresses IP 10.1.1.1 jusqu’à 10.1.1.3.
Note : Il correspondra également à 10.1.1.0 mais comme il s’agit d’une adresse réseau, ce n’est pas une adresse source valide sur un paquet.
Utilisons la configuration de laboratoire suivante pour notre étude de cas :
Vous pouvez construire cette topologie dans GNS3 ou Packet Tracer. Les adresses IP ont été configurées sur toutes les interfaces et EIGRP fonctionne sur le réseau de sorte qu’il y a une connectivité entre tous les périphériques :
R1 :
R2 :
R3 :
Pour tester la connectivité, je vais pinger R3 à partir des interfaces de bouclage de R2 :
Création de listes de contrôle d’accès sur Cisco IOS
Configurons maintenant une liste de contrôle d’accès sur R1 de sorte que les conditions suivantes soient remplies :
- Tout le trafic ICMP de 192.168.10.0/24 vers n’importe quelle destination doit être autorisé
- Tout autre trafic ICMP doit être refusé
- Tout le trafic IP de 192.168.20.0/24 à 192.168.30.0/24 doit être autorisé
- Les appareils du réseau 192.168.10.0/24 doivent pouvoir se connecter à l’hôte 192.168.30.1 en utilisant SSH ; Telnet devrait être refusé.
- Tout autre trafic devrait être refusé
Pour configurer une ACL sur un périphérique Cisco IOS, nous utilisons les étapes suivantes :
- Définir l’ACL en utilisant un nom ou un numéro. Gardez à l’esprit que les ACL nommées sont plus faciles à modifier. La commande pour configurer une ACL nommée est ip access-list <ACL name>
- Configurer les ACE sous l’ACL en utilisant la syntaxe de base : <protocol><source network><source wildcard mask><destination network><masque sauvage de destination><options>
- Aller sous l’interface nécessaire et appliquer l’ACL en utilisant la commande ip access-group <ACL name>
C’est pourquoi, la configuration pour réaliser cela sur R1 est la suivante :
ip access-list extended EXAMPLE_ACLpermit icmp 192.168.10.0 0.0.0.255 anydeny icmp any anypermit ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.1 eq 22!interface FastEthernet0/0ip access-group EXAMPLE_ACL in!
Il y a deux choses à noter à propos de cette configuration :
- J’ai configuré une ACL nommée « EXAMPLE_ACL ». Cette ACL est étendue car j’ai besoin de correspondre sur plusieurs champs.
- Nous pouvons utiliser le mot clé « any » pour correspondre à n’importe quelle adresse
- Nous pouvons utiliser le mot clé « host » pour correspondre à une seule adresse
- Nous pouvons spécifier un port à correspondre en utilisant des mots clés tels que « eq » qui signifie égal à, « gt » qui signifie supérieur à, et ainsi de suite.
- Je n’ai pas refusé explicitement tout autre trafic – la règle « implicit deny » à la fin de chaque ACL Cisco refusera tout trafic qui n’est pas mis en correspondance par cette ACL
- J’ai appliqué cette ACL dans le sens entrant sur l’interface Fa0/0. J’aurais également pu l’appliquer en sortie sur l’interface Fa0/1.
Vérification des ACL
Je peux visualiser la configuration et les statistiques des ACL à l’aide de la commande show ip access-lists ou show access-lists :
Notez la numérotation : elle commence à 10 et chaque nouvelle entrée est ajoutée sous l’entrée précédente. Je peux utiliser la commande show ip interface pour visualiser les ACL appliquées sur une interface :
Note : vous pouvez appliquer jusqu’à deux ACL sur une interface, une dans chaque direction.
Modification des ACL
Cependant, en appliquant cette ACL, j’ai créé un problème entre R1 et R2 :
La relation EIGRP a été interrompue car les paquets EIGRP sont refusés par la règle « implicit deny » à la fin de l’ACL. Nous devons résoudre ce problème en autorisant explicitement les paquets EIGRP dans notre ACL.
Avertissement : Vous devez être prudent lorsque vous modifiez une ACL car les nouveaux ACE sont ajoutés en bas de l’ACL (avant le deny implicite). Cependant, avec les ACL nommées, vous pouvez spécifier le numéro de ligne où vous voulez qu’une entrée soit placée.
Dans notre cas, l’endroit où nous ajoutons l’entrée pour autoriser le trafic EIGRP n’a pas d’importance puisqu’il n’y a pas d’autre entrée qui affecte ce trafic avant la règle de refus implicite. Cependant, juste pour voir comment ajouter des entrées à n’importe quelle ligne d’une ACL, ajoutons l’entrée « permit eigrp any any » à la ligne 5 de notre ACL :
Cool ! Notre relation EIGRP est de retour.
Tester les ACL
Nous pouvons maintenant aller de l’avant et tester notre ACL. Rappelez-vous que lorsque vous testez des ACL, vous ne devez pas seulement tester ce qui devrait fonctionner, mais aussi ce qui ne devrait PAS fonctionner.
Test 1 : le ping de 192.168.10.1 à 192.168.30.1 devrait être autorisé en raison de l’entrée de ligne 10 de l’ACL.
Nous pouvons vérifier les compteurs de notre ACL pour voir que ce trafic a été mis en correspondance avec l’ACL :
Test 2 : Ping de 192.168.20.1 à 192.168.30.1 devrait échouer en raison de l’entrée de ligne ACL 20.
Test 3 : Telnet et SSH de 192.168.20.1 à 192.168.30.1 devraient être autorisés en raison de l’entrée de ligne ACL 30.
Test 4 : SSH de 192.168.10.1 vers 192.168.30.1 devrait être autorisé en raison de l’entrée 40 de la ligne ACL.
Test 5 : Telnet de 192.168.10.1 à 192.168.30.1 devrait échouer à cause de la règle de refus implicite.
Nous pouvons vérifier les comptes sur l’ACL pour nous assurer que le trafic a réellement touché l’ACL :
Conseils utiles pour les ACL
Voici quelques conseils pour vous aider dans la mise en œuvre de votre ACL :
- Puisque la correspondance sur une ACL est arrêtée une fois qu’une entrée est mise en correspondance, mettez vos entrées les plus spécifiques en haut de l’ACL et les plus génériques en dessous.
Par exemple, si vous mettez l’entrée :deny icmp any any
avant l’entrée
permit icmp host 1.1.1.1 any
, le trafic ICMP provenant de l’hôte 1.1.1.1 hôte sera également refusé.
- Puisque les ACL sont recherchées de haut en bas, vous devriez mettre votre trafic le plus susceptible d’être apparié vers le haut de l’ACL. Cela réduira le temps de recherche et la consommation de ressources.
- Vous pouvez utiliser des remarques pour rendre vos ACL plus lisibles c’est-à-dire pour que vous puissiez comprendre ce que fait une entrée particulière et pourquoi elle est là.
- Dans la mesure du possible, appliquez une ACL aussi proche que possible de la source du trafic. Il n’y a aucun intérêt à ce que le trafic fasse tout le chemin à travers le réseau pour ensuite être refusé. Notez que cette astuce peut ne pas être applicable pour les ACL standard.
- Si vous pouvez vous le permettre, appliquez une ACL en entrée plutôt qu’en sortie. En effet, les paquets sont déjà traités (par exemple, la consultation de la table de routage) avant d’être vérifiés par une ACL sortante. Pourquoi gaspiller les ressources de traitement pour ensuite abandonner le trafic ? Bien sûr, il y a des moments où cela ne peut pas être évité.
Conclusion
Ceci nous amène à la fin de cet article où nous avons examiné les listes de contrôle d’accès en détail, en nous concentrant sur la façon dont elles sont utilisées pour le filtrage réseau. Nous avons vu que les ACL sont composées d’entrées de contrôle d’accès (ACE) qui autorisent ou refusent le trafic en fonction de certains critères.
Nous avons discuté des règles de traitement des ACL : de haut en bas ; arrêt dès qu’une correspondance est établie. Nous avons également examiné comment les ACL peuvent être appliquées à des interfaces dans le sens entrant ou sortant. Enfin, nous avons examiné une étude de cas sur l’implémentation des ACL sur les appareils Cisco IOS ainsi que des conseils utiles.
Il s’agit d’une étude de cas.
0 commentaire