Rapport stage Dess Isa

3.4Etude de différents firewalls

Il existe deux types de pare-feu : les pare-feu matériels et les pare-feu logiciels. Les pare-feu matériels se présentent sous forme d'un boîtier. Il n'y a pas vraiment de différence importante au niveau de l'architecture par rapport aux pare-feu logiciels ; Les pare-­feu matériels sont dépendants d'un matériel propriétaire spécifique. Les pare-feu logiciels permettent de transformer un PC classique (ou un Mac...) en véritable pare-feu à part entière, à la restriction près que l'OS sous-jacent possède des failles inhérentes à un OS généraliste, pouvant inhiber le rôle de pare-feu attribué à la machine.

Un aspect dangereux des pare-feu logiciels est que l'on peut installer d'autres composants logiciels de sécurité sur le même PC, par exemple un anti-virus ou un IDS, et ce pour des raisons de coût. Cette solution, bien qu'apparemment satisfaisante pour plusieurs entreprises, peut éventuellement être nuisible au principe même de sécurité, car une fois qu'un PC regroupant toutes ces fonctions est compromis, l'ensemble des défenses qu'il assurait sont mises en échec. Tous les firewalls présentés ci dessous sont à filtrage dynamique (ou Stateful Multi-layer Inspection).

3.4.1Netfilter

Linux contient un module destiné au filtrage réseau, Netfilter[7]. Il se configure au moyen d'un outil appelé iptables. Netfilter est un pare feu logiciel, il travaille sur des paquets réseaux.
Fonctionnement
La couche réseau Linux présente plusieurs points d'accès (en anglais hook). Aux points d'accès sont associées des tables¹² de traitement. A l'intérieur des ces tables, on peut trouver plusieurs chaînes¹³. Ce sont elles qui contiendront les règles à appliquer aux paquets. Concrètement, lorsqu'un paquet réseau atteint un point d'accès, on transmet le paquet à ces chaînes de traitement. Un paquet passe toujours tout d'abord par l'une de ces 3 chaînes :

• 
  INPUT : un paquet à destination du système entrant dans une interface
  
• 
  OUTPUT : un paquet généré par le système sortant par une interface
  
• 
  FORWARD : un paquet traversant le système
  

Les principales cibles sont :

• 
  ACCEPT : le paquet est accepté,
  
• 
  DROP : le paquet est ignoré,
  
• 
  RETURN : fin du sous-programme courant ou application de la politique par défaut pour INPUT, OUTPUT et FORWARD,
  
• 
  REJECT : le paquet est rejeté avec un message d'erreur,
  

Les règles sont évaluées séquentiellement. Le format d’une règle est le suivant :

Table .
Netfilter offre des mécanismes de gestion des règles de contrôle d’accès intéressants. Il offre la possibilité de configurer nos règles avec les trois solutions envisagées. En effet, Il permet de créer des chaînes de règles indépendantes que l’on peut atteindre grâce au mécanisme « jump ». De plus il possède une commande très récente le « iprange » qui nous permet de spécifier un intervalle d’adresse.

3.4.2IPFilter

IPFilter[8] est une application qui est intégrée sur les systèmes d'exploitation FreeBSD, NetBSD. Le programme IPFilter peut s'exécuter dans le noyau ou sous forme de module. Le lancement du firewall doit se faire lors du démarrage de la station dans le noyau. Cette méthode est préconisée en exploitation pour s’assurer de ne rien laisser passer tant que les règles ne sont pas chargées.

Fonctionnement
Le filtrage s’effectue sur le flux entrant et sur celui sortant. Ce qui signifie que pour les paquets transmis d’une interface réseau à une autre, IPFilter évalue successivement la chaîne in de l’interface entrante puis la chaîne out de l’interface sortante. Les règles forment des listes d’accès ou ACL (Access Control List) qui sont spécifiés dans un fichier de configuration. Avec IPfilter, les règles sont traitées dans un ordre séquentiel et sont donc lues du début à la fin.
Les versions d'IPFilter sont basées sur la logique 'la dernière règle qui matche l'emporte' mais IPFilter a introduit l'option 'quick' qui permet de sortir du fichier si une règle est matchée. Le fonctionnement filtrage dynamique se fait avec l'option 'keep state'.
La syntaxe est aisément compréhensible et le format d’une règle est :


