LINUX.ORG.RU

FastNetMon 1.0.0 — программа для выявления входящих/исходящих атак

 , , ,


9

6

Хотел бы поделиться своей программой для анализа проходящего миррор-порты/роутеры/OpenVZ ноды трафика на предмет входящих/исходящих DDoS атак.

  • Для чего она писалась? Чтобы фиксировать серьезные всплески в сотни kpps по полосе/pps как со стороны клиентов, так и со стороны интернета в сторону клиентов.
  • Что выдает? Выдает топ 10 самых активных потребителей ресурсов сети, выборки топ 10 можно делать как по pps так и по трафику.
  • Что умеет? Умеет передавать управление внешнему скрипту, который передаст IP на/с которого идет атака на анализ группе администраторов либо заблокирует его на некоторое время.
  • На чем работает? Поддерживает PF_RING (рекомендуется), pcap (не рекомендуется) и ULOG2 (не рекомендуется).
  • Что еще умеет? Умеет считать трафик по заданным диапазонам, решение базируется на redis и используется в исключительно внутренних целях.
  • На каком канале работает? Приложение сейчас в продакшене (на миррор портах, с отдельной машины) с нагрузкой в несколько гигабит входящего+исходящего трафика с примерно 550kpps и более в среднем. Ресурсы почти не жрет — около 10% по всем ядрам на i7 2600.
  • На какой платформе точно работает? Debian/CentOS/Ubuntu. Но скомпилировать можно только на Debian 7.
  • На чем написано? C++ 11.

>>> Подробности



Проверено: fallout4all ()
Последнее исправление: ymn (всего исправлений: 2)

Но скомпилировать можно только на Debian 7

Это успех. Т.е. ебилдов можно не ждать? Установку из deb не предлагать.

ass ★★★★
()

звучит прикольно, но интересно, что скажут более опытные, чем я, аналитики лора.

anonymous
()

скомпилировать можно только на Debian 7.

можешь объяснить почему, перед тем как я начал писать Gentoo ebuild?

clojure
()

FastNetMon 1.0.0 — программа для выявления входящих/исходящих атак
входящих/исходящих DDoS атак.
Выдает топ 10 самых активных потребителей ресурсов сети

Так она что-то кроме показа самых активных IP делает? Нет? Так почему это тогда выявление атак? И каким образом всплеск активности с одного IP стал DDoS? Что значит первая D в DDoS и каким образом показ 10 IP поможет в борьбе с DDoS?

Mr_Alone ★★★★★
()

Ресурсы почти не жрёт

Ресурсы почти не жрет — около 10% по всем ядрам на i7 2600.

10% по всем ядрам i7 это уже «ресурсы почти не жрёт»?

Camel ★★★★★
()
Ответ на: комментарий от Mr_Alone

И каким образом всплеск активности с одного IP стал DDoS ?

Если это источник, одна из атакующих нод. В общем-то, это гораздо более частая ситуация, нежели атака в сторону клиента. Только вот интенсивность, чаще, совсем маленькая, по всплеску трафика плохо ловится.

AS ★★★★★
()
Ответ на: комментарий от ass

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

clojure
()
Ответ на: комментарий от clojure

На опеннете написано что

Из-за использования C++11 для сборки требуется свежий инструментарий C++ (можно собрать в Debian 7, но g++ из CentOS 6 не подходит для сборки)

ya-betmen ★★★★★
()
Ответ на: комментарий от AS

Только вот интенсивность, чаще, совсем маленькая, по всплеску трафика плохо ловится.

Вот-вот. Проще блокировать по User-Agent, он как правило у всех нод в случае атаки одинаковый.

Mr_Alone ★★★★★
()
Ответ на: комментарий от ya-betmen

а, понятно, наверное мы (те, кто из нас) неправильно поняли автора, он говорит, наверное, что скомпилировать можно со списка Debian/CentOS/Ubuntu только на Debian 7.

clojure
()

Пару месяцев назад я так вас искал..

Пришлось писать свой костыль на ipt-netflow

