Из основных изменений стоит отметить следующие:
- Возможность выявлять самые популярные виды атак: 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, без которой данный проект был бы невозможен!
Комментарии (25)
Kaliha
03.06.2015 10:40На Ubuntu и не будет работать?
pavelodintsov Автор
03.06.2015 10:43Будет, с радостью будет. Вообще работать будет везде, где есть C++ и Boost, ничего особенно тулкиту не требуется. Поидее, даже на ARM/PowerPC соберется и заработает.
xdeller
03.06.2015 11:06+1А сколько на этой версии драйвера получается выжать на одной карте на 60b пакетиках на сабжевой корке? В более ранних сломан DCA, поэтому там может быть печаль, а односокетные системы интересны тем, что не дают лайн рейта ни при каких ухищрениях на насыщении пакетами.
pavelodintsov Автор
03.06.2015 11:09Если с обработкой и 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.xdeller
03.06.2015 11:13+1Да, я имел в виду обработку, то есть все, отлично от pkt-gen -f rx и бриджа. 10, соответственно, с отключенным турбо и зафиксированными частотами, включенным dca, и разбросанными прерываниями? // 3.23.2 еще был сломан, в .1 как раз дофиксили DCA.
pavelodintsov Автор
03.06.2015 11:26Турбо не трогал, потоки жестко прибиты к ядрам (код в апстриме), частота в потолок, прерывания распределены либо силами birq либо силами жесткой фиксаии на те же ядра, где выполняются соотвествующие им потоки.
dca, признаться, не трогал вообще — стоит забитое по дефалту. Могу попробовать портироваться на 4й драйвер ixgbe и посмотреть прирост.pavelodintsov Автор
03.06.2015 11:44Забил себе баг репорт про битый DCA, github.com/pavel-odintsov/ixgbe-linux-netmap/issues/4 как будет время, соберу новый и протестирую производительность на нем.
xdeller
03.06.2015 11:55+1Нуу 3.23.2.1 как раз его чинит, в дмесге это видно. До него последний рабочий кажется 3.17. 4ка по кодовой базе очень мало отличается, так что она вряд ли даст какое-то улучшение. Для обработки, если не упираться в процессор и выделить изолированные ядра для юзерспейса, чтобы процессить трафик, показательно что-то в районе 12.6Mpps/карта. Потолок также зависит от конкретного процессора — например, идентичные настройки и идентичная платформа для 2620v2 и 2603v2 дают больший результат для второго, если у первого, имеющего большую частоту и большее число ядер, включен гипертрединг.
pavelodintsov Автор
03.06.2015 11:58А, все, вижу, у меня как раз ведь .1 подверсия, я какое-то время назад допортировался на нее и забыл =) А что про гипертрединг думаете? Внутри netmap есть заметные в perf top локи и поидее отключение гипертрединга снизит их использование и может увеличить пропускную прилично. Но я не тестировал, просто рассуждаю.
simpleadmin
03.06.2015 11:58Павел, а какие действия вообще осуществляются при syn-флуде со спуффингом?
Если я правильно понял просто уведомление?pavelodintsov Автор
03.06.2015 12:00+1Уведомление либо разворот на фильтрующее облако/ферму фильтров. Как решение — можете попробовать synproxy на CentOS 7 либо Debian 8, он дает очень хорошие возможности по фильтрации, я его разгонял до 3mpps. Хорошие конфиги под него генерит firehol (без внешней помощи можно поседеть).
xdeller
03.06.2015 12:02+2Коннтрек в линуксе к сожалению обрушивается при флуде с нулевого порта в условиях насыщения очередей :) Давеча писал в нетдев, пока что-то никто не ответил. Касательно HT в другой цепочке — да, отключать его надо всегда.
pavelodintsov Автор
03.06.2015 12:04Ссылочку дадите на багрепорт?
Так поидее в случае synproxy оно же не доходит до добавления записи в коннтрек хэш пока не пройдет 3WHS? А чтение обрушивать не должно, оно там приличное очень по скорости.xdeller
03.06.2015 12:12К сожалению, практика показывает иное.
Ссылка на описание:
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 — флоу контроль начинает дергаться и летят софт локапы. Иными словами, любой фильтрующий сины инстанс на линуксе сейчас можно подвесить достаточно дешевой атакой, достаточной для забивания одной очереди карты. Другое дело, что одинокий трансмиттер легко забанить, а флуд со многих ничем не отличается от обычной «теоретической» атаки на синпрокси, так что проблема вряд ли принадлежит к кругу реальных.
simpleadmin
03.06.2015 12:06+1Меня больше интересует фильтрация на базе netmap, года 2 назад довёл отражение перфект SYN до ~8mpps, но стабильности не достиг и за неимением времени проект забросил. А за это время netmap претерпел кардинальные изменения, нужно начинать с нуля, думал может у Вас в рамках данного проекта есть и «свежая» реализация фильтрации.
pavelodintsov Автор
03.06.2015 12:11Она как раз на 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?simpleadmin
03.06.2015 12:42+1Она как раз на netmap-ipfw на Linux и есть. Работает стабильно.
Тогда мне его запустить не удалось. Падал в кору при первом поступившем пакете. Луиджи отписывался, но ответа так и не получил.
А как вы отбивали им syn flood?
Свой syn-кукер писал, альтернативы особой не вижу.pavelodintsov Автор
03.06.2015 15:24Круто :) Было бы чудесно, получить это дело в опенсорс и интегрировать с FastNetMon.
Spy
04.06.2015 12:03+1Интересно, планирует кто-нибудь сделать софт для защиты обычный домашних компьютеров от DDoS?
pavelodintsov Автор
04.06.2015 12:43А что мешает использовать FastNetMon для этой цели? =) Обычно, пров по обычному домашнему компьютеру кончится либо смертью роутера, который стоит у вас дома либо смертью роутера, который стоит для вас у провайдера.
Отбивать атаки на домашнем интернете (конечно, если это не гугл файбер в 1 гигабит) бессмысленно — это задача Вашего провайдера и только его.Spy
04.06.2015 15:32+2Все провайдеры умывают руки. Как говорится: спасение утопающих — дело рук самих утопающих. Когда идет игра на деньги со ставками (киберспорт), то защита личного компьютера становится актуальной.
А что мешает использовать FastNetMon для этой цели?
FastNetMon ведь не работает под Windows.pavelodintsov Автор
04.06.2015 16:31Мой софт лишь практически не работает под Windows. Теоретически, я могу его собрать под Windows силами MinGW.
Но тут стоит понимать, что нужно будет сильно переделать домашнюю сеть — убрать дилинки там, скажем, и до предела расширить каналы.
Если есть желающие тестировать — прошу в багтрекер. Функционал sFLOW/NetFLOW работать будет почти точно. За прочие — не ручаюсь.
AMDmi3
А почему не было попыток добавить FreeBSD'шный порт в официальное дерево?
pavelodintsov Автор
К сожалению, дистрибутивов очень много, а я один. Я сам поддерживаю версии для Fedora/CentOS (почти месяц назад отправлены в Fedora для review) и вот совсем скоро закончу версию для Debian Jessie (моя рабочая машинка). Потом скорее всего попробую с FreeBSD, там нужен rc файл, пример конфиг-файла в общем-то все.
Но есть и помощники, например огромное спасибо Alexei Takaseev за пакет для AltLinux sisyphus.ru/en/srpm/fastnetmon :)