[completement OT] recuperation de logs distants
bonjour a tous, dans le cadre d'un stage, une petite (toute petite meme) partie du sujet consiste a rapatrier des logs de differents firewalls/IDS sur une meme machine. Et la est le probleme, je n'ai pas trop d'idee pour le faire : j'ai pense au client/serveur (mais ca fait un serveur sur chaque machine dont on veut les logs, c'est assez lourd comme systeme), le ftp, le mail...comme tout doit etre automatise, il ne faut pas d'interaction mais plutot que la machine fasse tout, de maniere a ce que les logs soient bien proprement mis en local prets pour les traitements. Ca fait depuis ce matin que je cherche ans vraiment trouver ce que je veux : logrotate le fait bien, mais par mail...j'ai cherche sur google, rien du tout...enfin il faut noter que ca ne me derangerait pas de reprogrammer ca, mais si ca a deja ete fait, je ne tiens pas a reinventer la roue. Je me doute que ca existe deja, mais je ne trouve pas. Aller j'y retourne... Merci d'avance! Romain Gardon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [completement OT] recuperation de logs distants
O dans le cadre d'un stage, une petite (toute petite meme) partie du sujet consiste a rapatrier des logs de differents firewalls/IDS sur ben une partie de ta toute petite partie m'intéresse également ... une meme machine. Et la est le probleme, je n'ai pas trop d'idee pour le faire : j'ai pense au client/serveur (mais ca fait un serveur sur chaque machine dont on veut les logs, c'est assez lourd comme systeme), le ftp, le mail... tu parles d'un réglage en serveur/client de log (syslogd)?? (je croyais que c'était simple ...) comme tout doit etre automatise, il ne faut pas d'interaction mais plutot que la machine fasse tout, de maniere a ce que les logs soient bien proprement mis en local prets pour les traitements. Je sais pas si ça va répondre à ton contexte, mais pour une gestion analogue j'utilise tout bêtement un démon rsync sur la machine de collecte et des crons sur les machines clientes. Pour chaque machine, le rsync se fait de /var/log vers qqchose comme : serveur:/dépot-collect/$machine$[/var]/log/* pour avoir tout bien aligné On profite au passage de toute la configuration rsync pour inclure/exclure des fichiers ... Remarque, Normalement le texte du script cron client ne dépend pas syntaxiquement de la machine cliente (suffit d'utiliser qqchose comme $(HOSTNAME)). Il peut donc être déployer facilement. A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [completement OT] recuperation de logs distants
Le 15/04/02, georges mariano a ecrit: Je sais pas si ça va répondre à ton contexte, mais pour une gestion analogue j'utilise tout bêtement un démon rsync sur la machine de collecte et des crons sur les machines clientes. Pour chaque machine, le rsync se fait de /var/log vers qqchose comme : serveur:/dépot-collect/$machine$[/var]/log/* pour avoir tout bien aligné Logcheck utilise un outil qui s'appelle logtail, qui garde une trace de l'offset ou il est arrive dans les logs (un peu comme un tail -f, sauf qu'on peu le mettre dans un cron, par exmple). Du moins, c'est comme ca sur redhat. Sous debian, logtail est p'tet home-made. Mais ca devrait faire l'affaire. Sinon, syslog peut envoyer ses logs via le reseau. Ce qui est con, c'est que c'est de l'UDP, et que c'est pas crypte. -- Manu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [completement OT] recuperation de logs distants
On Mon, 15 Apr 2002, VALLIET Manu wrote: Sinon, syslog peut envoyer ses logs via le reseau. Ce qui est con, c'est que c'est de l'UDP, et que c'est pas crypte. En quoi le cryptage peut etre utile dans le log ? :-) Deja que les fichiers sont world readable par defaut... Pour ce qui est d'utilisation d'UDP, c'est justifie, puisque qu'on envoie tous les logs vers un serveur central de logs dans un reseau local dans la plus grande partie des cas. Or, un reseau local est tres fiable, compare a travers Internet. De plus, on retrouve assez rarement des informations intressantes susceptible d'attirer l'attention des hackers. Ils sont fait pour retracer les problemes des logiciels des plus standards. Par contre, il peut avoir certaines informations critiques evidemment (comme mettre des failed logins, dont on peut savoir le login, mais pas le password heureusement (sauf le connard de l'ancien pppd qui mettait le pass en clair)), bha, utilisez le tunneling SSH (ou tout autre IPSec) M'enfin, c'etait mon opinion... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [completement OT] recuperation de logs distants
Le 15/04/02, Eric LeBlanc a ecrit: On Mon, 15 Apr 2002, VALLIET Manu wrote: Sinon, syslog peut envoyer ses logs via le reseau. Ce qui est con, c'est que c'est de l'UDP, et que c'est pas crypte. En quoi le cryptage peut etre utile dans le log ? :-) Deja que les fichiers sont world readable par defaut... Pour ce qui est d'utilisation d'UDP, c'est justifie, puisque qu'on envoie tous les logs vers un serveur central de logs dans un reseau local dans la plus grande partie des cas. Mhh, par defaut, sous debian, les fichiers sont loins d'etre world readable: -rw-r-1 root adm 36528 avr 15 10:10 auth.log -rw-r-1 root adm 13232 avr 15 09:33 daemon.log -rw-r-1 root adm 0 mar 10 06:31 kern.log -rw-r-1 root adm 0 avr 14 06:29 lpr.log -rw-r-1 root adm 54237 sep 10 2001 mail.log -rw---1 mysqlmysql 49196 avr 15 10:05 mysql.log ... Or, un reseau local est tres fiable, compare a travers Internet. Certes, l'UDP, en local, c'est sympa. Mais une option TCP, ca serait bien aussi. P'tet qu'elle existe, mais je la connais pas. Il me semble que syslog-ng permet de faire ca, et meme de faire des tunnels cryptes (ssh ? ssl ?). Ce qui est dommage, c'est que son developpement a l'air chaotique. De plus, on retrouve assez rarement des informations intressantes susceptible d'attirer l'attention des hackers. Ils sont fait pour retracer les problemes des logiciels des plus standards. Par contre, il peut avoir certaines informations critiques evidemment (comme mettre des failed logins, dont on peut savoir le login, mais pas le password heureusement (sauf le connard de l'ancien pppd qui mettait le pass en clair)), bha, utilisez le tunneling SSH (ou tout autre IPSec) Bah, ou taper son mot de passe a la place de son login, sur une fenetre gdm quand on croit etre sur un xlock (bon, j'etais pas super reveille...). Resultat, le mot de passe se retrouve dans auth.log. Ca empeche pas de modifier son mot de passe dans les minutes qui suivent, mais ca la fout mal si il est broadcaste en UDP. De la meme maniere, j'aimerais pas que n'importe qui lise le mail.log. Question de respect de la vie privee. Bref, faut pas deconner avec les logs :-] M'enfin, c'etait mon opinion... -- Manu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
