LINUX.ORG.RU

Изобрёл алгоритм защиты от флуда. Покритикуйте.

 


1

2

Велосипед скорее всего.

Алгоритм повышения стоимости операций для клиента с сохранением низкой стоимости для сервера.

Пример где это нужно: хочется зарегать учётную запись без sms, email и т.п., но надо избежать флуда регистраций.

  1. В начале процедуры регистрации генерим на сервере 64КБ рандома.
  2. Запоминаем 8 случайных кусков по 8 байт из этих 64кб рандома и смещения до них.
  3. Отправляем юзеру данные 64кб и забываем эти 64 кб.
  4. Далее с интервалом в секунду посылаем юзеру запросы «дай 8 байт со смещения N», где очередное N - какое-то из запомненных нами на шаге (2).
  5. Юзер не знает что мы запомнили на шаге (2) и, таким образом, что сервер может спросить и вынужден хранить всё.
  6. Серверу нужно хранить только 8*8 байт.
  7. «с интервалом в секунду» - чтобы инициатива о длительности процедуры была полностью в руках сервера. Если клиент ответил раньше - отпинываем его совсем.

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

Хочется узнать:

  1. Как называется велосипед, который я только что изобрёл, у нормальных людей.
  2. Что можно улучшить.
  3. Альтернативы этому подходу.

Говнокод и издевательство над юзерами

Идея больная

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

anonymous ()
  1. В начале процедуры регистрации генерим на сервере 64КБ рандома.

Это тяжелая операция

  1. Отправляем юзеру данные 64кб и забываем эти 64 кб.

Это трафик.

Тебя за (d)dos’ят.

anonymous ()

Как называется велосипед, который я только что изобрёл, у нормальных людей.

Proof of capacity

Что можно улучшить.

Хранить только AES ключ, а «случайные числа» генерировать при надобности просто шифрованием номера блока.

Альтернативы этому подходу.

Proof of <anything-else>.

i-rinat ★★★★★ ()
Ответ на: комментарий от Twissel

В википедии. :-)

Там же из названия всё должно быть понятно. Зачем ещё что-то читать?

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Proof of capacity

Я тут подумал ещё, и осознал, что обычно proof-of-something подразумевают публичность, потому что возникли в контексте криптовалют, которые распределённые. Так что термин не очень хорошо подходит. Но я не знаю более подходящего выражения.

i-rinat ★★★★★ ()
Ответ на: комментарий от vvn_black

А потом юзер закрыл браузер… И что страшного произошло?

igloev ()
Ответ на: комментарий от anonymous

Говнокод и издевательство над юзерами

Идея больная

Каптча.

Чем именно капча лучше? Могу сказать чем лучше мой способ: от юзера не требуется думать/разгадывать, а только нажать кнопку и подождать 10 сек, наблюдая за прогрессбаром.

igloev ()

Это куцый вариант «proof of space», но примененный не по назначению.

Недостатков примерно два:

  • генерация и передача 64К рандома - это дорого и хорошая основа для DDOS (ибо write amplification).
  • есть масса других задачек-загадок, которые можно потребовать решить на стороне пользователя.

Один из вариантов = предложить пользователю подобрать N байт для получения заданного дайджеста SHA3 (при заданном суффиксе) и т.п. На сервере достаточно хранить только эти N байт.

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от igloev

Генерить медленно. Не торопясь.

Соединение с незарегистрированным случайным прохожим будет висеть пока будет «неторопясь генериться»?

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

Джипег генерится каждый раз или статичный файл, который может закешировать прокси?

Джипеги всем прохожим раздаешь или только зареганым пользователям?

anonymous ()
Ответ на: комментарий от Deleted

Один из вариантов = предложить пользователю подобрать N байт для получения заданного дайджеста SHA3 (при заданном суффиксе) и т.п. На сервере достаточно хранить только эти N байт.

Это много кто предлагал, хоть тот же MS. И не взлетело по причине, что в те времена, до криптовалют был просто стрёмно просить весь мир жечь без полезной работы электричество. Было много разговоров, что неплохо бы выполнять вычисления, полезные для мира, от поисков лекарств до внеземных цивилизаций. Вот только есть проблема — задач, которые для сервера по проверке бесплатные и легко параллелятся наделать сложно, никому не нужны задачи, когда для проверки надо проводить теже вычисления, что и провёл клиент.

vodz ★★★★★ ()
Ответ на: комментарий от igloev

Генерить медленно. Не торопясь.

Количество одновременно открытых TCP-соединений - ресурс весьма ограниченный

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

Но ты же не будешь джипег бэкэндом раздавать, и соединение нормальный веб-сервер будет разрывать при большом потоке запросов. К тому же после первого запроса он попадет в кэш ФС и последующие обращения будут отчень быстрыми.

