DDOS Защита ресурсоемких операций

Значит речь о конкретном типе DDOS-атак на ресурсоёмкие страницы поиска. Вернее о реализации защиты последних.
Даже в случае использования сфинкса и аналогов для организации поиска по индексам, как мы знаем, все равно операция остается весьма ресурсоемкой.
Допустим речь идет о разработке нагруженной системы с рисками атак непосредственно на страницу сложного параметрического поиска.
Поделитесь своим опытом и видением решений для защиты этих страниц.

Допустим, выдачу по наиболее частым запросам мы будем кешировать, но при этом, в случае с DDOS все равно придется делать выборку (с индексов сфинкса или напрямую с бд). Не кешировать же все результаты по всем запросам ... или это может быть выходом?
Например, - кешировать результаты по всем запросам в течении часа, после чего кэши низкочастотных запросов обнулять.

Знаю, что есть подход к реализации защиты поиска, избавляющий от необходимости кеширования и позволяющий показывать живые результаты. Это постановка задания на поиск в очередь и поочередное а не параллельное выполнение их сервером. Реализовывал-ли кто-то подобный подход? Интересует как архитектурно должно выглядеть готовое решение.
В моем представлении может работать так:
1. Записываем запрос в таблицу очереди заданий в БД
2. Информируем пользователя о том, что задание поставлено в очередь (визуальную реализацию сейчас не берем: вариантов много)
3. Запрос на поиск от одного юзера может быть только один (ну или n-ое количество). Периодически аяксом пинаем скрипт проверяющий очередь запросов. Если очередь дошла до запроса юзера - формируем выдачу, удаляем задание из очереди.
Итог: при DDOSе поиска останемся без поиска а не без сайта. Точнее даже без поиска мы не останемся: будет работать, но медленно, проходя через тонны мусорных запросов.

Имеет-ли право на жизнь подобная реализация или есть более элегантные решения?

(Отредактировано автором: 28 Марта, 2013 - 09:26:03)

Как бэ от ддоса нужно средствами сервера защищаться (файрволы всякие и т.д.), на php серьезную защиту не построишь.

Как вариант, перед каждым выполнением скрипта делать sleep на секунду-две, тогда нагрузка будет не слишком высокая. Ну и слишком частые запросы банить по ip...

(Отредактировано автором: 28 Марта, 2013 - 09:22:20)

Встаёт вопрос - как идентифицировать такого "пользователя"? Пользователь чего - очереди? Тогда он ничем не отличается от того, что вызвал проверяющий ajax-триггер.
Не очень понимаю, как Вы собираетесь это делать - а, поскольку в схеме это один из ключевых моментов, то всё, к сожалению, разваливается. Поясните, пожалуйста, вероятно, я не совсем верно понял.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Если это не зарегистрированный пользователь, тогда использовать в качестве идентификатора его запросов сессии. Выстраиваем, к примеру хеш из ip+браузер пишем пользователю в куку и в бд. Этим в принципе и пользуюсь если нужно как-то работать с незарегистрированным пользователем сайта. На каком этапе писать куку это уже вопросы конкретной реализации.
1.Пользователь сформировал запрос, нажал кнопку поиск.
2.В таблице заданий появляется идентификатор пользователя + сам поисковый запрос (или не появляется если от него задание уже поступало и прочие "или" конкретной реализации)
3. При аякс-запросах проверки очереди заданий передаем пользовательскую куку для идентификации задания.
А есть-ли смысл четко привязывать задание к пользователю через идентификатор? Наверно есть только в контексте задачи подсчета заданий поиска от конкретного посетителя.
В простом варианте вполне достаточна будет самого запроса. Ведь что такое поисковый запрос?
Это:
а. - параметры параметризованного запроса
б. - поисковая фраза.
Возможно, будет достаточно, при аякс-запросе искать задание по ключевой фразе, которую передаем с клиента. Тогда таблица заданий примет простейший вид:
id | request
4. Если задание 1 в очереди - выполняем, удаляем. Если нет - передаем номер в очереди.

(Отредактировано автором: 28 Марта, 2013 - 10:42:24)

Вы уверены, что речь идёт о DDoS? Подделать это не стоит никаких усилий, передать в куках можно всё, что угодно. Да хотя бы делать запросы с пустыми куки (нельзя ведь это отфильтровывать - если приходит запрос с пустыми куками - это просто "новый" пользователь, которого нужно считать корректным и обрабатывать, впоследствии уже высылая куки).

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

Вариант решения с защитой от DDoS никогда не был "изящным" - и никогда не решался путём только приёмов в веб-приложении. Наиболее простой вариант - если важно выделить критичные части наподобие поиска:
0. Разделить функционал на OLAP/OLTP - например, БД.
1. Через OLAP (с максимальным индексированием) должны работать все части, которые используют поиск.
2. Репликация OLAP<-OLTP - тут всё и так ясно, схемы стандартны, вопрос лишь в том, насколько важны актуальные данные, и, если важны, то за какой период.

