2.12. Аудит событий и его безопасность

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

Интерес для администратора могут представлять файлы протоколов, а также файлы, которые создаются прикладными программами в процессе своего функционирования, но не являются объектом работы пользователя или протоколом работы прикладной программы. Файлы аудита могут иметь расширение .log , а системные файлы аудита обычно расширения не имеют.

Основные файлы системных протоколов (журналы) ОС Linux находятся в каталоге /var/log. Информация о функционировании системы и работе пользователей записывается системными программами в определённые файлы этого каталога. Большей частью журналы представляют собой текстовые файлы, в которые информация записывается построчно и последовательно. Некоторые файлы аудита являются двоичными и имеют специальную структуру, что требует для их просмотра использования специальных утилит, интерпретирующих содержимое этих файлов в удобный для просмотра вид.

Каталог /var/log обычно содержит следующие основные файлы аудита:

• cron – текстовый файл, содержащий информацию о фактах выполнения пользователями периодических заданий;

• debug – текстовый файл, содержащий отладочную информацию ядра системы и некоторых системных или прикладных программ;

• faillog – двоичный файл, содержащий информацию о неудачных попытках входа в систему (утилита для работы с этим файлом также называется faillog);

• lastlog – двоичный файл, содержащий информацию о последних входах в систему (утилита для работы с этим файлом – last);

• maillog – текстовый файл, содержащий информацию о работе почтовой системы sendmail+procmail;

• messages – текстовый файл, содержащий протоколируемую информацию о системе и процессах категории выше info и ниже warn (об уровнях значимости см. ниже);

• syslog – текстовый файл, содержащий протоколируемую информацию о системе и процессах категории warn;

• secure – текстовый файл, содержащий информацию о попытках получения и использования пользователями полномочий суперпользователя, о смене пароля, о регистрации и удалении пользователей и др.;

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

Наблюдение за событиями и их протоколирование производится с помощью системы регистрации syslog. Она состоит из трех компонентов:

• демона syslogd, который собственно отвечает за регистрацию событий,

• пользовательской программы logger,

• библиотечных функций openlog(), syslog() и closelog(), которые обслуживают службу регистрации сообщений.

Детали, связанные с использованием программы logger и вышеназванных библиотечных функций, с достаточной полнотой изложены в [1, 10].

Демон syslogd запускается автоматически процессом init из загрузочных сценариев и работает непрерывно до останова системы. Программ, обеспечивающих информацией службу регистрации, довольно много. К ним относятся такие известные программы, как su, sudo, getty, passwd, inetd, crond, login, halt и др. Источником сообщений ядра, кроме того, является файл специального устройства /dev/klog или /dev/log. Для отправки сообщения в файл протокола программа использует библиотечную функцию syslog()языка Си, а в сценариях, написанных на языке интерпретатора команд, используется утилита logger. Демон syslogd читает эти сообщения, фильтрует их и помещает в журнальные файлы. Фильтрующие параметры содержатся в текстовом конфигурационном файле /etc/syslog.conf.

Файл /etc/syslog.conf отличается простым форматом и состоит из строк, включающих два поля, разделенные одним или несколькими пробелами или знаками табуляции:

селектор действие

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

селектор=средство.уровень

Селекторы могут содержать символ * (все) и ключевое слово none (ничего). Существует более 20 допустимых имен средств, из которых наиболее часто встречаются:

kern ядро;

user пользовательские процессы;

mail почтовые программы;

cron планировщик задач;

mark периодические временные метки;

auth процессы, обеспечивающие авторизацию и безопасность;

daemon демоны;

syslog внутренние сообщения демона syslogd .

Предусмотрено 8 уровней значимости сообщений (в порядке убывания значимости):

emerg экстренные ситуации;

alert срочные ситуации;

crit критические состояния;

err ошибочные состояния;

warning предупреждающие сообщения;

notice необычные сообщения;

info обычная информация;

debug отладочная информация.

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

В файле syslogd.conf уровень сообщения определяет его минимальную важность для того, чтобы быть зарегистрированным. Так, селектор cron.warning означает, что будут регистрироваться сообщения демона crond с уровнями warning, err, crit, alert и emerg.

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

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

Для администратора важно не только собрать информацию о событиях безопасности, но и вовремя увидеть необходимое. Особым разнообразием записей отличается журнал /var/log/messages. Для облегчения визуального анализа журнала следует использовать возможность цветового форматирования строк [13].

