ERA
application graphique de génération de règles de sécurité
à quoi ça sert ?
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.
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.
Note
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.
- format xml de description du pare-feu
- modélisation pour amon
- le générateur de règles
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 graphique
La fenêtre principale : les zones, et les flux qui les relient.
Note
- description de la fenêtre principale
- les directives de sécurité sont classées d'après leur origine et
leur destination.
- mentionner qu'il y a deux cases par flux
- un éditeur orienté flux de règles
- l'organisation des directives de sécurité
orientation des flux
pour le modèle trois zones...
politique de sécurité par défaut
... ce qui est autorisé et ce qui est interdit
Chaque zone est donc reliée à une autre zone par des flux de
règles. Les flux montants concernent les interactions d'un niveau de
sécurité plus faible vers un niveau de sécurité plus élevé, et
réciproquement pour les flux descendants.
résumé du modèle de sécurité
Récapitulatif des composants de la matrice de flux
- les zones et les extrémités
- les flux
- le tableau des flux et leur orientation
- les directives de sécurité (montantes et descendantes)
l'éditeur de directives
exemple : de la pédago vers l'extérieur, on ne peut qu'interdire
Note
une directive est de type autorisation ou interdiction, mais
ça ne veut absolument pas dire qu'il y a des choses qu'on ne
peut interdire ou autoriser ! Il suffit simplement de changer
de case.
description d'une directive
- les types de directives
- autorisation
- interdiction
- redirection
- snat, dnat
- les extrémités d'origine et de destination
- le service (ou groupe de services) qui y est associé
c'est au niveau de la directive que sont définies toutes les
actions possibles (plages horaires, log...)
Note
ce qui est accessible à une directive (extrémités, services)
doit être défini à l'extérieur.
intégration sur un amon
- les variables créole sont accessibles
- les directives optionnelles (au niveau de l'ead)
- les directives cachées et l'imbriquation de modèles
- l'envoi d'un modèle vers zephir
Note
- il est donc possible de concevoir un parc de pare-feu
parfaitement maintenable
- pas d'équivalent semble-t-il actuellement, même dans
le monde propriétaire
fonctionnalités de bas niveau
- plages horaires
- logs
- inclusions statiques de règles iptalbes
- netbios
- ...
Note
- on n'est donc jamais bloqué, il est toujours possible
d'intervenir au plus bas niveau, sur le lance.firewall
- description rapide de l'arborescence amon (ce que fait le
service bastion restart ou le reconfigure
- les fichiers modèles sont disponibles dans /usr/share/era/modèles
- le répertoire source est /usr/share/eole/bastion/modeles
- le fichier template est /etc/eole/bastion.xml, c'est une copie d'un des fichiers du répertoire des modèles
- le fichier instancié est /usr/share/eole/bastion/xml/bastion.xml, c'est lui qui va servir pour la génération de l'iptables.
la suite : mise en pratique !
- des questions ?
- ressources : site de diffusion eole, documentation utilisateur, la page era du wiki
- etape suivante : conception et design de pare-feu avec era
- merci...
