Анализ журналов регистрации

Очень часто злоумышленники оставляют следы своих действий в различных журналах регистрации, постоянный просмотр которых является еще одним, а зачастую единственным способом обнаружения атак. Файлы регистрации могут содержать доказательства различных несанкционированных или непредвиденных действий, происходящих в системе или сети. Записи журналов могут говорить о том, что кто-то скомпрометировал или пытался скомпрометировать систему. Регулярно анализируя журналы регистрации, можно идентифицировать многие из предпринимаемых или уже совершенных атак и реализовать те или иные процедуры реагирования. Необходимо различать журналы регистрации событий и журналы регистрации транзакций. Вторые позволяют не только фиксировать тип события доступа к контролируемому объекту, но и отражать то, что конкретно сделал тот или иной пользователь с данным объектом. Благодаря этому в ОС Windows NT не всегда можно уверенностью сказать, что именно сделал пользователь. Например, вы можете с уверенностью заявить, что бухгалтер Сидоров открыл файл Salary.ххх для чтения, записи или удаления (код события 560). Вместе с тем, используя только журнал регистрации Windows NT, в принципе нельзя сформировать мнение, внес ли какие-нибудь изменения бухгалтер Сидоров, а если сделал, то какие.

Управление журналами регистрации состоит из трех этапов, на которых требуется определить:

1. Что вы хотите знать о вашей системе?

2. Какие журналы регистрации содержат нужную информацию?

3. Какие признаки атаки вы будете использовать?

Например, вы хотите знать, кто пытается задействовать уязвимость ехрn в реализации почтовой программы sendmail. Это первый этап. Вы определили, что вы хотите обнаружить. На втором этапе вы должны обратиться к файлу /etc/syslog.conf, в котором указаны пути к журналам регистрации [Spitzner 1-00]. В случае с sendmail это — /etc/log/maillog для Linux. Признаком несанк­ционированного использования команды expand в программе sendmail явля­ется строка, показанная в листинге 5.1.

Способы анализа журналов регистрации зависят от типа и объема обрабаты­ваемых данных. В случае небольших объемов не запрещается анализировать такие файлы вручную (как это делалось раньше) из обычного текстового редактора или встроенного менеджера работы с журналами (например, Event Viewer). Можно использовать редакторы электронных таблиц (Excel) или системы управления базами данных (Access, Oracle и т, д.), позволяющие осуществлять различные операции над обрабатываемыми данными (фильтрацию, выборку, сортировку, построение зависимостей и т.д.). Однако та­кой анализ сравнительно утомителен и долог, т.к. необходимо просмотреть сотни и тысячи записей в поисках всего одной, свидетельствующей о не­санкционированной деятельности. Например, после двойного нажатия кнопкой мыши при наведении указателя на ярлык текстового файла из программы Windows NT Explorer происходит запуск программы Wordpad (или Notepad или WinWord). При этом фиксируется более двадцати событий, связанных с доступом к открываемому файлу [Смит 1-00]. А таких со­бытий в системе в течение рабочего дня может быть несколько сотен, что приводит к "распуханию" журнала регистрации.

Помимо обычных систем управления базами данных можно использовать специализированные системы анализа журналов регистрации (log checker), которые изначально предназначены для анализа журналов регистрации в режиме, близком к реальному. К таким системам могут быть отнесены RealSecure OS Sensor, SWATCH или Axent Enterprise Security Manager. Следую­щим поколением систем являются системы анализа журналов регистрации е поддержкой механизмов семантического сжатия, которые позволяют не­сколько связанных событий объединить в одно и именно его выводить наконсоль. Например, пять событий "Неудачная попытка входа в систему" (Logon Failure) можно свести к одному — "Подбор пароля". По такому принципу работает система RealSecure Server Sensor, в которой реализован механизмы SecureLogic и Local Fusion.

Приведу случай, который произошел со мной в ноябре 2000 года. В среду утром, в процессе генерации отчетов в системе обнаружения атак RealSecure, я обнаружил 6 событий Brute_Force_Login_Attack, зафиксированных с утра понедельника до вечера вторника. То есть система RealSecure "вычислила" 6 атак типа "подбор пароля", направленную на мой компьютер. Дополнительный анализ показал, что каждое из этих событий появилось в результате семантического сжатия 8 попыток неудачного подключения к моему компьютеру, выполненного в течение короткого времени. Система RealSecure определила данные события как Failed_login-bad_username_or_password. Если бы у меня не было системы обнаружения атак, то мне пришлось бы просмотреть несколько сотен событий, зафиксированных в журнале регистрации Windows NT. Фильтрация событий (результат, которой показан в листинге 5.2) не всегда удобна. Особенно, когда необходимо одновременно контролировать несколько узлов, находящихся в разных сегментах сети.

