Администрирование систем Linux. Журналирование событий

Глава 17. Журналирование событий

В данной главе обсуждаются три отдельных вопроса.

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

Во-вторых, рассматривается процесс настройки демона syslog, а также его тестирования с помощью утилиты logger.

Последняя часть главы в основном посвящена механизму ротации фалов журналов, а также содержит пояснения относительно использования команд tail -f и watch для отслеживания изменений файлов журналов.

17.1. Журналирование входов в систему

С целью облегчения процесса отслеживания входов пользователей в систему Linux может записывать необходимые данные в файлы журналов /var/log/wtmp, /var/log/btmp, /var/run/utmp и /var/log/lastlog.

17.1.1. Файл журнала /var/run/utmp (who)

Используйте утилиту who для просмотра содержимого файла /var/run/utmp. Эта утилита выводит информацию о пользователях, осуществивших вход в систему и в данный момент работающих с ней. Обратите внимание на то, что файл utmp находится в директории /var/run, а не /var/log.

[root@rhel4 ~]# who
paul     pts/1        Feb 14 18:21 (192.168.1.45)
sandra   pts/2        Feb 14 18:11 (192.168.1.42)
inge     pts/3        Feb 14 12:01 (192.168.1.33)
els      pts/4        Feb 14 14:33 (192.168.1.19)

17.1.2. Файл журнала /var/log/wtmp (last)

Содержимое файла журнала /var/log/wtmp обновляется силами программы login. Используйте утилиту last для просмотра содержимого файла журнала /var/run/wtmp.

[root@rhel4a ~]# last | head
paul     pts/1       192.168.1.45     Wed Feb 14 18:39   still logged in
reboot   system boot 2.6.9-42.0.8.ELs Wed Feb 14 18:21          (01:15) 
nicolas  pts/5       pc-dss.telematic Wed Feb 14 12:32 - 13:06  (00:33) 
stefaan  pts/3       pc-sde.telematic Wed Feb 14 12:28 - 12:40  (00:12) 
nicolas  pts/3       pc-nae.telematic Wed Feb 14 11:36 - 12:21  (00:45) 
nicolas  pts/3       pc-nae.telematic Wed Feb 14 11:34 - 11:36  (00:01) 
dirk     pts/5       pc-dss.telematic Wed Feb 14 10:03 - 12:31  (02:28) 
nicolas  pts/3       pc-nae.telematic Wed Feb 14 09:45 - 11:34  (01:48) 
dimitri  pts/5       rhel4            Wed Feb 14 07:57 - 08:38  (00:40) 
stefaan  pts/4       pc-sde.telematic Wed Feb 14 07:16 - down   (05:50) 
[root@rhel4a ~]#

Утилита last также может использоваться и для получения информации о последних перезагрузках.

[paul@rekkie ~]$ last reboot 
reboot   system boot  2.6.16-rekkie   Mon Jul 30 05:13     (370+08:42) 

wtmp begins Tue May 30 23:11:45 2006
[paul@rekkie ~]

17.1.3. Файл журнала /var/log/lastlog (lastlog)

Используйте утилиту lastlog для просмотра содержимого файла /var/log/lastlog.

[root@rhel4a ~]# lastlog | tail
tim              pts/5  10.170.1.122     Вт фев 13 09:36:54 +0100 2007
rm               pts/6  rhel4            Вт фев 13 10:06:56 +0100 2007
henk                                     **Никогда не входил в систему**
stefaan          pts/3  pc-sde.telematic Ср фев 14 12:28:38 +0100 2007
dirk             pts/5  pc-dss.telematic Ср фев 14 10:03:11 +0100 2007
arsene                                   **Никогда не входил в систему**
nicolas          pts/5  pc-dss.telematic Ср фев 14 12:32:18 +0100 2007
dimitri          pts/5  rhel4            Ср фев 14 07:57:19 +0100 2007
bashuserrm       pts/7  rhel4            Чт фев 13 10:35:40 +0100 2007
kornuserrm       pts/5  rhel4            Чт фев 13 10:06:17 +0100 2007
[root@rhel4a ~]#

17.1.4. Файл журнала /var/log/btmp (lastb)

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

[root@RHEL4b ~]# lastb
lastb: невозможно открыть /var/log/btmp: Нет такого файла или каталога
[root@RHEL4b ~]#

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

