• Les cookies assurent le bon fonctionnement de nos services. En poursuivant votre navigation, vous acceptez l'utilisation de cookies.

Amon, le pare-feu EOLE
Amon , EOLE , Technique

Cet article est initialement paru dans le numéro spécial du Linux Magazine France N°41

« Configurez et optimisez votre firewall » avril/mai 2009 sous le titre « Amon, le pare-feu de l’Education Nationale »

licence : GNU Free Documentation License, merci à Linux Mag pour avoir permis la mise en ligne de l’article

Amon est un pare-feu hautement configurable développé par et pour l’Éducation Nationale et utilisé ailleurs (ministères, collectivités territoriales, entreprises). Il est basé sur la distribution GNU Linux EOLE, qui propose un ensemble de solutions intégrées intranet-internet, (du serveur de fichiers dans les établissements scolaires jusqu’au concentrateur VPN inter-académique, en passant par la gestion de parc et la configuration automatisée de serveurs). Au sein de l’Éducation Nationale les questions de sécurité des réseaux se posent de manière cruciale. L’outil Era, « Éditeur de Règles pour Amon », conçu à l’origine comme un éditeur de règles de pare-feu, est devenu un framework de compilation et d’interprétation de directives de sécurité. Il a permis de mettre en place dans les établissements scolaires une politique globale de sécurité à l’échelle nationale.

EOLE et Amon

Historique

Le pare-feu Amon est né au centre informatique du rectorat de l’académie de Dijon en 2000. Au départ, il s’agissait d’installer des pare-feu dans quelques établissements scolaires de l’académie avec des outils libres. Amon était alors basé sur ipchains. Le passage à iptables est venu assez rapidement avec le noyau 2.4 un an plus tard.

Au début, la génération des règles iptables était un ensemble de script bash. Il est devenu nécessaire, ensuite, de mieux gérer la pile d’instructions iptables. De plus il fallait gérer les données de configuration des serveurs (notamment pour pouvoir les centraliser). Il a été décidé de tout enregistrer dans des fichiers XML.

Aujourd’hui les différents fichiers de configuration, scripts et autres sont générés à partir d’interfaces graphiques codées en python-GTK (gen_config). Il est possible soit de les exécuter sur le serveur au prompt, soit depuis des applications Web ou GTK décentralisées.

En complément, le pôle développement travaille sur un système de Single Sign On (SSO) pour toutes les applications Web EOLE. Les bibliothèques de programmation réseau de bas niveau utilisent python-twisted (le framework GPL de programmation réseau Twisted Matrix).

Et comme tous les produits EOLE, c’est du libre, diffusé sous licence CeCILL. Des paquets ubuntu sont mis à disposition sur le dépot EOLE, et pendant que j’y suis, pour compiler des paquets, eole-epack est un outil graphique de compilation à partir d’un dépot subversion, c’est assez pratique. Cet outil sera même bientôt utilisable depuis l’extérieur. Dans la ferme de compilation EOLE on génère une distrib entière un peu comme on génère une page Web, c’est à dire sans plus y penser…

Une grande partie des logiciels EOLE sont des logiciels de configuration. A l’installation, ce qui prend le plus de temps, c’est la copie du cd sur le disque dur. Pour la configuration globale, la technologie Créole (pour « Création EOLE ») est utilisée. Elle est rapide et permet l’industrialisation de la mise en place des serveurs.

Amon et l’outil Era

Revenons à Era. C’est un logiciel en deux parties installé par défaut sur les pare-feu Amon. La première partie du logiciel est graphique (GTK). La deuxième partie est un outil ligne de commande, le compilateur-générateur de règles iptables, de QOS (qualité de service), et de règles authentifiantes (grâce à l’intégration de NuFW dans Amon). Era peut-être lancé directement sur un Amon, ou bien depuis n’importe quel poste de travail linux, ou même installé sur un poste Windows.

l'interface au lancement Fig. 1 : L’interface d’Era au lancement, la fenêtre principale représente le tableau des flux

À première vue, l’interface d’édition est déjà très différente de celle d’un éditeur de règles classique à la Firewall Builder. La configuration de pare-feu est orientée flux de directives. Nous y reviendrons.

