L’objectif principal d’un ingénieur réseau est de rendre possible les communications TCP/IP entre différents systèmes. Seulement voilà, il ne faut pas oublier que ces échanges doivent pouvoir se faire en prenant en compte les problématiques de sécurité. Il s’agit alors d’un objectif supplémentaire (parfois implicite) assigné à l’ingénieur réseau: garantir la sécurisation des échanges. Cette sécurisation consiste dans un premier temps à autoriser certaines communications et en interdire d’autres. C’est à partir de là où notre ingénieur devra utiliser un outil intégré dans l’IOS: les listes de contrôle d’accès ou ACL (Access Control Lists). Cet article constitue une introduction aux concepts fondamentaux des ACLs…

Remarquons en premier lieu que les ACLs peuvent avoir des utilisations variées (comme pour la classification de flux dans un objectif de qualité de service). Mais cet article étant principalement destiné aux candidats à la certification CCNA, nous allons nous concentrer sur l’utilisation des ACLs pour le filtrage des paquets.

L’idée générale consiste à empêcher des communications entre systèmes en fonction des caractéristiques de ces communications. Par exemple: seule la machine d’administration a le droit de se connecter sur les équipements réseaux, ou bien encore, les clients ne peuvent accéder qu’à une groupe limité de serveurs. 

 

ACL: Les concepts fondamentaux

Lorsque l’on s’initie aux ACLs Cisco, il faut prendre en compte deux éléments complémentaires:

• la localisation précise où s’appliquent les règles de filtrage: sur quelle interface ? Pour les paquets qui entrent ou qui sortent?
• les spécifications techniques du trafic à autoriser ou interdire : il s’agit de définir les caractéristiques recherchées dans les paquets IP pour indiquer au routeur: ce paquet est autorisé ou non.

 Ces deux aspects correspondent aux deux étapes de configuration des ACLs dans l’interface de commande en ligne Cisco.

 

Point d’application de l’ACL

Une liste de contrôle d’accès peut être appliquée sur une interface donnée et pour un sens de communication donné (soit entrant, soit sortant, voire les deux). 

Ainsi, la configuration se fait en mode de configuration de l’interface et faisant référence à l’identifiant de l’ACL (un nom ou un numéro). C’est cet identifiant qui a été utilisé lors de la création ou de la définition de l’ACL.

Prenons un exemple. Dans les lignes de commandes ci-dessous, tous les paquets entrants (mot-clé in) sur l’interface FastEthernet 0/1 de l’équipements vont être filtrés en fonction des règles de l’ACL n°7

interface Fa0/1
 ip access-group 7 in

 

Attention à la limitation : une seule liste d’accès ne peut être associée à une interface donnée et par direction. Pour bien comprendre, quelques exemples valides et un exemple impossible sur l’IOS Cisco:

 

Si l’on rentre les commandes comme indiquées dans le cadre rouge ci-dessus, la ligne ip access-group 7 in serait remplacée par la dernière pour respecter la limitation énoncée.  Ainsi, si l’on souhaite appliquer l’ACL 7 ET l’ACL 3, il faudra créer une ACL supplémentaire de façon à ce qu’elle joue un rôle équivalent aux ACL 7 et 3… Il n’y a aucun autre moyen.

 

Spécifications du filtrage: Caractéristiques et Règle associée 

Lorsque l’on doit autoriser certains flux et en interdire d’autres, il faut techniquement commencer par identifier les caractéristiques des paquets qui vont permettre de distinguer un paquet entre ceux autorisés (on utilisera le mot clé permit) et ceux interdits (on utilisera le mot clé deny).

La définition d’une ACL se fait par plusieurs lignes de commandes successives où chaque ligne correspond à une entrée de la liste (Cisco utilise le terme de ACE pour Access Control Entry).

Chaque ligne d’une ACL (dans le contexte de l’IOS Cisco) se fait suivant le principe suivant:

access-list <ACL-id> [permit|deny] <caractéristique-techniques>

On remarquera qu’il n’y a pas de mode de configuration propre à l’ACL: chaque entrée de l’ACL se fait en mode de configuration globale. Le lien entre chaque entrée se fait seulement avec l’identifiant de l’ACL (j’ai noté ACL-id  dans la notation ci-dessus).

 

