Configurer les listes de contrôle d'accès IP couramment utilisées - Cisco

Introduction

Ce document fournit des exemples de configurations pour les listes de contrôle d’accès (ACL) IP couramment utilisées, qui filtrent les paquets IP en fonction de :

Adresse source
Adresse de destination
Type de paquet
Toute combinaison de ces éléments

Afin de filtrer le trafic réseau, les ACL contrôlent si les paquets acheminés sont transmis ou bloqués à l’interface du routeur. Votre routeur examine chaque paquet afin de déterminer s’il doit être transmis ou abandonné en fonction des critères que vous spécifiez dans la LCA. Les critères de l’ACL comprennent :

Adresse source du trafic
Adresse de destination du trafic
Protocole de couche supérieure

Complétez ces étapes afin de construire une ACL comme le montrent les exemples de ce document :

Créer une ACL.
Appliquer l’ACL à une interface.

L’ACL IP est une collection séquentielle de conditions d’autorisation et de refus qui s’appliquent à un paquet IP. Le routeur teste les paquets par rapport aux conditions de l’ACL, un par un.

La première correspondance détermine si le logiciel Cisco IOS® accepte ou rejette le paquet. Comme le logiciel Cisco IOS arrête de tester les conditions après la première correspondance, l’ordre des conditions est essentiel. Si aucune condition ne correspond, le routeur rejette le paquet en raison d’une clause implicite deny all.

Il s’agit d’exemples de listes de contrôle d’accès IP qui peuvent être configurées dans le logiciel Cisco IOS :

Les ACL standard
Les ACL étendues
Les ACL dynamiques (verrouillage et clé)
Les ACL à nom IP
Les ACL réflexives
Les ACL basées sur le temps qui utilisent des plages de temps
Les entrées d’ACL IP commentées
Les ACL basées sur le contexte
Les ACL basées sur le temps.ACL basées sur le contexte
Proxy d’authentification
Turbo ACL
Activités ACL distribuées basées sur le temps

Ce document traite de certaines ACL standard et étendues couramment utilisées. Reportez-vous à la section Configuration des listes d’accès IP pour plus d’informations sur les différents types de listes de contrôle d’accès pris en charge dans le logiciel Cisco IOS et sur la manière de configurer et de modifier les listes de contrôle d’accès.

Le format de la syntaxe de commande d’une liste de contrôle d’accès standard est access-list access-list-number {permit|deny}. {host|source source-wildcard|any}.

Les ACL standard comparent l’adresse source des paquets IP aux adresses configurées dans l’ACL afin de contrôler le trafic.

Les ACL étendues comparent les adresses source et destination des paquets IP aux adresses configurées dans l’ACL afin de contrôler le trafic. Vous pouvez également rendre les listes de contrôle d’accès étendues plus granulaires et les configurer pour filtrer le trafic selon des critères tels que :

Protocole
Numéro de port
Valeur de point de code de services différenciés (DSCP)
Valeur de précédence
État du bit de numéro de séquence de synchronisation (SYN)

Les formats de syntaxe de commande des listes de contrôle d’accès étendues sont :

access-list access-list-number ]{deny | permit} protocol source source-wildcard destination destination-wildcard

Protocole de message de contrôle Internet (ICMP)

access-list access-list-number ] {deny | permit} icmp source source-wildcard destination destination-wildcard
 | ]

Protocole de contrôle de transport (TCP)

access-list access-list-number ] {deny | permit} tcp source source-wildcard ] destination destination-wildcard ]

access-list access-list-number ] {deny | permit} udp source source-wildcard ] destination destination-wildcard ]

Prérequis

Exigences

Vérifiez que vous remplissez cette exigence avant de tenter cette configuration :

Compréhension de base de l’adressage IP

Référez-vous à la section Adressage et sous-numérotation IP pour les nouveaux utilisateurs pour des informations supplémentaires.

Composants utilisés

Ce document n’est pas limité à des versions logicielles et matérielles spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d’un environnement de laboratoire spécifique. Tous les appareils utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en direct, assurez-vous de comprendre l’impact potentiel de toute commande.

Configurer

Ces exemples de configuration utilisent les ACL IP les plus courantes.

Autoriser un hôte sélectionné à accéder au réseau

Cette figure montre un hôte sélectionné auquel on accorde la permission d’accéder au réseau. Tout le trafic provenant de l’hôte B destiné à NetA est autorisé, et tout autre trafic provenant de NetB destiné à NetA est refusé.

La sortie sur la table R1 montre comment le réseau accorde l’accès à l’hôte. Cette sortie montre que :

La configuration autorise uniquement l’hôte avec l’adresse IP 192.168.10.1 à travers l’interface Ethernet 0 sur R1.
Cet hôte a accès aux services IP de NetA.
Aucun autre hôte de NetB n’a accès à NetA.
Aucune instruction deny n’est configurée dans l’ACL.

