4 votes

Comment empêcher l'usurpation de la mention "kernel.*" dans le syslog ?

Je trouve des cas où syslog-ng écrit des déchets suivis d'un blanc. kernel.emerg dans l'un de nos environnements de production. Exemple d'une ligne de production :

Dec 21 00:14:56 someserver [syslog-ng.err] Error processing log message: <Qb
+\c 21 00:14:56 someserver [syslog-ng.err] Error processing log message: <;E0
Dec 21 00:14:56 someserver [syslog-ng.err] Error processing log message: <"l
Dec 21 00:14:57 someserver [syslog-ng.err] Error processing log message: <eF
Dec 21 00:14:57 someserver [syslog-ng.err] Error processing log message: <
Dec 21 00:14:58 someserver [kernel.emerg]

Les kernel.emerg me préoccupe particulièrement. D'après le man 3 syslog :

       LOG_KERN
              kernel messages (these can’t be generated from user processes)

Cela semble indiquer qu'il n'est pas possible d'usurper la fonction du noyau. Je comprends que les appels système eux-mêmes puissent empêcher une telle usurpation, mais ai-je raison de penser qu'il n'y a rien qui puisse empêcher un processus d'écrire directement a /dev/log et l'usurpation d'une installation de kernel ? J'ai envie de dire que la seule chose qui pourrait vraiment empêcher une telle usurpation serait que le démon syslog fasse la différence entre le fait qu'il ait obtenu un message à partir de /proc/kmsg par rapport à d'autres sources.

  • La distribution est RHEL5.5. La version du noyau est 2.6.18-194.8.1.el5 . Ce ne sont pas des facteurs sur lesquels j'ai encore le contrôle ; considérez-moi comme grondé.
  • Le démon syslog est un démon d'entreprise. syslog-ng 3.1.4 (32 bits et fonctionnant sur un noyau 64 bits, mais je ne m'attendrais pas à ce que cela soit lié).
  • J'ai trouvé sur Google des messages de listes de diffusion suggérant que les changements apportés aux kmsg dans le noyau 3.5 peut créer des erreurs de sortie comme celle-ci, mais ce n'est absolument pas le cas ici.

Les messages ne proviennent pas du réseau. C'est la seule source définie :

source s_syslog {
# message generated by Syslog-NG
internal();
# standard Linux log source (this is the default place for the syslog()
# function to send logs to)
unix-stream("/dev/log");
# messages from the kernel
file("/proc/kmsg" program_override("kernel: "));
};

1voto

Bandrami Points 893

Selon le Guide de l'administrateur de syslog-ng ( http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guides/en/syslog-ng-ose-v3.3-guide-admin-en/html-single/index.html#kernel-messages ), la fonction du noyau (du moins telle qu'elle est définie par défaut) lit directement dans /proc/kmsg, qui ne peut pas être écrit à partir de la zone utilisateur.

(C'est de mémoire, mais je suis presque sûr que RHEL 5.5 n'a pas besoin de klogd ou même de ksymoops pour la sortie des symboles vers l'adresse ; vérifiez votre documentation à ce sujet, cependant )

Si vous craignez (voir mon commentaire ci-dessus) qu'un processus malveillant ajoute la chaîne littérale "kernel : " à leur message, vous pouvez toujours ajouter un filtre qui supprimerait la chaîne "kernel : " au début de tout message reçu. Une autre solution consiste à définir /proc/kmsg comme une source distincte avec une destination distincte.

EDIT : En regardant de plus près cette section :

"Note

Si le message n'a pas d'en-tête syslog approprié, syslog-ng traite les messages reçus de fichiers comme étant envoyés par l'installation kern. Utilisez les options default-facility et default-priority dans la définition de la source pour assigner une facilité différente si nécessaire."

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X