The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Эффективное блокирование тысяч IP в Linux

04.07.2007 16:15

В статье "Filtering traffic based on thousands of IPs efficiently" рассказывается о программе nfqueue, которая работает на пользовательском уровне и использует NetFilter библиотеку netlink-queue.

Nfqueue позволяет значительно повысить эффективность блокирования десятков тысяч IP, не требуя при этом накладывания дополнительных патчей, как происходив в случае с ipset.

При тестировании, загрузка 70000 обычных правил заняла около часа, в то время как nfqueue почти мгновенно подгружает большие cписки блокировки, оформленные в p2p, dat, csv форматах или преобразованные в специальный сжатый бинарный вид.

  1. Главная ссылка к новости (http://www.debian-administrati...)
  2. OpenNews: nf-HiPAC - высокопроизводительный пакетный фильтр для Linux
  3. OpenNews: Блокирование диапазонов адресов отдельных стран в iptables
  4. ipset
  5. nfqueue Documentation
Лицензия: CC-BY
Тип: английский / Практикум
Короткая ссылка: https://opennet.ru/11286-netfilter
Ключевые слова: netfilter, linux, firewall, iptables
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (42) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, ФФ (?), 18:33, 04/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А для чего это нужно?
     
     
  • 2.2, const86 (ok), 18:47, 04/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    > А для чего это нужно?

    В теории можно управлять доступом на уровне приложений (например, allow from... у апача итд) и не вешать лишний хлам на внешние интерфейсы. Но это в теории... Поэтому, как всегда, наматываем на ус, вдруг пригодится.

     
  • 2.4, serg1224 (?), 20:47, 04/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    А может для защиты от DDOS-атак?
     
  • 2.17, uldus (ok), 10:52, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >А для чего это нужно?

    Например адреса ботнетов блокировать на уровне фаервола, чтобы ресурсы MTA не съедали. Но там не тысячи, а миллионы адресов в блэклистах.

     
  • 2.50, etc (?), 23:35, 25/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >А для чего это нужно?

    Для хардкорного фильтрования по куче правил.Скажем поищите файлик для емуля ipfilter.dat
    Грубо говоря, большой список систем с которых вам 1 фиг никогда не пришлют полезные данные, а вот флудить, ддосить, слать левак и т.п. - могут.Когда рулесов становится тысячи - обычные фаерволы начинают дуреть, они на это не рассчитаны...

     

  • 1.3, ФФ (?), 18:55, 04/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    сложно представить реально зачем...если сервера приложений стоят в ДатаЦентре и там есть нормальные средства фильтрации и защиты зачем на уровне ОС лесть в сетевые вещи ?
     
     
  • 2.7, _Nick_ (??), 22:26, 04/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    тебя послушать так в датацентре и работать серваку незачем.
    А нафига, если вокруг и так стока серваков??
     
     
  • 3.32, medioom (?), 16:01, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Если сетевики не нормальные - халявщики, то они всё спускают до системных администраторов, которым приходится самим работать.
     
     
  • 4.51, etc (?), 23:42, 25/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Если сетевики не нормальные - халявщики, то они всё спускают до системных
    >администраторов, которым приходится самим работать.

    Кого ваши разборки сетевиков и админов волнуют, а?Вещь безусловно полезная.И позволит обойтись без пачки кисок местами.Что есть гуд, ибо экономия.

     

  • 1.5, alteleid (ok), 20:47, 04/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    теоретически можно использовать как часть интеллектуального IPS против DDoS, но ни в коем случае не так как хотят создатели... для этого есть специализированное железо
     
     
  • 2.8, _Nick_ (??), 22:28, 04/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    не всегда стоимость и деревянность железаных средств являются приемлемыми.
     
     
  • 3.9, alteleid (ok), 23:20, 04/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Всегда, если речь идет о scalability и performance
    Дискуссия закрыта.
     
     
  • 4.52, etc (?), 03:02, 26/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Всегда, если речь идет о scalability и performance
    >Дискуссия закрыта.

    Ага, ну конечно.Смотрите, дети, вот еще один представитель вида животных "есть 2 мнения - мое и неправильное" ;)

     
  • 2.11, gvy (ok), 01:48, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Кажется, при последнем DDoS наш пров упоминал какую-то байду за $180K, если не послышалось.  Видимо, специализированное на выем денег железо...
     
     
  • 3.12, _Nick_ (??), 01:50, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Кажется, при последнем DDoS наш пров упоминал какую-то байду за $180K, если
    >не послышалось.  Видимо, специализированное на выем денег железо...

    вово
    мало какая проблема требует просто тупо вкладывать бабло.

    Чаще просто головой подумать - толку будет больше, чем за сотни тыщщ неденег

     
     
  • 4.26, alteleid (ok), 14:21, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Все просто, если ваша сеть не стоит этих 180К (не много, кстати, магистральное оборудование в 2-3 раза дороже) не покупайте. Однако не понятно как вы достигли таких объемов, а железо не окупается? Может у вас бесплатная сеть?
     
     
  • 5.31, Michael Shigorin (ok), 15:56, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Может у вас бесплатная сеть?
    Если не заметили -- упоминалось про _нашего_ (а не наш) ISP.  Он ни разу не бесплатный, хотя и неплохой :-)
     
     
  • 6.33, alteleid (ok), 16:12, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    а что такое _нашего_ (а не наш) ISP ? Я честно не понял.
     
     
  • 7.34, Michael Shigorin (ok), 16:29, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >а что такое _нашего_ (а не наш) ISP ? Я честно не понял.
    Ну в смысле "те, кто нам тырнет провайдят".

    Кстати, пока искал для них контакт заодно -- брошу-ка и сюда, мож кому интересно/полезно пообщаться будет:

    http://conference.osdn.org.ua/ru/archive/2005/
    Алексей Лукин, ЧГТУ:
    Сетевые системы детектирования атак и противодействия им на базе фильтрующих маршрутизаторов.
    Работа посвящена построению сетевых IDS на основе фильтрации трафика на пограничном маршрутизаторе. В отличии от подобных систем (Snort, Prelude), работающих на основе прослушивания трафика, предложенный класс систем на основе фильтрации трафика на пограничном маршрутизаторе позволяет не только обнаружить вредоносный трафик, но и предотвратить его попадание в сеть.

    Водится здесь: http://www.stu.cn.ua/~alukin/

    PS: в этом году тоже будет конференция. :)

     
  • 5.53, etc (?), 03:08, 26/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Все просто, если ваша сеть не стоит этих 180К (не много, кстати,

    Угу, для CISCO это немного.А для остальных - кому как.Даже крупный бизнес сто раз подумает до того как столько отстегнуть, переберет все варианты, etc.Кто-то покупает - когда иного выхода нет.А так - сервант с этой приблудой в отличие от... - практически бесплатный, да?Особенно на фоне 180К зелени.А значит позволить себе то что вчера было доступно только крутым сможет больше народа.Даже если цискарям это и не нравится, это их половые трудности.То что вчера было пределом мечтаний провайдера завтра будет у Васи Пупкина дома, в маленькой коробочке.

     

  • 1.6, Вова (?), 21:09, 04/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    сколько людей и сколько ресурсов неужеле нечего более стоящего придумать нельзя -- к примеру СПАМ или еще что-то массу всего
     
  • 1.13, universite (ok), 07:33, 05/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    C DDoS надо бороться на магистралях, но они наоборот заинтересованы в запредельных загрузках каналов и бредят Mpps и Gpps.
    А на датацентрах установка подобной железки лишь способ срубить бабла и увеличить капитализацию своего бизнеса.
     
     
  • 2.14, _Nick_ (??), 08:01, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >C DDoS надо бороться на магистралях, но они наоборот заинтересованы в запредельных
    >загрузках каналов и бредят Mpps и Gpps.
    >А на датацентрах установка подобной железки лишь способ срубить бабла и увеличить
    >капитализацию своего бизнеса.

    каждый хочет наи... ть

     
     
  • 3.16, DXT (??), 09:21, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >каждый хочет наи... ть
    Ну дык в стране откатов живемcЪ ...
     

  • 1.18, nuclight (?), 11:15, 05/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хехе, смотрим в статью, на сайт программы - и видим, что обрааботка происходит в _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 раз.

     
     
  • 2.19, nuclight (?), 11:17, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Аналогично, с вызовом программы на каждое правило и еще и печатью на stdout кот... большой текст свёрнут, показать
     
     
  • 3.21, _Nick_ (??), 11:37, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    да, защитник от ДДоСа в юзер-левеле это бред.

    Но вот проблема добавления в фаервол не так уж и страшна.
    Думаю, немалый процент времени, использованного для загрузки правил,
    уходит на fork+exec. Следовательно, тут более логично смотрелось бы
    решение в виде проги, которая закачивает правила из файла в фаервол сама
    (по тем же вызовам, что делает ipfw или iptables).
    Ядерная проверка и быстрая загрузка - где-то там было бы приемлемое решение

     
     
  • 4.22, nuclight (?), 12:14, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >да, защитник от ДДоСа в юзер-левеле это бред.
    >
    >Но вот проблема добавления в фаервол не так уж и страшна.
    >Думаю, немалый процент времени, использованного для загрузки правил,
    >уходит на fork+exec. Следовательно, тут более логично смотрелось бы
    >решение в виде проги, которая закачивает правила из файла в фаервол сама
    >
    >(по тем же вызовам, что делает ipfw или iptables).
    >Ядерная проверка и быстрая загрузка - где-то там было бы приемлемое решение


    А оно уже и так. Как мне тут сейчас сообщили, iptables-save делает это за две минуты. В общем, скрипач^W nfqueue не нужен.


     
     
  • 5.27, _Nick_ (??), 14:44, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >А оно уже и так. Как мне тут сейчас сообщили, iptables-save делает
    >это за две минуты.
    Ну да

    >В общем, скрипач^W nfqueue не нужен.


     
  • 2.23, devcoder (??), 13:04, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    А Linux netfilter + ipset?

    ИМХО, согласен что для такой задачи нужна аппаратная железка и у того,
    у кого такая необходимость блокирования реально может возникнуть,
    деньги на неё (железку) безусловно есть.

     
     
  • 3.55, etc (?), 03:25, 26/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >у кого такая необходимость блокирования реально может возникнуть,
    >деньги на неё (железку) безусловно есть.

    Узость взглядов - хреново, да?Такая задача в принципе возникает например у почти любого P2P юзера и как ни странно, далеко не любой юзер в состоянии купить себе стоечку с цисками.Это так, для тех кто в танке.С ручника полезно иногда сниматься.Говорят, помогает.

     

  • 1.29, bel (?), 15:40, 05/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если проверка всех этих 70000 правил делается простым перебором адресов, то эффективность блокирования под сомнением.
     
     
  • 2.30, _Nick_ (??), 15:42, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Если проверка всех этих 70000 правил делается простым перебором адресов, то эффективность
    >блокирования под сомнением.

    так ли это - можно легко узнать почитав доки упомянутых модулей в упомянутых системах :)

     
  • 2.39, exn (??), 23:10, 05/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >елается простым перебором адресов
    скорее хеширование
     
     
  • 3.47, nuclight (?), 10:20, 06/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>елается простым перебором адресов
    >скорее хеширование

    Покажите мне хэш-функцию, эффективно работающую для IPv4 адресов. Для таких случаев применяют деревья - во FreeBSD, например, radix tree.

     
     
  • 4.48, dsn (??), 17:12, 06/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>>елается простым перебором адресов
    >>скорее хеширование
    >
    >Покажите мне хэш-функцию, эффективно работающую для IPv4 адресов. Для таких случаев применяют
    >деревья - во FreeBSD, например, radix tree.


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

     
     
  • 5.56, etc (?), 03:27, 26/07/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >приближения. Очень быстро получается.

    А поподробнее?Что за метод?Насколько быстро?Скажем у тупого перебора отстойное соотношение - O(n).А у вас - что в итоге?

     
     
  • 6.58, LonliLokli (ok), 22:00, 11/01/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>приближения. Очень быстро получается.
    >
    >А поподробнее?Что за метод?Насколько быстро?Скажем у тупого перебора отстойное соотношение - O(n).А
    >у вас - что в итоге?

    google://метод бисекции

    Если в кратце - берётся элемент посередине уорядоченного множества и сравнивается с данным. Если данный элемент меньше - берём "нижнюю" половину множества, если больше - "верхнюю". Дальше всё повторяется с выбранной половиной.

     
     
  • 7.59, universite (ok), 03:17, 12/01/2009 [^] [^^] [^^^] [ответить]  
  • +/

    >google://метод бисекции
    >
    >Если в кратце - берётся элемент посередине уорядоченного множества и сравнивается с
    >данным. Если данный элемент меньше - берём "нижнюю" половину множества, если
    >больше - "верхнюю". Дальше всё повторяется с выбранной половиной.

    Тогда надо как-то дерево адресов ipv4 упорядочить в одномерный массив или последовательность.

    В общем, алгоритмов достаточно, но универсальных нет ;)

     

  • 1.37, juni (??), 21:59, 05/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    почитав рассылку netfilter.org на предмет проекта libnf-queue увидел, что просили помочь задокументировать этот модуль, потому как не описан совершенно. это отталкивало людей от миграции с libipqueue. Предполагаю, что это и есть та самая попытка написать доки.
     
  • 1.49, Moralez (??), 04:17, 07/07/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ммм... не пробовал такой объем, но pf должен вообще махом и грузить и обрабатывать такое количество правил...
     
     
  • 2.57, guest (??), 21:10, 02/08/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >ммм... не пробовал такой объем, но 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 сетевых интерфейсов.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру