Search
Write a publication
Pull to refresh

Comments 7

Все ушли в 22 году и никого официально не осталось

Привет, Игорь! Зато остались российские поставщики. К примеру, у компании Гарда остался и развивается анализ NetFlow и как раз для продукта класса NTA/NDR для анализа аномалий в трафике.

IPFIX поддерживает анализ трафика на уровне приложений

Генерация + экспорт потоков IPFIX с анализом приложений требует вычислительных ресурсов.
Если включить IPFIX, то анализ трафика может привести к перегрузке CPU и памяти маршрутизаторов и коммутаторов.

Чтобы справиться с нагрузкой у тебя два варианта
1. Использовать мощные устройства с аппаратной поддержкой IPFIX (ASIC, FPGA). Есть ли в России такие?
2. Фильтровать или агрегировать потоки перед отправкой. Но такой путь не дает полной информации о всех потоках приложений .

Денис, привет! )

Чтобы справиться с нагрузкой у тебя два варианта

Оба варианта не очень подходят. Сетевая инфра обычно уже есть и менять ее под решения ИБ - обычно никто так не делает. Фильтровать тоже плохой вариант.

Мне кажется, есть еще один вариант - использовать съемники Flow Probe, которые будут вставать через брокеры или TAP на трафик и условные 100 гигабит трафика превращать в 1 гигабит IPFIX в сторону Flow Collector.

На большом трафике *flow как правило семплированный. И, чем больше трафика, тем сильнее поднимают sampling rate. На терабитных сетях можно увидеть 1:10000 или даже 1:64000.

Чем выше эта частота, тем меньше можно в трафике чего-то увидеть. Ну, да, крупный DoS/DDoS видно, грубо видно разбивку трафика по GeoIP/AS. Обычно операторы используют *flow только для этого.

Причем, частоту повышают не только для того чтобы разгрузить сетевое железо, но и потому что обрабатывающий софт (*flow-коллекторы/анализаторы) захлебывается.

AI/ML пытаются прикрутить к анализаторам уже давно, еще до последнего AI-хайпа. Пока никаких особо хороших результатов никто не показал.

Я участвую в разработке опенсорсного Netflow/IPFIX/sFlow анализатора https://github.com/vmxdev/xenoeye/, кроме довольно тупой статистики (временные ряды, окна фиксированного размера, скользящие средние) мы ничего не придумали. Можно парсить кусочки пакетов из sFlow, извлекать из них какую-то информацию, мы читаем DNS иTLS(HTTPS) SNI.

Подавляющее большинство и коммерческих, и опенсорсных анализаторов дальше этого не продвигаются. Разве что в GenieATM (они, кстати, не ушли из РФ) есть интересная фича - они следят за энтропией (адресов, протоколов, портов). Может быть мы эту фичу позаимствуем, если получится придумать, как это нормально реализовать.

Пошел изучать вашу документацию, потому что мысли у меня в эту сторону. Но не для операторского уровня, а для сетей предприятий, для анализа внутреннего трафика(горизонтального).

А с помощью AI/ML пробовали пытаться детектить приложения в шифрованном трафике? По совокупности заголовков, длины пакетов, задержек между пакетами?

>для сетей предприятий, для анализа внутреннего трафика

Ничего в этом не понимаю, даже не знаю зачем на предприятиях следят за внутренним трафиком.

Из общих соображений, если нужно фильтровать что-то, тем более быстро (netflow/IPFIX отдает статистику с существенной задержкой, в зависимости от настроек железа до нескольких десятков секунд), то лучше стоять в inline.

>с помощью AI/ML пробовали пытаться детектить приложения в шифрованном трафике?

Постоянно натыкаюсь на статьи, в которых тренируют роботов и что-то детектируют по netflow. Как это работает вживую, на настоящем трафике - не видел ни разу.

Теоретически можно что-то детектировать по TLS Hello (они идут не зашифрованные). Есть несколько проектов, которые детектируют таким образом ботов и прочую нежелательную активность. Например https://github.com/FoxIO-LLC/ja4

К netflow это никак не прикрутить, нужен сырой трафик. Или хотя бы кусочки пакетов (sFlow, IPFIX 315).

>По совокупности заголовков, длины пакетов, задержек между пакетами?

У нас трафик в 99% случаев семплированный, там ничего такого не видно. Даже на таймстампы фловов не смотрим, это довольно бессмысленно.

Какие сенсоры рекомендуете использовать на Linux-сервере с трафиком 20/40/100 Gbit/s? Желательно opensource решения.

У нас нет софтроутеров. Ничего не могу сказать.

Иногда вижу статьи про ipt_netflow (и про то, что его сборка ломается на новых ядрах).

На таких скоростях я бы пытался снимать sFlow с коммутатора, если он умеет.

Если не умет, то поискал бы готовый XDP sFlow сенсор. Хотя, сейчас бегло погуглил и ничего такого не увидел. Это, конечно, странно.

Немного ковырялся с этим XDP, вроде должно быть не очень сложно сделать простенький sFlow-сенсор.

Но про сенсор на XDP это я теоретизирую, на больших скоростях его не видел, может быть на 100Gbe он даже не простых программах будет не быстро работать.

Sign up to leave a comment.

Articles