ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Убийца Apache у вас на поро ге



On Fri, Aug 26, 2011 at 02:28:10PM +0300, Gena Makhomed wrote:
> On 26.08.2011 12:44, Igor Sysoev wrote:
> 
> >>> На запрос GET без gzip с большим количеством диапазонов nginx ответит 
> >>> всеми
> >>> диапазонами. Эти диапазоны будут создаваться по мере отдачи файла.
> >>> Максимальная число диапазонов - сколько может поместиться в
> >>> large_client_header_buffers.
> 
> >> по дефолту 8k. а вот тут - похоже что есть в nginx уязвимость,
> >> которую Michal Zalewski нашел и опубликовал еще в 2007 году:
> >> http://seclists.org/bugtraq/2007/Jan/83
> 
> ...
> 
> >> ...и дополнительно удалось бы защититься от любой (D)DoS атаки
> >> на сервер по алгоритму http://seclists.org/bugtraq/2007/Jan/83
> 
> > Эта проблема решена в r4036: если суммарный объём всех ranges больше
> > самого исходного ответа, то ranges запрещаются и выдаётся полный ответ.
> 
> отлично, спасибо.
> 
> но осталась еще одна возможность устроить (D)DoS-атаку через nginx:
> 
> если у кого-то на сервере лежит большое количество "крупных файлов", 
> например, с (мульт)фильмами - даже если на этом сервере есть 80 гиг
> оперативной памяти и файловая система уже не RAID-Z/ZFS -
> 
> такой сервер всеравно могут за-(D)DoS`ить, давая в 8k строке Range
> запрос, который будет вынуждать nginx совершать очень большое число
> операций seek - один байт в начале файла, один байт в конце файла,
> потом один байт в начале файла + смещение в $offset байт,
> один байт в конце файла - смещение в $offset байт и т.д.
> 
> $offset - это например, 1 мегабайт или 512 килобайт и т.п.
> 
> в результате - производительность дисковой подсистемы ввода/вывода
> сервера резко упадет из-за такой создаваемой через nginx нагрузки
> и сервер уйдет в состояние denial of service для всех клиентов.
> 
> даже большое количество оперативно памяти для файлового кеша тут
> не спасет - потому что каждый новый запрос к этому серверу будет
> к "холодному" контенту, которого еще нет в файловом кеше системы.
> 
> причем, суммарный объем отдаваемого контента будет гораздо меньше,
> чем полный файл, так что защита из r4036 в этом случае не сработает.
> 
> причем, для Apache в сообщении от Wed, 24 Aug 2011 16:16:39 GMT
> http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3C20110824161640.122D387DD@xxxxxxxxxxxxxxxxxxx%3E
> предложили такой workaround: "...detect a large number of ranges
> and then either ignore the Range: header or reject the request".

Вопрос, что такое "large number" - 2, 3, 10 или 100 ?
Например, дёргать диск вышеприведённым алгоритмом можно достаточно
малыми числами.

> для nginx - наверное тоже можно сделать аналогичный workaround
> этой уязвимости с помощью директив из ngx_http_rewrite_module?

server {

    if ($http_range ~ "(\d*\s*-\s*\d*\s*,\s*){5,}") {
        return 416;
    }


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

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


 




Copyright © Lexa Software, 1996-2009.