0,0
рейтинг
23 марта 2011 в 21:06

Разработка → Атака на отказ в обслуживании методом slow HTTP POST из песочницы

Доброго времени суток, уважаемые хабровчане!
Я хочу рассказать вам об относительно новом и интересном, на мой взгляд, механизме атаки на отказ в обслуживании — Slow HTTP POST.
Поиск показал отсутствие на хабре информации по теме, что несколько удивило меня, и я решил восполнить это досадное упущение. Тема не нова, но, как показали мои небольшие исследования, более чем актуальна. Забегая вперед, скажу, что полученные мной результаты позволяют говорить о существовании широко доступной технологии, позволяющей с одного компьютера с небольшим каналом «укладывать» небольшие и средние сайты, а при использовании нескольких машин с повсеместно распространенным сейчас скоростным доступом в Интернет причинить немало проблем и более серьезным проектам. Всех заинтересовавшихся покорнейше прошу пожаловать под хабракат.

Теория


Как и все гениальное, технология этой атаки очень изящна и проста. Атака базируется на уязвимости в протоколе HTTP. Slow HTTP POST атака работает следующим образом: злоумышленник отправляет POST заголовок с легитимным полем «Content-Length», которое позволяет веб серверу понять, какой объём данных к нему поступает. Как только заголовок отправлен, тело POST сообщения начинает передаваться с очень медленной скоростью, что позволяет использовать ресурсы сервера намного дольше, чем это необходимо, и, как следствие, помешать обработке других запросов. Несколько тысяч таких соединений могут положить веб сервер на несколько минут. Если ваша система имеет веб интерфейс, то данный вид атак позволит «положить» его без особых проблем.
Атака была впервые продемонстрирована широкой публике на OWASP 2010 Application Security Conference. Исследователь Wong Onn Chee первый обнаружил атаку в 2009 совместно с командой исследователей из Сингапура. Позже были проведены исследования атаки (в том числе компанией Microsoft). Уязвимость в протоколе сейчас официально признана. Изначально атаки такого рода проводились в Китае. Для рекрутинга ботов использовались онлайн игры — компьютеры незадачливых игроков использовались для отправки специально сформированных HTTP-запросов целевой системе.
Простота реализации атаки позволила эффективно использовать для этого простой Java аплет, который запускался во время онлайн игры. Как только жертва принимала self-signed аплет, аплет начинаел выполнять атаку в то время, пока пользователь играл в онлайн игру. После выхода из игры и закрытия браузера атака прекращалась, а аплет удалялся. Обнаружить, что ты стал источником атаки довольно проблематично — ведь компьютер не заражается в классическом понимании этого слова, а отличить трафик от легального HTTP-трафика сложно. Кроме того, интернет-канал почти не перегружается.
Атака приводит к обрушению веб-серверов с Microsoft IIS и Apache (как показали мои опыты, список уязвимых веб серверов ими не ограничивается) в рамках протоколов HTTP или HTTPS и, очевидно, любых «безопасных» подключений вроде SSL, VPN и других. Также атака может быть адаптирована для работы с SMTP и даже DNS-серверами. Программное обеспечение, балансирующее нагрузку, ныне используемое для предотвращения DDOS-атак, схожих по типу (Slowloris), не эффективно против новой методики.
Программы, реализующие атаку (R U Dead Yet? и OWASP HTTP POST Tool, которую я использовал, дальше речь идет о ней), находятся в свободном доступе и легко гуглятся. Настройки программы очень просты, есть подробный хелп и даже графическая оболочка (сама программа консольная). Также доступны исходные коды.

Окошко OWASP HTTP POST Tool

OWASP HTTP POST Tool

Практика