[root@RHEL4b ~]# touch /var/log/btmp
[root@RHEL4b ~]# ll /var/log/btmp
-rw-r--r-- 1 root root 0 июл 30 06:12 /var/log/btmp
[root@RHEL4b ~]# chmod o-r /var/log/btmp 
[root@RHEL4b ~]# lastb

btmp begins Пн июл 30 06:12:19 2007
[root@RHEL4b ~]#

Информация о попытках ввода некорректных паролей при использовании утилит ssh, rlogin или su не сохраняется в файле /var/log/btmp. В нем сохраняется исключительно информация о попытках ввода некорректного пароля при работе с терминалами.

[root@RHEL4b ~]# lastb
HalvarFl tty3                  Mon Jul 30 07:10 - 07:10  (00:00) 
Maria    tty1                  Mon Jul 30 07:09 - 07:09  (00:00) 
Roberto  tty1                  Mon Jul 30 07:09 - 07:09  (00:00) 

btmp begins Mon Jul 30 07:09:32 2007
[root@RHEL4b ~]#

17.1.5. Журналирование входов в систему с использованием утилит su и ssh

В зависимости от дистрибутива в файловой системе вашего компьютера вы также можете обнаружить файл /var/log/secure, который заполнен сообщениями от вспомогательных модулей auth и/или authpriv демона syslog. Этот файл журнала должен содержать информацию о неудачных попытках входа в систему с использованием утилиты su и/или ssh. В некоторых дистрибутивах данная информация сохраняется в файле /var/log/auth.log, поэтому следует проверить конфигурацию демона syslog.

[root@RHEL4b ~]# cat /var/log/secure
Jul 30 07:09:03 sshd[4387]: Accepted publickey for paul from ::ffff:19\
2.168.1.52 port 33188 ssh2
Jul 30 05:09:03 sshd[4388]: Accepted publickey for paul from ::ffff:19\
2.168.1.52 port 33188 ssh2
Jul 30 07:22:27 sshd[4655]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 05:22:27 sshd[4656]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 07:22:30 sshd[4655]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 05:22:30 sshd[4656]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 07:22:33 sshd[4655]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 05:22:33 sshd[4656]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 08:27:33 sshd[5018]: Invalid user roberto from ::ffff:192.168.1\
.52
Jul 30 06:27:33 sshd[5019]: input_userauth_request: invalid user rober\
to
Jul 30 06:27:33 sshd[5019]: Failed none for invalid user roberto from \
::ffff:192.168.1.52 port 41064 ssh2
Jul 30 06:27:33 sshd[5019]: Failed publickey for invalid user roberto \
from ::ffff:192.168.1.52 port 41064 ssh2
Jul 30 08:27:36 sshd[5018]: Failed password for invalid user roberto f\
rom ::ffff:192.168.1.52 port 41064 ssh2
Jul 30 06:27:36 sshd[5019]: Failed password for invalid user roberto f\
rom ::ffff:192.168.1.52 port 41064 ssh2
[root@RHEL4b ~]#

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

auth.*,authpriv.*                 /var/log/customsec.log

17.2. Демон журналирования событий syslogd

17.2.1. О демоне syslogd

Стандартный метод журналирования событий в Linux связан с использованием демона syslogd. Демон syslogd был разработан Eric Allman для использования совместно с агентом передачи почты sendmail, но вскоре стал одним из множества стандартных приложений Unix, архитектура которого гораздо позднее была описана в рамках стандарта RFC 3164. Демон принимает сообщения от множества приложений (и системных утилит) по протоколу UDP на порту 514 и может дописывать сообщения в файлы журнала, выводить их, показывать сообщения в терминалах и передавать данные журнала другим демонам syslogd, работающим на других машинах. Конфигурация демона syslogd осуществляется с помощью файла /etc/syslog.conf.

17.2.2. О демоне rsyslogd

Новый демон журналирования событий носит имя rsyslogd (reliable and extended syslogd - надежный и расширяемый syslogd) и использует файл конфигурации /etc/rsyslogd.conf. Обратная совместимость синтаксиса данного файла конфигурации сохранена.

В каждой строке файла конфигурации используется идентификатор системы (facility) для определения источника сообщения. Также она содержит описание приоритета (priority) для определения важности сообщения и описание действия (action) для принятия решения о том, что нужно сделать с данным сообщением.

17.2.3. Модули

Новый демон rsyslog предоставляет много дополнительных возможностей, набор которых может быть расширен с помощью модулей. Модули позволяют, например, осуществлять экспорт сообщений из журнала syslog в базу данных.