Voyons, pour l’exemple, la définition d’une ACL (identifié par le n°7)  qui autorise les flux à destination de Bob mais interdit les flux qui viennent de Alice. On aura une configuration qui va ressembler à cela (c’est du pseudo-code, pour aider à la compréhension: nous verrons la syntaxe exacte dans l’article suivant):

access-list 7 permit destination=Bob 
access-list 7 deny source=Alice

 

Comme déjà indiqué plus haut, une liste d’accès reste une simple succession de caractéristiques des attributs IP ou TCP/UDP avec, pour chaque caractéristique, une règle associée. Cette règle est binaire, c’est: soit « j’autorise » (permit), soit « j’interdit » (deny). 

 

ACL Cisco et Règles générales

Toujours en guide d’introduction, voyons deux règles fondamentales à maitriser lors de l’écriture des ACLs Cisco.

 

Analyse séquentielle

Une access-list est une liste de caractéristiques technique avec une règle associée (j’autorise ou j’interdit). Mais, l’ordre de création de la liste est importante car chaque paquet est analysé dans l’ordre de la liste. Lorsque le paquet analysé répond à une caractéristique, la règle est appliquée et le processus d’analyse est arrêté (on ne va pas plus loin pour voir si une règle est plus précise ou si une autre règle prévoit une action contraire!).

Revenons sur notre exemple (ACL 7 appliquée sur F0/1 en entrant):

access-list 7 permit destination=Bob   ! Règle 1
access-list 7 deny source=Alice        ! Règle 2

Ainsi, si le paquet entrant sur F0/1 est émis par Alice (source=Alice) et à destination de Bob (Destination de Bob), l’ACL va conduire à autoriser le paquet même s’il est émis par Alice! En effet, puisque le paquet à une destination=Bob, on applique la règle associée (ici, permit) et le routeur ne va pas plus loin dans l’analyse.

 

Par contre, si on inverse les deux règles:

access-list 7 deny source=Alice         ! Règle 2
access-list 7 permit destination=Bob    ! Règle 1

 

Alors, le même paquet qui rentre sur l’interface va être bloqué par le routeur. En effet, la première règle rencontrée respecte bien la caractéristique du paquet, donc le routeur applique les indications (deny) et arrête l’analyse… Il est donc important de définir la règle dans un ordre cohérent. Cette cohérence dépend directement de ce que l’on veut interdire et autoriser !

 

Règle par défaut

Considérons que l’on souhaite désormais empêcher les seules communications vers Bob. Pour cela, on va utiliser l’access-list n°7 comme suit:

access-list 7 deny destination=Bob    

Le problème, c’est que si le paquet ne satisfait pas la caractéristique explicite (ici adresse IP destination = Bob), alors le routeur va appliquer la règle par défaut qui consiste à interdire le paquet. En fait, tout se passe comme si toutes les ACLs se finissaient par:

access-list 7 deny N'Importe    (règle implicite)

Donc, si l’on veut corriger l’ACL pour que seules les communications vers Bob soient interdites, il faudra écrire l’ACL comme suit:

access-list 7 deny destination=Bob
access-list 7 permit N'Importe

Ainsi, soit la destination=Bob et le paquet est interdit conformément à la règle 1, sinon la règle 2 sera appliquée puisque les caractéristiques ne sont pas définies (peu importe les attributs, le paquet correspond aux caractérises définies). Et comme la règle 2 ne sera appliquée que si la règle 1 ne l’est pas (parce que les caractéristiques ne correspondent pas): l’objectif est atteint !

 

 

Différents Types d’ACLs

L’IOS propose différents types d’ACLs: standard, étendues, additionnelles, nommées, etc. 

Une ACL peut être indentifiée par un identifiant numéraire (ce sont les ACLs numbered) ou bien par un nom (on parle alors d’ACLs named). 

Initialement, les caractéristiques des paquets se limitaient aux seules adresses sources IP. C’est ce que Cisco appelle des ACLs standards. Et puis, Cisco a introduit la possibilité d’identifier des paquets en fonction de la source ou de la destination IP, des ports sources et/ou destination, etc.: ce sont des ACLs étendues.

 

—

Dans cette brève introduction aux ACLs, nous avons présenté le concept mais nous n’avons pas détaillé le détail de la définition d’une ACL, notamment pour définir les caractéristiques des paquets IP. C’est l’objet de l’article suivant, disponible en ligne sur iplogos.fr …

Pour tout commentaires ou questions, utilisez l’espace ci-dessous: je me ferai un plaisir de vous répondre !