Тогда имеем, что ресурсы серверной системы будут распределены, и даже в самом худшем случае (OLAP не выдержал), произойдёт отказ в обслуживании только поисковой части. Достигнуть же этого сложнее, так как, во-первых, индексирование намного лучше (а этого можно достигнуть, потому как там происходят только выборки) - то есть, и быстродействие тоже, а во-вторых, нет конкурирующих запросов из транзакционной части приложения.
Минусы тоже очевидны - по сути, это дополнительные мощности, правда, более правильно применённые. Но DDoS в любом случае - атака на мощности серверных систем, поэтому без их защиты дело решить на 100% - не выйдет.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

А не стоит задачи не давать это подделывать. Ну подделает, ну будет добавлена задача в очередь. Суть в том что сервер будет выполнять всего одну задачу на поиск одновременно. 1 запрос. В простейшем случае, при отправке поисковой формы формируется и сразу выполняется запрос на поиск в бд одновременно таких запросов будет поступать неограниченно количество и сервер будет пытаться выполнять их все. А выполнение поиска может повесить сервер даже, скажем при небольшом количестве одновременных запросов (сложный параметризированный поиск на виртуальном хостинге, к примеру, или слабом VPS).
В случае же, когда эти запросы будут стоять в очереди (в отдельной таблице БД), единовременно будет выполняться только 1 сложный поисковый запрос, а остальные будут ждать в очереди. Будут идти только нересурсоемкие операции записи, поиска по индексу и удаления заданий из одной таблицы, что, согласитесь, несравнимо по затрачиваемым ресурсам при поиске в бд по полнотекстовому индексу с 10 дополнителными параметрыми и 5-тью джоинами таблиц.
Спору нет, что если ресурсов для DDOS хватает - вполне достаточно будет просто открытия любой некешированной страницы, или атакующего вообще не будет интересовать время формирования страницы если он тупо способоен сгенерировать трафика на 1+гб/c, но если не обезопасить к примеру страницу поиска на уровне приложения, повесить какой-нибудь простой интернет магазин можно и с всего одной машины и пары десяткой запросов с разных IPов.
Очень может быть что я в чем-то из этого не прав или что-то не понимаю. Тогда прошу объяснить в чем я не прав.

(Отредактировано автором: 28 Марта, 2013 - 11:16:30)

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

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Если я правильно понял, то вы говорите о том, что не важно какой сложности будет поисковый запрос при DDOS, если это подготовленная к данном сайту атака, то она может быть нацелена на то, чтобы повесить СУБД посредством записи большого числа заданий в таблицу очереди поиска, что при отсутствии ограничений все равно повесит сервер.
В таком случае (это подразумевалось) что количество заданий на поиск в бд должно быть ограниченно. В случае достижения максимума записей (к примеру, 100) сервер перестает принимать задания и отдает кешированную запись о достижении максимума заданий и не осуществляет обращений к бд.
Так решается проблема использование бд при добавлении задачи на поиск.
Остается проблема, касающееся необходимости проверки очереди задачи на поиск по идентификатору пользователя (допустим все идентификаторы подделаны и без труда генерируются). Задача решается кешированием очереди запросов. Мы можем отдавать её статикой из кеша скажем в 1 минуту:
1. Аякс-запрос очереди задачи
2. Отдаем из кеша очередь. Пользователь получает инфу, что он, к примеру 10
3. Пользователь вновь запрашивает позицию...
4. Пользователь 1 в очереди - выполняем поиск, создаем новый кеш очереди.
Ещё раз повторю, что речь идет о конкретном типе атак на конкретные ресурсоемкие страницы, при которых задача нарушить работу сайта может быть решена малым трафиком. Понятно, что при условном отсутствии в ограничении мощности можно не быть столь изобретательным в запросах к атакуемому серверу. Имхо, во многих нагруженных ресурсах, в которых не применяются или применяются указанные в предыдущем посте технологии, задача поиска должна выполнятся аналогичным образом.

(Отредактировано автором: 28 Марта, 2013 - 12:40:48)

Ответ достаточно прост: http://nginx[dot]org/ru/docs/http/ng[dot][dot][dot]_req_module[dot]html

-----
Шта? Репозиторий?

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

(Отредактировано автором: 28 Марта, 2013 - 12:53:36)

Какая нагрузка на БД? Ты страницу всеравно генеришь с этими запросами.
Нжинкс не пропустит запросы СТРАНИЦ с одного айпи чаще чем ты ему укажешь.
Причем тут конкретно БД?
Или тебя по порту 3306 ддосят?
Закрой его фаерволом и разреши только локальные подключения, или только тем кому можно.

-----
Шта? Репозиторий?

А если нет доступа к конфигу сервера и конкретно этого модуля?
Опять же, если правильно понял, в это случае ограничение ставятся на обработку запросов. тем самым фильтруется их количество, а когда количество запросов превышено - 503.
Допустим есть страница search.php
Допустим прописываем в настройке модуля ограничения по запросу к ней. Точнее вы прописать вряд ли сможете, потому что не знаете число параметров (поиск параметрический и число параметров может динамически изменяться).
Минус в том, что мы сразу отдаем 503, если запросов поступило 100, при этом запросможет быть таким:
search.php?key=word
или таким:
и search.php?key=other_word&par1=123=par2=inpack&....

(Отредактировано автором: 28 Марта, 2013 - 13:03:18)

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

-----
Шта? Репозиторий?