Проводим аудит системы с помощью SNARE

СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Проводим аудит системы с помощью SNARE

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

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

События, происходящие в последнее время, показывают пока только неэффективность традиционных средств защиты, не срабатывающих при появлении новых алгоритмов нападения. Пока действительно хорошо справляются со своей задачей инструменты, позволяющие определить уже произошедшее проникновение. Поэтому в настоящее время особым вниманием пользуются проактивные системы защиты, реагирующие на системные события, а не сравнивающие сигнатуры, сгенерированые специалистами по безопасности. Такие средства аудита контролируют различные системные выводы и в результате дают полную картину происшедшего на контролируемом узле. А именно: кто, когда обращался, к какому файлу, заходил по сети, модифицировал те или иные данные, т.е. в итоге позволяют получить полную картину происшедшего на контролируемом компьютере. Во всех операционных системах ведутся более или менее подробные логи, но большей частью на основные события (за исключением модуля BSM (Basic Security Module) в Solaris), чего в большинстве случаев достаточно. Но, например, в спецификациях выдвигаются дополнительные требования по регистрации событий для защищенных систем, начиная с класса С. К тому же такие возможности могут понадобиться в системах, предназначенных для обработки конфиденциальной информации. Естественно, отслеживая потенциально опасные события, можно предотвратить взлом и утечку информации, поэтому одним из требований к таким системам является быстрая реакция (под реакцией в данном случае подразумевается оповещение). Для централизованного сбора, хранения и обработки данных о событиях, происходящих на подчиненных системах, приветствуется отправка сообщений на удаленные системы.

