Détection d anomalies dans les configurations de firewalls de dernière génération

Détection d anomalies dans les configurations de firewalls de dernière génération Rapport d étude bibliographique Master Recherche en Informatique 2010-2011 Réalisé par : Ibra Seye Encadrants : Frédéric Cuppens Nora Cuppens

Table des matières 1 Introduction 3 2 Règle de filtrage des Firewalls 4 2.1 Règle de filtrage des Firewalls sans états (stateless)................. 4 2.2 Règle de filtrage des Firewalls à états (stateful)................... 4 2.3 Règle de filtrage des Firewalls applicatifs....................... 6 2.4 Règle de filtrage des Firewalls réseaux-applicatifs.................. 6 3 Anomalies dans la configuration des firewalls réseaux 7 3.1 Anomalies intra-firewall................................ 8 3.2 Anomalies inter-firewalls................................ 9 4 Vérification des configurations 10 4.1 Approche par raffinement............................... 10 4.2 Approche analytique.................................. 12 4.2.1 Analyse intra-firewall............................. 12 4.2.2 Analyse inter-firewalls............................. 13 5 Conclusion 14 Références 14 2

1 Introduction La sécurité informatique gagne de plus en plus une attention particulière dans les communautés de recherches et industrielles du fait de la démocratisation de l internet. En raison de la menace grandissante des attaques des réseaux les firewalls sont devenus d importants éléments intégrés, non seulement dans les réseaux d entreprises mais aussi dans les réseaux domestiques. Les firewalls, constituant la première ligne de défense des réseaux contre les attaques et les trafics non autorisés, filtrent les trafics réseaux non désirés entrant ou sortant du réseau sécurisé. La décision de filtrage est basée sur un ensemble de règles de filtrage défini selon les exigences de la politique de sécurité spécifiée. Bien que le déploiement des firewalls constitue une étape fondamentale pour la sécurité des réseaux, la complexité de la gestion des politiques de sécurité des firewalls peut limiter l efficacité de la sécurité des firewalls. Dans un environnement où il y a un unique firewall, la politique de sécurité locale peut générer des anomalies intra-firewall, où une ou plusieurs règles de sécurité s appliquent sur un même paquet. Par ailleurs dans un environnement distribué où il y a plusieurs firewalls, il peut exister des anomalies inter-firewalls ou chaque firewall sur un même chemin applique différentes règles de filtrage sur un même trafic. C est donc cet aspect de configuration des firewalls afin qu ils soient exempts d erreurs qu il sera question dans cette étude bibliographique. Les solutions actuelles de firewalls proposent des fonctionnalités qui vont bien au-delà du simple contrôle de l origine et de la destination des paquets. Les fonctionnalités des firewalls de dernières générations permettent notamment de contrôler l état d une connexion (firewall dynamique), le contenu des paquets ou bien encore la conformité d un paquet avec un protocole de niveau applicatif. Par conséquent l administrateur de sécurité doit donner une attention particulière non seulement sur les relations entre les règles d un même firewall afin de déterminer l ordre des règles correctes mais aussi toutes les relations entre les règles de différents firewalls. Bien que la sécurité des firewalls ait donnée une attention particulière dans la communauté de la recherche, l accent a été principalement mis sur l analyse et la détection d anomalies sur les firewalls sans états. Les premières approches [11, 18] proposent l utilisation d un langage de politique de sécurité de haut niveau pour définir et analyser la politique de sécurité des firewalls et ensuite implémente ce langage sur les règles de filtrage. Si l utilisation de tels langages de haut niveau permet d éviter les anomalies, ils ne sont pas faisables pour la plupart des firewalls contenant des langages de filtrage de bas niveau. D autres approches [7, 6, 13, 3, 4] proposent l application d un processus d audit à l ensemble des règles de filtrage existantes afin de détecter les erreurs de configurations et de les corriger sans effets de bord. Les firewalls à filtrage statique de paquets ne contrôlent pas les messages applicatifs, pas plus que les firewalls à filtrage dynamiques, ces derniers filtrant néanmoins d avantage la présence d application à commutation de port. Tandis que les firewalls de dernières générations tels que les pare-feu applicatifs extraient les données du protocole de niveau 7 et traitent les requêtes par des processus dédiés (proxy) et les firewalls réseaux-applicatifs, à partir des règles de filtrage, peuvent systématiquement autoriser, bloquer et poser des questions sur le trafic provenant d adresse IP et de ports spécifiques. Cependant dans la littérature il ne semble pas que ces derniers types de firewalls ont été abordés pour la découverte et de suppression d anomalies dans leurs différentes règles de filtrage. L objectif du stage sera donc de prolonger ces travaux déjà initiés à Télécom Bretagne afin d étendre ces algorithmes aux fonctions de filtrage à états, d analyse de contenu et de filtrage applicatif. Pour ce faire nous étudierons les travaux menés dans ce domaine de détection d anomalies dans la configuration des firewalls en cherchant à les mettre en œuvre dans les configurations des firewalls dynamiques, applicatifs et réseaux-applicatifs afin de voir sil y a création de nouvelles anomalies. 3

