ITСooky

Snorby пока еще не работает видим ошибку
The Snorby worker is not currently running.

Ошибка известная еще в 2011 году обещали скоро исправить!
Создаем скрипт, в журнале предлагает bash скрипт который и сам по себе с ошибками и не работает так как надо!

Вообще как то с bash у меня не сложилось, нужен мне был язык который заменяет глаза и руки админа - ну тоесть выполнил команду - вижу что какое то значение столько - значит надо сделать то-то. И вот это я нашел в Expect

Устанавливаем
cd /usr/ports/lang/expect
make
make install

пишем
vi /root/run_snorby_WP
вставляем

#!/usr/local/bin/expect -f
set timeout 1000
spawn /bin/ps aux
expect "delayed_job" {
exit
}
cd /usr/local/www/snorby
spawn /usr/local/bin/ruby ./script/delayed_job start RAILS_ENV=production
expect "ERROR: there is already one or more instance(s) of the program running" {
cd /usr/local/www/snorby
system /usr/local/bin/ruby ./script/delayed_job restart RAILS_ENV=production
}
exit

UPD: Второй вариант чтобы заставить Snorby обновлять графики!
Но скорее всего у вас как и уменя Snorby все равно не будет обновлять графики и ни что из фебинтерфейса заставить его это сделать не сможет.

Чтобы это исправить прикручиваем следующий костыль!
пишем
vi /root/run_snorby_WP2
вставляем

