• Aucun résultat trouvé

72 5.1 Positionnement de problème

L’application correcte des politiques de sécurité d'entreprise dans un environnement de réseau étendu est une tâche difficile pour les administrateurs réseau. Une grande partie de l'application de la politique de sécurité au niveau du réseau consiste à configurer les stratégies de classification des paquets en utilisant les listes de contrôle d’accès (ACL). Un dispositif de passerelle de trafic effectuant un filtrage peut déployer une ACL avec des milliers de règles. En raison des difficultés de langage de configuration ACL, les ACL de grandes tailles peuvent facilement devenir redondantes, incohérentes et difficile à optimiser ou même à comprendre. Ce problème est aggravé par des facteurs extrinsèques tels que le renouvellement des administrateurs, les changements mal planifiés et non structurés de la topologie. Avec plusieurs pare-feux de la topologie, toutes les ACL doivent être configurées de manière cohérente pour faire appliquer la politique de sécurité de l'entreprise.

Un ensemble d'algorithmes sont introduits pour détecter et supprimer les règles redondantes, découvrir et réparer des règles incohérentes et enfin fusionner les règles adjacentes et celles qui se chevauchent. Dans ce chapitre, nous proposons un nouvel algorithme pour optimiser et automatiser l'analyse de l’ACL, ce qui simplifie énormément la tâche de l'administrateur réseau pour implémenter et vérifier des politiques de sécurité de l'entreprise.

5.2 Concept d’optimisation d’une ACL et algorithme utilisé 5.2.1 Structure de données utilisée

Cette section décrit la structure des données fondamentales utilisée dans les algorithmes d'analyse ACL. Tout d'abord, une correspondance entre le type d'attribut d’ACE et la dimension des arbres à intervalle est dérivée. Les types d’attributs exacts disponibles dans une ACE sont à charge du fournisseur. Nous allons utiliser la liste d’accès étendue de Cisco à titre d'exemple. Une ACE dans une liste d'accès étendue fournit les types d'attributs suivants: adresse source, adresse de destination, le protocole et le numéro de port. Toutes les valeurs spécifiées dans chaque attribut forment un intervalle. La commande spéciale any peut être utilisée pour spécifier toutes les valeurs possibles pour un attribut. Soient ximin et ximax les valeurs minimales et maximales d'un intervalle de dimension i, et

D imin et D imax représentent respectivement les valeurs minimale et maximale possible de la dimension i. La correspondance peut être effectuée comme suit (voir tableau 3):

73

Une liste d'accès étendue de Cisco correspond à un nœud de l'arbre à intervalles avec 4 dimensions, avec D1 correspondant à l'adresse source, D2 correspondant à l'adresse de destination, D3 désigne le protocole et D4 et le numéro du port.

Plus formellement, soit V := {[ v1: v1’], …, [vn: vn’]} l'ensemble des valeurs d'attribut n dans une ACE. Un nœud d’arbre multidimensionnel à intervalle correspondant est construit comme suit:

X := {[x1min=v1:x1max=v1’], …, [xnmin = vn: xnmax = vn’]}

La valeur de l'attribut spécial any est toujours associée à l’intervalle [D imin : D imax]. Grâce à cette correspondance, nous pouvons facilement convertir n'importe quel ACE dans un nœud d’arbre multidimensionnel à intervalle. Un arbre à intervalle est un arbre binaire construit sur la base des points de fin d'intervalle. Par exemple, soit X un ensemble d'intervalles dans une seule dimension, et soit m la médiane des points fin de l'intervalle. L'ensemble des intervalles contenant m sont stockés à la racine. L'ensemble des intervalles de gauche ou de droite de m forment le sous-arbre gauche et le sous-arbre droit. Ces intervalles sont récursivement partitionnés en fonction de leur médiane. Les opérations de recherche, d'insertion et de suppression dans un arbre à intervalle à une dimension nécessitent O(nlogdn) du temps {[46],[47]}.

