Comments
В дополнении скажу, что тема неплохо освещена на Московском MUMе 2018 года от Романа Козлова, также у него на канале есть более подробное видео с вебинара (не воспринимайте за рекламу, просто сам немного интересуюсь данной темой). Посмотрите, может что то новое для себя откроете. Также есть телеграмм канал, можно спросить там по вашим проблемам.
А так статья хорошая, спасибо за труды.
Да, я просмотрел это видео. Мне оно показалось несколько поверхностным, оно скорее как источник вдохновения для реализации такой связки на базе готового решения SELKS. У меня SELKS5 тоже участвовал в ходе поиска решения, но мне его не удалось завести с trafr, видимо, потому что плохо старался). В итоге описанное в моей статье решение лично для меня оказалось более простым и понятным, хотя, как я отметил в заключении, и не лишенным недостатков.
Буквально на неделе завершил (надеюсь) создание стабильной сборки mikrotik + SELKS, трафр не идет на той сборке debian из за отсутствия архитектуры и библиотек (после доставления хорошо работает, оставил tzsp2pcap так как указывал дополнительно порт приема),
на данный момент сборка принимает 400 мбит от порт мирроринга (микротик свитч) и под 100 от сниффера микротика роутера (c виртуального интефейса), суриката смотрит в 2 интерфейса, блеклист микротика заполняется из fast.log suricatы. Дальше дело за farewall.
fare-wall? Ну, удачи!

Вообще, конечно, вопрос — насколько это все эффективно. Не удивительно, что функции файрволла тащат через dpdk в юзер спейс. Либо ставят отдельную коробку. Ибо все задыхается от недостатка производительности
Вы имеете в виду virtual appliance? Если его, то нет.
Если имеете в виду готовое решение, то оно есть, но у меня не заработало по причине, указанной в комментарии выше:
трафр не идет на той сборке debian из за отсутствия архитектуры и библиотек (после доставления хорошо работает<...>)

Я говорю о SELKS.
А виртуализация какая? Оно не умеет, как ESXi, делать promisc-порты в нужном влане? Это позволило бы без trafr обойтись, а напрямую в сурикату копию WAN-трафика WAN отдать.

ESXi и есть. Если бы они были на одном хосте, то задача зеркалирования порта была бы решена силами vSwitch'а, да… Вообще, я сторонник принципа keep it simple, и если задачу можно решить минимумом привлеченных ресурсов, значит так ее и надо решать).

Чего не достаёт:


  • развертывание всего через docker'ы (изоляция сервисов — это прекрасно)
  • или хотя бы разворачивания через ansible (долой копипаст команд!!!)
  • второй" головы" для эластика (в режиме standalone он работает плохо)
  • установки trafr как сервиса (ну, нафига записать тулзу в nohup/screen, если можно написать systemd юнит)
  • настройки параметров джавы (ну, там Хип и пр.)
    Понимаю, что часть этого за скоупом статьи, но мы же делаем всё "по уму", не так ли?

В остальном — большое спасибо, очень интересный опыт.

Вы меня заинтриговали). В чем выражается плохая работа ES, если он один? И что именно нужно подкрутить у джавы, и что будет, если этого не сделать?

Касаемо второго пункта — это прекрасно, но чтобы создать пакет развертывания, сначала нужно, чтобы оно хотя бы заработало после установки ручками, и именно этот процесс я описал).
Кратко. По эластику — он, например, никогда не даст «зелёный» статус кластера в однонодовом режиме.
Ну, как минимум, неаккуратненько. Я уж не говорю про отказоустойчивость, быстродействие и т.п.
Кстати, очень не круто может быть, когда диск на ноде с эластиком будет кончаться место.
По джава — ну, вопрос в том, что несколько сервисов на одной машине будут «давить» друг друга. Попробуйте залить много данных в эластик и сделать «злой» запрос в кибану. Дальше уже всякие xmx, xms и прочая фигня.

Касательно разворачивания. Ну, да, наверное, можно сначала сделать «в черную».
Мне кажется прелесть Сурикаты как раз в работе как IPS, с его-то inline режимом и блокировкой только нежелательного трафика, а блокировать все IP только из за того, что они генерили алерты как-то грубовато.
IDS/NMS это только обнаружение и мониторинг.
IPS это тема для отдельного разговора. И в этом разговоре, разумеется, не будет размахивания шашкой на каждый алерт.

У меня опыт с ELK равен 0, поэтому, возможно вопрос глупый. В куче статей, в том числе и на оф. сайте читал, что чуть ли не абсолютный минимум для Elasticsearch 12 Гб RAM. У вас, я так понимаю, получилось запустить весь стек на 4Гб?

Ну, как-то «получилось запустить» — это громко сказано… Установил и запустил без всякого конфигурирования, оптимизаций и прочего. Все шаги, что я выполнял — в статье. Никаких дополнительных действий не выполнял.
Правда, это не полноценный ELK, ибо Logstash отсутствует, Filebeat отдает данные напрямую в ES.
При этом типичное потребление ресурсов вот такое:
В принципе, можно заставить работать trafr в SELKS5. Для начала:
Скрытый текст
wget http://www.mikrotik.com/download/trafr.tgz
tar -xzf trafr.tgz
sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6:i386
sudo mv trafr /usr/local/bin/

А после этого надо сделать что-то типа:
Скрытый текст
ip link add eth10 type dummy
ip link set eth10 up
/bin/systemctl stop suricata
rm -rf /var/run/suricata.pid
trafr -s | tcpreplay --topspeed -i eth10 - &
/bin/systemctl start suricata

из-под рута. Я больше застрял на том, как сделать, чтобы при перезапуске всё начинало само работать нормально (Debian 9, systemd).
Only those users with full accounts are able to leave comments. Log in, please.