17.4 Управление системными журналами (Managing System Logs)

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

• Настройка файлов журналов
• Использование файлов журналов для устранения неполадок
• Использование файлов журналов для обнаружения злоумышленников

Начнём с настройки файлов журналов.

Настройка файлов журналов (Configuring Log Files)

Системные файлы журналов хранятся в каталоге /var/log, показанном на рис. 17-15.

Рис. 17-15. Содержимое каталога /var/log.

Обратите внимание: в /var/log есть ряд подкаталогов, где системные демоны — mysql, apparmor, audit, cups — хранят свои журналы. Некоторые файлы журналов представляют собой простые текстовые файлы, доступные для чтения стандартными утилитами. Другие — двоичные файлы, требующие специальных утилит, например lastlog. Среди множества файлов в /var/log и его подкаталогах одни значительно полезнее других. Таблица 17-5 содержит список наиболее важных файлов журналов.

Файл журнала	Описание
boot.log	Записи демонов при запуске в ходе загрузки системы.
boot.msg	Все сообщения, отображаемые на экране при загрузке системы. Очень ценный инструмент диагностики — загрузочные сообщения обычно мелькают на экране слишком быстро для чтения.
faillog	Неудачные попытки аутентификации.
firewall	Записи межсетевого экрана.
lastlog	Информация о последнем входе в систему для каждого пользователя.
mail	Сообщения, генерируемые демонами postfix и sendmail.
messages	Сообщения от большинства запущенных процессов. Вероятно, один из наиболее полезных журналов: по нему можно диагностировать незапускающиеся и некорректно работающие службы.
warn	Предупреждения.
wtmp	Список пользователей, прошедших аутентификацию в системе.
xinetd.log	Записи демона xinetd.

Табл. 17-5. Полезные файлы журналов.

Примечание

Файлы из таблицы 17-5 — журналы SUSE Linux. В других дистрибутивах по умолчанию могут использоваться другие файлы. Журналирование можно настроить с помощью файла syslog.conf, описанного далее.

Реализация журналирования в Linux зависит от используемого дистрибутива. Для экзамена Linux+/LPIC-1 необходимо знать следующие реализации:

• syslogd
• journald

syslogd

В Linux-системах с демоном init журналирование обычно обеспечивает демон syslogd. Вместо того чтобы каждый демон вёл собственный журнал, большинство Linux-служб по умолчанию настроены на запись записей в /dev/log. Этот файл устройства поддерживается демоном syslogd. Когда служба записывает в этот сокет, ввод перехватывается syslogd. Демон syslogd использует записи из файла /etc/syslog.conf, показанного на рис. 17-16, чтобы определить, куда направить информацию.

Рис. 17-16. Файл /etc/syslog.conf.

Примечание

Некоторые дистрибутивы Linux вместо syslogd используют syslog-ng или rsyslogd. Демон журналирования задаётся в /etc/sysconfig/syslog директивой SYSLOG_DAEMON=.

Синтаксис файла syslog.conf:

facility.priority    file

Объект (facility) — подсистема, генерирующая сообщение. Каждый процесс Linux, использующий syslog для журналирования, относится к одному из следующих объектов:

• authpriv — все службы, связанные с безопасностью системы или авторизацией
• cron — сообщения журнала от cron и at
• daemon — для демонов, не имеющих собственного объекта
• kern — все сообщения журнала ядра
• lpr — сообщения системы печати
• mail — сообщения почтового агента (например, postfix или sendmail)
• news — сообщения демона новостей
• syslog — внутренние сообщения самого демона syslogd
• user — сообщения журнала, связанные с пользователями (например, неудачные попытки входа)
• uucp — сообщения журнала демона uucp
• local0–local7 — объекты для записи сообщений журнала собственных приложений

Помимо объектов, демон syslogd поддерживает приоритеты для настройки журналирования. Приоритизацию в большинстве дистрибутивов обеспечивает демон klogd, работающий как клиент syslogd. Доступные приоритеты:

• debug — вся информация
• info — информационные сообщения
• notice — вопросы, требующие внимания, но не являющиеся проблемой
• warn — некритические ошибки
• err — серьёзные ошибки
• crit, alert или emerg — критические ошибки

Например, в файле на рис. 17-16 syslog.conf направляет сообщения всех уровней приоритета (*) объекта cron в файл /var/log/cron. При необходимости можно настроить файл syslog.conf для разделения сообщений разных уровней приоритета по разным файлам.

