☰

Как предотвращается подделка системного журнала «kernel.*»?

tag-icon • tag-icon rhel5 syslog-ng
Как предотвращается подделка системного журнала «kernel.*»?

Я нахожу случаи, когда syslog-ng пишет мусор, за которым следует пустая kernel.emergстрока в одной из наших производственных сред. Пример одного из них:

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]

Эта kernel.emergлиния вызывает у меня особую озабоченность. Согласно man 3 syslog:

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

Это, кажется, предполагает, что возможности ядра не могут быть подделаны. Я понимаю, где системные вызовы сами могут предотвратить такую ​​подмену, но прав ли я, думая, что нет ничего, что могло бы помешать процессу записатьнапрямуюи /dev/logподделывание объекта kernel? Я хочу сказать, что единственное, что действительно может остановить такой спуфинг, — это демон syslog, различающий, получил ли он сообщение из /proc/kmsgдругих источников или нет.

  • Дистрибутив — RHEL5.5. Версия ядра — 2.6.18-194.8.1.el5. Это пока не те факторы, которые я могу контролировать; считайте, что меня отругали.
  • Демон syslog — это syslog-ngпакет 3.1.4, созданный компанией (32-разрядный и работающий на 64-разрядном ядре, но я бы не стал ожидать, что это как-то связано).
  • Я нашел несколько сообщений в почтовых рассылках через Google, в которых предполагается, что изменения kmsgв ядре 3.5 могут приводить к появлению ошибок вывода, подобных этой, но в данном случае это определенно не так.

Сообщения не приходят из сети. Это единственный определенный источник:

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

решение1

Согласно Руководству администратора 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), функция ядра (по крайней мере, как определено по умолчанию) считывает данные непосредственно из /proc/kmsg, запись в который из пользовательского пространства невозможна.

(Это по памяти, но я почти уверен, что RHEL 5.5 не нуждается в klogd или даже ksymoops для вывода символов в адрес; хотя, проверьте свою документацию по этому поводу..)

Если вы беспокоитесь (см. мой комментарий выше) о том, что какой-то вредоносный процесс добавляет буквальную строку "kernel: " к своему сообщению, вы всегда можете добавить фильтр, который удалит строку "kernel: " в начале любого полученного сообщения, чтобы быть уверенным. В качестве альтернативы определите /proc/kmsg как отдельный источник с отдельным пунктом назначения.

EDIT: Если рассматривать этот раздел подробнее:

"Примечание

Если сообщение не имеет надлежащего заголовка syslog, syslog-ng обрабатывает сообщения, полученные из файлов, как отправленные средством kern. Используйте параметры default-facility и default-priority в определении источника, чтобы назначить другое средство, если необходимо."

Связанный контент