On Fri, Aug 26, 2011 at 12:05:03PM +0300, Gena Makhomed wrote:
> 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.

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

> там подразумевается 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

Эта проблема решена в r4036: если суммарный объём всех ranges больше
самого исходного ответа, то ranges запрещаются и выдаётся полный ответ.


--
Игорь Сысоев
http://sysoev.ru

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