Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
Альтернативная энергия




Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

Cистемное протоколирование в Linux

В.Костромин.

Каждый из начинающих пользователей Linux рано или поздно встречается с какими-то проблемами в настройке и организации функционирования своей системы. И каждый из новичков почти наверняка слышал от более опытных пользователей совет: "Смотри логи". Совет-то хорош, да ведь новичку еще надо знать: что такое логи и где их искать! Вот я и попытаюсь в этой статье рассказать, что и где нужно смотреть.

На программистском сленге "логами" называют протоколы работы, которые ведутся как самой операционной системой, так и самостоятельно многими программами. В качестве синонима слова "протокол" в этом смысле часто используется и слово "журнал". Существует две основных ситуации, в которых возникает необходимость анализа протокола: когда что-то в системе работает не так, как мы ожидали, (разрешение проблем), и когда появляется подозрение, что система взломана каким-то злоумышленником и надо выяснить, что именно произошло, как это было сделано, и что нужно предпринять, чтобы ликвидировать последствия вторжения.

Одним из самых известных случаев использования файлов протоколов для обнаружения вторжения злоумышленника является история поимки специалистом по компьютерной безопасности Тсуомо Шимомура знаменитого хакера Кевина Митника. Вот один абзац из статьи [1], описывающей, как это произошло.

"В Рождество, когда Шимомура поехал на каникулах покататься на лыжах в Неваду, кто-то (мы уже знаем, кто именно) проник в его суперзащищенный домашний компьютер в Солана Бич, Калифорния, и начал копировать его файлы - сотни засекреченных файлов. Один магистрант из Центра Суперкомпьютеров в Сан Диего, где работал Шимомура, заметил изменения в системных "журнальных" (log) файлах и быстро сообразил, что происходит. Все это оказалось возможным благодаря тому, что Шимомура установил на свой компьютер программу, автоматически копирующую "журнальные" записи на дублирующий компьютер в Сан Диего. Студент позвонил Шимомуре, и тот помчался домой, чтобы провести инвентаризацию украденного."

Я не буду рассказывать здесь всю эту историю, нам важно отметить только то, что анализ протоколов работы системы послужил основой для успеха проведенного расследования неправомерных действий. Более подробное описание того, как проводятся такие расследования, вы сможете найти в статье [2]. Но, чтобы суметь воспользоваться результатами протоколирования, надо понимать, как создаются протоколы, где они хранятся и что из них можно извлечь. Рассмотрению всех этих вопросов и посвящена настоящая статья.

Как формируются сообщения для протокола

Начать надо с того, что при создании программ на языке С программисты имеют возможность в необходимых случаях вставить вызов специальных функций openlog, setlogmask, syslog и closelog, включенных в стандартную библиотеку языка C. Эти функции служат для посылки сообщений о тех или иных событиях при выполнении программы специальному системному демону syslogd, ведущему системный протокол. Функция openlog устанавливает связь с демоном syslogd, функция syslog формирует конкретное сообщение для записи в протокол, а функция closelog закрывает открытую связь.

Сообщения, формируемые функцией syslog, состоят из нескольких полей, разделяемых пробелами. Каждое сообщение начинается с поля PRI, которое в закодированном виде содержит информацию о категории сообщения (facility) и уровне серьезности (severity level) или приоритете (priority) сообщения.

Категория (facility) - это информация о том, к какому классу относится данное сообщение. Категория кодируется числом от 0 до 23. Существуют следующие категории (они определяются в файле /usr/include/sys/syslog.h):

Таблица 1.

Числовое значениеУсловное обозначениеРасшифровка
0kernСообщения ядра
1userПредназначена для разнообразных сообщений от программ пользователя.(сообщения пользовательских программ)
2mailСообщения от почтовой системы.
3daemonСообщения от тех системных демонов, которые в отличие от FTP или LPR не имеют выделенных специально для них категорий.
4 auth Все что связано с авторизацией пользователей, вроде login и su (безопасность/права доступа)
5syslogСистема протоколирования может протоколировать сообщения от самой себя.
6lprСообщения от системы печати.
7newsСообщения от сервера новостей. (Netnews, USENET)
8uucpСообщения от UNIX-to-UNIX Copy Protocol. Это часть истории UNIX и вероятнее всего она вам никогда не понадобится (хотя до сих пор определенная часть почтовых сообщений доставляется через UUCP).
9cronСообщения от системного планировщика.
10authpriv То же самое, что и auth, однако сообщения этой категории записываются в файл, который могут читать лишь некоторые пользователи (возможно, эта категория выделена потому, что принадлежащие ей сообщения могут содержать открытые пароли пользователей, которые не должны попадать на глаза посторонним людям, и следовательно файлы протоколов должны иметь соответствующие права доступа).
11 ftpПри помощи этой категории вы сможете сконфигурировать ваш FTP сервер, что бы он записывал свои действия.
с 12 по 15 - Зарезервировано для системного использования.
с 16 по 23local0 - local7 Зарезервированные категории для использования администратором системы. Категория local7 обычно используется для сообщений, генерируемых на этапе загрузки системы.

Категория auth имеет устаревшее наименование-синоним security, которое не рекомендуется использовать. Кроме того, существует особая категория mark (не имеющая цифрового эквивалента), которая присваивается отдельным сообщениям, формируемым самим демоном syslogd. Эта категория используется для того, что бы помещать в протокол специальные отметки через заданный интервал времени (по умолчанию каждые 20 минут), что позволяет, например, узнать с 20-ти минутной точностью, когда же завис ваш компьютер.

Отметим, что категория не имеет вообще говоря никакого отношения к имени программы, которая шлет сообщения демону syslogd. Как говорится, всякое совпадение - чистая случайность. Более того, некоторые программы могут порождать сообщения разных категорий. Например, демон telnetd в случае неудачных попыток логирования порождает сообщения категории authpriv, а в других случаях относит свои сообщения к категории daemon.

Второй параметр, на основе которого формируется значение поля PRI, - это уровень или приоритет сообщения (priority), то есть информация о степени важности сообщения. Стандартно заданы 8 уровней важности (они тоже определены в файле /usr/include/sys/syslog.h), которые кодируются числами от 0 до 7:

Таблица 2.

Числовое значениеУсловное обозначение Расшифровка
0emerg (старое название PANIC) Чрезвычайная ситуация. Система неработоспособна.
1alert Тревога! Требуется немедленное вмешательство.
2crit Критическая ошибка (критическое состояние).
3err (старое название ERROR) Сообщение об ошибке.
4warning (старое название WARN)Предупреждение.
5notice Информация о каком-то нормальном, но важном событии.
6info Информационное сообщение.
7debug Сообщения, формируемые в процессе отладки.

Поле PRI сообщения образуется следующим образом: числовое значение категории умножается на 8 и складывается с числовым значением приоритета, получившееся число заключается в угловые скобки и записывается в поле.

Вслед за полем PRI в сообщение включаются следующие поля:

  • TIMESTAMP - время формирования сообщения,
  • HOSTNAME - имя или IP-адрес хоста в десятичной записи,
  • MSG - произвольный текст сообщения - некоторая текстовая (информационная) строка в коде US-ASCII (0x20 - 0x7e).

Время (местное!) записывается в формате: Feb 13 21:12:06. Если номер дня является однозначным числом, то перед ним ставится дополнительный пробел (не 0!). Обратите внимание на отсутствие года и зоны в дате, что необходимо учесть при организации долговременного хранения файлов протокола. Для того, чтобы время в сообщении было правильным, оно должно быть синхронизовано (например, по протоколу NTP).

Имя хоста включается в сообщение с той целью, чтобы не путать сообщения от разных хостов, поскольку, как будет показано ниже, ведение протоколов может вестись на одном из выделенных компьютеров в сети. В качестве имени хоста указывается простое сетевое имя компьютера, без указания домена. Если компьютер имеет несколько интерфейсов с различными IP-адресами, то в качестве имени или адреса хоста может быть использовано любое из них.

