Après avoir ajouté des interfaces à mes serveurs Vulture pour prendre en charge mes certificats SSL par domaine, j’ai du mettre à jour mes scripts de synchronisation et de supervision. Pour rappel, la première version ainsi qu’une doc explicative se trouve à cette adresse : http://www.croc-informatique.fr/2009/07/synchronisation-et-monitoring-de-deux-reverse-proxy-vulture/

J’en ai profité pour remanier un peu mon code pour qu’il soit plus exploitable par tous. J’espère que ça servira à quelqu’un.

Attention :

J’ai transformé le script permettant la supervision de la synchronisation du shell en perl. Donc, à présent, il faut mettre dans le fichier /etc/sudoers la ligne :

nagios   ALL = NOPASSWD: /usr/bin/perl /usr/lib/nagios/plugins/check_synchro_vulture.pl

Au lieu de :

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

Modifier également la commande utilisé par Nagios.

La supervision des sites Web hébergés a également changée. La commande s’exécute de cette manière :

./check_vulture.pl -H 192.168.0.1

Il vous faudra modifier les constantes dans la plupart des scripts.

Vous pouvez télécharger la dernière version ici

Mot de passe de l’archive : http://www.croc-informatique.fr

Introduction

J’utilise depuis quelques temps GNS3 pour effectuer quelques maquettes et réviser mes cours Cisco. Afin de maquetter un peu la sécurité ( ACL, ASA), j’ai décidé de prendre un peu de temps pour réaliser une maquette comportant des postes de travail virtuels et ainsi tester en réel l’accès aux ports voulus.

Dans ce document, je montrerais seulement la manière de faire communiquer deux machines virtuelles avec un projet GNS3/Dynamips à partir d’interfaces TAP.

Schéma Cible

Voici ma maquette cible: Deux machines virtuelles (PC1 et PC2) appartenant à deux réseaux différents qui pourront communiquer ensemble via le routeur R0. Ce schéma sera souvent utilisé par la suite.

Schéma 1

Pré-requis :

• GNS3 : Simulateur Cisco ( apt-get install gns3 )
• VirtualBOX : Virtualisation de postes de travail –> http://www.virtualbox.org/wiki/Linux_Downloads

Mise en place des interfaces TAP :

Définition d’une interface TAP :

Une interface TAP permet, dans notre cas, d’établir une communication entre le programme GNS3/Dynamips et les machines virtuelles de VirtualBox. Pour pouvoir créer ces interfaces, nous allons devoir installer les packages bridge-utils et uml-utilities.

Pour plus d’informations, vous pouvez aller consulter ce site : http://www.linux-france.org/prj/inetdoc/articles/vm/vm.network.tun-tap.html

Installation des paquets bridge-utils et uml-utilities :

sudo apt-get install bridge-utils uml-utilities

Maintenant, nous allons pouvoir créer nos interfaces TAP. Pour mon projet, j’ai besoin de deux interfaces TAP pour différentier les communication PC1 ↔ Fa0/0 et PC2 ↔ Fa0/1 comme indiqué sur le schéma 1.

Création d’une interface TAP :

Voici les commandes à taper pour créer les interfaces tap0 et tap1.

Création de l’interface tap0 :

sudo tunctl -t tap0

sudo ifconfig tap0 0.0.0.0 promisc up

Création de l’interface tap1 :

sudo tunctl -t tap1

sudo ifconfig tap1 0.0.0.0 promisc up

Cette configuration est éphémère. Elle disparaît au reboot. Je l’utilise seulement lorsque je fais des maquettes donc ça m’arrange.

Voici ce que j’ai lorsque je tape la commande ifconfig :

tap0 Link encap:Ethernet HWaddr 82:9b:7e:df:7d:9b

adr inet6: fe80::809b:7eff:fedf:7d9b/64 Scope:Lien

UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1

Packets reçus:2216 erreurs:0 :0 overruns:0 frame:0

TX packets:225 errors:0 dropped:174 overruns:0 carrier:0

collisions:0 lg file transmission:500

Octets reçus:175316 (175.3 KB) Octets transmis:126614 (126.6 KB)

tap1 Link encap:Ethernet HWaddr 02:b4:43:5f:e2:34

adr inet6: fe80::b4:43ff:fe5f:e234/64 Scope:Lien

UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1

Packets reçus:2237 erreurs:0 :0 overruns:0 frame:0

TX packets:222 errors:0 dropped:6 overruns:0 carrier:0

collisions:0 lg file transmission:500

Octets reçus:175971 (175.9 KB) Octets transmis:127908 (127.9 KB)