Cette étude bibliographique s efforcera donc de présenter l état de l art relatif aux travaux que nous allons mettre en œuvre dans ce stage. Nous décrirons ainsi dans la première partie les règles générales de filtrage des firewalls réseaux, applicatifs et réseaux-applicatifs, en présentant un certain nombre d articles ou de travaux que nous espérons représentatifs. Dans une seconde partie nous nous intéresserons sur les différentes anomalies pouvant exister entre les règles de filtrage dans un environnement où il y a un ou plusieurs firewalls reseaux. Et dans une troisième partie nous allons mettre l accent sur les méthodes déployées afin d analyser et de supprimer ces anomalies liées surtout aux firewalls réseaux. 2 Règle de filtrage des Firewalls Un firewall est une machine qui sert comme intermédiaire pour l accès à un réseau (interne), permettant ou interdisant certain type d accès avec le respect de la politique de sécurité. Pour atteindre cet objectif, le firewall réalise alors un filtrage des paquets en se basant sur un ensemble de règles définies par l administrateur de sécurité. Il propose donc un véritable contrôle sur le trafic réseau du système informatique. Il permet d analyser, de sécuriser et de gérer le trafic réseau. Différentes catégories de firewall on été développées afin de réaliser ces objectifs de sécurité. Le choix d un type de firewall plutôt qu un autre dépendra de l utilisation que l on souhaite en faire. 2.1 Règle de filtrage des Firewalls sans états (stateless) Ce sont les firewalls les plus anciens mais surtout les plus basiques qui existent. Ils font un contrôle de chaque paquet indépendamment les uns des autres en se basant sur des règles prédéfinies par l administrateur. Ces firewalls interviennent sur les couches réseau et transport. Une règle est composée des champs de filtrage tels que le type de protocole (tcp, udp, imcp ), l adresse IP source et de destination, le numéro de port source et destination et le champs de filtrage. Les s des règles de filtrage sont soit accepter qui autorise les paquets de traverser ou de sortir du réseau sécurisé, soit refuser qui rejette les paquets. Les paquets sont donc acceptés ou refusés par une règle spécifique si l information de l en-tête des paquets correspond à tous les champs réseaux de la règle. Ainsi dans [2] les auteurs proposent une représentation (comme l illustre la figure 1)très explicite des règles de filtrage existantes dans les firewalls sans état. En effet ils formalisent les règles de filtrage sous forme d arbre fournissant une représentation simple et compréhensive des règles de filtrage. On voit clairement que chaque nœud représente un champs de la règle de filtrage, et chaque branche de chaque nœud représente une valeur possible de l association des champs. De plus ils utilisent une table de hachage pour stocker la valeur du champs pour chaque branche émergente. Chaque chemin de l arbre commençant à la racine et terminant sur une feuille représente alors une règles de filtrage. Nous voyons clairement que cette démarche fournit une vision claire des règles de filtrage et des relations pouvant exister entre elles. Une description complète des firewalls sans états ainsi que leurs règles de filtrage est présentée dans [9]. Dans la section 2.2 nous étudierons essentiellement les règles de filtrage des firewalls dynamiques même s il n ont pas eu une place assez déterminante dans la communauté de la recherche. 2.2 Règle de filtrage des Firewalls à états (stateful) Les firewalls à états constituent une évolution des firewalls sans état. La différence entre ces deux types de firewalls réside dans la manière dont les paquets sont contrôlés. Les firewalls à 4

protocol tcp udp src_ip src_ip 140.192.37.20 140.192.37.30 140.192.37.... 140.192.37.... src_port src_port src_port src_port src_port src_port... dst_ip... dst_ip... dst_ip 140.192.37.40 140.192.37.40 dst_ip... dst_ip... dst_ip 140.192.37.... 80 21 80 21 80 21 80 21 53 53 deny deny accept accept deny accept accept accept deny accept accept deny rule 1 rule 5 rule 2 rule 6 rule 4 rule 7 rule 8 rule 3 rule 4 rule 8 rule 9 rule 10 rule 11 rule 12 Figure 3. Policy tree for the firewall policy in Figure 2. Figure 1: Règle de filtrage des firewalls sans états. Extrait de [2] The algorithm shown in Figure 4 is used in building the policy tree. The basic idea is to insert the filtering rule in the correct tree path. While inserting a rule field at any tree node, the rule branch is determined based on matching the field value with the existing branches. If a branch exactly matches the rule, the rule is inserted in this branch; otherwise a new branch is created. The rule also propagates in superset or superset branches to preserve the relations between the policy rules. The algorithm is invoked for each rule in the policy with the rule as the first parameter, the protocol field as the second parameter and the root node as the third parameter. If the inserted field is not the rule, the algorithm checks if the input field value matches any of the already created branches at the input node. If a match is found, the algorithm is recursively called with the same rule and the next field and the matching branch node as parameters. The recursive call ensures that a rule will propagate in all the branches representing rules that may be related to the newly inserted rule. If the field value was not equal to any of the existing branches, a new branch that represents the inserted field value is created. If the inserted field is not the field, the algorithm is recursively applied on the new branch with the same rule and the next field and the new branch node as parameters. états prennent en compte la validité des paquets qui transitent par rapport aux paquets précédemment reçus. Ils gardent alors en mémoire les différents attributs de chaque connexion, de leur commencement jusqu à leur fin, c est le mécanisme de «statefull» inspection. De ce fait ils seront capables de traiter les paquets non plus uniquement suivant les règles définies par les administrateurs, mais également par rapport à l état de session. Dans [10] les auteurs considèrent que la suivie de connexion classifie chaque paquet suivant plusieurs états : NEW : si le paquet initialise une connexion, We would ESTABLISHED like to emphasize that our main objective : si leis paquet to provide a simple est associé model that can avec be used une for connexion qui a the analysis of filtering rules, as well as visualizing the rules in an expressible view that will reflect rencontré des paquets relations dans between rules. The deux main objective directions, of the Firewall RELATED Policy Advisor is : to si assist lein paquet firewall policy initie une nouvelle editing. Therefore, we are not as much concerned about search time complexity as we are concerned connexion, mais toujours about clarity and associé simplicity avec of the rule une model. connexion déjà établie, INVALID : ne fait pas parti d une connexion déjà existante. Les attributs gardés en mémoire sont donc les adresses IP, numéros de port et numéro de séquences des paquets qui ont traversé le firewall. Les firewalls dynamiques sont donc capable de déceler une anomalie protocolaire de TCP. 8/21 De plus, les connexions sont gardées dans une table des états de la connexion. L application des règles de filtrage est alors possible sans lire les ACL à chaque fois, car l ensemble des connexions appartenant à une connexion active seront acceptées. Les premières modélisations des règles de filtrage des firewalls dynamiques ont été faites dans [14]. Chaque firewall a un ensemble de variables appelé état du firewall, qui est utilisé pour stocker les paquets que le firewall a déjà accepté et dont il aura besoin prochainement. Dans chaque firewall nous avons deux sections : une section à états et une section sans états. Et chaque section est composée d une séquence de règles. Pour chaque paquet les règles de filtrage se font comme suit : la section à état est utilisée pour vérifier si l état d un paquet antérieur peut influencer le comportement du paquet courant. Et ils ajoutent un champs aditionnel à chaque paquet appelé tag où ils stockent le résultat de cette vérification. Et enfin la section sans état sera utilisée pour décider du comportement de chaque paquet suivant les informations basées sur le paquet lui même et la valeur du tag. On voit donc clairement que les firewalls dynamiques, même s ils filtrent d avantage en présence d application a commutation de ports, ne contrôlent pas les messages applicatifs. La section 2.3 présentera donc les différentes règles de filtrage des firewalls applicatifs permettant d extraire les données du protocole du niveau 7 afin de les étudier. 5