В дистрибутив также должна входить утилита logrotate. По умолчанию демон cron запускает её ежедневно. Настроить ротацию файлов журналов можно с помощью файла /etc/logrotate.conf, показанного на рис. 17-17.

Рис. 17-17. Настройка ротации файлов журналов в /etc/logrotate.conf.

Примечание

Некоторые дистрибутивы используют демон logrotated для управления ротацией файлов журналов.

Этот файл содержит глобальные параметры по умолчанию, используемые logrotate для определения порядка и времени ротации журналов. Однако эти параметры можно переопределить для конкретных демонов с помощью файлов конфигурации в каталоге /etc/logrotate.d/. Например, на рис. 17-18 файл /etc/logrotate.d/apache2 используется для настройки журналирования демона apache2.

Рис. 17-18. Настройка журналирования веб-сервера Apache.

В этом файле файл /var/log/apache2/access_log будет сжат. Максимальный срок хранения — 365 дней, после чего файл удаляется (maxage 365). Старые версии архивируются с расширением даты (dateext). Файл проходит 99 ротаций до удаления (rotate 99). Если файл превысит 4096 КБ, он будет ротирован (size=+4096k). Пустой файл не ротируется (notifempty). Отсутствие файла не вызывает сообщения об ошибке (missingok). Файл создаётся с правами доступа 644, владельцем root и группой root (create 644 root root). После ротации выполняется команда /etc/init.d/apache2 reload (postrotate /etc/init.d/apache2 reload).

Примечание

В файле конфигурации logrotate можно использовать множество других директив. Дополнительную информацию см. на man-странице logrotate.

Одна из полезных функций демона syslogd — поддержка журналирования на удалённом узле. Перемещение файлов журналов с локальной системы на другой компьютер в сети — ценная административная и защитная мера. Например, можно перенаправить всё журналирование от Linux-систем в сети на единственный узел журналов. Тогда при обращении пользователя с проблемой файлы его журналов будут доступны мгновенно.

Кроме того, удалённое журналирование повышает безопасность систем. Неопытные злоумышленники оставляют множество следов в файлах журналов. Опытные же пытаются замести следы, изменяя журналы после проникновения, что сильно затрудняет обнаружение вторжения. Если журналирование перенаправлено, злоумышленнику значительно сложнее скрыть следы. Для перенаправления журналирования выполните следующее:

1. Откройте сеанс терминала и выполните su – до root.
2. Откройте /etc/syslog.conf в текстовом редакторе.

3. Добавьте в начало файла следующую строку:

   *.*             @IP_address_of_loghost
   

   Например, для перенаправления всех сообщений на сервер журналов с IP-адресом 192.168.1.10:

   *.*             @192.168.1.10
   

4. Сохраните файл и выйдите из редактора.

5. Перезапустите демон syslogd.
6. Для настройки сервера журналов на приём сообщений от других систем выполните следующее:
   • Откройте /etc/sysconfig/syslog в текстовом редакторе.
   • Найдите директиву SYSLOGD_PARAMS.
   • Задайте для SYSLOGD_PARAMS значение –r.
   • Сохраните изменения и закройте файл.
   • Перезапустите syslogd.

Совет

Проверить конфигурацию журналирования можно с помощью утилиты logger. Этот инструмент командной строки позволяет вручную добавлять записи в систему журналирования. Синтаксис: logger –p facility.priority "log_message".

journald

В новых дистрибутивах Linux, использующих демон systemd, для журналирования вместо syslogd применяется демон journald. Демон journald ведёт системный журнал — журнал (journal), расположенный в /var/log/journal/. Просмотр журнала осуществляется командой journalctl. Выполнение этой команды без параметров выводит весь журнал, как показано на рис. 17-19.

Рис. 17-19. Просмотр журнала с помощью journalctl.

Одна из полезных функций демона journald — возможность просматривать загрузочные сообщения системы. Для этого в командной строке вводится journalctl –b. Отображаются сообщения последней загрузки. Кроме того, journalctl позволяет просматривать сообщения предыдущих загрузок двумя способами:

• Параметр –b с положительным числом выполняет поиск сообщений указанной загрузки, начиная с начала журнала. Например, journalctl –b 1 отобразит сообщения первой загрузки, найденные в начале журнала.
• Параметр –b с отрицательным числом выполняет поиск сообщений указанной загрузки, начиная с конца журнала. Например, journalctl –b -2 отобразит системные сообщения, созданные две загрузки назад.

