Pull to refresh

Comments 17

В дополнении скажу, что тема неплохо освещена на Московском 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).
Sign up to leave a comment.

Articles