войти зарегистрироваться

Информационная безопасность whois

индекс
212,69

Slow Lori атака на веб-сервер Apache

Slow Lori — это животное, живущее в юговосточной Азии и известное своей медлительностью и размеренными движениями. По нему была названа новая DoS и DDoS атака на веб-сервер Apache.

image

Данный тип атаки был обнародован специалистом по безопасности RSnake 17 июня и подробно описан на странице http://ha.ckers.org/blog/20090617/slowloris-http-dos

Атака заключается в очень медленной посылке все новых и новых HTTP заголовков в рамках одного HTTP запроса, никогда его не завершая.

Поскольку Apache выделяет ресурсы для запроса очень рано, то на один такой запрос тратится «полноценное» кол-во ресурсов. Такое же, как и для обычного запроса.

Как известно, Apache использует для обработки запросов или процессы или смесь процессов с нитями. Использование нитей позволит отсрочить смерть, но так или иначе Apache упрется в ограничение по памяти или ограничение, заданное администратором.

Что самое неприятное, Slowlori атака не оставляет никаких следов, кроме огромного количества открытых cоединений со статусом ESTABLISHED. Не будет никаких записей даже в access_log-е.

Первоначально разработчики Apache не очень активно отреагировали на сообщение RSnake в список рассылки, ответив ему что данная атака давно известна и является минусом не самого веб-вервера, а скорее TCP-стека. Однако, в дальнейшем разработчики веб-сервера Apache зашевелились и начали активно обсуждать пути решения проблемы.

Веб-серверы основанные на state machine не подвержены данной атаке. Таким образом простейшим способом обезопасить себя от Slowlori атаки является использование двухуровневой архитектуры, когда первым на пути является веб\прокси сервер, основанный на state machine, такой как nginx.

Другими возможными решениями являются Access HTTP фильтры в FreeBSD, использование хитрых правил на файрволе, которые, в то же время, могут отсечь и легитимных медленных пользователей.

Кроме собственно изменения архитектуры, разработчики Apache согласны в необходимости внедрения более мелких, локальных таймаутов. На данный момент в Apache 2.2 реализован один обший таймаут, влияющий на практически все IO действия.

Более подробную информацию можно получить в списке рассылки httpd-dev и в пока не открытой для публичного доступа статье на LWN.
+71
26 июня 2009, 12:30
mkevac

