Релиз FastNetMon 1.1.2 открытого решения для мониторинга DoS/DDoS атак

    За прошедшие почти 10 месяцев с релиза 1.0.0 была очень большая работа по улучшению программы.

    Из основных изменений стоит отметить следующие:
    • Возможность выявлять самые популярные виды атак: syn_flood, icmp_flood, udp_flood, ip_fragmentation_flood
    • Добавление поддержки протокола Netflow, поддерживаются 5, 9 и 10 (IPFIX) версии
    • Добавление поддержки протокола sFLOW v5, который поддерживается большинством современных сетевых коммутаторов
    • Добавлена поддержка использования netmap (поддерживаются Linux и FreeBSD, для Linux предоставляется специальная версия драйвера ixgbe: github.com/pavel-odintsov/ixgbe-linux-netmap) для захвата пакетов. Данный режим обеспечивает наивысшую производительность захвата трафика наряду с PF_RING ZC.
    • Добавлена поддержка PF_RING ZC (к сожалению, этот режим требует отдельной лицензии на библиотеку PF_RING)



    Полный список изменений можно найти ниже:
    • Добавлена возможность сбора netflow на основе шаблонов с нескольких устройств (в том числе — виртуальных, в пределах одного шасси)
    • Базовая поддержка IPv6 в модуле Netflow, коллектор может прослушивать IPv6 интерфейс, анализ протокола пока не поддерживается
    • Информация об атаке теперь включает очень большое число полей, среди которых — используемые протоколы, типы пакетов, флаги TCP и многое другое, все это позволяет идентифицировать атаки максимально точно
    • Вместо ежесекундного расчета используется усреднение скорости атаки за Х последних секунд, что позволяет минимизировать ложные срабатывания
    • Добавлена возможность сохранения отпечатков атаки в отдельных файлах
    • Добавлена возможность указывать лимит с которого трафик считается атакой в числе потоков, пакетов/секунду и байт/секунду.
    • Добавлена интеграция с проектом ExaBGP, с помощью которого можно анонсировать блокируемые IP адреса непосредственно на BGP роутеры собственной сети либо напрямую аплинку
    • Добавлена поддержка плагинов, теперь возможна разработка собственных систем захвата трафика в дополнение к имеющимся
    • Добавлены init файлы для систем на базе systemd
    • Добавлена возможность разблокировки IP после истечения заданного периода времени
    • Добавлена возможность сохранения данных об атаке в Redis
    • Добавлена поддержка распаковки протокола L2TP в режиме захвата с зеркальных портов


    Со стороны разработки были осуществлены следующие изменения:
    • Осуществлен переход на систему сборки cmake
    • Добавлена интеграция CI системы Travis CI
    • По соображениям переносимости осуществлен отказ от использования функционала С++ 11


    Список поддерживаемых платформ претерпел огромные изменения, добавлена поддержка следующих систем:
    • Fedora 21
    • Debian 6, 7, 8
    • CentOS 6, 7
    • FreeBSD 9, 10, 11
    • DragonflyBSD 4
    • MacOS X 10.10


    Для следующих систем были собраны бинарные пакеты:

    Для других Linux систем рекомендуется использовать автоматический установщик.

    Новая версия позволяет достичь очень высокой производительности. Скорость обработки sFLOW/Netflow почти неограниченная (до десятков и сотен гигабит секунду). Для режима PF_RING (не ZC) максимально достигнутая скорость в районе ~3mpps/5GE. Наивысшей скорости можно добиться используя системы захвата трафика PF_RING ZC или netmap, обе библиотеки позволяют обрабатывать до 10 и более миллионов пакетов в секунду на зеркальных портах (10GE+). Обращаю внимание, что при очень высокой скорости рекомендуется отключать режим трекинга соединений, который очень сильно нагружает процессорные ресурсы. Все измерения приведены для Intel i7 2600 и сетевой карты Intel 82599.

    Из вещей касающихся сообщества разработки стоит отметить подключение проекта Gitter для эффективного обсуждения вопросов, касающихся проекта и в дополнение к нему добавлен классический список рассылки.

    Отдельно мы бы хотели поблагодарить людей внесших большой вклад в помощь проекту и в первую очередь компанию FastVPS, без которой данный проект был бы невозможен!
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 25
    • +1
      А почему не было попыток добавить FreeBSD'шный порт в официальное дерево?
      • +4
        К сожалению, дистрибутивов очень много, а я один. Я сам поддерживаю версии для Fedora/CentOS (почти месяц назад отправлены в Fedora для review) и вот совсем скоро закончу версию для Debian Jessie (моя рабочая машинка). Потом скорее всего попробую с FreeBSD, там нужен rc файл, пример конфиг-файла в общем-то все.

        Но есть и помощники, например огромное спасибо Alexei Takaseev за пакет для AltLinux sisyphus.ru/en/srpm/fastnetmon :)
      • 0
        На Ubuntu и не будет работать?
        • 0
          Будет, с радостью будет. Вообще работать будет везде, где есть C++ и Boost, ничего особенно тулкиту не требуется. Поидее, даже на ARM/PowerPC соберется и заработает.
        • +1
          А сколько на этой версии драйвера получается выжать на одной карте на 60b пакетиках на сабжевой корке? В более ранних сломан DCA, поэтому там может быть печаль, а односокетные системы интересны тем, что не дают лайн рейта ни при каких ухищрениях на насыщении пакетами.
          • 0
            Если с обработкой и c FastNetMon, то 10 mpps на i7 3840, 64 байта пакеты, TCP SYN флуд. Режим — netmap, ixgbe драйвер 3.23.2 мой отсюда: github.com/pavel-odintsov/ixgbe-linux-netmap

            Если тупой захват — 14.6 MPPS без проблем забирается стандартным pkt-gen -f rx -i netmap:ethX.
            • +1
              Да, я имел в виду обработку, то есть все, отлично от pkt-gen -f rx и бриджа. 10, соответственно, с отключенным турбо и зафиксированными частотами, включенным dca, и разбросанными прерываниями? // 3.23.2 еще был сломан, в .1 как раз дофиксили DCA.
              • 0
                Турбо не трогал, потоки жестко прибиты к ядрам (код в апстриме), частота в потолок, прерывания распределены либо силами birq либо силами жесткой фиксаии на те же ядра, где выполняются соотвествующие им потоки.

                dca, признаться, не трогал вообще — стоит забитое по дефалту. Могу попробовать портироваться на 4й драйвер ixgbe и посмотреть прирост.
                • 0
                  Забил себе баг репорт про битый DCA, github.com/pavel-odintsov/ixgbe-linux-netmap/issues/4 как будет время, соберу новый и протестирую производительность на нем.
                  • +1
                    Нуу 3.23.2.1 как раз его чинит, в дмесге это видно. До него последний рабочий кажется 3.17. 4ка по кодовой базе очень мало отличается, так что она вряд ли даст какое-то улучшение. Для обработки, если не упираться в процессор и выделить изолированные ядра для юзерспейса, чтобы процессить трафик, показательно что-то в районе 12.6Mpps/карта. Потолок также зависит от конкретного процессора — например, идентичные настройки и идентичная платформа для 2620v2 и 2603v2 дают больший результат для второго, если у первого, имеющего большую частоту и большее число ядер, включен гипертрединг.
                    • 0
                      А, все, вижу, у меня как раз ведь .1 подверсия, я какое-то время назад допортировался на нее и забыл =) А что про гипертрединг думаете? Внутри netmap есть заметные в perf top локи и поидее отключение гипертрединга снизит их использование и может увеличить пропускную прилично. Но я не тестировал, просто рассуждаю.
          • 0
            Павел, а какие действия вообще осуществляются при syn-флуде со спуффингом?
            Если я правильно понял просто уведомление?
            • +1
              Уведомление либо разворот на фильтрующее облако/ферму фильтров. Как решение — можете попробовать synproxy на CentOS 7 либо Debian 8, он дает очень хорошие возможности по фильтрации, я его разгонял до 3mpps. Хорошие конфиги под него генерит firehol (без внешней помощи можно поседеть).
              • +2
                Коннтрек в линуксе к сожалению обрушивается при флуде с нулевого порта в условиях насыщения очередей :) Давеча писал в нетдев, пока что-то никто не ответил. Касательно HT в другой цепочке — да, отключать его надо всегда.
                • 0
                  Ссылочку дадите на багрепорт?

                  Так поидее в случае synproxy оно же не доходит до добавления записи в коннтрек хэш пока не пройдет 3WHS? А чтение обрушивать не должно, оно там приличное очень по скорости.
                  • 0
                    К сожалению, практика показывает иное.
                    Ссылка на описание:
                    lists.openwall.net/netdev/2015/05/28/191
                    lists.openwall.net/netdev/2015/05/29/94
                    Правила можно взять отсюда:
                    devconf.cz/filebrowser/download/374
                    Флудер можно использовать какой угодно (я использую переделанный нетмап, который вместо udp генерит tcp с чексуммами).

                    Насыщение очереди /32м флудом после докручиваний наступает в районе 495kpps, если выставить рейт 485, то все ок, если 490 или 493 — флоу контроль начинает дергаться и летят софт локапы. Иными словами, любой фильтрующий сины инстанс на линуксе сейчас можно подвесить достаточно дешевой атакой, достаточной для забивания одной очереди карты. Другое дело, что одинокий трансмиттер легко забанить, а флуд со многих ничем не отличается от обычной «теоретической» атаки на синпрокси, так что проблема вряд ли принадлежит к кругу реальных.
                • +1
                  Меня больше интересует фильтрация на базе netmap, года 2 назад довёл отражение перфект SYN до ~8mpps, но стабильности не достиг и за неимением времени проект забросил. А за это время netmap претерпел кардинальные изменения, нужно начинать с нуля, думал может у Вас в рамках данного проекта есть и «свежая» реализация фильтрации.
                  • 0
                    Она как раз на netmap-ipfw на Linux и есть www.stableit.ru/2015/03/linux-netmap-ipfw.html :) Работает стабильно. Но оно только для блокировки по типовым параметрам пакета, что делать с SYN с netmap-ipfw я ума не приложу :)

                    Сейчас уже есть BGP Flow Spec интерфейс для него, чтобы из FastNetMon дергать триггер на блокировку того или иного трафика с высочайшей скоростью: github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/firewall_queue.py

                    А как вы отбивали им syn flood?
                    • +1
                      Она как раз на netmap-ipfw на Linux и есть. Работает стабильно.

                      Тогда мне его запустить не удалось. Падал в кору при первом поступившем пакете. Луиджи отписывался, но ответа так и не получил.
                      А как вы отбивали им syn flood?

                      Свой syn-кукер писал, альтернативы особой не вижу.
                      • 0
                        Круто :) Было бы чудесно, получить это дело в опенсорс и интегрировать с FastNetMon.
                        • 0
                          А можно подробнее про свой синкукер? Можно в личку.
                • +1
                  Интересно, планирует кто-нибудь сделать софт для защиты обычный домашних компьютеров от DDoS?
                  • 0
                    А что мешает использовать FastNetMon для этой цели? =) Обычно, пров по обычному домашнему компьютеру кончится либо смертью роутера, который стоит у вас дома либо смертью роутера, который стоит для вас у провайдера.

                    Отбивать атаки на домашнем интернете (конечно, если это не гугл файбер в 1 гигабит) бессмысленно — это задача Вашего провайдера и только его.
                    • +2
                      Все провайдеры умывают руки. Как говорится: спасение утопающих — дело рук самих утопающих. Когда идет игра на деньги со ставками (киберспорт), то защита личного компьютера становится актуальной.

                      А что мешает использовать FastNetMon для этой цели?

                      FastNetMon ведь не работает под Windows.
                      • 0
                        Мой софт лишь практически не работает под Windows. Теоретически, я могу его собрать под Windows силами MinGW.

                        Но тут стоит понимать, что нужно будет сильно переделать домашнюю сеть — убрать дилинки там, скажем, и до предела расширить каналы.

                        Если есть желающие тестировать — прошу в багтрекер. Функционал sFLOW/NetFLOW работать будет почти точно. За прочие — не ручаюсь.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.