from <@ipsource>
to <@ipdestination>
.
Avec IPFilter, on peut aussi améliorer les performances en créant des groupes de règles par interface avec les mots clé ‘head’ et ‘group’. Un mécanisme intéressant pour le modèle Or-Bac est le ‘skip’. Il permet de sauter en avant plusieurs règles dans un fichier de configuration.

3.4.3Packet Filter

Packet Filter[9] est une application qui est intégrée sur les systèmes d'exploitation OpenBSD.
Fonctionnement
Le fonctionnement de Packet Filter est identique à celui de IPFilter, il n’existe des différences importantes que dans les fonctionnalités avancées. Les ACL sont les mêmes qu’avec IPFilter: il s’agit toujours de bloquer ou de laisser passer des paquets. La syntaxe ne change pas et une grande partie des commandes sont communes. Avec Packet Filter les mots clé head et group sont supprimés, l’optimisation des règles se fait grâce à un mécanisme interne le skip step. Il est aussi possible de faire des énumérations d’adresse IP de cette manière {192.168.0.0/16, 169.65.9.0/24, 225.14.86.0/24}.

3.4.4IPFW

Ipfw[10] est un firewall porté sur Free BSD et sur MAC OS. C’est un firewall qui a la possibilité d’être à filtrage dynamique. Il est dans le principe et dans la syntaxe assez similaire à IPFilter et à Packet Filter, les opérations de filtrage portent toujours sur les mêmes critères et s’effectuent aussi de manière séquentielle. La grande différence est que chaque règle possède un numéro. Grâce à ce numéro on peu atteindre en utilisant la commande « skip to », n’importe quel règle dans le fichier de configuration. Une autre de ses particularités est qu’il peut filtrer grâce aux options uid/gid sur le processus émetteur.

Le format des règles est le suivant :

add

from <@ip [port]> to <@ip [port]> .

3.4.5Firewall Cisco Pix

Pix[11] est un firewall matériel qui se présente sous la forme d'un boîtier. Il dispose généralement de plusieurs interfaces et intègre un OS minimaliste (garantissant une faible exposition aux attaques), ainsi que le logiciel de pare-feu proprement dit, tous deux non compatibles avec une architecture PC classique.

Fonctionnement
On affecte à chacune des interfaces connectées un niveau de sécurité allant de 0 à 100. Puis on associe aux interfaces des listes de control d’accès ou ACL¹⁴, où sont écrites les règles de filtrage. On attribue habituellement un niveau de sécurité proche de 0 pour l'interface connectée à Internet et un niveau proche 100 pour l'interface connecter au LAN. Pour la DMZ (zone démilitarisée), on met généralement un niveau de sécurité à 50.

Le Pix interdit par défaut toute communication  émanent d'une interface ayant un niveau de sécurité bas vers une interface de niveau élevé, seule les listes de contrôle d’accès permettent la communication entre les interfaces.

Le PIX autorise le trafic venant d'une interface de niveau de sécurité haut (inside ou interne) vers une interface de niveau bas (outside ou externe), sauf si des access-lists limitent ce trafic. Les flux ICMP sont interdits à moins de les permettrent spécifiquement.

Il n’y a pas de mécanisme équivalent au « jump»  de netfilter ou au  «quick» de packet filter quand une règle match on quitte la liste d’accès. Il faut donc ordonner les règles correctement.

Le format des règles :

access-list

<@ipsource [port]> <@ipdestination [port]> .

3.4.6Planets

Planets est un nouveau langage d’expression de politique de sécurité. Il a été développé à l’ENSTB, il est adapté au compilateur CaraHD6, lui-même conçu à l’ENSTB. Ce nouveau langage peut être utilisé pour la configuration des cartes IFT¹⁵ mais également pour définir une politique de sécurité sur d’autres applications.

En fait, avec les langages précédents, les opérations de filtrage ne portent que sur des protocoles fixes et connus par le langage. Planets donne la possibilité de définir n’importe quel protocole que nous souhaitons contrôler et tous les champs que nous souhaitons tester ou filtrer. Il faut ainsi déclarer chaque protocole et chaque champ à analyser, en précisant la position du champ par rapport à l’entête du protocole et sa taille. Ainsi, le langage est évolutif. Dans le fichier de configuration on définit donc les protocoles et les règles de politique de sécurité. Les règles sont analysées séquentiellement du début à la fin, dés qu’une règle est matché, la décision est effectué et on quitte le fichier.

