Как работает атака Slowloris?
Здравствуйте! Продолжая опубликовать серии статей, посвященные безопасности от заражения компьютерных вирусов, в сегодняшнем выпуске продолжим рассматривать одну из разновидность DDoS атак.
Slowloris — это программа DDoS атаки, которая позволяет злоумышленнику сокрушить целевой сервер, открывая и поддерживая множество одновременных HTTP-соединений между злоумышленником и целью. Многие термины и определения для новичков могут запутать и не придать смысл принцип самой атаки, но я постараюсь выделить отдельные ключевые моменты, чтобы в целом объяснить суть как работает атака Slowloris.
Как работает атака Slowloris?
Slowloris — это атака уровня приложения, которая работает с использованием частичных HTTP-запросов. Атака функционирует, открывая соединения с целевым веб-сервером, а затем сохраняя эти соединения открытыми до тех пор, как это возможно.
Прежде всего, я бы хотел отметить один небольшой нюанс, дело в том, что Slowloris не является категорией атаки, но вместо этого является конкретным инструментом, предназначенным для того, чтобы позволить одной машине снять сервер без использования большой пропускной способности. В отличие от DDoS-атак, основанных на использовании полосы пропускания, таких как усиление NTP, этот тип атаки использует низкую пропускную способность и вместо этого стремится использовать ресурсы сервера с запросами, которые кажутся медленнее обычного, но в противном случае имитируют обычный трафик. Он попадает в категорию атак, известных как «слабые и медленные».
Целевой сервер будет иметь только несколько потоков, доступных для обработки параллельных подключений. Каждый поток сервера будет ожидать завершения медленного запроса, который никогда не прекратится. При превышении максимально возможного количества подключений к серверу на каждое дополнительное подключение не будет дан ответ и произойдет отказ в обслуживании.
Атаки Slowloris происходит в 4 шага:
— Сначала злоумышленник открывает несколько подключений к целевому серверу, отправляя несколько частичных заголовков HTTP-запросов.
— Цель открывает поток для каждого входящего запроса с намерением закрыть поток после завершения подключения. Для того чтобы быть эффективным, если соединение занимает слишком много времени, сервер будет уходить в тайм-аут, освобождая поток для следующего запроса.
— Чтобы предотвратить истечение времени ожидания соединения цели, злоумышленник периодически отправляет частичные заголовки запроса цели, чтобы сохранить его. В сущности говоря, «я все еще здесь! Я просто медленный, пожалуйста, подожди меня».
— Целевой сервер никогда не сможет освободить любое из открытых частичных подключений во время ожидания завершения запроса. После использования всех доступных потоков сервер не сможет отвечать на дополнительные запросы, поступающие от обычного трафика, что приведет к отказу в обслуживании. Ключом Slowloris является его способность вызвать много проблем с очень небольшой пропускной способностью.
Как смягчается атака Slowloris?
Для веб-серверов, уязвимых для Slowloris, существуют способы смягчения некоторых последствий. Параметры смягчения для уязвимых серверов можно разделить на 3 общие категории:
1. Увеличение доступности сервера. Увеличение максимального числа клиентов, разрешенного сервером в любой момент времени, приведет к увеличению числа подключений, которые злоумышленник должен заполнить, прежде чем он сможет перегрузить сервер. Реально, злоумышленник может масштабировать количество атак, чтобы преодолеть емкость сервера независимо от увеличения.
2. Ограничение скорости входящих запросов. Ограничение доступа на основе определенных факторов использования поможет смягчить атаку Slowloris. Такие методы, как ограничение максимального количества подключений, разрешенных одному IP-адресу, ограничение медленных скоростей передачи и ограничение максимального времени, в течение которого клиенту разрешено оставаться на связи, — это все подходы для ограничения эффективности низких и медленных атак.
3. Облачная защита. Использовать службу, которая может функционировать как обратный прокси-сервер, защищая исходный сервер.
Как Cloudflare смягчает атаку Slowloris?
Cloudflare буферизует входящие запросы перед отправкой на исходный сервер. В результате «слабый и медленный» трафик атаки, такой как атаки Slowloris, никогда не достигает намеченной цели.
Если у вас возникли какие-либо вопросы, предложения или пожелания относительно этой статьи или всего блога в целом, тогда жду ваших комментариев, уважаемые друзья!
Блог разработчика Dominus’a
Эксперт в области информационной безопасности Роберт Хансен (Robert Hansen), известный под ником RSnake, сконструировал инновационный инструмент, пригодный для проведения атак типа «Denial of Service» нового поколения. Творение Хансена, получившее имя Slowloris, использует обнаруженную уязвимость в архитектуре серверов Apache и других популярных веб-серверов.
В отличие от DoS-атак «старой школы», которые позволяли подвесить любой веб-сайт путем бомбардировки сервера пакетами данных и возникающих как следствие перегрузки каналов связи, Slowloris позволяет добиться тех же результатов путем отправки относительно небольшого количества пакетов.
Практикуемый современными хакерами подход требует наличия большого количества вычислительных ресурсов. Зачастую для блокирования единственного сайта задействуются тысячи компьютеров, скомпрометированных злоумышленниками. Технология Slowloris обладает минимальными требованиями к ресурсам. «Вам потребуется всего тысяча пакетов для начала атаки, – утверждает Роберт Хансен. – Впоследствии для поддержания сайта в нерабочем состоянии достаточно будет отправлять от 200 до 300 пакетов в минуту. С этой задачей с легкостью справится стандартный персональный компьютер».
Атака Slowloris заставляет атакуемый сервер обслуживать большое количество открытых соединений путем непрерывной отправки незавершенных HTTP-запросов. В случае, если такие запросы отправляются с нужной периодичностью, сервер Apache надолго «погружается в раздумья», ожидая завершения каждого из открытых соединений. При этом сервер не перегружен – процессор может оставаться относительно свободным, просто он не обслуживает следующие подключения и запросы.
Дело в том, что веб-серверы, подобные Apache, предусматривают ограничение на число одновременно открытых подключений. Хансен утверждает, что разработанная им методика может с успехом использоваться для блокирования серверов Apache 1.x, Apache 2.x, dhttpd, GoAhead WebServer и Squid. При этом Slowloris не представляет особой опасности для серверов IIS6.0, IIS7.0 или lighttpd. Эти решения оснащены эффективными механизмами распределения нагрузки и используют «пулы рабочих потоков» (worker pool), позволяющие удерживать любое количество открытых соединений при наличии свободных ресурсов.
Разработчики популярного веб-сервера пока не откликнулись на письмо от обозревателей сайта The Register с просьбой прокомментировать найденную уязвимость. Впрочем, Хансену удалось связаться с организацией и предупредить их об опасности.
Для запуска необходимы следующие модули Perl’a : IO::Socket::INET, IO::Socket::SSL, и GetOpt::Long.
Для установки модулей можно воспользоваться CPAN :
Атака проводимая с ОС Windows не будет иметь особого эффекта через ограничение открытых сокетов в районе 130.
Пример использования :
Уязвимости серверов к медленному чтению
Приветствую.
Хочу рассказать, чем я баловался в свободное от работы в Qualys время. Так как в англоязычном интернете на удивление много шума про Slow Read DoS attack, и уверен что получу здесь много полезной критики и дельных предложений.
В августе 2011 года написал програмку slowhttptest, которая тестирует веб-серверы на наличие уязвимостей, связанных с обработкой медленных HTTP запросов, таких как slowloris и slow HTTP Post. Цель — создать конфигурируемый инструмент, облегчающий работу разработчиков и позволить им концентрироваться на создании эффективных защит, а не ковырянии в питоне, на котором написаны большинство proof-of-concept эксплоитов.
А потом решил попробовать, как реагируют серверы на медленное чтение клиентами HTTP респонсов. На удивление плохо реагируют. Дефолтные apache, nginx, lightpd, IIS отказывают в обслуживании на ура.
А суть такова:
если найти ресурс на веб сервере, который размером больше send buffer-a, который ядро выделило для соединения, в который серверная программа пошлет ресурс, то если каким то образом вынудить ядро не принимать все данные — сервер будет пытаться послать оставшийся кусок данных, занимая ограниченную в размере очередь соединений, процессорное время, память, и свободное время сисадмина. Если забить такими соединяниями всю очередь — сервер, соответственно начнет отказывать в обслуживании быстрым клиентам.
Заставить ядро себя так вести довольно просто и описано было еще в 2008 году ребятами из Outpost24 в методе Sockstress: например, посылать в TCP пакете размер окна равным 0, т.е. у клиента нет места для приема данных. Дизайн TCP правильно подразумевает, что приложение, а не ядро обязано контролировать медленные и мертвые соеднинения. Однако за 4 года никто не пошевелил пальцем.
Sockstress вручную создает пакеты, высчитывает, когда послать очередное подтверждение, чтоб не ресетнуть persist timer на сервере, сложно короче.
Мой метод даже школьник в состоянии реализовать на практике:
Создаете сокет, задаете сравнительно малый размер receive buffer-а на клиенте, посылаете совершенно целостный и нормальный HTTP запрос на картинку размером 100Кб, например. Сервер берет картинку из памяти, дает ядру, чтоб тот передал ее в сеть. Сервер берет кусок картинки и шлет, клиент принимает первые тыщу байт, и говорит стоп, места нету. Сервер poll-ает сокет, пытаясь понять когда он будет готов к записи, а он не готов! Раз в минуту читаете пару байтов из клиентского receive buffer, чтоб TCP стек послал что то отличное от нуля, тем самым создав видимость живого соедниения для файрволов и IDS-ов.
Вот и все. Прошу сильно не пинать, первый технический пост на русском, но хабр нравится, неудержался. Детальное описание можно найти здесь.
P.S. Для предыдущей версии slowhttptest написал вики по-русски, если хоть одной душе интересно, переведу и для новой версии.
Update:
ModSecurity подсуетилась, детально показывают как защищаться:
ModSecurity Advanced Topic of the Week: Mitigation of ‘Slow Read» Denial of Service Attack
Update 2:
Semy указал на ошибки сборки на BSD. Исправил в svn.
Slowloris — DoS Инструмент с низкой пропускной способностью
DoS Инструмент с низкой пропускной способностью: Slowloris
Slowloris — это тип атаки «отказ от обслуживания», изобретенный Робертом «RSnake» Хансеном (Robert «RSnake» Hansen), который позволяет одной машине снести веб-сервер другой машины с минимальной пропускной способностью и побочными эффектами для несвязанных сервисов и портов. Slowloris пытается открыть много соединений с целевым веб-сервером и держать их как можно дольше. Это достигается путем открытия соединений с целевым веб-сервером и отправки частичного запроса. Периодически он отправляет еще заголовки HTTP, добавляя, но, никогда не завершая запрос. Пораженные серверы будут поддерживать соединение открытым, заполняя, таким образом, свой максимальный пул параллельных соединений, в конечном счете, отказывая в дополнительных попытках подключения от клиентов.
Скачать Slowloris
Slowloris в основном, является HTTP атакой типа «отказ от обслуживания», которая поражает потоковые сервера.
Ее работа выглядит следующим образом:
Это истощает и перезаполняет пул потока сервера и он просто не может отвечать другим людям.
Как установить и запустить?
Вы можете клонировать git репозиторий или просто установить используя pip. Вот как следует запускать его.
Это все, что требуется для установки и запуска slowloris.py.
Если вы хотите клонировать git репозиторий, не используя pip, то ниже приведен способ, как это сделать.
Несмотря на отсутствие надежных конфигураций на пораженных веб-серверах, которые могут предотвратить атаку Slowloris, существуют способы смягчения или уменьшения воздействия такой атаки. В общем, это связано с увеличением максимального количества клиентов, которые может принять веб-сервер, ограничением количества подключений, которое может произвести один IP-адрес, наложением ограничений на минимальную скорость передачи, доступную для подключения, и ограничением количества времени, которое клиент может оставаться подключенным.
Другие методы смягчения включают настройку обратных прокси-серверов, брандмауэров, балансировщиков нагрузки или коммутаторов контента. Администраторы также могут изменить программное обеспечение пораженного веб-сервера, на программное обеспечение, которое не подвержено влиянию этой формы атаки.
Это интересно:
Slow Lori атака на веб-сервер Apache
Slow Lori — это животное, живущее в юговосточной Азии и известное своей медлительностью и размеренными движениями. По нему была названа новая DoS и DDoS атака на веб-сервер Apache.
Данный тип атаки был обнародован специалистом по безопасности RSnake 17 июня и подробно описан на странице http://ha.ckers.org/blog/20090617/slowloris-http-dos
Атака заключается в очень медленной посылке все новых и новых HTTP заголовков в рамках одного HTTP запроса, никогда его не завершая.
Поскольку 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.