Ainsi, les interfaces tap0 et tap1 sont bien reconnu comme interface par ubuntu. Nous allons maintenant pouvoir créer nos machines virtuelles.

Création des machines virtuelles PC1 et PC2 avec VirtualBox :

OS utilisé:

Pour mes maquettes, j’utilise la distribution très légère Microcore Linux. La version que je vous propose de télécharger a été modifiée par les utilisateurs de GNS3 afin d’avoir quelques outils réseaux intéressant comme :

- netcat

- tcpdump

- iperf

Téléchargement :

Voici ou vous pouvez la télécharger : Microcore-linux v2.10 à cette adresse :http://www.gns3.net/download

Conversion img vers vdi:

Le fichier téléchargé est un fichier img. Il n’est pas exploitable directement par VirtualBox. Pour remédier à ce problème, nous allons devoir le convertir en suivant ces étapes :

Installer qemu :

sudo apt-get install qemu-kvm

Convertir IMG vers RAW

qemu-img convert -f qcow2 /home/olivier/Bureau/linux-microcore-2.10.img -O raw /home/olivier/Bureau/linux-microcore-2.10.raw

Convertir RAW en VDI

VBoxManage convertfromraw -format VDI /home/olivier/Bureau/linux-microcore-2.10.raw /home/olivier/Bureau/linux-microcore-2.10.vdi

Voilà, vous avez un beau disque dure compatible avec VirtualBOX.

Création du disque de PC2 :

Pour PC2, il faudra copier le fichier VDI et changer son UUID afin que VirtualBox puisse l’utiliser. Voici la commande permettant de changer l’UUID d’un fichier VDI :

VBoxManage internalcommands setvdiuuid ‘/home/olivier/Bureau/PC2.vdi’

Création sous VirtualBox:

• Nom de la machine : PC1
• Mémoire 128M ( 20 M devrait suffir)
• Disque existant pointant vers le fichier VDI généré précédemment.

Configuration sous VirtualBox :

Une fois la machine Virtuelle Créé, allez dans la configuration et éditez la partie réseau comme ceci :

Pour le PC1, il faudra utiliser un mode d’accès réseau par pont avec l’interface tap0

Pour le PC2, il faudra utiliser un mode d’accès réseau par pont avec l’interface tap1

Une fois que vous avez démarré vos Vms, il vous faut configurer la partie réseau de chaque VM.

Configuration réseau de l’OS

Configuration PC1 :

sudo ifconfig eth0 192.168.0.1

sudo route add default gw 192.168.0.254

sudo hostname PC1

Configuration PC2 :

sudo ifconfig eth0 10.0.0.1

sudo route add default gw 10.0.0.254

sudo hostname PC2

pour arrêter la machine proprement, taper :

sudo halt

Création de la maquette sous GNS3 :

Attention : Pour avoir accès aux interfaces TAP, il est nécessaire de lancer GNS3 en tant que root :

sudo gns3

Ajoutez un routeur et deux nuages comme indiqué sur le schéma 1.

Configurer le premier nuage avec l’interface NIO TAP : tap0

Après l’avoir ajoutée, elle devrait apparaître sous cette forme : nio_tap:tap0

Ceci permet à GNS3 d’utiliser l’interface tap0 pour émettre et recevoir du trafic réseau.

Effectuez la même manipulation pour le second nuage mais cette fois avec tap1 ( C01 → tap1 ).

Configuration du routeur R0 :

Pour cette maquette, j’utilise cette image c3640-a3jk9s-mz.124-3i.bin et j’ai configuré en tant que slot0, le module NM-16ESW afin de transformer mon routeur en switch de niveau3.

Afin de tester la communication, vous pouvez attribuer des ip directement aux interfaces fa0/0 et fa0/1 comme ceci :

en

conf t

ip routing

int fa0/0

no switchport

ip address 192.168.0.254 255.255.255.0

no shut

int fa0/1

no switchport

ip address 10.0.0.254 255.255.255.0

no shut

end

Conclusion :

Avec tout ça si vous essayez de faire des pings entre les pc, ça devrait fonctionner. Je l’ai déjà fais quelques fois et je n’ai jamais de problèmes sauf à l’utilisation de GNS3. Pensez à démarrer Dynamips avant l’ouverture de votre projet. Si vos routeurs consomment trop de cpu, utilisez idle-pc. Pensez à sauvegarder vos conf via tftp. Ça vous sera très utile.

Bon maquettage

Infos supplementaires :

Ecouter un port :

tcp : nc -l -p 80

udp : ns -l -p 53 -u

Sources :

Tutorial Qemu GNS3 : http://docs.google.com/View?id=dfzhd6z4_397g3jjf4db