комментарии (92)

  • опа :) Они только проснулись? :)))
    nginx самое то!
    • У меня только один вопрос, как у человека который nginx не ставил и не работал.
      Он может быть полноценной заменой apache? (например для WP и PHPBB3 )
      • тут же написано что использовать nginx как прокси перед апачем.
        • Да это я понимаю, просто может nginx работать как самостоятельный web сервер?
          Минусовать не надо, обычный житейский вопрос.
          Или лучше использовать связку как прокси?
          • Да можно :)
            я использовал. пхп у меня работал как fastcgi, причем лучше использовать патч php-fpm
            • А есть статьи хорошие на эту тему?
              Просто я обычно использую несколько вещей:
              WP,PHPBB3, Simple Machines.

              Да еще иногда CRM SugarCRM.
              Просто если Nginx сможет полностью заменить apache, это классно!
              • www.google.com/search?client=opera&rls=en&q=nginx+wordpress

                Ну и так далее.
                • Да нет Гуглом пользоваться умею, просто думал мало ли кто то имеет хорошую статью на примете. Есть хороший сервис letmegooglethatforyou.com/ =) Правда что то он щас не работает T_T
              • ну тут все уже зависит от вас. Сможете переписать mod_rewrite правила — значит хорошо, нет — извольте
                • там не сложно переписать:
                  1) надо в нгинксовой версии добавить слеши в начале
                  2) RewriteRule заменить на rewrite
                  3) [L] заменить на last;

                  Пример апача:
                  RewriteRule  ^(en|de)/album/(.+?)/(.+?)/(.*)$ album.php?cn=$1&albid=$2&albname=$3&$4 [L]

                  нгинкс
                  rewrite ^ /(en|de)/album/(.+?)/(.+?)/(.*)$ /album.php?cn=$1&albid=$2&albname=$3&$4 last;
                  • в нгинкс-варианте не должно быть пробела между ^ и /:
                    rewrite ^/(en|de)/album/(.+?)/(.+?)/(.*)$ /album.php?cn=$1&albid=$2&albname=$3&$4 last;
          • НЛО прилетело и опубликовало эту надпись здесь.
            • А что такое nginx-passenger? Google не сильно помог.
              • НЛО прилетело и опубликовало эту надпись здесь.
            • Вы про запускалку fastcgi процессов из пакета lighttpd (spawn-fcgi или как его там) или про что-то другое?
              • НЛО прилетело и опубликовало эту надпись здесь.
                • Никогда не понимал, почему на неё будто молятся и ставят ради неё пакет лайти в добавок к nginx. Она же довольно тупая и по возможностям не отличается принципиально от штатного start-stop-daemon.

                  Хоть хабратопик в духе разрушителей мифов пиши :-)
                  • НЛО прилетело и опубликовало эту надпись здесь.
                    • При том, что сама spawn'илка не делает ровным счётом ничего полезного и почти полностью полагается на штатный механизм PHP.
                      Это меня и удивляет.
                      • НЛО прилетело и опубликовало эту надпись здесь.
                  • Есть ещё патч php-fpm — по возможностям гораздо более интересный. Я лично его использзую, доволен.
                    • Да, согласен полностью, php-fpm — хороший, нужный проект.
                  • Приятная новость: 3 месяца назад spawn-fcgi формально отделился от lighttpd в отдельный проект: redmine.lighttpd.net/projects/spawn-fcg. И выпущено уже 3 minor-релиза.
                  • Так точно, поэтому у нас, например, обычный start-stop-daemon в обвязке с gentoo script :-)
          • nginx не имеет механизмов, похожих на htaccess. Всё остальное более-менее можно и переписать.
            • НЛО прилетело и опубликовало эту надпись здесь.
              • Почему?
                • На каждый запрос дёргать N директорий (где N — уровень вложенности) на наличие и/или изменение .htaccess?
                  • тем более в случае с nginx понятие «директория» не такое простое как в апаче.
                  • Понял. Вы про файлик .htaccess на диске.
                    Я почему-то подумал про ограничение доступа вообще, в том числе те что в httpd.conf.
                    • Ну возможности ограничения у него тоже не очень широкие. В LDAP он за паролями точно не полезет :-)
                      • НЛО прилетело и опубликовало эту надпись здесь.
                • НЛО прилетело и опубликовало эту надпись здесь.
                  • habrahabr.ru/blogs/infosecurity/62980/#comment_1743685

                    Но на самом деле это ведь не обязательная функция. Захотел администратор — значит будем дергать. Не включал эту функцию — не будем дергать.
                    • НЛО прилетело и опубликовало эту надпись здесь.
      • Для многих задач может. Если все же нужен Апач, nginx принимает соединения, отдает статические файлы, а динамику передает дальше на обработку Апачу.
        • Спс. Пойду читать больше информации про nginx. Думаю в любом случаи он не помешает.
      • Да.
  • А что на рисунке рука или нога?
    • рука
    • я только щас понял что рука))
    • нога
    • Рука. Это картинка из Википедии.
      • ВикиМедии
        commons.wikimedia.org/wiki/File:Slow_Loris_Female.jpg
    • руга
    • Внимательно присмотревшись понял, что там рука, повернутая ладонью вверх и от камеры.
  • Да кстати можно прямую ссылку на письмо RSnake в рассылке?
  • Може нубский вопрос, но все же:
    IIS такой атаке подвержен?
    • Ща потестим
    • нет. это подробно описано в статье.
    • Не подвержен. Это связано с тем, что IIS использует совсем отличный от других веб-серверов спрособ обработки запросов.
      • Спасибо :)
      • НЛО прилетело и опубликовало эту надпись здесь.
        • Сразу скажу что с ним не работал, рассказываю только по тому что я понял из статей.

          В статьях написано что IIS посылает данные обработчикам не на уровне HTTP запросов, а на уровне сетевых пакетов или группы пакетов. Звучит очень сложно, но, в принципе, реально.
          • Вот отрывок:

            «What IIS does differently, is in the way it handles incoming requests: There is no static tie between a worker thread and a network socket in IIS. Rather, the workers are organized in a pool where they wait for incoming TCP packets (rather than TCP connections as Apache does). These packets are then assigned dynamically to threads. So, an idle connection occupies a socket, but it does not block an entire thread. Thus the web need not be shut down by penny-wielding customers or slowloris.»
        • Судя по википедии, в винде тоже подобие accept-фильтров BSD-шных (сюрприз!) используется. :-)
  • раскрыть комментарий
  • >>Атака заключается в очень медленной посылке все новых и новых HTTP заголовков в рамках одного HTTP запроса...
    Эстонский DoS :)
  • Замените нити на потоки… вроде принятая терминология.
  • Ну да, прям ни кто не знал про эту атаку. 8-\ Самый настоящий баян.
    • Вот и разработчики Apache так говорят, но на самом деле данный тип аттаки гораздо более доступен скрипт-киддисам, чем обычная DDoS атака. В то же время он гораздо дешевле.
      • скрипт-киддисы в данном случае лечатся лимитом на число соединений с одного IP
        • Увы, не все так просто. Существующие модули для ограничения соединений работают не на том уровне обработки запроса.
          Более того, ограничением по IP вы порежете сети, которые сидят за NAT-ом.
          • Netfilter поможет.

            Что касается NAT, то надо просто лимит не слишком маленький ставить, чтобы не мешало нормальной работе. А при атаке лучше пусть сетка за NAT отключится, чем вообще весь апач
  • Данный тип атаки был обнародован специалистом по безопасности RSnake 17 июня

    Вообще, в Update сказано, что он далеко не первый это придумал.

    Ну а на самом деле это классический DoS против любого fork-ающегося сервера без адекватных лимитов и таймаутов. Настолько классический, что преподносить его как что-то новое довольно странно.
    • Можно сказать что RSnake раскрыл глаза разработчикам Apache и поднял шум вокруг этого. Думаю им придется в ближайшее время заняться таймаутами как минимум.
      • Шум поднял и proof-of-concept сделал.

        Атака не новая, новы только шум и инструмент.

        Ну а таймауты/лимиты — это так, workaround. Проблему решает только accept-фильтр на базе state machine (либо в ядре, либо в самом апаче, либо перед апачем).
        • В Apache есть mpm_event, который реализует state machine, но в этом случае не будут работать большинство модулей, в т.ч. mod_php. Все равно придется делать двухуровневую архитектуру.

          Хотя чего уж там, сейчас даже нет реализации mod_php для mpm_worker, — только процессы.

          Вы не в курсе, есть ли какие-то планы по имплементации accept http фильтров в ядре Линукс аналогично тем что есть в ядре FreeBSD?
          • Про планы не слышал, есть khttpd и tux, но я с ними не игрался.
            khttpd даже в mainline 2.4 одно время был.
    • P.S.
      «A computer is a state machine. Threads are for people who can't program state machines.» © Alan Cox
  • Атака заключается в очень медленной посылке все новых и новых HTTP заголовков в рамках одного HTTP запроса, никогда его не завершая
    Какая страшная смерть! (с)
  • > в очень медленной посылке все новых и новых HTTP заголовков в рамках одного HTTP запроса, никогда его не завершая
    > кроме огромного количества открытых cоединений со статусом ESTABLISHED.
    По-моему фразы противоречат друг другу. В рамках одного запроса = одно соединение. Тогда откуда много открытых сокетов? Или я чего-то не понимаю?

    В свое время я клал серваки следующим образом (спокойствие, хозяева были вкурсе):
    1. Находится самая «тяжелая» страница с долгим запросом.
    2. Пишется клиент, который открывает как можно больше соединений с сервером (пару тысяч).
    3. Когда достигнуто максимально возможное значение, по всем посылается http запрос на эту страницу.
    4. Для всех сокетов надо установить таймаут побольше и размер входного буфера 1 байт и не читать ответы от сервера.

    Простой ограничитель числа коннекшнов с одного ip решает проблему.
    • Представьте себе 100 000 соединений (пользователей) и в каждом межденно посылаются HTTP запросы. Получаем 100 000 открытых (ESTABLISHED) соединений. А потому как HTTP запрос еще не завершен, никакой информации в access_log не будет.
      • Пробовал 3 года назад на Apache-1.3 модуль, писавший в access_log только что поступившее соединение, не дожидаясь его завершения; удобно было для отслеживания скачивания больших файлов.
        Однако названия модуля уже не вспомню, увы.
  • Что означает очень медленная посылка HTTP заголовков 10 байт в минуту или сколько?
    • Не так принципиально. Главное то, чтобы таймаут не сработал (вы его ресетите посылкой данных) и чтобы траффик был маленький. Поскольку траффик маленький, не нужны большие затраты на канал.
  • оффтопик: красавица (я про животное) :)
  • была почти такая же ситуация. только не хакеры ддосили, а региональные пользователи с модемами ходили.

    поставили апач на фронтэнд и нагрузка на сервера упала.
    • Может быть nginx? :)
      • да да. это я заработался =)
  • Странно, нас такой фигней пытались валить еще в прошлом году. Nginx, как всегда, помог.
  • скромная pr-реклама nginx?
    • Конечно! Именно для этого я писал пост.
  • Данный тип атаки был обнародован специалистом по безопасности RSnake

    как политкорректно нынче называют хакеров XD
  • вот меня поражают люди, которые ставят минус и никак его не коментируют =/
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.