Sur un Amon, après avoir édité et enregistré le XML dans l’interface Era, il faut lancer la ligne de commande en root pour appliquer les règles de pare-feu :

$ service bastion restart
Si vous êtes à distance, vous pouvez stocker la configuration XML sur un serveur de centralisation des configurations (le serveur Zéphir). Ce serveur est utilisé dans le cadre de la gestion de parc pour déployer les modèles. Il est ainsi possible de reconfigurer plusieurs centaines de pare-feu en quelques minutes. Pratique en cas d’alerte de sécurité.

Sur un autre type de pare-feu qu’Amon vous ne pouvez pas bénéficier de cette possibilité d’envoi de la configuration, mais vous pouvez simplement générer un script de règles iptables à lancer manuellement. Si vous êtes directement sur un Amon, vous pouvez en profiter pour réinstaller la configuration complète du système en tapant en root :

$ reconfigure
Voilà, quand même c’est pas très compliqué. Si vous voulez adapter le pare-feu à vos différents besoins, il va vous falloir comprendre un peu le fonctionnement de l’interface graphique.

La représentation du réseau avec Era

Les niveaux de sécurité

Voici l’idée principale : la problématique d’intégrité et de cohérence doit être assurée au moment de la configuration du pare-feu. Et pour raisonner sur un réseau, il est nécessaire de simplifier l’information, de sorte que l’observation du système fournisse une vue d’ensemble.

Le modèle est en fait une gestion par flux : je donne plus de droits à ce à quoi je fais le plus confiance (j’autorise du plus sécurisé vers le moins sécurisé) et je donne moins de droits à ce à quoi je fais le moins confiance. C’est le modèle de l’écoulement fluide : ça passe, sauf directive contraire (directive de type barrage), de ce qui est le plus sécurisé vers le moins sécurisé (flux descendant), et ça ne passe pas, sauf directive contraire (directive de type pont ou aqueduc), de ce qui est le moins sécurisé vers le plus sécurisé (flux montant).

Centrons-nous sur le pare-feu (c’est la zone la plus sécurisée). Autour, il y a internet (la zone extérieur, c’est la zone la moins sécurisée). Puis d’autres cartes réseau ou tunnels (dans un établissement scolaire il y a typiquement deux autres interfaces réseau : la zone pédagogique et la zone administrative et au moins un tunnel vers l’académie).

Affectons ensuite des niveaux de sécurité à chacune de ces zones.

Fig. 2 : Les niveaux de sécurité

Ce choix détermine une vue par flux entre chaque zone. Par zone, entendons une carte réseau. A l’intérieur, vont être définies des directives de sécurité. Et enfin, une politique par défaut (par exemple, sauf directive contraire, ce qui vient de l’extérieur est peu sécurisé, donc doit être bloqué).

Le modèle devient exécutable

Au niveau du code, le modèle en mémoire après chargement du XML ressemble à ce qu’on peut reproduire ici au prompt python après avoir importé les objets de la librairie :
>>> from era import fwobjects
>>> z1 = Zone('z1', 30)
>>> z2 = Zone('z2', 50)
>>> assert z1 < z2
True
>>>
Pour créer une zone, il faut un nom et un niveau de sécurité (en plus de l’interface réseau). Les zones sont alors immédiatement ordonnées les unes par rapport aux autres, ce qui donne le tableau des flux montants et descendant une fois inséré dans l’objet matrice de flux :
>>> matrix = MatrixModel()
>>> matrix.add_zone(z1)
>>> matrix.add_zone(z2)
Deux flux sont créés :
[Flux : [z1 <===> z2], Flux : [z2 <===> z1]]
Le modèle exécutable apparaît comme bien plus pratique dans le cadre des méthodes agiles (en principe au labo on programme toujours en binôme, et les développements sont dirigés par les tests). Il dérive directement de la représentation que l’on se fait du réseau, la logique métier, sans avoir à être décrit dans un ou plusieurs langages de haut niveau ou un langage de configuration.

Bien sûr ces créations d’objets sont transparentes, elles se font naturellement depuis l’interface graphique (par exemple la fenêtre d’édition des zones). Ce qu’il est important de constater, c’est que derrière l’interface graphique il y a un modèle objet qui évolue au fur et à mesure de la conception du pare-feu.

