On 25.08.2011 15:45, Igor Sysoev wrote:

>> http://habrahabr.ru/blogs/infosecurity/127029/
>> Убийца Apache у вас на пороге
>>
>> для проксируемых на backend запросов
>> можно поставить proxy_set_header Range "";
>>
>> а как быть с теми запросами,
>> которые nginx сам обслуживает?

> Конкретно на этот запрос (HEAD/много диапазонов/gzip)

в этом скрипте был специально закодирован запрос "HEAD / HTTP/1.1\r\n"
насколько я понимаю, только для того, чтобы уменьшить ущерб от skiddies.

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

> Для запросов с gzip nginx игнорирует Range, подробности здесь:
> http://mailman.nginx.org/pipermail/nginx/2011-June/027691.html

отлично, спасибо. значит аналогичной апачевской
"denial of service vulnerability" в nginx`е нет.

> На запрос GET без gzip с большим количеством диапазонов nginx ответит всеми
> диапазонами. Эти диапазоны будут создаваться по мере отдачи файла.
> Максимальная число диапазонов - сколько может поместиться в
> large_client_header_buffers.

по дефолту 8k. а вот тут - похоже что есть в nginx уязвимость,
которую Michal Zalewski нашел и опубликовал еще в 2007 году:
http://seclists.org/bugtraq/2007/Jan/83

сервера, которые стоят в дата-центрах обычно имеют подключение
к интернету 100 мегабит или 1 гигабит, так что с помощью этого
метода можно будет устроить (D)DoS атаку на nginx таким образом,
что он легко сделает 100% загрузку исходящего канала своими ответами
на такие запросы, даже если на сервере нет "больших" файлов и адекватно
настроены все лимиты limit_req / limit_conn / keepalive_requests и т.п.

второй нюанс - обычно дата-центры дают ограниченное количество трафика
на высокой скорости 100 мегабит, например 5 терабайт, после чего
скорость падает до 10 мегабит или надо оплачивать перелимит.

поэтому - даже если на 100 мегабитах атакующий и не сможет
полностью "положить" канал, - через некоторое время он сможет
из-за лимитов в дата-центре снизить канал сервера до 10 мегабит,
который забить трафиком на 100% атакующему будет уже в 10 раз проще.

================================================================

есть несколько возможных вариантов решения проблемы со стороны nginx:
сразу отвергать запросы с кодом 416 Requested Range Not Satisfiable,
или "склеивать" перекрывающиеся запросы, так чтобы вместо 5х файла
при запросе 0-,0-,0-,0-,0- отдавать только 1х файл, "объединив"
все перекрывающиеся в клиентском запросе области, например.
т.е. что-то аналогичное merge_slashes, только для ranges.

даже если это не так критично для самого nginx`а - таким образом
удалось бы "по дефолту" сделать защиту сразу всех стоящих на ним
апачей, большая часть из которых еще очень долгое время будут уязвимыми

...и дополнительно удалось бы защититься от любой (D)DoS атаки
на сервер по алгоритму http://seclists.org/bugtraq/2007/Jan/83

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru