Era
Un article de EoleWiki.
Sommaire |
ERA : Editeur de Règles pour Amon
Pour la version stable :
Site de diffusion ERA : http://eole.orion.education.fr/diff/article.php3?id_article=29
Description générale
ERA est un générateur de règles de pare-feu. Il permet de générer la description d'un pare-feu, sa politique générale de sécurité et de la sauvegarder intégralement dans un seul fichier sous un format XML interne à l'application.
Ensuite, il est possible de générer à partir du fichier XML de description du pare-feu, un script de règles iptables pour Netfilter de manière à implémenter ces règles sur un pare-feu cible.
l'interface de conception et le générateur de règles
Era se compose de deux parties :
- le frontend, organise la politique de filtrage du pare-feu et l'enregistre dans un fichier XML.
- le backend, générant le script iptables à partir du fichier XML.
Le backend peut être classiquement installé sur Amon, il peut aussi être utilisé depuis le frontend pour générer un script utilisable sur toute machine compatible iptables/netfilter.
La fenêtre principale représente chaque zone et une orientation des flux qui les relient.
Era propose un ensemble de directives permettant une configuration avancée d'un pare-feu sans avoir à être un expert iptables/netfilter.
En plus du filtrage simple (interdiction/autorisation d'accès), d'autres fontionnalités sont proposées :
- REDIRECTion sur un port local
- NAT, mask et redirection distante
- TIME, application d'horaires à des directives
- Journalisation des directives (utilisation de ulog)
- Rendre une directive optionnelle ((des)activable dans l'EAD, ou depuis un fichier CSV)
- Cacher une directive ((dés)activable seulement depuis un fichier instanciable)
téléchargement depuis le dépot de code
pour les braves, la version subversion d'era :
la documentation en cours est là :
Frontend
L'application graphique permet de gérer les liens entre chaque zone/extremité. Une zone représente un sous-réseau, une extrémité une machine dans un sous réseau. Dans une certaine mesure, une zone est définie par une carte réseau sur le pare-feu (cas particulier : les ethX aliases).
Chaque zone est définie par un nom, une adresse réseau, ainsi qu'un niveau de sécurité. Le niveau de sécurité détermine la position de la zone dans le tableau de flux et donc sa politique de sécurité. Une zone a un accès complet aux zones de niveau inférieur et aucun accès à celles de niveau supérieur.
Une extrémité est un sous ensemble d'une zone. Elle est définie par une adresse IP. Elle hérite du niveau de sécurité de la zone à laquelle elle appartient.
Présentation du tableau des flux
Backend
A la compilation du fichier xml, un certain nombre d'actions sont effectuées :
- définition d'une sous-chaine pour chaque flux (liaison entre zone/extremité)
- création de la politique par défaut (en fonction du niveau des zones)
- ajout des règles correspondant aux directives
- ajout de règles implicites liées au directives
- insertion des inclusions statiques (règle iptables de bas niveau)
Sur Amon, le backend gère aussi l'affichage des règles optionnelles dans l'EAD et récupère leur configuration en cas de mise à jour, et contrôle l'activation des directives cachées.
Utilisation :
aller dans le répertoire era (à priori /usr/share/era)
cd $ROOT/era
lancer le compilateur avec le fichier de modèles adapté
[era]$ ./backend/compiler --help usage: Script de génération de règles iptables à partir d'un modèle ERA.
compiler [options] era_model_file.xml
par exemple :
[era]$ ./backend/compiler modeles/3-zones.xml
différentes options sont possibles :
- -o pour enregistrer les règles iptables dans un fichier cible
- -f pour utiliser un fichier de configuration externe au format csv qui permet d'activer ou de désactiver des directives optionnelles depuis un fichier externe (ou depuis l'application web ead par exemple)
- -a pour spécifier un fichier plat comportant les libellés de directives cachées à activer depuis une source extérieure (c'est possible aussi depuis l'interface era directement)
Explications détaillées
Gestion des formats
versionning des modèles
- version de modèle
- le format interne d'enregistrement xml a un attribut de version qui dépend de la version d'era avec laquelle il a été conçu
- Versions actuelles des fichiers xml :
- version 1.0 (concerne era-1.0 et era-1.1)
- version 1.2 (concerne era-1.2)
Proposition d'une batterie de modèles en version 1.2
A la fermeture, si le modèle ouvert est du format 1.0, Era propose de le convertir en version 1.2. Cette conversion pouvant avoir des effets de bords (c.f. EraFormats) le choix par défaut est de conserver la version d'origine.
Les différents formats xml possibles sur un amon
Il existe plusieurs formats de modèle xml :
- Ancien format (ancien générateur de règles iptables de l'amon 1.0) et nouveaux format (format xml era 1.0)
- Versionning des formats era (1.0, 1.2 et 2.0)
- format 1.0 : format xml implémentant les fonctionnalités spécifiques à era (matrices de flux)
- format 1.2 : insertion de règles implicites, de directives cachées, fonctionnalités de log
- format 2.0 : possibilité d'insertion de directives de qos
comportement du backend
directives cachées
Une directive cachée signifier qu’elle peut-être activée ou désactivée depuis l’interface era. Si une directive possède un tag (qui est la description depuis l'editeur de directives) alors il est possible de la cacher ou de l'activer
Cacher ou rendre visible des directives
Pour cacher une directive, il suffit de mettre son tag dans un fichier externe, le fichier par défaut est /usr/share/era/backend/data/active_tags
Une fois spécifiée comme cachée dans le menu Bibliothèque, cette directive sera alors activable/désactivable depuis le fi- chier externe /usr/share/era/backend/data/active_tags
Il est possible aussi de templatiser (au sens de creole) ce fichier et ensuite, suivant l’existence ou non d’une variable dans le dictionnaire créole, d'afficher ou non le tag, du coup la directive est cachée/montrée automatiquement.
règles implicites : redirect
Un redirect doit inclure aussi une chaine input chaine xxx-bas.
A une règle de forward vient donc se greffer une règle de type input.
la chaine input qui vient se greffer sur le redirect (sur le forward) est implicite.
un forward z1->z2 doublé d'une redirection, ajoute une règle de type input vers le bastion.
- une règle input vers le bastion
- une règle forward z1-->z2
flux descendants
la règle implicite n'est pas nécéssaire dans le snat et le dnat
dnat et snat
dnat
Lors d'un dnat, une règle de type input est doublée d'un forward (s'ajoute à un forward)
même chose pour le masque de snat exemple
un serveur de la dmz répond à une requète sur le port 80 du bastion
un input est transformé en forward
snat
un poste de travail peut surfer sur le web avec l'ip publique du bastion
cela permet de surfer masqué
procedure de log
- il y a une inclusion statique avec une ligne de log générique dans toutes les versions de fichiers
- cette inclusion statique utilise ulog au lieu de log
- le logging est maintenant accessible au niveau de l'éditon des directives (concernant les version ultérieures à 1.0)
Releases et Changelog
Release de 2006 (version 1.2)
Release de 2007 (version 2.0)