Les directives de sécurité

Au plan des décisions à prendre, il existe des niveaux d’analyse qu’il faut privilégier. La notion de directive représente ce niveau d’abstraction. Qu’est-ce qu’une directive ? C’est l’abstraction d’une action comme « j’autorise les profs à aller surfer sur internet » ou « j’interdis aux élèves l’accès à la zone administrative ».

« j’autorise, j’interdis, je redirige vers… », des actions simples qui vont produire des quantités de lignes d’instruction réseau, ou de QOS, ou de règles authentifiantes dont l’imbrication est complexe mais dont nous sommes sûrs qu’elle reste cohérente. De plus, la configuration de pare-feu devient possible pour quelqu’un qui ne maîtrise pas tous ces langages de bas niveau (iptables, trafic control…).

Un mécanisme de directives optionnelles permet d’activer ou de désactiver des directives depuis diverses sources, notamment depuis des interfaces Web. Cela permet de définir des consignes qui ne sont réellement appliquées que sur demande. Par exemple, il est possible de décider s’il faut couper momentanément l’accès au Web ou au chat pour une salle informatique pendant un cours.

Les directives dépendent de l’échelle. A une grande échelle, (c’est-à-dire une petite surface, celle d’une salle info par exemple) il faut pouvoir rendre la configuration adaptable. A une plus petite échelle (une plus grande surface, l’échelle d’un établissement ou d’une académie) on peut choisir de rediriger systématiquement les élèves vers le proxy établissement.

En plus, un mécanisme de directives dites « cachées » est prévu : ces directives ne s’activent que si nécessaire. Par exemple, Amon peut détecter s’il dispose d’un proxy installé sur le serveur et ainsi l’activer en conséquence.

Enfin, à une échelle encore plus petite, l’échelle nationale, EOLE fournit les moyens techniques pour appliquer de grandes orientations et préconisations de sécurité en proposant des modèles. Ce sont des fichiers XML, qu’on appelle fichiers de modèles de pare-feu prédéfinis (modèle 3 zones, 4 zones, 5 zones).

Ces modèles XML peuvent être « templatisés » c’est-à-dire que les valeurs des ips et des réseaux ne sont pas renseignées directement dans le fichier de manière à assurer la généricité. Il est aussi possible d’imbriquer hiérarchiquement les modèles pour en faciliter la maintenance (un modèle 4 zones hérite d’un modèle 3 zones, si on modifie le 3 zones les autres modèles répercutent la modification).

Bien souvent dans les académies, il suffit de modifier un seul fichier XML pour mettre à jour en quelques minutes plusieurs centaines de pare-feu Amon. Allez donc tenter de faire la même chose avec un simple éditeur de règles !

Les directives dans le modèle

Pour poursuivre sur les objets du modèle, il se passe quelque chose comme ceci dans la matrice au moment de l’ajout d’une directive :

Soit à partir du XML :

>>> dir_node = '''<directive id='1' service='serv1' priority='1' action='1' libelle='directive'>
<source name='extr1' /><source name='extr2' /><destination name='extr3' />
</directive>'''
>>> xmldoc = parseString(dir_node)
>>> directive = domparsers.instantiate_directive_from_dom(xmldoc)

Fig. 3 : L’éditeur de directives. Ici pour affecter une authentification à la directive, il suffit de glisser-déposer le groupe d’utilisateurs choisi.

Soit depuis l’interface d’édition des directives, il se passe alors cela :

>>>directive = Directive([extremite1], [extremite2]], service1, ACTION_DENY, 1)
Puis dans tous les cas, la directive est insérée dans la matrice au bon endroit dans les flux:
>>>matrix.add_directive(directive)

Utilisation de l’interface graphique

Voilà, maintenant que vous en savez plus sur le modèle, la prise en main de l’interface graphique sera plus évidente. Le but du jeu est de créer des directives. Au lancement vous avez le tableau des flux. Vous pouvez alors ajouter ou supprimer des zones. Ce tableau a autant de lignes et de colonnes que de zones. En cliquant droit sur une zone vous pouvez accéder à sa configuration et y créer des extrémités (ajout de machines ou de sous-réseaux).

