Synchronisation et monitoring de deux reverses proxy Vulture

J’ai décidé de vous faire profiter de ce projet que j’ai finalisé il y a plus d’un an. Sa mise en place m’a donné entière satisfaction et surtout, m’a simplifié la vie.

J’espère que vous trouverez cet article intéressant et pertinent.

Bonne Lecture 🙂

DEFINITION :

Vulture est un firewall applicatif Open source protégeant efficacement les applications Web.

Basé sur une technologie de Proxy Inverse, Vulture fait barrière entre les applications et le monde extérieur.

Vulture prend en charge toutes les fonctionnalités liées à la sécurité, et notamment :

• L’authentification des utilisateurs
• Le chiffrement des flux
• Le filtrage de contenu
• La réécriture des Urls
• La haute disponibilité
• La répartition de charge

OBJECTIF :

j’ai depuis quelques années cet outil comme reverse proxy dans mon entreprise pour sécuriser l’accès aux sites web. Je l’ai installé sur deux serveurs en Actif/Passif.  Pour améliorer la haute disponibilité, je souhaite que ces deux serveurs fonctionnent en même temps de manière à faire de la répartition de charge et rediriger tout le trafic sur un serveur dans le cas où un des deux tombe en panne. Pour cela, je dois être sûr que leur configuration est identique.

J’utilise Nagios pour monitorer mon système d’information. Je souhaite utilisé cet outil pour monitorer  le bon fonctionnement de mes sites WEB sur chaque reverse proxy et vérifier que la configuration des deux serveurs est identique.

Dans ce document, je vais expliquer ce que j’ai mis en place pour synchroniser  et la superviser ces deux serveurs.

MISE EN OEUVRE DE LA SYNCHRONISATION

SERVEURS

Pour mon projet, trois serveurs seront utilisés :

• Vulture2 : Reverse Proxy principal –> 192.168.0.1
• Vulture1 : Reverse Proxy Secondaire –> 192.168.0.2
• Admin1 : Serveur de synchronisation –> 192.168.0.3

Pour des raisons de sécurité, les transferts de données et le traitement seront à l’initiative du serveur Admin1.

DIFFERENCE DE CONFIGURATION ENTRE LES SERVEURS

Les fichiers à synchroniser seront la base de données SQLite, les fichiers de configurations et le fichier /etc/hosts.

BASE DE DONNEES

La base de données de Vulture se situe dans « /opt/INTRINsec/vulture/sql/db ». Vous pouvez voir sa structure dans le zip fourni à la fin de l’article.

La différence entre la base de Vulture1 et celle de Vulture2 sera seulement le champ “ip” de la table « if ». Cette table correspond aux interfaces http et https. Il faut spécifier à Vulture l’adresse IP d’écoute.

FICHIERS DE CONF

Les fichiers de conf qui diffèrent entre chaque serveur sont  «/opt/INTRINsec/vulture/conf/1.conf » et « /opt/INTRINsec/vulture/conf/2.conf ». Ils correspondent à la configuration des interfaces de Vulture. Il nous faut remplacer les adresses IP (@Ip Vulture2 –> @Ip Vulture1) dans ces fichiers.

FICHIER /ETC/HOSTS

Le fichier host comprend une ligne différente entre les deux serveurs. Cette ligne est propre à chacun d’eux. Nous devons remplacer les noms d’hôtes et l’adresse IP.

ALGORITHME DU SCRIPT DE SYNCHRONISATION

• Récupération de la base de données du Vulture2 vers Admin1
• Récupération des fichiers de conf de Vulture2 vers Admin1
• Récupération du fichier /etc/hosts de Vulture2 vers Admin1
• Sauvegarde du répertoire  /opt/INTRINsec/vulture  de Vulture1 sur Admin1
• Sauvegarde du fichier /etc/hosts de Vulture1 sur Admin1
• Remplacement des IP de la table « IF » sur la base de données de Vulture2 sur Admin1
• Remplacement de l’IP du fichier 1.conf de Vulture2 sur Admin1
• Remplacement de l’IP sur le fichier hosts de Vulture2 sur Admin1
• Remplacement du nom d’hôte sur le fichier host de Vulture2 sur Admin1
• Déplacement de la base de données de Admin1 vers Vulture1
• Déplacement des fichiers de configuration de Admin1 vers Vulture1
• Déplacement du fichier hosts de Admin1 vers Vulture1

PARTIE WEB

La synchronisation sera lancée manuellement à partir de l’interface d’administration de Vulture dans le menu Interfaces puis Synchronisation vers Vulture1. Pour cette étape, nous avons dû configurer apache, créer une page php et donner des droits privilégiés à l’utilisateur « apache ».