2.3 Règle de filtrage des Firewalls applicatifs Les firewalls à filtrage statique de paquets et dynamiques ne contrôlent pas les messages applicatifs, or ces derniers contiennent des informations cruciales pour la décision d acceptation ou de rejet. Les firewalls applicatifs représentent alors d indispensables compléments aux par-feux de filtrage de paquets. Les firewalls applicatifs (aussi nommés pare-feu de type proxy ou passerelle applicative) fonctionnent sur la couche 7 du modèle OSI. Cela suppose que le firewall connaisse l ensemble des protocoles utilisés par chaque application. Par son mode de fonctionnement, le firewall applicatif assure trois fonctions de protection : dissimulation d adresse IP permettant de remplacer toutes les adresses IP par celle du firewall empêchant ainsi un pirate d obtenir des informations sur l adresse Ip, destruction d en-têtes permet d arrêter toutes les attaques reposant sur les en-têtes IP, TCP, et UDP, renforcement de protocole permettant de contre carré les attaques de type «usurpation de numéro de port». Les pare-feux applicatifs assurent aussi une fonction de protection relative à l application qui intéresse le proxy. Chaque protocole dispose donc d un module spécifique à celui-ci. Ainsi distingue généralement différents types de filtrage selon le protocole utilisé : Filtrage de commande : Avec un filtre spécifique à l application, on peut empêcher les machines internes ou externes d utiliser certaines commandes, tel que la commande Get servant au téléchargement de fichiers à partir d un serveur et normalement acceptés par les proxy HTTP. Il est également possible de configurer les proxy de sorte qu ils rejettent tous les messages contenant la commande Post servant à envoyer des fichiers vers l extérieur du réseau de l entreprise. Filtrage de machine ou d URL : Permet de filtrer les messages à destination ou en provenance de machine ou d URL spécifiques. Les pare-feux font dans ce cas recours à des répertoires fournissant des adresses de serveur ou d URL pour interdire l accès à de telles ou telles références Web. Fitrage MIME : Les en-têtes des messages de réponse HTTP contiennent le champs MIME spécifiant le format du fichier en cours de livraison. La configuration du proxy peut rejeter les messages contenant des fichiers exécutables (.exe,.vbc, etc.) et des fichiers binaires non spécifiés, pour éviter toute infection. Fitrage FTP : Permet de filtrer les commandes Put permettant de mettre à jour les serveurs FTP externes afin d éviter toutes fuites d informations sensibles depuis le réseau. Une description détaillée des firewalls applicatifs est étudiée dans [17]. Dans la section 2.4 nous allons introduire la notion de pare-feu réseau-applicatif qui est pour la plupart du temps construit par des commerciaux. 2.4 Règle de filtrage des Firewalls réseaux-applicatifs Les firewalls réseaux-applicatifs constituent un complément des firewalls réseaux et applications car ils mêlent généralement toutes les techniques présentées précédemment. En effet ils fournissent une protection supplémentaire sur les couches réseau, session, et application. Ce sont des pare-feux «full-inspection», permettant aux administrateurs de définir des politiques granulaires pour contrôler les informations qui entrent et qui sortent du réseau, ils contrôlent d abord minutieusement les paquets pour supprimer et consigner les mauvais paquets. Le pare-feu ouvre et examine ensuite les paquets de protocole de couche d application. Ces paquets sont vérifiés pour garantir la conformité aux commandes valables. Une fois de plus, les mauvais paquets sont 6

