Буквально пять дней назад в листе рассылки Full Disclosure появился скрипт, по заявлению автора, убивающий Apache начиная от самых старых версий до самых новых.
И он действительно работает. Скрипт killapache.pl запускает в несколько десятков потоков простой запроc:
HEAD / HTTP/1.1
Host: www.example.com
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,<...>,5-1299,5-1300
Accept-Encoding: gzip
Connection: close
В ответ на такой запрос Apache для подсчета Content-Length собирает в памяти длинный ответ из перекрывающихся кусков запрошенного файла, который может занять и занимает заначительный объём памяти. При этом потребление памяти Apache начинает резко расти, как на том графике в начале, что при должном, совсем небольшом, количестве запросов приводит к DoS даже на приличных серверах.
Как же быть?
Если у вас перед Apache стоит nginx, то можно вообще ничего не делать, даже если файлы, для которых возможны описанные выше запросы, не раздаёт nginx, потому как по-умолчанию, по крайней мере на версии 1.1.0, nginx не передаёт загловок Range на проксируемый сервер.
Проверить, уязвим ли ваш сервер к этой атаке легко:
curl -I -H "Range: bytes=0-1,0-2" -s www.example.com/robots.txt | grep Partial
Если на такие запросы отвечает Apache и вы видите 206 Partial Content, значит быть беде.
Запретить nginx проксировать опасный заголовок можно директивой:
proxy_set_header Range "";
Если нет nginx?
Если у вас во внешний мир Apache смотрит напрямую… Вы можете полностью заблокировать проблемный заголовок при помощи mod_headers:
# a2enmod headers
RequestHeader unset Range
Источник
http://habrahabr.ru/blogs/infosecurity/127029/
И он действительно работает. Скрипт killapache.pl запускает в несколько десятков потоков простой запроc:
HEAD / HTTP/1.1
Host: www.example.com
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,<...>,5-1299,5-1300
Accept-Encoding: gzip
Connection: close
В ответ на такой запрос Apache для подсчета Content-Length собирает в памяти длинный ответ из перекрывающихся кусков запрошенного файла, который может занять и занимает заначительный объём памяти. При этом потребление памяти Apache начинает резко расти, как на том графике в начале, что при должном, совсем небольшом, количестве запросов приводит к DoS даже на приличных серверах.
Как же быть?
Если у вас перед Apache стоит nginx, то можно вообще ничего не делать, даже если файлы, для которых возможны описанные выше запросы, не раздаёт nginx, потому как по-умолчанию, по крайней мере на версии 1.1.0, nginx не передаёт загловок Range на проксируемый сервер.
Проверить, уязвим ли ваш сервер к этой атаке легко:
curl -I -H "Range: bytes=0-1,0-2" -s www.example.com/robots.txt | grep Partial
Если на такие запросы отвечает Apache и вы видите 206 Partial Content, значит быть беде.
Запретить nginx проксировать опасный заголовок можно директивой:
proxy_set_header Range "";
Если нет nginx?
Если у вас во внешний мир Apache смотрит напрямую… Вы можете полностью заблокировать проблемный заголовок при помощи mod_headers:
# a2enmod headers
RequestHeader unset Range
Источник
http://habrahabr.ru/blogs/infosecurity/127029/