Команда journalctl также позволяет выводить только записи журнала, связанные с конкретной службой. Синтаксис: journalctl –u service_name. Например, для просмотра всех записей журнала, связанных с SSH-демоном, введите journalctl –u sshd. Пример показан на рис. 17-20.

Рис. 17-20. Просмотр событий журнала sshd.

Поведение демона журнала настраивается с помощью файла /etc/systemd/journald.conf. Этот файл содержит множество параметров конфигурации. Наиболее полезные из них:

• MaxFileSec — максимальное время хранения записей в файле журнала до создания нового файла.
• MaxRetentionSec — максимальное время хранения записей журнала. Записи старше указанного срока автоматически удаляются.
• ForwardToSyslog — настраивает journald на пересылку сообщений журнала традиционному демону syslogd.
• MaxLevelStore — максимальный уровень журнала для сообщений, хранимых в файле журнала. Хранятся все сообщения с уровнем, равным указанному или ниже; сообщения выше — отбрасываются. Возможные значения:
  • emerg (0)
  • alert (1)
  • crit (2)
  • err (3)
  • warning (4)
  • notice (5)
  • info (6)
  • debug (7)

Примечание

Если дистрибутив использует systemd, но требуется функциональность syslogd, можно установить syslog-ng. Демон syslog-ng работает совместно с systemd, однако настраивается аналогично syslog.

Использование файлов журналов для устранения неполадок (Using Log Files to Troubleshoot Problems)

Как упоминалось ранее, файлы журналов — неоценимый ресурс при диагностике проблем Linux. Если ядро или служба сталкиваются с проблемой, она записывается в журнал. Просмотр журналов может предоставить массу информации, которая не отображается на экране.

Некоторые файлы журналов — двоичные и требуют специальных утилит. Большинство же — простые текстовые файлы, доступные стандартными инструментами. Ранее мы рассматривали утилиты cat, less и more для просмотра текстовых файлов. Их можно использовать и для просмотра текстовых журналов. Однако есть проблема: файлы журналов обычно слишком длинны для эффективного просмотра этими утилитами.

Например, файл /var/log/messages может содержать 10 000 и более строк. Это много текста! Утилита less отображает только 24 строки за раз — придётся часто нажимать пробел.

Есть два способа обойти это. Первый — перенаправить вывод команды cat в grep для фильтрации по конкретному слову в журнале. Например, для поиска информации о входах в систему в /var/log/messages можно ввести cat /var/log/messages | grep login | more. Будут отображаться только записи, содержащие слово «login». Если система использует systemd и журнал, аналогичное можно сделать с командой journalctl — просто перенаправить её вывод в grep с нужным словом.

Помимо grep, для просмотра записей журналов можно использовать утилиты head и tail. Большинство журналов ведутся в хронологическом порядке — от старых к новым. Для просмотра начала журнала введите head filename в командной строке. Например, на рис. 17-21 начало файла /var/log/messages выведено с помощью head.

Рис. 17-21. Использование head для просмотра файла журнала.

Утилита tail работает противоположным образом: отображает последние строки файла. Это очень удобно — при диагностике обычно нужны только последние строки журнала. Для этого введите tail filename. На рис. 17-22 файл /var/log/messages просматривается с помощью tail.

Рис. 17-22. Использование tail для просмотра файла журнала.

Утилита tail поддерживает параметр –f, который очень полезен при диагностике. При использовании –f утилита tail выводит последние строки файла как обычно, но не завершается после начального отображения. Вместо этого она следит за файлом и отображает новые строки по мере их добавления. Например, команда tail –f /var/log/messages позволяет в режиме реального времени отслеживать системный журнал на наличие сообщений об ошибках при диагностике системы.

Команда tail следит за файлом /var/log/messages в ожидании новых строк. Если происходит событие, генерирующее сообщения, — например, остановка и перезапуск сетевого интерфейса — результаты мгновенно отображаются на экране без повторного запуска tail. Завершить отслеживание файла можно нажатием Ctrl+C.

Если система использует демон journald, аналогичного результата можно добиться командой journalctl. Запустив journalctl –f в командной строке, получим последние записи журнала. Команда journalctl затем следит за журналом и выводит новые записи по мере их добавления.