éliminés et consignés. Si les paquets sont basés sur les protocoles HTTP, la technologie de filtrage de contenu compare l adresse IP source avec une liste de sites Web interdits. Le contenu interdit est supprimé et consigné. Si les paquets sont basés sur les protocoles HTTP, FTP et SMTP, les fichiers et les pièces jointes sont envoyés à l analyseur antivirus de référence. Celui-ci bloque également de manière active les courriers électroniques selon l objet, le texte, le nom de fichier, le type de la pièce jointe et la taille du message. Si un virus est détecté, le fichier est réparé ou supprimé. Tous les virus sont consignés et un message est ajouté aux courriers électroniques indiquant qu un virus a été détecté et que la pièce jointe a été supprimée. Si tous ces contrôles sont passés avec succès, le boîtier autorise le paquet à entrer ou quitter le réseau. Cette combinaison unique de technologies de sécurité permet de bloquer les virus, les attaques malveillantes et les menaces combinées au niveau du réseau. Ce mécanisme d inspection de paquets se fait à travers des outils filtrage dont une liste non exhaustive est : Une liste noire : Permet de rejeter tout le trafic d un ou plusieurs adresses IP. Si une machine est dans la liste noire le firewall supprime tous les paquets de ce poste. Ainsi le paquet sera immédiatement supprimees, évitant tout traitement ultérieur au niveau du firewall. Une interface basée sur le filtrage de paquets : Les paquets qui ne sont pas dans la liste noire sont alors testés à partir des filtres d entrés existant sur l interface. L interface de filtrage de paquets permet de bloquer un trafic spécifique. Validation des datagrammes IP : Le firewall réseau applicatif fait également une vérification sur les datagrammes IP. Ici le firewall inspecte les datagrammes IP afin de vérifier la longueur des paquets TCP, le flag TCP, la longueur des paquets UDP et l exactitude des paquets DHCP. Inspection dynamique d application : L inspection dynamique de paquets permet d examiner les premières séries de paquets pour une connexion donnée et de vérifier si les paquets sont valides. Durant cette phase tout le trafic se comporte normalement. Après avoir traiter les premières paquets, le proxy vérifie par le biais d un scanneur de données si les futurs paquets de cette session sont autorisés ou non avant de traverser le réseau et qu il n est pas nécessaire d aller jusqu à la couche application pour une ultérieure inspection. Une liste très large et détaillée des outils de filtrage des firewalls réseaux-applicatifs est présentée dans [19]. Cependant, bien que ces règles de filtrage constituent la base de la sécurité des réseaux, leur gestion devient de plus en plus complexe vu la grandeur de la taille des règles à mettre en œuvre dans les firewalls. Et nous remarquons également que dans la littérature seules les anomalies liées à la configuration des firewalls réseaux ont été abordées. Ainsi dans la section 3 nous traiteront que les incohérences rencontrées sur le management des règles de filtrage de ces types de pare-feu. 3 Anomalies dans la configuration des firewalls réseaux Bien que le déploiement de la technologie des firewalls constitue une étape très importante dans la configuration de la sécurité des réseaux, la complexité de management de la politique de sécurité de ces derniers peut limiter l efficacité de leur sécurité. Dans un environnement où il y a un seul firewall, la politique de sécurité locale peut engendrer des anomalies intra-firewalls, où plus d une règle de filtrage s appliquent aux même paquets. Par ailleurs dans un environnement 7

où il y a beaucoup de firewalls, on peut avoir des anomalies inter-composants où chaque firewall du même chemin effectue des règles de filtrages différentes sur le même trafic. 3.1 Anomalies intra-firewall Une anomalie de configuration de firewall est définie comme étant l existence de deux ou de plusieurs règles de filtrage qui font correspondre le même paquet ou l existence d une règle qui ne fait correspondre aucun paquet et dans le chemin du réseau traversant le firewall. Dans cette section on définit et décrit le nombre d anomalies possibles qu on peut détecter sur la configuration intra-firewalls. Ces dernières incluent les erreurs de conflits définies par le fait que certaines règles suppriment d autres règles, ou des avertissements pour de potentiels conflits pouvant exister entre les règles de filtrage. anomalie masquage Dans [7] les auteurs considèrent qu une règle est masquée s il y a une règle ou une combinaison de règles antérieures ayant une priorité plus grande qui s applique sur tous les paquets que font correspondre la première règle de telle sorte que la règle ne s applique jamais. Une anomalie de masquage est très critique pour la politique de sécurité des réseaux car ça peut engendrer qu un trafic autorisé soit interdit et un trafic autorisé soit accepté. anomalie redondante Une règle est dite redondante si on peut la supprimer sans influencer la décision de filtrage. En effet dans ce cas la règle applique la même sur les mêmes paquets comme une autre règle. Bien qu elle n affecte pas la configuration du réseau, la redondance est considérer comme une anomalie car elle augmente la taille de la table de filtrage, et par conséquent entraine une augmentation du temps et l espace de recherche du processus de filtrage des paquets. anomalie non-pertinente Une règle de filtrage dans un firewall est dite impertinente si elle ne peut s appliquer sur aucun trafic découlant du firewall. Cela a lieu si les champs d adresse source et de destination de la règle ne font correspondre à aucun domaine accessible par le firewall. C està-dire le chemin entre l adresse source et de destination de cette règles ne passe pas à travers ce firewall. Par conséquent cette règle n a aucun effet sur le résultat de filtrage du firewall [3]. La non pertinence est donc considérée comme une anomalie car ça ajoute des chevauchements sur le processus de filtrage. anomalie corrélée et généralisée Deux règles sont dites corrélées si elles ont différentes s de filtrage et si la première règle fait correspondre certains paquets qui sont mappés par la seconde règle, et la seconde règle fait correspondre des paquets qui sont mappés par la première règle. Tandis qu une règle est une généralisation d une autre règle s ils ont différente et que la première règle puisse mapper tous les paquets que fait correspondre la première règle [3]. Dans la littérature se sont les incohérences dans la configuration des firewalls sans états qui ont été les plus étudiée du fait de la grande taille de l espace à états. Une première tentative pour modéliser les firewalls dynamiques a été faite dans [14] mais ces travaux n ont proposé aucune méthode pour trouver les incohérences dans la configuration de ces derniers. Dans [10] les auteurs ont réalisé une modélisation technique des incohérences des firewalls à états. Ils modélisent un état comme étant un sous-ensemble particulier de l ensemble des règles de filtrage d un firewall c està-dire les règles statistiques et cohérentes pour un état donné. Une règle est alors dite state full si elle définit des informations d états et est donnée de la forme suivante <P,, infoetat> avec P le prédicat décrivant les critères que les paquets doivent satisfaire pour correspondre à la 8