Par défaut, il y a une clause implicite deny all à la fin de chaque ACL. Tout ce qui n’est pas explicitement autorisé est refusé.

hostname R1!interface ethernet0 ip access-group 1 in!access-list 1 permit host 192.168.10.1

Note : L’ACL filtre les paquets IP de NetB vers NetA, à l’exception des paquets provenant de NetB. Les paquets provenant de l’hôte B vers NetA sont toujours autorisés.

Note : L’ACL access-list 1 permit 192.168.10.1 0.0.0.0 est une autre façon de configurer la même règle.

Défendre un hôte sélectionné pour accéder au réseau

Cette figure montre que le trafic provenant de l’hôte B destiné à NetA est refusé, tandis que tout autre trafic provenant de NetB pour accéder à NetA est autorisé.

Cette configuration refuse tous les paquets provenant de l’hôte 192.168.10.1/32 via Ethernet 0 sur R1 et autorise tout le reste. Vous devez utiliser la commande access list 1 permit any pour autoriser explicitement tout le reste car il existe une clause implicite deny all avec chaque ACL.

hostname R1!interface ethernet0 ip access-group 1 in!access-list 1 deny host 192.168.10.1access-list 1 permit any

Note : L’ordre des déclarations est critique pour le fonctionnement d’une ACL. Si l’ordre des entrées est inversé comme le montre cette commande, la première ligne correspond à chaque adresse source de paquet. Par conséquent, la LCA ne parvient pas à bloquer l’hôte 192.168.10.1/32 d’accéder à NetA.

access-list 1 permit anyaccess-list 1 deny host 192.168.10.1

Autoriser l’accès à une plage d’adresses IP contiguës

Cette figure montre que tous les hôtes de NetB avec l’adresse réseau 192.168.10.0/24 peuvent accéder au réseau 192.168.200.0/24 dans NetA.

Cette configuration permet aux paquets IP avec un en-tête IP qui a une adresse source dans le réseau 192.168.10.0/24 et une adresse destination dans le réseau 192.168.200.0/24 d’accéder à NetA. Il y a la clause implicite deny all à la fin de l’ACL qui refuse le passage de tout autre trafic par Ethernet 0 en entrée sur R1.

hostname R1!interface ethernet0 ip access-group 101 in!access-list 101 permit ip 192.168.10.0 0.0.0.255 192.168.200.0 0.0.0.255

Note : Dans la commande access-list 101 permit ip 192.168.10.0 0.0.0.255 192.168.200.0.0.0.255, le « 0.0.0.255 » est le masque inverse du réseau 192.168.10.0 avec le masque 255.255.255.0. Les ACL utilisent le masque inverse pour savoir combien de bits de l’adresse réseau doivent correspondre. Dans le tableau, l’ACL autorise tous les hôtes dont l’adresse source se trouve dans le réseau 192.168.10.0/24 et l’adresse de destination dans le réseau 192.168.200.0/24.

Référez-vous à la section Masques de la section Configuration des listes d’accès IP pour plus d’informations sur le masque d’une adresse réseau et sur la façon de calculer le masque inverse nécessaire aux ACL.

Deny Telnet Traffic (TCP, Port 23)

Pour répondre à des préoccupations de sécurité plus élevées, vous pourriez avoir à désactiver l’accès Telnet à votre réseau privé depuis le réseau public. Cette figure montre comment le trafic Telnet de NetB (public) destiné à NetA (privé) est refusé, ce qui permet à NetA de lancer et d’établir une session Telnet avec NetB alors que tout autre trafic IP est autorisé.

Telnet utilise TCP, port 23. Cette configuration montre que tout le trafic TCP destiné à NetA pour le port 23 est bloqué, et que tout autre trafic IP est autorisé.

hostname R1!interface ethernet0 ip access-group 102 in!access-list 102 deny tcp any any eq 23access-list 102 permit ip any any

Autoriser uniquement les réseaux internes à initier une session TCP

Cette figure montre que le trafic TCP provenant de NetA destiné à NetB est autorisé, tandis que le trafic TCP de NetB destiné à NetA est refusé.

Le but de l’ACL dans cet exemple est de :

Autoriser les hôtes de NetA à initier et établir une session TCP vers les hôtes de NetB.
Interdire aux hôtes de NetB d’initier et d’établir une session TCP destinée aux hôtes de NetA.

Cette configuration permet à un datagramme de passer par l’interface Ethernet 0 entrante sur R1 lorsque le datagramme a :

des bits d’accusé de réception (ACK) ou de réinitialisation (RST) activés (indiquant une session TCP établie)
Une valeur de port de destination supérieure à 1023

hostname R1!interface ethernet0 ip access-group 102 in!access-list 102 permit tcp any any gt 1023 established