annulen ★★★★★ ()
Ответ на: комментарий от vodz

Один из вариантов = предложить пользователю подобрать N байт для получения заданного дайджеста SHA3 (при заданном суффиксе) и т.п. На сервере достаточно хранить только эти N байт.

[…] Вот только есть проблема — задач, которые для сервера по проверке бесплатные и легко параллелятся наделать сложно, никому не нужны задачи, когда для проверки надо проводить теже вычисления, что и провёл клиент.

Вы видимо что-то неверно поняли или неверно додумали.

Серверу достаточно сгенерировать 3-8 псевдо-случайных байт (но неведомых для пользователя), добавить к ним 8-13 байт суффикса (его можно обновлять раз в минуту-час) и посчитать хэш от этих 16-ти байт. Соответственно при проверке ответа еще раз посчитать хеш. Это копейки.

А на стороне пользователя придется подбирать хеш, это на много порядков более сложная задача (с каждым «секретным» битом усложняется в 2 раза).

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Вы видимо что-то неверно поняли или неверно додумали.

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

vodz ★★★★★ ()
Ответ на: комментарий от Deleted

Речь о том, что задача подбора части хеша не приносит пользы человечеству.

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Да. Запутанно.

Я всегда считал, что форум не место для идеального выражения и прочей эпистолярности. И вообще, как 5 часов спать уже бы надо было б. Но вам же удалось распарсить! А общий уровень местного парсенья удручает :(

vodz ★★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от Deleted
  1. Про DDOS выше отвечено: заддосить можно запрашивая 100КБ jpeg фотку.
  2. sha3-и-всё-такое - оно дорого по процу. Смартфоны будут плавиться, а десктопы раскалывать за полмикросекунды.
igloev ()
Ответ на: комментарий от vodz

удалось распарсить

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Я действительно криво написал вот тоже самое?

Да. Запутанно.

Скорее неожиданно. Я действительно неверно понял ваш ответ.

Идея-то конечно (мягко-говоря) не новая, но в контексте «защиты от флуда» я честно не ожидал упоминания поиска инопланетян )

Deleted ()
Ответ на: комментарий от annulen

Количество одновременно открытых TCP-соединений - ресурс весьма ограниченный

Нам пофигу, на что они тратятся. Клиент - это всегда 2-4 keep-alive соединений, которые держит chrome. Что он через них делает уже не важно - регистрируется, сидит на форуме и т.п.

igloev ()

Алгоритм повышения стоимости операций для клиента с сохранением низкой стоимости для сервера.

но по факту всё наоборот, генерить 64кб настоящего рандома на каждого клиента это очень затратная операция без аппаратного генератора, а клиенту хранить 64кб ничего не стоит

Harald ★★★★★ ()
Ответ на: комментарий от i-rinat

что код плохо читаемый, когда он читается плохо.

Большинство кода перед пубикацией вылизывается, долго и кропотливо. Если код плох, то это хороший индикатор, что писатель в принципе вряд ли добросовестно его писал. Но его тексты в рассылках и прочих форумах вовсе не показатель, там можно и отписываться короткими и едкими фразами, а можно оффтопить не по делу, длинно и запутанно, ибо не вылизано же.

У меня по теме есть презабавная история и даже не оффтопик, как я сломал Линуксом вот такую задачу, где авторы клялись и божились, что они считают рендер для мультика. На целую статью тянет.

vodz ★★★★★ ()
Ответ на: комментарий от Harald

генерить 64кб настоящего рандома

Что вы привязались к этому «настоящему рандому»? Вроде ТС об этом не педалировал.

vodz ★★★★★ ()
Ответ на: комментарий от igloev

Клиент - это всегда 2-4 keep-alive соединений, которые держит chrome

Браузер будет держать столько keep-alive соединений, сколько ему дадут, в случае атаки веб-сервер позакрывает лишние

annulen ★★★★★ ()
Ответ на: комментарий от igloev
  1. Про DDOS выше отвечено: заддосить можно запрашивая 100КБ jpeg фотку.

Нет, это разные вещи.

jpeg у вас статический и будет в кеше. А 64К рандома нужно генерировать, т.е. выделить память, записать в память, отдать клиенту, отследить конец передачи и освободить. Это выйдет в ~10 раз дороже, т.е. у вас первые шаги дороже для сервера, и растет эта стоимость с обоих сторон одинаково и линейно.

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

В примере с SHA3 вы можете просить подобрать N бит (даже всего 1). Таким образом, регулируя стоимость по степени двойки. Ну и есть масса других дорогих по-вычислениям «загадок».

Кроме этого, подбор на стороне клиента может предполагать построение rainbow-таблиц (по префиксу или другим параметрам генерируемых сервером).