Figure Figure 2: 1: Encodage Encoding de the l état firewall d unstate firewall. as a binary Extrait vector. de [10] We can now introduce a partial ordering on the set S of all possble states: règle (c est-à-dire le protocole, les adresses et ports sources et de destinations), l (accepter oudefinition refuser) et(partial infoetatordering à l état de of la firewall connexion. states) Et Let l état s and du firewall s be two correspond states of donc the same à tous lesfirewall états dynamiques (i.e., two binary et statiques vectors qui of the ontsame une length). entrée associée We have à s la table s if all dethe suivi dynamic de connexion. rules L état that du are firewall included estin donc s are considéré also included comme in un s. vecteur In other binaire words, représentant if the i-th element l ensemble of the des binary règles dynamiques vector corresponding actives ou non to s dans is 1, la then table the de i-th suivie element de connexion of the binary comme vector illustrer corresponding à la figure to s 2. A partir is also de 1. ça les auteurs définissent une relation d ordre partielle dans l ensemble des états. Ainsi si s 1 et s 2 sont deux états d un même firewall tel que s 1 < s 2 alors toutes les règles dynamiques incluses The key dans idea s 1 of sont our donc work incluses is that we dans show s 2 that. Par whenever conséquent, s s, le the nombre number d incohérences of inconsistencies dans s 1 nein peuvent s cannot pas be être larger plus than grande the number que leof nombre inconsistencies d incohérences s. The qui next sont theorem dans sstates 2. Parthis suite for on peut the dire number que of le nombre shadowings: de règles masquées dans l états s 1 ne peuvent pas être plus grande que le nombre de règles masquées dans s 2. Et il en va de soit pour toutes les autres anomalies de configuration Theorem (Shadowing) intra-firewalls. Let s and s be two states of the same firewall such that s s. The Jusqu ici number of les shadowings différentesin anomalies s cannot décrites be larger étaient then the denumber type intra-firewall. of shadowings La section in s. 3.2 présente donc une description claire et succincte des incohérences qu on peut avoir dans les architectures réseaux Proof: comportant Without loss plusof d un generality, firewall. we can assume that the i-th stateful rule r i of the firewall rule-set is included in s, otherwise s contains no stateful rules, which means that s = s, and 3.2the Anomalies statement of inter-firewalls the theorem follows trivially. Let us denote by s the state that we obtain from s by removing rule r i. En générale, une anomalie inter-firewall existe si deux firewalls sur un chemin du réseau appliquent Now, if différentes there exists règles a (stateful de filtrage or stateless) pour le même rule r trafic. j of the Dans same [3] firewall, les auteurs such ont that modélisé either r les i anomalies shadows pouvant r j or r j shadows exister dans r i, then un firewall removing comme r i from suit s : and obtaining s surely decreases the number Si le firewall of shadowings. le plus en Otherwise, aval («most-downstream») if no rule shadows accepte r i and no des rule paquets is shadowed qui sont by bloqués r i, then par removing le firewall r i from en amont s and (upstream). obtaining s does not affect the number of shadowings. Le firewall le plus en amont («most-upstream») permet du trafic bloqué par n importe quel As firewall state s en can aval. be obtained from s by iteratively removing from s the dynamic rules that are not Un contained firewall en in s, aval the refuse statement un trafic of the qui theorem est déjà can refusé be obtained par unby firewall iteratively plus using en amont. the above. C est-à-dire argument. que tous les firewalls en amont doivent permettre n importe quel trafic permis par le firewall le plus en aval afin que les données puissent atteindre leur destination. Nous allons donc Similar définir theorems les différentes can be anomalies stated and de configuration proven in the entre same plusieurs way firewalls. for the other types of inconsistencies and inefficiencies (see [14] for details). This leads to the following main theorem: 9

anomalie de masquage et de redondance Une anomalie de redondance entre firewalls existe si un firewall en aval refuse le trafic qui est déjà bloqué par un firewall en amont. Tandis qu une anomalie de masquage a lieu si le firewall en amont bloque le trafic réseau accepté par firewall en aval. anomalie corrélée : les auteurs de [3] définissent une anomalie corrélée dans les firewalls distribués comme étant le resultat obtenu entre deux règles de filtrage corrélées dans les firewalls en aval et en amont. Les règles de filtrage corrélées d une sont aussi sources d anomalies dans les firewalls distribués en raison de la règle implicite résultante de la conjonction des règles corrélées. Non seulement ça crée des ambiguïtés sur la politique de sécurité des firewalls mais aussi des anomalies de masquage. anomalie de mauvaise connexion Une anomalie de mauvaise connexion existe entre deux composants si le firewall le plus en amont du trafic permet tout le trafic ou une partie du trafic refusée par le firewall le plus en avale. Malgré toutes ces incohérences liées à la configuration des firewalls de types réseau plusieurs mécanismes on été abordées afin de vérifier ces erreurs de configuration et de les éliminer. La section 4 présentera donc essentiellement les mécanismes à utiliser pour vérifier les configurations de ces firewalls afin qu elles exempt d erreurs. 4 Vérification des configurations 4.1 Approche par raffinement De nombreuses recherches ont été faites la configuration des firewalls visant en utilisant cette approche dite descendante. L approche présentée dans [8] divise la configuration des firewalls avec une séparation nette entre la politique de sécurité et les spécifications technologiques des composants de sécurité. elle vise à implémenter la politique de sécurité indépendamment de la topologie du réseau. Par conséquent la politique de sécurité reste intacte quelque soit les changements de la topologie réseau et la génération des règles concrètes pour les firewalls serait automatique et accompagnée par un débugger permettant pour l administration des fichiers de configurations des firewalls.l outil réalisé est basé sur un Modèle Entité-Association (niveau abstrait) qui prend en compte la topologie du réseau (donc pas d indépendance claire entre la politique de sécurité et la topologie du réseau) par un concept nouveau, rôle, qui définit «les capacités du réseau» et que les auteurs utilisent sans sémantique claire et ambiguë. Un langage claire de définition du modèle et un compilateur de Modèle, qui réalise la traduction (du Modèle Entité-Association) vers les fichiers de configuration du firewall, permettent de faire l instanciation du Modèle Entité- Association. Ce concept de rôle mélange la topologie du réseau (niveau concret) et la politique de sécurité, d où l ambiguïté. Il introduit également une notion de groupe qui n est pas assez claire car elle désigne tantôt un ensemble machine tantôt un rôle. Celle-ci conduit inévitablement à des difficultés d affecter des entités du réseau aux entités du modèle. Les auteurs utilisent l héritage des privilèges parmi les hiérarchies des groupes pour dériver automatiquement des permissions. Pour l héritage des permissions ils introduisent la notion de «groupe ouvert» et pour les permissions la notion de «groupe fermé». Cette notion de groupe induit des confusions, alors qu elle n est pas nécessaire à ce niveau d abstr. Nous remarquons que l approche avec RBAC génère de nombreux dis fonctionnement qui sont liés à la complexité des règles a exprimer, à l absence de gestion de contexte et de conflits, à l absence de structuration de règles. Cependant d autres 10