PF_RING записал, может в будущем буду пользоваться.

multihead
()

спасибо что поделились, думаю VDS хостерам будет интересно!

jekader ★★★★★
()
Ответ на: комментарий от ass

Боюсь, что тут проблемы не с моей стороны, а со стороны PF_RING. Его нет в репозиториях почти всех дистрибутивов, в связи с лицензионными проблемами.

nrg
() автор топика
Ответ на: комментарий от Mr_Alone

Речь идет о том, что мы фиксируем активность не внешних узлов, а нагрузку по пакетам в секунду всех наших узлов. Да, я согласен, что показатели в районе 7-10 kpps могут быть вызваны легитимным трафиком, но цифры от 50 и выше - это однозначно DoS/DDoS, за полгода в продакшене не было ни единого ложно положительного срабатывания на «чистый» трафик.

nrg
() автор топика
Ответ на: Ресурсы почти не жрёт от Camel

На фоне альтернативных решений - это совершенно не жрет :) Кроме этого, оно при этом не теряет половину пакетов, как это делает любое решение на базе pcap, выедающее почти под 100% этой же самой машинки.

Честно говоря, я думаю нагрузку можно снизить еще, бОльшая ее часть потребляется драйвер ixgbe, который еще можно очень хорошо оптимизировать.

nrg
() автор топика
Ответ на: комментарий от nrg

Его нет в репозиториях почти всех дистрибутивов, в связи с лицензионными проблемами.

PF_RING™ (kernel module), PF_RING™-DNA, drivers are distributed under the GNU GPL license and available in source code format.

Я чего-то не понимаю?

ass ★★★★
()
Ответ на: комментарий от clojure

Я сейчас специально просмотрел дерево кода PF_RING (версии 6.0.1) и обнаружил, что и модуль ядра (GPLv2), так и либа LGPL имеют вполне адекватные свободные лицензии (смотри выше).

Да, в том же самом репозитории лежит несвободный софт, за который нужно оплатить денюжку прежде чем использовать, но сама либа и модуль ядра (только они в общем-то и нужны) полностью открытые.

Может быть кто-то займется лоббированием вопроса по добавлению PF_RING в Gentoo?

nrg
() автор топика
Ответ на: комментарий от multihead

ipt-netflow временами крайне смачно виснет из-за проблем с блокировками, будьте аккуратны с его использованием на роутере. Мы использовали его только на mirror портах и машина валялась через день :(

nrg
() автор топика
Ответ на: комментарий от ya-betmen

Да, с этим в CentOS 6 проблема, поэтому и был собран статический бинарик, потому что все библиотеки C++11 нельзя притащить более-менее прилично, чтобы не испортить систему.

Но в связи с релизом RHEL7, я думаю скоро CentOS 6 начнет сдавать свои позиции.

nrg
() автор топика
Ответ на: комментарий от Mr_Alone

К сожалению, до прикладных протоколов в случае входящих/исходящих атак последних лет дело доходит крайне редко.

По нашей практике (по данным снятым как раз FastNetMon) распределение примерно такое:

  • 70% udp флуд через DNS усиление
  • 10% просто udp флуд рандомными крупными пакетами (обычно со спуфингом)
  • 10% tcp syn флуд со спуфингом
  • 10% прочие виды атак, в том числе http флуд и прочие.
nrg
() автор топика

возможны варианты доса, при которых ваша программа грузит проц более чем на 50 процентов ?

kto_tama ★★★★★
()
Ответ на: комментарий от Deleted

Это вы зря :) Запустите хотя бы tcpdump (он на pcap) с перенаправлением в /dev/null и посмотрите, как он нагрузит систему и какой у него при этом будет packetloss. 10% нагрузка на потоках в 0.5 mpps, при меньшей нагрузке Вы его даже в top не увидите почти никогда.

nrg
() автор топика
Ответ на: комментарий от kto_tama