Un arbre multidimensionnel à intervalle est une généralisation de l'arbre à une dimension à intervalle. Un arbre à intervalle peut être construit en premier sur la base des intervalles dans la première dimension seulement. Cet arbre à intervalle de premier niveau (parfois appelée arborescence des composants) contient un ensemble d'éléments dans chaque nœud de l'arbre. Chaque nœud stocke à son tour son élément en utilisant un arbre à intervalle basé sur la seconde dimension. Toute requête est réduite à une séquence de recherche binaire dans chaque dimension. La structure de données de l’arbre multidimensionnel à intervalle implémentée dans notre travail est un arbre dynamique à intervalle dans le sens où il peut prendre en charge les insertions et les suppressions. Les opérations de recherche, d'insertion et de suppression consomment un temps de l’ordre de O(nlogdn) {[46],[47]}

où d est la dimension.

5.2.2 Algorithme d'analyse d’ACL

Avant d'examiner l’algorithme d'analyse d’ACL en détail. Nous présentons un ensemble de définitions formelles concernant la relation entre deux règles. Ces définitions précises nous permettent de décrire les algorithmes d'une manière concise et sans ambiguïté.

5.2.2.1 Définitions  Définition 1

Soient M et N deux intervalles tels que : M = [m:m’] et N= [n:n’]

1. M s’intersecte avec N si m <=n <= m’ ou m<=n’<=m’ ou n<=m<=n’ ou n<=m’<=n’ 2. M contient N si m <= n et n’ <= m’

3. M et N sont adjacents si m’+1 = n ou n’+1 = m  Définition 2

Soient les règles : X et Y, où X = [x1, x2, … xn] et Y= [y1, y2, … yn] 1. X et Y s’intersectent si, pour chaque xi et yi, xi et yi se croisent. 2. X et Y sont disjoints s’ils ne s’intersectent pas.

74 3. X contient Y si, pour chaque xi et yi, xi contient yi.

4. X, Y se chevauchent s'il existe un xi et yi où xi et yi se croisent, pour toutes les autres dimensions, xj == yj

5. X, Y sont adjacents s'il existe un xi et yi qui sont adjacents, pour toutes les autres dimensions, xi == yi.

Contenance et chevauchement sont des relations plus spécialisées de la relation intersection. Adjacence est une relation plus spécialisée de la relation disjoint. La Figure 20 illustre ces relations.

Fig. 20 : Relations des règles

a) intersection, b) contenance, c) chevauchement, d) adjacence et e) disjoint

L'observation importante à faire ici, c'est que la forme géométrique projetée par une ACE est toujours rectiligne. Par conséquent, la relation test ne prend pas quelques comparaisons simples dans chaque dimension, qui prend un temps O(d), où d est le nombre de dimensions. Test d'intersection entre deux formes arbitraires est une tâche beaucoup plus difficile.

Sur la base des relations primitives définies, on peut formaliser la notion de cohérence et de redondance.

Soient X et Y deux entrées ACE, où X précède Y dans l’ACL (note: l'indice p est utilisé si la règle est une règle d'autorisation, d est utilisé s'il s'agit d'une règle de refus):

 Définition 3

X ou Y est redondante si l'une des conditions suivantes s’applique suffisamment : 1. Xp contient Yp

2. Xd contient Yd

3. Yp contient Xp et il n'existe pas de règle Zd entre Xp et Yp tel que Zd se croise avec XP et XP ne contient pas Zd

4. Yd contient Xd et il n'existe pas de règle Zp entre Xd et Yd de telle sorte que Zp se croise avec Xd et Xd ne contient pas Zp. Les deux premières conditions déterminent si Y est redondante. X contient Y implique que les paquets qui correspondent à Y sont compensés par X. Comme X précède Y, Y ne sera jamais utilisée. Les conditions 3 et 4 déterminent si X est redondante. La vérification supplémentaire pour la règle Z est nécessaire, car si une telle règle Z existe, et si la règle X est supprimée, tous les paquets avec des valeurs qui se situent dans la région d'intersection de X et Z peuvent être appariés par Z. L'action spécifiée dans Z sera prise, et non pas X. La propriété de classification des paquets sera altérée. Si X contient Z, Z est une règle incompatible (voir définition 4), et sera supprimée. La figure 21 illustre les deux cas.

75

a) Xp est redondant, tous les paquets qui sont autorisés par X seront permis par Y. b) Xp n'est pas redondant, si XP est supprimé, tout paquet qui tombe dans la partie ombrée peut être refusé par Z.  Définition 4

