The OpenNET Project / Index page

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



"Эксперимент по настройке Linux для блокирования 10 млн пакет..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от opennews (??), 08-Июл-18, 09:37 
Марек Майковски (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.me/opennews/art.shtml?num=48690) и Cilium (https://www.opennet.me/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.me/opennews/art.shtml?num=48925

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (1), 08-Июл-18, 09:37 
Теперь понятно почему nftables не прижился. По сравнению с iptables не только синтаксис вырвиглазный, но и производительность ниже. Но конечно по сравнению "tc filter" синтаксис nftables просто конфетка.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –5 +/
Сообщение от fske (?), 08-Июл-18, 13:02 
> 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 | Наверх | Cообщить модератору

19. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +3 +/
Сообщение от Crazy Alex (ok), 08-Июл-18, 13:58 
Мне тоже не нравится - слишком много текста в одном регистре, глазу плохо куски выхватывать. Ключики iptables рубят строку удобнее.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

24. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от KonstantinB (ok), 08-Июл-18, 16:29 
С консоли - возможно (хотя дело привычки). А при редактировании nftables.conf в сколь-либо вменяемом $EDITOR, который умеет в подсветку синтаксиса, все шикарно.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

47. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от цветник (?), 08-Июл-18, 23:21 
используй цвет
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

20. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –3 +/
Сообщение от commiethebeastie (ok), 08-Июл-18, 14:07 
Хорошие правила в виде дерева, спокойно помещаются в json формат.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

22. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +2 +/
Сообщение от Аноним (22), 08-Июл-18, 16:01 
Да все эти фильтры вырвиглазные и нечитаемые.
Смотри, как надо:

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

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

23. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –2 +/
Сообщение от commiethebeastie (ok), 08-Июл-18, 16:13 
Оно тоже 10кк пакетов в секунду блокирует? Или на 10к синий екран вызывает?
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

56. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (22), 09-Июл-18, 12:10 
>Оно тоже 10кк пакетов в секунду блокирует?

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

66. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +1 +/
Сообщение от KonstantinB (ok), 09-Июл-18, 21:42 
Оно ваще все пакеты блокирует.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

42. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от пох (?), 08-Июл-18, 20:00 
> Разница, что называется, очевидна.

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

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

91. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (91), 12-Июл-18, 12:45 
Как минимум netsh умеет кучу remoteaddress через запятую.
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

43. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –3 +/
Сообщение от Ан (??), 08-Июл-18, 20:29 
В этом вашем "как надо" кто-то фаерфол использует через консольку и с целями отличными от заблочить варезной программе доступ в интернет? Для всяких роутеров там есть платные приблуды.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

55. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +1 +/
Сообщение от нах (?), 09-Июл-18, 10:38 
> В этом вашем "как надо" кто-то фаерфол использует через консольку

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

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

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

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

59. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от powershell (ok), 09-Июл-18, 16:16 
Да
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

35. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +1 +/
Сообщение от Аноним (1), 08-Июл-18, 18:39 
Нечитаемая мешанина без разделителей, особенно вторая строчка.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

41. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от пох (?), 08-Июл-18, 19:51 
> Нечитаемая мешанина без разделителей, особенно вторая строчка.

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

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

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

53. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –2 +/
Сообщение от Аноним (53), 09-Июл-18, 09:32 
>Они все "в редакторе с подсветочкой" собирались настраивать, поэтому им не нужны удобные способы построчной работы с правилами.

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

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

54. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –2 +/
Сообщение от нах (?), 09-Июл-18, 10:32 
просто ты, обезьянка, не умеешь ни sed, ни grep. Вот тебе vim и "удобен" для тех целей, для которых нафиг не нужен.

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

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

58. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (58), 09-Июл-18, 15:06 
>простыню на пару тысяч (правил и поболее бывает)

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

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

61. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от нах (?), 09-Июл-18, 16:48 
> Я стесняюсь спросить - а зачем столько? Это действительно оправдано?

ну вот ботнеты блокировать ты - вообще не собираешься?

У меня был специфический use-case - QUEUE, там тоже поболее тысячи (и нам никогда не надо было читать эту простыню глазами - достаточно номера строки с нужным нам блоком, если клиент внезапно поехал на другой сервер)

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

72. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (58), 10-Июл-18, 09:26 
>ну вот ботнеты блокировать ты - вообще не собираешься?

А смысл? Сегодня ботнет есть, завтра его попалили, послезавтра хаксор забацал два новых. Там не то что 2k, там 2M не хватит. Кстати, а с чего ты взял, что все ботнеты против на тебя охотятся? В Пентагоне работаешь?

>достаточно номера строки с нужным нам блоком, если клиент внезапно поехал на другой сервер

А всех клиентов и сервера ты наизусть должно быть, помнишь?

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

76. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от нах (?), 10-Июл-18, 14:40 
> А смысл?

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

> А всех клиентов и сервера ты наизусть должно быть, помнишь?

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

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

73. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от yu (??), 10-Июл-18, 10:54 
Шаблонизаторы в данном случае решают. Не все кто умеют sed, grep и awk применяют из везде подряд, особенно там где они не подходят.

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

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

77. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от нах (?), 10-Июл-18, 15:00 
> см. "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.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

81. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от yukra (ok), 10-Июл-18, 15:42 
К тому, что crontab создаёт тебе новый файл где-то в районе /tmp.   И никакого inotify там нет. "Среагирует" ОС только на ":wq" (сохранение и выход), если ты конечно не лазиешь руками мимо crontab'а
Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

2. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +25 +/
Сообщение от Нанобот (ok), 08-Июл-18, 10:18 
для ускорения обработки пакетов в ядре линукс нужно...не допускать попадания пакетов в ядро линукс
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –5 +/
Сообщение от пох (?), 08-Июл-18, 11:09 
ну и что в общем удивительного в таком выводе, если вся "обработка" в ронянии их на пол?

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

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

60. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –2 +/
Сообщение от Ivan_83 (ok), 09-Июл-18, 16:22 
В том что линупs только для загрузки правил нужен - нет ничего плохого или необычного.
В bpf (скорее компилятор правил к нему) никогда не поздно добавить скажем хэш таблицы или бинарный поиск и сортировать массив предварительно, полагаю подобных специфичных оптимизаций уже придумано много для поиска попадания адреса в подсеть из списка.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

62. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от нах (?), 09-Июл-18, 16:53 
> В том что линупs только для загрузки правил нужен - нет ничего плохого или необычного.

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

Ну вон посмотри, если товарищ майор не запретил, слайды по ссылке Солара - товарищ с qратора искренне недоволен тем, что дефолтный таймаут коннтрака для tcp - 5 дней. У меня сессия может висеть открытой и больше - и я совершенно не вижу причин ей рваться, если на дороге оказался шибкоооптимизированный линукс вместо нормального маршрутизатора.

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

75. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Ivan_83 (ok), 10-Июл-18, 13:45 
Дефолтами не довольны все, кто туда заглядывает, ибо универсальных значений не существует.
В венде всё сильно хуже стало со времён ХР/семёрки, возвращаться туда - как добровольно сдаться в конц лагерь.
Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

78. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от нах (?), 10-Июл-18, 15:05 
> возвращаться туда - как добровольно сдаться в конц лагерь.

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

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

12. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +4 +/
Сообщение от Olegemail (??), 08-Июл-18, 11:44 
Статья не про обработку пакетов в ядре, а про их роняние. Вариант XDP роняет пакеты раньше всех других способов, потому победил.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

17. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +1 +/
Сообщение от Аноним (17), 08-Июл-18, 13:39 
Нужно линукс запихнуть в Intel Stratix FPGA
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

29. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Старый одмин (?), 08-Июл-18, 17:37 
Эх, а раньше это была Altera.
Слава богу, их продукт Quartus продолжил жить.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

3. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –9 +/
Сообщение от Лычев Андрейemail (?), 08-Июл-18, 10:19 
ичто? роутерам всё это не поможет. и серверам не поможет, они всё равно падут,потому как всяких интернетвещеё уже миллиарды одновременно ддосить могут, и дальше таких бешеных вещёй и чёкнутых смартфонов только ещё больше становиться.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +10 +/
Сообщение от Начальник (?), 08-Июл-18, 10:39 
Ну вот сходи к CF расскажи как ddos отбивать правильно, кто в теме понимает, что это крутые результаты, а обсирать все могут.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +3 +/
Сообщение от Аноним (5), 08-Июл-18, 10:58 
Откуда вы лезете? Три первых комментария, а все неимоверно тупые и написаны типичными мамиными специалистами.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

57. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +1 +/
Сообщение от Аноним (57), 09-Июл-18, 12:49 
Каникулы
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +5 +/
Сообщение от оттуда (?), 08-Июл-18, 11:10 
Тебе уже ничего не поможет.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

9. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +1 +/
Сообщение от Vitaliy Blatsemail (?), 08-Июл-18, 11:22 
> ичто? роутерам всё это не поможет. и серверам не поможет, они всё равно падут,потому как всяких интернетвещеё уже миллиарды одновременно ддосить могут, и дальше таких бешеных вещёй и чёкнутых смартфонов только ещё больше становиться.

Просто вы, как и многие другие, склонны путать DDoS и DoS.

Первый - достаточно редок и весьма дорог, и в принципе ориентирован на саму сеть и ее железо, а не на операционную систему. Пример - ICMP-флуд. Ну то есть когда вы пингуете миллион ПК, подменяя свой IP-адрес на адрес жертвы, и весь миллион ПК шлет ответы на ПК жертвы и тупо забивает канал. В таких случаях патчи ядра до жопы.

Второй - это когда 1000 VPS-сок использующих дырявый плагин к Джумле, начинают синхронно слать лабуду через POST-запрос на сервер жертвы, вызывая бугурт у апача или нжинкса. Вот таких и можно будет успешно блокировать не напрягая проц как в случае netfilter.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

11. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (11), 08-Июл-18, 11:38 
но в новости так и написано DDoS
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

15. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +2 +/
Сообщение от dry (ok), 08-Июл-18, 13:02 
> Просто вы, как и многие другие, склонны путать DDoS и DoS.
> Первый - достаточно редок и весьма дорог,

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

18. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Vitaliy Blatsemail (?), 08-Июл-18, 13:51 
> Это DDOS то "редок и дорог"?!
> Мьсе живет в каком-то абстрактном розовом мире, ни имеющим соприкосновения с реальностью.

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

25. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +1 +/
Сообщение от KonstantinB (ok), 08-Июл-18, 16:36 
Не, дешевле вроде.
Ассист, судя по материалам уголовного дела и сливам[1], ддосили за 9k в сутки.

[1]https://krebsonsecurity.com/2011/06/financial-mogul-linked-t.../

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

26. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +3 +/
Сообщение от KonstantinB (ok), 08-Июл-18, 16:36 
Опечатался (точнее, забыл отредактировать) - за 1к в сутки, всего 9к за 9 дней.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

93. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от чече (?), 13-Июл-18, 17:57 
почему то у токсина самый дешевый акк на стрессере с NTP,BoostHTTP,методами дудоса OVH и прочим стоит всего 150 рублей в месяц,тысяч далларов не вижу
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

39. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +1 +/
Сообщение от Аноним (39), 08-Июл-18, 19:16 
Боюсь все зависит от цели, заказчика и исполнителя. Тоесть  когда речь идет о ддосе серверов тогоже пентагона  - цена одна, Когда речь идет о ддосе серверов игры Perfect World  или  близовского World of Wrcraft - цена уже другая.   Когда же речь идет о ддосе серверов какойнибудь пиратки   типа  Wowcircle хотябы то уже третья цена. Просто если  пентагон  ддосить   то заказывать будет  "серьезная организация  и  серьезным людям" .  А а ддос серверов  того же  Wowcircle  думаю выполнялся уже  людьми намного более  простыми.

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

33. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +4 +/
Сообщение от angra (ok), 08-Июл-18, 18:19 
> Просто вы, как и многие другие, склонны путать DDoS и DoS.
> Второй - это когда 1000 VPS-сок

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

90. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от тигарэтоя (?), 12-Июл-18, 10:11 
ddos уже давно не дорог. и не особо сложен.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

8. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от Анонимemail (8), 08-Июл-18, 11:12 
Было бы интересно глянуть что за железо использовалось.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от Аноним (11), 08-Июл-18, 11:45 
А это можно использовать каким-то способом для увеличения количества отправляемых пакетов?
Что в линуксе отвечает за отправку пакетов? Можно добиться снижение нагрузки системы при отправки пакетов?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +5 +/
Сообщение от Аноним (14), 08-Июл-18, 12:32 
> Можно добиться снижение нагрузки системы при отправки пакетов?

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

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

21. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +1 +/
Сообщение от solardiz (ok), 08-Июл-18, 15:00 
Интересно, но:

Странно, что не упомянута фильтрация средствами сетевушек 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 это где-то не так.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (17), 08-Июл-18, 17:56 
Они используют Solarflare NIC, они судя по характеристикам еще круче.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

31. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (17), 08-Июл-18, 17:58 
> берем планку в 14,88 Mpps

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

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

32. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от пох (?), 08-Июл-18, 18:18 
ну они вообще, похоже, странные. Либо само это исследование - не для работы, а просто ни о чем, лишь бы был повод для публикации.

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

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

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

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

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

63. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (63), 09-Июл-18, 20:13 
Если блокировать нужно миллионы адресов, вместо обычной таблицы можно использовать какое-нибуть дерево
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

64. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от пох (?), 09-Июл-18, 21:15 
ну, мы где-то даже такое делали, во времена оны, раскидывая теми же iptables сперва по /8, потом /16 и т д, потом уже фильтруя конкретные небольшие блоки, но надо ж понимать,что оно от этого валидные пакеты тоже начинает на пол ронять, просто не успевая гонять их по всем этим бесконечным веткам, поскольку веток вообще-то получается изрядно много (если предположить что сайтик-то кому-то на самом деле нужен, а не только роботам-%там)

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

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

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

68. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Netmapguy (?), 10-Июл-18, 01:15 
>влезет ли оно в отведенную для этого память

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

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

71. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Vkni (ok), 10-Июл-18, 07:43 
А случайный доступ к ней на чтение дорогой (как это ни парадоксально на первый взгляд, на амортизированный доступ на запись - бесплатный).
Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

74. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от yu (??), 10-Июл-18, 11:05 
Но вот никто не запрещает ставить несколько серверов параллельно, шарить на них трафик в зависимости от адреса источника и соответственно не держать все в памяти одной железки
Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

79. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от нах (?), 10-Июл-18, 15:07 
> А случайный доступ к ней на чтение дорогой

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

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

82. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от DPDKguy (?), 10-Июл-18, 16:45 
>А случайный доступ к ней на чтение дорогой

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

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

70. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Vkni (ok), 10-Июл-18, 07:42 
> то есть вопрос о том, влезет ли оно в отведенную для этого память вообще, и насколько будет тормозить - никуда от этого не девается, и опыт подсказывает, что на этом направлении амбец приходит гораздо раньше, чем просто по ронянию пакетов на землю.

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

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

83. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от DPDKguy (?), 10-Июл-18, 16:50 
ну, мы можем лукапить пачками и префетчить.
Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

67. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Netmapguy (?), 10-Июл-18, 01:07 
>какое-нибуть дерево

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

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

80. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от нах (?), 10-Июл-18, 15:09 
> Nyet, это будет fail. Правильнее будет думать о чем-то вроде dir-24-8

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


Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

89. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (89), 12-Июл-18, 09:30 
>dir-24-8

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

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

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

92. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от DPDKguy (?), 12-Июл-18, 18:01 
>А что тогда делать с IPv6?

страдать.

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

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

Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

69. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Netmapguy (?), 10-Июл-18, 01:18 
>фильтрация средствами сетевушек Intel

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

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

34. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (34), 08-Июл-18, 18:36 
На увеличенной картинке черный фон, не видно подписей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

49. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Григорий Федорович Конин (?), 09-Июл-18, 02:12 
там прозрачный фон, просто у кого-то цвет в браузере по умолчанию черный
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

36. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (36), 08-Июл-18, 18:52 
Скоро ожидать наборы платных файлов вида xdp-make_something-ebpf-corp.o, для корпоративных нужд?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

38. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (38), 08-Июл-18, 18:54 
Никогда. Разреверсить тривиально.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

40. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от пох (?), 08-Июл-18, 19:43 
вечно. поскольку совершенно непонятно, какую бы корпоративную нужду оно могло бы удовлетворить.

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

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

44. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (36), 08-Июл-18, 20:45 
Ну не такое же глупое условие я имел в виду. Скорее говорил про сложные правила с возможной заточкой под нужды заказчика.
Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

48. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от пох (?), 08-Июл-18, 23:47 
> Скорее говорил про сложные правила с возможной заточкой под нужды заказчика.

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

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

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

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

50. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от RotarenegeD (?), 09-Июл-18, 02:39 
это называется нанять аутсорсера для написания правил.. но по хорошему скорее всего придётся штатного специалиста держать всёравно..
Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

65. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от пох (?), 09-Июл-18, 21:18 
нет, это называется подписка на наборы правил. Существует десятки лет, в том числе для таких правил, которые вполне человекочитаемы - и ничего, платим. Потому что это не "нанять аутсорсера", а "построить сеть honeypot'ов, наладить сбор паттернов, организовать круглосуточную работу по сбору, классификации, обработке и тестированию (потому что можно ненароком и лишнего чего отрезать)".

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

37. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (38), 08-Июл-18, 18:53 
fpga всё равно вне конкуренции.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

45. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Anonymous_ (?), 08-Июл-18, 21:41 
Да клали все с прибором на FPGA.
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

46. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от Зеленая слизь на продакшен Линухе (?), 08-Июл-18, 22:03 
Майню на ASIC у тебя в медиаплеере
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

51. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (-), 09-Июл-18, 06:50 
Майню на ASIC у тебя в вибраторах
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

52. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от qweoemail (?), 09-Июл-18, 09:10 
"Приложение" значит "прикладная программа". Не стоит называть так хотя бы совсем уж служебные вещи, вроде заглушки, помянутой в новости!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

94. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Мимокрокодил (?), 17-Июл-18, 11:47 
Прикладная программа делает полезное действие и не важно какая она в плане скоупа, узерспейсная или системная.
Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

85. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (85), 11-Июл-18, 04:39 
Очень интересно...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

86. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  –1 +/
Сообщение от vantoo (ok), 11-Июл-18, 13:45 
Могу заблокировать хоть миллиард пакетов в секунду простым выниманием кабеля.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

87. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от нах (?), 11-Июл-18, 14:40 
плохая попытка, грант не дадут :-(
Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

88. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Аноним (88), 11-Июл-18, 14:47 
> Могу заблокировать хоть миллиард пакетов в секунду простым выниманием кабеля.

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


Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

95. "Эксперимент по настройке Linux для блокирования 10 млн пакет..."  +/
Сообщение от Анонимemail (95), 15-Сен-18, 21:47 
Ненавижу гребаный cloudflare. Чтоб им там подавиться своей гугл-капчей и вечными трекерами! Зачем делать свою капчу? Лучше пусть гугл заплатит нам за то что наши рабы ему будут дорожные знаки, книги, карты читать. Глядишь - за пару дней на 22ю машину накопится.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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