Обратитесь к страницам руководств для получения дополнительной информации (после того, как вы закончите чтение данной главы).

root@rhel65:/etc# man rsyslog.conf
root@rhel65:/etc# man rsyslogd
root@rhel65:/etc#

17.2.4. Идентификаторы систем (facilities)

На странице руководства, доступной после исполнения команды man rsyslog.conf, можно найти информацию о различных стандартных идентификаторах систем для классификации сообщений от определенных демонов, таких, как mail, lpr, news и kern(el). Идентификаторы систем local0 и local7 могут использоваться для классификации сообщений от системных утилит (или любых подключенных к сети устройств, которые поддерживают механизм сообщений демона syslogd). Ниже приведен список всех идентификаторов систем из файла конфигурации rsyslog.conf версии 1.3. Ключевое слово security является устаревшим.

auth (security)
authpriv
cron
daemon
ftp
kern
lpr mail
mark (только для внутреннего использования)
news
syslog
user
uucp
local0-7

17.2.5. Описания приоритетов (priorities)

Наиболее важное сообщение может иметь описание приоритета emerg, вслед за которыми идут описания приоритетов alert и crit. Сообщения с наиболее низкими приоритетами имеют описания приоритетов info и debug. При указании минимального приоритета для журналирования сообщений будет осуществляться журналирование сообщений и с более высоким приоритетом. Вы можете использовать префикс = перед описанием приоритета для получения только тех сообщений, которые соответствуют этому описанию. Также вы можете использовать описание приоритета .none для предотвращения выполнения определенного действия при приеме любого сообщения с определенным идентификатором системы.

Ниже приведен список приоритетов в порядке возрастания. Ключевые слова warn, error и panic являются устаревшими.

debug
info
notice
warning (warn)
err (error)
crit
alert
emerg (panic)

17.2.6. Действия (actions)

Стандартным действием является отправка сообщения пользователю, имя которого записано в качестве действия. Если в качестве действия приводится строка с префиксом /, демон rsyslogd будет отправлять сообщение в файл (который может быть как обычным файлом, так и файлом устройства принтера или терминала). Префикс @ позволяет осуществлять отправку сообщения другому серверу с исполняющимся на нем демоном syslogd. Ниже приведен список всех возможных действий.

root,user1 передача сообщений пользователям с именами из списка, разделенными с помощью запятой

*передача сообщения всем пользователям, осуществившим вход в систему
/ запись сообщения в файл (который может представлять принтер, консоль, терминал, ...)
-/ запись сообщения в файл без принудительной записи данных каждого сообщения на диск
| запись сообщения в именованный программный канал
@ передача сообщения по сети другому демону syslog, исполняющемуся на узле с заданным именем

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

17.2.7. Конфигурация

Ниже приведен пример фрагмента файла конфигурации /etc/rsyslog.conf для обработки нестандартных сообщений с идентификатором системы local4.

local4.crit                            /var/log/critandabove
local4.=crit                           /var/log/onlycrit
local4.*                               /var/log/alllocal4

17.2.8. Перезапуск демона rsyslogd

Не забудьте перезапустить демон после модификации его файла конфигурации.

root@rhel65:/etc# service rsyslog restart
Shutting down system logger:                           [ OK ]
Starting system logger:                                [ OK ]
root@rhel65:/etc#

17.3. Утилита logger

Утилита logger может использоваться для генерации тестовых сообщений для демона syslogd. Также вы можете использовать ее в сценариях командной оболочки. Ниже приведен пример команд, используемых для тестирования демона syslogd с помощью утилиты logger.

[root@rhel4a ~]# logger -p local4.debug "l4 debug"
[root@rhel4a ~]# logger -p local4.crit "l4 crit"
[root@rhel4a ~]# logger -p local4.emerg "l4 emerg"
[root@rhel4a ~]#

Результаты тестирования демона журналирования событий с помощью утилиты logger.

[root@rhel4a ~]# cat /var/log/critandabove 
Feb 14 19:55:19 rhel4a paul: l4 crit
Feb 14 19:55:28 rhel4a paul: l4 emerg
[root@rhel4a ~]# cat /var/log/onlycrit 
Feb 14 19:55:19 rhel4a paul: l4 crit
[root@rhel4a ~]# cat /var/log/alllocal4 
Feb 14 19:55:11 rhel4a paul: l4 debug
Feb 14 19:55:19 rhel4a paul: l4 crit
Feb 14 19:55:28 rhel4a paul: l4 emerg
[root@rhel4a ~]#