Puisque la plupart des ports bien connus des services IP utilisent des valeurs inférieures à 1023, tout datagramme avec un port de destination inférieur à 1023 ou un bit ACK/RST non activé est refusé par l’ACL 102. Par conséquent, lorsqu’un hôte de NetB initie une connexion TCP en envoyant le premier paquet TCP (sans bit de synchronisation/départ de paquet (SYN/RST) activé) pour un numéro de port inférieur à 1023, il est refusé et la session TCP échoue. Les sessions TCP initiées depuis NetA à destination de NetB sont autorisées car elles ont le bit ACK/RST activé pour le retour des paquets et utilisent des valeurs de port supérieures à 1023.

Référer à la RFC 1700 pour une liste complète des ports.

Deny FTP Traffic (TCP, Port 21)

Cette figure montre que le trafic FTP (TCP, port 21) et de données FTP (port 20 ) provenant de NetB et destiné à NetA est refusé, alors que tout autre trafic IP est autorisé.

FTP utilise le port 21 et le port 20. Le trafic TCP destiné au port 21 et au port 20 est refusé et tout le reste est explicitement autorisé.

hostname R1!interface ethernet0 ip access-group 102 in!access-list 102 deny tcp any any eq ftpaccess-list 102 deny tcp any any eq ftp-dataaccess-list 102 permit ip any any

Autoriser le trafic FTP (FTP actif)

FTP peut fonctionner dans deux modes différents nommés actif et passif. Reportez-vous à la section Fonctionnement de FTP pour comprendre le fonctionnement du FTP actif et passif.

Lorsque FTP fonctionne en mode actif, le serveur FTP utilise le port 21 pour le contrôle et le port 20 pour les données. Le serveur FTP (192.168.1.100) est situé sur NetA. Cette figure montre que le trafic FTP (TCP, port 21) et de données FTP (port 20 ) provenant de NetB et destiné au serveur FTP (192.168.1.100) est autorisé, tandis que tout autre trafic IP est refusé.

hostname R1!interface ethernet0 ip access-group 102 in!access-list 102 permit tcp any host 192.168.1.100 eq ftpaccess-list 102 permit tcp any host 192.168.1.100 eq ftp-data established!interface ethernet1 ip access-group 110 in!access-list 110 permit host 192.168.1.100 eq ftp any establishedaccess-list 110 permit host 192.168.1.100 eq ftp-data any

Autoriser le trafic FTP (FTP passif)

FTP peut fonctionner dans deux modes différents nommés actif et passif. Reportez-vous à la section Fonctionnement du FTP afin de comprendre le fonctionnement du FTP actif et passif.

Lorsque le FTP fonctionne en mode passif, le serveur FTP utilise le port 21 pour le contrôle et les ports dynamiques supérieurs ou égaux à 1024 pour les données. Le serveur FTP (192.168.1.100) est situé dans NetA. Cette figure montre que le trafic FTP (TCP, port 21) et les données FTP (ports supérieurs ou égaux à 1024) provenant de NetB et destiné au serveur FTP (192.168.1.100) sont autorisés, tandis que tout autre trafic IP est refusé.

hostname R1!interface ethernet0 ip access-group 102 in!access-list 102 permit tcp any host 192.168.1.100 eq ftpaccess-list 102 permit tcp any host 192.168.1.100 gt 1023!interface ethernet1 ip access-group 110 in!access-list 110 permit host 192.168.1.100 eq ftp any establishedaccess-list 110 permit host 192.168.1.100 gt 1023 any established

Autoriser les pings (ICMP)

Cette figure montre que les ICMP provenant de NetA et destinés à NetB sont autorisés, et que les pings provenant de NetB et destinés à NetA sont refusés.

Cette configuration autorise uniquement les paquets echo-reply (réponse ping) à entrer sur l’interface Ethernet 0 depuis NetB vers NetA. Cependant, la configuration bloque tous les paquets ICMP echo-request lorsque les pings proviennent de NetB et sont destinés à NetA. Par conséquent, les hôtes de NetA peuvent envoyer des pings aux hôtes de NetB, mais les hôtes de NetB ne peuvent pas envoyer de pings aux hôtes de NetA.

hostname R1!interface ethernet0 ip access-group 102 in!access-list 102 permit icmp any any echo-reply

Autoriser HTTP, Telnet, Mail, POP3, FTP

Cette figure montre que seuls les trafics HTTP, Telnet, Simple Mail Transfer Protocol (SMTP), POP3 et FTP sont autorisés, et que le reste du trafic provenant de NetB et destiné à NetA est refusé.

Cette configuration autorise le trafic TCP dont les valeurs de port de destination correspondent à WWW (port 80), Telnet (port 23), SMTP (port 25), POP3 (port 110), FTP (port 21) ou données FTP (port 20). Remarquez qu’une clause implicite deny all à la fin d’une ACL refuse tout autre trafic, qui ne correspond pas aux clauses de permission.

