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

Хм.

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

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

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

Хороший аватар. Одобряющий.

Т.е. ебилдов можно не ждать?

а самому написать?

// ща напишу.

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

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

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

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

// ща напишу.

Пиши. не забудь в депенды PF_RING, которого в дереве нет.

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

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

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

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

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

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

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

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

И в pentoo он похоже слегка несвеж.

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

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

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

10% по всем ядрам i7

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

а много у тебя рефералов по ссылке в бложике?

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

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

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

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

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

Fixed!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ОК.

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

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

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

А для каких целей у вас udp? Может проще дропать весь udp траффик? Ну раз 80% атак идет через udp.

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

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

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

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

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

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

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

• #include <thread>
• #include <chrono>
• #include <mutex>

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

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

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.

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

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

Почему? От чего зависит?

Ответил выше, кратко - С++11:)

so slow

А, то есть на LLVM 3.4.1 эта штука пойдет)

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

Для вычисления узлов ботнета.