User Tools

Site Tools


informatique:linux:syslog

Théorie du syslog

  • service de gestion des logs écoutant sur le port udp/514
  • 2 démons utilisés sous Linux : klogd et rsyslogd
  • klogd : récupère les logs du noyau seulement
  • rsyslogd : gestion des logs locaux : il reçoit des trap et les redirige où il faut en suivant les règles de /etc/rsyslog.conf. Fonctionne aussi avec les logs distants (si activation, voir plus bas).

Les services/types

Listes des services ou types (facility en anglais) reconnus par syslog :

  • auth : Messages relatifs à la sécurité du système et à l'authentification des utilisateurs.
  • cron : Messages générés par les daemons cron et at.
  • daemon : Messages générés par les autres daemons systèmes.
  • kern : Messages générés par le noyau (en provenance de klogd).
  • local0 à local7 : Services définis localement par l'administrateur système.
  • lpr : Messages relatifs au service d'impression.
  • mail : Messages provenant du système de mail.
  • news : Messages générés par la gestion des news USENET.
  • syslog : Messages générés en interne par syslog.
  • user : (C'est le service par défaut) Messages en provenance des utilisateurs.

Les priorités

Listes des priorités (au nombre de 8, par ordre croissant) reconnues par syslog :

  • emerg (emergency) : Message urgent. Le système est inutilisable ou risque de le devenir à très cours terme.
  • alert (alerte) : Message alertant l'administrateur système qu'une action de sa part est requise.
  • crit (critique) : Message critique.
  • err (erreur) : Message d'erreur.
  • warning (ou warn)(avertissement) : Message d'avertissement.
  • notice (note) : Message de fonctionnement normal, sans gravité particulière.
  • info (information) : Message à titre informatif.
  • debug (debogage) : Message de débogage

/etc/rsyslog.conf

Fichier de conf de rsyslogd organisé en 2 colonnes :

  • la première (sélecteur) définit l'origine (service/type + priorité)
  • la seconde (action) la destination (fichier, console, machine distante, liste d'utilisateurs, tube)

Ces colonnes sont donc de la forme :

<service.priorité>   </path/fichier> | </dev/ttyX> | @<host> | <root,toto> | | </path/to/pipe>

Par exemple pour récupérer les logs critiques (crit) de la messagerie (mail) et les rediriger dans la console /dev/tty8 :

mail.crit                          /dev/tty8

On utilise :

  • une étoile * pour désigner toutes les valeurs possibles d'un champ.
  • une virgule , pour séparer 2 noms de services ou 2 priorités
  • un point virgule ; pour assembler deux sélecteurs
  • un point d'exclamation ! pour inverser la sélection (NOT)
  • un tiret - en suffixe pour écrire dans la cible en différé (consomme moins de ressources mais à n'utiliser que pour les logs non critiques).
  • la priorité none matche les messages n'ayant pas de priorité définie

Exemple1 : pour écrire les logs d'erreur des services de mail et de news en différé dans /var/log/mail_et_news.log :

mail,news.err                 -/var/log/mail_et_news.log

Diagnostique

On peut vérifier la configuration avec la commande :

rsyslogd -N1

Pour lancer le démon syslog en mode DEBUG, il faut spécifier l'option -d :

vi /etc/default/syslogd
 SYSLOGD="-d"

Configuration sous Debian

Options de démarrage du démon

Se configure dans le fichier /etc/default/rsyslog.

# Options for rsyslogd
# -d enables debug
# -m 0 disables 'MARK' messages.
# -r enables logging from remote machines
# -x disables DNS lookups for remote messages
# See rsyslogd(8) for more details
RSYSLOGD_OPTIONS=""

Filtres

Notation basée propriété

C'est une notation abrégée permettant d'écrire des filtres simples.

Structure : :PROPERTY, [!]COMPARE_OPERATION, “STRING”

# property-based filter :
#       msg | hostname | programname | etc...
# compare-operation :
#       contains | isequal | startswith | regex | ereregex | isempty
# string (cible) :
#       prefixée par "-" pour écrire en asynchrone
 
:msg, contains, "iptables " -/var/log/iptables/iptables.log
# ancienne notation
# & ~
# nouvelle notation
& stop
:msg, regex, "^\[ *[0-9]*\.[0-9]*\] iptables" -/var/log/iptables/iptables.log
& stop

Notation basée expression

Notation plus verbeuse basée sur le langage RainerScript propre à rsyslog, qui utilise des opérateurs logiques.

Structure : if EXPRESSION then ACTION else ACTION

if $msg regex '^\[ *[0-9]*\.[0-9]*\] iptables' then /var/log/iptables/iptables.log
& stop

Template

# création du template "Openvpn" pour l'emplacement des logs openvpn
$template OpenVPN,"/var/log/openvpn/ovpn.log"
# on y transfère tous les messages issus des processus dont le nom commence par "ovpn-"
:programname, startswith, "ovpn-" -?OpenVPN
# puis on arrête le traitement de ces messages pour éviter les doublons
:programname, startswith, "ovpn-" stop

Syslog centralisé

Lorsqu'on a un parc qui grossit il devient très utile de centraliser les logs des différents équipements sur une seule machine. C'est possible en configurant syslog pour qu'il accepte les messages venant du réseau.

Depuis Debian 8, pour activer la gestion des logs par le réseau il faut :

  • décommenter les 2 lignes suivantes dans /etc/rsyslog.conf :
# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
  • activer la prise en charge “remote” de rsyslog ; cela se configure en spécifiant RSYSLOGD_OPTIONS=“-r” dans le fichier /etc/default/rsyslog
  • créer un fichier dans /etc/rsyslog.d/ , par exemple test.conf et y définir où stocker les logs que l'on va recevoir :
# les logs provenant de l'IP 192.168.2.1 seront envoyés dans le fichier /var/log/test.log
if $fromhost-ip == '192.168.2.1' then /var/log/test.log
# possible aussi de filtrer par bout d'IP
if $fromhost-ip startswith '192.168.2.' then /var/log/test.log
# et c'est tout (on ne traite plus d'autres règles pour ces logs)
& ~
  • redémarrer le service
systemctl restart rsyslog

Pour sécuriser un minimum, il faut compléter cela avec une règle iptables qui n'accepte les sockets udp/514 que depuis notre machine :

iptables -A INPUT -p udp -s 192.168.2.1 --dport 514 -j ACCEPT

Client distant

Pour envoyer les messages vers un serveur distant.

Structure : @[(zNUMBER)]HOST:[PORT]

Exemple : sur le client rsyslog distant, configurer le filtre suivant :

cat /etc/rsyslog.d/remote.conf
# Envoyer ces messages au syslog central
:programname, startswith, "ovpn-" @10.0.0.1

WRT54G(L)

Avec certain équipement, comme un routeur Linksys WRT54G, on ne connait pas forcément le facility des messages envoyés, donc on ne sais pas comment les récupérer. Ca se vérifie avec tcpdump :

tcpdump -i eth0 udp dst port 514
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

22:31:29.623663 IP odin.2062 > tyr.syslog: SYSLOG authpriv.notice, length: 138
22:31:46.322926 IP odin.2062 > tyr.syslog: SYSLOG user.warning, length: 274
... (blabla)

Là on écoute sur l'interface eth0 les paquet UDP ayant pour port de destination le 514 (port du syslog). On voit qu'il (odin, le routeur) envoie des logs (à ma machine tyr faisant tourner le tcpdump et le syslogd) de type authpriv.notice et user.warning.

En furetant dans le fichier de conf du syslogd, /etc/syslog.conf pour ma part, on y voit ces lignes :

auth,authpriv.*     /var/log/auth.log
user.*        -/var/log/user.log

Voilà donc où vont être redirigés ces damned messages de log.

Syntaxe avancée

Concernant le sélecteur : mail.info désigne les messages issus du système de mail ayant une priorité supérieure ou égale à info ; mail.=info désigne seulement les messages dont la priorité est exactement info ; mail.!=info désigne tous les messages venant du système du mail à l'exception de ceux ayant la priorité info ; mail.!info désigne les messages dont la priorité est strictement inférieure à info.

Pour reprendre l'exemple des log du routeur odin, je veux les isoler dans un fichier spécial : odin_iptables.log. Je pourrais me contenter d'ajouter la ligne suivante à la conf de mon syslogd :

user.=warning  -/var/log/odin_iptables.log

mais alors j'aurai de la redondance dans mes logs : en effet l'information sera également placer dans tous les autres fichiers de log qui matchent le facility “user” ou la priorité “warning”. Sachant que, comme on le devine facilement, mon routeur est un firewall, il va émettre un tas de données que je ne veux surtout pas concerver en double, triple, voir plus. Il faut donc parser la conf du syslog, repérer les règles qui matchent, et leur dire de ne plus matcher :) (non, je n'aime pas la redondance !). Voici les dites lignes :

# lui il récupère presque tout !
*.*;auth,authpriv.none  -/var/log/syslog

# lui il récupère le facility user
user.*                  -/var/log/user.log

# lui je l'ai inventé pour l'exemple (il n'existe pas par défaut) : il récupère tous les warnings
*.=warning              -/var/log/careful.log

Et voici les modifications à leur apporter :

# maintenant il ne récupère plus le facility user (qui va déjà dans user.log de toute façon)
*.*;\
 auth,authpriv,user.none  -/var/log/syslog

# lui il récupère le facility user sauf la priorité warning
user.*;user.!=warning     -/var/log/user.log

# lui je l'ai inventé pour l'exemple (il n'existe pas par défaut) : il récupère tous les warnings sauf le facility user
*.=warning;user.none      -/var/log/careful.log

Surtout, ne pas oublier de rediriger les flux de notre routeur !

#récupération des logs de mon routeur
user.=warning   -/var/log/odin_iptables.log

Log

On peut choisir la priorité syslog des journaux iptables (dans cet exemple, 4) :

iptables -t filter -A INPUT -j LOG --log-level=4

logger

Pour tester sa configuration, on utilise logger qui permet d'envoyer à syslog une chaîne de caractères.

Par exemple :

logger -t <programme> -p mail.debug <message>'

Liens

informatique/linux/syslog.txt · Last modified: 2020/09/14 08:50 by pteu