ACL

Bonjour à tous, je suis ici aujourd’hui avec un nouveau sujet. Dans cet article, nous allons apprendre la logique de base des listes de contrôle d’accès avant de passer à leur configuration. Si vous êtes prêt, passons à notre sujet.

Les listes de contrôle d’accès (ACL) sont principalement utilisées à des fins de sécurité, pour contrôler l’accès et garantir la confidentialité au sein d’un environnement réseau. Permettez-moi d’illustrer leur importance par une expérience personnelle : à une époque où je n’avais que peu de connaissances en matière de réseaux, j’ai essayé d’établir une connexion SSH avec un ordinateur de mon bureau à l’aide de mon ordinateur personnel. La connexion a réussi et je me suis souvenu de l’adresse IP de l’ordinateur. Cependant, lorsque j’ai essayé d’établir la même connexion SSH depuis chez moi en utilisant la même adresse IP, j’ai rencontré un échec. Cela m’a laissé perplexe jusqu’à ce que je réalise que les listes de contrôle d’accès régissaient cet accès. En substance, les ACL nous permettent de réguler de tels scénarios. Elles servent à gérer l’accès et la confidentialité, en autorisant ou en refusant un trafic spécifique, en gérant la bande passante et en protégeant les ressources.

Les ACL peuvent être classées en deux types principaux : ACL standard et ACL étendue.

Maintenant, examinons leurs différences :

• ACL standard : ces ACL s’appuient uniquement sur l’adresse IPv4 source et fournissent un filtrage au niveau de la couche 3. Il s’agit d’un processus de filtrage simple. Par exemple, nous pouvons bloquer l’accès à notre appareil à partir d’adresses IP commençant par 192.168.10. Cependant, nous ne pouvons pas effectuer d’actions plus complexes. Nous ne pouvons pas, par exemple, spécifier que notre appareil doit communiquer avec l’appareil X, envoyer des fichiers ou des e-mails, mais restreindre uniquement certains types de données sur des ports spécifiques, comme empêcher les connexions SSH tout en autorisant d’autres communications.
• ACL étendues : en revanche, les ACL étendues permettent un filtrage basé à la fois sur les adresses source et de destination. De plus, elles offrent la possibilité de spécifier des restrictions nuancées, telles que le scénario susmentionné autorisant toutes les communications avec un périphérique à l’exception des connexions SSH, ce qui peut être réalisé en configurant les numéros de port appropriés. Une telle utilisation illustre les ACL étendues.

Lors de la gestion du trafic entrant dans une interface, nous désignons les listes de contrôle d’accès qui régissent les paquets entrants par le terme « listes de contrôle d’accès entrantes ». De même, les listes de contrôle d’accès qui gèrent le trafic sortant d’une interface sont appelées « listes de contrôle d’accès sortantes » .

Maintenant, discutons d’un autre concept lié aux ACL. Nous en avons largement parlé dans mes articles sur OSPF, je ne vais donc pas m’y attarder en détail, mais il vaut la peine de s’en souvenir : le masque générique !

Le masque générique est essentiellement similaire à un masque de sous-réseau. Par exemple, un réseau avec un masque de sous-réseau de 0.0.0.0 aurait un masque générique de 255.255.255.255. Lorsque nous représentons le masque de sous-réseau avec des bits, nous inversons les bits lorsqu’ils sont définis sur 1 et les laissons tels quels lorsqu’ils sont définis sur 0, ce qui donne le masque générique. Vous vous demandez peut-être pourquoi nous avons besoin d’un masque générique si le masque de sous-réseau semble suffisant, car il change simplement les 1 en 0 et vice versa. Cependant, il existe une différence petite mais cruciale avec le masque générique. Dans un masque de sous-réseau, une fois que nous rencontrons un 0 après des 1 consécutifs, les bits suivants doivent également être 0. Mais avec un masque générique, nous n’avons pas de telles restrictions. Nous pouvons faire des choses avec un masque générique que nous ne pouvons pas réaliser avec un masque de sous-réseau. Par exemple, un masque de sous-réseau ne peut pas effectuer une action spécifique pour des réseaux tels que 192.168.X.10 car pour ce faire, le masque de sous-réseau devrait être 255.255.0.255, mais un masque de sous-réseau ne peut pas contenir de 0 entre les deux ! Un masque générique nous permet d’accomplir cela.

Examinons maintenant le nombre maximal d’opérations ACL qu’une interface de routeur peut avoir.

Figure 1

Comme le montre la figure 1, une interface de routeur peut prendre en charge jusqu’à 4 processus ACL. Il s’agit d’ACL entrantes et sortantes distinctes pour IPv4 et IPv6. Cela s’applique à chaque interface de notre routeur. Elle peut prendre en charge jusqu’à 4 processus distincts. Par exemple, si nous avons 2 interfaces différentes, elles peuvent prendre en charge jusqu’à 8 processus au total. Renforçons cela avec l’exemple suivant :