17.4. Просмотр журналов событий

Вы можете использовать команду tail -f для просмотра последних строк файла журнала. Параметр -f позволяет динамически выводить строки, которые добавляются в файл журнала в реальном времени.

paul@ubu1010:~$ tail -f /var/log/udev 
SEQNUM=1741
SOUND_INITIALIZED=1
ID_VENDOR_FROM_DATABASE=nVidia Corporation
ID_MODEL_FROM_DATABASE=MCP79 High Definition Audio
ID_BUS=pci
ID_VENDOR_ID=0x10de
ID_MODEL_ID=0x0ac0
ID_PATH=pci-0000:00:08.0
SOUND_FORM_FACTOR=internal

Также вы можете автоматически повторять вызовы утилит, размещая перед ними вызов утилиты watch. Примером может служить следующая команда:

[root@rhel6 ~]# watch who

Данный подход аналогичен описанному выше, ведь в результате вывод утилиты who обновляется на экране через каждые две секунды.

Every 2.0s: who                Sun Jul 17 15:31:03 2011

root     tty1         2011-07-17 13:28
paul     pts/0        2011-07-17 13:31 (192.168.1.30)
paul     pts/1        2011-07-17 15:19 (192.168.1.30)

17.5. Ротация журналов событий

Размер большинства файлов журналов событий неуклонно растет. Для ограничения размеров этих файлов может использоваться утилита logrotate, предназначенная для ротации, сжатия, удаления и отправки по электронной почте файлов журналов событий. Дополнительная информация об утилите logrotate может быть получена из основного файла конфигурации /etc/logrotate.conf. Отдельные файлы конфигурации могут находиться в директории /etc/logrotate.d/.

Ниже приведено содержимое стандартного файла конфигурации logrotate.conf из состава дистрибутива Red Hat.

root@rhel65:/etc# cat logrotate.conf
# see "man logrotate" for details
# (обратитесь к странице руководства man logrotate за подробностями)
# rotate log files weekly
# (еженедельная ротация файлов журналов)
weekly

# keep 4 weeks worth of backlogs
# (сохранение файлов журналов четырехнедельной давности)
rotate 4

# create new (empty) log files after rotating old ones
# (создание новых (пустых) файлов журналов перед ротацией старых)
create

# use date as a suffix of the rotated file
# (использование даты в качестве суффикса имени файла, подвергающегося ротации)
dateext

# uncomment this if you want your log files compressed
# (раскомментируйте эту строку если вы хотите, чтобы ваши файлы журналов подвергались компрессии)
#compress

# RPM packages drop log rotation information into this directory
# (информация о ротации файлов журналов, извлеченная из пакетов программного обеспечения формата RPM, должна размещаться в данной директории)
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
# (ни один из пакетов программного обеспечения не содержит информации о ротации файлов журналов wtmp и btmp - мы приведем параметры их ротации здесь)
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.
# (параметры ротации специфичных для системы файлов журналов также могут быть приведены здесь.)
root@rhel65:/etc#

17.6. Практическое задание: журналирование событий

1. Выведите содержимое файла журнала /var/run/utmp с помощью специально предназначенной для этой цели утилиты (без использования утилиты cat или текстового редактора vi).

2. Выведите аналогичным образом содержимое файла журнала /var/log/wtmp.

3. Используйте утилиты lastlog и lastb и сделайте вывод о различии этих утилит.

4. Исследуйте файл конфигурации демона журналирования событий syslogd с целью выяснения пути к к файлу журнала событий, который содержит информацию о неудачных попытках удаленного входа в систему с помощью клиента ssh.

5. Настройте демон журналирования событий syslogd таким образом, чтобы сообщения с идентификатором системы и приоритетом local4.error и сообщения с более высокими приоритетами и этим же идентификатором системы размещались в файле журнала /var/log/l4e.log, а сообщения с идентификатором системы и исключительным приоритетом local4.info - в файле журнала /var/log/l4i.log. Проверьте корректность настройки с помощью утилиты logger!

6. Настройте демон журналирования событий syslogd таким образом, чтобы в файле журнала /var/log/Mysu.log размещались все сообщения, сгенерированные утилитой su в ходе получения привилегий пользователя root. Проверьте корректность настройки!