Текст сообщения (MSG) обычно содержит этикетку (TAG), указывающую на программу или процесс, выдавшую это сообщение, и тело сообщения (CONTENT). Этикетка может содержать латинские буквы и цифры. Обычно в качестве этикетки используется простое имя программы, иногда дополненное идентификатором процесса, заключенным в квадратные скобки. Тело сообщения отделяется от этикетки специальными символами - в Linux это обычно двоеточие и пробел.

Обработка сообщений демоном syslogd

Все сообщения, формируемые отдельными программами с помощью функции syslog, отправляются через сокет /dev/log системному демону syslogd, который отвечает за обработку этих сообщений. Надо сказать, что вообще-то в системе запускаются два демона протоколирования - syslogd и klogd. Оба демона входят в состав пакета sysklogd, последнюю версию которого вы можете найти на сайте [3].

Демон klogd отвечает за протоколирование событий, происходящих в ядре системы. Необходимость в отдельном демоне klogd объясняется тем, что ядро не может использовать стандартную функцию syslog. Дело в том, что стандартные библиотеки (включая ту библиотеку, в которой находится функция syslog) предназначены для использования только обычными приложениями. Поскольку ядро тоже нуждается в аналогичных функциях, в него включены свои библиотеки, недоступные приложениям. Поэтому ядро использует свой собственный механизм генерации сообщений. Демон klogd предназначен для организации обработки этих сообщений. В принципе он может производить такую обработку полностью самостоятельно и независимо от syslogd, например, записывая эти сообщения в файл, но в большинстве случаев используется принятая по умолчанию настройка klogd, при которой все сообщения от ядра пересылаются тому же демону syslogd.

Чтобы убедиться, что демоны syslogd и klogd запущены в вашей системе, выполните команду ps -ax | grep log. У меня эта команда дала следующий результат:

[kos]$ ps -ax | grep log

  569 ?        S      0:00 syslogd -m 0
  574 ?        S      0:00 klogd -x
 1013 ?        S      0:00 login -- kos     
 1191 ?        S      0:00 kalarmd --login
Две первые строчки как раз и сообщают, что в системе запущены демоны протоколирования.

Обработка сообщений демоном syslogd состоит в том, что он постоянно отслеживает появление сообщений и сравнивает каждую пришедшую запись с правилами, которые находятся в файле /etc/syslog.conf. Каждое правило записывается в виде строки файла /etc/syslog.conf, состоящей из двух полей. Левое поле ("selector") задает один или несколько шаблонов, по которым отбираются сообщения. Шаблоны разделяются точкой с запятой (смотри приведенный ниже пример файла /etc/syslog.conf). Правое поле ("действие") определяет порядок обработки отобранных сообщений. Поля разделены одним или несколькими пробелами или символами табуляции.

Каждый шаблон в поле "selector" имеет вид "категория.уровень" (то есть "facility.priority"). Значениями поля "категория" может служить:

  • одно из перечисленных в таблице 1 условных наименований категорий,
  • несколько таких наименований (в этом случае они разделяются запятыми)
  • или символ * (что означает "все категории").

Значениями поля "уровень" может служить:

  • одно из перечисленных в таблице 2 условных наименований уровня,
  • символ * (записывать все сообщения данной категории, независимо от уровня),
  • или слово none (не записывать сообщения данной категории).

Задание конкретного значения в поле "уровень" трактуется как "все значения данного уровня и выше". Если нужно записывать сообщения только одного уровня, то нужно перед задаваемым значением поставить знак равенства ("="). Если требуется записывать сообщения всех уровней, кроме указываемого, то перед наименованием уровня ставится восклицательный знак ("!"). Простановка двух этих знаков одновременно трактуется как "не записывать сообщения указанного уровня и выше".

Прописные и строчные буквы в поле "selector" не различаются. Можно также использовать числа (см. /usr/include/syslog.h). Кроме перечисленных в таблице 1 категорий можно указывать mark (регулярные временные метки) и security (устаревший синоним для auth). Кроме перечисленных в таблице 2 значений приоритета можно использовать warn (синоним для warning), error (синоним для err), panic (синоним для emerg).

Когда обнаруживается соответствие категории и уровня полученного сообщения с одним из шаблонов поля "selector" какой-то строки, syslogd обрабатывает запись в соответствии с действием, прописанным в поле "действие" данной строки.

В поле "действие" может стоять

  • имя обычного файла (файла протокола), причем должен быть указан полный путь к файлу, начиная с корня "/", а если указанного файла не сущестует, syslogd создает его,
  • название именованного канала (named pipe) - FIFO; в этом случае перед именем ставится вертикальная черта ("|"), а сам канал должен быть создан перед запуском syslogd командой mkfifo,
  • указание на терминал или консоль (как на устройство: /dev/tty1),
  • указание на удаленный хост (перед которым ставится символ @),
  • или список пользователей (через запятую), на терминалы которых будет послано сообщение по данному правилу. Вместо списка пользователей можно поставить звездочку (*), что будет означать, что сообщения посылаются всем пользователям, работающим в данный момент в системе.

Чаще всего в поле "действие" все же стоит имя файла протокола. Причем, перед именем файла можно проставить знак минуса ("-"), что будет означать, что система может хранить файл в буфере кеша, а не сбрасывать его после записи каждого сообщения на диск. Это, конечно, ускоряет работу, особенно если в протокол записывается много больших сообщений, однако может привести к потере части сообщений при неожиданном крахе системы, то есть именно тогда, когда такие сообщения особенно нужны. В качестве устройства в поле "действие" можно указать также принтер - /dev/lp0. Такой вариант "действия" целесообразно применять в тех случаях, когда речь идет об особо важных системах. Протоколы, которые распечатаны, не могут быть стерты или изменены хакерами, так что это неплохое применение для старого матричного принтера.

Кроме строк с правилами в файле /etc/syslog.conf могут содержаться пустые строки и строки комментариев, начинающиеся символом #. Подробнее о структуре файла /etc/syslog.conf вы можете прочитать на man-страничке syslog.conf [4], где приведено достаточно много примеров записей правил в этом файле. Отметим, что при задании пар "категория.уровень" в файле syslog.conf нельзя использовать числовые значения, приведенные в таблицах 1 и 2, допускаются только их условные наименования.

Если сообщение соответствует шаблонам двух или более строк, оно будет обрабатываться по каждому из этих правил (т.е. обработка сообщения не прекращается при первом успехе). Это означает, что для одного сообщения может быть выполнено произвольное количество действий. Поэтому вы можете и записать сообщение в файл протокола и отправить его пользователю(лям) или на удаленный хост.

Кроме того, если в поле "selector" перечислены (через точку с запятой) несколько пар "категория.уровень", то последующие пары могут отменить действие предыдущих. Пример такой отмены вы видите в приводимом ниже листинге файла /etc/syslog.conf: в файл /var/log/messages записываются все сообщения, уровень которых равен или выше info, однако при этом пропускаются (не записываются) сообщения категорий mail, authpriv и cron.

Листинг 1. Файл /etc/syslog.conf из системы, построенной на основе дистрибутива Red Hat Linux 7.1 (я только перевел на русский язык комментарии, содержащиеся в этом файле и выделил жирным шрифтом строки правил).
# Выдавать все сообщения от ядра на консоль.
#kern.*							/dev/console

# Записывать в протокол все сообщения уровня info или выше,  
# кроме сообщений почтовой системы, содержащих конфиденциальную 
# информацию аутентификационных сообщений и сообщений демона cron.
*.info;mail.none;authpriv.none;cron.none		/var/log/messages

# Записывать в отдельный файл сообщения, содержащие конфиденциальную 
# информацию аутентификации, независимо от их уровня.
authpriv.*						/var/log/secure

# Все сообщения почтовой системы тоже записывать отдельно.
mail.*							/var/log/maillog

# Протоколировать действия демона cron.
cron.*							/var/log/cron