Voyons maintenant les configurations des listes ACL standard et étendues. Je vais vous montrer un exemple simple et très général juste pour voir plus clairement la différence, et nous examinerons les détails dans un autre article.

Configuration de la liste de contrôle d’accès standard

Comme on peut le voir dans l’exemple ci-dessus, nous avons créé une liste d’accès avec le numéro 10. Nous pouvons remplacer ce numéro par n’importe quel autre ; cela n’a pas vraiment d’importance. Avec la commande « permit », nous spécifions les adresses IP que nous voulons autoriser. Dans l’exemple ci-dessus, nous autorisons l’accès à toutes les adresses IP commençant par 192.168.10. Nous savons que le masque générique que nous avons utilisé correspond à un masque de sous-réseau de 255.255.255.0. Cela signifie que nous autorisons l’accès à toutes les adresses IP commençant par 192.168.10.X, où X peut être n’importe quel nombre. Il s’agit d’un exemple d’ACL standard, où nous ne mentionnons pas les numéros de port et ne pouvons gérer que le trafic lié aux adresses sources. Dans cet exemple de configuration, nous n’avons pas de dispositions pour les paquets quittant notre système ; il se concentre sur la gestion des paquets entrants.

Configuration de la liste de contrôle d’accès étendue

Dans l’exemple ci-dessus, nous avons créé une liste d’accès numérotée 100. Cette commande définit une règle de liste de contrôle d’accès (ACL) qui autorise le trafic TCP provenant du réseau 192.168.10.0 et permet l’accès à n’importe quelle adresse IP ainsi qu’au service Web (HTTP) (port 80). Il est important de noter qu’en utilisant la commande « permit », nous autorisons l’accès uniquement aux appareils dont les adresses IP sont spécifiées, et uniquement via le port HTTP (port 80). Les autres méthodes d’accès ne sont pas affectées, mais seuls les appareils dont les adresses IP sont autorisées peuvent accéder à nous via le port 80.

Maintenant, abordons un autre aspect des ACL. Nous avons mentionné précédemment que nous avons attribué des numéros aux listes d’accès, mais nous pouvons également leur donner des noms au lieu de numéros. Cela permet d’éviter toute confusion. Par exemple, supposons que nous souhaitons bloquer les connexions SSH (port 22) pour certaines adresses IP à l’aide d’une adresse IP et d’un masque générique. Nous pouvons nommer cette règle quelque chose comme « SSH_DENY ».

Enfin, discutons de l’endroit où les configurations ACL doivent être appliquées.

Mise en place du LCA

Les listes de contrôle d’accès étendues doivent être proches de l’adresse source. Les listes de contrôle d’accès standard doivent être proches de l’adresse de destination. Mais pourquoi ? Parce que les listes de contrôle d’accès étendues sont plus complexes. Illustrons cette logique avec un scénario.

Dans le diagramme ci-dessus, empêchons le trafic SSH (port 22) du commutateur 1 vers le routeur 3. Nous voulons bloquer le port 80, qui est le service HTTP, du commutateur 2. Il serait difficile de configurer ces paramètres individuellement sur notre routeur car de nombreuses tâches sont impliquées. Imaginez que nous ne parlons que de 2 choses maintenant, mais pensez aux nombreuses autres tâches auxquelles nous pourrions être confrontés. Dans ce cas, configurer tout individuellement serait déroutant. Au lieu de cela, configurer ces paramètres sur le routeur 1 avant qu’ils ne nous parviennent allégerait notre charge. Les processus sont vraiment compliqués. Le commutateur 1 peut accéder à tout sauf à SSH, et le commutateur 2 peut accéder à tout sauf à HTTP. Il est important de gérer ces tâches aussi près que possible de la source. Examinons maintenant les ACL standard. Les choses ne sont pas compliquées ici ; elles peuvent être facilement gérées. Il n’y a pas de blocage de port spécifique, nous pouvons donc contrôler rapidement l’accès à proximité de la destination. Par exemple, si nous voulons rompre complètement les liens avec le commutateur 1, nous pouvons le faire rapidement. Il n’y a pas d’informations spécifiques ou de confusion, nous bloquons simplement tous les ports directement, c’est aussi simple que cela. Si nous essayions de faire cela près de la source, ce serait compliqué. Car nous devrions dire au commutateur 1 individuellement : « Vous ne pouvez pas aller ici, ce port ne peut pas aller ici, vous ne pouvez pas aller à cet endroit, c’est interdit… » et le trafic serait congestionné. Il est donc plus avantageux de procéder avec cette logique.