X et Y sont incompatibles si l'une des conditions suivantes s’applique suffisamment : 1. Xp contient Yd

2. Xd contient Yp

Dans le cas 1 et 2, la règle Y est redondante dans certains sens. Cependant, puisque l'action déclenche Y est à l'opposé de X, différents comportements de filtrage se traduiront, si Y est utilisée. Cela pourrait indiquer une incohérence en termes de classification de paquets dans le but de l'ACL. Très probablement, l’administrateur du réseau a configuré Y sans se rendre compte qu'elle est contenue dans X. Ceci pourrait conduire à un compromis de sécurité grave. (Note: Il est recommandé de préciser X et Y tels que Y contient X. L'idée est que l'administrateur doit tout d'abord configurer les règles correspondantes à des cas exceptionnels, et puis une règle large pour couvrir le cas par défaut).  Définition 5

X peut être fusionnée avec Y (la règle X est supprimée, la règle Y est étendue) si l'une des conditions suivantes s'applique suffisamment :

1. Xp et Yp se chevauchent ou sont adjacents et il n'existe pas de règle Zd entre Xp et Yp tel que Zd se croise avec XP et XP ne contient pas Zd.

2. Xd et Yd se chevauchent ou sont adjacents et il n'existe pas de règle Zp entre Xd et Yd de telle sorte que Zp se croise avec Xd et Xd ne contient pas Zp.

Le rationnel pour la vérification supplémentaire pour Z est similaire au cas de la redondance. Si une telle règle Z existe, et si la règle X est fusionnée, tous les paquets avec des valeurs qui se situent dans la région d'intersection de X et Z peuvent être appariés par Z. L'action spécifiée dans Z sera prise, et non pas X. La propriété de classification des paquets sera modifiée. Dans ce cas, X ne peut pas être fusionnée. La figure 22 illustre les deux cas.

Fig. 22 : Vérification de fusion

a) Xp peut être fusionnée avec Yp. b) Xp ne peut pas être fusionnée, si XP est fusionnée, tout paquet qui tombe dans la partie ombrée peut être refusée par Z

5.2.2.2 L’algorithme d’optimisation utilisé « optimise»

L’algorithme « optimise » fusionne les ACE adjacentes ou celles qui se chevauchent, détecte, résoud les incohérences et supprime les redondances. Après l’algorithme « optimise », une ACL est associée à une forme plus simple sans aucune modification des propriétés de classification des paquets. Cette représentation simplifiée est plus facile pour les administrateurs à comprendre, et peut remplacer l'ACL d'origine sur le pare-feu. Au cours de l’algorithme « optimise », les redondances et les incohérences sont identifiées. L’algorithme « optimise » peut être exécuté hors ligne ou directement intégré à l'interface du routeur en ligne de commande. Dans ce cas, un administrateur devrait recevoir de la rétroaction interactive au fur et à mesure qu’il configure les ACL, ainsi la détection des risques

76

de sécurité le plus tôt possible. Les notations suivantes sont utilisées: Ip et Id sont deux intervalles de

l’arbre qui stockent les règles permit et deny respectivement. Sp et Sd sont des ensembles qui stockent

la requête retournée à partir de chaque arbre. La variable a définie dans la ligne 4 sert comme index à l'arbre à intervalle approprié ou un ensemble de requêtes. Par exemple, si a est permis, alors Sa réfère à Sp, S!a réfère à Sd.

Algorithm optimise (L)

Input. An ACL

Output. An optimised ACL 1.for each rule y in L 2. S

p = Ip.query (y); // return permit rules that intersect or adjacent y 3. S

d = Id.query (y); // returns deny rules that intersect or adjacent y 4. let a = action type of y // permit or deny