Dans le tableau il y a autant de cases que de flux, cliquez sur une case pour ajouter une directive, vous obtiendrez la liste des directives existantes. Lors de l’ajout vous accéderez à l’éditeur de directives fonctionnant par glisser-déposer d’extrémités, de services et/ou d’utilisateur.

Pour entrer un peu dans les détails, une extrémité est une ip, une plage d’ip ou un sous-réseau. Un service est un ensemble protocole, port ou plage de ports. L’action peut-être une autorisation, une interdiction, une redirection ou du DNAT ou SNAT. La matrice comptabilise les directives et leur priorité, et les ajoute aux bons emplacements dans les flux.

Pour plus de détails, je vous renvoie au manuel d’utilisation.

Le compilateur

Fonctionnement du compilateur

Du point de vue de la sécurité, il n’y a pas de niveau d’analyse privilégié : au final tout est ramené à une pile d’instructions réseau. Récapitulons : ces échelles sont toutes très différentes, c’est le modèle et la définition des directives qui permet de les unifier. Mais comment garantir l’intégrité et la cohérence d’une pile entière d’instructions iptables? Et entre les différents réseaux ? Et par rapport aux différentes technologies (ipsec, QOS…) ?

Le compilateur de règles récupère les directives, les classe par types (directives standard en ACCEPT ou en DROP, de redirection, de DNAT ou de SNAT) et génère les règles iptables, les règles de QOS et les règles authentifiantes correspondantes.

Regardons comment ça se passe au niveau du code et décomposons les différentes étapes :

récupérons la matrice :

>>> from era.initialize import initialize_app
 >>> matrix_model = initialize_app('3zones.xml')
initialisons le compilateur iptables :
>>> from era.compiler import Compiler
>>> from era.iptwriter import IPTWriter
>>> compiler = Compiler(IPTWriter, sys.stdout)
passons la matrice en paramètre au compilateur :
>>> compiler.compile(matrix_model)
les règles iptables sont alors générées (dans ce cas, sur la sortie standard).

Il y a des processeurs de directives. Ce qui revient, lorsqu’on dispose d’une directive, à faire ceci :

>>> proc = era.processors.get_processor(directive)
>>> rules = proc.process()
>>> for rule in rules:
>>> writer.append_rule(rule)
A un processeur correspond un type de directive (DNAT, SNAT, …).

Observez la dernière ligne ci-dessus (l’itération sur la liste), ce sont des objets modélisant une règle iptables.

La génération des règles iptables

Maintenant, nous arrivons au niveau des règles iptables. Au passage, le compilateur intègre une modélisation objet de bas niveau des règles iptables.

Là aussi, plutôt que de créer une syntaxe de haut niveau qui pourra ensuite être compilée en langage de plus bas niveau, avec Era il y a un modèle exécutable mais sans syntaxe (sans langage associé). Chacun sait que la définition d’un langage et de son arbre de syntaxe est lourde en temps et en moyens. Les projets comme HLFL (high level firewalling language) ou WallFire cherchent depuis des années à définir des syntaxes possibles.

Au niveau du compilateur, une directive n’est pas nécessairement associée à une unique règle iptables. Suivant le type de directive, le comportement du compilateur est différent. En effet, il se peut que le compilateur rajoute des règles implicitement, par exemple, dans le cas d’une redirection, une règle iptables de FORWARD doit être accompagnée d’une règle INPUT (si je redirige les élèves depuis internet sur le port 3128 d’un proxy de la dmz, je dois bien ouvrir ce port sur le bastion d’abord).

Une seule directive, si elle est composée d’un groupe de services, d’une liste d’extrémités ou autre, peut générer une grande quantité de lignes iptables. Une directive va générer autant de règles qu’elle compte d’extrémités, de services, et des règles implicites.

Toutes ces règles sont indispensables pour que ça marche. Une seule action de haut niveau doit se traduire en plusieurs règles iptables.

Le filtrage authentifié et la qualité de service

Les règles authentifiantes sont gérées par NuFW.