hostname R1!interface ethernet0 ip access-group 102 in!access-list 102 permit tcp any any eq wwwaccess-list 102 permit tcp any any eq telnetaccess-list 102 permit tcp any any eq smtpaccess-list 102 permit tcp any any eq pop3access-list 102 permit tcp any any eq 21access-list 102 permit tcp any any eq 20

Autoriser DNS

Cette figure montre que seul le trafic du système de nom de domaine (DNS) est autorisé, et que le reste du trafic provenant de NetB destiné à NetA est refusé.

Cette configuration autorise le trafic TCP avec la valeur de port de destination 53. La clause implicite deny all à la fin d’une ACL refuse tout autre trafic, qui ne correspond pas aux clauses de permission.

hostname R1!interface ethernet0 ip access-group 102 in!access-list 102 permit udp any any eq domain access-list 102 permit udp any eq domain anyaccess-list 102 permit tcp any any eq domain access-list 102 permit tcp any eq domain any

Permettre les mises à jour de routage

Lorsque vous appliquez une ACL in-bound sur à une interface, assurez-vous que les mises à jour de routage ne sont pas filtrées. Utilisez l’ACL pertinente de cette liste pour autoriser les paquets de protocole de routage :

Entrez cette commande afin d’autoriser le protocole d’information de routage (RIP) :

access-list 102 permit udp any any eq rip

Entrez cette commande afin d’autoriser le protocole de routage de passerelle intérieure (IGRP):

access-list 102 permit igrp any any

Entrez cette commande afin d’autoriser l’IGRP amélioré (EIGRP) :

access-list 102 permit eigrp any any

Entrez cette commande afin d’autoriser Open Shortest Path First (OSPF):

access-list 102 permit ospf any any

Entrez cette commande afin d’autoriser Border Gateway Protocol (BGP) :

access-list 102 permit tcp any any eq 179 access-list 102 permit tcp any eq 179 any

Déboguer le trafic en fonction de l’ACL

L’utilisation des commandes de débogage nécessite l’allocation de ressources système comme la mémoire et la puissance de traitement et, dans des situations extrêmes, peut provoquer le blocage d’un système fortement chargé. Utilisez les commandes de débogage avec précaution. Utilisez une ACL afin de définir de manière sélective le trafic qui doit être examiné pour réduire l’impact de la commandedebug. Une telle configuration ne filtre aucun paquet.

Cette configuration active la commande debug ip packet uniquement pour les paquets entre les hôtes 10.1.1.1 et 172.16.1.1.

R1(config)#access-list 199 permit tcp host 10.1.1.1 host 172.16.1.1R1(config)#access-list 199 permit tcp host 172.16.1.1 host 10.1.1.1R1(config)#end
R1#debug ip packet 199 detailIP packet debugging is on (detailed) for access list 199

Référez-vous à Informations importantes sur les commandes de débogage pour obtenir des informations supplémentaires sur l’impact des commandes de débogage.

Référez-vous à la section Utiliser la commande de débogage de Comprendre les commandes Ping et Traceroute pour des informations supplémentaires sur l’utilisation des ACL avec les commandes de débogage.

Filtrage des adresses MAC

Vous pouvez filtrer les trames avec une adresse source ou de destination de station de couche MAC particulière. Un nombre quelconque d’adresses peut être configuré dans le système sans pénalité de performance. Afin de filtrer par adresse de couche MAC, utilisez cette commande en mode de configuration globale :

Router#config terminal bridge irb bridge 1 protocol ieee bridge 1 route ip

Appliquez le protocole de pont à une interface dont vous avez besoin pour filtrer le trafic avec la liste d’accès créée :

Router#config terminal
int fa0/0 no ip address bridge-group 1 {input-address-list 700 | output-address-list 700} exit

Créer une interface virtuelle pontée et appliquer l’adresse IP qui est attribuée à l’interface Ethernet :

Router#config terminal
int bvi1 ip address exit ! ! access-list 700 deny <mac address> 0000.0000.0000 access-list 700 permit 0000.0000.0000 ffff.ffff.ffff

Avec cette configuration, le routeur autorise uniquement les adresses MAC configurées sur la liste d’accès 700. Avec la liste d’accès, refusez l’adresse MAC qui ne peut pas avoir accès, puis autorisez le reste.

Note : Créez chaque ligne de liste d’accès pour chaque adresse MAC.

Vérifier

Il n’y a actuellement aucune procédure de vérification disponible pour cette configuration.

Dépannage

Il n’y a actuellement aucune information de dépannage spécifique disponible pour cette configuration.

Configurer les listes de contrôle d’accès IP couramment utilisées