Rsyslog en duplication de log (sur Redhat)

Bonjour à tous, aujourd’hui je vais vous montrer comment configurer un serveur Rsyslog en duplication de log, c’est une configuration qui est très très utile quand on bosse sur un SIEM. En effet, parfois les solutions (au hasard Broadcom SEP…) qui émettent du syslog ne permettent pas toujours d’envoyer les logs à plusieurs destinations. C’est gênant car en cas d’étude ou tout simplement changement de SIEM, on ne peut pas dupliquer les logs vers le nouveau système. Si c’est mal géré cela peut obliger à des bascules en mode big bang dans ce genre de situation, ce qui n’est pas pas idéal pour des reprises en douceur.

Mais ce problème peut être simplement adressé avec un petit serveur rsyslog devant le SIEM. En effet ce service possède nativement la fonctionnalité de reforwardé des logs. Du coup, un petit passage dans la doc de rsyslog et un nouveau serveur plus tard et pouf on a la procédure suivante :

Installer et configurer Rsyslog en duplication de log

yum install rsyslog

Puis configurer en éditant le fichier /etc/rsyslog.conf. Notez que vous avez un générateur de configuration automatique fourni directement sur le site du projet. Il faut admettre que la syntaxe n’est pas la fois facile que j’ai vu.

###############################
# activer la reception UDP sur le 514
$ModLoad imudp
$UDPServerRun 514
input(type="imudp", port="514")
# activer la reception TCP sur le 514
$ModLoad imtcp
$InputTCPServerRun 514
input(type="imtcp", port="514")
# Si l'ip source est 1.2.3.4 ou 5.6.7.8
if ($fromhost-ip == '1.2.3.4' or $fromhost-ip == '5.6.7.8')
then {
# reforward vers l'ip n°1
action(type="omfwd"
Target="192.168.1.1"
Port="514"
Protocol="tcp")
# reforward vers l'ip n°2
action(type="omfwd"
Target="192.168.1.2"
Port="514"
Protocol="tcp")
# Stocker aussi en format fichier localement ou cas ou on aurait des pertes !
action(type="omfile"
File="/var/log/mycustomappfile.log")
}

Ensuite tester la configuration avec :

rsyslogd -N1

Puis appliquer la configuration en redémarrant le service.

systemctl restart rsyslog.service

N’oubliez pas de mettre un logrotate sur votre fichier pour ne pas saturer le disque :

/var/log/mycustomappfile.log

et checkez que le port est bien ouvert en local (et vos règles de firewall) avec netstat et iptables, hein.

tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 36379/rsyslogd

Pour finir suivez l’arrivée de vos logs dans /var/log/mycustomappfile.log a grand coup de tail -f et en testant avec mon script powershell qui envoie du syslogs en TCP par exemple.

Pour conclure ce micro TP linux et rsyslog, j’aimerai vous dire que c’est tellement con simple à mettre en œuvre que c’est en place comme couche de pré-collecte de premier niveau devant tous les SIEM et système de traitement de log… Mais la réalité c’est que les éditeurs ont une fâcheuse tendance à imposer des collecteurs syslog bien propriétaires comme il faut, rendant chaque migration lors d’un appel d’offre une plaie. Et côté client, il faut admettre que les responsables des projets sont souvent bien content que l’éditeur fasse ça, comme ça : zéro responsabilité pour eux en cas de pépins , il peuvent tout mettre sur le dos de l’éditeur. Au final, tout ça coûte un fric de dingue (comme dirai l’autre) pour un service qui est rarement au niveau. Je crois que le message est passé, non 🙂 ?

Bref, dupliquer vos syslog systématiquement geekez bien d’ici la prochaine.