Выборка из содержимого файла /var/log/secure, в который демон syslogd записывал сообщения, генерируемые программами login, su, passwd, useradd и userdel, приведена на рис. 2.10. Формат и содержание записей в дополнительных пояснениях не нуждаются.

Jan 14 11:26:20 server login[2987]: ROOT LOGIN on `tty1'

Jan 14 12:02:23 server useradd[7244]: new user: name=user, uid=1000, gid=100, home=/home/user, shell=/bin/bash

Jan 14 12:02:24 server chfn[7245]: changed user `user' information

Jan 14 12:02:29 server passwd[7246]: password for `user' changed by `root'

Jan 14 17:15:16 server userdel[1193]: delete user `user'

Feb 17 18:53:15 samsung login[3877]: invalid password for `root' on `tty6'

Feb 17 18:53:22 samsung login[3877]: ROOT LOGIN on `tty6'

Feb 26 20:19:17 samsung useradd[6886]: new user: name=petrov, uid=1000, gid=100, home=/home/petrov, shell=

Feb 26 20:19:32 samsung useradd[6896]: new user: name=ivanov, uid=1001, gid=100, home=/home/ivanov, shell=

Feb 26 20:20:11 samsung passwd[6918]: password for `ivanov' changed by `root'

Feb 26 20:20:36 samsung passwd[6937]: password for `petrov' changed by `root'

Feb 26 20:20:50 samsung su[6959]: + pts/2 root-petrov

Feb 26 20:21:46 samsung su[7000]: + pts/2 petrov-ivanov

Mar 22 05:48:47 samsung login[4158]: ROOT LOGIN on `tty1'

Mar 22 06:51:40 samsung su[7323]: + pts/1 root-ivanov

Mar 22 07:17:24 samsung su[8498]: + pts/1 root-ivanov

Mar 22 07:37:08 samsung passwd[8946]: password for `ivanov' changed by `ivanov'

Mar 22 07:54:14 samsung passwd[10205]: password for `ivanov' changed by `root'

Mar 22 08:13:06 samsung su[11070]: + pts/1 ivanov-petrov

Рис. 2.10. Выборка из содержимого файла /var/log/secure

Система обеспечения безопасности в первую очередь зависит от неуязвимости самой службы безопасности. В известной прибаутке говорится: «Не спит собака, дачу охраняет, и я не сплю – собаку стерегу». Эти соображения полностью относятся к системе аудита.

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

Кстати, любопытно, как система осуществляет аудит событий при запуске переименованных утилит типа passwd или su. Если пользователь создаст из своего каталога или каталога /tmp символическую ссылку на утилиту su, а затем запустит ее в целях подбора пароля администратора, то в списке процессов команда отобразится по имени созданной ссылки и как запущенная от имени root. Но система аудита нормально зафиксирует и запишет в журнальный файл запуск пользователем утилиты su под ее настоящим именем.

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

1. Удаление определенных журнальных файлов, в которых протоколируются факты проникновения в систему, повышение прав доступа, создание новых учетных записей и др. Удаление файлов для пользователя, имеющего права на поиск и запись в каталог /var/log , никаких проблем не представляет. Ликвидация бинарных файлов wtmp, wtmp, lastlog, faillog приводит к тому, что регистрация соответствующих событий будет прекращена, а удаленные файлы вновь не появятся. Подобное грубое вмешательство заведомо привлечет внимание администратора и иных пользователей хотя бы по той причине, что станет невозможно пользоваться некоторыми командами, такими как who, w, last.

2. Завершение работы демона syslogd. После этого дальнейшее пополнение регистрационных записей прекратится. Демаскирующий признак – отсутствие syslogd в списке процессов. Нарушителю имеет смысл завершать этот процесс до выполнения деструктивных действий, хотя само проникновение в систему и приобретение администраторских прав будет зафиксировано.

3. Нейтрализация работы демона syslogd с оставлением его в списке процессов может происходить путем его перезапуска с направлением вывода в нулевое устройство /dev/null.

4. Установка и запуск «исправленного» демона syslogd, который не будет протоколировать демаскирующие события.

Программы, используемые злоумышленниками для очистки журналов аудита, получили название log cleaner или log wiper. Они служат для избирательного удаления информации, свидетельствующей о незаконных действиях в системе. Стирание или замена строки, демаскирующей нарушителя, в текстовом log-файле программных затруднений не вызывает (если нарушитель имеет права администратора). Но такие файлы аудита, как utmp, wtmp и lastlog, имеют двоичный вид, и произвести в них удаление или замену записей непросто.