Figure 3: Approche descendante. Extrait de [18] approches tel que Or-BAC (ORganization Based Acces Control) offrent une démarche détaillée et très claire du processus d implémentation de la politique de sécurité [11]. Or-BAC est caractérisé par deux niveaux d abstrs : le niveau organisationnel (rôle, activité, vue) et un niveau concret (sujet,, objet). il permet d exprimer des permissions, des interdictions et des obligations, indépendamment de l implémentation de la politique de sécurité. Les auteurs dans [15] proposent une administration très efficace du modèle Or-BAC par le biais de AdOr-BAC qui garantie son «auto-administration». Un processus de génération automatique des règles de filtrage avec Or-BAC à partir d une spécification formelle de la politique de sécurité est détaillé dans [11]. Dans la même lancée dans [18] les auteurs utilisent le même modèle de contrôle d accès pour formaliser un ensemble global d exigences de sécurité et un ensemble de compilation ultérieure pour transformer automatiquement cette abstr de politique de sécurité dans une configuration spécifique d un dispositif de sécurité sur système. A travers cette stratégie les auteurs simplifient le travail des administrateurs mais aussi garantissent un management de la politique de sécurité de telle sorte qu elle soit exempt d anomalies c est-à-dire d ambiguïtés, de redondances etc. Les auteurs définissent alors un ensemble de d algorithmes représentés dans la figure 3. La première compilation est répétée à chaque fois qu une sous-organisation (par exemple le firewall) se révèle. Le résultat est un pacquage de règles écrits dans une expression générique ("multi-target") mais pas pour une technologie générique. La deuxième compilation prend en compte la spécificité et la grammaire (syntaxe et sémantique) du dispositif de sécurité. Nous remarquons que ces mécanismes de formalisation et d abstr de la politique de sécurité sont d une importance capitale et ont également permis à mieux gérer l administration des configurations des firewalls afin qu ils soient exempt d erreurs. Cependant force est de constater que l évolution et la diversité des langages de configuration des firewalls actuels rendent ces approches de plus en plus délicates. Avec ces dernières, il est donc fort probable qu on obtienne des non-conformités avec les spécifications de la politique de sécurité. Une approche plus précise propose l application d un processus d audit à l ensemble des règles de filtrage existantes afin de détecter les erreurs de configurations et les corriger, nous l a présenterons dans la section suivante : c est l approche ascendante. 11

4.2 Approche analytique 4.2.1 Analyse intra-firewall De nombreux travaux ont été menés dans ce sens notamment dans [1] les auteurs considèrent que deux règles sont en conflit si la première règles fait correspondre quelques paquets qui correspondent aux paquets de la deuxième règles, et la deuxième règle aussi fait correspondre des paquets qui correspondent à ceux de la première règle. Cette approche est limitée car elle détecte un cas particulier d ambiguïté dans un seul composant de sécurité car elle ne peut pas détecter d anomalies sur plusieurs composants. Dans [16] l auteur considère deux cas d anomalies. D abord une règles R i est dite redondante arriérée s il existe une autre règle R j avec une priorité supérieure de telle sorte que les paquets qui correspondent à la règle R j correspondent aussi à la règle R i. Ensuite une règle R i est dite redondante en avant s il existe une autre règle R j avec la même décision et moins prioritaire de telle sorte que : tous les paquets qui s identifient à R i s identifient à R j Pour toute règle R k entre R i et R j s identifiant à tous les paquets correspondant à R i, alors R k et R i ont la même décision. Bien que cette approche semble aller dans la bonne direction, elle est incomplète, car elle ne détecte pas tous les cas d anomalies possibles dans une configuration intra-composante. Par exemple si on considère cette règle de filtrage suivante (ou chaque règle est de la forme R i : condition i decision j avec i la position relative de la règle dans l ensemble de règles, decision i une expression booléenne avec accepter,refuser et une condition i l attribut de condition de la zone source) : 1. R 1 : szone [10, 50] refuser 2. R 2 : szone [40, 70] acepter 3. R 3 : szone [50, 80] acepter et comme la règle R 2 vient après R 1 alors elle s applique sur l intervalle [51, 70] c est-à-dire la suppression de la règle n aura pas d effet sur la politique de filtrage, donc elle n est pas nécessaire.l approche proposée dans [16] ne peut alors détecter la redondance de la règle R 2 dans une telle configuration. De nombreux travaux effectués par [3, 5, 4] afin de détecter les anomalies dans la configuration des firewalls. Par contre leur approche n est pas assez complète car leur algorithme de détection d anomalies est basé sur l analyse de règles deux par deux. Cette démarche ne prend donc pas prendre en compte la réunion de règles. Par exemple comme montrer dans [7], la configuration de règles suivantes : 1. R 1 : szone [10, 50] acepter 2. R 2 : szone [40, 90] acepter 3. R 3 : szone [30, 80] refuser peut entrainer leur algorithme de détection à une décision inappropriée. Ainsi l approche définie dans [4] ne pourra pas détecter que la règle R i ne pourra jamais s appliquer du fait de l union des règles R 1 etr 2. Par contre l approche proposée dans [20] donne une vision beaucoup plus approfondie dans la détection de ce genre d anomalie. Bien que ces approches précitées présentent quelques faiblesses liées à la détection des anomalies dans la configuration intra-firewalls, une démarche claire et beaucoup plus détaillée est présentée dans [12]. En effet ici les auteurs présentent le processus de détection d anomalies en le subdivisant en trois algorithmes. Un premier algorithme qui est une fonction auxiliaire prenant deux règles comme argument en entré et retourne une troisième règle dont l ensemble des attributs est l exclusion de l ensemble d attributs des conditions des deux premières règles. Le second algorithme quand-à lui est une fonction booléenne retournant vrai ou faux faisant des vérifications nécessaires afin de décider si une règle est 12