CONFIGURATION APACHE

Pour créer cette étape, nous avons ajouté un VirtualHost sur Admin1 qui pointe sur /www/sync_vulture et dont l’adresse d’accès est : http://sync.domaine.fr .
Voici la configuration effectuée :

<VirtualHost 172.17.4.7>
ServerName sync.domaine.fr
ServerAlias sync
DocumentRoot “/www/sync_vulture”

<Directory /www/sync_vulture/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from 172.18.0.0/24
</Directory>
CustomLog /log/httpd/sync.domaine.fr_access.log common
ErrorLog  /log/httpd/sync.domaine.fr_error.log
</VirtualHost>

Nous avons restreint l’accès au réseau 172.18.0.0/24.
Les logs d’accès http sont situés dans « /log/httpd/sync.domaine.fr_access.log »
Les logs d’erreur http sont situés dans « /log/httpd/sync.domaine.fr_error.log »

CREATION D’UNE PAGE WEB EN PHP

Pour lancer notre script perl, nous avons créé un fichier « /www/sync_vulture/sync.php ». Celui-ci exécute le fichier « synchro_vulture.pl » et renvoie sur le navigateur Internet les
étapes du script de synchro et les éventuelles erreurs. Vous pouvez voir le code source du fichier /www/sync_vulture/sync.php en annexe C.

AJOUT DE DROIT A L’UTILISATEUR « APACHE »

Pour que le script php puisse exécuter le script « synchro_vulture.pl » qui doit être lancé en utilisateur « root », nous avons dû modifier le fichier « /etc/sudoers » de cette manière :

User_Alias   SYNC_VULTURE= apache
SYNC_VULTUREALL = NOPASSWD: /usr/bin/perl /www/sync_vulture/synchro_vulture.pl

En modifiant ce fichier, nous permettons à l’utilisateur « apache » d’exécuter en tant que root et sans mot de passe le fichier « /www/sync_vulture/synchro_vulture.pl ».  Pour cela, il faudra utiliser la commande « sudo » avant la commande d’exécution.

Exemple :

$> Sudo /usr/bin/perl /www/sync_vulture/synchro_vulture.pl

AJOUT DU LIEN A L’INTERFACE DE VULTURE2

Le fichier correspondant au menu interface de Vulture2 se situe ici : « /opt/INTRINsec/vulture/www/WEB-INF/tpl/if.tpl »

Il suffit d’éditer ce fichier et d’y ajouter après :

<a href=’?do=sync’><img src=’img/puce.png’>&nbsp;”.$i18n[“synchronize”].”<br></a>

La ligne :

<a href=’http://sync.domaine.fr/sync.php’ target=’_blank’><img src=’img/puce.png’>&nbsp;Synchroniser Vulture1<br></a>

Vous verrez apparaître un nouveau lien dans la rubrique action dans le menu interfaces :

Le lien « Synchroniser Vulture1 » pointe vers « http://sync.domaine.fr/sync.php »

RECAPITULATIF DE LA SYNCHRONISATION

Script de synchro : « /www/sync_vulture/synchro_vulture.pl » à exécuter en root.
Page Web : http://sync.domaine.fr/sync.php accessible via l’interface Web de Vulture2
Les modifications doivent être effectuées seulement sur un des deux vultures.

MISE EN ŒUVRE DE LA SUPERVISION

SUPERVISION DE LA SYNCHRONISATION

Pour superviser la synchronisation entre Vulture1 et Vulture2, j’ai créé un script shell qui permet de comparer la taille des fichiers des différents éléments.

ALGORITHME

• Voici l’algorithme simplifié utilisé pour vérifier la synchronisation entre Vulture2 et Vulture1 :
• On récupère la taille de la base de Vulture2
• On récupère la taille de la base de Vulture1
• On compare les deux tailles
• Si les deux tailles sont différentes, on sort avec un code erreur critique
• On récupère la taille du fichier 1.conf de Vulture2
• On récupère la taille du fichier 1.conf de Vulture1
• On compare les deux tailles
• Si les deux tailles sont différentes, on sort avec un code erreur critique
• On récupère la taille du fichier 2.conf de Vulture2
• On récupère la taille du fichier 2.conf de Vulture1
• On compare les deux tailles
• Si les deux tailles sont différentes, on sort avec un code erreur critique
• On récupère la taille du fichier /etc/hosts de Vulture2
• On récupère la taille du fichier /etc/hosts de Vulture1
• On compare les deux tailles
• Si les deux tailles sont différentes, on sort avec un code erreur critique
• On sort avec un code erreur OK.