5. if any rule in S

a contains y 6. continue // redundancy rule 1,2 7. if any rule in S

!a contains y

8. continue // inconsistency rule 1,2 9. for each rule x in S

a that is contained by y 10. if (there does not exist a rule z in S

!a, where z is between x and y 11. and x intersects z and x does not contain z)

12. I

a.remove (x) // redundancy rule 3,4 13. for each rule x in S

a that overlaps or is adjacent to y 14. if (there does not exist a rule z in S

!a, where z is between x and y 15. and x intersects z and x does not contain z)

16. I

a.remove (x)

17. y = merge(x, y) // merge rule 1,2 18. I

a.insert (y); 19. build L

result using Ip and Ib 20. return L

result

Cet algorithme est organisé pour illustrer clairement chaque cohérence, redondance et la condition de fusion. L’implémentation actuelle peut être moins verbeuse. Ip et Id sont vides au début. Les lignes 5 à 8 vérifient les cas simples d'abord. Les lignes 9 à 12 contrôlent et assurent la redondance d'une règle définie précédemment. Les lignes 13 à 17 fusionnent une règle définie précédemment avec la règle actuelle (Note: afin de trouver les règles adjacentes, y a besoin d’être augmenté de 1 dans toutes les dimensions avant d'effectuer la requête dans les lignes 2 et 3). Enfin, si la ligne 18 est atteinte, cette nouvelle règle est insérée dans l'arbre à intervalle approprié. Un message d'erreur ou d'information peut être délivré à l'administrateur chaque fois qu’une redondance et une incohérence est détectée, ou lorsque se produit une fusion. Chaque règle stocke un numéro d’ordre qui correspond à l'ordre initial dans l’ACL. Le numéro d'ordre est maintenu dans l'ensemble du processus d'optimisation. L'opération

77

de fusion de la ligne 17 ne change pas le numéro d'ordre de y. La nouvelle liste d’optimisation des règles peut être générée par un simple parcours de Ip et Id de l'arbre et retourne le résultat en fonction de l'ordre des règles d'origine. Si chaque requête retourne des résultats proportionnels à n, où n est la taille d’ACL originale, cet algorithme nécessite un temps O(n2). Toutefois, une telle configuration

d’ACL est impraticable. Nous pouvons dire que la requête renvoie un ensemble de taille fixe. Par conséquent, les deux boucles des lignes 9 à12 et 13 à 17 s’exécutent en un temps constant. Le temps d'exécution de cet algorithme est donc dominé par le temps de la requête, O(nlogdn).

Il est souvent judicieux de voir une ACL comme une séquence de règles « permit » suivie de la règle implicite « deny-all » ou vice versa. L’entrelacement arbitraire des règles « permit » et « deny » peut être difficile à déchiffrer. Cela est particulièrement vrai si l'ACL est modifiée ou agrandie au fil du temps par différents administrateurs.

5.3 Conclusion

Dans ce chapitre nous avons présenté une nouvelle approche pour l'analyse des ACL. Nous avons modélisé des ACE dans une ACL en utilisant bien définis des constructeurs, ce qui conduit à la définition mathématique précise de leurs relations. Sur la base de ces ensembles de relation primitive et des opérations, nous avons proposé un nouvel algorithme pour l'optimisation des ACL. L’arbre multidimensionnel à intervalle est utilisé pour sa généralisation intuitive pour des grandes dimensions et pour le simple mappage entre la règle et les intervalles. L’algorithme proposé dans notre travail devrait simplifier énormément la tâche de l'administrateur réseau pour implémenter et vérifier des politiques de sécurité d'entreprise.

Il serait intéressant d'intégrer une analyse ACL à l'interface du pare-feu en ligne de commande afin que l'administrateur doive obtenir une rétroaction immédiate sur les redondances et les incohérences au moment qu’il configure l'ACL. Le pare-feu peut également optimiser les ACL configurées pour augmenter la vitesse de classification des paquets.

78

Chapitre 6 : Déploiement des Politiques

Documents relatifs