(s)ource zone, (d)estination zone, and destination port dport for short): over f we pol- [16] fig- om- 19]. pleient glealso and nce, heir ionthe ach ecie R 3 R 2. gnal Figure 4: Exemple de configuration extrait de [7] their algorithms will inappropriately report a redundancy pertinente ou non pour la configuration d un firewall donné. Le troisième algorithme est aussi une anomaly fonction booléenne between qui à son filtering tour applique rules la transformation FW 1 {Rd exclusion 1 } andsurfw l ensemble 2 {Rdes 1 }. règles de configuration afin de vérifier si la règle obtenue comme paramètre est potentiellement This is because rule FW 1 {R 1 } matches every packet that redondante ou bien. Et enfin un quatrième algorithme qui effectue l ensemble du processus de détection also FW et de 2 suppression {R 1 } does. complèteas des anomalies a consequence, intra-composantes. [5] Ce processus considers est divisé rule en trois phases. Une première étape qui détecte et supprime des règles masquées avec une itération du FW premier 2 {Ralgorithme. 1 } as redundant L ensemble des since règles résultantes packets de ladenied première phase byest this ensuite rule utilisée are pour détecter et supprimer les règles redondantes avec l application du troisième algorithme. Et finalement alreadydurant denied la troisième by rule étape les FW ensembles 1 {Rde 1 }. règles However, non vides sont this analysées conclusion afin de détectées et supprimées les non-pertinences en appliquant impérativement le deuxième algorithme. L intérêt is notdeappropriate cette approche est que because non seulement rule elle analyse FW 1 {Rrègles 1 } applies de filtrage deux topar packets from the external zone to the private zone whereas rule deux mais aussi apporte une analyse complète de l ensemble des règles de filtrage dans les firewalls. 4.2.2 FWAnalyse 2 {R 1 } inter-firewalls applies to packets from the DMZ zone to the private zone. So, rule FW 2 {R 1 } is useful and cannot be removed. Comme mentionné avant, les anomalies inter-firewalls constituent un potentiel risque dans la sécurité des firewalls car les architectures réseaux deviennent de plus en plus complexes et leur configuration Though aussi in [5,6] s avère très the difficile. authors Dans [3, 5, claim 4] les auteurs that onttheir donné deanalysis nombreux résultats technique peuvent marks générer des every incohérences rulesurthat règles is de used détections on d anomalies a network doncpath, engendrer no qui ont permis de mieux gérer les conflits inter-firewall. Par contre ils considèrent des anomalies qui d autres erreurs de configurations. Par exemple sur la configuration de la figure 4 leur algorithme va specific rapporter une algorithms anomalie redondante haventre been les règles provided filtrage FWfor 1 {R 1 } doing et FW 2 {Rso. 1 } duthe fait que la règle FW main advantage 1 {R 1 } fait correspondre tous les paquets dont FW of our proposal over their 2 {R 1 } fait correspondre. Par contre bien que [3] considère la deuxième règles comme redondante, les approach auteurs dans is[7] that ont montré que la règle FW it includes a model 2 {R 1 } est belle et bien utilisable car la règle FW of the traffic which flows 1 {R through 1 } s applique aux each paquets venant de l extérieur vers la zone privée contrairement à FW 2 {R 1 }. Par ailleurs, les auteurs component. dans [6] développent We consider une démarchent thisclaire necessary du processus deto détection drawd anomalies the right en utilisant des algorithmes efficaces. conclusion En effet ils divisent inlethis processus case. de détection et de suppression d anomalies en utilisant quatre algorithmes. Un premier algorithme qui prend en argument un ensemble de composants et qui calcule Finally, pour chaque although composant sesinzones both source [7,28] et destination thepour authors lesquels l intersection considerest their non vide. Et là pour chaque route, règles et les zones sur lesquelles ce composant est connecté sont pris work en argument as sufficiently pour un second general algorithme afin todebe calculer used la route forminimale verifying connectant many ces deux zones. En effet ils décomposent l ensemble des composants à l intérieur de chaque chemin du other filtering based security policies such as intrusion detection and prevention systems, no specific mechanisms have trafic en aval(«downstream») et du trafic en amont («most-stream»). Et le premier composant been provided for doing so. 13 123