Австралийская фирма, занимающаяся безопасностью, InterSectAlliance (http://www.intersectalliance.com/projects/Snare), в разработке SNARE – System iNtrusion Analysis and Reporting Environment основной упор сделала на регистрацию как можно большего количества событий. В том числе контролируются открытые сетевые соединения, чтение и запись в файлы и каталоги, модификация данных пользователя и групп, изменение программ. Система SNARE может быть сконфигурирована в двух вариантах. Первый позволяет обнаружить, когда какой-либо пользователь остановил ключевую программу, переключился к учетной записи администратора или установил файлы в системный каталог. В другом варианте использования SNARE контролирует непосредственно определенные системные вызовы, например, открывающие или переименовывающие файлы, chroot, reboot, mkdir, mknod и другие операции. Система реализована на нескольких платформах с учетом особеностей каждой, при этом она может использоваться как автономный инструмент анализа или быть удаленным сенсором для центрального сервера: Linux (обеспечивает аудит, принятый в системах класса C2 или CAPP), Windows, Solaris, Irix, AIX, IIS Web Server (используется для обработки файлов регистрации в реальном времени) и ISA Server. Распространяется SNARE под GNU Public License. В статье мы рассматриваем Linux-реализацию.

Как работает SNARE

SNARE в варианте для Linux использует три компонента:

• Патч к ядру (в версиях 0.9.3 и выше), ранее для этих целей использовался динамически загружаемый модуль ядра auditmodule.o, который можно было установить без перекомпиляции ядра. Разработчики стремятся сделать систему контроля как можно более легкой и универсальной, способной работать как на маломощной рабочей станции, так и загруженном сервере, этим вызвано такое изменение в подходе.
• auditd – демон, являющийся front end к модулю (находится в пакете snare-core).
• snare – утилита графической конфигурации и просмотра отчетов (пакет snare-gui).

Модуль проверки, работая в пространстве ядра, отлавливает критические системные вызовы вроде «execve» (выполнение команды), «open» (открыть файл), «mkdir» (создать каталог) и отправляет результат к подпрограмме, которая собирает всю информацию относительно процесса и пользователя, его запустившего или просто попытавшегося выполнить рассматриваемый системный вызов. Этот контрольный модуль сохраняет собранную информацию во временном буфере, который и считывается демоном auditd. Демон читает данные от системы контроля через устройство /proc/snare (ранее /proc/audit), преобразовывая двоичные контрольные данные в понятный текстовый формат, и отделяет информацию в ряд лексем, используя для отделения данных и улучшения дальнейшей обработки информации три разделителя: табуляцию, запятые и пробел. Получаем приблизительно следующее:

Кстати, реализация под Windows отличается работой всего двух компонентов: сервиса snarecore.exe и утилиты конфигурирования и получения отчетов snare.exe.

Установка

Для установки SNARE под Linux понадобится два файла: snare-core и snare, а также патч к ядру (в настоящее время ведется работа по включению кода в основное ядро). Для некоторых дистрибутивов (RHEL, Fedora, Debian) на сайте доступны ссылки на прекомпилированые пакеты, в том числе и подготовленные ядра, которые и рекомендуется использовать. В целях эксперимента установим SNARE, используя исходные тексты.

Скачиваем версию ядра, под которую имеются патчи и сам патч.

# cd /usr/src; wget -c http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.gz

# tar xzfv linux-2.6.11.tar.gz

# wget -c http://www.intersectalliance.com/projects/Snare/Download/snare-0.9.7-2.6.11.7.diff

Накладываем патч, конфигурируем ядро.

# cd linux-2.6.11

# patch -p0 < snare-0.9.7-2.6.11.7.diff

# make menuconfig

И в «General Setup» включаем пункт «SNARE C2 Auditing».

Далее компилируем как обычно и устанавливаем загрузчик. Затем скачиваем с сайта проекта SNARE архивы snare-core-0.9.7.tar.gz и snare-gui-0.9.6.tar.gz.

# tar -xzvf snare-core-0.9.7.tar.gz

# cd snare-core-0.9.7

# make clean

# make

# make install

# /etc/init.d/snare start

Теперь необязательный графический интерфейс.

# snare-gui-0.9.6.tar.gz

# cd snare-gui-0.9.6

# ./autogen.sh

# make

# make install

# cp snare-icon.png /usr/share/pixmaps

# cp snare.desktop /usr/share/gnome/apps/System

# cp snare.desktop /usr/share/gnome/ximian/Programs/Utilities/

# cp Snare.kdelnk /usr/share/applnk/System/

И запускаем, набрав snare в окне терминала или через меню KDE (в Gnome «Система  Snare  Event Logging»).

Инсталляция под Windows заключается в получении одного файла SnareSetup.exe и запуске его обычным способом.

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

Все настройки демона хранятся в файле /etc/audit/audit.conf с вполне понятной структурой. Лучший способ изменения настроек – использование графической утилиты SNARE (рис. 1)

Рисунок 1. Графическая утилита позволяет просмотреть события в реальном времени и настроить систему.

После запуска которой заходим в пункт «Setup  Audit Configuration» и устанавливаем необходимые параметры во вкладках:

• Auditing Control – метод контроля (Objectives или Kernel), место, куда отправлять логи (локальный файл, на удаленный хост или оба варианта) и параметры настройки сети, необходимые для посылки логов (имя локального узла, IP-адрес или DNS-имя удаленного, UDP-порт на удаленном компьютере, куда будут посылаться сообщения).
• Kernel events – тип ревизии, может быть или события ядра, или настроенные пользователем фильтры. В данном пункте выбираются все те системные вызовы, которые необходимо отслеживать, при этом в журнал будут записаны все такие вызовы без какой-либо дополнительной фильтрации, при установке большего количества контролируемых вызовов журнал начнет быстро заполняться, причем, как правило, будет много лишней информации. Этот метод ревизии больше подходит для классического «C2»-стиля аудита, в котором все запросы должны быть зарегистрированы.
• Objectives (рис. 2) – более усовершенствованный метод аудита через определение объектов контроля и слежения за всеми изменениями состояния или обращения к ним.

Рисунок 2. Просмотр объектов контроля и слежения

criticality=4   event=open(.*),mkdir,mknod,link,symlink return=Success  user!=root      match=^/etc/shadow$

criticality=2   event=open(.*),mkdir,mknod,link,symlink return=Failure  user!=root      match=^/etc/shadow$

Если оставить одну строку, то это снизит эффективность системы, и действительно опасное предупреждение может просто затеряться среди подобных сообщений.

Для более тонкой настройки можно добавить индивидуальный контроль файлов, в которых прячутся rootkits (их список большой, вот некоторые: login, telnet, ftp, netstat, ifconfig, ls, ps, ssh, find, du, df, sync, reboot, halt и shutdown) и основные настроечные системные и сетевые файлы /etc/resolv.conf, /etc/hosts, /etc/lilo.conf, /boot/grub/grub.conf, и пр. Список основных системных вызовов и их значения приведен в разделе «Appendix A – Events Audited».

Единственное, о чем следует помнить, – это то, что при увеличении контролируемых параметров увеличивается и потребление системных ресурсов, на маломощных системах этот показатель может быть критичным.

В Windows нет разделения на Objectives или Kernel, доступна только Audit Reporting Objectives, и в силу специфики системы отслеживаются другие события (logon, logoff, обращение к файлу или каталогу, остановка и запуск процесса, использование прав пользователя и администратора, изменение политики безопасности, перезагрузка, останов системы и некоторые другие).

После внесения всех необходимых настроек необходимо перезапустить сервис «Activity  Apply and Restart Audit», после чего в главном окне программы будут выводиться все события, попадающие под установленные правила. Щелкнув дважды мышкой по представляющему интерес событию, можно получить дополнительную информацию. Используя «Prev» и «Next», можно двигаться вперед-назад, просматривая события. Все, на мой взгляд, просто и понятно. Просмотреть статус работы SNARE можно, выбрав пункт «Bид  Audit Status», при этом можно увидеть общее количество событий, обработанных модулем ядра без фильтрации, а также ID процесса демона, версию SNARE и активность демона.

Удаленное управление

К сожалению, версия под Linux лишена на данный момент возможности удаленного управления при помощи веб-интерфейса. А вот запустив SNARE под Windows и набрав в строке браузера IP-адрес или имя компьютера, получаем не только возможность сконфигурировать его удаленно, но и информацию о пользователях и группах локальных и домена. Для подстраховки лучше зайти предварительно в пункт «Setup  Remote Control Configuration» и выставить IP-адрес, с которого можно удаленно заходить на компьютер и пароль для получения доступа, здесь же можно выбрать и порт, на котором работает сервер.

Но в Linux можно просто зайти на удаленную систему при помощи SSH и запустить на ней клиента. Если на подконтрольной системе не используется X-Window, то перед запуском экспортируем переменную DISPLAY.

myguisystem# ssh auditedsystem

..

auditedsystem# /bin/su -

[password]

auditedsystem# export DISPLAY=myguisystem:80

auditedsystem# snare &

И еще одна полезная возможность заложена в SNARE – это отправка логов на удаленный узел по протоколу UDP, которая может помешать хакерам скрыть свое пребывание чисткой логов, хотя при контроле большого количества машин и параметров это может существенно забить сеть пакетами. Для этого в «Auditing Control» выбираем пункт «Log events to the networked host and a local file» и далее устанавливаем имя узла и порт (по умолчанию 6161), которому будут отправляться сообщения. На сервере, предназначенном для сбора всех логов, запускаем Perl-скрипт auditserver.pl (лежит в пакете snare-core), в котором нужно изменить переменную $ServerPort, установив нужное значение, совпадающее с таковым у клиентов, и каталог, куда будут складываться сообщения. Cервер в каталоге /var/log/audit создает отдельные файлы для каждого клиента вида YYYYMMDD-host.name.LinuxAudit. То есть в итоге получаем несколько файлов вида /var/log/audit/20050821-host.com.LinuxAudit. В дальнейшем эти файлы можно заархивировать для истории или распаковать при помощи скрипта extract.pl, который можно найти в документе «Guide to SNARE for Linux», потом просто запуская его вручную или при помощи cron.

#cat  /var/log/audit/20050821-host.com.LinuxAudit | ./extract.pl

На данный момент не поддерживается какая-либо защита при передаче файлов журналов, что дает возможность злоумышленику подделать логи либо провести элементарную DOS-атаку, поэтому пользоваться возможностью отправки логов в таком варианте необходимо осторожно и в защищенных сетях. Хотя стоит отметить, что отправка журналов на централизованый сервер разработчиками ориентируется больше при взаимодействии с SNARE Server (http://www.intersectalliance.com/snareserver/index.html). Основное назначение которого сбор и анализ информации, поставляемой с различных систем. С его демо-версией можно ознакомиться на сайте проекта. Для централизованого сбора и отправки журналов с других систем с ним в паре будет работать SNARE Reflector, разработка которого ведется в настоящее время.

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

Как видите, в отличие от средств контроля целостности системы, которые запускаются время от времени, SNARE позволяет контролировать происходящее практически в реальном времени, что существенно повышает общую безопасность. Также являются интересными сочетания вроде «IDS+SNARE» или «honeypots+SNARE». Первый вариант позволяет получить более подробную информацию об инциденте и может помочь при обработке последствий. Во втором случае предоставляется хорошая возможность изучить инструменты и действия взломщиков. Также подобные средства могут понадобиться тем, кому по роду деятельности нужна операционная система класса С2.

Удачи.