Deleted ()

Фишка капчи именно в том что ее прохождение нельзя (сложно) автоматизировать, а у тебя автоматизация лежит в основе.

64кб очень мало, на фоне питона их даже не заметят :)

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

Предлагаю сдеать платный постиг, за крипту. И чем интенсивнее общий постинг тем дороже стоит пост.

KillTheCat ★★★★★ ()
Ответ на: комментарий от Deleted

генерация и передача 64К рандома - это дорого и хорошая основа для DDOS (ибо write amplification).

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

Если же это сайт на хостинге и доступа к звуковой карте или аппаратному генератору нет, то рандом можно генерировать на отдельном ПК откуда он будет забираться сервером по мере надобности.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 2)
Ответ на: комментарий от vodz

Я действительно криво написал вот тоже самое?

А главное оффтопное, потому что твой это не техническое возражение на предложенную идею.

torvn77 ★★★★★ ()
Ответ на: комментарий от Deleted

Это выйдет в ~10 раз дороже, т.е. у вас первые шаги дороже для сервера, и растет эта стоимость с обоих сторон одинаково и линейно.

У ТС видимо та идея, что ‘‘стоимость’’ времени меньше ‘‘стоимости’’ ОЗУ.

Сервер расходует время и только на короткое время ОЗУ, которое к стати можно съэкономить пересылая тестовую последовательность блоками.

А вот клиент будет расходовать И время и ОЗУ, которого у него не 64 ГБ.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от KillTheCat

Предлагаю сдеать платный постиг, за крипту. И чем интенсивнее общий постинг тем дороже стоит пост.

Тоже вариант :)) Только тут вот какая проблема, если крипту клиент будет майнить, то что помешает сделать ддос с вайниванием всего пула крипты атакующим.

А если использовать реальную крипту, которую уже надо не майнить, а покупать то минимальная цена, при которой ддосить будет не выгодно может оказаться слишком большой.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от torvn77

А главное оффтопное, потому что твой это не техническое возражение на предложенную идею.

Если идея старая и не юзается, то надо объяснять причину. Вот вы знаете, ртутный градусник — очень хорош, а ртутный выпрямитель так вообще...

vodz ★★★★★ ()
Ответ на: комментарий от vodz

Если что то ртутный и сейчас используется в энергетике.

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

torvn77 ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

SZT ★★★★★ ()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от torvn77

Если что то ртутный и сейчас используется в энергетике.

Ну а криптовалюты тоже не умерли.

А приведённая тобой причина имеет сугубо историчнское значение,

Доо, и потому надо назло дидам сделать ровно наоборот. Впрочем, типичненько в расуждениях на данном ресурсе.

из неё ни как не следует что обсуждаемый способ борьбы с ддомом плох сам по себе как таковой.

Я всё никак не пойму, вы действительно тупите, или просто так хочется чего-то возразить, что на подумать время не остаётся. Что трудного понять в том, что если некоторая идея известна давно, но не применяется (для тупых — это слово в настоящем времени), то полезно узнать почему?

vodz ★★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vodz

Что трудного понять в том, что если некоторая идея известна давно, но не применяется (для тупых — это слово в настоящем времени), то полезно узнать почему?

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

До их и твоей головы не доходит той простой мысли, что логин на сайт осуществляется раз в полгода, а то и реже, и по этому это предложение не приведёт к растрате энергоресурсов, но с другой стороны позволило бы очень легко останавливпть ддос ботнетов путём исчерпания памяти на заражонных soho роутерах, чем к стати ещё и секономило бы и очень много электроэнергии.

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

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 3)
Ответ на: комментарий от vodz

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

torvn77 ★★★★★ ()

Очевидные проблемы:

  1. 64 кб данных для клиента — это очень мало.
  2. Обход твоего алгоритма легко автоматизируется.
theNamelessOne ★★★★★ ()
Ответ на: комментарий от theNamelessOne

64 кб данных для клиента — это очень мало.

В каком смысле-- мало? Ну попробуйте взломать хотя бы из 8 символов пароль. Хорошая и полезная задача :)

vodz ★★★★★ ()
Ответ на: комментарий от vodz

Так речь идёт же не о взломе, а именно о хранении.

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

theNamelessOne ★★★★★ ()
Последнее исправление: theNamelessOne (всего исправлений: 1)
Ответ на: комментарий от KillTheCat

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

А если рассчёты с таймаутами? Т.е. юзеру нужно будет сделать 10 простых рассчётов, но каждый раз в секунду и не чаще.

igloev ()
Ответ на: комментарий от theNamelessOne

а именно о хранении.

Ах, ну да. Зато можно сделать, что каждый топик форума — отдельный мусорный блок для хранения.

vodz ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.