# Сообщения о чрезвычайных ситуациях должны немедленно 
# получить все пользователи системы
*.emerg							*

# Сообщения от служб новостей уровня crit и выше записывать в отдельный файл.
uucp,news.crit						/var/log/spooler

# Сообщения, выдаваемые на этапе загрузки, копировать в файл boot.log
local7.*						/var/log/boot.log
Как видите, большинство сообщений просто записываются в различные файлы протоколов, расположенные в каталоге /var/log или его подкаталогах, причем основным файлом системного протокола в Red Hat Linux является файл /var/log/messages. В него не попадают только сообщения категорий mail, authpriv и cron (для которых выделены отдельные файлы). Давайте же заглянем в этот файл и на его примере рассмотрим, что бывает записано в файлах протоколов.

Файл протокола /var/log/messages

Конечно, рассказать здесь о содержании каждой строки этого файла нет возможности. Для того, чтобы читатель мог составить представление о том, какую информацию можно найти в протоколе, приведем отдельные строки-сообщения с очень краткими комментариями.

Каждая строка в файле протокола содержит запись одного сообщения, состоящую из следующих полей сообщения, разделенных пробелами:
  • дата в стандартном текстовом формате (поле TIMESTAMP из сообщения syslog),
  • имя хоста (поле HOSTNAME из сообщения syslog)
  • текст сообщения (поля TAG и CONTENT из сообщения syslog)

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

Sep 17 08:32:56 kos3 syslogd 1.4-0: restart.
Сен 17 08:32:56 kos3 syslog: запуск syslogd succeeded
Sep 17 08:32:56 kos3 kernel: klogd 1.4-0, log source = /proc/kmsg started.
Sep 17 08:32:56 kos3 kernel: Inspecting /boot/System.map-2.4.2-2
Сен 17 08:32:56 kos3 syslog: запуск klogd succeeded

