В статье "Filtering traffic based on thousands of IPs efficiently (http://www.debian-administration.org/articles/540)" рассказывается о программе nfqueue (http://nfqueue.sf.net), которая работает на пользовательском уровне и использует NetFilter библиотеку netlink-queue.
Nfqueue позволяет значительно повысить эффективность блокирования десятков тысяч IP, не требуя при этом накладывания дополнительных патчей, как происходив в случае с ipset (http://ipset.netfilter.org/).
При тестировании, загрузка 70000 обычных правил заняла около часа, в то время как nfqueue (http://nfqueue.sf.net) почти мгновенно подгружает большие cписки блокировки, оформленные в p2p, dat, csv форматах или преобразованные в специальный сжатый бинарный вид.URL: http://www.debian-administration.org/articles/540
Новость: https://www.opennet.ru/opennews/art.shtml?num=11286
А для чего это нужно?
> А для чего это нужно?В теории можно управлять доступом на уровне приложений (например, allow from... у апача итд) и не вешать лишний хлам на внешние интерфейсы. Но это в теории... Поэтому, как всегда, наматываем на ус, вдруг пригодится.
А может для защиты от DDOS-атак?
>А для чего это нужно?Например адреса ботнетов блокировать на уровне фаервола, чтобы ресурсы MTA не съедали. Но там не тысячи, а миллионы адресов в блэклистах.
>А для чего это нужно?Для хардкорного фильтрования по куче правил.Скажем поищите файлик для емуля ipfilter.dat
Грубо говоря, большой список систем с которых вам 1 фиг никогда не пришлют полезные данные, а вот флудить, ддосить, слать левак и т.п. - могут.Когда рулесов становится тысячи - обычные фаерволы начинают дуреть, они на это не рассчитаны...
сложно представить реально зачем...если сервера приложений стоят в ДатаЦентре и там есть нормальные средства фильтрации и защиты зачем на уровне ОС лесть в сетевые вещи ?
тебя послушать так в датацентре и работать серваку незачем.
А нафига, если вокруг и так стока серваков??
Если сетевики не нормальные - халявщики, то они всё спускают до системных администраторов, которым приходится самим работать.
>Если сетевики не нормальные - халявщики, то они всё спускают до системных
>администраторов, которым приходится самим работать.Кого ваши разборки сетевиков и админов волнуют, а?Вещь безусловно полезная.И позволит обойтись без пачки кисок местами.Что есть гуд, ибо экономия.
теоретически можно использовать как часть интеллектуального IPS против DDoS, но ни в коем случае не так как хотят создатели... для этого есть специализированное железо
не всегда стоимость и деревянность железаных средств являются приемлемыми.
Всегда, если речь идет о scalability и performance
Дискуссия закрыта.
>Всегда, если речь идет о scalability и performance
>Дискуссия закрыта.Ага, ну конечно.Смотрите, дети, вот еще один представитель вида животных "есть 2 мнения - мое и неправильное" ;)
Кажется, при последнем DDoS наш пров упоминал какую-то байду за $180K, если не послышалось. Видимо, специализированное на выем денег железо...
>Кажется, при последнем DDoS наш пров упоминал какую-то байду за $180K, если
>не послышалось. Видимо, специализированное на выем денег железо...вово
мало какая проблема требует просто тупо вкладывать бабло.Чаще просто головой подумать - толку будет больше, чем за сотни тыщщ неденег
Все просто, если ваша сеть не стоит этих 180К (не много, кстати, магистральное оборудование в 2-3 раза дороже) не покупайте. Однако не понятно как вы достигли таких объемов, а железо не окупается? Может у вас бесплатная сеть?
>Может у вас бесплатная сеть?
Если не заметили -- упоминалось про _нашего_ (а не наш) ISP. Он ни разу не бесплатный, хотя и неплохой :-)
а что такое _нашего_ (а не наш) ISP ? Я честно не понял.
>а что такое _нашего_ (а не наш) ISP ? Я честно не понял.
Ну в смысле "те, кто нам тырнет провайдят".Кстати, пока искал для них контакт заодно -- брошу-ка и сюда, мож кому интересно/полезно пообщаться будет:
http://conference.osdn.org.ua/ru/archive/2005/
Алексей Лукин, ЧГТУ:
Сетевые системы детектирования атак и противодействия им на базе фильтрующих маршрутизаторов.
Работа посвящена построению сетевых IDS на основе фильтрации трафика на пограничном маршрутизаторе. В отличии от подобных систем (Snort, Prelude), работающих на основе прослушивания трафика, предложенный класс систем на основе фильтрации трафика на пограничном маршрутизаторе позволяет не только обнаружить вредоносный трафик, но и предотвратить его попадание в сеть.Водится здесь: http://www.stu.cn.ua/~alukin/
PS: в этом году тоже будет конференция. :)
>Все просто, если ваша сеть не стоит этих 180К (не много, кстати,Угу, для CISCO это немного.А для остальных - кому как.Даже крупный бизнес сто раз подумает до того как столько отстегнуть, переберет все варианты, etc.Кто-то покупает - когда иного выхода нет.А так - сервант с этой приблудой в отличие от... - практически бесплатный, да?Особенно на фоне 180К зелени.А значит позволить себе то что вчера было доступно только крутым сможет больше народа.Даже если цискарям это и не нравится, это их половые трудности.То что вчера было пределом мечтаний провайдера завтра будет у Васи Пупкина дома, в маленькой коробочке.
сколько людей и сколько ресурсов неужеле нечего более стоящего придумать нельзя -- к примеру СПАМ или еще что-то массу всего
C DDoS надо бороться на магистралях, но они наоборот заинтересованы в запредельных загрузках каналов и бредят Mpps и Gpps.
А на датацентрах установка подобной железки лишь способ срубить бабла и увеличить капитализацию своего бизнеса.
>C DDoS надо бороться на магистралях, но они наоборот заинтересованы в запредельных
>загрузках каналов и бредят Mpps и Gpps.
>А на датацентрах установка подобной железки лишь способ срубить бабла и увеличить
>капитализацию своего бизнеса.каждый хочет наи... ть
>каждый хочет наи... ть
Ну дык в стране откатов живемcЪ ...
Хехе, смотрим в статью, на сайт программы - и видим, что обрааботка происходит в _userland_. То есть каждый пакет копируется туда и обратно, с сопутствующими переключениями контекста. Фактически, это FreeBSD'шный divert, за NAT на котором столько ругали систему за тормоза. Какая при этом может быть борьба с DDOS? И это при тм, что ведь есть же в линуксе для iptables тот же ядерный ipset.Но да ладно, проведем аналогичные измерения для FreeBSD, как по добавлению голого списка правил,что заняло час для iptables в статье по ссылке выше, так и с использованием таблиц ipfw, аналогом которых явялется ipset (быстрое сравнение в ядре). Сначала напишем перловый скрипт, который может генерировать скрипты по добавлению 70000 адресов:
#!/usr/bin/perl -w
use Socket qw/inet_aton inet_ntoa/;
my $prefix = "ipfw add 777 deny all from ";
my $suffix = " to any\n";
#my $prefix = "ipfw table 111 add ";
#my $suffix = "\n";
my $base = '1.1.1.1';
my $howmany = 70000;
my $nbase = unpack 'N',inet_aton($base);my @quads = map { inet_ntoa(pack('N', $_)) }
grep { $_ % 256 }
$nbase .. $howmany + $nbase;print "#!/bin/sh\n\n";
map { print $prefix, $_, $suffix } @quads;И запустим ./genips.pl > table.sh; chmod +x table.sh; time ./table.sh
Получен результат: ./table.sh 10,45s user 94,32s system 104% cpu 1:40,07 totalТо есть, в таблицу 70000 адресов были добавлены менее чем за 2 минуты! И это при том, что внешняя программа ipfw вызывалась в скрипте 70000 раз.
Аналогично, с вызовом программы на каждое правило и еще и печатью на stdout (которое мы отправим в /dev/null), чтоб замедлить насколько можно, запустим простое добавление в ipfw семидесяти тысяч правил, прямой аналог того, что делали с iptables в статье:# ./genips.pl > rules.sh; chmod +x rules.sh # в genips строки сменены с таблицы на обычное add all from, см. комментарии в скрипте
# time ./rules.sh > /dev/null
./rules.sh > /dev/null 116,97s user 519,57s system 100% cpu 10:33,90 totalДесять с половиной минут.
Измерения проводились на ненагруженном в этот момент сервере:
FreeBSD 6.2-STABLE #0: Sat Apr 28 23:26:52 NOVST 2007
vadim@hostel.avtf.net:/usr/obj/usr/src/sys/HOSTEL
acpi_alloc_wakeup_handler: can't alloc wake memory
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf34 Stepping = 4
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x441d<SSE3,RSVD2,MON,DS_CPL,CNTX-ID,<b14>>
Logical CPUs per core: 2Повторим добавление в таблицу в "боевых" условиях, наиболее быстрым способом (подгружая из файла без печати на stdout):
# ./genips.pl > table
# time ipfw -q /home/vadim/work/table
ipfw -q /home/vadim/work/table 0,67s user 0,19s system 93% cpu 0,910 totalТо есть практически мгновенно. Строки в скрипте генерации были изменены на:
my $prefix = "table 111 add ";
my $suffix = "\n";Изменим их на:
my $prefix = "add 777 deny all from ";
my $suffix = " to any\n";И проверим добавление 70000 правил снова:
# ./genips.pl > rules
# time ipfw -q /home/vadim/work/rules
ipfw -q /home/vadim/work/rules 85,85s user 315,14s system 98% cpu 6:46,03 totalВ полтора раза быстрее, чем в предыдущий раз, как видим.
Ну и в дополнение по нагрузке. Если запустить на этот сервер ping -f с соседнего, то есть каждый пакет проходит через все 70000 правил и ответ на него - тоже, при примерно 300-400 pps (фря ограничивает количество icmp-ответов в секунду) нагрузка по прерываниям составляет около 50% CPU.
да, защитник от ДДоСа в юзер-левеле это бред.Но вот проблема добавления в фаервол не так уж и страшна.
Думаю, немалый процент времени, использованного для загрузки правил,
уходит на fork+exec. Следовательно, тут более логично смотрелось бы
решение в виде проги, которая закачивает правила из файла в фаервол сама
(по тем же вызовам, что делает ipfw или iptables).
Ядерная проверка и быстрая загрузка - где-то там было бы приемлемое решение
>да, защитник от ДДоСа в юзер-левеле это бред.
>
>Но вот проблема добавления в фаервол не так уж и страшна.
>Думаю, немалый процент времени, использованного для загрузки правил,
>уходит на fork+exec. Следовательно, тут более логично смотрелось бы
>решение в виде проги, которая закачивает правила из файла в фаервол сама
>
>(по тем же вызовам, что делает ipfw или iptables).
>Ядерная проверка и быстрая загрузка - где-то там было бы приемлемое решение
А оно уже и так. Как мне тут сейчас сообщили, iptables-save делает это за две минуты. В общем, скрипач^W nfqueue не нужен.
>А оно уже и так. Как мне тут сейчас сообщили, iptables-save делает
>это за две минуты.
Ну да>В общем, скрипач^W nfqueue не нужен.
А Linux netfilter + ipset?ИМХО, согласен что для такой задачи нужна аппаратная железка и у того,
у кого такая необходимость блокирования реально может возникнуть,
деньги на неё (железку) безусловно есть.
>у кого такая необходимость блокирования реально может возникнуть,
>деньги на неё (железку) безусловно есть.Узость взглядов - хреново, да?Такая задача в принципе возникает например у почти любого P2P юзера и как ни странно, далеко не любой юзер в состоянии купить себе стоечку с цисками.Это так, для тех кто в танке.С ручника полезно иногда сниматься.Говорят, помогает.
Если проверка всех этих 70000 правил делается простым перебором адресов, то эффективность блокирования под сомнением.
>Если проверка всех этих 70000 правил делается простым перебором адресов, то эффективность
>блокирования под сомнением.так ли это - можно легко узнать почитав доки упомянутых модулей в упомянутых системах :)
>елается простым перебором адресов
скорее хеширование
>>елается простым перебором адресов
>скорее хешированиеПокажите мне хэш-функцию, эффективно работающую для IPv4 адресов. Для таких случаев применяют деревья - во FreeBSD, например, radix tree.
>>>елается простым перебором адресов
>>скорее хеширование
>
>Покажите мне хэш-функцию, эффективно работающую для IPv4 адресов. Для таких случаев применяют
>деревья - во FreeBSD, например, radix tree.
а я для других целей, применял поиск с двоичным приближением.
Сортируешь искомые данные в порядке возрастания, а потом ищешь совпадения, методом двоичного приближения. Очень быстро получается.
>приближения. Очень быстро получается.А поподробнее?Что за метод?Насколько быстро?Скажем у тупого перебора отстойное соотношение - O(n).А у вас - что в итоге?
>>приближения. Очень быстро получается.
>
>А поподробнее?Что за метод?Насколько быстро?Скажем у тупого перебора отстойное соотношение - O(n).А
>у вас - что в итоге?google://метод бисекции
Если в кратце - берётся элемент посередине уорядоченного множества и сравнивается с данным. Если данный элемент меньше - берём "нижнюю" половину множества, если больше - "верхнюю". Дальше всё повторяется с выбранной половиной.
>google://метод бисекции
>
>Если в кратце - берётся элемент посередине уорядоченного множества и сравнивается с
>данным. Если данный элемент меньше - берём "нижнюю" половину множества, если
>больше - "верхнюю". Дальше всё повторяется с выбранной половиной.Тогда надо как-то дерево адресов ipv4 упорядочить в одномерный массив или последовательность.
В общем, алгоритмов достаточно, но универсальных нет ;)
почитав рассылку netfilter.org на предмет проекта libnf-queue увидел, что просили помочь задокументировать этот модуль, потому как не описан совершенно. это отталкивало людей от миграции с libipqueue. Предполагаю, что это и есть та самая попытка написать доки.
ммм... не пробовал такой объем, но pf должен вообще махом и грузить и обрабатывать такое количество правил...
>ммм... не пробовал такой объем, но pf должен вообще махом и грузить
>и обрабатывать такое количество правил...[sp@bastion: ~] % sudo time pfctl -f /etc/pf/pf.conf
pfctl -f /etc/pf/pf.conf.all 1,00s user 1,14s system 54% cpu 3,925 total
[sp@bastion: ~] % sudo wc -l /etc/pf/pf.conf
69731 /etc/pf/pf.conf.all
[sp@bastion: ~] % uname -srp
FreeBSD 6.2-STABLE i386на компьютере 12 сетевых интерфейсов.