The OpenNET Project / Index page

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

Эксперимент по настройке Linux для блокирования 10 млн пакетов в секунду

08.07.2018 08:18

Марек Майковски (Marek Majkowski), разработчик ядра Linux, работающий в компании CloudFlare, опубликовал результаты оценки производительности различных решений на базе ядра Linux для отбрасывания огромного числа пакетов, поступающих в ходе DDoS-атаки. Наиболее высокопроизводительный метод позволил отбрасывать потоки запросов, поступающие с интенсивностью 10 млн пакетов в секунду.

Наибольшей производительности удалось добиться при использовании подсистемы eBPF, представляющей встроенный в ядро Linux интерпретатор байткода, позволяющий создавать высокопроизводительные обработчики входящих/исходящих пакетов с принятием решений об их перенаправлении или отбрасывании. Благодаря применению JIT-компиляции, байткод eBPF на лету транслируется в машинные инструкции и выполняется с производительностью нативного кода. Для блокировки использовался вызов XDP_DROP, предоставляемый подсистемой XDP (eXpress Data Path), позволяющей запускать BPF-программы на уровне сетевого драйвера, с возможностью прямого доступа к DMA-буферу пакетов и на стадии до выделения буфера skbuff сетевым стеком.

Блокировка осуществлялась при помощи загруженного в ядро простого BPF-приложения (около 50 строк кода), написанного на подмножестве языка C и скомпилированного при помощи Clang. Для загрузки скомпилированного модуля eBPF применяется недавно появившаяся в iproute2 команда "xdp obj" ("ip link set dev ext0 xdp obj xdp-drop-ebpf.o"), позволяющая обойтись без написания специализированного BPF-загрузчика. Для просмотра статистики применялась команда "ethtool -S". Логика блокировки была зашита непосредственно в BPF-приложение, например, блокируемые IP-подсеть, порт назначения и тип протокола были определены через условные операторы (системы типа bpfilter и Cilium умеют генерировать BPF-программы на основе высокоуровневых правил фильтрации):


   if (h_proto == htons(ETH_P_IP)) {
       if (iph->protocol == IPPROTO_UDP
           && (htonl(iph->daddr) & 0xFFFFFF00) == 0xC6120000 //    198.18.0.0/24
           && udph->dest == htons(1234)) {
           return XDP_DROP;
       }
   }

Другие опробованные методы блокировки:

  • Отбрасывание пакетов путём создания приложения-заглушки, принимающего запросы на целевом сетевом порту, но не выполняющего каких-либо действий ("s.bind(("0.0.0.0", 1234))" и бесконечный цикл с "s.recvmmsg()" - использование recvmmsg вместо recvmsg важно с точки зрения снижения числа системных вызовов, в свете накладных расходов при включении в ядре защиты от уязвимости Meltdown). Производительность такого решения составила всего 174 тысячи пакетов в секунду, при этом узким местом было не переключение контекста и само приложение (нагрузка была 27% sys и 2% userspace), а полная утилизация второго ядра CPU при обработке SOFTIRQ.

    Большие накладные расходы также возникали из-за ведения ядром таблиц отслеживания соединений (conntrack), отключение которых при помощи правила "iptables -t raw -I PREROUTING -d 198.18.0.12 -p udp -m udp --dport 1234 -j NOTRACK" позволило поднять производительность почти в два раза, до 333 тысяч пакетов в секунду. Дополнительное применение режима SO_BUSY_POLL подняло скорость обработки до 470 тысяч пакетов в секунду.

  • Использование BPF с привязкой к сетевому сокету и запуском на уровне ядра (как с обычным BPF, так и с eBPF). Специально написанное BPF-приложение bpf-drop, подключающее обработчик для фильтрации пакетов к сокету через вызов "setsockopt(SO_ATTACH_FILTER)", продемонстрировало производительность всего 512 тысяч пакетов в секунду (в 20 раз меньше, чем BPF-обработчик на базе XDP). Причиной низкой производительности, как и в первом рассмотренном методе, стали большие накладные расходы при обработке SOFTIRQ.
  • Применение операции DROP в iptables в цепочке INPUT (после обработки маршрутизации). При использовании следующих правил
    
       iptables -t raw -I PREROUTING -d 198.18.0.12 -p udp -m udp --dport 1234 -j NOTRACK
       iptables -I INPUT -d 198.18.0.12 -p udp --dport 1234 -j DROP
    

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

  • Использование iptables DROP на стадии до обработки маршрутизации (PREROUTING). Замена в правиле "-I INPUT" на "-I PREROUTING -t raw" подняло производительность почти в три раза до 1.688 млн пакетов в секунду.
  • Применение операции DROP в nftables на стадии до выполнения стадии отслеживания соединений (для обхода CONNTRACK применяется "hook ingress"):
    
       nft add table netdev filter
       nft -- add chain netdev filter input { type filter hook ingress device vlan100 priority -500 \; policy accept \; }
       nft add rule netdev filter input ip daddr 198.18.0.0/24 udp dport 1234 counter drop
       nft add rule netdev filter input ip6 daddr fd00::/64 udp dport 1234 counter drop
    

    Производительность предложенного решения составила 1.53 млн пакетов в секунду, что немного отстаёт от iptables DROP с PREROUTING.

  • Применение операции DROP в ingress-обработчике tc позволило добиться производительности в 1.8 млн пакетов в секунду.
    
       tc qdisc add dev vlan100 ingress
       tc filter add dev vlan100 parent ffff: prio 4 protocol ip u32 match ip protocol 17 0xff match ip dport 1234 0xffff match ip dst 198.18.0.0/24 flowid 1:1 action drop
       tc filter add dev vlan100 parent ffff: protocol ipv6 u32 match ip6 dport 1234 0xffff match ip6 dst fd00::/64 flowid 1:1 action drop
    


  1. Главная ссылка к новости (https://blog.cloudflare.com/ho...)
  2. OpenNews: Оценка способности сетевого стека Linux обрабатывать миллион пакетов в секунду
  3. OpenNews: Проект LibOS развивает вариант ядра Linux с сетевым стеком в форме библиотеки
  4. OpenNews: Intel представил сокращённый вариант сетевого стека для Linux
  5. OpenNews: Открыт код Syncookied, системы защиты от DDoS-атак
  6. OpenNews: CloudFlare применил NetMap для повышения скорости обработки пакетов в Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48925-ebpf
Ключевые слова: ebpf, linux, iptables, packet, filter, nftables, traffic, tc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (91) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:37, 08/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Теперь понятно почему nftables не прижился. По сравнению с iptables не только синтаксис вырвиглазный, но и производительность ниже. Но конечно по сравнению "tc filter" синтаксис nftables просто конфетка.
     
     
  • 2.16, fske (?), 13:02, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > nft add table netdev filter
    > nft -- add chain netdev filter input { type filter hook ingress device vlan100 priority -500 \; policy accept \; }
    > nft add rule netdev filter input ip daddr 198.18.0.0/24 udp dport 1234 counter drop
    > nft add rule netdev filter input ip6 daddr fd00::/64 udp dport 1234 counter drop

    И что тут вырвиглазного, болезный? А я отвечу - ничего. Просто среди никсоидов есть большАя часть людей, которые не способны выучить новый инструмент и будут всячески поливать говном всё, что они не способны понять/изучить.

     
     
  • 3.19, Crazy Alex (ok), 13:58, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Мне тоже не нравится - слишком много текста в одном регистре, глазу плохо куски выхватывать. Ключики iptables рубят строку удобнее.
     
     
  • 4.24, KonstantinB (ok), 16:29, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    С консоли - возможно (хотя дело привычки). А при редактировании nftables.conf в сколь-либо вменяемом $EDITOR, который умеет в подсветку синтаксиса, все шикарно.
     
  • 4.47, цветник (?), 23:21, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    используй цвет
     
  • 3.20, commiethebeastie (ok), 14:07, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Хорошие правила в виде дерева, спокойно помещаются в json формат.
     
  • 3.22, Аноним (22), 16:01, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да все эти фильтры вырвиглазные и нечитаемые.
    Смотри, как надо:

    New-NetFirewallRule -Direction Inbound -DisplayName "New_Rule" -Name "New_Rule" -RemoteAddress 13.54.0.0/16 -Action Block

    Разница, что называется, очевидна.

     
     
  • 4.23, commiethebeastie (ok), 16:13, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Оно тоже 10кк пакетов в секунду блокирует? Или на 10к синий екран вызывает?
     
     
  • 5.56, Аноним (22), 12:10, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Оно тоже 10кк пакетов в секунду блокирует?

    И даже больше. Оно же не глинукс. 👍

     
  • 5.66, KonstantinB (ok), 21:42, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Оно ваще все пакеты блокирует.
     
  • 4.42, пох (?), 20:00, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Разница, что называется, очевидна.

    до New-.. -remoteaddress 13.54.0.0/24 - следом

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

     
     
  • 5.91, Аноним (91), 12:45, 12/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Как минимум netsh умеет кучу remoteaddress через запятую.
     
  • 4.43, Ан (??), 20:29, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    В этом вашем "как надо" кто-то фаерфол использует через консольку и с целями отличными от заблочить варезной программе доступ в интернет? Для всяких роутеров там есть платные приблуды.
     
     
  • 5.55, нах (?), 10:38, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В этом вашем "как надо" кто-то фаерфол использует через консольку

    ну я иногда использую, если консолька под рукой, а правило такое же примитивное, как этот образчик.
    Это быстрее, чем ждать пока отрисуется mmc

    Если в правиле уже десяток адресов, а надо еще пару добавить - остается только mmc.

    И у вас так будет, слава роботам, nft и неумению современных горе-админов работать в юниксе.

     
  • 5.59, powershell (ok), 16:16, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да
     
  • 3.35, Аноним (1), 18:39, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нечитаемая мешанина без разделителей, особенно вторая строчка.
     
     
  • 4.41, пох (?), 19:51, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Нечитаемая мешанина без разделителей, особенно вторая строчка.

    в ней ЕСТЬ разделители ;-) что делает ее еще более нечитаемой, особенно из-за необходимости экранировать в шелле посимвольно (в моем еще и {})

    пейсателям этой хрени никогда не приходилось управлять сложными фильтрами, о чем уже говорено. Они все "в редакторе с подсветочкой" собирались настраивать, поэтому им не нужны удобные способы построчной работы с правилами. В лучшем случае, а скорее всего - их мечта выглядит как плохая копия windows advanced firewall, с окошком и менюшком.

     
     
  • 5.53, Аноним (53), 09:32, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Они все "в редакторе с подсветочкой" собирались настраивать, поэтому им не нужны удобные способы построчной работы с правилами.

    В vim'е есть подсветка для nft, будешь втирать, что vim не удобен для построчной работы? Хотя я б не удивился, ты ж упoротый на всю голову.

     
     
  • 6.54, нах (?), 10:32, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    просто ты, обезьянка, не умеешь ни sed, ни grep. Вот тебе vim и "удобен" для тех целей, для которых нафиг не нужен.

    вместо одной строки - будешь тупо разглядывать простыню на пару тысяч (правил и поболее бывает)
    Наверное, и искать в ней будешь стрелка-вниз,стрелка-вниз - те, кому по силам /pattern, не будут ради этого запускать vim (ну или теперь - будут, чертыхаясь что новый обезьяно-совместимый формат конфига нормальным образом уже нечитаем, только с "подсветочкой синтаксиса", и непременно через промежуточное сохранение в ненужно-файл)

     
     
  • 7.58, Аноним (58), 15:06, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >простыню на пару тысяч (правил и поболее бывает)

    Я стесняюсь спросить - а зачем столько? Это действительно оправдано?

     
     
  • 8.61, нах (?), 16:48, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну вот ботнеты блокировать ты - вообще не собираешься У меня был специфический ... текст свёрнут, показать
     
     
  • 9.72, Аноним (58), 09:26, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А смысл Сегодня ботнет есть, завтра его попалили, послезавтра хаксор забацал дв... текст свёрнут, показать
     
     
  • 10.76, нах (?), 14:40, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    чтобы тебя не поломали и не положили, дружочек Понятно, что кому-то все равно м... большой текст свёрнут, показать
     
  • 7.73, yu (??), 10:54, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Шаблонизаторы в данном случае решают. Не все кто умеют sed, grep и awk применяют из везде подряд, особенно там где они не подходят.

    Хотя конечно для отладки придется и "ручками" эти конфиги потрогать. Кстати что бы что-то в vim открыть не обязательно это руками в файл сохранять (см. "crontab -e", хотя конечно "лишний" файл там создаётся, но проблем это не доставляет)

     
     
  • 8.77, нах (?), 15:00, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    с чего это лишний и создается Файл у тебя существует перманентно, в etc и в v... большой текст свёрнут, показать
     
     
  • 9.81, yukra (ok), 15:42, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    К тому, что crontab создаёт тебе новый файл где-то в районе tmp И никакого i... текст свёрнут, показать
     

  • 1.2, Нанобот (ok), 10:18, 08/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +25 +/
    для ускорения обработки пакетов в ядре линукс нужно...не допускать попадания пакетов в ядро линукс
     
     
  • 2.6, пох (?), 11:09, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    ну и что в общем удивительного в таком выводе, если вся "обработка" в ронянии их на пол?

    ядро линукс предназначено не для этого,и я бы руки отрывал авторам попыток "оптимизации" подобных вещей. Интересно, зачем им весь остальной линукс? А, понял - в качестве загрузчика правил?

    При этом TL;DR - кто-нибудь прочел первоисточник, зачем они вообще все это затеяли и не делали ли при этом более реальных метрик - например, насколько быстро повиснет нахрен чудесный ebpf, если ронять на пол надо не единственный src/dst, а примерно половину интернета, с соответствующих размеров таблицами?

     
     
  • 3.60, Ivan_83 (ok), 16:22, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В том что линупs только для загрузки правил нужен - нет ничего плохого или необычного.
    В bpf (скорее компилятор правил к нему) никогда не поздно добавить скажем хэш таблицы или бинарный поиск и сортировать массив предварительно, полагаю подобных специфичных оптимизаций уже придумано много для поиска попадания адреса в подсеть из списка.
     
     
  • 4.62, нах (?), 16:53, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    плохо будет, если его начнут с этой целью улучшать Как обычно, ломая то, что ... большой текст свёрнут, показать
     
     
  • 5.75, Ivan_83 (ok), 13:45, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Дефолтами не довольны все, кто туда заглядывает, ибо универсальных значений не существует.
    В венде всё сильно хуже стало со времён ХР/семёрки, возвращаться туда - как добровольно сдаться в конц лагерь.
     
     
  • 6.78, нах (?), 15:05, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > возвращаться туда - как добровольно сдаться в конц лагерь.

    "некоторые ваши товарищи уже на себе почувствовали наше гуманное обращение!"
    "каждому новобранцу - чистая униформа и миска каши!"

     
  • 2.12, Oleg (??), 11:44, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Статья не про обработку пакетов в ядре, а про их роняние. Вариант XDP роняет пакеты раньше всех других способов, потому победил.
     
  • 2.17, Аноним (17), 13:39, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нужно линукс запихнуть в Intel Stratix FPGA
     
     
  • 3.29, Старый одмин (?), 17:37, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Эх, а раньше это была Altera.
    Слава богу, их продукт Quartus продолжил жить.
     

  • 1.3, Лычев Андрей (?), 10:19, 08/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    ичто? роутерам всё это не поможет. и серверам не поможет, они всё равно падут,потому как всяких интернетвещеё уже миллиарды одновременно ддосить могут, и дальше таких бешеных вещёй и чёкнутых смартфонов только ещё больше становиться.
     
     
  • 2.4, Начальник (?), 10:39, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Ну вот сходи к CF расскажи как ddos отбивать правильно, кто в теме понимает, что это крутые результаты, а обсирать все могут.
     
  • 2.5, Аноним (5), 10:58, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Откуда вы лезете? Три первых комментария, а все неимоверно тупые и написаны типичными мамиными специалистами.
     
     
  • 3.57, Аноним (57), 12:49, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Каникулы
     
  • 2.7, оттуда (?), 11:10, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Тебе уже ничего не поможет.
     
  • 2.9, Vitaliy Blats (?), 11:22, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Просто вы, как и многие другие, склонны путать DDoS и DoS Первый - достаточно ... большой текст свёрнут, показать
     
     
  • 3.11, Аноним (11), 11:38, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    но в новости так и написано DDoS
     
  • 3.15, dry (ok), 13:02, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Просто вы, как и многие другие, склонны путать DDoS и DoS.
    > Первый - достаточно редок и весьма дорог,

    Это DDOS то "редок и дорог"?!
    Мьсе живет в каком-то абстрактном розовом мире, ни имеющим соприкосновения с реальностью.

     
     
  • 4.18, Vitaliy Blats (?), 13:51, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Это DDOS то "редок и дорог"?!
    > Мьсе живет в каком-то абстрактном розовом мире, ни имеющим соприкосновения с реальностью.

    Да. Редок и дорог. Час - порядка нескольких тысяч долларов. Ложит иногда даже ISP.

     
     
  • 5.25, KonstantinB (ok), 16:36, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не, дешевле вроде.
    Ассист, судя по материалам уголовного дела и сливам[1], ддосили за 9k в сутки.

    [1]https://krebsonsecurity.com/2011/06/financial-mogul-linked-to-ddos-attacks/

     
     
  • 6.26, KonstantinB (ok), 16:36, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Опечатался (точнее, забыл отредактировать) - за 1к в сутки, всего 9к за 9 дней.
     
  • 5.93, чече (?), 17:57, 13/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    почему то у токсина самый дешевый акк на стрессере с NTP,BoostHTTP,методами дудоса OVH и прочим стоит всего 150 рублей в месяц,тысяч далларов не вижу
     
  • 4.39, Аноним (39), 19:16, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Боюсь все зависит от цели, заказчика и исполнителя. Тоесть  когда речь идет о ддосе серверов тогоже пентагона  - цена одна, Когда речь идет о ддосе серверов игры Perfect World  или  близовского World of Wrcraft - цена уже другая.   Когда же речь идет о ддосе серверов какойнибудь пиратки   типа  Wowcircle хотябы то уже третья цена. Просто если  пентагон  ддосить   то заказывать будет  "серьезная организация  и  серьезным людям" .  А а ддос серверов  того же  Wowcircle  думаю выполнялся уже  людьми намного более  простыми.

    з.ы. все выше сказанное - Имхо - ибо я не спец в этом.

     
  • 3.33, angra (ok), 18:19, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Просто вы, как и многие другие, склонны путать DDoS и DoS.
    > Второй - это когда 1000 VPS-сок

    В первую очередь путаешь их ты. Второй случай это тоже DDoS, хоть и меньшего масштаба.

     
  • 3.90, тигарэтоя (?), 10:11, 12/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ddos уже давно не дорог. и не особо сложен.
     

  • 1.8, Аноним (8), 11:12, 08/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Было бы интересно глянуть что за железо использовалось.
     
  • 1.13, Аноним (11), 11:45, 08/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А это можно использовать каким-то способом для увеличения количества отправляемых пакетов?
    Что в линуксе отвечает за отправку пакетов? Можно добиться снижение нагрузки системы при отправки пакетов?
     
     
  • 2.14, Аноним (14), 12:32, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Можно добиться снижение нагрузки системы при отправки пакетов?

    Смотря что у вас за пакеты. Смотрите в сторону Netmap и DPDK, ими можно генерировать трафик на line rate (т.е. около 14.88 млн коротких пакетов в секунду для 10Gbe) на одном ядре CPU.

    На самом деле ими можно и отбрасывать трафик с такой же скоростью, специалисты из CloudFlare прекрасно об этом знают и статьей слегка тралируют сетевую подсистему линукс

     

  • 1.21, solardiz (ok), 15:00, 08/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Интересно, но:

    Странно, что не упомянута фильтрация средствами сетевушек Intel. "Высокий пакетрейт на x86-64: берем планку в 14,88 Mpps" от Highload Lab / Qrator, 2013 год:

    https://www.slideshare.net/phdays/phd2013-lyamin-22234235
    https://www.youtube.com/watch?v=mZ9yE9HvPHc&list=PLEl1NAXHTFNwvfTVurLKwpOtXzLZ

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

    А conntrack и KPTI на машинах такого предназначения лучше просто выключить полностью. Странно, если в CloudFlare это где-то не так.

     
     
  • 2.30, Аноним (17), 17:56, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Они используют Solarflare NIC, они судя по характеристикам еще круче.
     
  • 2.31, Аноним (17), 17:58, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > берем планку в 14,88 Mpps

    Там ведь задержки большие, у CloudFlare задержки должны быть мега-низкие.

     
  • 2.32, пох (?), 18:18, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну они вообще, похоже, странные. Либо само это исследование - не для работы, а просто ни о чем, лишь бы был повод для публикации.

    я там выше уже обозначил проблему - фильтровать-то при ddos'е надо далеко не один адрес (его и без тебя зафильтруют, на апстриме, если оно настолько большое). И вот там, вангую, будет совсем другой расклад, и даже не берусь предсказать, у кого получится отвратительнее - у iptables, nf, или у модной технологии ebpf (а в память сетевухи просто не влезет), так что до пропускной способности "дропов в секунду" дело вообще не дойдет.

    Даже если conntrack изначально выключить, а не добавлять еще вторую такую же огромную таблицу.

    btw, мельком глянув запрещенные слайды - удивление г-на Лямина по поводу нормальных таймаутов ядра - тоже вызывает вопросы о марсианах. Видимо, сотрудникам qrator неведомо, что помимо http бывает еще какой-то ip, совершенно необязательно живущий до закрытия страницы.

    И опять же - не дай Б-г, и это "соптимизирует" кто-то из его коллег с доступом к исходникам :-(

     
     
  • 3.63, Аноним (63), 20:13, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если блокировать нужно миллионы адресов, вместо обычной таблицы можно использовать какое-нибуть дерево
     
     
  • 4.64, пох (?), 21:15, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну, мы где-то даже такое делали, во времена оны, раскидывая теми же iptables сперва по /8, потом /16 и т д, потом уже фильтруя конкретные небольшие блоки, но надо ж понимать,что оно от этого валидные пакеты тоже начинает на пол ронять, просто не успевая гонять их по всем этим бесконечным веткам, поскольку веток вообще-то получается изрядно много (если предположить что сайтик-то кому-то на самом деле нужен, а не только роботам-%там)

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

    очень странно что эти экспериментаторы этот вопрос бодренько посчитали решенным, особенно в вариантах с bpf, где все это придется делать вручную.

     
     
  • 5.68, Netmapguy (?), 01:15, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >влезет ли оно в отведенную для этого память

    послушайте, память - дешевая.

     
     
  • 6.71, Vkni (ok), 07:43, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А случайный доступ к ней на чтение дорогой (как это ни парадоксально на первый взгляд, на амортизированный доступ на запись - бесплатный).
     
     
  • 7.74, yu (??), 11:05, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Но вот никто не запрещает ставить несколько серверов параллельно, шарить на них трафик в зависимости от адреса источника и соответственно не держать все в памяти одной железки
     
  • 7.79, нах (?), 15:07, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А случайный доступ к ней на чтение дорогой

    там не случайный, но от этого сильно почему-то не легчает, это надо на уровне даже не ebpf, а самого ядра оптимизировать. (в tc что-то на эту тему пытались делать, отчасти потому он так уродлив. А потом процессоры вроде как стали большие, а оптимизировать стало некому.)

     
  • 7.82, DPDKguy (?), 16:45, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >А случайный доступ к ней на чтение дорогой

    а в чем дороговизна в вашем понимании?

     
  • 5.70, Vkni (ok), 07:42, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > то есть вопрос о том, влезет ли оно в отведенную для этого память вообще, и насколько будет тормозить - никуда от этого не девается, и опыт подсказывает, что на этом направлении амбец приходит гораздо раньше, чем просто по ронянию пакетов на землю.

    Кстати про резиновую память - случайный доступ к ОЗУ - это 500 тактов. Т.е. если памяти требуется много и вероятность промаха кеша велика, то в самом лучшем случае получаем 3ГГц/500 = 6E6 адресов/сек.

     
     
  • 6.83, DPDKguy (?), 16:50, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ну, мы можем лукапить пачками и префетчить.
     
  • 4.67, Netmapguy (?), 01:07, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >какое-нибуть дерево

    Nyet, это будет fail. Правильнее будет думать о чем-то вроде dir-24-8

     
     
  • 5.80, нах (?), 15:09, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Nyet, это будет fail. Правильнее будет думать о чем-то вроде dir-24-8

    ну и вот где это делать-то? В bpf? Скорее всего не получится.
    А в более доступных механизмах фильтрации - и негде.


     
  • 5.89, Аноним (89), 09:30, 12/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >dir-24-8

    А что тогда делать с IPv6?

    Мы экспериментировали с несколькими видами trie, при некотором упорстве (и если избегать явных и неявных LOCK-операций) можно лукапить и форвардить на 20Gbe (т.е. на 14.88*2 млн pps) вход и столько же выход. У trie (даже radix trie) есть недостаток - им нужно много памяти. Но если нужды специфические - можно пользоваться и деревьями

     
     
  • 6.92, DPDKguy (?), 18:01, 12/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >А что тогда делать с IPv6?

    страдать.

    >Мы экспериментировали с несколькими видами trie, при некотором упорстве (и если избегать явных и неявных LOCK-операций) можно лукапить и форвардить на 20Gbe (т.е. на 14.88*2 млн pps) вход и столько же выход.

    с dir-24-8 можно делать 200 млн лукапов в секунду на одном ядре.

     
  • 2.69, Netmapguy (?), 01:18, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >фильтрация средствами сетевушек Intel

    а смысл? фильтры там довольно тупые, да и если у вас там линк-агрегация и вланы - будет забавно.

     

  • 1.34, Аноним (34), 18:36, 08/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На увеличенной картинке черный фон, не видно подписей.
     
     
  • 2.49, Григорий Федорович Конин (?), 02:12, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    там прозрачный фон, просто у кого-то цвет в браузере по умолчанию черный
     

  • 1.36, Аноним (36), 18:52, 08/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Скоро ожидать наборы платных файлов вида xdp-make_something-ebpf-corp.o, для корпоративных нужд?
     
     
  • 2.38, Аноним (38), 18:54, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Никогда. Разреверсить тривиально.
     
  • 2.40, пох (?), 19:43, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вечно. поскольку совершенно непонятно, какую бы корпоративную нужду оно могло бы удовлетворить.

    нужды "дропать пакеты с фиксированного src с адским рейтом" у корпоративных систем - нет.

     
     
  • 3.44, Аноним (36), 20:45, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну не такое же глупое условие я имел в виду. Скорее говорил про сложные правила с возможной заточкой под нужды заказчика.
     
     
  • 4.48, пох (?), 23:47, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Скорее говорил про сложные правила с возможной заточкой под нужды заказчика.

    дык - а это как раз и не меряет никто.

    то есть вполне возможно, что сложное и под заказчика гораздо проще и эффективнее окажется делать штатными tc/iptables... в крайнем случае - дописав модуль. Реверсится, не реверсится - заказчику похрен, он платит не за это, а за тяжкий труд индусов, нанятых ляпать эти самые правила круглосуточно и без выходных.

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

     
  • 4.50, RotarenegeD (?), 02:39, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    это называется нанять аутсорсера для написания правил.. но по хорошему скорее всего придётся штатного специалиста держать всёравно..
     
     
  • 5.65, пох (?), 21:18, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    нет, это называется подписка на наборы правил. Существует десятки лет, в том числе для таких правил, которые вполне человекочитаемы - и ничего, платим. Потому что это не "нанять аутсорсера", а "построить сеть honeypot'ов, наладить сбор паттернов, организовать круглосуточную работу по сбору, классификации, обработке и тестированию (потому что можно ненароком и лишнего чего отрезать)".

     

  • 1.37, Аноним (38), 18:53, 08/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    fpga всё равно вне конкуренции.
     
     
  • 2.45, Anonymous_ (?), 21:41, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да клали все с прибором на FPGA.
     
     
  • 3.46, Зеленая слизь на продакшен Линухе (?), 22:03, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Майню на ASIC у тебя в медиаплеере
     
     
  • 4.51, Аноним (-), 06:50, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Майню на ASIC у тебя в вибраторах
     

  • 1.52, qweo (?), 09:10, 09/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Приложение" значит "прикладная программа". Не стоит называть так хотя бы совсем уж служебные вещи, вроде заглушки, помянутой в новости!
     
     
  • 2.94, Мимокрокодил (?), 11:47, 17/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Прикладная программа делает полезное действие и не важно какая она в плане скоупа, узерспейсная или системная.
     

  • 1.85, Аноним (85), 04:39, 11/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень интересно...
     
  • 1.86, vantoo (ok), 13:45, 11/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Могу заблокировать хоть миллиард пакетов в секунду простым выниманием кабеля.
     
     
  • 2.87, нах (?), 14:40, 11/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    плохая попытка, грант не дадут :-(
     
  • 2.88, Аноним (88), 14:47, 11/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Могу заблокировать хоть миллиард пакетов в секунду простым выниманием кабеля.

    Точно? А вдруг, при таком насыщении, они и по воздуху проскакивать будут (т.н. «пакетная дуга»)?


     

  • 1.95, Аноним (95), 21:47, 15/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ненавижу гребаный cloudflare. Чтоб им там подавиться своей гугл-капчей и вечными трекерами! Зачем делать свою капчу? Лучше пусть гугл заплатит нам за то что наши рабы ему будут дорожные знаки, книги, карты читать. Глядишь - за пару дней на 22ю машину накопится.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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