Syslog-ng

user_icon admin | icon2 Syslog | icon4 14/12/2008 17h16| Type doc: article| Type File: xml| icon3 No Comment

Supervision des logs : syslog-ng


1. Syslog-ng

Le daemon Syslog-ng ( ng pour nouvelle génération ) est compatible avec son ainé syslog, il lui ajoute une grande souplesse dans la gestion des logs. Il est ainsi possible de décrire la source du log qui peut être le daemon lui-même, un fichier, pipe, réseau. La destination des journaux est elle aussi variée : fichier, tcp, usertty, program. Le filtre sélectionnera les lignes de logs qui nous intéresseront et pour finir le log composé d'une source , d'une destination et d'un filtre assemblera le tout. C'est grace à ce dernier que nous pourrons affiner le filtrage de nos logs. Je n'en dirais pas plus sur la configuration de syslog-ng, de nombreuses documentations et exemples sont disponibles sur le net.

Testons l'exemple simple mais néanmoins très utile publié dans le Linux Magazine Hors Serie n°37 : le filtrage des accès ssh

Dans le fichier /etc/syslog-ng/syslog-ng .conf sont déjà définis de nombreuses source, destinations et log. La source que nous utiliserons est 's_all', elle représente les fichiers générés par syslog-ng (voir sa définition dans le fichier de conf).

Le filtre ' f_ssh_login_attempt ' filtre les messages contenant 'Failed' ou 'Accepted' générés par le daemon sshd

filter f_ssh_login_attempt {
    program("sshd.*")
    and match("Failed|Accepted");
};

La destination ' d_mysql ' est une base de donnée Mysql ... ça devient intéressant :)

destination d_mysql {
        program(
                "mysql -u syslog --password=syslogng syslog -B > /dev/null"
                template("INSERT INTO logs (host, facility, priority,
                        level, tag, date, time, program, msg) VALUES ( '$HOST', '$FACILITY', '$PRIORITY', '$LEVEL',
                        '$TAG', '$YEAR-$MONTH-$DAY', '$HOUR:$MIN:$SEC', '$PROGRAM', '$MSG' );\n")
                template-escape(yes)
        );
};

La directive 'template' / 'template-escape' génère une requète SQL à la volée en remplacant les variables issues de la ligne de log.

Et enfin le log associe le tout

log {
        source(s_all);
        filter(f_ssh_login_attempt);
        destination(d_mysql);
};

Et voilà avec 3 définitions nous venons de mettre en oeuvre un puissant système de filtrage.

Il ne reste qu'a créer la base pour en vérifier le fonctionnement.

mysql> CREATE DATABASE syslog;
mysql> GRANT ALL ON syslog.* TO syslog@localhost IDENTIFIED BY 'syslogng';
mysql> FLUSH PRIVILEGES;

Le fichier de création de la base 'syslog-ng.sql' :

USE syslog

CREATE TABLE logs (
host varchar(32) default NULL,
facility varchar(10) default NULL,
priority varchar(10) default NULL,
level varchar(10) default NULL,
tag varchar(10) default NULL,
date date default NULL,
time time default NULL,
program varchar(15) default NULL,
msg text,
seq int(10) unsigned NOT NULL auto_increment,
PRIMARY KEY (seq),
KEY host (host),
KEY seq (seq),
KEY program (program),
KEY time (time),
KEY date (date),
KEY priority (priority),
KEY facility (facility)
) TYPE=MyISAM;

que l'on exécute

mysql -u syslog -psyslogng syslog < syslog-ng.sql

Redémarrage de syslog-ng :

/etc/init.d/syslog-ng restart

Les prochains accès ssh sont maintenant logués en base :)

2. Une surcouche Catalyst

On va maintenant créer une interface web à notre base, le framework Catalyst nous sera d'une grande aide.

$ catalyst.pl Catalog
$ cd Catalog

Notre application 'Catalog' est crée, ajoutons lui un schéma d'accès aux données:

$ ./script/catalog_create.pl model DB DBIC::Schema DB::Schema create=static dbi:mysql:dbname=syslog syslog syslogng

La table 'logs' est découverte, il nous faut un controleur avec lequel nous filtrerons les données.

$ ./script/catalog_create.pl controller ssh

Dans ce dernier nous ajouterons une action 'accès' qui n'est rien d'autre qu'une méthode du controleur. Nous pourrons ainsi accéder à notre interface au travers de l'url http://localhost:3000/ssh/acces

Pour afficher le résultat il est nécessaire de disposer d'une Vue:

$ ./script/catalog_create.pl view TT TT

Il ne reste qu'a créer la requête dans le controller et le fichier template pour l'afficher.

On ajoute l'action 'acces' au controleur lib/Catalog/Controller/ssh.pm :

sub acces : Local {
    my ( $self, $c ) = @_;

    $c->stash->{results} = [ $c->model('DB::Logs')->search( {program => 'sshd' } ) ];
    $c->stash->{template} = 'ssh/acces.tt2';
}

Le template root/ssh/acces.tt2 :

<table>
    <tr><th>host</th><th>facility</th><th>priority</th><th>level</th><th>tag</th><th>date</th><th>program</th><th>msg</th></tr>

    [% FOREACH r IN results -%]
      <tr>
        <td>[% r.host %]</td>
        <td>[% r.facility %]</td>
        <td>[% r.priority %]</td>
        <td>[% r.level %]</td>
        <td>[% r.tag %]</td>
        <td>[% r.date %]</td>
        <td>[% r.program %]</td>
        <td>[% r.msg %]</td>

      </tr>
    [% END -%]
</table>

Démarrage d'un serveur http embarqué:

./script/catalog_server.pl

Et voilà, on peut s'y loguer sur http://localhost:3000/ssh/acces

A l'aide du plugin Catalyst::Plugin::Scheduler il est très simple d'exécuter péridiquement une requête de contrôle sur la table Logs. En quelques lignes de code il est possible de mettre en place un système complet de gestion et surveillance des logs.


Add_a_comment

Validator_logo
Catapulse v0.06
( 0.079972 s)