Опасность в том, что по мере наполнения данного журнала старые записи замещаются новыми. Нерегулярный анализ журнала регистрации приведет к тому, что некоторые события останутся за пределами вашего рассмотрения. Однако даже механизмы семантического сжатия не всегда предоставляют тот уровень анализа, который необходим для эффективного расследования инцидента безопасности. При проведении анализа невозможно обойтись только системой анализа журналов регистрации или системой обнаружения атак. Даже, несмотря на то, что эта система автоматизирует процесс анали­за, без человеческой помощи расследование несанкционированной деятель­ности злоумышленников вряд ли будет успешным, как показано в примере выше, система обнаружения атак не смогла подсказать мне, что вероятнее всего подбор пароля осуществлялся при помощи автоматизированного средства. А ручной анализ это выделил с первого взгляда, т.к. простейший под­счет показывает, что каждая новая попытка подключения к моему компью­теру осуществлялась через каждые 9 секунд. Вручную ввести 8 паролей с разницей в 9 секунд невозможно, что говорит о применении именно авто­матизированного средства.

Кроме того, необходимо использовать для анализа различные журналы регистрации, что пока не свойственно большинству систем обнаружения атак. Допустим, в журнале банковской системы зафиксировано, что операционистка Петрова провела несколько платежных поручений в среду, с 12.00 до 13.00. Эта информация свидетельствует о нормальной деятельности, присущей данной операционистке. Однако в журнале регистрации операционной системы (или системы защиты) отмечено, что операциониста Петрова не работала в указанный период — она была на обеденном перерыве. Без дополнительного ручного анализа различных журналов обнаружить такого рода несоответствие было бы затруднительно. Другой пример: в журнал были внесены отметки, что администратор Иванов произвел некоторые операции на компьютере А в 14.00.12, а на компьютере Б в 14.07.35. Казалось бы, ничего страшного в этом нет. Однако компьютеры А и Б находятся в совершенно разных зданиях одной площадки. Чтобы преодолеть расстояние между двумя зданиями, требуется не менее 10 минут. В результате обнаруживается подлог — несколько сотрудников управления информатизации работали под одной и той же учетной записью, что является нарушений политики безопасности организации. И, наконец, третий пример, о котором уже упоминалось выше. Анализируя только Security EventLog ОС Windows NT нельзя сказать, изменил ли бухгалтер Сидоров файл с зарплатой Salary.ххх. Однако, привлекая к анализу журнал регистрации системы контроля целостности, можно с уверенностью определить факт записи в данный файл. Мало того, сравнивая размер файла до изменения и после, можно выяснить добавлялись или удалялись какие-либо записи.

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

q пограничных маршрутизаторов;

q серверов, размещаемых в демилитаризованной зоне;

q межсетевых экранов;

q сетевых систем обнаружения атак;

q других средств периметровой защиты;

q серверов приложений;

q файловых серверов;

q рабочих станций.

Например, уязвимости Web-сервера могут быть обнаружены путем анализа записей его журнала регистрации (листинг 5.3).

А атаки типа "подбор пароля" могут быть опознаны по большому числу обращений к файлу паролей (листинг 5.4).

Периодическая проверка журналов регистрации

К сожалению, сами по себе записи журнала регистрации не могут сказать, что те или иные действия не санкционированы. В журналах только регистрируется необходимая для анализа информация. Все остальное зависит только от политики безопасности, принятой в организации. Как уже было отмечено выше, только знание того, что мы ищем и на основании каких факторов мы делаем вывод о несанкционированности, дает право судить наличии атаки. Сделать этот вывод можно только после соответствующего ручного или автоматизированного анализа записей журналов регистрации. Умение проводить ручной анализ может быть приобретено только после ее ответствующего обучения и применения полученных знаний на практике. На первом этапе приходится использовать автоматизированный анализ, ко­торый, однако, как показывает практика, не может заметить все нарушения политики безопасности, особенно серьезные. Как следует из [Allen l-99], практически все известные серьезные вторжения в информационные систе­мы были обнаружены благодаря автоматизированному анализу, дополненному ручной обработкой. Постепенно вы сможете более эффективно анализировать журналы регистрации, сразу отмечая все необычные записи и без помощи целевых специализированных систем. В табл. 5.2показаны типовые непредвиденные действия для различных журналов регистрации. Дополнительная инфор­мация о признаках несанкционированной деятельности может быть полу­чена из главы 4.

Таблица 5.2.Необычные действия для различных журналов регистрации