 |
|
|
|
MRTG + Snort
MRTG + Snort «Лучше один раз увидеть, чем сто раз услышать» гласит пословица. Многие вещи мы лучше понимаем, представляем и запоминаем, если видели их собственными глазами. При этом не всякое нами увиденное воспринимается одинаково хорошо. Очень сильно на процесс восприятия влияет наглядность. В этой статье будет рассмотрен именно такой вариант отображения данных об интенсивности атак, регистрируемых с помощью Snort. В качестве средства отображения используется MRTG. Предполагается, что имеется СОА Snort, данные с одного или нескольких сенсоров которой заносятся в БД инцидентов. Необходимо организовать визуальное отображение среднего уровня атак в зависимости от времени. Для отображения удобнее всего использовать штатное средство большинства Linux-систем – MRTG (The Multi Router Traffic Grapher) [1, 2 стр. 52-53, 3 стр. 316, 4 стр. 208-216]. Предполагается, что MRTG у вас уже установлен. Рассмотрим его настройку. Конфигурационный файл MRTG обычно называется mrtg.cfg и находится в директории /etc/mrtg. Нам необходимо отредактировать или создать заново этот файл, добавив туда следующие строки: mrtg.cfg # Рабочая директория mrtg, где создаются поддиректории для отчётов, обычно она уже указана WorkDir: /var/www/html/mrtg # Выбор языка – вносит в заголовок html-cтроку с CONTENT="text/html; charset=koi8-r" и локализует html-файлы создаваемых отчётов Language: russian # Внешний файл, который будет являться источником данных для mrtg, записывается в обратных кавычках Target[snort]:`/etc/mrtg/snort_stat.pl` # Максимальное число атак в единицу времени. Значения выше игнорируются, нужно больше для наглядности MaxBytes[snort]: 2000 AbsMax[snort]: 2000 # Заголовок окна браузера, тег в html Title[snort]: Статистика атак (данные Snort) # Заголовок страницы с графиками PageTop[snort]: <H1>Статистика атак (данные Snort)</H1> # Поддиректория в WorkDir, где будут создаваться отчёты Directory[snort]: snort # Размер графиков по ширине в точках XSize[snort]: 600 # Размер графиков по высоте в точках YSize[snort]: 160 # Подпись графиков по оси ординат YLegend[snort]: Attacks per minute # Подпись легенды, пояснение, что именно за график нарисован таким-то цветом.(Необходимо, чтобы не запутаться, когда графиков несколько) Legend1[snort]: Число атак в минуту # Убрать лишнюю информацию LegendI[snort]: LegendO[snort]: # Задать направление рисования графиков и что значения, выдаваемые программой, указанной в Target, являются абсолютными Options[snort]: absolute, growright # Подпись единиц измерения атак ShortLegend[snort]: атак/мин После того как внесена правка в конфигурационный файл mrtg.cfg, необходимо создать файл, на который мы сделали ссылку в поле Target[snort]: /etc/mrtg/snort_stat.pl. Этот файл будет запускаться по запросу mrtg, и он должен подключаться к БД snort и подсчитывать число атак, например за последние 5 минут, после чего выдавать это значение в требуемом mrtg формате. Реализовать данную идею возможно с помощью следующего SQL-запроса: SELECT count(timestamp) FROM event WHERE unix_timestamp(now())-unix_timestamp(timestamp)<300 который фактически является основным ядром нижеследующего perl-скрипта, который лишь осуществляет автоматизацию процесса подключения и работы с БД и выводит результат в нужном формате. Перед созданием скрипта убедимся, что данный запрос работает правильно, подключившись к БД из консоли от имени пользователя snort. Выполним подключение командой: # mysql -u snort -p введя после соответствующий пароль, если он был задан. Далее выберем БД snort командой: mysql> USE snort; и выполним вышеописанный SQL-запрос. В результате на экране у вас может быть примерно следующее:
Если БД с инцидентами у вас достаточно большая, то запрос может выполняться несколько десятков секунд. Убедившись, что число строк в таблице event, время которых лежит в интервале последних 300 секунд, считается правильно, создадим файл snort_stat.pl в директории /etc/mrtg, который будет выполнять все проделанные нами действия в автоматическом режиме. Подробнее о создании подобных скриптов можно прочитать в [7, 8]. Файл snort_stat.pl #!/usr/bin/perl # Файл, выдающий число атак за последние 300 секунд use DBI; # Хост, где запущена БД MySQL $hostname="адрес_хоста_MySQL_с_БД_snort"; # Порт, на котором запущена БД MySQL $port="3306"; # Имя пользователя, от которого подключаться к БД $user="snort"; # Пароль пользователя, указанного выше $password="пароль_подключения_к_БД"; # Имя БД, к которой осуществляется подключение $database="snort"; # Подключиться к БД $dbh = DBI->connect("DBI:mysql:$database:$hostname:$port", $user,$password); # Подготовить SQL-запрос, выполняющий подсчёт числа атак за последние 300 секунд на выполнение $sth = $dbh->prepare("SELECT count(timestamp) FROM event WHERE unix_timestamp(now())-unix_timestamp(timestamp)<300"); # Выполнить запрос $sth->execute; # Результат выполненного ранее запроса поместить в массив ref @ref = $sth->fetchrow_array; # Вывести полученное в результате запроса значение print $ref[0]," "; # Завершить работу с БД и отключиться от неё. $rc = $sth->finish; $rc = $dbh->disconnect; # Вывести дополнительные значения, необходимые для соблюдения формата передачи данных в mrtg print "0 "; print "0 "; print "snort "; Соответствующие параметры: адреса MySQL-сервера и пр. следует задать самостоятельно, в зависимости от вашей конфигурации. Следует отметить, что сам скрипт и БД могут быть разнесены и выполняться на разных компьютерах, если вы запускаете скрипт на том же самом компьютере, где находится БД, что наиболее вероятно, то без сомнения можно использовать значение «localhost». После указания в файле правильных значений необходимо придать файлу атрибут запускаемости следующей командой: # chmod +x /etc/mrtg/snort_stat.pl Далее, для того чтобы данный сценарий работал без ошибок, перед его тестовым запуском необходимо убедиться в том, что в системе установлен не только сам perl по тому адресу, что указан в первой строчке, который будет выполнять написанный нами скрипт, но и его пакеты-расширения, позволяющие ему взаимодействовать с БД. Это perl-DBD-MySQL и perl-DBI. Проверить их наличие можно командой: # rpm -qa|grep perl которая выдаст имена всех пакетов в вашей системе, в которых содержится слово perl. В случае отсутствия двух вышеуказанных пакетов, содержащих необходимые нам для работы perl-модули, следует установить их, например для RedHat v.7.3, командами: # rpm -ihv perl-DBI-1.21-1.i386.rpm # rpm -ihv perl-DBD-MySQL-1.2219-6.i386.rpm (Эти rpm-пакеты с модулями можно найти на втором и третьем компакт-дисках соответственно.) В случае если система обнаружения атак у вас работает и регистрирует атаки, запустив данный скрипт вручную, при правильной его работе вы сможете увидеть примерно следующий результат в виде четырёх строк.
Первая цифра – число атак за последние 5 минут, следует заметить, что она может отличаться от той цифры, что была выдана при ручном вводе соответствующего SQL-запроса ранее, так как время не стоит на месте, то пятиминутные интервалы, в промежутке которых осуществляется подсчёт, будут разные для разных моментов запуска. В случае отсутствия атак первая цифра будет 0. Три последующие строки меняться не будут, что легко заметить из последних строчек выводящего их скрипта. Нужны они лишь для того, чтобы правильно работал mrtg и не ругался. Так как чаще всего mrtg работает с маршрутизаторами, то на месте этих строчек оказываются не пустые значения, а значения входящего и исходящего трафика, uptime соответствующего устройства и его имя. После того как как мы убедились, что скрипт работает, можно запустить mrtg. Первые три раза лучше это сделать вручную, так как директория snort к моменту запуска скорее всего будет отсутствовать со всем её будущим содержимым, то в первые два раза будет выдано сообщение о создании директории, и будут выданы сообщения об ошибках. Mrtg будет жаловаться на то, что отсутствует log-файл, где хранятся данные и отсутствует его резервная копия. Третий раз запуск программы должен пройти тихо, без выдачи каких-либо сообщений об ошибках. Если это так, то можно смело переходить к автоматизации процесса запуска mrtg. Если бы мы сразу решили автоматизировать запуск, то эти и, возможно, другие сообщения об ошибках могли бы оказаться в log-файлах вашей системы, что усложнило бы процесс отладки и поиска возможных ошибок. Дополнительно убедиться в правильности работы mrtg можно, изучив содержимое директории /var/www/html/mrtg/snort командой: # ls /var/www/html/mrtg/snort Там должны быть 7 файлов:
Процесс автоматизации запуска mrtg возможно организовать двумя путями: запускать mrtg в виде демона один раз из стартовых скриптов, например из /etc/rc.d/rc.local, указав дополнительно соответствующий параметр в файле конфигурации, либо запускать с помощью демона crond. Второй вариант мне нравится больше. Для его реализации необходимо в файле /etc/crontab прописать следующие две строчки:
Строка-комментарий никакой смысловой нагрузки не несёт, кроме того, что это правила хорошего тона, пояснять все записи в crontab-файлах, да и потом в случае чего проще будет разобраться. Сообщения от mrtg лучше вести в отдельный файл /var/log/mrtg.log, дабы не замусоривать и так перегруженный /var/log/messages, хотя это не обязательно. MRTG лучше запускать раз в пять минут (запись 0-59/5), каждого часа, каждого дня месяца, каждого месяца в любой день недели (оставшиеся четыре *). Подробнее про синтаксис и процесс автоматизации см. [9 стр.34-38]. В случае если вы будете запускать его чаще или реже, следует изменить и скрипт, подсчитывающий значение числа атак, заменив там соответствующее 5 минутам значение в 300 секунд. После того как добавлены эти строчки, можно считать, что работа по настройке закончена, и если у вас, как и положено, запущен демон crond, то всё будет работать. И уже через несколько часов можно будет наблюдать не совсем пустые гистограммы. В случае если у вас запущен веб-сервер, просмотрите любым графическим браузером файл http://yourserver/mrtg/snort/snort.html, либо файл /var/www/html/mrtg/snort/snort.html локально в противном случае. В результате вы увидите картинку, подобную нижеследующей:
После того как, казалось бы, всё рассказано и показано, хочется сделать пару замечаний. Первое касается точности построения графиков. Как легко заметить, для запуска используется демон crond, который запускается после указанного времени, когда не только загрузка системы позволит это сделать, но и будет ниже определённой. В результате следует понимать, что запуск происходит не точно каждые 5 минут. Если будет запоздание, то скрипт, подсчитывающий атаки, запустится позже, в результате его пятиминутный интервал не перекроется с предыдущим и будет дырка, то есть часть атак не будет подсчитано. Если же после «запоздавшего» задания следующее будет вовремя, то произойдёт перекрытие и некоторые атаки будут подсчитаны дважды. Для систем с грубой оценкой это не важно, так как отклонения эти не большие и примерно компенсируются и не накапливаются в силу случайно флуктуирующего числа атак в единицу времени. Для более точных оценок данный метод следует корректировать. Именно по причине грубости данного метода я не вижу смысла запускать mrtg чаще чем раз в 5 минут. Второе замечание касается подсчёта числа атак в единицу времени при построении графика. В случае если по каким-то причинам придётся запускать mrtg в разные интервалы времени, то, возможно, вам пригодится следующая информация. Сейчас, когда запускается mrtg то, так как в Options указано слово absolute, осуществляется деление переданного значения от скрипта на время, равное разнице между текущим запуском mrtg и предыдущим. Это время приблизительно равно 300 секундам и там, и там, поэтому получается примерно точно. Однако если по каким-то причинам с момента последнего запуска mrtg прошло другое количество времени, то как легко предположить, среднее число атак будет подсчитано неправильно. Несколько исправить ситуацию может использование опции gauge вместо absolute, но не всегда. Если указана опция gauge, то значение не делится на интервал времени, а принимается равным тому, что передали. Соответственно, для правильного подсчёта и отображения в скрипте snort_stat.pl необходимо будет делить выводимое значение на 5. Этот способ подсчёта также является грубым, но может помочь вам несколько уменьшить ошибку, поменяв правила её подсчёта. Литература, ссылки:
|
ПАВЕЛ ЗАКЛЯКОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