Le mécanisme intéressant de Planets est de pouvoir spécifier des intervalles d’adresses de cette manière (111.222.1.2/32..111.222.1.74/32). Il nous permet donc d’implémenter la « solution découpage ».
La description des règles est la suivante :

: 

3.4.7Tableau récapitulatif des éléments de comparaison 

Firewall (type)	Solution Jump	Solution découpage	Création de chaîne	Politique par défaut
Planets (First matching)	Non	Oui	Non	Fermée
NetFilter (First matching)	Oui	Oui (iprange)	Oui	Fermée ou ouverte
IPFilter (Last matching)	Oui	Non. Intervalles spécifiés grâce au masque.	Non	Fermée
Ipfw (Last matching)	Oui	Non. Intervalles spécifiés grâce au masque	Oui	Fermée
PFilter (Last matching)	Non.	Non. Intervalles spécifiés grâce au masque.	Non	Fermée
PIX (First matching)	Non.	Non. Intervalles spécifiés grâce au masque	Non	Fermée

Pour valider l’approche nous décidons de faire les transformations avec le langage Planets en utilisant la solution « découpage ».

3.4.8Génération de règles pour Planets.

Pour parvenir à la génération de règles pour Planets, on prendra un exemple du modèle Or-bac pour un réseau donné. On effectue une première transformation en XSLT¹⁶ sur cet exemple pour obtenir un premier fichier au format XML, que l’on appelle fichiers de règles génériques. Ce fichier décrit en fait toutes les règles qui sont spécifiées dans le modèle Or-bac conformément à la politique de sécurité. C’est une re-formulation du fichier Or-bac, en un fichier plus proche du modèle d’expressivité des firewalls. Ce premier programme de transformation instancie indépendamment du firewall cible ainsi la politique avant la 2^ème transformation. Concernant ce programme, il a été programmé par d’autres stagiaires et il a dans un premier temps donné satisfaction.
Seconde compilation

La construction de notre seconde XSLT est complètement conditionnée par le choix du pare-feu auquel nous devrons fournir les règles générées. En effet, le principe de fonctionnement ainsi que la syntaxe du pare-feu doivent être pris en compte dans cette étape.

Pour mon projet, le pare-feu choisi fut celui développer à l’ENST : Planets. Une des particularités de Planets est de pouvoir spécifier des intervalles d’adresses. Le principe de fonctionnement, tel qu'il est implémenté dans Planets repose sur deux points essentiels :

• 
  Tout interdire par défaut et n'autoriser que certains flux bien identifiés,
  
• 
  Travailler sur la première règle satisfaisante dans la liste (first matching rule)
  

.

Voici le fichier de règles génériques :

Les résultats suivants sont pour l’exemple développé en annexe :

in: (ipv4_sa = 111.222.2.1/24 .. 111.222.2.54/24 )-> permit
in: (ipv4_sa = 111.222.3.6/24 )&(ipv4_da = 111.222.1.254) &(tcp_dp = 443 )-> permit
in: (ipv4_sa = 111.222.3.6/24 )&(ipv4_da = 111.222.2.1) &(tcp_dp = 443 )-> permit
in: (ipv4_sa = 111.222.3.6/24 )&(ipv4_da = 111.222.3.1) &(tcp_dp = 443 )-> permit
in: (ipv4_sa = 111.222.3.7/24 )&(ipv4_da = 111.222.100.1) &(tcp_dp = 443 )-> permit

Conclusion
Pour pouvoir gérer les exceptions, le programme que j’ai développé ne fait appel qu’à des permissions. Il faudrait développer d’autres mécanismes pour Planets qui nous permettrait d’implémenter d’autres solutions.
Une partie de mon travail consistait en l’étude d’un logiciel permettant la génération de règles pour plusieurs pare feu. Ce logiciel se nomme Firewall Builder. Ce qui nous a intéressé dans ce logiciel c’est qu’on le voyait comme un outil à « pluguer » pour la dernière phase de génération de règles de configuration des firewalls. En fait la spécification et la modélisation d’une politique de sécurité Or-Bac conforme à la politique de haut niveau sont cohérentes et ne comportent pas de conflit.