Марек Майковски (Marek Majkowski), разработчик ядра Linux, работающий в компании CloudFlare, опубликовал (https://blog.cloudflare.com/how-to-drop-10-million-packets/) результаты оценки производительности различных решений на базе ядра Linux, способных отбрасывать огромное число пакетов, поступающих в ходе DDoS-атаки. В итоге удалось выработать метод, позволяющий отбрасывать потоки пакетов, поступающие с интенсивностью до 10 млн пакетов в секунду, при том что до оптимизации максимальный результат составлял около 1.8 млн пакетов в секунду.Наибольшей производительности удалось добиться при использовании подсистемы eBPF, представляющей встроенный в ядро Linux интерпретатор байткода, позволяющий создавать высокопроизводительные обработчики входящих/исходящих пакетов с принятием решений об их перенаправлении или отбрасывании. Благодаря применению JIT-компиляции, байткод eBPF на лету транслируется в машинные инструкции и выполняется с производительностью нативного кода. Для блокировки использовался вызов XDP_DROP, предоставляемый подсистемой XDP (https://www.iovisor.org/technology/xdp) (eXpress Data Path), позволяющей запускать BPF-программы на уровне сетевого драйвера, с возможностью прямого доступа к DMA-буферу пакетов и на стадии до выделения буфера skbuff сетевым стеком.
Блокировка осуществлялась при помощи загруженного в ядро простого BPF-приложения (около 50 строк кода (https://github.com/cloudflare/cloudflare-blog/blob/master/20...)), написанного на подмножестве языка C и скомпилированного при помощи Clang. Для загрузки скомпилированного модуля eBPF применяется недавно появившаяся в iproute2 команда "xdp obj" ("ip link set dev ext0 xdp obj xdp-drop-ebpf.o"), позволяющая обойтись без написания специализированного BPF-загрузчика. Для просмотра статистики применялась команда "ethtool -S". Логика блокировки была зашита непосредственно в BPF-приложение, например, блокируемые IP-подсеть, порт назначения и тип протокола были определены через условные операторы (системы типа bpfilter (https://www.opennet.dev/opennews/art.shtml?num=48690) и Cilium (https://www.opennet.dev/opennews/art.shtml?num=48556) умеют генерировать 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 (https://github.com/cloudflare/cloudflare-blog/blob/master/20...), подключаемое обработчик для фильтрации пакетов к сокету через вызов "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
URL: https://blog.cloudflare.com/how-to-drop-10-million-packets/
Новость: https://www.opennet.dev/opennews/art.shtml?num=48925
Теперь понятно почему nftables не прижился. По сравнению с iptables не только синтаксис вырвиглазный, но и производительность ниже. Но конечно по сравнению "tc filter" синтаксис nftables просто конфетка.
> 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И что тут вырвиглазного, болезный? А я отвечу - ничего. Просто среди никсоидов есть большАя часть людей, которые не способны выучить новый инструмент и будут всячески поливать говном всё, что они не способны понять/изучить.
Мне тоже не нравится - слишком много текста в одном регистре, глазу плохо куски выхватывать. Ключики iptables рубят строку удобнее.
С консоли - возможно (хотя дело привычки). А при редактировании nftables.conf в сколь-либо вменяемом $EDITOR, который умеет в подсветку синтаксиса, все шикарно.
используй цвет
Хорошие правила в виде дерева, спокойно помещаются в json формат.
Да все эти фильтры вырвиглазные и нечитаемые.
Смотри, как надо:New-NetFirewallRule -Direction Inbound -DisplayName "New_Rule" -Name "New_Rule" -RemoteAddress 13.54.0.0/16 -Action Block
Разница, что называется, очевидна.
Оно тоже 10кк пакетов в секунду блокирует? Или на 10к синий екран вызывает?
>Оно тоже 10кк пакетов в секунду блокирует?И даже больше. Оно же не глинукс. 👍
Оно ваще все пакеты блокирует.
> Разница, что называется, очевидна.до New-.. -remoteaddress 13.54.0.0/24 - следом
и пойди угадай, какое из двух работает в данную погоду, особенно, когда, в реальности, этих remoteaddress там два десятка в одном правиле (потому что цепочек мы не умеем точно так же, как и последовательностей).
Как минимум netsh умеет кучу remoteaddress через запятую.
В этом вашем "как надо" кто-то фаерфол использует через консольку и с целями отличными от заблочить варезной программе доступ в интернет? Для всяких роутеров там есть платные приблуды.
> В этом вашем "как надо" кто-то фаерфол использует через консолькуну я иногда использую, если консолька под рукой, а правило такое же примитивное, как этот образчик.
Это быстрее, чем ждать пока отрисуется mmcЕсли в правиле уже десяток адресов, а надо еще пару добавить - остается только mmc.
И у вас так будет, слава роботам, nft и неумению современных горе-админов работать в юниксе.
Да
Нечитаемая мешанина без разделителей, особенно вторая строчка.
> Нечитаемая мешанина без разделителей, особенно вторая строчка.в ней ЕСТЬ разделители ;-) что делает ее еще более нечитаемой, особенно из-за необходимости экранировать в шелле посимвольно (в моем еще и {})
пейсателям этой хрени никогда не приходилось управлять сложными фильтрами, о чем уже говорено. Они все "в редакторе с подсветочкой" собирались настраивать, поэтому им не нужны удобные способы построчной работы с правилами. В лучшем случае, а скорее всего - их мечта выглядит как плохая копия windows advanced firewall, с окошком и менюшком.
>Они все "в редакторе с подсветочкой" собирались настраивать, поэтому им не нужны удобные способы построчной работы с правилами.В vim'е есть подсветка для nft, будешь втирать, что vim не удобен для построчной работы? Хотя я б не удивился, ты ж упoротый на всю голову.
просто ты, обезьянка, не умеешь ни sed, ни grep. Вот тебе vim и "удобен" для тех целей, для которых нафиг не нужен.вместо одной строки - будешь тупо разглядывать простыню на пару тысяч (правил и поболее бывает)
Наверное, и искать в ней будешь стрелка-вниз,стрелка-вниз - те, кому по силам /pattern, не будут ради этого запускать vim (ну или теперь - будут, чертыхаясь что новый обезьяно-совместимый формат конфига нормальным образом уже нечитаем, только с "подсветочкой синтаксиса", и непременно через промежуточное сохранение в ненужно-файл)
>простыню на пару тысяч (правил и поболее бывает)Я стесняюсь спросить - а зачем столько? Это действительно оправдано?
> Я стесняюсь спросить - а зачем столько? Это действительно оправдано?ну вот ботнеты блокировать ты - вообще не собираешься?
У меня был специфический use-case - QUEUE, там тоже поболее тысячи (и нам никогда не надо было читать эту простыню глазами - достаточно номера строки с нужным нам блоком, если клиент внезапно поехал на другой сервер)
>ну вот ботнеты блокировать ты - вообще не собираешься?А смысл? Сегодня ботнет есть, завтра его попалили, послезавтра хаксор забацал два новых. Там не то что 2k, там 2M не хватит. Кстати, а с чего ты взял, что все ботнеты против на тебя охотятся? В Пентагоне работаешь?
>достаточно номера строки с нужным нам блоком, если клиент внезапно поехал на другой сервер
А всех клиентов и сервера ты наизусть должно быть, помнишь?
> А смысл?чтобы тебя не поломали и не положили, дружочек. Понятно, что кому-то все равно может повезти прямо с первой попытки, не в том, так в другом, но уменьшать поверхность атаки все же надо по мере возможности.
> А всех клиентов и сервера ты наизусть должно быть, помнишь?
ну, по сути, да. Не всех, но тех которые в QUEUE - точно приходится помнить. Как ты понимаешь (зачеркнуто, как мог бы понимать, если бы обладал не гонором, а квалификацией) - далеко не любые сервисы можно развернуть в твоем любимом k8s, и дважды кликать свою верную мышь поднимая тысячами - иногда для переноса клиента надо одновременно кое-что править в его оборудовании, сделанном недочеловеками, и у себя тоже, и новый сервер тооже не разворачивается парой кликов, его вводят вручную несколько дней, проверяя и перепроверяя функционал. Причем оно такое, что автоматизации не поддается - точнее, ущерб от нее будет больше, чем выгода. Есть в мире еще кое-что, помимо порнобаннеров и фотокотиков, которых никому не жалко.
Шаблонизаторы в данном случае решают. Не все кто умеют sed, grep и awk применяют из везде подряд, особенно там где они не подходят.Хотя конечно для отладки придется и "ручками" эти конфиги потрогать. Кстати что бы что-то в vim открыть не обязательно это руками в файл сохранять (см. "crontab -e", хотя конечно "лишний" файл там создаётся, но проблем это не доставляет)
> см. "crontab -e", хотя конечно "лишний" файл там создаётся, но проблем это не доставляетс чего это лишний и создается? Файл у тебя существует перманентно, в /etc и в /var/spool/cron
Причем там масса костыликов и подпорочек в виде висения на inotify у тех что поновее, или ежеминутном рескане mtime у тех что unixway, чтобы этот файл не разошелся с представлениями демона о том, что в нем лежит.
Правда, это нынче тоже уже почти доломано неосиляторами sed - сплошные cron.daily и run-parts, и /etc/crontab из одной строки * * * * * root do-all-magic-through-the-ass.А в случае фиреволла у тебя все хуже - файл тебе все же нужен - из чего-то восстановить потом настройки, но ядру на него плевать, и никакого механизма обмена кроме довольно уродливых save/restore, даже нормальной гранулярности не обеспечивающих, не предусмотрено.
Поэтому лично я предпочитаю работать не с файлом, а с реальным состоянием фильтра, сохраняя его после отладки изменений. Счетчиков ты в файле не видишь, последовательность проходов по цепочкам в нем отслеживать неудобно, целиком он тебе вообще никогда и ни для чего не будет нужен - сплошные минусы. А юзерлевел утилиту писали еще те люди, которые именно так им и пользовались - поэтому она достаточно удобна для применения.
В концепцию редхатоидов (досистемдэшных, конечно) этот механизм ложится идеально, для остальных все равно все приходится делать через задницу, поскольку у них банального resore на старте и save по желанию не предусмотрено, одни интуитивно-приятные уродливые монстры типа ufw.
К тому, что crontab создаёт тебе новый файл где-то в районе /tmp. И никакого inotify там нет. "Среагирует" ОС только на ":wq" (сохранение и выход), если ты конечно не лазиешь руками мимо crontab'а
для ускорения обработки пакетов в ядре линукс нужно...не допускать попадания пакетов в ядро линукс
ну и что в общем удивительного в таком выводе, если вся "обработка" в ронянии их на пол?ядро линукс предназначено не для этого,и я бы руки отрывал авторам попыток "оптимизации" подобных вещей. Интересно, зачем им весь остальной линукс? А, понял - в качестве загрузчика правил?
При этом TL;DR - кто-нибудь прочел первоисточник, зачем они вообще все это затеяли и не делали ли при этом более реальных метрик - например, насколько быстро повиснет нахрен чудесный ebpf, если ронять на пол надо не единственный src/dst, а примерно половину интернета, с соответствующих размеров таблицами?
В том что линупs только для загрузки правил нужен - нет ничего плохого или необычного.
В bpf (скорее компилятор правил к нему) никогда не поздно добавить скажем хэш таблицы или бинарный поиск и сортировать массив предварительно, полагаю подобных специфичных оптимизаций уже придумано много для поиска попадания адреса в подсеть из списка.
> В том что линупs только для загрузки правил нужен - нет ничего плохого или необычного.плохо будет, если его начнут с этой целью "улучшать". Как обычно, ломая то, что работало в более традиционных его применениях. И вот люди, когда-то сознательно выбравшие линукс, с чертыханиями перелезают с него на винду - где хуже, чем было, но лучше, чем "светлое будущее" с плохой (потому что толком не разобрались как это работает и зачем этим пользуются) имитацией все той же винды.
Ну вон посмотри, если товарищ майор не запретил, слайды по ссылке Солара - товарищ с qратора искренне недоволен тем, что дефолтный таймаут коннтрака для tcp - 5 дней. У меня сессия может висеть открытой и больше - и я совершенно не вижу причин ей рваться, если на дороге оказался шибкоооптимизированный линукс вместо нормального маршрутизатора.
Дефолтами не довольны все, кто туда заглядывает, ибо универсальных значений не существует.
В венде всё сильно хуже стало со времён ХР/семёрки, возвращаться туда - как добровольно сдаться в конц лагерь.
> возвращаться туда - как добровольно сдаться в конц лагерь."некоторые ваши товарищи уже на себе почувствовали наше гуманное обращение!"
"каждому новобранцу - чистая униформа и миска каши!"
Статья не про обработку пакетов в ядре, а про их роняние. Вариант XDP роняет пакеты раньше всех других способов, потому победил.
Нужно линукс запихнуть в Intel Stratix FPGA
Эх, а раньше это была Altera.
Слава богу, их продукт Quartus продолжил жить.
ичто? роутерам всё это не поможет. и серверам не поможет, они всё равно падут,потому как всяких интернетвещеё уже миллиарды одновременно ддосить могут, и дальше таких бешеных вещёй и чёкнутых смартфонов только ещё больше становиться.
Ну вот сходи к CF расскажи как ddos отбивать правильно, кто в теме понимает, что это крутые результаты, а обсирать все могут.
Откуда вы лезете? Три первых комментария, а все неимоверно тупые и написаны типичными мамиными специалистами.
Каникулы
Тебе уже ничего не поможет.
> ичто? роутерам всё это не поможет. и серверам не поможет, они всё равно падут,потому как всяких интернетвещеё уже миллиарды одновременно ддосить могут, и дальше таких бешеных вещёй и чёкнутых смартфонов только ещё больше становиться.Просто вы, как и многие другие, склонны путать DDoS и DoS.
Первый - достаточно редок и весьма дорог, и в принципе ориентирован на саму сеть и ее железо, а не на операционную систему. Пример - ICMP-флуд. Ну то есть когда вы пингуете миллион ПК, подменяя свой IP-адрес на адрес жертвы, и весь миллион ПК шлет ответы на ПК жертвы и тупо забивает канал. В таких случаях патчи ядра до жопы.
Второй - это когда 1000 VPS-сок использующих дырявый плагин к Джумле, начинают синхронно слать лабуду через POST-запрос на сервер жертвы, вызывая бугурт у апача или нжинкса. Вот таких и можно будет успешно блокировать не напрягая проц как в случае netfilter.
но в новости так и написано DDoS
> Просто вы, как и многие другие, склонны путать DDoS и DoS.
> Первый - достаточно редок и весьма дорог,Это DDOS то "редок и дорог"?!
Мьсе живет в каком-то абстрактном розовом мире, ни имеющим соприкосновения с реальностью.
> Это DDOS то "редок и дорог"?!
> Мьсе живет в каком-то абстрактном розовом мире, ни имеющим соприкосновения с реальностью.Да. Редок и дорог. Час - порядка нескольких тысяч долларов. Ложит иногда даже ISP.
Не, дешевле вроде.
Ассист, судя по материалам уголовного дела и сливам[1], ддосили за 9k в сутки.[1]https://krebsonsecurity.com/2011/06/financial-mogul-linked-t.../
Опечатался (точнее, забыл отредактировать) - за 1к в сутки, всего 9к за 9 дней.
почему то у токсина самый дешевый акк на стрессере с NTP,BoostHTTP,методами дудоса OVH и прочим стоит всего 150 рублей в месяц,тысяч далларов не вижу
Боюсь все зависит от цели, заказчика и исполнителя. Тоесть когда речь идет о ддосе серверов тогоже пентагона - цена одна, Когда речь идет о ддосе серверов игры Perfect World или близовского World of Wrcraft - цена уже другая. Когда же речь идет о ддосе серверов какойнибудь пиратки типа Wowcircle хотябы то уже третья цена. Просто если пентагон ддосить то заказывать будет "серьезная организация и серьезным людям" . А а ддос серверов того же Wowcircle думаю выполнялся уже людьми намного более простыми.з.ы. все выше сказанное - Имхо - ибо я не спец в этом.
> Просто вы, как и многие другие, склонны путать DDoS и DoS.
> Второй - это когда 1000 VPS-сокВ первую очередь путаешь их ты. Второй случай это тоже DDoS, хоть и меньшего масштаба.
ddos уже давно не дорог. и не особо сложен.
Было бы интересно глянуть что за железо использовалось.
А это можно использовать каким-то способом для увеличения количества отправляемых пакетов?
Что в линуксе отвечает за отправку пакетов? Можно добиться снижение нагрузки системы при отправки пакетов?
> Можно добиться снижение нагрузки системы при отправки пакетов?Смотря что у вас за пакеты. Смотрите в сторону Netmap и DPDK, ими можно генерировать трафик на line rate (т.е. около 14.88 млн коротких пакетов в секунду для 10Gbe) на одном ядре CPU.
На самом деле ими можно и отбрасывать трафик с такой же скоростью, специалисты из CloudFlare прекрасно об этом знают и статьей слегка тралируют сетевую подсистему линукс
Интересно, но:Странно, что не упомянута фильтрация средствами сетевушек 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=PLEl1NAXHTF...Наверное, она им не подходит из-за своей ограниченности, но упомянуть можно было бы.
А conntrack и KPTI на машинах такого предназначения лучше просто выключить полностью. Странно, если в CloudFlare это где-то не так.
Они используют Solarflare NIC, они судя по характеристикам еще круче.
> берем планку в 14,88 MppsТам ведь задержки большие, у CloudFlare задержки должны быть мега-низкие.
ну они вообще, похоже, странные. Либо само это исследование - не для работы, а просто ни о чем, лишь бы был повод для публикации.я там выше уже обозначил проблему - фильтровать-то при ddos'е надо далеко не один адрес (его и без тебя зафильтруют, на апстриме, если оно настолько большое). И вот там, вангую, будет совсем другой расклад, и даже не берусь предсказать, у кого получится отвратительнее - у iptables, nf, или у модной технологии ebpf (а в память сетевухи просто не влезет), так что до пропускной способности "дропов в секунду" дело вообще не дойдет.
Даже если conntrack изначально выключить, а не добавлять еще вторую такую же огромную таблицу.
btw, мельком глянув запрещенные слайды - удивление г-на Лямина по поводу нормальных таймаутов ядра - тоже вызывает вопросы о марсианах. Видимо, сотрудникам qrator неведомо, что помимо http бывает еще какой-то ip, совершенно необязательно живущий до закрытия страницы.
И опять же - не дай Б-г, и это "соптимизирует" кто-то из его коллег с доступом к исходникам :-(
Если блокировать нужно миллионы адресов, вместо обычной таблицы можно использовать какое-нибуть дерево
ну, мы где-то даже такое делали, во времена оны, раскидывая теми же iptables сперва по /8, потом /16 и т д, потом уже фильтруя конкретные небольшие блоки, но надо ж понимать,что оно от этого валидные пакеты тоже начинает на пол ронять, просто не успевая гонять их по всем этим бесконечным веткам, поскольку веток вообще-то получается изрядно много (если предположить что сайтик-то кому-то на самом деле нужен, а не только роботам-%там)то есть вопрос о том, влезет ли оно в отведенную для этого память вообще, и насколько будет тормозить - никуда от этого не девается, и опыт подсказывает, что на этом направлении амбец приходит гораздо раньше, чем просто по ронянию пакетов на землю.
очень странно что эти экспериментаторы этот вопрос бодренько посчитали решенным, особенно в вариантах с bpf, где все это придется делать вручную.
>влезет ли оно в отведенную для этого памятьпослушайте, память - дешевая.
А случайный доступ к ней на чтение дорогой (как это ни парадоксально на первый взгляд, на амортизированный доступ на запись - бесплатный).
Но вот никто не запрещает ставить несколько серверов параллельно, шарить на них трафик в зависимости от адреса источника и соответственно не держать все в памяти одной железки
> А случайный доступ к ней на чтение дорогойтам не случайный, но от этого сильно почему-то не легчает, это надо на уровне даже не ebpf, а самого ядра оптимизировать. (в tc что-то на эту тему пытались делать, отчасти потому он так уродлив. А потом процессоры вроде как стали большие, а оптимизировать стало некому.)
>А случайный доступ к ней на чтение дорогойа в чем дороговизна в вашем понимании?
> то есть вопрос о том, влезет ли оно в отведенную для этого память вообще, и насколько будет тормозить - никуда от этого не девается, и опыт подсказывает, что на этом направлении амбец приходит гораздо раньше, чем просто по ронянию пакетов на землю.Кстати про резиновую память - случайный доступ к ОЗУ - это 500 тактов. Т.е. если памяти требуется много и вероятность промаха кеша велика, то в самом лучшем случае получаем 3ГГц/500 = 6E6 адресов/сек.
ну, мы можем лукапить пачками и префетчить.
>какое-нибуть деревоNyet, это будет fail. Правильнее будет думать о чем-то вроде dir-24-8
> Nyet, это будет fail. Правильнее будет думать о чем-то вроде dir-24-8ну и вот где это делать-то? В bpf? Скорее всего не получится.
А в более доступных механизмах фильтрации - и негде.
>dir-24-8А что тогда делать с IPv6?
Мы экспериментировали с несколькими видами trie, при некотором упорстве (и если избегать явных и неявных LOCK-операций) можно лукапить и форвардить на 20Gbe (т.е. на 14.88*2 млн pps) вход и столько же выход. У trie (даже radix trie) есть недостаток - им нужно много памяти. Но если нужды специфические - можно пользоваться и деревьями
>А что тогда делать с IPv6?страдать.
>Мы экспериментировали с несколькими видами trie, при некотором упорстве (и если избегать явных и неявных LOCK-операций) можно лукапить и форвардить на 20Gbe (т.е. на 14.88*2 млн pps) вход и столько же выход.
с dir-24-8 можно делать 200 млн лукапов в секунду на одном ядре.
>фильтрация средствами сетевушек Intelа смысл? фильтры там довольно тупые, да и если у вас там линк-агрегация и вланы - будет забавно.
На увеличенной картинке черный фон, не видно подписей.
там прозрачный фон, просто у кого-то цвет в браузере по умолчанию черный
Скоро ожидать наборы платных файлов вида xdp-make_something-ebpf-corp.o, для корпоративных нужд?
Никогда. Разреверсить тривиально.
вечно. поскольку совершенно непонятно, какую бы корпоративную нужду оно могло бы удовлетворить.нужды "дропать пакеты с фиксированного src с адским рейтом" у корпоративных систем - нет.
Ну не такое же глупое условие я имел в виду. Скорее говорил про сложные правила с возможной заточкой под нужды заказчика.
> Скорее говорил про сложные правила с возможной заточкой под нужды заказчика.дык - а это как раз и не меряет никто.
то есть вполне возможно, что сложное и под заказчика гораздо проще и эффективнее окажется делать штатными tc/iptables... в крайнем случае - дописав модуль. Реверсится, не реверсится - заказчику похрен, он платит не за это, а за тяжкий труд индусов, нанятых ляпать эти самые правила круглосуточно и без выходных.
такова бизнес-модель практически всех приличных файрволов на сегодня, включая и такие, которые сами по себе стоят чемодан деньгов, и на коленке не соберешь. (а правила писать - можешь. только что-то никто от подписки еще не отказался)
это называется нанять аутсорсера для написания правил.. но по хорошему скорее всего придётся штатного специалиста держать всёравно..
нет, это называется подписка на наборы правил. Существует десятки лет, в том числе для таких правил, которые вполне человекочитаемы - и ничего, платим. Потому что это не "нанять аутсорсера", а "построить сеть honeypot'ов, наладить сбор паттернов, организовать круглосуточную работу по сбору, классификации, обработке и тестированию (потому что можно ненароком и лишнего чего отрезать)".
fpga всё равно вне конкуренции.
Да клали все с прибором на FPGA.
Майню на ASIC у тебя в медиаплеере
Майню на ASIC у тебя в вибраторах
"Приложение" значит "прикладная программа". Не стоит называть так хотя бы совсем уж служебные вещи, вроде заглушки, помянутой в новости!
Прикладная программа делает полезное действие и не важно какая она в плане скоупа, узерспейсная или системная.
Очень интересно...
Могу заблокировать хоть миллиард пакетов в секунду простым выниманием кабеля.
плохая попытка, грант не дадут :-(
> Могу заблокировать хоть миллиард пакетов в секунду простым выниманием кабеля.Точно? А вдруг, при таком насыщении, они и по воздуху проскакивать будут (т.н. «пакетная дуга»)?
Ненавижу гребаный cloudflare. Чтоб им там подавиться своей гугл-капчей и вечными трекерами! Зачем делать свою капчу? Лучше пусть гугл заплатит нам за то что наши рабы ему будут дорожные знаки, книги, карты читать. Глядишь - за пару дней на 22ю машину накопится.