Комментарии 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 он даже не простых программах будет не быстро работать.
IPFIX с точки зрения информационной безопасности