Era récupère les directives authentifiantes au niveau du compilateur iptables et rajoute l’instruction -J NFQUEUE. De plus, pour les redirections, un marquage est affecté. Cette marque est spécifique à chaque groupe d’utilisateur. Un fichier d’ACLs est généré sous cette forme :

[directive_description]
proto = 6
srcport = 1024-65535
outdev = eth0
indev = eth2
gid = 10001
 ...
Le GID permet de déterminer à qui appartient cette ACL.

Quant à la QOS, elle est limitée à la patte externe. Un script est généré. Il représente une sous-partie du modèle global de la matrice de flux.

C’est réglable depuis l’interface graphique. Il s’agit de diverses poignées de déplacement qui permettent de répartir la bande passante vers les différentes zones. La taille allouée est proportionnelle et la vue correspond simplement à des pourcentages de la bande passante totale (que l’on définit).

La simulation et les tests

La sémantique d’Era (c’est-à-dire ce que fait effectivement le programme) est conforme à sa spécification (c’est-à-dire ce que l’on voulait que le programme fasse). Les techniques de tests de génération des règles sur des jeux de réseaux ou de simulation sur un réseau physique passent difficilement à l’échelle : en bref il est impossible de traiter tous les cas. Notre manière de vérifier a été de faire des tests et de constater que le programme correspond bien à sa spécification dans un grand nombre de cas donnés.

Il y a eu pas mal de tests et on aurait pu encore pousser ça avec des simulateurs comme nf-sim, un simulateur Netfilter dans l’espace utilisateur. En exécutant ou en simulant le programme dans un grand nombre d’environnements suffisamment représentatifs des exécutions possibles, il devient clair qu’on peut dormir sur ses deux oreilles.

La compilation dynamique

Récapitulons : une règle iptables générée aura beau être syntaxiquement correcte et bien positionnée, si elle ne s’inscrit pas dans un contexte elle pourra être sémantiquement fausse (la sémantique au sens ce que fait effectivement la pile d’instructions réseau).

Le choix qui a été fait est une modélisation qui prend de la distance par rapport à une syntaxe. C’est l’interface graphique, donc le modèle, qui permet de fédérer les décisions, ainsi que le compilateur et son comportement de bas niveau.

Y a-t-il un moyen de faire du « reverse », de décompiler ? De passer d’un résultat de iptables -L ou iptables-save à un modèle objet ? C’est possible en l’état actuel du compilateur, c’est possible parce que le compilateur est statique, c’est-à-dire non contextuel.

Mais si l’on veut dépasser les limitations liées au cumul des caractéristiques d’une directive (l’authentification, la qualité de service, le marquage, la journalisation…), le modèle lui-même doit devenir dynamique.

La modélisation par flux et les espaces d’objets qui constituent le modèle doivent devenir dynamiquement adaptables, contextuels. Un peu comme une syntaxe dont la grammaire serait contextuelle. Cela devient indispensable notamment si l’on veut approfondir les possibilités dans Era liées au filtrage authentifié.

Conclusion

Dans l’avenir, le compilateur devra modifier son comportement en fonction de la pile des instructions réseau qu’il rencontre. Si la compilation et les espaces d’objets dynamique vous intéressent, je vous suggère pour approfondir cette question d’aller faire un tour du côté de PyPy, le compilateur dynamique du langage dynamiquement typé Python, codé en Python lui-même, et de revenir lire le code d’Era dans… pas pour tout de suite en tout cas…

Que Patrick McHardy change nos habitudes en nous proposant nftables, peu importe. C’est très certainement mieux. Les règles en seront plus condensées mais les problématiques d’accumulation resteront : il s’agit toujours d’une pile d’instructions réseau. Que les règles soient générées ou non, si on n’y prend pas garde elles finissent par tourner au plat de spaghettis, se confondre puis au final se contredire les unes les autres, d’où l’importance de disposer d’une vue d’ensemble.

Jusqu’à présent, les outils EOLE se sont adaptés à une échelle de travail nationale sur des milliers de serveurs et avec des centaines de milliers d’utilisateurs (les élèves, les profs et les administratifs). Nous allons continuer nos efforts.

Commentaires

Aucun commentaire pour l'instant, soyez le premier !

Cadoles recrute !

Nous recherchons de nouveaux coopérateurs :