Все это я, разумеется, проверил на практике. Я скачал OWASP HTTP DoS Tool, ввел адрес одного подконтрольного мне сайта. Недоверчиво клацнул по кнопочке. Через минуту сайт лежал. Это при том, что я дома обделен хорошим интернетом, и моя скорость на аплоад составляет всего пол-мегабита. Сайтик слабенький, это форум (vBulletin) на сто человек, виртуальный хостинг, сервер nginx. Но, все-же, согласитесь, даже такой небольшой сайт повешать из-под пол-мегабитного канала… это по меньшей мере удивительно.
Наука пошла дальше. Поняв, что для реализации атаки достаточно даже очень маленького канала, я запустил атаку через AdvTor (Об TOR’e читаем тут). Как-бы глупо и неправдоподобно это не звучало, сайт упал. Позже, используя несколько компьютеров с более широким интернет-каналом, все через тот-же AdvTor я сумел, сугубо из научного интереса отправить в даун более серьезные сайты (поспорив предварительно с владельцем, что положу его детище без помощи ботнета). Дальше – больше. Был написан скрипт, реализующий непрерывную атаку (у OWASP’овской программки на это дело стоит ограничение – после 40000 запросов она выключается), время от времени переключающий выходную ноду TOR’a, очищающий его кэш и перезапускающий обе программки. Кстати, в таком режиме использования они начинали очень хорошо течь. Процессор загружался под 100%, а AdvTor бесстыдно пожирал память. Вообще TOR был далеко не в восторге от такого использования, но держался на удивление хорошо, хотя иногда и зависал намертво. Использовать сеть TOR’a для этого, конечно, полнейшее варварство, но руки чешутся наука требует жертв. Испытания проводились еще на нескольких сайтах разного уровня (опять-же, по договоренности с владельцами, кроме одного раза, когда я решил мило подшутить над товарищем). Результат оказался печальным. Оказалось. что уложить почти любой средний сайт относительно несложно и более чем возможно.

Выводы


1) Slow HTTP POST позволяет организовывать атаки на отказ в обслуживании, с недостижимым раньше соотношением необходимой мощности/канала атакующего компьютера (компьютеров) и атакуемого сервера.
2) Огромное количество малых и средних сайтов на сегодняшний день подвержены этой атаке. Причем зачастую со стороны сервера сложно даже диагностировать, что сайт атакуют – трафик не превышает нормальных значений.
3) Реализация атаки очень проста, и практически не требует никаких вложений. Более того, это единственная известная науке атака на отказ в обслуживании, которую реально организовать через прокси!
4) Схожесть трафика атаки с легальным трафиком усложняют фильтрацию «вредных» пакетов, а также позволяют легко организовать сложно обнаруживаемый ботнет.

P.S.


Информация не претендует на новизну или полноту. Это скорее сборный вольный перевод из многих источников, плюс немного интересного опыта. Писалось в редкую свободную ночь (благо работы хватает), поэтому за ошибки извиняюсь, поправьте. Если эта тема кого-то заинтересует, готов написать более подробно о механизме атаки и методах защиты.

Литература и ссылки


Официальная страничка программы от OWASP
Отличная статья (для дружащих с английским)
Официальная презентация по теме (PDF), опять же для англоговорящих
Подробное исследование с описанием методов защиты (и снова английский)
Общая информация по теме на сайте OWASP
В этом ЖЖ был пост по теме

Добавлено


Уважаемы хабраюзер Sicness не поленился, и скомпилировал OWASP HTTP POST Tool под Ubuntu. По ссылке архив с бинарником и необходимой для его работы библиотекой. Исходный код доступен здесь.
Никита Карпенков @bulletproofcupid
карма
50,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (98)

  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Принимать больше 1000 только от зарегистрированных пользователей, и если пользователь плохо себя ведет, и шлет медленные запросы — банить его?
      • 0
        Я так понял автор статьи говорит о Tor-сети как в том ключе, что куча халявных разных IP можно получить. И банить по кол-ву IP на соединение не особо эффективно. Да и закрывать на public-доступ сайты тоже не метод. Действительно нужно более детально работать с HTTP-протоколом. А разве в nginx'е нельзя проскриптовать поведение на этот случай, он же много всяких низкоуровневых манипуляций позволяет.
    • 0
      Не обязательно использовать таймаут, давно же уже придумали epoll/kqueue/poll/select и неблокирующие сокеты. Открытое соединение может висеть сколь угодно долго, потребляя минимальное количество ресурсов, и при этом не нагружая сервер.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Да хоть раз в год, сервер от этого хуже работать не станет, а просто будет обрабатывать другие соединения, а этот будет висеть в ожидании новых событий. А памяти открытый сокет жрёт не так уж много по современным меркам, и этим можно пренебречь. Если уж на то пошло, то тот же connection: keep-alive, которым сейчас пользуются абсолютно все браузеры, оставляет сокет в открытом состоянии в течение некоторого времени, так что для сервера по сути ничего не меняется. Просто нужно периодически отрубать «висячие» сокеты, вот и всё.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Я, когда писал свой сервер, сделал следующим образом: как только поступают новые данные от клиента (точнее они записываются к уже полученным ранее от того же клиента), то проверяется, есть ли в них последовательность байтов \r\n\r\n (конец заголовка http), на Си это делается в пару строчек. Если есть, то обрабатываются заголовки, и если после обработки заголовков остаются необработанные данные, то обрабатывается post и т.д. Если же заголовки уже обработаны, а данные поступают, то обрабатывается post.
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  Килобайт — это не так уж много, пусть висит в памяти. Можно записывать структуру в файл, если память поджимает, или если соединение долго висит в открытом состоянии. Хотя, я не думаю, что 1-2 мегабайта (а это около 1024-2048 одновременно висячих соединений) будет проблемой для современного железа с гигабайтами оперативки. При правильном подходе проблем с такими атаками не будет вообще.
                  • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Открытый сокет жрет память? Сама структура сокета в памяти 5-10 килобайт примерно занимает насколько знаю.
          Или кеш переданных данных? Это тоже копейки, атака не на это расчитана.
  • +41
    Ну вот, сейчас начнутся проказы. Молодежь полезет проверять как это все работает и пол рунета ляжет :)
    • 0
      К тому же линки на инструменты под рукой)
    • 0
      Удивительно, как хабр, все еще жив
      • –5
        Не упадет, nginx атаке не подвержен.
        • 0
          В большинстве случаев подвержено то, что за nginx'ом (если это не асинхронный сервер, как nginx)
          • 0
            А nginx разве не забуферизирует предварительно запрос, а будет передавать его например для php-fpm по мере поступления?
            • 0
              Да, nginx пишет в файл длинные запросы, снизу дали ссылку на нужное место в документации. Но тогда непонятно как завалили сайт на Nginx, описанный в статье
              • 0
                >виртуальный хостинг

                Может в этом проблема основная?
              • +2
                Я не силен в низкоуровневой архитектуре nginx, но мы с заинтересовавшимся хабраюзером провели атаку на его nginx/0.8.54, причем атака проводилась через TOR с частой сменой IP. Результатом был упавший сервер — лишь изредка проскакивали нормальные страницы, все чаще появлялись ужасы из подземелий 500ые ошибки, наконец сервер вообще перестал что-либо выдавать. В логах: worker_connections are not enough. Следует заметить, что атака с одного IP бесполезна и приводит к недоступности сайта только с одного IP (потому что воркер, выделенный для этого IP очень-очень занят).
                • +1
                  Информация не очень полезна без предоставления «в студию» конфигов nginx и настроек самого сервера (sysctl -a, например)
                • +2
                  Мне в голову приходит мысль, что мастер-процесс Nginx как-то при открытии нового соединения открывает файловый дескриптор к воркеру. А максимальное количество открытых файлов по-умолчанию 1024.
                  Но это только предположение.
                  • 0
                    поэтому при настройке сервера я ставлю worker_processes в 4, а connections — в 4096.
    • +9
      120 закладок на статью. Что-то будет…
  • +3
    Напишите про защиту, интересно.
    • +11
      Вот тут немного написано про вариант защиты l0rda.biz/2011/01/30/tornado-web-nginx-block-http-ddos-get-post/
      • 0
        Спасибо.
      • +6
        я думал убрал статью с сайта, а она торчит до сих пор оказывается. Там не очень точные замеры, я понял, что с помощью ab вообще тестировать нельзя нормально. Но если не вдаваться в цифры, то технология работает.
        • 0
          + сейчас все работает на третьем варианте, mysql был заменен на mysql+handlerSocket (сборка percona).
        • 0
          Сейчас больше встречаю установленные до серверов «кластерные Системы защиты», значительно упрощают жизнь сисадминам.
          • 0
            это у нас тоже есть, но «не все йогурты одинаково полезны», включаем только в крайних случаях, при гигабитных объемах ддоса
            • 0
              Конечно одной такой железки мало, нужно безопасность делать в комплексе, но у меня друг поставил 2 года назад такую игрушку, говорит значительно улучшилась жизнь во время ddos атак.
      • 0
        там в основном теория, без примеров конфигов
        • +1
          а какие имемнно нужны примеры? там же элементарно все.
          • 0
            я новичек с торнадо, еще не все элементарно, хотя проанализировать запрос и отдать заголовок можно разобраться как… в любом случае спасибо за статью…
    • +2
      Напишу, правда немного позже, я буквально завален работай ближайшие дни.
    • +2
      Маленький таймаут (возможно только для пост-запросов), проверка количества поступающих данных, реализовать что-то вроде паттерна атаки, а затем проверять подходит текущий запрос под паттерн или нет
  • НЛО прилетело и опубликовало эту надпись здесь
    • +7
      Расскажите подробнее, пожалуйста. Для меня это действительно новость.
    • 0
      Все новое — это хорошо забытое старое.
  • +5
    А в чем отличие от slowloris? Опасна ли атака для NGINX?
    • +4
      Slowloris это несколько другая атака. Если меня не подводит память, в slowloris серверу отправляются заголовки запроса без продолжения, после чего сервер ждет продолжения запроса и долго оставляет подключение живым. В атаке которую я описал, данные запроса серверу все-таки передаются, но очень медленно. Таким образом, в большинстве случаев методы защиты от slowloris бесполезны для борьбы с описанной мной атакой.
      Сервер на NGINX'e я благополучно положил этим методом, не знаю, вина ли это сервера или причиной столь легкой победы является кривизна рук человека, этот сервер настраивавшего.
      • +2
        В slowloris, если верить статье на хабре, «Атака заключается в очень медленной посылке все новых и новых HTTP заголовков в рамках одного HTTP запроса, никогда его не завершая.»

        Nginx не должен страдать, так как для всех воркеров используется 1 поток.
      • 0
        gist.github.com/884870

        Похоже?
        • 0
          И судя по replay.waybackmachine.org/20080522111624/http://insa.pp.ru/files/tools/http/ написано это еще 2007. И уже тогда это был жуткий боян.
        • 0
          Охх… 10000 тредов это слишком жестко. Так вы скорее свою систему подвесите. Лучше на каком-нить EventMachine.
          • +1
            Вообще там green threads, они копеечные.
            • 0
              А, ну если green threads то ок, без вопросов. Я просто в ruby не рублю))
  • +11
    NGINX умеет кэшировать клиентский запрос перед отправкой на бэкэнд. То есть пока весь запрос не будет выкачан, драгоценные потоки бэкэнда затрачиваться не будут, а NGINX должно быть пофигу.
    • +3
      Звучит убедительно, теперь я понимаю, почему в официальном списке уязвимых серверов NGINX не значился. Скорее всего, в NGINX сервере, который я положил, кэширование клиентских запросов было отключено.
      • +1
        Только что попробовал атаковать сайт на nginx — результата никакого. Использовал OWASP
        • 0
          Видимо, ваш сервер грамотно настроен. Тот, что попался мне под руку, под атакой выдавал 500 Error.
          • +5
            500-ю выдавал и у меня, но только с атакующей машины. У меня просто рядом ноутбук еще стоит. Под атакой на сайт из браузера не смог зайти с атакующей машины, а с ноутбука без проблем.
            • +1
              Разумеется, я проверял доступность сайта не с атакующего компьютера. Проверялось с другой сети несколькими друзьями. Следует заметить, что nginx сервера официально не подвержены этой атаке — возможно мне просто попался на редкость плохо сконфигурированный вариант. Разрешение на эксперименты я брал не у администратора ресурса, а у хозяина, который в технологиях разбирается, мягко говоря, слабо. О том что там nginx я судил по стандартным страницам, подробный аудит не проводил. Так что есть вероятность, что там крутится старина апач, замаскированный, от греха подальше, под nginx. Хотя звучит это уж слишком фантастично, учитывая микроскопичность ресурса, сомневаюсь, что там кто-то занимался такими тонкостями. Скорее всего просто очень слабый сервер и неудачная настройка.
            • 0
              Toy, просто на атакующей машине в операционке количество открытых/полуоткрытых соединений имеет свой лимит. У вас и любой другой сайт во время атаки не откроется. :)
      • 0
        это вроде не отключабельно. sysoev.ru/nginx/docs/http/ngx_http_core_module.html#client_body_buffer_size
        Возможно дело было в общем количестве коннектов. Или еще в чём либо.
        • –1
          Дело становится таинственным, попробую выяснить все у администратора того сервера. Скорее всего все-таки, это не nginx.
    • +3
      У nginx буферы тоже не бесконечные, их размер конфигурируется. Можно модифицировать атаку так, чтобы сначала приезжало такое количество данных, размер которых был бы достаточен для инициирования отправки запроса на бекенд, и дальше слать по байту в секунду.
      • +1
        Там вроде бы есть возможность сливать содержимое запроса во временный файл пока не будет получен весь запрос — так что пусть шлют.

        Собственно вот вся искомая группа настроек: sysoev.ru/nginx/docs/http/ngx_http_core_module.html#client_body_buffer_size
  • –8
    Еще есть «Кластерная Система Защиты От DDOS Атак» antiddos.com.ua/?p=244
    • –1
      Вот хоть бы кто-то сказал, за что так жестко минусуют и понижают карму.
  • +2
    > Для рекрутинга ботов использовались онлайн игры — компьютеры незадачливых игроков использовались для отправки специально сформированных HTTP-запросов целевой системе.
    Это была официальная проверка или какой-то spyware заражалось злоумышленно? Если первое, то проверяющие ведь могут на весьма крупную сумму загреметь. Вывод — не доверяй клиентам онлайн игр :)

    По теме вопрос: разве нет настроек брандмауэра на сервере, с помощью который прерываются длительные коннекты по прошествии некоего таймаута?
    • +1
      Таймаут наступает только при полном отсутствии активности. В нашем же случае данные постоянно продолжают передаваться.
      • 0
        Я имею ввиду не полное значение таймаута, а максимальное время исполнения запроса. То бишь, в случае если продолжительность запроса превышает либо равно некой заданной величине, то попросту обрубать запрос. Конечно, это несет за собой проблемы с пользователями на медленном соединении.
        • 0
          Простое ограничение времени запроса принесет так же нескоько проблем. Например пользователи не смогут заливать большие файлы.
  • +1
    Настройки брандмауэра на сервере есть, вопрос в том, у кого брандмауэр на сервере настрое правильно. Кроме того, обрубая длительные подключения, рискуем обрубить «хорошие» коннекты, которым просто не повезло со скоростью доступа. Проблема собственно говоря и состоит в том, что все-таки приходится разрешать подключения определенной длинны, которой вполне хватает для проведения атаки. Тем не менее уменьшение максимально допустимой длинны коннекта до некого достаточно малого значения позволит если не отразить, то хотя-бы легче пережить атаку.
    • +2
      Прошу прощения, в следующий раз буду внимательнее смотреть куда пишу комментарий, он был предназначен для тов. 047
    • 0
      Только заметил этот комментарий :) Ну да, верно, в принципе как я написал выше.
  • +4
    Вспоминается SYN flood пятнадцать лет назад. Из под дешевого модема на 9600 bps можно было положить сайт на мощном канале. Аналогия очевидна — slow HTTP post, slow three-way handshake…
  • +11
    Мне что-то кажется что серверам на неблокирующем IO такая атака абсолютно пофигу. Т.е. если мы поставим какой-нить Nginx перед апачем/иным бэкендом, то Nginx будет спокойненько себе кешировать входящие данные по мере их поступления и, когда соберется весь Content-length, одним большим куском передаст бэкенду.
    А вот голый Апач и другие сервера которые на каждое соединение выделяют по потоку/процессу действительно запросто укладываются, т.к. заканчиваются свободные воркеры или память сервера.
  • 0
    Проверил на своих серверах с параметрами как на картинке в посте.
    lighttpd/1.4.26 — лег сразу же
    Cherokee/1.0.15 — никакого эффекта
    • 0
      Тут патчики для лайта. По идее в 1.4.27+ и в 1.5 ветке бага уже пофиксена.
  • 0
    Почему именно POST? Я так понимаю, что проблема с любым типом slow-соединения, нет?

    Кстати, насчёт SMTP вы сильно ошибаетесь. Некоторое время назад были тупые боты, которые коннектились с SMTP-серверу и ждали команды от мастера для начала рассылки. В то время это приводило к неприятным последствиям, так что у современных почтовых серверов с вменяемыми конфигами есть лимит на количество коннектов с клиента и довольно суровые таймауты.

    Кстати, насколько я понимаю, указанная проблема существует только в условиях приёма неограниченного количества соединений с IP. Все нормальные сайты давно прикрыты nginx'ом, так что даже если вы начнёте развлекаться парочкой постов, то третий-четвёртый от вас просто не примут.
    • +2
      потому что сервер ожидает принять запрос целиком (данные формы), на get-запрос он просто выкинет ответ и не будет slow
      • 0
        Чем это отличается от медленного скармливания http-request?
        • +1
          вероятно тем, что данные можно гораздо дольше посылать небольшими порциями. обычный запрос быстрее отвалится либо по таймауту либо закончатся данные.
  • 0
    mod_limitipconn, по идее, не спасёт от ботнета, но спасёт от энтузиастов, желающих положить сайт с одного-двух компьютеров.
  • +5
    Да, и, кстати, mod_reqtimeout — не лекарство ли?
  • +1
    Проблема была описана по крайней мере пару лет назад, на хабре. Топик, составленный в форме вопроса, найти не получилось, но суть была в том, что автора пытались развести на бабло за прекращение атаки на его апач. Атака была описана именно так, как в этом топике. Сообщество предложило поставить nginx, чтобы он по-быстрому забирал страницу у апача и занимался собственно отдачей контента в сеть, в том числе по медленным соединениям. Проблема исчезла.
    • –1
      Вероятнее всего, что пару лет назад это была slowloris-атака, поскольку, согласно википедии , она появилась в 2009 году. Тот тип атаки, о котором написал я, сравнительно новый, отличие этой атаки от slowloris обсуждалось в этой ветке.
      Если о ошибаюсь, простите, поиск по теме на хабре результатов не дал, а поскольку я здесь новенький, о посте двухгодичной давности мне не было известно. Кроме того, если эта информация для многих актуальна, то пост по теме не повредит.
      • 0
        Да я не против поста! Я написал на тот случай, если кто-то все-таки не поленится и откопает ту страницу с животрепещущими подробностями
  • +13
    Большое спасибо! Обязательно встрою в свой ботнет.
  • 0
    Атака действует только на серверы, которые создают треды/процессы на каждый запрос, а тот же нгинкс пишет POST запрос в временный файл и ему пофиг на такую атаку. Более того, там даже можно этот временный не закачивать в бекенд заново, а передавать только путь к нему через параемтры запроса. В обзем, спасибо его разработчику, что бы мы без него делали, а апач страшно вообще в сеть мордой выставлять.
    • 0
      нгинкс пишет POST запрос в временный файл

      Можно источник, где про это написано? Первый раз про это слышу
      • +1
        Если тело запроса больше заданного буфера, то всё тело запроса или только его часть записывается во временный файл.
        sysoev.ru/nginx/docs/http/ngx_http_core_module.html#client_body_buffer_size прям так черным по белому и написано. Там чуть выше в комментариях ссылку на это давали.
  • 0
    Решение навскидку для nginx+threaded backend:
    sysoev.ru/nginx/docs/http/ngx_http_limit_zone_module.html
    sysoev.ru/nginx/docs/http/ngx_http_limit_req_module.html

    Директива client_body_timeout работать не будет, т.к. таймаут в этом случае не на весь запрос, а на две операции чтения. Можно также попробовать уменьшить client_max_body_size
    • 0
      +сonnlimit
      Ну или recent прикручивать, хотя это уже от HTTP Flood
  • +1
    Это решается очень просто с помощью событий и асинхронных серверов. Сам недавно написал свой асинхронный http-сервер и могу сказать, что на нём это не прокатит, т.к. он обрабатывает запросы по мере поступления, а не ждёт завершения какого-то одного медленного запроса. Сейчас почти все современные сервера работают по этой схеме (nginx, cherokee, lighttpd), разве что apache работает по устаревшему принципу с использованием блокирующих сокетов и тредов, т.е. если закончатся обработывающие треды, то апач «ляжет». Выход один — не использовать апач, т.к. по сути только он и подвержен этой атаке.
    • +1
      Ну ещё и IIS тоже. На своих серваках проверил и расстроился.
      • 0
        Если я не ошибаюсь, Windows не поддерживает нормальные методы работы с неблокирующими сокетами, только устаревший select, который потребляет много ресурсов. А значит асинхронные сервера для Windows писать не резон. Возможно там эта проблема решается каким-то другим способом, я с программированием серверов под win мало знаком, поэтому точно сказать не могу. У того же nginx на сайте в описании версии под win написано: «nginx/Windows работает с Win32 API (не эмуляция Cygwin). В качестве метода обработки соединений используется select, поэтому не стоит ожидать высокой производительности и масштабируемости.»
        • 0
          Мне кажется вы ошибаетесь. Асинхронные сокеты в Win существуют очень и очень давно.
          Но скажу честно — предметом владею плохо.
        • +1
          IOCP
  • 0
    Мне показалось, или я несколько раз видел на хабре 503?
  • 0
    хмм,, nginx писал
    Active connections = 243, при

    • 0
      #comment_3767035 отпостил по ошибке…
      — хмм,, nginx писал
      Active connections = 243, при этом % процессора на сервере не скакал.
      а все посланные на сервер запросы отображались в Waiting:…

      Кстати настройки limit_req_zone и limit_zone никак не влияли… (сервер не отрубал коннекты, хотя тест велся с одного и того же ип).
  • 0
    Nginx выдержал с одного IP.
    Apache лег сразу же.

    Вспомнил, что надо закрыть Apache на 81-ом порту. :)

    В Nginx параметр client_body_temp_path у меня не определен. Значит ли это, что тело запроса НЕ хранится во временных файлах?
  • 0
    Уже больше года пользуюсь данным софтом.
    Странно что все украинские сайты операторы мобильной связи могут упасть после этого вида доса.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.