☰

Wie wird das „kernel.*“-Syslog-Spoofing verhindert?

tag-icon • tag-icon rhel5 syslog-ng
Wie wird das „kernel.*“-Syslog-Spoofing verhindert?

kernel.emergIch finde Fälle, in denen syslog-ng in einer unserer Produktionsumgebungen Müll ausgibt, gefolgt von einer leeren Zeile. Beispiel für eines:

Dec 21 00:14:56 someserver [syslog-ng.err] Error processing log message: <Q▒b
+\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: <▒▒▒▒e▒F
Dec 21 00:14:57 someserver [syslog-ng.err] Error processing log message: <▒▒
Dec 21 00:14:58 someserver [kernel.emerg]

Die kernel.emergZeile bereitet mir besondere Sorgen. Laut man 3 syslog:

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

Dies scheint darauf hinzudeuten, dass die Kernel-Einrichtung nicht manipuliert werden kann. Ich kann sehen, dass die Systemaufrufe selbst ein solches Manipulieren verhindern könnten, aber liege ich richtig in der Annahme, dass es nichts gibt, was einen Prozess davon abhält,direktund /dev/logeine Einrichtung von vortäuschen kernel? Ich möchte sagen, dass das einzige, was ein solches Spoofing wirklich stoppen könnte, ein Syslog-Daemon wäre, der unterscheidet, ob er eine Nachricht von /proc/kmsgeiner anderen Quelle erhalten hat oder nicht.

  • Die Distribution ist RHEL5.5. Die Kernel-Version ist 2.6.18-194.8.1.el5. Das sind Faktoren, die ich noch nicht beeinflussen kann. Ich bin also ein Kritikpunkt.
  • Der Syslog-Daemon ist ein vom Unternehmen erstelltes syslog-ng3.1.4-Paket (32-Bit und läuft auf einem 64-Bit-Kernel, aber ich würde nicht erwarten, dass das damit zusammenhängt).
  • Ich habe über Google einige Mailinglisten-Beiträge gefunden, in denen darauf hingewiesen wird, dass Änderungen in kmsgKernel 3.5 zu derartigen Ausgabefehlern führen können. Dies ist hier jedoch definitiv nicht der Fall.

Die Nachrichten kommen nicht aus dem Netzwerk. Dies ist die einzige definierte Quelle:

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: "));
};

Antwort1

Gemäß dem syslog-ng-Administratorhandbuch (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) liest die Kernel-Einrichtung (zumindest wie standardmäßig definiert) direkt aus /proc/kmsg, wohin vom Userland aus nicht geschrieben werden kann.

(Dies ist aus dem Gedächtnis, aber ich bin ziemlich sicher, dass RHEL 5.5 für die Symbol-zu-Adresse-Ausgabe weder klogd noch ksymoops benötigt; sehen Sie sich dazu jedoch Ihre Dokumentation an.)

Wenn Sie sich Sorgen machen (siehe meinen Kommentar oben), dass ein betrügerischer Prozess seiner Nachricht die wörtliche Zeichenfolge „kernel:“ voranstellt, können Sie zur Sicherheit immer einen Filter hinzufügen, der die Zeichenfolge „kernel:“ am Anfang jeder empfangenen Nachricht entfernt. Alternativ können Sie /proc/kmsg als separate Quelle mit separatem Ziel definieren.

EDIT: Bei genauerem Hinsehen in diesem Abschnitt:

"Notiz

Wenn die Nachricht keinen richtigen Syslog-Header hat, behandelt syslog-ng aus Dateien empfangene Nachrichten so, als ob sie von der Kern-Einrichtung gesendet worden wären. Verwenden Sie die Optionen default-facility und default-priority in der Quelldefinition, um bei Bedarf eine andere Einrichtung zuzuweisen."

verwandte Informationen