Centralisation des logs

Avec l’ajout de nouveaux serveurs, pc, équipements dans votre réseau, la centralisation des logs sur une seule machine devient une évidence.

Passer 1 heure a se connecter en ssh, minicom ou autre sur chaque bestiole pour vérifier les logs devient vite fastidieux et la mise en place d’un « Syslog Host » (terme que j’emploierai pour désigner le serveur de récupération des logs) coule de source.

Heureusement, ce genre de déploiement est assez simple car déjà inclus nativement sur nos Linux / *BSD préféré.

Le choix du serveur de logs n’est pas non plus à prendre a la légère. Outre le volume de données a stocker/traiter, la criticité d’une telle machine ne doit pas être oubliée.

1. Vous vous exposez à une « attaque » de type Syslog Bombing
2. Certains logs peuvent être sensible et ne pas être donné en pature a n’importe quel lecteur

Prévoyez donc une partition dédiée (type /var/log) suffisamment dimensionnée et réservée aux logs.

Côté sécurité réseau, les flux Syslog utilisent le protocole UDP sur le port 514, a vous donc de positionner vos ACL et/ou règles Firewall en conséquences et bien entendu à ne pas l’exposer au réseau Internet.

L’idéal étant bien évidemment de positionner le SyslogHost dans un VLAN dédié ou vous n’autoriserez que l’UDP port 514 et le SSH depuis le poste de management.

(Petite parenthèse d’humour paranoïaque :
La sécurité ultime étant justement d’utiliser la particularité du protocole UDP qui travaille en mode non-connecté pour couper physiquement le fil TX du câble réseau côté carte du SyslogHost 😀

Bon OK, là c’est vraiment Parano 😉

fin de la parenthèse qui sert à rien)

Activation du démon Syslogd

Sur votre Pingouin, il suffit de rajouter l’option « -r » a Syslog.

Debian Like : /etc/default/syslogd

RedHat Like : /etc/sysconfig/syslog

Relancer syslog.

Sur le Poisson qui pique, ajouter le flag -u dans votre /etc/rc.conf :

syslogd_flags= »-u »

Killer le process Syslogd et relancer le en mode -u : syslogd -u

Un netstat -an | grep 514 vous confirmera l’écoute :

udp 0 0 *.514 *.*

Sur les clients, il suffit maintenant de modifier le fichier /etc/syslog.conf pour lui demander de tout envoyer au Syslog Host :

Ex: *.* @192.168.0.1

Bien sur vous pouvez peaufiner ce que vous voulez envoyer comme logs. (lire cet article par exemple).

N’oubliez surtout pas de configurer la rotation automatique des logs !!!

Avec logrotate.d sur Linux et Newsyslog sur OpenBSD (MAN est votre ami)…

Remontée les logs Cisco

Les Ciscos savent envoyer leurs logs ves un Syslog host.

Sur un routeur :

logging 192.168.0.1

Sur un Pix :

logging host inside 192.168.0.1

Par défaut, les Ciscos envoient leurs logs avec le niveau local.7

Il peut être intéressant de peaufiner le traitement des logs et de séparer les logs « syslog » des machines, des logs équipements.

Pour un Pix par exemple, nous pouvons utiliser le tableau suivant :

1. Préparons le SyslogHost a recevoir les logs : local3.debug /var/log/cisco.log (dans le syslog.conf)
2. Sur le Pix ou le routeur Cisco :

logging trap informational
logging facility 19

Car facility 19 = local 3

NB : Il s’agit simplement d’une traduction du binaire :-p

• 16 = 00010000 = local0
• 17 = 00010001 = local1
• 18 = 00010010 = local2
• 19 = 00010011 = local3
• 20 = 00010100 = local4
• 21 = 00010101 = local5
• 22 = 00010110 = local6
• 23 = 00010111 = local7

On utilise les 4 derniers bits, exemple 22 = 00010110, les 4 derniers =0110 = en décimal 6, c’est du local 6.

Le flag Trap est le niveau de log voulu :

alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging Debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
warnings Warning conditions (severity=4)

Les commandes suivantes ne sont pas négligeables à rajouter :

service timestamps log datetime localtime (Cisco routeur)

logging timestamp (Cisco PIX)

Si cela vous amuse 🙂 vous pouvez également coloriser vos logs qui s’afficheront (voir l’article ICI ).

Traitement des logs

Se coltiner des flux continus de logs qui défilent n’est pas des plus agréables et une information Critique peut vous échapper si vous ne lisez pas vos logs ou ne les traiter pas automatiquement.

Il existe des multitudes de script vous permettant de parser vos logs et d’en extraire les informations essentielles, je vous laisse avec Google pour faire le plein de bonne solution.

Personnellement, comme je l’avais expliqué dans un billet précédent, j’utilise Prelude comme centralisateur d’informations et en installant un module Prelude-LML (LML : Log Monitoring Lackey) sur le SyslogHost, je remonte tout cela sur le Prelude Manager et une bonne moulinette maison me permet d’être alerté en temps réel en cas d’incident.

J’espère que vous prendrez conscience de l’utilité et de l’importance de la centralisation des logs qui n’a été que rapidement approchée dans ce billet mais que vous pourrez étendre beaucoup plus loin (remontée des logs applicatives par exemple (qui a dit Log4j ??? 😉 ) etc..

Bon courage