Invictus-firewall
De Wiki de la communauté Mandriva.
Sommaire |
Présentation
Invictus Firewall, ça sonne bien mais à quoi ça sert ?
Imaginons la situation classique suivante. J'ai un réseau interne possédant un serveur web par exemple. Ce serveur est accessible depuis l'extérieur par l'intermédiaire d'une machine faisant office de pare-feu. Le pare-feu tombe en rideau … de fumée, évidemment ! Galère.
Si nous avions une deuxième machine qui puisse prendre le relais du pare-feu ce serait déjà un progrès. Qu'à cela ne tienne, ucarp va nous aider à réaliser cela de manière simple. Comment ? Une des deux machines sera active (maître) et l'autre sera en attente (esclave) d'une éventuelle défaillance de la première.
UCARP
1)ucarp va faire apparaître les deux machines physiques (ayant chacune leur propre adresse réseau) comme une machine virtuelle ayant une adresse réseau virtuelle unique. C'est cette adresse virtuelle qui sera utilisée pour accéder au serveur web.
2)Le service ucarp (daemon) installé sur le maître s'occupe d'envoyer régulièrement des signaux au service ucarp installé sur l'esclave pour le rassurer et lui dire que tout va bien.
Lorsqu'une demande est envoyée à l'adresse virtuelle, les deux services l'interceptent, mais seul celui qui est sur la machine active l'honorera.
Au démarrage, le service écoute sur le réseau s'il y a déjà un maître. Si oui, il attend, sinon il devient maître. Il est possible de désigner un maître préféré par l'intermédiaire de l'interface de configuration (on peut aussi le faire à la main, mais on peut aussi ne pas utiliser mandriva ;).
La transition de l'état "maître" vers l'état "esclave", ou inversement, nécessite de mettre la machine en état de répondre à la demande. Cela se fait par l' intermédiaires de scripts (que le paquetage invictus-firewall met en place automatiquement).
Les deux services auront besoin pour communiquer:
- d'un mot de passe partagé - d'un numéro de reconnaissance commun, un identifiant partagé (ID virtuel)
En outre, chaque service devra connaître
- l'adresse réelle de l'interface réseau de sa propre machine.
Il reste un problème qui a « une certaine importance » comme disait Reggiani (Serge).
Si la panne du maître se produit en cours de communication sur le serveur, le client sera déconnecté et n'en sera peut-être même pas averti. Jérémiades en perspectives... C'est là qu'intervient ct_sync.
CT_SYNC
Il s'agit d'un module du noyau destiné à faciliter l'implémentation de grappes de pare-feux utilisant netfilter et capables de surmonter la défaillance d'un élément.
Soyons simple. Réduisons la grappe à deux éléments: les deux machines précédentes.
Le maître transmet (forwarding) les demandes de l'extérieur vers le serveur web et maintient (c'est normal) une table de l'état des connexions en cours.
ct_sync permet de copier cette table vers l'esclave. En fait, le maître envoie un message à chaque changement d'état. L'esclave est donc en permanence à jour pour peu qu'il soit attentif à ce qu'on lui dit. En cas de panne du maître, et grâce à ucarp, l'esclave peut reprendre la main à la volée. Le client, roi mais naïf, ne se doute de rien !
Un avantage de ce système, c'est que les règles netfilter des deux machines ne sont pas nécessairement identiques (mais c'est mieux généralement).
Les sigles:
UCARP (Userland Common Address Redundancy Protocol) signifie PRACU (Protocole de Redondance avec Adresses Commune en zone Utilisateur – traduction libre).
CT_SYNC (connections tracking synchronisation – réplication de l'état du suivi de connexions).
Installation
Pour installer invictus-firewall, lancez  Installer et désinstaller des logiciels et recherchez le paquet invictus-firewall.
Sélectionnez-le et cliquez sur Appliquer (Aide). Vous pouvez également l'installer en utilisant la console en tant qu'administrateur avec la commande suivante : urpmi invictus-firewall |
Contenu
Le paquetage, invictus-firewall, contient:
/etc/rc.d/init.d/ctsync : un script ajoutant une règle à netfilter pour l'envoi des messages signalant la modification de la table de suivi des connexions. Ce script est installé comme un service system V.
/etc/sysconfig/ctsync : un fichier de configuration utilisé par le script précédent.
Dans /usr/share/invictus-firewall/, on a ucarp-action.sh, ucarp-down.sh et ucarp-up.sh : un jeu de scripts destinés mettre ucarp en mode esclave (ucarp-down) ou maître (ucarp-up) et à placer la machine en état d'utiliser la table de suivi de connexion (ucarp-action).
Ces scripts sont configurés par drakinvictus.
Configuration
On lance drakinvictus dans une console root. Dans mandriva 2008, on accède à la configuration depuis le centre de contrôle de mandriva dans l'onglet Sécurité en choisissant Configuration avancée des interfaces réseau et du pare-feu
Résumé
DrakInvictus est une interface graphique permettant de faciliter la configuration d'ucarp et ct_sync.
1) ct_sync voir netfilter
En gros, ct_sync est un module du noyau qui sert à répliquer la table d'état du sous-système de suivi de connexions de netfilter de l'ordinateur maître vers l'ordinateur esclave. Lorsque le service ct-sync est lancé, une règle est ajoutée à netfilter via iptable et le module est chargé.
2) ucarp (/usr/share/doc/ucarp/README) est un deamon qui permet de coupler deux serveurs en remplaçant leurs adresses ip réelles par une adresse ip virtuelle. Ce daemon est lancé sur chacun des deux ordinateurs, l'un en tant que maître l'autre en tant qu'esclave. Le maître envoie régulièrement un signal à l'esclave qui prend le relais du maître si celui-ci est défaillant et que le signal est absent. Le serveur virtuel possède une adresse virtuelle et un identifiant compris entre 1 et 255. Les deux daemons communiquent via un mot de passe crypté. De l'extérieur l'accès au service se fera via l'adresse virtuelle.
3) drakinvictus, permet de configurer l'hôte sur lequel il est lancé.
Redondance réseau: c'est la partie ucarp
interface: interface du réseau sur lequel se trouvent les deux serveurs.
adresse réelle: adresse ip de l'interface
adresse virtuelle: adresse virtuelle partagée par les deux serveurs
ID virtuel: identifiant partagé (identique sur les deux machines) compris entre 1 et 255
Mot de passe: partagé lui aussi. Il n'apparaît pas en clair sur le réseau.
Démarrer en maître: un des deux hôtes pourra être déclaré maître, cela permet à ucarp de gérer la préemption si le maître se réveille après la défaillance. Sinon, une procédure d'arbitrage automatique entre les deux hôtes permet de répartir les rôles. C'est la configuration préconisée.
Réplication pare-feu: concerne ct_sync
synchroniser les tables conntrack du parefeu: cocher pour oui, c'est ce qu'on recherche en général.
synchronisation de l'interface réseau: nom de l'interface connectée au réseau sur lequel communiquent les deux serveurs
mark bit: numéro de bit du champ de marquage de connexion utilisé pour le suivi de connexion. On peut laisser à 30.
4) Pour que ce système fonctionne, il est nécessaire que les programmes serveurs utiles (serveur de mail par exemple, ou apache) sur chaque ordi soient configurés de manière identique.
5) Ce système n'est pas en soit un pare-feu mais permet de répliquer l'état du trafic de l'un vers l'autre pour que la défaillance du premier n'ait pas de conséquence sur le service rendu. Les deux pare-feux (des deux machines) peuvent avoir les mêmes règles, c'est plus simple mais ce n'est pas obligatoire.
6) Ce qui précède n'est qu'un résumé pratique (ou qui se veut tel...) des renseignements tirés de la lecture des scripts du paquetage invictus-firewall et de la documentation citée à laquelle il faut bien évidemment se reporter avant toute mise en oeuvre.
7) Merci de me signaler les erreurs.
Voir aussi:http://blog.mandriva.com/2006/10/06/invictus-firewall/