en avale et le dernier composant en amont seront passés comme argument pour les deux derniers algorithmes afin de conclure pour l ensemble des vérifications nécessaires garantissant le processus d audit. Même si ces derniers ont pu implémenter des algorithmes qui analysent très bien la détection d anomalies dans la configuration des firewalls sans états, ils n ont pas explorer la piste des firewalls dynamiques ou applicatives voir même réseau-applicatif qui constituent la majeure partie des composants utilisés actuellement. 5 Conclusion Nous nous sommes donc efforcés dans cette étude bibliographique de dresser l état de l art relatif aux travaux que nous allons mettre en œuvre dans ce stage. Nous avons ainsi clairement présenté les différents règles de filtrage des firewalls de type réseaux, applicatifs, réseaux-applicatifs. Ensuite nous avons étudié les anomalies pouvant exister entre les différentes règles des firewalls réseaux. Nous avons également insisté sur les différentes approches verification de configuration des firewalls réseaux visant à faire éviter les incohérences qui peuvent être liées aux règles de filtrage de ces firewalls tout en mettant l accent sur l approche ascendante. Dans ce stage nous mettrons donc essentiellement l accent sur les travaux décrits dans [7, 6, 13] afin d étendre les algorithmes proposés aux fonctions de filtrage dynamiques, d analyse de contenu et de filtrage applicatif. Références [1] Hari Adiseshu, Subhash Suri et Guru M. Parulkar : Detecting and resolving packet filter conflicts. In INFOCOM, pages 1203 1212, 2000. [2] Ehab S. Al-Shaer et Hazem H. Hamed : Firewall policy advisor for anomaly discovery and rule editing. In Integrated Network Management, pages 17 30, 2003. [3] E.S. Al-Shaer et HH Hamed : Discovery of policy anomalies in distributed firewalls. volume vol.4, pages 2605 2616. IEEE INFOCOM 04, 2004. [4] E.S. Al-Shaer et HH Hamed : conflicts classification and analysis of distributed firewallpolicies. pages 2069,2085. IEEE J.Select Areas Common. Magazine, 2005. [5] E.S. Al-Shaer et HH Hamed : Taxonomy of conflicts in network security policies. pages 134 141. IEEE Common. Magazine, 2006. [6] Joaquin Garcia Alfaro, Frédéric Cuppens et Nora Cuppens-Boulahia : Analysis of policy anomalies on distributed network security setups. Lecture notes in computer science, 4189(1):496 511, 2006. [7] Joaquin Garcia Alfaro, Nora Cuppens-Boulahia et Frédéric Cuppens : Complete analysis of configuration rules to guarantee reliable network security policies. International Journal of Information Security (IJIS), 7(2):103 122, 2008. [8] Yair Bartal, Alain Mayer, Kobbi Nissim et Avishai Wool : Firmato : A novel firewall management toolkit. ACM Trans. Comput. Syst., 22:381 420, November 2004. [9] Matt Bishop : Introduction to Computer Security. Addison-Wesley Professional, 2004. [10] Levente Buttyán, Gábor Pék et Ta Vinh Thong : Consistency verification of stateful firewalls is not harder than the stateless case. Infocommunications Journal, LXIV(2009/2-3), 2-3 2009. 14

[11] F. Cuppens, N. Cuppens-Boulahia, T. Sans et A. Miège : A formal approach to specify and deploy a network security policy. In Theo Dimitrakos et Fabio Martinelli, éditeurs : Formal Aspects in Security and Trust, volume 173 de IFIP International Federation for Information Processing, pages 203 218. Springer Boston, 2005. 10.1007/0-387-24098-5-15. [12] Frédéric Cuppens, Nora Cuppens-Boulahia et Joaquin Garcia Alfaro : Detection of network security component misconfiguration by rewriting and correlation. In First joint conference on security in network architectures (SAR) and security of information systems (SSI), 6-9 june, Seignosse, Landes, France. RSM - Dépt. Réseaux, Sécurité et Multimédia (Institut Télécom-Télécom Bretagne), 2006. [13] Joaquín García-Alfaro, Frédéric Cuppens et Nora Cuppens-Boulahia : Towards filtering and alerting rule rewriting on single-component policies. In Janusz Górski, éditeur : Computer Safety, Reliability, and Security, volume 4166 de Lecture Notes in Computer Science, pages 182 194. Springer Berlin / Heidelberg, 2006. [14] Mohamed G. Gouda et Alex X. Liu : A model of stateful firewalls and its properties. In DSN, pages 128 137, 2005. [15] Alexandre Miege : Definition of a formal framework for specifying security policies.the Or-BAC model and extensions. Thèse de doctorat, Télécom Paris, june 27th 2005. [16] Gupta P. : Algorithm for routing lookups and packet classification. Phd thesis, Departement of Computer Science, Stanford University, 2000. [17] Raymond Panko : Sécurité des systèmes d information et des réseaux. Pearson Education France, 2004. [18] Stere Preda, Nora Cuppens-Boulahia, Frédéric Cuppens, Joaquín García-Alfaro et Laurent Toutain : Reliable process for security policy deployment. CoRR, abs/0905.1362, 2009. [19] Symantec Corporation. Symantec Enterprise Firewall, Symantec Enterprise VPN, and VelociRaptor Firewall Appliance, 2001. [20] Lihua Yuan, Jianning Mai, Zhendong Su, Hao Chen, Chen-Nee Chuah et Prasant Mohapatra : FIREMAN : A toolkit for FIREwall Modeling and ANalysis. In Proceedings of 2006 IEEE Symposium on Security and Privacy, pages 199 213, Berkeley, CA, mai 21-24, 2006. 15