7. Настройте отправку сообщений с идентификатором системы local5 на сервер вашего соседа, на котором исполняется демон syslogd. Проверьте корректность настройки.

8. Разработайте сценарий, который будет вызывать утилиту logger для отправки сообщений с идентификатором системы local4 демону журналирования событий через каждые 15 секунд (текст сообщений должен отличаться). Используйте команду tail -f для отслеживания изменений ваших локальных файлов журналов событий.

17.7. Корректная процедура выполнения практического задания: журналирование событий

1. Выведите содержимое файла журнала /var/run/utmp с помощью специально предназначенной для этой цели утилиты (без использования утилиты cat или текстового редактора vi).

who

2. Выведите аналогичным образом содержимое файла журнала /var/log/wtmp.

last

3. Используйте утилиты lastlog и lastb и сделайте вывод о различии этих утилит.

lastlog: выводит информацию о последних входах пользователей в систему

lastb: выводит информацию о неудачных попытках входа в систему

4. Исследуйте файл конфигурации демона журналирования событий syslogd с целью выяснения пути к к файлу журнала событий, который содержит информацию о неудачных попытках удаленного входа в систему с помощью клиента ssh.

RHEL: root@rhel53 ~# grep authpriv /etc/syslog.conf 
authpriv.* /var/log/secure
Debian/Ubuntu:	/var/log/auth.log

Дистрибутивы Ubuntu 9.10 и Debian Lenny переведены на использование демона журналирования событий rsyslog.

root@ubuntu910:~# grep authpriv /etc/rsyslog.d/50-default.conf 
auth,authpriv.*	/var/log/auth.log
root@deb503:~# grep authpriv /etc/rsyslog.conf 
auth,authpriv.*	/var/log/auth.log

5. Настройте демон журналирования событий syslogd таким образом, чтобы сообщения с идентификатором системы и приоритетом local4.error и сообщения с более высокими приоритетами и этим же идентификатором системы размещались в файле журнала /var/log/l4e.log, а сообщения с идентификатором системы и исключительным приоритетом local4.info - в файле журнала /var/log/l4i.log. Проверьте корректность настройки с помощью утилиты logger!

echo local4.error /var/log/l4e.log >> /etc/syslog.conf
echo local4.=info /var/log/l4i.log >> /etc/syslog.conf
/etc/init.d/syslog restart
logger -p local4.error "l4 error test"
logger -p local4.alert "l4 alert test"
logger -p local4.info "l4 info test"
cat /var/log/l4e.log
cat /var/log/l4i.log

6. Настройте демон журналирования событий syslogd таким образом, чтобы в файле журнала /var/log/Mysu.log размещались все сообщения, сгенерированные утилитой su в ходе получения привилегий пользователя root. Проверьте корректность настройки!

echo authpriv.* /var/log/Mysu.log >> /etc/syslog.conf

Данная директива позволит записывать в файл журнала событий не только данные, касающиеся использования утилиты su.

7. Настройте отправку сообщений с идентификатором системы local5 на сервер вашего соседа, на котором исполняется демон syslogd. Проверьте корректность настройки.

В дистрибутиве RHEL5 следует отредактировать файл /etc/sysconfig/syslog для активации режима приема сообщений от удаленных узлов.

В дистрибутиве RHEL7 следует раскомментировать две следующие строки файла /etc/rsyslog.conf для 'приема сообщений syslog с использованием протокола UDP'.

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

В Debian/Ubuntu следует отредактировать файл /etc/default/syslog или /etc/default/rsyslog.

На клиентском компьютере:

logger -p local5.info "Тестовое сообщение local5 для соседа"

8. Разработайте сценарий, который будет вызывать утилиту logger для отправки сообщений с идентификатором системы local4 демону журналирования событий через каждые 15 секунд (текст сообщений должен отличаться). Используйте команду tail -f для отслеживания изменений ваших локальных файлов журналов событий.

root@rhel53 scripts# cat logloop 
#!/bin/bash
for i in `seq 1 10`
do
logger -p local4.info "local4.info тест номер $i"
sleep 15
done

root@rhel53 scripts# chmod +x logloop
root@rhel53 scripts# ./logloop &
[1] 8264
root@rhel53 scripts# tail -f /var/log/local4.all.log 
Mar 28 13:13:36 rhel53 root: local4.info тест номер 1
Mar 28 13:13:51 rhel53 root: local4.info тест номер 2
...