SYSLOG - Description d'un serveur de log Syslog-NG
Sommaire
Introduction
Cet article décrit la création d'un serveur de logs centralisé.
Cette machine permet donc de déporter les logs de chaque serveur, et ainsi d'améliorer la sécurité globale du SI: si une machine déporte tous ses logs sur un serveur syslog sur le réseau, un intrus pourra toujours entrer sur cette machine mais ne pourra en principe pas effacer ses traces comme cela se fait d'habitude.
Plateforme
La machine est une machine virtuelle gérée par la plateforme ESX.
Cette machine fonctionne sous Ubuntu Server:
root@hikaru:/etc/logrotate.d# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 7.04 Release: 7.04 Codename: feisty
Solution technique de loggage
Le serveur de log centralisé utilise syslog-ng et php-syslog-ng.
La page consacrée à syslog-ng chez l'éditeur
La page permettant le téléchargement de php-syslog-ng
Le service de loggage standard sur linux, syslog, aurait pu être utilisé.
Le choix de syslog-ng a été motivé par la capacité de l'outil à stocker ses logs en base de donnée (MySQL dans ce cas), et à s'associer à php-syslog-ng pour consulter ces logs en temps réel.
Installation
Quelques liens vers des howto sur le net:
- SYSLOG-NG
- PHP-SYSLOG-NG
Configuration
Pour le fichier complet de configuration au mois de juillet 2008, cf Fichier de configuration de PHP-Syslog-NG.
Les extraits suivant sont spécifiques à notre mise en place:
- Définition d'une source:
source s_net {
unix-stream("/dev/log");
udp();
}; => cette source permet de récupérer les infos de loggage arrivant sur le port UDP 514
- Définition de filtres:
#filter f_syslog { not facility(auth, authpriv); };
filter f_syslog { not facility(auth, authpriv, local4, local5); };
=> on exclut les facilities 4 et 5 de syslog, sinon tout part dans le fichier de log syslog.
# all messages of info, notice, or warn priority not coming form the auth,
# authpriv, cron, daemon, mail, and news facilities
#filter f_messages {
# level(info,notice,warn)
# and not facility(auth,authpriv,cron,daemon,mail,news);
#};
filter f_messages {
level(info,notice,warn)
and not facility(auth,authpriv,cron,daemon,mail,news,local4,local5);
};
=> on exclut les facilities 4 et 5 de messages, sinon tout part dans le fichier de log messages.
filter f_chapi { host( "10.5.1.3" ); };
filter f_chapo { host( "10.5.1.6" ); };
filter f_chapu { host( "10.5.1.12" ); };
filter f_asa { host( "192.168.1.1" ); };
=> on déclare des filtres par IP pour les hôtes loggant sur le serveur de log centralisé.
#LOCAL4 stats.log
#LOCAL5 portal.log
filter f_ent_stats { facility(local4); };
filter f_ent_portal { facility(local5); };
=> 2 filtres pour lié la facility local4 aux stats et local5 aux log de fonctionnement.
- Définition de destinations:
#destination df_ent_portal_chapo { file("/var/log/ent/portal_chapo.log"); };
#destination df_ent_portal_chapu { file("/var/log/ent/portal_chapu.log"); };
#destination df_ent_portal_chapi { file("/var/log/ent/portal_chapi.log"); };
=> les destinations d'origine, 1 fichier de logs de fonctionnement par instance d'ESUP.
destination df_ent_portal { file("/var/log/ent/portal.log"); };
destination df_ent_stats { file("/var/log/ent/stats_$YEAR-$MONTH.log" template("${MSG}\n")); };
=> les destinations en vigueur pour les logs de fonctionnement et de stats d'ESUP.
destination df_asa { file("/var/log/asa_inside"); };
=> le fichier de log destiné à recevoir les logs du firewall INSA.
destination d_mysql {
program("/usr/bin/mysql -usyslogadmin -ppwdPSNsla syslog"
template("INSERT INTO logs (host, facility, priority, level, tag, datetime, program, msg) VALUES ( '$HOST', '$FACILITY', '$PRIORITY', '$LEVEL', '$TAG', '$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC', '$PROGRAM', '$MSG' );\n")
template-escape(yes));
};
=> 1 exemple de destination en base de donnée, utilisée pour les logs ESUP au départ mais mis de coté pour l'instant.
- Définition de logs:
log {
source(s_net);
filter(f_chapo);
filter(f_ent_portal);
#destination(df_ent_portal_chapo);
destination(df_ent_portal);
# destination(d_mysql);
};
log {
source(s_net);
filter(f_chapu);
filter(f_ent_portal);
#destination(df_ent_portal_chapu);
destination(df_ent_portal);
# destination(d_mysql);
};
log {
source(s_net);
filter(f_chapi);
filter(f_ent_portal);
#destination(df_ent_portal_chapi);
destination(df_ent_portal);
# destination(d_mysql);
};
=> on applique les filtres pour les IP de chap(x), et on leur désigne la destination fichier portal.log. Pour info, on n'utilise plus pour l'instant le stockage en base.
log {
source(s_net);
filter(f_chapi);
filter(f_ent_stats);
# destination(df_ent_stats_chapi);
destination(df_ent_stats);
};
log {
source(s_net);
filter(f_chapu);
filter(f_ent_stats);
# destination(df_ent_stats_chapu);
destination(df_ent_stats);
};
log {
source(s_net);
filter(f_chapo);
filter(f_ent_stats);
#destination(df_ent_stats_chapo);
destination(df_ent_stats);
};
=> on applique les filtres pour les IP de chap(x), et on leur désigne la destination fichier stats_(année)-(mois).log. Pour info, on n'utilise plus pour l'instant le stockage en base.
log {
source(s_net);
filter(f_asa);
destination(df_asa);
};
=> on applique le filtre pour l'IP du firewall et on lui désigne un fichier de destination.
Problèmes connus
Quelques problèmes ont été rencontrés lors de la mise en place de ce serveur de log centralisé.
Il est à noter que ce serveur fait aussi office de serveur de base MySQL et qu'il est utilisé pour l'instant par les 3 machines du cluster ESUP.
Pour optimiser le stockage en base de donnée, et ne pas occuper tout l'espace disque avec de trop nombreuses lignes de log, l'installation de php-syslog-ng précise qu'il faut lancer à intervalle régulier par la cron un traitement php destiné à supprimer les doublons dans la base.
Un extrait de la crontab:
@daily php /var/www/psn/scripts/logrotate.php >> /var/log/psnlogrotate.log
@daily find /var/www/psn/html/jpcache/ -atime 1 -exec rm -f '{}' ';'
#*/5 * * * * php /var/www/psn/scripts/reloadcache.php >> /var/log/apache2/psnreloadcache.log
#*/5 * * * * php /var/www/psn/scripts/SqueezeDB-v2.0.php >> /var/log/apache2/psnsqueezedb.log
Après quelques jours de fonctionnement, il est apparu que ce traitement php occupait toutes les ressources du serveur, provoquant des ralentissements sensibles qui perturbaient le bon fonctionnement de ESUP (problèmes liés aux lenteurs d'accès à la base ESUP).
C'est la raison pour laquelle les traitements php dans l'extrait de crontab ci-dessus ont été desactivés.
Lorsque l'on décidera de déporter sur ce serveur des logs "classiques" d'autres serveurs (type logs apache, postfix, ssh, ...), la fonctionnalité apportée par la consultation via le web des logs avec php-syslog-ng reprendra tout son sens, il faudra alors se poser la question suivante: comment faire fonctionner SqueezeDB sans surcharger le serveur?