Для диагностики проблем можно просмотреть один из файлов журналов из таблицы 17-5. Однако в других дистрибутивах, например Fedora, могут использоваться другие журналы:

• cron — записи от демона cron
• dmesg — информация об обнаружении оборудования
• maillog — записи от демона sendmail
• secure — информация о доступе к сетевым демонам
• rpmpkgs — список установленных RPM-пакетов

Для диагностики проблем с приложением или службой может потребоваться проверить файл журнала, поддерживаемый конкретно для этой службы. Например, для диагностики проблем с демоном postfix или sendmail на SUSE Linux следует проверить файлы mail, mail.err, mail.info и mail.warn, а на Fedora — файл maillog. При проблемах с демоном mysqld нужно смотреть файл mysqld.log в каталоге /var/log/mysql. Для диагностики веб-сервера Apache следует изучить различные файлы журналов в каталоге /var/log/apache2.

Использование файлов журналов для обнаружения злоумышленников (Using Log Files to Detect Intruders)

Обнаружение злоумышленников предполагает поиск оставленных ими следов в системе. Один из лучших ресурсов для этого — файлы журналов. Подобно следователю, нужны практика и опыт, чтобы выработать интуицию, позволяющую замечать подозрительное. Лучший способ её развить — проводить много времени за просмотром журналов. Это поможет сформировать представление о «норме» для вашей системы. Зная, что является нормой, легко заметить отклонения.

Рассмотрим несколько файлов журналов для анализа подозрительной активности.

Первый — /var/log/wtmp. Этот журнал содержит список всех пользователей, прошедших аутентификацию в системе. Файл хранится в двоичном формате: cat, less или текстовые редакторы его не прочитают. Для просмотра используется команда last. Пример вывода утилиты last показан на рис. 17-23.

Рис. 17-23. Использование last для просмотра истории входов.

Утилита last отображает учётную запись пользователя, время входа, время выхода и источник входа. При анализе этого файла обращайте внимание на всё необычное — например, входы в систему ночью, когда никто не работает.

Можно также просмотреть файл /var/log/faillog. Этот журнал содержит список неудачных попыток аутентификации и очень эффективен при обнаружении словарных атак (dictionary attacks) — перебора словарных слов в качестве паролей. Как и wtmp, файл faillog двоичный. Для его просмотра используется утилита faillog, отображающая пользователя, количество неудачных попыток входа и время последней неудачной попытки. Параметр –u позволяет просмотреть попытки входа для конкретной учётной записи: faillog –u rtracy.

При анализе этого журнала обращайте внимание на необычные попытки входа — например, аномально большое количество неудачных попыток, особенно поздно ночью. Утилита faillog также позволяет задать поведение системы при неудачных попытках входа:

• –l seconds — блокирует учётную запись на указанное число секунд после неудачной попытки входа
• –m number — задаёт максимальное число неудачных попыток входа до отключения учётной записи

Следующий файл журнала — /var/log/lastlog. Он содержит список всех пользователей системы и время их последнего входа. Как и другие рассмотренные журналы, lastlog нельзя просмотреть с помощью less, cat или текстового редактора. Для просмотра используется утилита lastlog, как показано на рис. 17-24.

Рис. 17-24. Использование lastlog для просмотра времени последнего входа.

Последний тип журналов для обнаружения попыток вторжения — /var/log/messages и журнал journald (если дистрибутив его использует). Как упоминалось ранее, эти журналы содержат сообщения от всех запущенных служб, поэтому включают большой объём данных, которые могут быть или не быть связаны с попытками вторжения. Для выделения нужных записей можно использовать grep. Например, команда cat /var/log/messages | grep login | more позволяет просмотреть записи о входах в систему. Аналогичное можно сделать с помощью команды journalctl.

Помимо просмотра журналов, для определения текущих пользователей системы можно использовать ряд инструментов командной строки. Первый — команда who. С её помощью можно узнать, кто в данный момент вошёл в систему. На рис. 17-25 видно, что в систему вошли пользователи rtracy и ksanders. Пользователь rtracy вошёл в первый сеанс X-сервера (:0) и открыл сеанс терминала на консоли. Пользователь ksanders вошёл через SSH-соединение с узла с IP-адресом 10.0.0.60. Также для просмотра текущих пользователей системы можно использовать утилиту finger, как показано на рис. 17-25.

Рис. 17-25. Использование who и finger.

Далее рассмотрим настройку xinetd и inetd.