Conversion IMG vers VDI : http://bber.biz/index.php?m=02&y=09&entry=entry090212-210202

Autre tuto GNS3 – VirtualBox : http://www.firstdigest.com/2010/02/how-to-integrate-gns3-with-virtualbox/

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

Configuration Syslogd :

Voici mon fichier syslog.conf :

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don’t log private authentication messages!
#*.info;mail.none;authpriv.none;cron.none               /var/log/messages
local1.*                                                /log/site1/all.log
local2.*                                                /log/site2/all.log
# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

Ici on sépare les logs des differents sites. la séparation est utilisé uniquement pour avoir un visu des logs sur le serveur.

Configuration des équipements réseaux :

logging trap warning
logging facility local2
logging IP_SERVEUR_SYSLOG

• logging trap permet de selectionner le niveau de log
• logging facility permet de differencier au niveau serveur syslog les différents sites.
• logging permet de specifier le serveur syslog auquel envoyé les logs.

Préparation de mysql pour la réception des logs parser :

Il vous faut une base de donnée nommé syslog.

Voici la structure des tables :

Script de parsing des logs v1.0 :

#!/usr/bin/perl
# Titre : Parseur de fichier log
# Auteur : Olivier Legras
# Date : 03/08
# Version : 1.0
#
# Description : Ce script permet de décomposé les messages de log reçu via syslog et de les stocker dans
#               une base mysql. Ce script devra être executé plusieurs fois par jour.
#

use Parse::Syslog;
use Date::Manip;
use DBI(); # Utilisation de la BD
use POSIX qw(strftime); #Date du jour
use Getopt::Long;
use strict;

my $help; my $client; my $chemin; my $anee;

#ARGUMENTS

# Affichage de l’aide
my $USAGE = <<EOF;
usage: $0 -options
  Options:
    -help             Affiche cet écran
    -path             Chemin du fichier log à parser
    -partenaire       Partenaire à analyser en majuscule

    Exemple :
    ./parser_syslog.pl -path /log/courneuve/all.log  -partenaire COURNEUVE
EOF

# Commandes optionnelles
&GetOptions(« help »    => $help,
            « path:s »    => $chemin,
            « partenaire:s »    => $client);

if ($help) {
    die « $USAGE »;
}

my $date = strftime « %Y », localtime;
print $date. » – « .$chemin. » – « .$client. »n »;

my $dbh = DBI->connect(« DBI:mysql:database=syslog;host=localhost »,
                          « root », « mdp »,
                          {‘RaiseError’ => 1});

Parser_log($chemin,$date,$client,’Reseau’);