Далее в файле протокола можно обнаружить, в частности, следующую информацию.

  • - Какая версия ядра используется:
    Sep 17 08:32:56 kos3 kernel: Linux version 2.4.2-2 (root@porky.devel.redhat.com) 
    (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 20:41:30 EDT 2001
    
  • - С какими параметрами запущено ядро:
    Sep 17 08:32:56 kos3 kernel: Kernel command line: auto BOOT_IMAGE=linux ro 
                                 root=303 BOOT_FILE=/boot/vmlinuz-2.4.2-2
    
  • - Информацию о типе процессора и объеме оперативной памяти:
    Sep 17 08:32:56 kos3 kernel: Detected 1594.849 MHz processor.
    Sep 17 08:32:56 kos3 kernel: Memory: 125652k/130560k available (1365k kernel code, 
                                 4200k reserved, 92k data, 236k init, 0k highmem)
    Sep 17 08:32:56 kos3 kernel: CPU: L1 I cache: 12K, L1 D cache: 8K
    Sep 17 08:32:56 kos3 kernel: CPU: L2 cache: 256K
    Sep 17 08:32:56 kos3 kernel: CPU: Intel(R) Pentium(R) 4 CPU 1.60GHz stepping 02
    
  • - Информацию о дисковой памяти (включая информацию о геометрии диска, структуре дисковых разделов и используемых прерываниях):
    Sep 17 08:32:56 kos3 kernel: hda: MAXTOR 6L020J1, ATA DISK drive
    Sep 17 08:32:56 kos3 kernel: hdc: SAMSUNG CD-ROM SC-148C, ATAPI CD/DVD-ROM drive
    Sep 17 08:32:56 kos3 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
    Sep 17 08:32:56 kos3 kernel: ide1 at 0x170-0x177,0x376 on irq 15
    Sep 17 08:32:56 kos3 kernel: hda: 40132503 sectors (20548 MB) w/1819KiB Cache, 
                                 CHS=2498/255/63, UDMA(100)
    Sep 17 08:32:56 kos3 kernel: Partition check:
    Sep 17 08:32:56 kos3 kernel:  hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >
    Sep 17 08:32:56 kos3 kernel: Floppy drive(s): fd0 is 1.44M
    
  • - Информацию о периферийных устройствах:
    Sep 17 08:32:56 kos3 kernel: usb-uhci.c: USB UHCI at I/O 0x1820, IRQ 11
    Sep 17 08:32:56 kos3 kernel: usb-uhci.c: Detected 2 ports
    Sep 17 08:32:56 kos3 kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
    Sep 17 08:32:56 kos3 kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A
    Sep 17 08:32:56 kos3 kernel: eth0: Intel(R) 8255x-based Ethernet Adapter
    Sep 17 08:32:56 kos3 kernel: Intel(R) PRO/100 Fast Ethernet Adapter - 
                                 Loadable driver, ver 1.5.6
    Sep 17 08:32:56 kos3 kernel: PCI: Found IRQ 11 for device 02:08.0
    
  • - Информацию о запуске отдельных служб и сервисов:
    Sep 17 08:32:56 kos3 kernel: NET4: Linux TCP/IP 1.0 for NET4.0
    Sep 17 08:32:56 kos3 kernel: IP Protocols: ICMP, UDP, TCP, IGMP
    Sep 17 08:32:56 kos3 kernel: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
    Sep 17 08:32:56 kos3 kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP]
    Sep 17 08:32:56 kos3 kernel: parport0: irq 7 detected
    Сен 17 08:32:42 kos3 rc.sysinit: Turning on user and group quotas for local 
                                     filesystems: succeeded 
    Сен 17 08:32:43 kos3 rc.sysinit: Enabling swap space:  succeeded 
    Sep 17 08:32:44 kos3 init: Entering runlevel: 3 
    Сен 17 08:32:45 kos3 kudzu: Updating /etc/fstab succeeded 
    Сен 17 08:32:55 kos3 kudzu:  succeeded 
    Сен 17 08:32:55 kos3 network: Устанавливаются параметры сети:  succeeded 
    Сен 17 08:32:55 kos3 network: Поднимается интерфейс lo:  succeeded 
    Сен 17 08:32:56 kos3 network: Активируется интерфейс eth0:  succeeded 
    Сен 17 08:32:56 kos3 keytable: Загружается раскладка клавиатуры: 
    Сен 17 08:32:56 kos3 keytable: Загружается системный шрифт: 
    Сен 17 08:32:56 kos3 random: Инициализируется генератор произвольных чисел: succeeded
    Sep 17 08:32:41 kos3 rc.sysinit: Configuring kernel parameters:  succeeded 
    Sep 17 08:32:41 kos3 rc.sysinit: Setting default font (cyr-sun16):  succeeded 
    Sep 17 08:32:41 kos3 rc.sysinit: Activating swap partitions:  succeeded 
    Sep 17 08:32:41 kos3 rc.sysinit: Setting hostname kos3:  succeeded 
    Sep 17 08:33:03 kos3 xinetd: запуск xinetd succeeded
    Сен 17 08:33:05 kos3 gpm: запуск gpm succeeded
    Сен 17 08:33:05 kos3 crond: запуск crond succeeded
    Sep 17 08:33:06 kos3 xfs: listening on port 7100 
    Сен 17 08:33:06 kos3 xfs: запуск xfs succeeded
    
  • - Информацию о подключении файловых систем:
    Sep 17 08:32:56 kos3 kernel: VFS: Mounted root (ext2 filesystem) readonly.
    Sep 17 08:32:56 kos3 kernel: Adding Swap: 265032k swap-space (priority -1)
    Sep 17 08:32:56 kos3 kernel: MSDOS FS: Using codepage 866
    Sep 17 08:32:56 kos3 kernel: MSDOS FS: IO charset koi8-r
    Sep 17 08:32:41 kos3 rc.sysinit: Mounting USB filesystem:  succeeded 
    Sep 17 08:32:41 kos3 rc.sysinit: Checking root filesystem succeeded 
    Sep 17 08:32:41 kos3 rc.sysinit: Remounting root filesystem in read-write mode:  succeeded 
    Sep 17 08:32:41 kos3 rc.sysinit: Mounting proc filesystem:  succeeded 
    Sep 17 08:32:41 kos3 fsck: /: clean, 30407/160000 files, 95270/319410 blocks 
    Sep 17 08:32:42 kos3 fsck: /HOME: clean, 6573/432864 files, 689090/863722 blocks 
    Sep 17 08:32:42 kos3 fsck: /usr: clean, 55105/329952 files, 286888/659602 blocks 
    Sep 17 08:32:42 kos3 rc.sysinit: Checking filesystems succeeded 
    
  • - Сообщения о некоторых ошибках:
    Sep 17 08:32:42 kos3 mount: SMB connection failed 
    Sep 17 08:32:42 kos3 mount: Packet send failed to 10.104.129.245(137) ERRNO=Network 
                                is unreachable 
    Sep 17 08:32:42 kos3 mount: mount: /dev/sda4: unknown device 
    Сен 17 08:32:59 kos3 mount: error connecting to 192.168.36.20:139 (No route to host)
    Сен 17 08:32:59 kos3 mount: mount: /dev/sda4: unknown device
    
  • - Сообщения о логировании пользователей:
    Sep 17 08:33:14 kos3 login(pam_unix)[916]: session opened for user kos by LOGIN(uid=0)
    Sep 17 08:33:14 kos3  -- kos[916]: LOGIN ON tty1 BY kos
    Сен 17 08:41:39 kos3 su(pam_unix)[1138]: authentication failure; logname=kos uid=500 
    					euid=0 tty= ruser= rhost=  user=root
    
  • - И, наконец, сообщения, записываемые при выключении компьютера, например:
    Сен 17 10:30:07 kos3 rc: Stopping keytable:  succeeded
    Sep 17 10:30:07 kos3 Font Server[870]: terminating 
    Сен 17 10:30:08 kos3 xfs: останов xfs succeeded
    Сен 17 10:30:08 kos3 gpm: останов gpm succeeded
    Sep 17 10:30:08 kos3 xinetd[668]: Exiting...
    Sep 17 10:30:10 kos3 rpc.statd[506]: Caught signal 15, un-registering and exiting.
    Sep 17 10:30:11 kos3 kernel: Kernel logging (proc) stopped.
    Sep 17 10:30:11 kos3 kernel: Kernel log daemon terminating.
    Сен 17 10:30:12 kos3 syslog: останов klogd succeeded
    Sep 17 10:30:12 kos3 exiting on signal 15
    

    Примерно такую же структуру имеют и записи в других файлах протоколов, упоминаемых в файле /etc/syslog.conf.

    Команды logger и tailf

    Из предыдущего описания можно сделать вывод, что выдача всех сообщений для системных журналов должна быть заложена программистом на этапе создания программы. Это не совсем так. Пользователь тоже имеет возможность послать сообщение демону syslogd. Для этого в Linux имеется команда logger [5], обеспечивающая отправку сообщения из командной строки (sh, bash и др.). Она входит в состав пакета util-linux. Естественно, что в первую очередь эта команда предназначена для обеспечения возможностей протоколирования при создании пользователем разного рода скриптов оболочки. Но ее можно запустить и непосредственно из командной строки, например, для ознакомления с возможностями системы протоколирования. Формат запуска команды:
    logger [-isd] [-f file] [-p PRI] [-t TAG] [-u socket] [MSG ...]
    
    Параметры командной строки имеют следующее значение:
    • -i - включать в сообщение номер процесса
    • -s - дублировать сообщение на stderr
    • -d - использовать при отправке сообщений режим дейтаграмм (вместо обычного потокового)
    • -f имя-файла - сохранять сообщение в указанном файле (по умолчанию используется /var/log/messages)
    • -p facility.level - задать категорию и приоритет сообщения (по умолчанию: user.notice)
    • -t TAG - задать поле TAG
    • -u socket - отправлять сообщение в указанный сокет, вместо обращения к syslogd
    • MSG - текст сообщения

    Пошлите несколько сообщений с помощью программы logger и полюбуйтесь на результат в файле /var/log/messages (если, конечно, вы не изменили заданное по умолчанию значение).

    Кстати сказать, имеется очень интересный способ просмотра сообщений, записываемых в файл /var/log/messages командой logger. Способ этот основан на использовании специальной программы tailf. Откройте окно терминала, получите права суперпользователя (командой su) и выполните в этом окне команду
    tailf /var/log/messages
    После этого переключитесь в другой терминал и выполните там команду logger произвольный_текст. Ваше сообщение тут же отобразится в том окне, где запущена программа tailf. То есть с помощью этой программы администратор системы может отслеживать запись новых сообщений в протокол в реальном режиме времени. Правда, у системного администратора вряд ли найдется время, чтобы следить за поведением системы таким образом (разве что в экстренных ситуациях). Поэтому для анализа протоколов разработаны специальные программы. Но о них чуть ниже, а пока перейдем к вопросу о том, как организовать надзор за удаленным компьютером (помните как поймал злоумышленника Шимомура?).

    Протоколирование в сети

    Как было сказано, сообщения системы протоколирования могут отправляться демоном syslogd на удаленный хост. Но там его кто-то должен принять. Оказывается делает это такой же демон syslogd, запущенный на этом удаленном хосте. Точнее, syslogd на любом компьютере может прослушивать не только сокет /dev/log (принимая тем самым сообщения от местных источников), но еще и порт 514/UDP, что обеспечивает прием сообщений с других компьютеров локальной сети (и последующую запись их в локальный файл). Тем самым обеспечивается возможность создания "сервера протоколирования", что может оказаться очень удобно для системного администратора (в одном месте отслеживаются все события в сети), а также повышает безопасность сети, поскольку сообщения о проникновении хакера на один из хостов сети не могут быть тут же этим хакером удалены из протокола.

    Однако, для организации такого "сетевого протоколирования" необходимо предпринять некоторые дополнительные усилия.

    Во-первых, поскольку для приема и отправки сообщений по сети используется порт 514/UDP, он должен быть доступен на обеих компьютерах (клиенте и сервере). Для этого в файле /etc/services на обеих компьютерах должна присутствовать строка
        syslog       514/udp
    Если такая строка в /etc/services отсутствует, syslogd не может ни принимать сообщения, ни отправлять их в сеть, поскольку не может открыть UDP-порт. Если такая ситуация возникает, syslogd немедленно прекращает записывать какие-либо сообщения даже в локальный протокол. При этом, как показывает команда ps, он остается в памяти и даже сохраняет сообщения в каких-то буферах, поскольку, если строку "syslog   514/udp" восстановить в файле /etc/services на клиенте, то по крайней мере часть "пропавших" сообщений все же появляется в протоколе (после перезапуска syslogd).

    Во-вторых, при запуске демона syslogd на сервере должна быть указана опция -r, которая обеспечивает возможность удаленного протоколирования (по умолчанию демон syslogd ждет сообщения только от локального сокета). О том, как и где задать эту опцию, будет рассказано ниже, в разделе о запуске демона syslogd.

    Ну, и в-третьих, должны быть соответствующим образом исправлены настройки в файлах /etc/syslog.conf на обеих компьютерах. Например, если вы хотите все сообщения перенаправить на сервер протоколирования, необходимо на компьютере-клиенте прописать в файле /etc/syslog.conf строку следующего вида:
    *.*     @hostname
    Если во время старта демона syslogd сервер окажется недоступен (например, он в этот момент отключен от сети) или не удастся найти его по имени (служба DNS не сработала должным образом) syslogd осуществляет еще 10 попыток нахождения сервера и только если и после этого найти сервер не удалось, прекращает попытки и посылает соответствующее сообщение.

    Если в вашей сети имеется несколько доменов, которые обслуживаются одним сервером протоколирования, то не удивляйтесь тому, что в протоколе на сервере будут указаны полные имена клиентов (с указанием домена). Правда, при запуске syslogd можно использовать опции -s список_доменов или -l список_хостов, которые обеспечивают замену в протоколе полных имен хостов на их краткие имена (без указания домена).

    Не забудьте после корректировки опций запуска и файла /etc/syslog.conf перезапустить демон, поскольку, в отличие от cron, sysklogd не перечитывает конфигурационные файлы автоматически.

    Опции запуска демона syslogd

    Раз уж мы коснулись в предыдущем подразделе вопроса задания параметров запуска демона syslogd, давайте рассмотрим этот вопрос подробнее. Как уже сказано, запускаются оба демона протоколирования на этапе инициализации системы, а конкретнее - посредством скрипта /etc/rc.d/init.d/syslog (для которого, как и для скриптов запуска других сервисов, создаются символьные ссылки в каталогах /etc/rc.d/rc?.d/). Однако для того, чтобы задать пераметры запуска, нет необходимости корректировать этот скрипт, потому что начиная с версии 7.2 в дистрибутиве Red Hat опции запуска обеих демонов считываются из отдельного конфигурационного файла /etc/sysconfig/syslog. Приведем краткий перечень возможных параметров для демона syslogd.
    Параметры запуска syslogd:
    • -a socket - Задает дополнительный сокет, который будет прослушиваться демоном syslogd. Можно задать до 19 сокетов (можно и больше, но для этого надо перекомпилировать пакет). Эта опция используется в тех случаях, когда какой-то другой демон (например, ftp или http) выполняется в ограниченном окружении (делает chroot).
    • -d - Отладочный режим. При этом демон не переходит в фоновый режим и выдает все сообщения на текущий терминал.
    • -f имя-конфигурационного-файла Задает имя альтернативного конфигурационного файла, который будет использоваться вместо заданного по умолчанию /etc/syslog.conf.
    • -h По умолчанию в sysklogd запрещена передача сообщений, принятых по сети, на какой-то другой компьютер. Это сделано с той целью, чтобы не образовывались бесконечные пересылки сообщений по кольцу. Опция -h позволяет изменить обычное поведение и обеспечить передачу сообщений, принятых от удаленных хостов, далее по сети (а уж о возможном зацикливании позаботьтесь сами).
    • -l список-хостов - Задает список хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN - Full Qwalified Domain Name); имена в списке разделяются двоеточием.
    • -m минут Запущенный без этой опции sysklogd регулярно (через каждые 20 минут) записывает в протокол сообщения категории mark, то есть просто временные отметки. С помощью опции -m можно либо изменить интервал между отметками, либо вовсе отменить выдачу таких сообщений, для чего надо задать нулевой интервал: -m 0.
    • -n Не уходить в фоновый режим; опция необходима в тех случаях, когда syslogd запускается и управляется процессом init.
    • -p socket Задает альтернативный сокет UNIX (вместо прослушиваемого по умолчанию /dev/log). Обратите внимание: опция -a задает дополнительные сокеты, а -p - альтернативный!
    • -r Разрешить принимать сообщения от удаленных хостов. Об этом мы говорили в предыдущем разделе, поэтому подробности опускаю.
    • -s список-доменов Задает список доменов, имена которых не нужно записывать в протокол вместе с именем хоста (то есть для этих доменов вместо полного доменного имени (FQDN) в протокол будут писаться только имена хостов. Имена в списке разделяются двоеточием. Имя домена, в котором расположен сервер syslogd, указывать в этом списке не требуется (его имя удаляется по умолчанию).
    • -v Показать версию и закончить работу.
    • -x Запретить определять имя хоста по его адресу, предотвращает deadlock при работе на одном хосте с сервером DNS.

    После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.

    С помощью команды
    kill -SIGNAL `cat /var/run/syslogd.pid`
    вы можете послать демону syslogd один из следующих сигналов:
    • SIGHUP - перезапуск демона (реинициализация); все открытые файлы закрываются, демон стартует заново, перечитывая при этом свой конфигурационный файл.
    • SIGTERM - завершение работы.
    • SIGINT, SIGQUIT - если включен режим отладки (опция -d), сигналы игнорируются, в противном случае - завершение работы.
    • SIGUSR1 - включить/выключить режим отладки (работает только в том случае, если демон был запущен с ключом -d).

    Демон klogd имеет не меньше опций запуска, чем syslogd, однако приводить их здесь не будем, отсылая читателя к соответствующей man-страничке (пользователю не стоит заниматься настройкой klogd, лучше оставить ее в том состоянии, как она произведена разработчиками дистрибутива).

    Файл dmesg и команда dmesg

    Как уже говорилось, файлы протоколов, упоминаемые в файле /etc/syslog.conf обычно располагаются в каталоге /var/log и его подкаталогах. Но, если заглянуть в этот каталог, то мы обнаружим там несколько файлов, которые в /etc/syslog.conf не упоминались. Давайте рассмотрим их назначение. И начнем, пожалуй, с файла dmesg.

    Сначала необходимо упомянуть, что в Linux имеется команда с таким же названием. Если сравнить вывод этой команды (когда она запущена без параметров) с содержимым файла /var/log/dmesg, то обнаружится что они очень похожи, хотя и не идентичны (направьте вывод команды в файл dmesg2 и сравните файлы dmesg и dmesg2). Точнее, файл /var/log/dmesg один в один совпадает с началом того вывода, который мы получим по команде dmesg. Как следует из [4,6], в ядре имеется кольцевой буфер, в который записываются сообщения демона протоколирования ядра. Те сообщения, которые записываются в этот буфер в процессе загрузки, и составляют содержание файла /var/log/dmesg. По-видимому, этот файл формируется по окончанию загрузки системы.

    Если вы снова посмотрите на приведенный листинг файла /etc/syslog.conf, то увидите, что все сообщения категории kern выдаются также и на консоль. Но там они быстро пробегают по экрану и вы вряд ли успеваете их прочитать и осмыслить. Зато они сохранены в файле /var/log/dmesg и тем самым доступны для неторопливого осмысления (если процесс загрузки успешно завершился). После окончания процесса загрузки запись сообщений от ядра в кольцевой буфер продолжается. Когда выполняется команда dmesg, выдается текущее состояние буфера. Поэтому вывод этой команды содержит больше сообщений, чем файл /var/log/dmesg: в выводе этой команды вы видите и те сообщения, которые ядро выдает после окончания процесса загрузки.

    Все сообщения из /var/log/dmesg вы обнаружите и в файле /var/log/messages, только там они чередуются с сообщениями от других программ. Имеется только одно существенное различие: в файле dmesg время и источник сообщения (имя хоста и категория сообщения) не указываются. Хост тут всегда "местный", а начало отсчета времени определяется последней перезагрузкой компьютера.

    Файлы lastlog, wtmp и utmp

    Кроме файла dmesg в каталоге /var/log/ есть еще два файла, не упоминавшихся в /etc/syslog.conf, но имеющих непосредственное отношение к протоколированию - это файлы lastlog и wtmp. Но заглядывать в них так же, как мы просматривали файл /var/log/messages не имеет смысла - вы ничего не поймете. Дело в том, что информация в эти файлы записывается в особом формате, и просматривать ее надо с помощью специальных программных средств. Но сначала надо сказать несколько слов о назначении этих файлов.

    Файл lastlog хранит информацию о последнем входе пользователя в систему. Не знаю, обращали ли вы внимание на то, что когда вы вводите имя и пароль пользователя, на экране появляется примерно следующее ссобщение:

    localhost login: kos
    Password:
    Last login: Wed Oct 9 19:25:53 on tty1 
    
    Эти три строки формируются утилитой login, которая после определения того, что пользователь имеет право входа в систему, обращается к файлу /var/log/lastlog, извлекает оттуда информацию о предыдущем успешном входе пользователя, выдает ее на экран, а затем обновляет запись в файле lastlog. Можно отменить вывод этого сообщения, создав пустой файл .hushlogin в своем домашнем каталоге. Однако делать этого не рекомендуется, скорее наоборот, стоит обращать особое внимание на содержание этого сообщения, чтобы не пропустить случаев, когда кто-то другой входил в систему под вашим именем.

    В отличие от файла /var/log/lastlog, который содержит записи о времени последнего входа в систему каждого пользователя, в файле /var/log/wtmp запоминаются все входы и выходы пользователей в систему с момента создания этого файла. Как и в файле lastlog, записи в /var/log/wtmp делаются в специальном формате, так что просматривать их можно только с помощью специальных команд. Но, прежде чем рассказывать об этих командах, скажем, что существует еще один файл, содержащий записи о логировании пользователей - это файл /var/run/utmp. Этот файл содержит информацию о том, кто из пользователей работает в системе в данный момент.

    Вот теперь можно рассказать о том, как просматривать информацию о работающих или ранее работавших в системе пользователях. Основной командой для этого является команда last. Она выводит все записи из файла /var/log/wtmp, причем указывается имя пользователя, указание на терминал, с которого работал пользователь, время входа пользователя в систему и время выхода его из системы, а также продолжительность сеанса работы пользователя в системе. В случае, если работа пользователя прервалась только из-за отключения самой системы, вместо времени выхода пользователя стоит слово "down" (по этим строкам легко определить время остановки системы). Время повторного запуска отображается отдельными строками, начинающимися словом "reboot".

    Команда lastb подобна команде last, но выводит информацию о неудачных попытках входа пользователей в систему. Однако, надо отметить, что эта команда будет работать только в том случае, если существует файл /var/log/btmp. Впрочем, ни одна из рассматриваемых здесь программ не создает файлов регистрации, поэтому если какой-то из них удален, то ведение записей заканчивается.

    Команда lastlog форматирует и выводит содержание файла /var/log/lastlog. Будут выведены поля имя пользователя, имя терминала, с которого вошел пользователь и время последнего входа в систему. По умолчанию (когда команда введена без параметров) элементы файла /var/log/lastlog будут выводиться в порядке номеров идентификаторов пользователей. Если указать параметр -u login-name, будет выведена только информация о времени последнего входа указанного пользователя. Указав параметр -t days, Вы получите только записи за последние days дней. Если пользователь вообще пока не заходил в систему, то вместо имени терминала и времени последнего входа будет указана строка "**Never logged in**".

    При выполнении команды lastlog на медленном компьютере в некоторых случаях может возникнуть впечатление, что команда "зависла". Это происходит в силу того, даже если в системе зарегистрировано всего два пользователя (root и user), в файле /var/log/lastlog все равно отведено место для максимально возможного числа пользователей, которые могут работать в системе. Поэтому в файле /var/log/lastlog могут иметься большие промежутки между номерами идентификаторов работавших в системе пользователей. Поскольку при просмотре таких интервалов программа не выводит информацию на экран, и возникает впечатление "зависания".

    Для вывода информации о том, кто работает в текущий момент в системе, используются команды w, who и users. Команда users используется тогда, когда вы хотите только знать, кто из пользователей работает в данный момент в системе, но не интересуетесь тем, с какого терминала он подключился и что делает. Если вы хотите знать, кто с какого терминала вошел в систему, используйте команду who. Эта команда выводит информацию из файла /var/run/utmp. Можно заставить ее выводить данные из файла /var/log/wtmp (или любого другого файла, для которого это имеет смысл), если указать имя этого файла в командной строке. Но в выводе вы все равно увидите только имя пользователя, указание на терминал, с которого вошел пользователь, время входа и, в случае входа с удаленного компьютера, имя этого компьютера.

    Существенно больше информации выводит команда w. В ее выводе вы увидите текущее время, как долго система уже работает, сколько пользователей в данное время работает в системе и средняя загузка системы за последнюю минуту, 5 и 15 минут. Затем для каждого пользователя выводится:

  • имя пользователя,
  • имя терминала,
  • имя удаленного хоста
  • время, прошедшее с момента входа в систему,
  • время, в течение которого данный терминал не используется (idle time),
  • суммарное время, затраченное всеми процессами, запущенными с данного терминала (графа JCPU),
  • время, в течение которого работает последний из запущенных пользователем процессов (графа PCPU),
  • информация о том, какая именно программа выполняется в данный момент пользователем (в виде командной строки запуска команды со всеми параметрами).

    Как уже говорилось, команда w выводит информацию, сохраненную в файле utmp. Между прочим, руководство man утверждает, что простые пользователи должны быть лишены права записи в файл utmp, так как многие системные программы (по каким-то необъяснимым причинам) зависят от его целостности. Вы рискуете спутать системные файлы статистики и внести изменения в системные файлы, если Вы предоставите любому пользователю возможность производить записи в файл utmp .

    Файлы протоколов других программ

    Кроме тех файлов, о которых мы уже рассказали, существуют и другие файлы протоколов, которые создаются отдельными программами. Наиболее характерными примерами могут служить протоколы работы демонов samba, ftpd или httpd, которые ведутся в отдельных файлах. Некоторые из этих программ создают свои протоколы в подкаталогах каталога /var/log/, другие сохраняют протоколы в других местах. И структура этих файлов может существенно отличаться от структуры файлов, создаваемых системой syslog. Приведу для примера несколько строк из протокола сервера Apache, запущенного на моем компьютере:
    192.168.36.21 - - [18/Oct/2002:11:58:05 +0400] "GET /ve/papers/new/log/ HTTP/1.1" 200 1774 
    		"-" "Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
    192.168.36.21 - - [18/Oct/2002:11:58:05 +0400] "GET /icons/back.gif HTTP/1.1" 304 - "-" 
    		"Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
    192.168.36.21 - - [18/Oct/2002:11:58:05 +0400] "GET /icons/folder.gif HTTP/1.1" 304 - "-" 
    		"Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
    192.168.36.21 - - [18/Oct/2002:11:58:05 +0400] "GET /icons/text.gif HTTP/1.1" 304 - "-" 
    		"Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
    192.168.36.21 - - [18/Oct/2002:11:58:09 +0400] "GET /ve/papers/new/log/protok_lovim.htm 
    		HTTP/1.1" 200 46597 "http://linux/ve/papers/new/log/" "Mozilla/5.0 
    		(X11; U; Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
    192.168.36.21 - - [18/Oct/2002:11:58:09 +0400] "GET /bugtraq.css HTTP/1.1" 404 279 
    		"http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; 
    		Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
    192.168.36.21 - - [18/Oct/2002:11:58:10 +0400] "GET /img/bug1.gif HTTP/1.1" 404 280 
    		"http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; 
    		Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
    192.168.36.21 - - [18/Oct/2002:11:58:10 +0400] "GET /img/title.gif HTTP/1.1" 404 281 
    		"http://linux/ve/papers/new/log/protok_lovim.htm" "Mozilla/5.0 (X11; U; 
    		Linux i686; ru-RU; rv:1.0.0) Gecko/20020530"
    
    Как видите, структура этого файла протокола существенно отличается от того, что мы видели в системных протоколах.

    Samba-сервер, кроме основного протокола работы сервера, создает в подкаталоге /var/log/samba целый ряд файлов протоколов на разные случаи, в частности отдельные файлы для каждого из пользователей, которым разрешено использовать ресурсы, предоставляемые этим сервером. Из одного такого файла и взяты следующие две записи:

    [2002/03/20 13:57:07, 1] smbd/service.c:make_connection(550)
      linux (192.168.36.10) connect to service public as user kos (uid=500, gid=500) (pid 1366)
    [2002/03/20 14:25:01, 1] smbd/service.c:close_cnum(550)
      linux (192.168.36.10) closed connection to service public
    
    Приведенные примеры показывают, что если немного уметь читать по-английски и иметь некоторое представление о структуре записей, из файлов протоколов можно извлечь массу полезной информации. Только извлекать ее приходится из целых залежей "пустой породы" - огромных последовательных файлов протоколов, что представляет собой нетривиальную задачу. Поэтому были разработаны специальные программные средства для анализа протоколов.

    Средства для обработки протоколов

    Различных программ и скриптов для анализа протоколов разработано достаточно много. Я ограничусь краткой характеристикой двух таких средств: logwatch и swatch.

    logwatch - это скрипт на языке Perl, входящий в стандартный дистрибутив Red Hat Linux. Как раз во время подготовки настоящей статьи на сайте разработчика (а им является Кирк Бауер) была выложена версия 4.1 этой программы [7].

    Основная идея, заложенная в эту программу, заключается в том, что файл протокола пропускается через фильтр, который выделяет из протокола все строки (то есть сообщения), удовлетворяющие заданному критерию. Результаты отправляются по электронной почте указанному пользователю (по умолчанию - root-у). Фильтры могут быть написаны на любом языке программирования, но автор пакета предпочитает Perl. Фильтры должны быть написаны так, что читают данные с stdin и выводят результат на stdout.

    Основной способ использования logwatch состоит во включении ссылки на основной скрипт (/etc/log.d/scripts/logwatch.pl) в директорию /etc/cron.daily, что вызывает ежедневное выполнение logwatch с параметрами по умолчанию. Ссылке дают имя, которое начинается с "00" (например, 00-logwatch), чтобы скрипт запускался до logrotate.

    Но можно запустить скрипт и из командной строки. Конечно, если вы не меняли параметр вывода информации, то результат его работы надо искать в почтовом ящике суперпользователя. Если же вы хотите видеть эти результаты на экране, то необходимо задать в командной строке параметр --print - выдавать отчет на stdout.

    Общий формат запуска скрипта:

    /etc/log.d/scripts/logwatch.pl [--detail уровень] [--logfile группа-журналов] [--service имя-сервиса] [--print] [--mailto адрес] [--save имя-файла] [--archives] [--range интервал-дат]

    Параметры по умолчанию хранятся в файле /etc/log.d/logwatch.conf, комментарии в котором позволяют понять смысл параметров командной строки:

    • LogDir - директория, относительно которой рассматриваются имена файлов;
    • MailTo - кому отправлять отчет;
    • Print - вместо посылки отчета по почте выдать его на stdout;
    • Save - вместо посылки отчета по почте сохранить его в указанном файле;
    • Archives - обрабатывать не только текущие версии журналов, но и созданные logrotate старые копии;
    • Range - обрабатывать указанный временной интервал: All, Today, Yesterday (вчерашние календарные сутки);
    • Detail - уровень подробности отчета: от 0 до 10 или Low, Med, High;
    • Service - All или имя фильтра из /etc/log.d/scripts/services/ (можно указывать несколько фильтров);
    • LogFile - All или имя группы журналов (можно указывать несколько групп).

    Более подробную информацию о скрипте logwatch вы найдете в [8,9].

    В статье [10] описан другой скрипт для обработки файлов протоколов, который входит в состав дистрибутива Mandrake Linux. Скрипт этот называется swatch ("Simple WATCHer") и тоже написан на Perl.

    Управление работой swatch осуществляется с помощью единственного конфигурационного файла, по умолчанию $HOME/.swatchrc. Этот файл содержит образцы текста (в форме регулярных выражений), которые swatch будет искать в файлах протоколов. Вслед за каждым таким образцом указывается действие, которое swatch должен предпринять в том случае, если он обнаружит текст, соответствующий шаблону.

    Например, вы хотите получать предупреждение при каждой попытке атаки на ваш web-сервер методом переполнения буфера при запросе очень длинного имени файла (buffer-overflow attack). И вы знаете, что в таких случаях в файле протокола /var/apache/error.log появляется сообщение, содержащее слова "File name too long". В таком случае в ваш файл .swatchrc необходимо вставить следующее указание:

    watchfor /File name too long/
        mail addresses=root@somedomain.com,
        subject=BufferOverflow_attempt
    

    Я не буду приводить здесь более подробное описаие программы swatch. Ей посвящена восторженная статья [10], а саму программу можно найти на сайте [11]. Хочется только отметить, и swatch, и logwatch реализуют довольно примитивный алгоритм обработки файлов протоколов, сводящийся к поиску в протоколе заданной строки символов (сигнатуры). Между тем, во-первых, наличие такой строки зачастую еще не свидетельствует о вторжении злоумышленника, а, во-вторых, грамотный злоумышленник может позаботиться о том, чтобы стереть следы свой деятельности [12]. Еще один очевидный недостаток рассмотренных продуктов заключается в том, что они работают в "отложенном режиме", поскольку запускаются только по расписанию. А борьбу со злоумышленниками надо вести "в режиме реального времени", немедленно реагируя на попытки проникновения в систему. Поэтому в коммерческих продуктах предлагаются системы мониторинга, работающие постоянно, и реализующие "интеллектуальные" алгоритмы анализа протоколов. Эти алгоритмы основываются на статистическом анализе потока сообщений и выявлении статистически значимых отклонений системы от ее нормального поведения.

    В заключение этого раздела отмечу, что на сайте SecurityLab.ru (http://www.securitylab.ru/tools/?ID=22111) приведен список ссылок на сайты различных программных средств для обработки протоколов с краткой характеристикой этих средств. Вы можете поэкспериментировать с различными программами и выбрать ту, которая вас устроит.

    Ротация файлов протокола

    Вы, конечно, понимаете, что если система интенсивно используется, то файлы протоколов быстро растут. Что влечет пустую трату дискового пространства. И возникает проблема "укрощения" протоколов. В Red Hat Linux эта проблема решается скриптои logrotate, который расположен в каталоге /etc/cron.daily, а, следовательно, запускается демоном cron ежедневно. Этот скрипт позволяет обрабатывать не только журналы системы syslog, но и любых других программ.

    Скрипт logrotate следит за ростом файлов протоколов и обеспечивает так называемую ротацию этих файлов в случае, если они превысили указанный размер (или по истечению указанного временного интервала). Ротация есть не что иное, как последовательное копирование предыдущих версий архивных файлов примерно следующим образом:

  • messages.2 -> messages.3
  • messages.1 -> messages.2
  • messages.0 -> messages.1
  • messages -> messages.0
    и создание нового файла messages для записи последующих сообщений.

    Перечень файлов для обработки скриптом logrotate и параметры этой обработки определяются конфигурационными файлами, которых может быть несколько. Имена конфигурационных файлов задаются в командной строке запуска скрипта (о параметрах запуска см. ниже). В Red Hat Linux по умолчанию в качестве конфигурационных файлов для logrotate используется файл /etc/logrotate.conf, который может иметь примерно такой вид:

    weekly
    rotate 4
    create
    compress
    include /etc/logrotate.d
    
    /var/log/wtmp /var/log/lastlog {
        monthly
        create 0664 root utmp
        rotate 1
    }
    

    Этот файл как и любой конфигурационный файл для скрипта logrotate состоит из нескольких секций. Первая секция определяет глобальные параметры (по одному на строке), задающие параметры по умолчанию для всех журналов. Следующие секции определяют локальные параметры для серии файлов протоколов. Имена этих файлов перечисляются в первой строке секции, а затем в фигурных скобках задаются локальные параметры, действующие только при обработке указанных файлов (тоже по одному параметру в строке). Имена файлов протоколов могут быть заключены в кавычки по правилам shell, если они содержат пробелы и другие специальные символы. Можно указывать несколько имен файлов или шаблонов имен файлов через пробел (шаблоны также по правилам shell). Обработка каждой секции рассматривается как единое действие. Строки, начинающиеся с символа "#" являются комментраиями. Локальные параметры имеют приоритет над глобальными.

    В приведенном примере конфигурационного файла сначала описываются глобальные параметры, а затем в отдельной секции - параметры обработки файлов /var/log/wtmp и /var/log/lastlog. Кроме того, среди глобальных параметров дается ссылка на директорию /etc/logrotate.d, в которую каждый пакет записывает локальные параметры для своих журналов.

    В секции глобальных параметров в первую очередь задается один из следующих параметров, определяющих критерий ротации файлов:

  • daily - смена версий в серии происходит ежедневно,
  • weekly - смена версий происходит еженедельно,
  • monthly - смена версий происходит ежемесячно,
  • size байт - смена версии происходит, если размер журнала превысил указанное число байт; можно использовать суффиксы "k" - килобайт - и "M" - мегабайт)

  • и параметр include, после которого может быть указано имя другого (дополнительного) конфигурационого файла или даже имя директории. В последнем случае все файлы в указанной директории, кроме подкаталогов, специальных файлов и файлов с суффиксами из списка исключений считаются конфигурационными файлами для скрипта logrotate (директиву include нельзя использовать внутри секции, задающей параметры обработки для группы файлов).

    Параметр rotate число может находиться как среди глобальных, так и среди локальных параметров и определяет сколько старых версий надо хранить; если число равно 0, то архивные версии протокола не создаются.

    Если задан параметр compress, то старые версии сжимаются с помощью gzip, а если указано nocompress - то не сжимаются. Параметр compresscmd позволяет указать, какая программа сжатия будет использоваться (по умолчанию - gzip), а uncompresscmd задает программу разжатия (по умолчанию - ungzip). compressoptions задает параметры программы сжатия; по умолчанию - "-9", т.е. максимальное сжатие для gzip. С помощью параметра compressext можно изменить суффикс для сжатых файлов, а параметр extension суффикс задает суффикс, добавляемый к именам файлов при ротации (перед суффиксом сжатия).

    Среди ключевых слов, встречающихся в конфигурационных файлах, надо особо отметить слова postrotate и prerotate, которые служат открывающими скобками для включения в конфигурационные файлы скриптов оболочки shell. Все строки конфигурационного файла от строки postrotate до строки endscript исполняются как команды shell после процесса смены версии файла протокола. Соответственно, все строки от строки prerotate до строки endscript исполняются до выполнения ротации файлов протокола. С помощью этих скриптов можно организовать различные процедуры обработки файлов протоколов в процессе ротации.

    С помощью других параметров конфигурационого файла можно переопределить права доступа к файлам протоколов (если этот параметр не задан, то используются аттрибуты старого файла протокола); указать, кому посылать сообщения об ошибках функционирования системы протоколирования; послать архивную копию журнала указанному пользователю; задать каталог, в который будут перемещаться протоколы во время смены версий (каталог должен находиться на том же физическом устройстве, что и /var/log) или задать список суффиксов-исключений для директории include. Подробное описание этих возможностей и параметров (а также тех, которые не были упомянуты) вы найдете по команде man logrotate.

    Как уже было сказано, дополнительные конфигурационные файлы logrotate могут быть заданы в командной строке запуска скрипта. Можно указать произвольное число имен конфигурационных файлов или каталогов. Имена файлов и каталогов в этом списке разделяются просто пробелами. Порядок перечисления имен в списке имеет значение, поскольку параметры, указанные в следующем конфигурационном файле, перекрывают значение параметров, указанных в предыдущем файле. Порядок файлов в конфигурационной директории не определен.

    Кроме того, в командной строке запуска можно указать следующие параметры:

    • -d - отладочный режим, реальных изменений не производится,
    • -f - производить изменения, даже если logrotate не видит необходимости - используется при изменениях в списке обрабатываемых журналов,
    • -s имя-файла-состояния - в этом файле (по умолчанию - /var/lib/logrotate.status) запоминаются имена файлов, которые были обработаны скриптом и даты, когда была произведена его обработка,

    Дополнительные замечания

    В завершение данной статьи хочется привести несколько коротких замечаний (заимствованных на сайте С.Богомолова [8]) по вопросам, не нашедшим отражения в предыдущем тексте.

    1. Как было сказано в самом начале статьи, syslogd рассчитан на обработку сообщений, формируемых функцией syslog стандартной билиотеки языка C. Поэтому, если эта библиотека по каким-либо причинам функционирует не корректно, система протоколирования откажется работать.
    2. Если при настройке протоколирования в сети указать неправильный адрес (имя) сервера, то никаких сообщений об ошибке не будет - сообщения будут удаляться (или записываться в чужой журнал).
    3. Никаких мер от зацикливания процессов передачи сообщений по сети не предусмотрено. При локальной обработке сообщений категории syslog тоже надо учитывать, что не стоит записывать в протокол сообщение о том, что поступило сообщение от системы протоколирования (последствия Вы легко можете представить).
    4. Демон syslogd запускается с правами root. Если вынужден создавать файл, то задает права доступа к нему равными 644. В процессе работы права доступа к файлам не меняет . При необходимости ограничить доступ к журналу, соответствующий файл надо создать вручную (или поменять права доступа).
    5. У протокола syslogимеется несколько изъянов с точки зрения безопасности:
      • Протокол не содержит никаких средств защиты от подделок сообщений. Хуже того, использование протокола UDP позволяет злоумышленникам посылать сообщения от имени любого хоста. Локальная сеть должна быть защищена экраном от приема пакетов с поддельными локальными адресами (хотя это не помешает посылать поддельные сообщения изнутри локальной сети) и от приема пакетов снаружи на порт 514/udp.
      • Протоколы syslog и UDP не обеспечивают гарантированной доставки (сообщения могут быть потеряны при перегрузке сети или перехвачены, поврежденные сообщения удаляются без предупреждения), правильной последовательности доставки (сообщение о завершении процесса может прийти раньше сообщения о его запуске), приоритетной доставки.
      • Конфиденциальность сообщений не обеспечивается, так как они передаются открытым текстом.
      Поэтому были предложены несколько проектов [15-19] улучшения протокола syslog. Например, документ RFC 3195 предлагает систему протоколирования (syslog-conn), основанную на TCP, обеспечивающую гарантированную доставку сообщений в правильной последовательности. Проект syslog-sign предлагает обеспечить аутентификацию, упорядоченность, целостность сообщений и обнаружение пропавших сообщений за счет генерации специальных сообщений, содержащих цифровую подпись (signature) блока предыдущих сообщений с сохранением стандартного протокола и формата syslog и использованием UDP.

      В проекте syslog-ng предлагается использовать для передачи сообщений протокол TCP, маршрутизацию сообщений в зависимости от источника и текста сообщения; сжатие и шифрование файлов протоколов; выдача журнала на stdin запускаемой программы и много других полезных вещей.

    Источники и ссылки

    1. Е.Горный "Сага о Митнике"
    2. "Узнай своего врага: Проводим следствие"
    3. www.infodrom.org/projects/sysklogd/ Сайт разработчика пакета sysklogd ("стандартные" syslogd и klogd)
    4. man syslog(2), syslog(3), syslogd, klogd, syslog.conf
    5. man logger, tailf
    6. man dmesg, last, lastb, who, w
    7. logwatch.org
    8. С.Богомолов, "Syslog - сетевой системный журнал"
    9. man logwatch
    10. Mick Bauer, "Paranoid Penguin: swatch: Automated Log Monitoring for the Vigilant but Lazy"
    11. http://www.stanford.edu/~atkins/swatch
    12. "Логи в Linux"
    13. RFC 3164. C. Lonvick, The BSD Syslog Protocol, August 2001.
    14. RFC 3195. D. New, M. Rose, Reliable Delivery for syslog, November 2001.
    15. syslog-ng
    16. nsyslogd
    17. Cryptographic Support for Secure Logs on Untrusted Machines
    18. Пер. С.Лапшанский, "Демон следит за системой"
    19. Денис Колисниченко, Протоколирование

    Эта статья еще не оценивалась
    Вы сможете оценить статью и оставить комментарий, если войдете или зарегистрируетесь.
    Только зарегистрированные пользователи могут оценивать и комментировать статьи.

    Комментарии отсутствуют