Comments 25
А почему не было попыток добавить FreeBSD'шный порт в официальное дерево?
К сожалению, дистрибутивов очень много, а я один. Я сам поддерживаю версии для Fedora/CentOS (почти месяц назад отправлены в Fedora для review) и вот совсем скоро закончу версию для Debian Jessie (моя рабочая машинка). Потом скорее всего попробую с FreeBSD, там нужен rc файл, пример конфиг-файла в общем-то все.
Но есть и помощники, например огромное спасибо Alexei Takaseev за пакет для AltLinux sisyphus.ru/en/srpm/fastnetmon :)
Но есть и помощники, например огромное спасибо Alexei Takaseev за пакет для AltLinux sisyphus.ru/en/srpm/fastnetmon :)
На Ubuntu и не будет работать?
А сколько на этой версии драйвера получается выжать на одной карте на 60b пакетиках на сабжевой корке? В более ранних сломан DCA, поэтому там может быть печаль, а односокетные системы интересны тем, что не дают лайн рейта ни при каких ухищрениях на насыщении пакетами.
Если с обработкой и 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.
Если тупой захват — 14.6 MPPS без проблем забирается стандартным pkt-gen -f rx -i netmap:ethX.
Да, я имел в виду обработку, то есть все, отлично от pkt-gen -f rx и бриджа. 10, соответственно, с отключенным турбо и зафиксированными частотами, включенным dca, и разбросанными прерываниями? // 3.23.2 еще был сломан, в .1 как раз дофиксили DCA.
Турбо не трогал, потоки жестко прибиты к ядрам (код в апстриме), частота в потолок, прерывания распределены либо силами birq либо силами жесткой фиксаии на те же ядра, где выполняются соотвествующие им потоки.
dca, признаться, не трогал вообще — стоит забитое по дефалту. Могу попробовать портироваться на 4й драйвер ixgbe и посмотреть прирост.
dca, признаться, не трогал вообще — стоит забитое по дефалту. Могу попробовать портироваться на 4й драйвер ixgbe и посмотреть прирост.
Забил себе баг репорт про битый DCA, github.com/pavel-odintsov/ixgbe-linux-netmap/issues/4 как будет время, соберу новый и протестирую производительность на нем.
Нуу 3.23.2.1 как раз его чинит, в дмесге это видно. До него последний рабочий кажется 3.17. 4ка по кодовой базе очень мало отличается, так что она вряд ли даст какое-то улучшение. Для обработки, если не упираться в процессор и выделить изолированные ядра для юзерспейса, чтобы процессить трафик, показательно что-то в районе 12.6Mpps/карта. Потолок также зависит от конкретного процессора — например, идентичные настройки и идентичная платформа для 2620v2 и 2603v2 дают больший результат для второго, если у первого, имеющего большую частоту и большее число ядер, включен гипертрединг.
А, все, вижу, у меня как раз ведь .1 подверсия, я какое-то время назад допортировался на нее и забыл =) А что про гипертрединг думаете? Внутри netmap есть заметные в perf top локи и поидее отключение гипертрединга снизит их использование и может увеличить пропускную прилично. Но я не тестировал, просто рассуждаю.
Павел, а какие действия вообще осуществляются при syn-флуде со спуффингом?
Если я правильно понял просто уведомление?
Если я правильно понял просто уведомление?
Уведомление либо разворот на фильтрующее облако/ферму фильтров. Как решение — можете попробовать synproxy на CentOS 7 либо Debian 8, он дает очень хорошие возможности по фильтрации, я его разгонял до 3mpps. Хорошие конфиги под него генерит firehol (без внешней помощи можно поседеть).
Коннтрек в линуксе к сожалению обрушивается при флуде с нулевого порта в условиях насыщения очередей :) Давеча писал в нетдев, пока что-то никто не ответил. Касательно HT в другой цепочке — да, отключать его надо всегда.
Ссылочку дадите на багрепорт?
Так поидее в случае synproxy оно же не доходит до добавления записи в коннтрек хэш пока не пройдет 3WHS? А чтение обрушивать не должно, оно там приличное очень по скорости.
Так поидее в случае synproxy оно же не доходит до добавления записи в коннтрек хэш пока не пройдет 3WHS? А чтение обрушивать не должно, оно там приличное очень по скорости.
К сожалению, практика показывает иное.
Ссылка на описание:
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 — флоу контроль начинает дергаться и летят софт локапы. Иными словами, любой фильтрующий сины инстанс на линуксе сейчас можно подвесить достаточно дешевой атакой, достаточной для забивания одной очереди карты. Другое дело, что одинокий трансмиттер легко забанить, а флуд со многих ничем не отличается от обычной «теоретической» атаки на синпрокси, так что проблема вряд ли принадлежит к кругу реальных.
Ссылка на описание:
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 — флоу контроль начинает дергаться и летят софт локапы. Иными словами, любой фильтрующий сины инстанс на линуксе сейчас можно подвесить достаточно дешевой атакой, достаточной для забивания одной очереди карты. Другое дело, что одинокий трансмиттер легко забанить, а флуд со многих ничем не отличается от обычной «теоретической» атаки на синпрокси, так что проблема вряд ли принадлежит к кругу реальных.
Меня больше интересует фильтрация на базе netmap, года 2 назад довёл отражение перфект SYN до ~8mpps, но стабильности не достиг и за неимением времени проект забросил. А за это время netmap претерпел кардинальные изменения, нужно начинать с нуля, думал может у Вас в рамках данного проекта есть и «свежая» реализация фильтрации.
Она как раз на 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?
Сейчас уже есть BGP Flow Spec интерфейс для него, чтобы из FastNetMon дергать триггер на блокировку того или иного трафика с высочайшей скоростью: github.com/FastVPSEestiOu/fastnetmon/blob/master/src/scripts/firewall_queue.py
А как вы отбивали им syn flood?
Интересно, планирует кто-нибудь сделать софт для защиты обычный домашних компьютеров от DDoS?
А что мешает использовать FastNetMon для этой цели? =) Обычно, пров по обычному домашнему компьютеру кончится либо смертью роутера, который стоит у вас дома либо смертью роутера, который стоит для вас у провайдера.
Отбивать атаки на домашнем интернете (конечно, если это не гугл файбер в 1 гигабит) бессмысленно — это задача Вашего провайдера и только его.
Отбивать атаки на домашнем интернете (конечно, если это не гугл файбер в 1 гигабит) бессмысленно — это задача Вашего провайдера и только его.
Все провайдеры умывают руки. Как говорится: спасение утопающих — дело рук самих утопающих. Когда идет игра на деньги со ставками (киберспорт), то защита личного компьютера становится актуальной.
FastNetMon ведь не работает под Windows.
А что мешает использовать FastNetMon для этой цели?
FastNetMon ведь не работает под Windows.
Мой софт лишь практически не работает под Windows. Теоретически, я могу его собрать под Windows силами MinGW.
Но тут стоит понимать, что нужно будет сильно переделать домашнюю сеть — убрать дилинки там, скажем, и до предела расширить каналы.
Если есть желающие тестировать — прошу в багтрекер. Функционал sFLOW/NetFLOW работать будет почти точно. За прочие — не ручаюсь.
Но тут стоит понимать, что нужно будет сильно переделать домашнюю сеть — убрать дилинки там, скажем, и до предела расширить каналы.
Если есть желающие тестировать — прошу в багтрекер. Функционал sFLOW/NetFLOW работать будет почти точно. За прочие — не ручаюсь.
Sign up to leave a comment.
Релиз FastNetMon 1.1.2 открытого решения для мониторинга DoS/DDoS атак