Нужно, чтобы sFlow (наверное, он, если flow с коммутаторов) как-то попал в контейнер. Я не очень в Proxmox, но из общих соображений нужно пробросить порт sFlow (скорее всего, UDP 6343) из хоста в контейнер.
Потом, когда трафик придет в коллектор, нужно настроить его так же, как и LXC
Иногда вижу статьи про ipt_netflow (и про то, что его сборка ломается на новых ядрах).
На таких скоростях я бы пытался снимать sFlow с коммутатора, если он умеет.
Если не умет, то поискал бы готовый XDP sFlow сенсор. Хотя, сейчас бегло погуглил и ничего такого не увидел. Это, конечно, странно.
Немного ковырялся с этим XDP, вроде должно быть не очень сложно сделать простенький sFlow-сенсор.
Но про сенсор на XDP это я теоретизирую, на больших скоростях его не видел, может быть на 100Gbe он даже не простых программах будет не быстро работать.
>для сетей предприятий, для анализа внутреннего трафика
Ничего в этом не понимаю, даже не знаю зачем на предприятиях следят за внутренним трафиком.
Из общих соображений, если нужно фильтровать что-то, тем более быстро (netflow/IPFIX отдает статистику с существенной задержкой, в зависимости от настроек железа до нескольких десятков секунд), то лучше стоять в inline.
>с помощью AI/ML пробовали пытаться детектить приложения в шифрованном трафике?
Постоянно натыкаюсь на статьи, в которых тренируют роботов и что-то детектируют по netflow. Как это работает вживую, на настоящем трафике - не видел ни разу.
Теоретически можно что-то детектировать по TLS Hello (они идут не зашифрованные). Есть несколько проектов, которые детектируют таким образом ботов и прочую нежелательную активность. Например https://github.com/FoxIO-LLC/ja4
К netflow это никак не прикрутить, нужен сырой трафик. Или хотя бы кусочки пакетов (sFlow, IPFIX 315).
>По совокупности заголовков, длины пакетов, задержек между пакетами?
У нас трафик в 99% случаев семплированный, там ничего такого не видно. Даже на таймстампы фловов не смотрим, это довольно бессмысленно.
На большом трафике *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 (они, кстати, не ушли из РФ) есть интересная фича - они следят за энтропией (адресов, протоколов, портов). Может быть мы эту фичу позаимствуем, если получится придумать, как это нормально реализовать.
Для себя делал простые тесты (и немного профилирование). Синтетические (флуд-трафиком) и так, на живых людях. Но у всех во-первых разное железо, во-вторых разное использование интернета, в-третьих разный Linux. Гарантированно такие же замеры у других людей дадут другие результаты.
Ну, скажем, на синтетическом UDP-трафике в 200 мегабит, который шейпится до 100м на моей железке процесс damper в топе ест где-то 15-17% CPU. Больше мне не нужно, не тестировал, там скорее всего начнутся какие-то неожиданные штуки.
Ядерные шейперы быстрее, конечно. И отлаженнее, это тоже немаловажно
> будет-ли работать данный код на роутере (а почему-бы и нет?) и насколько сильно будет грузить процессор.
С производительностью непонятно, надо пробовать. На ARM'ах Scaleway топ показывает максимум единицы процентов. Но там и трафика никакого нет. Показ статистики ощутимо сильнее нагружает процессор. Для графиков на каждый запрос генерируется PNG-картинка с максимальной компрессией. Несколько человек одновременно смотрящих статистику едят несколько десятков процентов этих армовских CPU (на современных x86/64 все работает конечно бодрее). Ну, для внутрисетевого сервиса должно быть нормально
> Можете-ли в конфиге предусмотреть какой-либо ограничитель по сохраняемым данным? Например: 1d, 3d, 1w, 1m и т.д.
Звучит разумно. Все равно вечно хранить статистику никто не планирует. Можно сделать дефолтный период в год, например, и дать пользователю возможность его изменять. Надо подумать
> Можете-ли сделать вариант html страницы, в которой все или часть JS подтягивается с внешних источников.
Да нет, не обязательно. Можно отзеркалировать порт в котором бегает DNS-трафик и снимать информацию с зеркала.
Теоретически можно даже linux/bsd заменить на Windows или другую платформу с libpcap. Но это очень теоретически, я в практике захвата трафика в Windows слабо понимаю, и мы пробовали только с linux/bsd на живых интерфейсах
Это, вроде, не очень большая сеть? Где-то /23 в терминах IPv4. У операторов, даже некрупных, бывают сотни таких сетей :)
И для них эти плюсы становятся уже не очень плюсами.
Горизонтально масштабировать, то есть покупать новые железные серверы - недешево.
Хранить все flow, то есть держать большое хранилище - тоже недешево.
Они наоборот хотят, чтобы трафик анализировался где-нибудь в мелкой виртуалке и ничего не просил.
Нужно, чтобы sFlow (наверное, он, если flow с коммутаторов) как-то попал в контейнер. Я не очень в Proxmox, но из общих соображений нужно пробросить порт sFlow (скорее всего, UDP 6343) из хоста в контейнер.
Потом, когда трафик придет в коллектор, нужно настроить его так же, как и LXC
https://github.com/vmxdev/xenoeye/blob/master/README.ru.md#lxc-контейнер
Отредактируйте /etc/xenoeye/xenoeye.conf, /var/lib/xenoeye/iplists/mynet и перезапустите.
У нас нет софтроутеров. Ничего не могу сказать.
Иногда вижу статьи про ipt_netflow (и про то, что его сборка ломается на новых ядрах).
На таких скоростях я бы пытался снимать sFlow с коммутатора, если он умеет.
Если не умет, то поискал бы готовый XDP sFlow сенсор. Хотя, сейчас бегло погуглил и ничего такого не увидел. Это, конечно, странно.
Немного ковырялся с этим XDP, вроде должно быть не очень сложно сделать простенький sFlow-сенсор.
Но про сенсор на XDP это я теоретизирую, на больших скоростях его не видел, может быть на 100Gbe он даже не простых программах будет не быстро работать.
>для сетей предприятий, для анализа внутреннего трафика
Ничего в этом не понимаю, даже не знаю зачем на предприятиях следят за внутренним трафиком.
Из общих соображений, если нужно фильтровать что-то, тем более быстро (netflow/IPFIX отдает статистику с существенной задержкой, в зависимости от настроек железа до нескольких десятков секунд), то лучше стоять в inline.
>с помощью AI/ML пробовали пытаться детектить приложения в шифрованном трафике?
Постоянно натыкаюсь на статьи, в которых тренируют роботов и что-то детектируют по netflow. Как это работает вживую, на настоящем трафике - не видел ни разу.
Теоретически можно что-то детектировать по TLS Hello (они идут не зашифрованные). Есть несколько проектов, которые детектируют таким образом ботов и прочую нежелательную активность. Например https://github.com/FoxIO-LLC/ja4
К netflow это никак не прикрутить, нужен сырой трафик. Или хотя бы кусочки пакетов (sFlow, IPFIX 315).
>По совокупности заголовков, длины пакетов, задержек между пакетами?
У нас трафик в 99% случаев семплированный, там ничего такого не видно. Даже на таймстампы фловов не смотрим, это довольно бессмысленно.
На большом трафике *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 (они, кстати, не ушли из РФ) есть интересная фича - они следят за энтропией (адресов, протоколов, портов). Может быть мы эту фичу позаимствуем, если получится придумать, как это нормально реализовать.
Ну, зато хоть немного там упорядочил
> 1. Можете-ли в конфиге предусмотреть какой-либо ограничитель по сохраняемым данным?
Ограничение теперь задается параметром keepstat. В нем можно указать количество дней сколько хранить статистику (по умолчанию 31)
> 2. Можете-ли сделать вариант html страницы, в которой все или часть JS подтягивается с внешних источников.
Сделал так: если страница не находит скрипты и стили локально, то пытается взять их из CDN
Вид графика немного изменился — теперь он показывает количество пропущеных/отброшеных пакетов и байт еще и оттенками.
Возможно, всплывут какие-то недоработки, еще немного потестирую. Если еще интересно, можете посмотреть, в целом должно работать
Ну, скажем, на синтетическом UDP-трафике в 200 мегабит, который шейпится до 100м на моей железке процесс damper в топе ест где-то 15-17% CPU. Больше мне не нужно, не тестировал, там скорее всего начнутся какие-то неожиданные штуки.
Ядерные шейперы быстрее, конечно. И отлаженнее, это тоже немаловажно
С производительностью непонятно, надо пробовать. На ARM'ах Scaleway топ показывает максимум единицы процентов. Но там и трафика никакого нет. Показ статистики ощутимо сильнее нагружает процессор. Для графиков на каждый запрос генерируется PNG-картинка с максимальной компрессией. Несколько человек одновременно смотрящих статистику едят несколько десятков процентов этих армовских CPU (на современных x86/64 все работает конечно бодрее). Ну, для внутрисетевого сервиса должно быть нормально
> Можете-ли в конфиге предусмотреть какой-либо ограничитель по сохраняемым данным? Например: 1d, 3d, 1w, 1m и т.д.
Звучит разумно. Все равно вечно хранить статистику никто не планирует. Можно сделать дефолтный период в год, например, и дать пользователю возможность его изменять. Надо подумать
> Можете-ли сделать вариант html страницы, в которой все или часть JS подтягивается с внешних источников.
Да, хорошо.
Не могу обещать что сделаю быстро, но постараюсь
Теоретически можно даже linux/bsd заменить на Windows или другую платформу с libpcap. Но это очень теоретически, я в практике захвата трафика в Windows слабо понимаю, и мы пробовали только с linux/bsd на живых интерфейсах