 |
|
|
|
Мониторинг сетевых событий при помощи sguil
Мониторинг сетевых событий при помощи sguil … is built by network security analysts for network security analysts. Интересно сегодня наблюдать за процессом развития средств сетевой безопасности. Сначала считалось, что для ее обеспечения на достаточном уровне необходимо использовать межсетевой экран, который при правильной настройке позволяет отсеивать проблемный трафик. Затем стало ясно, что межсетевой экран способен обеспечить только минимальный уровень защиты и в 1980 г. с публикации Джона Андерсона (John Anderson) «Computer Security Threat Monitoring and Surveillance» началось развитие систем обнаружения атак, хотя к их активному использованию пришли чуть позже – где-то в первой половине 90-х. Долгое время считалось, что системы обнаружения атак также являются идеальным помощником администратора, но вскоре стали заметны их недостатки. В первую очередь, это очень большое количество ложных предупреждений, так как таким системам недостает контекста, и поэтому они не могут отслеживать связи между событиями. Учитывая, что опытные хакеры очень непредсказуемы в своих действиях, выявить настоящее и хорошо подготовленное вторжение при помощи СОА довольно проблематично, а собранная такой системой информация бывает малополезной при последующем анализе инцидента. Впрочем, надо отметить, это не помешало появлению такого класса программ, как системы остановки атак. Здесь поступили просто, решив, что если атаку можно обнаружить, то почему бы вместо простого оповещения не прекратить ее. Фактически эти системы унаследовали недостатки СОА, но только теперь администратор, вместо того чтобы разбираться в большом количестве предупреждений, возможно, будет выслушивать жалобы от пользователей, которые по неизвестным причинам не могут попасть в сеть. Вот и получается, что стопроцентно принять решение о степени опасности того или иного события может только администратор, самостоятельно проанализировавший ситуацию. А для решения этих задач СОА не совсем подходят, так как они собирают максимальную информацию только о подозрительных пакетах, остальные же данные, как правило, игнорируются и будут потеряны для исследователя. А простая логика подсказывает, что известные уязвимости, имеющиеся в операционных системах, сервисах и протоколах не имеют ничего общего с возможными угрозами. На страницах журнала [5] уже рассказывалось о работе системы обнаружения атак SHADOW – Secondary Heuristic Analysis for Defensive Online Warfare (http://www.nswc.navy.mil/ ISSEC/CID), основное отличие которой от традиционных СОА, вроде Snort, состоит в отказе от наблюдения за конкретными уязвимостями и использовании статистического анализа потоков информации. Другой проект – sguil пробует решить задачу обнаружения атак по-своему. Проект sguil Методология, на которой построен sguil, называется Network Security Monitoring – NSM. Ее главный акцент сосредоточен на сборе как можно большего количества данных, упрощении доступа к ним и дальнейшего всестороннего анализа. В общем же назначение sguil состоит в интеграции различных инструментов, предназначенных для защиты сети. Для этого она связывает предупреждения СОА с базой данных TCP/IP-сеансов, полным содержимым пакетов и другой полезной информацией. После обнаружения атаки sguil обеспечивает исследователя полными данными, необходимыми для изучения проблемы, позволяя оценить ситуацию и принять правильное решение. При обнаружении события ему может быть присвоена одна из семи категорий (таблица 1). В противном случае оно помечается как не требующее дальнейшего внимания, и такие события больше не выводятся на консоль, но все равно сохраняются в базе данных. Вся записанная информация может быть легко добыта и проанализирована при помощи предварительно подготовленных SQL-запросов. Естественно, при необходимости такие запросы можно составлять и самому, сохраняя их затем для повторного использования. События, имеющие один и тот же IP-адрес, сигнатуру и сообщение, могут быть сопоставлены между собой. Для удобства реализован и импорт отчетов, составленных сканером безопасности Nessus. Система анализа информации, построенная на sguil, состоит из одного сервера и произвольного числа сетевых датчиков. Датчики собирают информацию и передают ее на сервер, который, в свою очередь, координирует полученные данные, сохраняет их в базе и отдает по требованию клиентам. В качестве датчиков на момент написания статьи использовались:
Дополнительно могут загружаться и расшифровываться данные от сниффера Ethereal, если он установлен в системе. Для доступа к информации, собранной сервером используются GUI-клиенты, написанные на Tcl/Tk, роль которых не менее важна, чем сервера и датчиков, т.к. именно с их помощью производится основной отбор данных в реальном времени и последующий их анализ. При необходимости могут создаваться отчеты в виде текстового файла или сообщений электронной почты. Таблица 1. Категории событий, контролируемые sguil
Естественно, первое, что приходит в голову после знакомства с sguil, это «еще один интерфейс к IDS Snort». Это не совсем так. Главное отличие sguil от других проектов, задачей которых является выдача информации собранной Snort, состоит в выводе данных в реальном времени и возможности проводить необходимые исследования, позволяющие изучить конкретное событие.
Установка sguil На момент написания статьи актуальной была версия 0.5.3. Такой номер версии, как обычно в мире Open Source, не означает недоработанность утилиты. Сама установка и настройка при внимательном подходе происходит, как правило, без особых проблем. В качестве операционной системы может быть использована любая из UNIX-систем, но использование мультиплатформенных компонентов позволяет установить sguil на Mac OS X или Windows. На сайте проекта http://sguil.sourceforge.net продукт доступен как через cvs, так и в виде архива с исходными текстами. Его также можно получить на сайте проекта Snort, при этом для удобства установки все части системы, т.е. sensor, server и client на некоторых сайтах могут находиться в разных архивах. Если хорошо поискать, то можно найти и прекомпилированые пакеты. Например, на сайте BOSECO Internet Security Solutions (http://www.boseco.com), кроме rpm-пакетов доступен и базирующийся на Fedora Core дистрибутив IDSLite, имеющий уже подготовленный к работе sguil. В ftp-архиве http://www.spenneberg.org/IDS, кроме rpm-пакетов со sguil, имеются и приложения, необходимые для удовлетворения зависимостей. Наиболее общей является установка исходных текстов, поэтому в статье будет показан этот вариант. Итак, для настройки различных компонентов нам понадобятся:
Плюс опционально всеми компонентами поддерживается OpenSSL, хотя как вариант можно использовать и stunnel. Перед установкой ознакомьтесь с составом пакетов, входящих в ваш дистрибутив, скорее всего, большая часть из необходимого уже имеется. Все компоненты системы можно установить как на одном компьютере, так и развернуть систему наблюдения за сетью на нескольких машинах.
Создание базы данных для хранения информации На всех компонентах sguil в целях безопасности рекомендуется использовать отдельного непривилегированного пользователя, поэтому вначале создаем его. # groupadd sguil # useradd -g sguil -s /bin/false -c "Sguil NSM" sguil В качестве сервера базы данных на данный момент используется только MySQL, установке которого посвящено много статей, плюс в документации sguil этот процесс описан подробно, поэтому сейчас он рассматриваться не будет. При установке сервера при помощи rpm-пакетов некоторые шаги будут выполнены автоматически, вам останется только проконтролировать результат. Запускаем MySQL, устанавливаем пароль для root, который во многих дистрибутивах оставлен пустым, и даем необходимые привилегии пользователю sguil, от имени которого и будем в дальнейшем работать с базой данных. # /etc/init.d/mysqld start
Далее нужную для работы базу данных можно создать вручную, в документации подробно описан этот процесс. Но сервер sguild при первом своем запуске при отсутствии необходимой базы данных сам попробует ее создать. После всего команда: # mysql -u root -p -e "show tables" должна дать следующий вывод.
Установка сервера sguild Для удобства лучше поместить все конфигурационные файлы сервера в отдельный каталог, например /etc/sguild. Поэтому создаем его и переносим туда файлы sguild.users, sguild.conf, sguild.queries, sguild.access, autocat.conf, которые находятся в архиве приложения в подкаталоге server. Далее проверяем наличие необходимых компонентов. # tclsh
Устанавливаем Tclx, в результате вывод будет такой.
tclsh>exit Затем необходимо зарегистрировать пользователя, от имени которого мы будем работать с сервером. # ./sguild -adduser sguil
Не получилось, система сообщает, что не установлен mysqltcl. Исправляемся. # ./sguild -adduser sguil
Опять. На этот раз нет sha1, являющегося частью библиотеки tcllib. # ./sguild -adduser sguil
Теперь все нормально, а в файле /etc/sguild/sguild.users должна появиться следующая запись. # cat /etc/sguild/sguild.users
По умолчанию файл /etc/sguild/sguild.access позволяет подсоединяться к серверу любому клиенту и датчику. Для безопасности желательно указать конкретные адреса. Например: sensor 192.168.0.20 client 127.0.0.1 Копируем исполняемый файл сервера sguild и библиотеки, после чего запускаем. # ср /home/source/sguil-0.5.3/server/sguild /usr/bin # ср -R /home/source/sguil-0.5.3/server/lib /etc/sguil # sguild
Все. Сервер работает и ждет подключения сенсоров, а в процессе первого запуска была создана база данных. В rpm-пакетах и в подкаталоге pkgbuild/rpm имеется скрипт sguild.init, который обеспечит запуск sguild при старте системы. Во время работы sguild использует конфигурационный файл sguild.conf, простой и к тому же хорошо комментированный. В нем придется подправить значения некоторых параметров, в первую очередь значение переменной SGUILD_LIB_PATH /etc/sguil/lib, так как по умолчанию она указывает на текущий каталог. Также проверьте путь к утилитам (p0f, tcpflow), параметры работы с базой данных, номера портов, на которых sguil будет ожидать подключения сенсоров и клиентов, каталог для хранения журналов, местонахождение правил snort и пр. Настройка GUI-клиента sguil.tk Это самая простая часть настройки. Клиент sguil.tk, представляет собой готовый скрипт на tcl/tk и при наличии всех необходимых компонентов он будет работать без проблем. В Windows его можно запустить при помощи библиотеки ActiveState (http://www.activestate.com/Products/ActiveTcl), в документе «Getting SGUIL to work with Windows» подробно описан этот процесс. Во время своей работы скрипт считывает файл sguil.conf, который по умолчанию должен лежать либо в домашнем каталоге пользователя, либо в каталоге, в котором находится скрипт. Иначе требуется указать его местонахождение явно. # ./sguil.tk -- -c /etc/sguil/sguil.conf Параметры, которые можно задать при помощи этого файла, понятны и где необходимо снабжены комментариями. Некоторые из них можно изменить и после запуска. Среди них имя сервера и порт, включение поддержки OpenSSL, путь к программам, вывод времени, цвет, используемый при отображении тех или иных событий, почтовый адрес и сообщение, которое будет отослано при обнаружении критических происшествий. Для тестирования можно подключиться к серверу demo.sguil.net порт 7734, введя любого пользователя и пароль, и выбрав датчик «reset». Установка датчика Это самая сложная часть настроек, требующая внимательности, так как скрипты выводят мало отладочной информации и ошибку отследить довольно тяжело. Для удобства все сенсоры, работающие на одном компьютере, используют свой персональный каталог, в который они будут записывать информацию – $LOG_DIR/$SENSOR_NAME. Разработчики рекомендуют создать для этих целей на жестком диске отдельный раздел, смонтировать его в каталог /nsm и создать в нем подкаталоги, в которые будет записываться информация, поступающая от датчиков. Такой подход позволит избежать переполнения основного раздела в случае, если информации будет много. Я для этих целей использую каталог /var/snort_data. В подкаталоге sensor/snort_mods находятся два патча для препроцессоров Snort. Для работы sguil они не обязательны, но увеличивают количество собранной информации и упрощают ее запись в базу данных. Для работы потребуются исходники Snort. На момент написания статьи в архиве sguil были патчи для snort 2.1, я использовал последний «слепок» (CVS snapshot), проблем с установкой и использованием не было. Но если у вас что-то пойдет не так, возьмите соответствующую версию snort и соберите датчик с ней. Далее заходим в подкаталог src/preprocessors и устанавливаем патчи. # cd src/preprocessors # cp spp_portscan.c spp_portscan.c.bak # cp spp_stream4.c spp_stream4.c.bak # cp /sensors/snort_mods/2_1/spp_portscan_sguil.patch # cp /sensors/snort_mods/2_1/spp_stream4.patch # patch spp_portscan.c < spp_portscan_sguil.patch # patch spp_stream4.c < spp_stream4_sguil.patch После чего устанавливаем Snort как обычно (см. статью Павла Заклякова [6]), не включая во время конфигурирования поддержку mysql, о взаимодействии с которой теперь позаботится barnyard. Теперь в файле snort.conf описываем параметры работы обновленных препроцессоров. Формат записи для portscan: preprocessor portscan: $HOME_NET В нашем случае он будет таким: preprocessor portscan: $HOME_NET 4 3 /var/snort_data/gateway/portscans syn Запись для stream4: preprocessor stream4: detect_scans, disable_evasion_alerts, keepstats db /var/snort_data/ gateway/ssn_logs И в разделе «Snort unified binary format alerting and logging» раскомментируем следующую строку: output log_unified: filename snort.log, limit 128 Для нормальной работы сенсоров необходимо, чтобы каталоги /var/snort_data/ gateway/portscans и /var/snort_data/gateway/ssn_logs существовали и права доступа позволяли пользователю sguil записать в них информацию. Иначе будет получено такое сообщение:
Перед запуском их необходимо создать вручную. # mkdir /var/snort_data/gateway/portscans # mkdir /var/snort_data/gateway/ssn_logs # chown -R sguil /var/snort_data # chgrp -R sguil /var/snort_data Запускаем Snort: # snort -u sguil -g sguil -l /var/snort_data/ -c /etc/snort/snort.conf -U -A none -m 501 -i eth0
И так далее, заодно наблюдаем, как запускаются сконфигурированые нами препроцессоры. Но это еще не все. Для захвата двоичных данных используется скрипт log_packets.sh, который можно найти в подкаталоге sensor архива sguil. Необходимо обеспечить его запуск/перезапуск при помощи cron. # cp /sensor/log_packets.sh /usr/bin/ И в файл, используемый crontab, внести следующие строки для перезапуска каждый час. 00 0-23/1 * * * /usr/bin/log_packets.sh restart Кроме того, необходимо обязательно заглянуть внутрь файла и подправить значения переменных HOSTNAME, SNORT_PATH, LOG_DIR, GREP, PS, PIDFILE, INTERFACE, выставив их в соответствии с вашей системой. При помощи MAX_DISK_USE можно указать процент заполнения диска данными по достижении которого начнется удаление старой информации, а переменная FILTER позволяет более точно указать скрипту на то, какие данные интересуют исследователя, так как сценарий по умолчанию забирает всю информацию. И наконец, установка Barnyard. Чтобы не накладывать патчи, необходимые для работы со sguil (они имеются в архиве), рекомендуется использовать версию 0.2.0. Конфигурирование производится с параметрами ./configure --enable-mysql, после чего Barnyard компилируется и устанавливается обычным образом. Далее правим конфигурационный файл barnyard.conf, раскомментируем строку в конце файла и указываем в ней на параметры подключения к базе данных и место сбора информации сенсорами. # sguil #---- # This output plug-in is used to generate output for use # with the SGUIL user interface. To learn more about # SGUIL, go to http://sguil.sourceforge.net # output sguil: mysql, sensor_id 0, database sguildb, server syn, user sguil,password sguilpasswd, sguild_host syn, sguild_port 7736 Теперь запускаем. # /usr/sbin/barnyard -c /etc/snort/barnyard.conf -d /var/snort_data/ -g /etc/snort/gen-msg.map -s /etc/snort/sid-msg.map -f snort.log -w /etc/snort/waldo.file
Правим конфигурационный файл sensor_agent.conf и запускаем сам скрипт sensor_agent.tcl, лежащий в подкаталоге sensor, который обеспечивает передачу данных на сервер. # ./sensor_agent.tcl
Теперь, запустив на сервере демон sguild, мы должны наблюдать подключение нового сенсора.
Для автоматического запуска sensor_agent.tcl при старте системы используйте скрипт init/sensoragent. Все. Теперь можно подключаться к серверу при помощи клиента sguil.tk и приступать к анализу собранной информации. Как видно из рисунка, окно клиента sguil по умолчанию состоит из двух вкладок RealTime Events и Escalated Events, в которых в реальном времени выводится информация, собранная snort. Верхняя половина также разделена на три части, в которых выводятся события по степеням важности, более серьезные в верхнем окне, менее серьезные в нижнем. Если это неудобно, то можно изменить количество панелей при помощи переменных RTPANES, RTPANE_ PRIORITY и RTCOLOR_PRIORITY в файле sguil.conf. Дополнительно можно отобрать все события, подпадающие под определенную категорию, в отдельную вкладку, воспользовавшись пунктом меню File. При этом если на скрытой вкладке появится событие, заслуживающее внимания, то заголовок изменит свой цвет. Параметр ST показывает на статус предупреждения (RT – real time), CNT представляет собой счетчик событий со сходными характеристиками. Нижняя половина также разделена на две части. Слева выводится информация, собранная при помощи обратного DNS-запроса и сервиса whois, внизу можно просмотреть, в зависимости от выбранной вкладки, системные и пользовательские сообщения. Последние представляют собой простейший чат между пользователями, зарегистрировавшимися на одном сервере. В правом нижнем окне выводится более подробная информация о предупреждении. При помощи меню Query можно создавать запросы для отбора определенной информации, которые будут сохранены в файле /etc/sguil/sguild.queries. Для удобства предлагаются мастера и уже подготовленные запросы. Пункт Reports позволяет генерировать отчеты. Sguil является довольно серьезным орудием в руках специалиста, которого беспокоит безопасность сетей. Но, как любой другой инструмент, он требует приобретения практических навыков работы. Освоив основные приемы, можно быстро находить и локализовать проблемные участки.
Ссылки:
|
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