На гигабитном канале мы нагружали ее почти до 1.47 mpps, то есть до теоретического предела Gigabit Ethernet, система при этом была нагружена процентов на 45-50. Но, повторюсь, мы использовали драйверы без оптимизации и почти вся эта нагрузка шла от драйвера, а не от программы как таковой.

nrg
() автор топика
Ответ на: комментарий от xsektorx

Не так много как хотелось бы :(

nrg
() автор топика
Ответ на: комментарий от nrg

Ну если только посмотреть на нагрузку...

ОК.

Deleted
()
Ответ на: комментарий от nrg

По нашей практике

Это FastVPS чтоль? И что, клиентов по вашему всегда udp флудом кладут, а просто по паре запросов в секунду с 10-20К хостов на сайт клиента вы спокойно перемалываете и за DDoS не считаете?

Mr_Alone ★★★★★
()
Последнее исправление: Mr_Alone (всего исправлений: 1)
Ответ на: комментарий от Mr_Alone

Почему не считаем? Мы их ровно также фиксируем, как и udp флуд и прочие виды атак. Мы не считааем пакеты с удаленной машины (да, такой бы подход позволил большому ботнету пройти незамеченно), мы считаем сколько приходит/уходит с _нашего_ (клиентского IP в данном случае) и на основании этого уже предпринимаем меры по отражению и в крайних случаях блокировке.

nrg
() автор топика
Ответ на: комментарий от nrg

Мы их ровно также фиксируем

И каким же образом с помощью этой тулзы можно отделить паразитный траффик от обычного? В чем будет разница между парой гет запросов с обычного айпишника от пары гет запросов с паразитного?

Mr_Alone ★★★★★
()

На какой платформе точно работает? Debian/CentOS/Ubuntu. Но скомпилировать можно только на Debian 7.

Это как вообще? Мэйк смотрит /etc/lsb-release и не работает, если там не визи?

sT331h0rs3 ★★★★★
()
Ответ на: комментарий от Mr_Alone

Он не у нас, он у клиентов, мы не можем решить самостоятельно, нужен он им или нет. Обычно UDP DNS/TeamSpeak/OpenVPN/другое.

А так, разумеется, блокировка UDP одна из первых мер при мощных атаках, но только этим дело кончается весьма редко.

nrg
() автор топика
Ответ на: комментарий от sT331h0rs3

Если бы так :( Только на Wheezy/Ubuntu/Fedora есть библиотеки С++11 и на них программа отлично соберется, все остальные более старые платформы (в том числе CentOS 6) выдадут ошибку «не могу найти файл», как только встретят такие вещи как:

  • #include <thread>
  • #include <chrono>
  • #include <mutex>
nrg
() автор топика
Ответ на: комментарий от Mr_Alone

В общем случае его никак не отличить, программа его и не пытается отличать. Она лишь сообщает администраторам как только поток любого (хоть паразитного, хоть легитимного) трафика с/на наш IP превысит, допустим, 100 kpps и это начнет угрожать оборудованию.

nrg
() автор топика

О, просьба к модераторам исправить строку «Но скомпилировать можно только на Debian 7» на «Обращаем внимание, что в связи с использованием С++11, возможность компиляции на ряде платформ выпущенных несколько лет назад (в том числе CentOS 5/6) отсутствует».

nrg
() автор топика

NETMAP

avtory respekt i malenkii sovet posmotret v storony netmap ... tam vozmogna skorost do 14kk pps . no gelatlno freebsd postavit tak kak na linux'e nexochet ono rabotat normalno.

anonymous
()
Ответ на: NETMAP от anonymous

Спасибо :) В принципе пока PF_RING справляется на ура, теоретически он тоже должен работать на линейных скоростях 10GE, как только нагрузки вырастут, я думаю поделюсь своими изысканиями на эту тему (а изыскания по текущим наработками выкладывал здесь, если кому интересно: ссылка).

nrg
() автор топика
Ответ на: комментарий от nrg

Удивительно, а я-то думал, что плюсовики до сих пор юзают только в лучшем случае C++98.

sT331h0rs3 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.