Комментарии 98
НЛО прилетело и опубликовало эту надпись здесь
Принимать больше 1000 только от зарегистрированных пользователей, и если пользователь плохо себя ведет, и шлет медленные запросы — банить его?
Я так понял автор статьи говорит о Tor-сети как в том ключе, что куча халявных разных IP можно получить. И банить по кол-ву IP на соединение не особо эффективно. Да и закрывать на public-доступ сайты тоже не метод. Действительно нужно более детально работать с HTTP-протоколом. А разве в nginx'е нельзя проскриптовать поведение на этот случай, он же много всяких низкоуровневых манипуляций позволяет.
Не обязательно использовать таймаут, давно же уже придумали epoll/kqueue/poll/select и неблокирующие сокеты. Открытое соединение может висеть сколь угодно долго, потребляя минимальное количество ресурсов, и при этом не нагружая сервер.
НЛО прилетело и опубликовало эту надпись здесь
Да хоть раз в год, сервер от этого хуже работать не станет, а просто будет обрабатывать другие соединения, а этот будет висеть в ожидании новых событий. А памяти открытый сокет жрёт не так уж много по современным меркам, и этим можно пренебречь. Если уж на то пошло, то тот же connection: keep-alive, которым сейчас пользуются абсолютно все браузеры, оставляет сокет в открытом состоянии в течение некоторого времени, так что для сервера по сути ничего не меняется. Просто нужно периодически отрубать «висячие» сокеты, вот и всё.
НЛО прилетело и опубликовало эту надпись здесь
Я, когда писал свой сервер, сделал следующим образом: как только поступают новые данные от клиента (точнее они записываются к уже полученным ранее от того же клиента), то проверяется, есть ли в них последовательность байтов \r\n\r\n (конец заголовка http), на Си это делается в пару строчек. Если есть, то обрабатываются заголовки, и если после обработки заголовков остаются необработанные данные, то обрабатывается post и т.д. Если же заголовки уже обработаны, а данные поступают, то обрабатывается post.
НЛО прилетело и опубликовало эту надпись здесь
Килобайт — это не так уж много, пусть висит в памяти. Можно записывать структуру в файл, если память поджимает, или если соединение долго висит в открытом состоянии. Хотя, я не думаю, что 1-2 мегабайта (а это около 1024-2048 одновременно висячих соединений) будет проблемой для современного железа с гигабайтами оперативки. При правильном подходе проблем с такими атаками не будет вообще.
Открытый сокет жрет память? Сама структура сокета в памяти 5-10 килобайт примерно занимает насколько знаю.
Или кеш переданных данных? Это тоже копейки, атака не на это расчитана.
Или кеш переданных данных? Это тоже копейки, атака не на это расчитана.
Ну вот, сейчас начнутся проказы. Молодежь полезет проверять как это все работает и пол рунета ляжет :)
К тому же линки на инструменты под рукой)
Удивительно, как хабр, все еще жив
Не упадет, nginx атаке не подвержен.
В большинстве случаев подвержено то, что за nginx'ом (если это не асинхронный сервер, как nginx)
А nginx разве не забуферизирует предварительно запрос, а будет передавать его например для php-fpm по мере поступления?
Да, nginx пишет в файл длинные запросы, снизу дали ссылку на нужное место в документации. Но тогда непонятно как завалили сайт на Nginx, описанный в статье
>виртуальный хостинг
Может в этом проблема основная?
Может в этом проблема основная?
Я не силен в низкоуровневой архитектуре nginx, но мы с заинтересовавшимся хабраюзером провели атаку на его nginx/0.8.54, причем атака проводилась через TOR с частой сменой IP. Результатом был упавший сервер — лишь изредка проскакивали нормальные страницы, все чаще появлялись ужасы из подземелий 500ые ошибки, наконец сервер вообще перестал что-либо выдавать. В логах: worker_connections are not enough. Следует заметить, что атака с одного IP бесполезна и приводит к недоступности сайта только с одного IP (потому что воркер, выделенный для этого IP очень-очень занят).
Информация не очень полезна без предоставления «в студию» конфигов nginx и настроек самого сервера (sysctl -a, например)
Мне в голову приходит мысль, что мастер-процесс Nginx как-то при открытии нового соединения открывает файловый дескриптор к воркеру. А максимальное количество открытых файлов по-умолчанию 1024.
Но это только предположение.
Но это только предположение.
120 закладок на статью. Что-то будет…
Напишите про защиту, интересно.
Вот тут немного написано про вариант защиты l0rda.biz/2011/01/30/tornado-web-nginx-block-http-ddos-get-post/
Спасибо.
я думал убрал статью с сайта, а она торчит до сих пор оказывается. Там не очень точные замеры, я понял, что с помощью ab вообще тестировать нельзя нормально. Но если не вдаваться в цифры, то технология работает.
+ сейчас все работает на третьем варианте, mysql был заменен на mysql+handlerSocket (сборка percona).
Сейчас больше встречаю установленные до серверов «кластерные Системы защиты», значительно упрощают жизнь сисадминам.
НЛО прилетело и опубликовало эту надпись здесь
Напишу, правда немного позже, я буквально завален работай ближайшие дни.
Маленький таймаут (возможно только для пост-запросов), проверка количества поступающих данных, реализовать что-то вроде паттерна атаки, а затем проверять подходит текущий запрос под паттерн или нет
НЛО прилетело и опубликовало эту надпись здесь
А в чем отличие от slowloris? Опасна ли атака для NGINX?
Slowloris это несколько другая атака. Если меня не подводит память, в slowloris серверу отправляются заголовки запроса без продолжения, после чего сервер ждет продолжения запроса и долго оставляет подключение живым. В атаке которую я описал, данные запроса серверу все-таки передаются, но очень медленно. Таким образом, в большинстве случаев методы защиты от slowloris бесполезны для борьбы с описанной мной атакой.
Сервер на NGINX'e я благополучно положил этим методом, не знаю, вина ли это сервера или причиной столь легкой победы является кривизна рук человека, этот сервер настраивавшего.
Сервер на NGINX'e я благополучно положил этим методом, не знаю, вина ли это сервера или причиной столь легкой победы является кривизна рук человека, этот сервер настраивавшего.
В slowloris, если верить статье на хабре, «Атака заключается в очень медленной посылке все новых и новых HTTP заголовков в рамках одного HTTP запроса, никогда его не завершая.»
Nginx не должен страдать, так как для всех воркеров используется 1 поток.
Nginx не должен страдать, так как для всех воркеров используется 1 поток.
И судя по replay.waybackmachine.org/20080522111624/http://insa.pp.ru/files/tools/http/ написано это еще 2007. И уже тогда это был жуткий боян.
Охх… 10000 тредов это слишком жестко. Так вы скорее свою систему подвесите. Лучше на каком-нить EventMachine.
NGINX умеет кэшировать клиентский запрос перед отправкой на бэкэнд. То есть пока весь запрос не будет выкачан, драгоценные потоки бэкэнда затрачиваться не будут, а NGINX должно быть пофигу.
Звучит убедительно, теперь я понимаю, почему в официальном списке уязвимых серверов NGINX не значился. Скорее всего, в NGINX сервере, который я положил, кэширование клиентских запросов было отключено.
Только что попробовал атаковать сайт на nginx — результата никакого. Использовал OWASP
Видимо, ваш сервер грамотно настроен. Тот, что попался мне под руку, под атакой выдавал 500 Error.
500-ю выдавал и у меня, но только с атакующей машины. У меня просто рядом ноутбук еще стоит. Под атакой на сайт из браузера не смог зайти с атакующей машины, а с ноутбука без проблем.
Разумеется, я проверял доступность сайта не с атакующего компьютера. Проверялось с другой сети несколькими друзьями. Следует заметить, что nginx сервера официально не подвержены этой атаке — возможно мне просто попался на редкость плохо сконфигурированный вариант. Разрешение на эксперименты я брал не у администратора ресурса, а у хозяина, который в технологиях разбирается, мягко говоря, слабо. О том что там nginx я судил по стандартным страницам, подробный аудит не проводил. Так что есть вероятность, что там крутится старина апач, замаскированный, от греха подальше, под nginx. Хотя звучит это уж слишком фантастично, учитывая микроскопичность ресурса, сомневаюсь, что там кто-то занимался такими тонкостями. Скорее всего просто очень слабый сервер и неудачная настройка.
Toy, просто на атакующей машине в операционке количество открытых/полуоткрытых соединений имеет свой лимит. У вас и любой другой сайт во время атаки не откроется. :)
это вроде не отключабельно. sysoev.ru/nginx/docs/http/ngx_http_core_module.html#client_body_buffer_size
Возможно дело было в общем количестве коннектов. Или еще в чём либо.
Возможно дело было в общем количестве коннектов. Или еще в чём либо.
У nginx буферы тоже не бесконечные, их размер конфигурируется. Можно модифицировать атаку так, чтобы сначала приезжало такое количество данных, размер которых был бы достаточен для инициирования отправки запроса на бекенд, и дальше слать по байту в секунду.
Там вроде бы есть возможность сливать содержимое запроса во временный файл пока не будет получен весь запрос — так что пусть шлют.
Собственно вот вся искомая группа настроек: sysoev.ru/nginx/docs/http/ngx_http_core_module.html#client_body_buffer_size
Собственно вот вся искомая группа настроек: sysoev.ru/nginx/docs/http/ngx_http_core_module.html#client_body_buffer_size
Еще есть «Кластерная Система Защиты От DDOS Атак» antiddos.com.ua/?p=244
> Для рекрутинга ботов использовались онлайн игры — компьютеры незадачливых игроков использовались для отправки специально сформированных HTTP-запросов целевой системе.
Это была официальная проверка или какой-то spyware заражалось злоумышленно? Если первое, то проверяющие ведь могут на весьма крупную сумму загреметь. Вывод — не доверяй клиентам онлайн игр :)
По теме вопрос: разве нет настроек брандмауэра на сервере, с помощью который прерываются длительные коннекты по прошествии некоего таймаута?
Это была официальная проверка или какой-то spyware заражалось злоумышленно? Если первое, то проверяющие ведь могут на весьма крупную сумму загреметь. Вывод — не доверяй клиентам онлайн игр :)
По теме вопрос: разве нет настроек брандмауэра на сервере, с помощью который прерываются длительные коннекты по прошествии некоего таймаута?
Таймаут наступает только при полном отсутствии активности. В нашем же случае данные постоянно продолжают передаваться.
Настройки брандмауэра на сервере есть, вопрос в том, у кого брандмауэр на сервере настрое правильно. Кроме того, обрубая длительные подключения, рискуем обрубить «хорошие» коннекты, которым просто не повезло со скоростью доступа. Проблема собственно говоря и состоит в том, что все-таки приходится разрешать подключения определенной длинны, которой вполне хватает для проведения атаки. Тем не менее уменьшение максимально допустимой длинны коннекта до некого достаточно малого значения позволит если не отразить, то хотя-бы легче пережить атаку.
НЛО прилетело и опубликовало эту надпись здесь
Мне что-то кажется что серверам на неблокирующем IO такая атака абсолютно пофигу. Т.е. если мы поставим какой-нить Nginx перед апачем/иным бэкендом, то Nginx будет спокойненько себе кешировать входящие данные по мере их поступления и, когда соберется весь Content-length, одним большим куском передаст бэкенду.
А вот голый Апач и другие сервера которые на каждое соединение выделяют по потоку/процессу действительно запросто укладываются, т.к. заканчиваются свободные воркеры или память сервера.
А вот голый Апач и другие сервера которые на каждое соединение выделяют по потоку/процессу действительно запросто укладываются, т.к. заканчиваются свободные воркеры или память сервера.
Проверил на своих серверах с параметрами как на картинке в посте.
lighttpd/1.4.26 — лег сразу же
Cherokee/1.0.15 — никакого эффекта
lighttpd/1.4.26 — лег сразу же
Cherokee/1.0.15 — никакого эффекта
Тут патчики для лайта. По идее в 1.4.27+ и в 1.5 ветке бага уже пофиксена.
Почему именно POST? Я так понимаю, что проблема с любым типом slow-соединения, нет?
Кстати, насчёт SMTP вы сильно ошибаетесь. Некоторое время назад были тупые боты, которые коннектились с SMTP-серверу и ждали команды от мастера для начала рассылки. В то время это приводило к неприятным последствиям, так что у современных почтовых серверов с вменяемыми конфигами есть лимит на количество коннектов с клиента и довольно суровые таймауты.
Кстати, насколько я понимаю, указанная проблема существует только в условиях приёма неограниченного количества соединений с IP. Все нормальные сайты давно прикрыты nginx'ом, так что даже если вы начнёте развлекаться парочкой постов, то третий-четвёртый от вас просто не примут.
Кстати, насчёт SMTP вы сильно ошибаетесь. Некоторое время назад были тупые боты, которые коннектились с SMTP-серверу и ждали команды от мастера для начала рассылки. В то время это приводило к неприятным последствиям, так что у современных почтовых серверов с вменяемыми конфигами есть лимит на количество коннектов с клиента и довольно суровые таймауты.
Кстати, насколько я понимаю, указанная проблема существует только в условиях приёма неограниченного количества соединений с IP. Все нормальные сайты давно прикрыты nginx'ом, так что даже если вы начнёте развлекаться парочкой постов, то третий-четвёртый от вас просто не примут.
mod_limitipconn, по идее, не спасёт от ботнета, но спасёт от энтузиастов, желающих положить сайт с одного-двух компьютеров.
Да, и, кстати, mod_reqtimeout — не лекарство ли?
Проблема была описана по крайней мере пару лет назад, на хабре. Топик, составленный в форме вопроса, найти не получилось, но суть была в том, что автора пытались развести на бабло за прекращение атаки на его апач. Атака была описана именно так, как в этом топике. Сообщество предложило поставить nginx, чтобы он по-быстрому забирал страницу у апача и занимался собственно отдачей контента в сеть, в том числе по медленным соединениям. Проблема исчезла.
Вероятнее всего, что пару лет назад это была slowloris-атака, поскольку, согласно википедии , она появилась в 2009 году. Тот тип атаки, о котором написал я, сравнительно новый, отличие этой атаки от slowloris обсуждалось в этой ветке.
Если о ошибаюсь, простите, поиск по теме на хабре результатов не дал, а поскольку я здесь новенький, о посте двухгодичной давности мне не было известно. Кроме того, если эта информация для многих актуальна, то пост по теме не повредит.
Если о ошибаюсь, простите, поиск по теме на хабре результатов не дал, а поскольку я здесь новенький, о посте двухгодичной давности мне не было известно. Кроме того, если эта информация для многих актуальна, то пост по теме не повредит.
Большое спасибо! Обязательно встрою в свой ботнет.
Атака действует только на серверы, которые создают треды/процессы на каждый запрос, а тот же нгинкс пишет POST запрос в временный файл и ему пофиг на такую атаку. Более того, там даже можно этот временный не закачивать в бекенд заново, а передавать только путь к нему через параемтры запроса. В обзем, спасибо его разработчику, что бы мы без него делали, а апач страшно вообще в сеть мордой выставлять.
нгинкс пишет POST запрос в временный файл
Можно источник, где про это написано? Первый раз про это слышу
Если тело запроса больше заданного буфера, то всё тело запроса или только его часть записывается во временный файл.sysoev.ru/nginx/docs/http/ngx_http_core_module.html#client_body_buffer_size прям так черным по белому и написано. Там чуть выше в комментариях ссылку на это давали.
Решение навскидку для 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
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
Это решается очень просто с помощью событий и асинхронных серверов. Сам недавно написал свой асинхронный http-сервер и могу сказать, что на нём это не прокатит, т.к. он обрабатывает запросы по мере поступления, а не ждёт завершения какого-то одного медленного запроса. Сейчас почти все современные сервера работают по этой схеме (nginx, cherokee, lighttpd), разве что apache работает по устаревшему принципу с использованием блокирующих сокетов и тредов, т.е. если закончатся обработывающие треды, то апач «ляжет». Выход один — не использовать апач, т.к. по сути только он и подвержен этой атаке.
Ну ещё и IIS тоже. На своих серваках проверил и расстроился.
Если я не ошибаюсь, Windows не поддерживает нормальные методы работы с неблокирующими сокетами, только устаревший select, который потребляет много ресурсов. А значит асинхронные сервера для Windows писать не резон. Возможно там эта проблема решается каким-то другим способом, я с программированием серверов под win мало знаком, поэтому точно сказать не могу. У того же nginx на сайте в описании версии под win написано: «nginx/Windows работает с Win32 API (не эмуляция Cygwin). В качестве метода обработки соединений используется select, поэтому не стоит ожидать высокой производительности и масштабируемости.»
Мне показалось, или я несколько раз видел на хабре 503?
хмм,, nginx писал
Active connections = 243, при
Active connections = 243, при
#comment_3767035 отпостил по ошибке…
— хмм,, nginx писал
Active connections = 243, при этом % процессора на сервере не скакал.
а все посланные на сервер запросы отображались в Waiting:…
Кстати настройки limit_req_zone и limit_zone никак не влияли… (сервер не отрубал коннекты, хотя тест велся с одного и того же ип).
— хмм,, nginx писал
Active connections = 243, при этом % процессора на сервере не скакал.
а все посланные на сервер запросы отображались в Waiting:…
Кстати настройки limit_req_zone и limit_zone никак не влияли… (сервер не отрубал коннекты, хотя тест велся с одного и того же ип).
Nginx выдержал с одного IP.
Apache лег сразу же.
Вспомнил, что надо закрыть Apache на 81-ом порту. :)
В Nginx параметр client_body_temp_path у меня не определен. Значит ли это, что тело запроса НЕ хранится во временных файлах?
Apache лег сразу же.
Вспомнил, что надо закрыть Apache на 81-ом порту. :)
В Nginx параметр client_body_temp_path у меня не определен. Значит ли это, что тело запроса НЕ хранится во временных файлах?
Уже больше года пользуюсь данным софтом.
Странно что все украинские сайты операторы мобильной связи могут упасть после этого вида доса.
Странно что все украинские сайты операторы мобильной связи могут упасть после этого вида доса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Атака на отказ в обслуживании методом slow HTTP POST