Pour récupérer la taille des éléments, nous exécutons les commandes à distance à partir d’Admin1 via le protocole SSH.

Vous pouvez voir le code source du script check_synchro_vulture.sh en archive, à la fin de l’article.

AJOUT DE DROIT A L’UTILISATEUR NAGIOS

Ce script se situe sur admin1 dans /usr/local/nagios/libexec et se nomme check_synchro_vulture.sh. Celui-ci doit être executé en tant que root. Pour cela, nous avons ajouté cette ligne dans le fichier /etc/sudoers :

nagios   ALL = NOPASSWD: /bin/sh /usr/local/nagios/libexec/check_synchro_vulture.sh

De cette manière, l’utilisateur « nagios » n’aura pas besoin de mot de passe pour executer la commande en tant que root. Cette commande devra être lancer de cette manière :

sudo /bin/sh /usr/local/nagios/libexec/check_synchro_vulture.sh

MESSAGE DE SORTIE

Voici les différentes Sorties Possibles :
Code CRITICAL : 2 -> PROBLEME DE SYNCHRO
Code OK : 0 -> PAS DE PROBLEME DE SYNCHRO
Ce script est lancé sans argument pour les deux serveurs Vulture sur Nagios.

RECAPITULATIF DE LA SUPERVISION DE LA SYNCHRO

Script de synchro : /usr/local/nagios/libexec/check_synchro_vulture.pl à exécuter en root.
Commande Nagios : check_synchro_vulture
Service Nagios : synchronisation_des_vultures
Nagios : ce script est appliqué au groupe INTERFACES_VULTURE sur nagios

SUPERVISION DES APPLICATIONS WEB

Pour vérifier les applications hébergées à travers Vulture1 et Vulture2, nous allons  utiliser  une  commande  fournie  par  Nagios.  Elle  se  nomme  check_http.  Cette commande va nous permettre de connaître l’état des interfaces http et https de Vulture et de vérifier  le contenu des pages Web  retourné par Vulture. Nous avons créé un script perl qui permet de superviser  les applications et formate l’affichage et  les codes erreur pour nagios.
Les applications à superviser seront fournies au script de manière automatique en lisant la base de données de Vulture2 stockée sur Admin1 par le script de synchronisation cité en partie II.

ALGORITHME

• On récupère l’adresse IP du serveur à superviser en argument
• On teste que les interfaces http et https du serveur Vulture sont bien actives
• On récupère l’url et le type d’interface (http ou https) de l’application dans la base de données de Vulture récupérée par le script de synchronisation
• On fait un check_http –H @IP_Serveur –I Nom_Application –v pour chaque application de la base
• On teste que les chaines de caractères d’erreurs ne sont pas dans le code source de la page retournée.
• Si l’application est en erreur, on stocke le nom et le type d’interface dans un tableau
• Si un problème survient, on affiche le tableau d’erreur et on sort avec le code erreur critique
• Sinon, on sort avec le code erreur OK.

Ce script est situé dans /usr/local/nagios/libexec/ et se nomme check_vulture.pl

MESSAGE DE SORTIE

Code Critical : 2 -> www.croc-informatique.fr(http)
Ici, l’application www.croc-informatique.fr n’est pas accessible sur le port 80.
Code OK : 0 -> PAS DE PROBLEME AVEC LES URLS

RECAPITULATIF

Emplacement du script : /usr/local/nagios/libexec/check_vulture.pl
Nagios : Ce script doit être appliqué aux deux serveurs Vulture
Commande Nagios : check_vulture
Exécution du script : $USER1$/check_vulture.pl -HOSTADDRESS $HOSTADDRESS$
Service Nagios : Check_site_vulture

Téléchargement des scripts :

Les scripts utilisés dans ce document ne sont pas optimisés mais fonctionnent très bien dans mon entreprise. A vous de l’adapter à votre architecture.

Vous pouvez les télécharger ici.

Le mot de passe de l’archive est : http://www.croc-informatique.fr

Mise à jour disponible ici : http://www.croc-informatique.fr/2010/07/mise-a-jour-synchroniser-et-superviser-vulture/

CONCLUSION

J’espère que cet article vous servira. Si oui, merci de me laisser un petit commentaire pour me dire ce que vous en pensez.

Je vais bientôt virtualiser mes serveurs Vulture. Donc, dans peu de temps, je rédigerai un tutorial d’installation.

Bon courage,

Olivier