 |
|
|
|
Три поросёнка Snort: «Ниф-Ниф», «Нуф-Нуф» и «Наф-Наф». Настройка нескольких сенсоров Snort с помощью SnortCenter
Три поросёнка Snort: «Ниф-Ниф», «Нуф-Нуф» и «Наф-Наф» Прежде чем перейти к практическим вопросам использования нескольких сенсоров на базе IDS Snort, рассмотрим теоретические аспекты этой задачи. Для этого оценим трудности, возникающие при различных способах реализации, и создадим модель, по большей части лишённую замеченных недостатков. «Одна голова хорошо, а две лучше», – подумал змей Горыныч, убегая от Ильи Муромца. Так и в вопросах обнаружения атак: информация лишней не бывает, больше сенсоров – меньше вероятность пропуска атаки. Конечно, эффективность подключения новых сенсоров, начиная с некоторого числа, не даст такого прироста эффективности, как вначале, но это уже другой вопрос. При использовании нескольких сенсоров наиболее удобным способом ведения логов будет использование одной или нескольких БД. Подробнее об этом можно прочитать в [4]. Задача заставить два сенсора вносить свои записи в одну БД не представляет из себя никакой сложности. Об этом не было рассказано ранее, но можно догадаться, что необходимо в третьей секции конфигурационного файла snort.conf, отвечающей за вывод данных, прописать всего лишь в одной строчке другое имя хоста с БД, номер порта, логин и пароль. Далее, если доступ к БД не закрыт каким-нибудь пакетным фильтром или МЭ по пути, то никаких проблем быть не должно. Даже ACID будет исправно показывать статистику от двух и более сенсоров. Работа такой системы только на первый взгляд кажется прозрачной и беспроблемной. По мере увеличения времени эксплуатации системы неизбежно возникнут различные вопросы. Вот некоторые из них, которые видно невооружённым глазом сразу до начала эксплуатации:
Таким образом, казалось бы, простенькая идея замены одного адреса хоста в файле конфигурации оборачивается большим списком вопросов, не на все из которых можно найти однозначный ответ. Давайте остановимся и частично рассмотрим проблемы и пути решения первого вопроса. При отсутствии каких-либо целенаправленных решений поставленный вопрос решается неудобно, но просто. Администратор подключается к компьютеру стандартными средствами администрирования, например, с помощью ssh или telnet. Руками вносит изменения в конфигурационный файл и перезапускает snort. Потом подключается к другому хосту, где установлен другой сенсор и повторяет операцию. Согласитесь, что при большом количестве узлов ситуация не очень удобная. Поэтому администратор, чтобы избавить себя от подобной рутинной работы, один раз автоматизирует процесс – пишет скрипт на bash, который периодически запускается через cron, скачивает c помощью wget новые правила с сайта www.snort.org и устанавливает их в систему. Благо правила всё время находятся в одном и том же месте на сайте, а имя файла с последними правилами остаётся неизменным. Либо http://www.snort.org/dl/rules/snortrules-stable.tar.gz (* см.ниже) – стабильная ветка, либо http://www.snort.org/dl/rules/snortrules-current.tar.gz (* см. ниже) – активно развивающаяся. Во время процесса установки в систему правила разархивируются, распаковываются, возможно, как-то проверяются, помещаются на место старых правил, в конфигурационный файл, возможно, вносятся изменения и происходит перезапуск демона snort, чтобы внесённые изменения вступили в силу. Таким образом, система работает с завидной стабильностью, присущей Linux/*BSD, некоторое, возможно, и продолжительное время. Позже планомерно появляются новые хосты с сенсорами, меняются правила и происходят другие мелкие события. В общем, всё работает. Но вот наступает тот самый момент, когда в алгоритме работы системы наступает сбой либо вероятность его возникновения велика. Нет, это не правила неверно скачались. И не изменилось их местоположение, хотя и такое частенько бывает. По этой причине вверху у ссылок стоят звёздочки, ссылки уже не действительны. Так, недавно обновились адреса и форматы правил для Snort после выхода версии 2.1.1-RC1 из серии 2.1.x. Сейчас для разных серий надо скачивать разные правила, в результате имеем следующие реальные ссылки для скачивания:
Старые же правила переехали в поддиректорию: http://www.snort.org/dl/rules/old. При этом на сайте даже нет мягких ссылок для обратной совместимости на новое местоположение старых правил. При попытке загрузить файлы по ссылкам выше со звёздочками выдаётся ошибка о том, что нет таких файлов. В ситуации выше будем считать, что система проверки правил их не установила и послала письмо-уведомление администратору о возникшей ошибке. Это будет не у всех, подобную обратную связь каждому придётся налаживать вручную. Но что же произошло, если даже и не система отказала из-за сбоев в электропитании? А просто в самой IDS Snort нашли очередную ошибку, например, для временного решения которой необходимо отключение того или иного препроцессора в системе обработки трафика. То есть просто-напросто надо внести изменения в конфигурационные файлы, например, закомментировать одну строчку. И вот ситуация повторяется, администратор залезает и вручную правит правила на каждом из сенсоров. А тут ситуация усугубляется тем, что раньше он работал один, а к моменту сбоя штаты разрослись, и администраторов стало много. Так что для установки всего лишь одного знака комментария необходимо всем знать пароль суперпользователя и прочие неудобства. Какой же может быть выход? Наиболее оптимальным решением для данного случая было бы использование некой единой конфигурационной БД с правилами для всех сенсоров. Удобно, когда все правила в одном месте, соответственно, для внесения изменений уже требуются права только на доступ к конфигурационной БД с правилами, то есть нет того случая, когда выдаются излишние права и пользователь может сильно повредить работоспособность системы. Всё, казалось бы, хорошо, но только за любое удобство приходится чем-то расплачиваться. В данном случае нам придётся решать проблемы связи сенсоров с центральной конфигурационной БД. Проблем здесь не меньше, а именно:
На наше счастье, нет необходимости придумывать данную систему с нуля, так как уже имеется пакет SnortCenter [1], изучением и настройкой которого мы займёмся далее. Коротко Основная идея SnortCenter – упростить конфигурирование (в том числе обновление правил) и диагностику работоспособности большого числа сенсоров. При необходимости могут конфигурироваться сенсоры на базе Windows NT платформы. Под диагностикой понимается информация о том, запущен и работает демон Snort или нет. Анализом и сбором данных SnortCenter не занимается, поэтому всё, что было рассказано в [4] о внесении записей сенсорами в единую БД и о том, как эту БД просматривать, нам пригодится. SnortCenter – это не зависимое от средств анализа решение, скорее – дополняющее его. Для удобства пользователей имеется SnortCenter ACID Plugin, позволяющий красиво интегрировать веб-интерфейсы SnortCenter и ACID. Из чего состоит SnortCenter?
Если попытаться наглядно представить работу данной системы, должна получиться примерно следующая схема:
Рисунок 1. Наглядная схема взаимодействия сенсоров с центром Данная система не является безопасной с точки зрения атак на неё и поэтому требует использования дополнительных средств. Наиболее простым и эффективным средством снижения опасности атак на систему может быть использование пакетных фильтров (на схеме они не изображены), например, iptables. В этом случае можно избежать большинства атак, осуществляемых без подмены IP-адреса. Несколько подробнее о вышеописанном способе и его недостатках написано далее. Если вы решили создать у себя систему обнаружения атак с несколькими сенсорами и поняли, что вышеописанная схема управления конфигурационными файлами в целом вам подходит или данная реализация всё же лучше, чем её отсутствие, то давайте приступим к её установке и настройке. Установка Snort Выберем три узла, которые будут сенсорами, назовём их, например, «Ниф-Ниф», «Нуф-Нуф» и «Наф-Наф» и попробуем создать схему, аналогичную приведённой выше, для этого, как и ранее, нам потребуется скачать и установить Snort с поддержкой ведения логов в БД (подробнее см. [4]) на каждый из узлов-сенсоров. Те, у кого Snort уже установлен, могут пропустить несколько шагов, со всеми остальными скачиваем последнюю версию Snort: # wget http://www.snort.org/dl/snort-2.1.1.tar.gz # wget http://www.snort.org/dl/snort-2.1.1.tar.gz.md5 Сравниваем значение хеша выданного командами: # cat snort-2.1.1.tar.gz.md5 # md5sum snort-2.1.1-RC1.tar.gz
Распаковываем содержимое архива snort-2.1.1.tar.gz куда-нибудь, например, в уже имеющуюся директорию /progi: # tar -zxvf snort-2.1.1.tar.gz -C /progi После заходим в /progi/snort-2.1.1: # cd /progi/snort-2.1.1 и запускаем конфигурирование с опцией --with-mysql, не забыв о том, что для осуществления этого шага нам необходимо, чтобы в системе уже стояла библиотека libpcap, например, licpcap-0.6.2-12, и часть файлов от MySQL, в частности пакеты mysql-3.23.58-1.73 и mysql-devel-3.23.58-1.73. Подробнее см. [4]. # ./configure --with-mysql Замечание. В процессе обновления Snort на одном из сенсоров с версии 2.0.4 до версии 2.1.1 во время запуска команды конфигурации новой версии выдалась следующая ошибка об отсутствии библиотеки pcre (Perl Compatible Regular Expressions [9]).
В то время как на другом компьютере конфигурация прошла без проблем. Первая мысль, что пришла в голову – поискать на нём файл pcre.h, запустив: # find / -name pcre.h В результате поиска были получены две строки:
после чего возникла мысль узнать, какой rpm-пакет содержит нужный файл, после чего была выполнена следующая команда: # rpm -qf /usr/include/pcre/pcre.h которая и сообщила, что нужный нам пакет – это pcre-devel-3.9-2, который успешно нашёлся на втором диске RedHat 7.3 и был установлен командой: # rpm -ihv pcre-devel-3.9-2.i386.rpm после чего конфигурирование, запущенное повторно, прошло без проблем. После конфигурирования необходимо скомпилировать Snort командой: # make И установить командой: # make install В процессе установки, если вы не задавали дополнительных ключей, у вас будет установлено всего лишь 2 файла: /usr/local/bin/snort – сама программа и man-страница к ней /usr/local/man/man8/snort.8. Далее следует создать директорию /etc/snort, если вы ставите Snort на данный компьютер в первый раз, или удалить все файлы и поддиректории оттуда, если они у вас остались от предыдущих версий. То же самое следует сделать с директорией /var/log/snort. В целом нам эта директория не понадобится, но если вдруг не получится вести логи в БД, то она может нам пригодиться в процессе отладки. Аналогичным образом следует установить Snort на все будущие сенсоры. Следующим шагом мы осуществим установку агентов (SnortSensor Agent) на наши сенсоры. После того как мы убедимся, что они работают, мы установим и настроим консоль управления SnortSensor (SnortCenter Management Console), через которую загрузим на все сенсоры их файлы конфигурации и осуществим дополнительную отладку агентов, если это понадобится. Установка SnortSensor Agent Перед установкой агента скачиваем необходимый для его работы модуль для perl Net::SSLeay [5]. (Если модуля нет – не будет поддерживаться закрытое SSL-соединение с агентом.) # wget http://symlabs.com/Net_SSLeay/Net_SSLeay.pm-1.21.tar.gz Распаковываем содержимое архива Net_SSLeay.pm-1.21.tar.gz куда-нибудь, например, в уже имеющуюся директорию /progi: # tar -zxvf Net_SSLeay.pm-1.21.tar.gz -C /progi После заходим в появившуюся директорию по имени и номеру версии модуля: # cd /progi/Net_SSLeay.pm-1.21 и запускаем # perl Makefile.PL либо # ./Makefile.PL Запущенный perl-скрипт проверяет наличие в системе OpenSSL и его версию, создаёт необходимые для дальнейшей установки Makefile файлы. OpenSSL необходим для нормальный работы Net_SSLeay. В случае необходимости выдаются рекомендации по обновлению версии. Замечание 1. Следует отметить, что не всегда лучше иметь самый последний номер того или иного пакета, в каждом конкретном случае следует разбираться отдельно. Так, например, тот же Red Hat очень любит выпускать исправления к старым версиям. В результате получается, что номер версии пакета остаётся старый, а ошибок в пакете уже нет. Замечание 2. Для компиляции модуля Net_SSLeay необходимо, чтобы также был установлен пакет openssl-devel, хотя его наличие не проверяется. Сделать это можно, например, командой: # rpm -ihv openssl-devel-0.9.6b-35.7.i386.rpm Если пакет openssl-devel у вас не будет установлен, то в процессе компиляции вы получите следующую ошибку:
Для компиляции запускаем: # make После успешной компиляции запускаем: # make install для установки модулей и man к ним. Для того чтобы убедиться, что модуль SSL установился правильно, запустите: # perl -e "use Net::SSLeay" Если не будет никаких сообщений об ошибках, то это значит, что SSL-модуль установился правильно. После того как модули установлены, можно приступить к непосредственной установке SnortSensor Agent. Для этого скачиваем последнюю версию из [2]. # wget http://users.pandora.be/larc/download/snortcenter-agent-v1.0-RC1.tar.gz Скорее всего версия у вас будет та же самая, так как уже более года не обновляются новости и не выпускаются новые версии. В процессе отладки продукта мы встретимся с некоторыми проблемами, часть которых попробуем решить своими силами. К сожалению, попытки связаться с автором («Stefan Dens» <larc@pandora.be>), чтобы скоординировать усилия и, возможно, способствовать выходу новой версии без замеченных недостатков, не привели к успеху. На форуме от Snort вопросами SnortCenter не интересуются. В российской части, например на sysadmins.ru, поиск чего-нибудь по ключевому слову snortcenter абсолютно бесполезен. Можно констатировать, что проект «не отполирован до конца». Несмотря на подобное равнодушие к нему, в нём можно найти некоторые полезные свойства, о которых можно прочитать ниже. После скачивания архив необходимо куда-нибудь распаковать, например в /progi: # tar -zxvf snortcenter-agent-v1.0-RC1.tar.gz -C /progi После запуска команды следует зайти в появившуюся директорию /progi/sensor: # cd /progi/sensor Далее следует запустить скрипт setup.sh для конфигурации сенсора посредством ответов на вопросы: # ./setup.sh Появится следующая картинка.
Рисунок 2. Конфигурирование посредством ответов на вопросы setup.sh На запрос «Config file directory» вместо /progi/sensor/conf следует указать /etc/snort / – то место, где будут располагаться и куда будут записываться конфигурационные файлы, необходимые для запуска Snort. На запрос «Log file directory» вместо /progi/sensor/log следует указать /var/log/snort – это место, куда будут вестись логи. На запрос расположения интерпретатора Perl «Full path to perl» нажмите просто {ENTER}, если вы не меняли его месторасположение и имя на отличные от приведённых по умолчанию /usr/bin/perl. То же самое и по поводу Snort – нажмите просто {ENTER}. На запрос о пути к правилам Snort «Snort Rule config file directory» введите /etc/snort вместо предлагаемых /progi/sensor/rules/. Замечание. Несмотря на то что в предыдущих настройках мы располагали правила в /etc/snort/rules, сейчас, исходя из соображений удобства, мы этого делать не будем. Далее задаются вопросы, необходимые для настройки собственного веб-сервера. Уточняется порт, на котором будет веб-сервер агента «Sensor port», лучше всего его оставить без изменений, если у вас нет других соображений на этот счёт, нажав {ENTER}. (По умолчанию 2525). Далее спрашивается, какой IP-адрес следует прослушивать. Это нужно на тот случай, если у вас несколько IP-адресов на одном интерфейсе или более сложная схема. По умолчанию следует оставить «any», и тогда будут прослушиваться только те адреса, которые связаны с конкретным интерфейсом. Это первое неудобство агентов, что их следует привязывать к интерфейсам. Это не самое страшное неудобство, и об этом мы поговорим чуть ниже. Пока же на запрос «If this host has multiple IP addresses, the server can be configured to listen on only one address (default any):» нажмём просто {ENTER}. Далее программа настройки запрашивает логин пользователя, которому будет разрешено в дальнейшем подключаться к веб-серверу. Для начала на запрос «Login name (default admin)» можно нажать просто {ENTER}, однако если вы хотите несколько повысить защищённость, то придумайте своё имя, которое вам придётся соответственно заменить и в других местах самостоятельно, где это понадобится. Замечание. Реальные пользователи в системе не заводятся. Заведённые пользователи с хэшами от паролей находятся в /etc/snort/sensor.users. В силу особенностей реализации не используйте символы «:» и «@» в логине и пароле во избежание ошибок. На запросы «Login password:» и «Password again:» придумайте и введите два раза пароль: ваш_пароль№7 для доступа вышеобозначенного пользователя к веб-серверу. Будьте внимательны, во время ввода пароля в соответствии с одним из требований безопасности System V звёздочки вместо вводимых символов не отображаются. В случае несовпадения паролей программа выдаст ошибку:
и необходимо будет запустить конфигурацию ещё раз: # ./setup.sh и ответить на вышеописанные вопросы заново. После удачного ввода пароля появится вопрос, как называется хост, на котором установлен сенсор. «Sensor host name (default %имя_вашего_хоста%):» Можно оставить то имя, что указано по умолчанию, нажав {ENTER}, а можно написать что-то новое, вроде Nif-Nif или Nuf-Nuf, чтобы как-то различать сенсоры в дальнейшем. На вопрос об использовании SSL отвечаем «y» и жмём {ENTER}. Далее нас спрашивают о диапазоне IP-адресов, с которых можно будет осуществлять доступ к агенту. Это дополнительная мера защиты, используемая в добавление к авторизации. При необходимости всё то же самое более гибко можно сделать с помощью какого-нибудь пакетного фильтра, вроде iptables, однако одно другому не мешает и на запрос «Allowed IP addresses» лучше ввести IP-адрес или имя центра управления сенсорами. При необходимости ввести несколько адресов разделяйте их пробелами, следуя выведенной подсказке. Следующим будет вопрос о том, следует ли запускать агента автоматически при загрузке системы «Start Sensor at boot time (y/n):», то есть необходимо ли создать соответствующие файлы в /etc/rc.d/... Отвечаем на этот вопрос «y» и жмём {ENTER}, в противном случае нам придётся каждый раз после перезагрузки системы по тем или иным причинам запускать агентов руками, что может быть не очень удобно. После ответа на все вопросы осуществляется запуск агента, и фактически он уже готов работать. В директории /etc/snort у вас появится 11 файлов и 2 директории с необходимыми файлами для работы агента (см. рис. 4). В частности, будут созданы файлы для запуска, остановки и деинсталляции, так что совсем не обязательно запускать и останавливать работу агента через /etc/rc.d/init.d/sensor.
Рисунок 3. Вид директории /etc/snort после установки SnortSensor Agent Запустив: # /etc/rc.d/init.d/sensor status можно убедиться, что агент запущен и работает. Если на компьютере будущего центра имеется веб-браузер или вы заходите с другого компьютера, указанного в списке разрешённых для доступа к веб-серверу, и правила пакетного фильтра позволяют проходить пакетам, то вы можете запустить браузер и подключиться к агенту через защищённый веб-интерфейс, набрав просто адрес «https://адрес_агента:2525». Проверить работу агента таким образом желательно, чтобы не искать после ошибку, потратив большее количество времени. Если вы не позаботились ранее о возможности подключения к агенту с других хостов, хотя бы на время настройки системы, то, возможно, вам потребуется дописать разрешение на нужный вам хост в файле /etc/snort/miniserv.conf через пробел после того, что написано у параметра «allow=». Удалить лишние разрешённые хосты можно там же. Для разрешения прохождения пакетов через пакетный фильтр iptables, настроенный на политику запрета по умолчанию, следует указать два следующих правила: # iptables -I INPUT -p tcp -s $REMOTE_IP --sport 1024:65535 -d $SENSOR_IP --dport 2525 -j ACCEPT # iptables -I OUTPUT -p tcp -s $SENSOR_IP --sport 2525 -d $REMOTE_IP --dport 1024:65535 -j ACCEPT Переменные $REMOTE_IP и $SENSOR_IP следует заменить нужными значениями. Данные правила не учитывают направления установления соединения, но при необходимости их можно подправить, ещё больше «закрутив гайки». После захода на веб-страничку агента будет запрошен логин и пароль. И выдастся следующая картинка:
Нам этого вполне достаточно, пытаться что-то запустить на данный момент есть бессмысленное занятие, так как у нас ещё нет конфигурационного файла, с которым бы следовало запускать Snort. Аналогичным образом устанавливаются и проверяются SnortSensor Agent на других узлах. Для того чтобы создать необходимые конфигурационные файлы и запустить Snort, нам необходимо теперь заняться центром управления, для этого установить на него непосредственно консоль управления, так называемую SnortSensor Management Console, и настроить её на совместную работу с БД правил и сенсорами, далее необходимо создать правила для сенсоров, передать их на узлы. После этого на узлах-сенсорах будут созданы соответствующие им файлы конфигурации, и можно будет попытаться запустить Snort. Установка и настройка консоли управления SnortSensor Management Console По идее, центр управления лучше установить на отдельном компьютере, но так как на сам центр могут также совершаться атаки, то лучше и на нём установить сенсор для их обнаружения. В результате получится конфигурация, когда центральная консоль управления устанавливается на одном из сенсоров. Для начала установки скачиваем из [2] последнюю версию SnortSensor Management Console, способную работать со Snort v.2.x. # wget http://users.pandora.be/larc/download/snortcenter-v1.0-RC1.tar.gz Далее распаковываем содержимое архива туда, где находятся файлы веб-сервера, например, в директорию /var/www/html: # tar -zxvf snortcenter-v1.0-RC1.tar.gz -C /var/www/html Далее, чтобы не запутаться, распаковавшуюся только что директорию /var/www/html/www переименуем в /var/www/html/snortcenter: # mv /var/www/html/www /var/www/html/snortcenter Затем нам необходимо отредактировать файл config.php, для этого либо запускаем: # mcedit /var/www/html/snortcenter/config.php либо жмём F4 на нужном файле в mc (midnight commander). Если у вас не установлен mc, то редактируем файл с помощью vi: # vi /var/www/html/snortcenter/config.php Предполагается, что на центральном компьютере уже установлен ACID и все необходимые для его работы компоненты, в частности php, php-mysql и ADODB – абстрактный класс доступа к базам данных, написанный на PHP [7]. Подробнее об установке ACID см. [4]. В процессе редактирования конфигурационного файла необходимо правильно определить следующие переменные:
В конфигурационном файле встречаются и другие переменные, но для нас они менее существенны, поэтому мы их не рассматриваем. Подробнее обо всех переменных см. [8]. После того как управляющая консоль SnortCenter настроена, нам необходимо:
Для этого подключаемся к БД MySQL от имени суперпользователя этой БД. # mysql -u root -p На запрос пароля вводим ваш_пароль№2 (см. [4]). Далее даём команды: mysql> CREATE DATABASE snortcenter; mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snortcenter.* to snortcenteruser@localhost; mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snortcenter.* to snortcenteruser; mysql> set password for "snortcenteruser"@"localhost"=password("ваш_пароль№6"); mysql> set password for "snortcenteruser"@"%"=password("ваш_пароль№6"); mysql> exit Третью и пятую команды можно не давать, если у вас БД и управляющая консоль стоят на одном компьютере. В результате должно получиться нечто следующее:
Далее начинается всё самое интересное, а именно, визуальная настройка через веб-интерфейс. Для этого заходим через любой графический браузер на адрес нашего центра, где установлена управляющая консоль SnortCenter (http://адрес_SnortCenter/snortcenter, а лучше, если ваш веб-сервер поддерживает защищённое соединение https://адрес_SnortCenter/snortcenter). Программа быстро определяет, что была запущена в первый раз, и создаёт необходимые для её работы таблицы. Также среди строчек мы можем увидеть строчку о создании пользователя:
из которой мы можем узнать логин и пароль для доступа к SnortSensor Management Console в дальнейшем. Если подождать некоторое время либо набрать вышеуказанный URL повторно, то мы попадём на страничку, где будут спрашиваться вышеуказанные login и password. В дальнейшем мы сменим пароль на другой, а пока вводим «change».
После входа нам необходимо записать в БД новые правила, обычно для этого рекомендуется зайти в меню «Admin –> Import/Update rules –> Update from Internet».
После чего программа скачивает все правила из Интернета с адреса $snortrules_url, указанного в файле config.php. Иногда по соображениям безопасности сервера не имеют доступа к веб-сайтам, поэтому такое обновление может потерпеть неуспех. Если у вас подобный случай, то вместо обновления правил вас ждёт через некоторое время следующая картинка.
Выходов из этой ситуации два. Первый – скачать правила вручную, проверить и загрузить их на доверенный веб-сервер в том виде, как они были изначально. После подправить $snortrules_url в config.php и, возможно, дописать пару разрешающих правил для iptables и проследовать указаниям выше, как будто вы загружаете правила из Интернета. Второй – так же вручную скачать правила, распаковать, проверить, создать из них единый текстовый файл. После использовать этот текстовый файл для записи правил в БД либо путём копирования всего его содержимого в соответствующую загрузочную область веб-формы («Admin –> Import/Update Rules –> Copy & Paste»), либо путём обычной загрузки файла на сервер («Admin –> Import/Update Rules –> Upload file»). Для второго необходимо включить в php поддержку загрузки файлов на сервер. Замечание. После выхода очередной версии Snort серии 2.1.x при попытке загрузить новые правила мной была обнаружена несовместимость правил от Snort 2.1.x со SnortCenter. Возникла следующая ошибка в процессе загрузки.
Рисунок 4. Ошибка в процессе загрузки Покопавшись в PHP-файлах SnortCenter, я раскомментировал 293-ю строку: //echo "$sql которая находится перед: $result = $db->acidExecute($sql); $result_a = $db->acidExecute("SELECT max(id) FROM preprocessor"); $myrow = $result_a->acidFetchRow(); $update_rule_count[1] = "add-spp"; $update_rule_count[2] = $myrow[0]; В результате была получена следующая картинка после запуска.
Рисунок 5. Ошибка, строка даёт понять причину ошибки После этого, глядя на «global », возникла мысль, что проблема, скорее всего, связана с переносом длинных строк в файлах конфигурации. В разборщике правил для SnortCenter, видимо, забыли учесть, что, начиная со Snort v.1.8, правила не обязательно должны писаться в одну строчку, и что теперь они могут переноситься с помощью указания обратного слеша «» в конце строки. После того как стала ясна причина ошибки, можно попытаться её исправить, для этого пишем небольшой скрипт на perl, который будет перенесённые строки собирать в одну строку. Создадим файл /var/www/html/snortcenter/convert_ru-les.pl следующего содержания: #!/usr/bin/perl while ($temp=){ if ($temp=~/^[^#].* $/) { chomp $temp; chop $temp; } print $temp; } Не забудем придать атрибут запускаемости этому файлу. # chmod +x convert_rules.pl При желании скрипт можно сократить, но тогда он будет менее наглядным. Скрипт делает следующее: читает построчно стандартный поток ввода и помещает прочитанное в переменную $temp. Далее эта переменная проверяется на наличие в конце строки обратного слеша и что эта строка не есть комментарий. Если обратный слеш есть и строка не начинается со знака «#» (какой смысл переносить комментарии), то осуществляется отрезание от строки символа её конца и обратного слеша, что приводит к тому, что последующая строка как бы приклеивается к текущей в общем потоке символов. Далее необходимо внести изменения в скрипт разбора файлов в нужном месте, чтобы наш файл оттуда вызывался перед тем, как правила попадут к разборщику. Для этого вносим изменения в строки 74 и 78 файла db_pars.php, отвечающие за загрузку правил с веб-сервера. Вносить изменения в файлы, загружаемые вручную также желательно, но не обязательно, так как в этом случае вы всегда имеете возможность их подправить, придав им нужный вид. Поэтому исправления будут только в двух местах, а не в большем количестве мест. Вместо: $fp=popen($curl_path."curl -s $proxyline $snortrules_url | gunzip -dcf - | tar -xOf - rules/*.rules rules/*.conf rules/*.config", "r"); и $fp=popen($curl_path."curl -s $proxyline $snortrules_url 2>/dev/null | tar xzOf - rules/*.rules rules/*.conf rules/*.config", "r"); пишем $fp=popen($curl_path."curl -s $proxyline $snortrules_url | gunzip -dcf - | tar -xOf - rules/*.rules rules/*.conf rules/*.config | /var/www/html/snortcenter/convert_rules.pl", "r"); и $fp=popen($curl_path."curl -s $proxyline $snortrules_url 2>/dev/null | tar xzOf - rules/*.rules rules/*.conf rules/*.config | /var/www/html/snortcenter/convert_rules.pl", "r"); После этого правила успешно загружаются, уже не выдавая сообщения об ошибке. В окошке браузера у вас появится примерно следующая картинка.
Рисунок 6. Фрагмент окна браузера после успешной загрузки правил Как видно, во время разгрузки правил выдаются предупреждения о неизвестности некоторых полей с комментариями: Unknown Rule option: msg:«....», однако на работоспособность snort это не влияет. После загрузки правил можно убедиться, что они оказались в БД snortcenter, для этого выбираем «Resources –> Rules –> View Rules» и наблюдаем правила.
Рисунок 7. Правила в БД, убедимся, что они есть Аналогичным образом можно просмотреть переменные («Resources –> Variables –> View Variables»), препроцессоры («Resources –> Preprocessors –> View Preprocessors») и другую информацию. Для просмотра не обязательно использовать средства SnortCenter, можно воспользоваться phpMyAdmin или напрямую использовать клиент mysql [4]. После того как в БД имеются правила, необходимо создать конфигурации сенсоров, активировать нужные для каждого сенсора правила и закачать конфигурации на свои места, чтобы конфигурационные файлы сенсоров соответствовали записям в БД для каждого сенсора. Для того чтобы добавить сенсор в БД, выбираем «Sensor Console –> Add Sensor».
Рисунок 8. Добавление сенсора И далее заполняем поля таблички. В имени сенсора не имеет смысла вводить знак «-», так как он автоматически после будет оттуда удалён. Среди параметров командной строки желательно указать ключ -D, чтобы snort запустился и стал демоном. В качестве пароля вводим ранее придуманный ваш_пароль№7. После того как все поля заполнены, нажимаем save.
Рисунок 9. Сохранение информации о новом сенсоре Далее необходимо для созданного сенсора активировать правила, для этого выбираем в меню «Sensor Config –> Rule Selection».
Рисунок 10. Выбор правил для просмотра/активации В появившемся окне после списка внизу нажимаем на Select, после чего все правила выделяются галочками:
далее в падающем меню выбираем пункт Activate и значки около правил изменяются.
Единственный недостаток программы, что All означает не все правила, как может показаться, а всего лишь все правила на текущей странице, поэтому не следует забывать активировать правила на 2-й, 3-й... и т. д. страницах. Разработчики не позаботились об удобстве, поэтому нелишним будет вспомнить про наличие переменной $max_lines в файле conig.php. Однако не стоит увлекаться, уже на значении $max_lines=1000 в процессе работы с правилами может появиться следующая ошибка.
Можно проверить, все ли правила вы активировали или нет, для этого необходимо щёлкнуть на Rule Category Overview.
После чего появится табличка, в которой правила будут разбиты по категориям, около каждой категории будет два числа через дробь – числа активированных правил к общему числу правил в категории. Если в категории не все правила активированы, то она для удобства подсвечивается жёлтым. Те категории, в которых все правила активированы, подсвечены зелёно-салатовым.
Рисунок 11. Просмотр активированности правил по категориям Аналогично, даже чуть более просто активируем переменные, для этого выбираем в меню «Sensor Config –> Variable selection» и т. д.
Аналогично поступаем с препроцессорами и другими пунктами меню RuleType Selection, Classificaton Selection и т. д.
Перед тем как активировать Output Plugin Selection, необходимо создать конфигурации для каждого из сенсоров, для этого необходимо выбрать «Resources –> Output Plugins –> Create Output Plugin».
Рисунок 12. Выбор пункта меню «Create Output Plugin» В появившемся падающем меню следует выбрать Databa-se (Log to a variety of databases) и нажать select.
Рисунок 13. Выбор пункта меню «Database (Log to a variety of databases)» Далее появится таблица, которую необходимо заполнить.
Рисунок 14. Настройка параметров ведения логов в БД В DB Host следует указать имя или адрес сервера, на котором запущена БД, в которую следует вести логи. Аналогично заполняются и другие параметры. После заполнения необходимо нажать на save. После того как будет создан хотя бы один output plugin, его можно будет выбрать и активировать в «Sensor Config –> Output Plugin Selection». После того как все необходимые составляющие правил для нужного сенсора выбраны, можно создать и скинуть итоговый конфигурационный файл на выбранный сенсор. Для этого следует выбрать «Sensor Console –> View Sensors» и у нужного сенсора (пока он один) нажать push.
Рисунок 15. Скидывание конфигурационного файла на сенсор После чего снизу на жёлтом фоне появится надпись, сообщающая об успешном сбросе файла конфигурации на его место.
Казалось бы, что на этом настройка должна быть закончена и достаточно нажать на start, чтобы всё заработало, но, к сожалению, это не так. Сейчас мы осуществим некоторые действия, догадка о выполнении которых была получена опытным путём. Если попытаться нажать start, то мы получим сообщение об ошибке, не дающее запустить snort на сенсоре:
Из чего можно сделать предположение о том, что системе не хватает файла unicode.map (находится в файле с правилами). По идее этот файл не должен меняться так же часто, как правила, поэтому нет смысла править SnortCenter, чтобы он умел его скидывать вместе с файлом конфигурации. Проще его скинуть один раз руками в директорию /etc/snort. Чтобы в дальнейшем не возникало подобных ошибок, лучше всего вместе с unicode.map скинуть и другие *.map-файлы, а именно для текущей версии это sid-msg.map и gen-msg.map. Далее следует подправить строчки 140-142 в файле parser.php. Вместо elseif ($what == "byte_test") { if ($rule["byte_test"]) $rule["byte_test"][$content_nr] .= "; byte_test: $val"; else $rule["byte_test"][$content_nr] = $val; следует написать: elseif ($what == "byte_test") { $rule["byte_test"][$content_nr] = $val; До того, как это было сделано, разборщик правил неверно разбирал правила, в результате чего дописывалось лишнее значение byte_test: и snort не хотел запускаться. Возможно, подобную операцию по корректированию в дальнейшем придётся сделать со строками 136-138, но пока в этом нет необходимости. Также при визуальном просмотре было замечено несколько опечаток: в строчках 166, 232, 250, 251 файла db_pars.php и строчке 307 файла rules.php, скорее всего, вместо Unknown-Catagory следует написать Unknown-Category. После этого при нажатии на start snort успешно запустился, имя сенсора стало подсвеченным салатово-зелёным цветом. Аналогичным образом следует усновить Snort и Snort-Center Agent на другие машины-сенсоры и настроить их на совместную работу со SnortCenter Management Console. (Обратите внимание, у разных сенсоров переменная HOME_NET будет разная). В результате после запуска Snort на всех сенсорах у вас получится примерно следующая картинка консоли управления, где все запущенные сенсоры окажутся на зелёно-салатовом фоне.
Рисунок 16. Успешно работающие сенсоры Если Snort остановлен, то подсветка будет жёлто-оранжевая, и справа вместо «stop» будет «start», а вот если сенсор недоступен, то подсветка будет красной, и также будет соответствующее сообщение.
Рисунок 17. Некоторые сенсоры недоступны, остановлены Теперь, когда всё работает, самое время поговорить об удобствах и недостатках. Удобства. SnortCenter + ACID Обычно SnortCenter и ACID [10] запускаются на одном сервере, поэтому возникает логичный вопрос, почему бы не интегрировать интерфейс одного средства с другим. Конечно, этого можно и не делать, но почему бы не иметь возможность с помощью мышки из одной страницы с записями об атаках попасть путём одного щелчка на страничку состояния сенсоров. В данном случае не надо ничего придумывать, так как уже имеется готовое решение в виде SnortCenter ACID Plugin. Нам необходимо просто скачать Plugin и установить в соответствии с прилагаемыми к нему инструкциями. (Предполагается, что у пользователя уже стоит ACID и работает, если нет, то его необходимо установить, см. [4].) Для этого скачиваем файл acid-0.9.6b23-plugin-v1.tar.gz: # wget http://users.pandora.be/larc/download/acid-0.9.6b23-plugin-v1.tar.gz Распаковываем содержимое архива в какую-нибудь директорию, например в /progi: # tar -zxvf acid-0.9.6b23-plugin-v1.tar.gz -C /progi Переименовываем как-нибудь файлы ACID acid_main.php, acid_output_html.inc, acid_style.css, чтобы они не потерялись, так как на их место будут записаны новые. Например, допишем к ним расширения .bak: # mv /var/www/html/acid/acid_main.php /var/www/html/acid/acid_main.php.bak # mv /var/www/html/acid/acid_output_html.inc /var/www/html/acid/acid_output_html.inc.bak # mv /var/www/html/acid/acid_style.css /var/www/html/acid/acid_style.css.bak Далее копируем все файлы с учётом поддиректорий из директории /progi/acid-0.9.6b23_plugin в директорию, где установлен ACID: /var/www/html/acid: # cp -R /progi/acid-0.9.6b23_plugin/* /var/www/html/acid либо с выводом имени каждого копируемого файла: # cp -Rv /progi/acid-0.9.6b23_plugin/* /var/www/html/acid Далее необходимо подредактировать файл plugin.conf.php, изменив в нём переменную $snortcenter_home таким образом, чтобы она указывала путь к файлам snortcenter. В нашем случае вместо $snortcenter_home = «http://localhost/»; пишем $snortcenter_home = «../snortcenter/»; Следует заметить, что помимо обычного интерфейса к ACID с полными правами мы также создавали интерфейс только для просмотра (см. [4]), соответственно, если это необходимо, все вышеописанные действия следует повторить и по отношению к нему. После установки в результате запуска ACID обычным образом мы получим следующую картинку.
Рисунок 18. Вид ACID после установки SnortCenter ACID Plugin Следует заметить, что так как изменения не коснулись файлов snortcenter, то специальной кнопки по прямому переходу в ACID из него нет. На этом статью можно было бы и закончить, если бы не ряд недостатков, которые не хочется оставлять без внимания. Недостатки Первый из них это то, что если произойдёт перезапуск компьютера-сенсора, на котором запущен snort, то после перезапуска работу snort, как это мы делали ранее, никто не восстановит. Как вариант необходимо вносить изменения в консоль управления SnortCenter, чтобы она умела запускать Snort автоматически и при этом отличала аварийно вставшие сенсоры от специально остановленных. Это может показаться не совсем удобным, несмотря на наличие довольно удобных средств конфигурирования и мониторинга, описанных выше. Решение этой проблемы довольно просто: необходимо, как и ранее, создать файл snortd, поместить его в директорию /etc/rc.d/init.d и сделать на него ссылки из директорий, соответствующих необходимым уровням запуска. Однако в связи с тем, что имена конфигурационных файлов теперь другие, изменится и содержание файла snortd. Например, вместо ранее snort.conf теперь может быть snort.eth0.conf. В принципе эту проблему можно бы было решить путём создания соответствующих мягких ссылок, но сделать это невозможно, так как в некоторых случаях на одном узле может быть запущено несколько демонов snort, прослушивающих разные интерфейсы. Этот случай наиболее неудобный, но не безысходный. Первый способ решения – это правка файла ниже и дублирование строк запуска с разными конфигурациями. Однако этот путь имеет недостатки, а именно все демоны работают или не работают одновременно, как остановить или запустить лишь один из демонов? Написав более сложный скрипт, можно решить и эту проблему. Возможно, в следующих статьях я напишу этот файл и приведу его с комментариями, однако он явно понадобится не всем, да и существует более простое решение, как создание нескольких файлов запуска/останова, каждый из которых будет отвечать только за свою конфигурацию snort. В этом случае просто создаём файлы snortd2, snortd3 и т. д., аналогичные файлу snortd, вносим в них изменения и также делаем необходимые ссылки. Листинг файла snortd.(snortd2, snortd3...): #!/bin/bash # # snortd Start/Stop the snort IDS daemon. # # chkconfig: 2345 79 11 # detection tool that currently detects more than 1100 host # and network vulnerabilities, portscans, backdoors, and more. # # June 10, 2000 -- Dave Wreski # - initial version # # July 08, 2000 Dave Wreski # - added snort user/group # - support for 1.6.2 # Source function library. . /etc/rc.d/init.d/functions # Specify your network interface here INTERFACE=eth0 # See how we were called. case "$1" in start) echo -n "Starting snort: " # ifconfig eth0 up daemon /usr/local/bin/snort -o -i $INTERFACE -d -D -c /etc/snort/snort.$INTERFACE.conf touch /var/lock/subsys/snort sleep 3 if [ -f /var/log/snort/alert ] then rm /var/log/snort/alert fi echo ;; stop) echo -n "Stopping snort: " killproc snort rm -f /var/lock/subsys/snort echo ;; restart) $0 stop $0 start ;; status) status snort ;; *) echo "Usage: $0 {start|stop|restart|status}" exit 1 esac exit 0 Далее следует дать команду: # chkconfig snortd on (# chkconfig snortd2 on) и т. д., чтобы в директориях соответствующих уровней появились символические ссылки на этот файл. Далее следует дать команду: # chkconfig snortd on чтобы в директориях соответствующих уровней появились символические ссылки на этот файл. После этого вышеописанная проблема запуска snort будет решена. Вторым недостатком в работе SnortCenter можно назвать слабые возможности по редактированию правил. Через веб-интерфейс нельзя внести существенные изменения в правила, а также я не заметил возможности удаления правил через веб-интерфейс. Конечно, это не критические недостатки, их можно обойти путём создания своих собственных правил (кстати, свои правила уже удаляются), их активации и деактивации ненужных, но в целом в этом направлении я бы доработал эту программу в будущем. Положительные моменты Помимо отрицательных моментов в работе программы есть и положительные моменты, а именно хорошая «защита от дурака» при создании нерабочеспособных конфигурационных файлов. Система себя ведёт очень хитрым образом, а именно на сенсорах всегда после первого запуска хранятся две конфигурации – основная и резервная. Когда вы загружаете новый файл конфигурации, то перед его запуском система осуществляет тестирование файла конфигурации и параметров запуска с опцией «-T». В случае успешного тестирования происходит запуск Snort с новым файлом конфигурации, а резервный файл конфигурации заменяется текущим. В случае если же тестовый запуск был неуспешным, система выдаёт пользователю сообщение об ошибке и на место неправильного нового файла записывает рабочую резервную копию последнего успешного запуска. И запускает Snort «в предыдущей» конфигурации. Таким образом, даже неумелому администратору будет сложно заставить Snort не работать ошибочными правилами, если он до этого уже работал. Заключение Описанное выше средство конфигурирования и диагностики нескольких сенсоров довольно удобно при создании сети диагностики на базе распределённых сенсоров и представляет собой относительно законченный продукт, однако в описанной выше реализации есть ряд недостатков разной степени важности, которые в будущем следует попытаться решить, если есть потребность в создании надёжной, отказоустойчивой и безопасной системы обнаружения атак. Среди недостатков можно отметить следующие:
В целом это не единственные недостатки данной системы, а лишь основные, которые бросаются сразу в глаза. Многие из них выходят за рамки описанного выше средства, решающего только одну узкую проблему единого хранения файлов конфигурации и диагностики, и затрагивают более широкий спектр средств, обеспечивающих безопасность. Описанные выше проблемы скорее повод для их будущего более глубокого осмысления, решения и последующего описания полученных результатов на страницах журнала. Литература, ссылки:
|
ПАВЕЛ ЗАКЛЯКОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
