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

[Gena Makhomed]

On 26.08.2011 14:48, Igor Sysoev wrote:

>> осталась еще одна возможность устроить (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@minotaur.apache.org%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 ?

подозреваю, что на этот вопрос нет однозначного ответа.

например, в сегодняшнем сообщении
http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/browser
разработчики апача говорят, что

The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.

наверное каждый server/location надо будет тюнить отдельно,
в зависимости от размеров и типов отдаваемых файлов, где-то
и более 1 Range будет много, а где-то и 10 Ranges будет мало.

какое следует поставить дефолтовое значение - затрудняюсь ответить.

возможно эту проблему будут исправлять на уровне RFC,
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311

но пока что от ietf нет никакого ответа.

> Например, дёргать диск вышеприведённым алгоритмом можно достаточно
> малыми числами.

да. поэтому где-то max_ranges 1; будет вполне нормально,
чтобы не запрещать пользователю сделать возможность докачки,
но вместе с тем отсечь всех (D)Dos-ботов, а где-то надо будет
тюнить настройки в зависимости от специфического клиентского софта.

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

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

спасибо. workaround для nginx есть, теперь можно спать спокойнее.

-- 
Best regards,
  Gena