#!/usr/local/bin/expect -f
set timeout -1
log_user 0
#exp_internal 1
set mysqlpass none
spawn /usr/bin/sed -n "s/^.*password\: \"\\(.*\\)\".*/\\1/p" /usr/local/www/snorby/config/database.yml
#spawn /usr/bin/sed -n "/Mysql/{n\;n\;p\;}" /root/dp
expect "\[a-z,A-z,0-9]*" {
set mysqlpass $expect_out(buffer)
}
interact
spawn /usr/local/bin/mysql -u snort -p
expect "Enter password:" {
send "$mysqlpass\n"}
expect "mysql>" {
send "use snorby;\n"}
expect "Database changed" {
send "TRUNCATE TABLE caches;\n"}
expect "Query OK" {
send "exit\n"}
set killid 0
spawn /bin/ps aux
expect "delayed_job" {
set killid 1
}
if $killid==0 {
catch {system cd /usr/local/www/snorby\;/usr/local/bin/ruby /usr/local/www/snorby/script/delayed_job start RAILS_ENV=production}
catch {system cd /usr/local/www/snorby\;/usr/local/bin/rails runner \"Snorby\:\:Jobs\:\:SensorCacheJob.new\(false\).perform\;\"}
catch {system cd /usr/local/www/snorby\;/usr/local/bin/rails runner \"Snorby\:\:Jobs\:\:DailyCacheJob.new\(false\).perform\;\"}
} else  {
system cd /usr/local/www/snorby
catch {system cd /usr/local/www/snorby\;/usr/local/bin/ruby /usr/local/www/snorby/script/delayed_job restart RAILS_ENV=production}
catch {system cd /usr/local/www/snorby\;/usr/local/bin/rails runner \"Snorby\:\:Jobs\:\:SensorCacheJob.new\(false\).perform\;\"}
catch {system cd /usr/local/www/snorby\;/usr/local/bin/rails runner \"Snorby\:\:Jobs\:\:DailyCacheJob.new\(false\).perform\;\"}
}
exit

Этот скрипт берет пароль пользователя Snorby к базе MySQL, заходит сбрасывает caches и перезапускает рабочий процесс Snorby.

НО! Скрипт (хотя я думаю это все из-за Snorby) не всегда кульминируетца запуском того что нужно - вот нет! И тут пригодится первый скрипт!
В crontab вот такая конструкция которая гарантирует обновление Snorby, раз в час с гарантией 66,666666666666666666666%

50 * * * * /usr/local/bin/expect -f /root/run_snorby_WP2 >/dev/null 2>&1

Сам перезапуск длится мянут пять!

вручную можно запустить процесс так
expect /root/run_snorby_WP

убить можно посмотрев какой у него ID (или у них, их два)
ps aux | grep -v "grep" | grep delayed_job

root     1420   0.0  6.8  94668  69632 ??  S     1:05PM  0:02.52 ruby: delayed_job (ruby)

и
kill 1420

Вставляем в crontab
crontab -e
строку чтобы проверялся(на 50-ой минуте, каждого часа) запущенли и на загрузке

50 * * * * /usr/local/bin/expect -f /root/run_snorby_WP >/dev/null 2>&1
@reboot /usr/local/bin/expect -f /root/run_snorby_WP >/dev/null 2>&1

И так для чистоты диагностики перезагрузимся!!!

Минут через 5-10 все что нужно и пошла информацияяя

Информация обновляется раз в 7 минут(почему-то)!
За одну секунду набралось 30000 желтых, пакеты они такие летают со скростью близкой к скорости света!

Можно посмотреть совершенно полнейшею информацию по совершенно не понтяному почему в легкой степени не хорошему пойманому трафику!

Snorby тупит! Иногда он перестает сам обновлять информацию, вы заходите в него, а события только за прошлую неделю, хотя они в базе есть... Разрабы Snorby решили эту проблему добавили кнопку More optiones > Force cache update

ВНИМАНИЕ: Snorby опять остановился, на это раз это не остановка Snort, не самоубийство процесса delayed_job он запушен... Это просто он не хочет обновить данные, если вы не видете последних данные, а знаете что они есть(да они даже в его Events видны) но на графике их нет, нажимайте More optiones > Force cache update! Делать это придется не каждый раз, но постоянно!

Все больше укрепляюсь в мысли, что Snorby - параша. Ведь выж с сами прикиньте, что от него требуется - прочитать базу MySQL - в которую усилиями snort и barnyard2 уже положены записи о событиях. И будь Snorby написан на каком-нибудь PHP проблем вообще бы с этим не было, но он на ruby on rails он какие-то процессы хочет, не можети, запустить чтобы что? ЧТОБЫ ПРОСТО ПРОЧИТАТЬ БАЗУ!!! Нет достопочимые господа, порашас она и есть параша!

UPD: Нерешенная проблема По моему мнению, большой объем ингформации из-за правила stream5: TCP session without 3-way handshake в купе с глючностью всего подвешивает работу всего IDS!!! Хотелось бы еще отключить собтыие stream5: TCP session without 3-way handshake но я не нашел где как!

Всё! Ставим SnortSAM
Снортсам скорее мертв чем жив, мертв сайт и все старые способы его установки и работы. Но вот есть подсказка, бесценная раньше он работал через Snort сейчас через Barnyard2 README.snortsam она и спасает!

Устанавливаем!
cd /usr/ports/security/snortsam/
make
По умолчанию, главное чтобы галочка была на IPFW

Тут установка ругается говорит не может скачать нужный файл, такое бывает, и главное говорит какой файл. Делаем руками, скачиваем у Никалая Эрнестовича, ему можно доверять он проверенный товарищ.
cd /usr/ports/distfiles/
fetch http://val.bmstu.ru/unix/snort/snortsam-src-2.70.tar.gz
Возврашаемся
cd /usr/ports/security/snortsam/
make
make install
Копируем файл настроек из примера
cp /usr/local/etc/snortsam/snortsam.conf.sample /usr/local/etc/snortsam/snortsam.conf
он большой и весь закоменченный, редактируем
vi /usr/local/etc/snortsam/snortsam.conf
открываем и меняем строки

defaultkey pAs$VV0roI

тут пишем ключ с которым Снорт будет подключаться

port 898

тут пишем порт на котором он будет слушать (он должен быть свободен)

accept 127.0.0.1

тут прописываем от кого принимать команды на блокировку, пароль будет поумолчанию заданные выше

dontblock <host>/<mask>
dontunblock <host>/<mask>

хорошие строки кого никогда не блокировать и кого никогда не разблокировать(единожды заблокировав так надо это понимать?)

много там таких полезных настроек
system /usr/local/bin/rails runner "Snorby::Jobs::SensorCacheJob.new\\(false\\).perform;Snorby::Jobs::DailyCacheJob.new\\(false\\).perform;"

logfile snortsam.log

имя лог файла, в таком виде будет писаться в /root/ директорию
так что правим на

logfile /var/log/snortsam.log

loglevel 2

да так

fwexec /sbin/ipfw

путь к нашему файрволу

ipfw2 em0 1 2

пишем так чтобы слушал и блокировал на внешнем интерфейсе em0.

В ipfw добавляем правило повыше
vi /etc/rc.firewall
такое

${FwCMD} add deny ip from any to "table(1)" via em0
${FwCMD} add deny ip from "table(2)" to any via em0

Теперь правим Barnyard2 раньше надо было тоже самое писать в Snort но это осталось в прошлом!
vi /usr/local/etc/barnyard2.conf

Добавляем в самом конце

output alert_fwsam: 127.0.0.1:898/pAs$VV0roI

В rc.conf не ставим
snortsam_enable="YES"
я подчеркиваю НЕ СТАВИМ, а то сервер не загрузится!

Добавим в
crontab -e
строку

@reboot /usr/local/sbin/snortsam  >/dev/null 2>&1

И возьмемка и перегрузим Сервер чтобы перезагрузить всея.

Создадим файл с нашим тестовым правилом
vi /usr/local/etc/snort/rules/local.rules/test.rules
в него добавим строку

alert tcp 192.168.1.200 any -> 192.168.1.100 any (msg:"TEST block localserver port 80"; sid:5555501; rev:1; priority:1;)

rev это версия правила, если её вообще не писать то правило работать не будет.

priority 1 это страшность это правило будет красным!

Когда пишем правило помним что блокируется трафик проходящий через шлюз, а собственно локальная сеть если IP в одной маске то они общаются напрямую без шлюза! То есть дискриминация применима к трафику на внешние сети! (при этом шлюз слышит весь внутренний трафик конечно же, и который не через него)

И еще snort слушает на внешнем интерфейсе em0(192.168.1.200), и как бы за NAT тоесть для него все локальные запросы видны как с 192.168.1.200, под это и пишем правило!

В snort.conf пишем строчку

include $RULE_PATH/local.rules/test.rules

Проверяем наше правило (всмысле все сразу но и новое правило тоже)
snort -T -c /usr/local/etc/snort/snort.conf
Хорошо если не ругается

В тойже папке где лежит barnyard2.conf создаем файл sid-block.map
vi /usr/local/etc/sid-block.map

а туда вставлем строчку с SID направлением и временем блокировки

5555501: dst, 10 min

это значит что мы 192.168.1.200 блокируем доступ на 192.168.1.4 (если тут писать src то заблокируется наоброт и ничего не даст)

Перезапускаем Snort и Barnyard2
/usr/local/bin/snort restart
Не срабатывает, ну и хрен с ним, перегружу сервер целиком

Пытаемся зайти на 192.168.1.4 он может даже открыться но пройдет пару секунд и!

ERROR
The requested URL could not be retrieved

While trying to retrieve the URL: http://192.168.1.4/

The following error was encountered:

    Connection to Failed 

The system returned:

    (13) Permission denied

The remote host or network may be down. Please try the request again.

Your cache administrator is webmaster.
Generated Sun, 22 Jun 2014 12:08:09 GMT by localhost.ITCookoy_VPS (squid/2.7.STABLE9) 

Смотрим Snorby собщает о красном случае под названием Snort Alert [1:5555501:1]

Посмотрим заблокировали ли нас в файрволе IPFW
ipfw -i table 1 list

192.168.1.4/32 0.0.0.0

ipfw -i table 2 list

192.168.1.4/32 0.0.0.0

Ура, правило сработало, блокировка сработала!!!

Но это не все надо теперь со всеми красными правилам от snort полученных автоматом по апдейту сделать тоже самое...
...хотя нет всё!!! Установка завершена!!! Готового способа сгенерировать sid-block.map нет, а придумывать это не на одну неделю задача (надо еще это привезать к обновлению правил oinkmaster)

UPD: Удалось! Пройти ад регулярных выражений и - автоматически сгенерировать файл блокировок sid-block.map для snortsam!

Регулярное выражение словами хватаем строку:
^[^\#] - которая не начинается с #
.*sid: - любая белеберда в строке слева на право, которая содержит sid:
(.[0-9]*[0-9]\) - как я понял () это то что мы хватаем, а [0-9]*[0-9] любое последовательное количество цифр
.* - билерда на конце
дальше то что касается sed
s// - оператор какойто связанный с записью
который записывает \1":" "src," "30min"/p"
\1 - то что мы поймали раньше
":" "src," "30min" - текст который мы к нему прикрепляем, тут внутри ковычек вот эти ковычки " " задают пробел
\p - это переход на новую строку энтер

Далее пишем пути к файлам, через пробел, выбирал по страшности название, многие бесплатно полученные файлы пусты, другие в правилах содержать URL не знаю подходят ли они для блокировки через IPFW. Тут в конце тестовые правила для симуляции red alert - в реальности его не дождешься!

Также не берусь судить стоит ли все эти правила блокировать по src

sed -n "\%^[^\#].*sid:\(.[0-9]*[0-9]\).*% s//\1":" "src," "30min"/p" /usr/local/etc/snort/rules/backdoor.rules /usr/local/etc/snort/rules/bad-traffic.rules /usr/local/etc/snort/rules/black_list.rules /usr/local/etc/snort/rules/botnet-cnc.rules /usr/local/etc/snort/rules/ddos.rules /usr/local/etc/snort/rules/exploit-kit.rules /usr/local/etc/snort/rules/exploit.rules /usr/local/etc/snort/rules/blacklist.rules /usr/local/etc/snort/rules/malware-backdoor.rules  /usr/local/etc/snort/rules/malware-cnc.rules /usr/local/etc/snort/rules/malware-other.rules /usr/local/etc/snort/rules/malware-tools.rules /usr/local/etc/snort/rules/phishing-spam.rules /usr/local/etc/snort/rules/policy-spam.rules /usr/local/etc/snort/rules/spyware-put.rules /usr/local/etc/snort/rules/virus.rules /usr/local/etc/snort/rules/web-attacks.rules /usr/local/etc/snort/rules/local.rules/test.rules >  /usr/local/etc/sid-block.map

Перезагружаем Barnyard2 как-нибудь...красивого способа не вижу!
Выясняем номер его процесса
ps aux | grep barnyard2

root     1268   0.0  0.5  18632   5140 ??  Ss   12:32PM 0:00.40 /usr/local/bin/barnyard2 -Dn -c /usr/local/e

Убиваем его
kill 1268
И опять стартуем
/usr/local/bin/barnyard2 -Dn -c /usr/local/etc/barnyard2.conf -d /var/log/snort -f snort.log

UPD: Автоматизируем всё! Обновление правил с сайта Snort и обновление затем что блакировать! Так как с первым справляется oinkmaster, то займемся вторым!

Для начала разделим правила которые надо блокировать по src(источник запроса), и dst (пункт назначения)!
В бесплатных правилах много пустых правил, так что из тех что есть...ммм

Бесплатные правила похоже бесполезны чуть менее чем совсем! Или я не понял что они призваны блокировать? Всю сеть если кто-то просканировал такой порт, я то надеялся что SNort умеет знать источники атак? Ну да ладно, мне главное написать скрипт автоматизации - создать идеальные правила безопасности такой задачи не стоит!

Так как многие правила безопасности пустые то я придумаю два файла правил:
/tmp/test/blocksrc.rules - блокирует источник опасности
/tmp/test/blockdst.rules - блокирует пункт назначения опасности

У нас будут две команды sed

удаляет старый файл вставляет в него все записи по новой из файла blocksrc.rules блокирует по src

sed -n "\%^[^\#].*sid:\(.[0-9]*[0-9]\).*% s//\1":" "src," "30min"/p" /tmp/test/blocksrc.rules >  /tmp/test/sid-block.map

добавляет в уже созданный файл записи блокирующие по dst

sed -n "\%^[^\#].*sid:\(.[0-9]*[0-9]\).*% s//\1":" "dst," "30min"/p" /tmp/test/blockdst.rules > /tmp/test/sbd_tmp.map

Мне не удалось заставить sed дописать в первый файл блокировки dst, так что третей командой склеиваем два файла

cat /tmp/test/sbd_tmp.map >> /tmp/test/sid-block.map

Итого в crontb
crontab -e
Модифицируем запись oinkmaster чтобы он по его окончании выполнял пересборн файл блокировок и перезагрузку barnyard2

30 5 * * * /usr/local/bin/oinkmaster -o /usr/local/etc/snort/rules/&&/usr/bin/sed -n "\%^[^\#].*sid:\(.[0-9]*[0-9]\).*% s//\1":" "src," "30min"/p" /tmp/test/blocksrc.rules >  /tmp/test/sid-block.map&&/usr/bin/sed -n "\%^[^\#].*sid:\(.[0-9]*[0-9]\).*% s//\1":" "dst," "30min"/p" /tmp/test/blockdst.rules > /tmp/test/sbd_tmp.map&&/bin/cat /tmp/test/sbd_tmp.map >> /tmp/test/sid-block.map&&/bin/ps aux | /usr/bin/grep -v "grep" | /usr/bin/grep /usr/local/bin/barnyard2 | /usr/bin/awk '{print $2}' | /usr/bin/xargs kill&&/usr/local/bin/barnyard2 -Dn -c /usr/local/etc/barnyard2.conf -d /var/log/snort -f snort.log >/dev/null 2>&1

UPD: Для этой системы требутся ресурсы, потому что совершенно неожиданные моменты могут создать кучу трафика Snort его честно и быстро засунет в файлы своего лога, а Barnyard2 вместе с MySQL будет по полчаса вытаскивать!

Вот например за две минуты Snort родил 200 мегабайт трафика, а Barnyard2 (сижу на него смотрю) запихивает уже сорок минут в MySQL и это на виртуальной машине с харками Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz с 2 GB RAM выделено два ядра 60% и 1 Gb! Что выразилось в падение скорости интернета для полдьзователей на этом шлюзе, даже не падения а они стали долго ждать открытия страницы, хотя после ожидания открывается быстро. НО нагрузка на Barnyard2 невлияет на блокировку, он такая же быстра (со второго зловредного запроса, с первого не успевает, пока воткнет)

Зато можно посмотреть кто создал чудовищный трафик:
это vk.com/widget_like.php пока насчитано 92 тысячи мусорных запросов

Немного беспокоит что взрыв трафика произошел на планшете под Android, в момент открытия сайта где есть виджет лайкнуть вконтакте и он наверняка повторится...

UPD: Экспорт отчетов snorby в PDF
Идем за конвертором
cd /usr/ports/converters/wkhtmltopdf
и ставим
make
make install
И это всё. В PDF будет все что на графиках (как способ получать более точную и актуальную инфу значит не подойдет). Красиво выглядит, из минусов только странный формат не A4!

Рубрика IT Рецепты

7 комментариев to “Установка на FreeBSD 9 системы анализа Snort и блокировки SnortSAM зловредного трафика!”

1. Jamal:

   26.10.2014 в 17:38

   Respekt Avtoru.
   Oqromnoe vam spasibo za prekrasniy dokument

   Ответить
2. Jamal:

   29.10.2014 в 16:44

   Tolko barnyard v daemon rejime rabotaet

   I on padaet lish v tom sluchae koqda, ne mojet chitat novie logi ot /var/log/snort

   I za etoqo ya sozdal novoqo polzovatelya snort i barny i i dobavil v cron nijnyuyu stroku ivse.

   # Snort logs chown
   */1 * * * * root chown -R barny:snort /var/log/snort

   Ответить
   • AlexandrBu:

     31.10.2014 в 19:49

     U menya na ne padanie povlialo otkluchenie ochistki logov v snorby…

     Ответить
     • Jamal:

       31.10.2014 в 19:58

       A vi ne Planiruete zdelat toje samoe na Suricata?

       Ответить
       • AlexandrBu:

         31.10.2014 в 20:03

         Net, y kak ya ponyal eto ne OS a uzhe IDS multyplatformenniy http://suricata-ids.org/features/all-features/

         Ответить
         • Jamal:

           31.10.2014 в 20:19

           Konechno on i v IPS rejime rabotaet i mojet chitat rule-i ot Snort. Ya eqo nastraival cherez divert.

         • Jamal:

           31.10.2014 в 20:23

           On budushee Snort-a i silno razvivaetsya