sub Parser_log {

  my $path = $_[0];
  my $annee = $_[1];
  my $partenaire = $_[2];
  my $categorie = $_[3];
  my $temps_ecoule; my $host2; my $timestamp;
  my $type;
  my $message;
  my @liste;

my $parser = Parse::Syslog->new( $path , year => $annee);
while(my $sl = $parser->next) {
    $message=$sl->{text};
    $timestamp=$sl->{timestamp};
    $host2=$sl->{host};
    $timestamp = UnixDate(ParseDate(« epoch $timestamp »), ‘%y-%m-%d %T’);

@liste = split(/:/,$message);

$temps_ecoule = @liste[0];
$type = @liste[1];
$message = @liste[2];
print $timestamp. » – PARTENAIRE : « .$partenaire. »n »;
$dbh->do(« INSERT INTO `syslog`.`message` (`id`,`timestamp`,`host`,`temps_ecoule`,`type_message`,`message`,`partenaire`,`categorie`) VALUES ( »,’$timestamp’,'$host2′,’$temps_ecoule’,'$type’,'$message’,'$partenaire’,'$categorie’); »);
}
$dbh->disconnect();
exec « cat /dev/null > $path »;

}

Veillez a bien renseigner les comptes d’accès à mysql.

Voici un exemple d’utilisation :

./parser_syslog.pl -path /log/site1/all.log  -partenaire Site1

Ce script doit être planifier plusieurs fois par jour.

Archivage de la table message dans historique

Ce script permet de rassembler tous les mêmes messages identiques par host et de stocké le message, la date et l’ heure du dernier message… Puis vider la table message. De cette manière la base de donnée ne prendra pas des proportions démesurées. Ce script sera à executer une fois par jour.

#!/usr/bin/perl
# Titre : Parseur de fichier log
# Auteur : Olivier Legras
# Date : 03/08
# Version : 1.0
#
# Description : Ce script permet d’alleger la base mysql rempli par le script parser_syslog.pl.
#

use strict;
use Parse::Syslog;
use Date::Manip;
use DBI(); # Utilisation de la BD

my $temps_ecoule;my $partenaire; my $categorie; my $host2; my $timestamp2;
my $type;
my $message;
my @liste;
my $host; my $i_message;my $occurence;
my $timestamp_dernier;
my $type ;my $categorie; my $partenaire; my $occurence_total;
my $dbh = DBI->connect(« DBI:mysql:database=syslog;host=localhost »,
                          « root », « mdp »,
                          {‘RaiseError’ => 1});

#HISTORIQUE

##On lit la table message en fonction du hosts
my $sth2= $dbh->prepare(« SELECT * FROM message »);
$sth2->execute();
my $i=0;
my @tab_host;
while (my $ref2 = $sth2->fetchrow_hashref()) {
   @tab_host[$i] = $ref2->{‘host’};
   $i=$i+1;
}
$sth2->finish();

#On vire les doublons de tab_host

my %hachage   = map { $_, 1 } @tab_host;
my @liste_host = keys %hachage;

#on lit les messages de chaque host

foreach $host (@liste_host)
{
      my $sth_host= $dbh->prepare(« SELECT * FROM message WHERE host=’$host’ »);
      $sth_host->execute();
      my $i=0;
      my @tab_host;
      my @tab_message;
      while (my $ref_host = $sth_host->fetchrow_hashref()) {
        @tab_message[$i] = $ref_host->{‘message’};
        $i=$i+1;
      }
      $sth_host->finish();

      # On vire les messages en double

      my %hachage2   = map { $_, 1 } @tab_message;
      my @liste_message = keys %hachage2;

      #On lit le tableau et on compte le nombre d’occurence dans la table message

     #print « HOST = $hostn »;

    foreach $message (@liste_message)
    {
       my $sth_message= $dbh->prepare(« SELECT * FROM message WHERE message=’$message’ AND host=’$host’ ORDER BY timestamp DESC »);
       $sth_message->execute();
       $i_message=0;
       my @tab_message;
       while (my $ref_message = $sth_message->fetchrow_hashref()) {
          # On récupère le dernier message
         if ($i_message==0){
           $timestamp_dernier = $ref_message->{‘timestamp’};
           $type = $ref_message->{‘type_message’};
           $categorie = $ref_message->{‘categorie’};
           $partenaire = $ref_message->{‘partenaire’};

         }
       $i_message=$i_message+1;

      }

      if ($i_message>0){

        #print « Nombre d’occurence du message : $i_message Timestamp=$timestamp_derniern »;
        #print $message. »n »;
        #On vérifier que le message se trouve dans la base historique en fonction
        #du host et du message
        my $sth_histo= $dbh->prepare(« SELECT * FROM historique WHERE message=’$message’ AND host=’$host’ »);
        $sth_histo->execute();
        #:my $i_message=0;
        my @tab_message;

        if (my $ref_message = $sth_histo->fetchrow_hashref()) {
        $occurence = $ref_message->{‘occurence’};

        $occurence_total = $i_message + $occurence;
        print $i_message. » + « .$occurence. » = $occurence_totaln »;

          # on modifie le compteur et la dernière date
          my $sth_historique= $dbh->prepare(« UPDATE `syslog`.`historique` SET occurence=’$occurence_total’, timestamp=’$timestamp_dernier’  WHERE message=’$message’ AND host=’$host’ »);
          $sth_historique->execute();
        }
        else{
          #On ajoute le dernier

          my $sth_historique2= $dbh->prepare(« INSERT INTO `syslog`.`historique` (`id`,`timestamp`,`host`,`occurence`,`type_message`,`message`,`partenaire`,`categorie`) VALUES ( »,’$timestamp_dernier’,'$host’,'$i_message’,'$type’,'$message’,'$partenaire’,'$categorie’); »);
          $sth_historique2->execute();
        }

      }
    $sth_message->finish();
    }

}
#On vide la table message
my $sth_vider= $dbh->prepare(« TRUNCATE TABLE `message` »);
$sth_vider->execute();

#On ferme la session mysql
$dbh->disconnect;

Il ne reste plus qu’ à utiliser les informations de la base mysql pour afficher sur des pages web.

Plan :

- Parser le fichier log (Parse::Syslog)

- Ajouter les données dans une base mysql

- Afficher les donnée en fonction des hosts sur une page mysql

- Gérer le log rotate ( 1 jour, 1 semaine?)

- Afficher les hosts en alerte sur la première page

- Intégré à l’intranet de la prod.

- Gérer peut-etre les alerte par email avec possibilité d’acknowledger… (En option )