Как стать автором
Обновить

Комментарии 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.
Но это только предположение.
поэтому при настройке сервера я ставлю worker_processes в 4, а connections — в 4096.
120 закладок на статью. Что-то будет…
Напишите про защиту, интересно.
Спасибо.
я думал убрал статью с сайта, а она торчит до сих пор оказывается. Там не очень точные замеры, я понял, что с помощью ab вообще тестировать нельзя нормально. Но если не вдаваться в цифры, то технология работает.
+ сейчас все работает на третьем варианте, mysql был заменен на mysql+handlerSocket (сборка percona).
Сейчас больше встречаю установленные до серверов «кластерные Системы защиты», значительно упрощают жизнь сисадминам.
это у нас тоже есть, но «не все йогурты одинаково полезны», включаем только в крайних случаях, при гигабитных объемах ддоса
Конечно одной такой железки мало, нужно безопасность делать в комплексе, но у меня друг поставил 2 года назад такую игрушку, говорит значительно улучшилась жизнь во время ddos атак.
НЛО прилетело и опубликовало эту надпись здесь
а какие имемнно нужны примеры? там же элементарно все.
НЛО прилетело и опубликовало эту надпись здесь
Напишу, правда немного позже, я буквально завален работай ближайшие дни.
Маленький таймаут (возможно только для пост-запросов), проверка количества поступающих данных, реализовать что-то вроде паттерна атаки, а затем проверять подходит текущий запрос под паттерн или нет
НЛО прилетело и опубликовало эту надпись здесь
Расскажите подробнее, пожалуйста. Для меня это действительно новость.
Все новое — это хорошо забытое старое.
А в чем отличие от slowloris? Опасна ли атака для NGINX?
Slowloris это несколько другая атака. Если меня не подводит память, в slowloris серверу отправляются заголовки запроса без продолжения, после чего сервер ждет продолжения запроса и долго оставляет подключение живым. В атаке которую я описал, данные запроса серверу все-таки передаются, но очень медленно. Таким образом, в большинстве случаев методы защиты от slowloris бесполезны для борьбы с описанной мной атакой.
Сервер на NGINX'e я благополучно положил этим методом, не знаю, вина ли это сервера или причиной столь легкой победы является кривизна рук человека, этот сервер настраивавшего.
В slowloris, если верить статье на хабре, «Атака заключается в очень медленной посылке все новых и новых HTTP заголовков в рамках одного HTTP запроса, никогда его не завершая.»

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

Собственно вот вся искомая группа настроек: sysoev.ru/nginx/docs/http/ngx_http_core_module.html#client_body_buffer_size
Вот хоть бы кто-то сказал, за что так жестко минусуют и понижают карму.
> Для рекрутинга ботов использовались онлайн игры — компьютеры незадачливых игроков использовались для отправки специально сформированных HTTP-запросов целевой системе.
Это была официальная проверка или какой-то spyware заражалось злоумышленно? Если первое, то проверяющие ведь могут на весьма крупную сумму загреметь. Вывод — не доверяй клиентам онлайн игр :)

По теме вопрос: разве нет настроек брандмауэра на сервере, с помощью который прерываются длительные коннекты по прошествии некоего таймаута?
Таймаут наступает только при полном отсутствии активности. В нашем же случае данные постоянно продолжают передаваться.
Я имею ввиду не полное значение таймаута, а максимальное время исполнения запроса. То бишь, в случае если продолжительность запроса превышает либо равно некой заданной величине, то попросту обрубать запрос. Конечно, это несет за собой проблемы с пользователями на медленном соединении.
Простое ограничение времени запроса принесет так же нескоько проблем. Например пользователи не смогут заливать большие файлы.
Настройки брандмауэра на сервере есть, вопрос в том, у кого брандмауэр на сервере настрое правильно. Кроме того, обрубая длительные подключения, рискуем обрубить «хорошие» коннекты, которым просто не повезло со скоростью доступа. Проблема собственно говоря и состоит в том, что все-таки приходится разрешать подключения определенной длинны, которой вполне хватает для проведения атаки. Тем не менее уменьшение максимально допустимой длинны коннекта до некого достаточно малого значения позволит если не отразить, то хотя-бы легче пережить атаку.
Прошу прощения, в следующий раз буду внимательнее смотреть куда пишу комментарий, он был предназначен для тов. 047
Только заметил этот комментарий :) Ну да, верно, в принципе как я написал выше.
НЛО прилетело и опубликовало эту надпись здесь
Мне что-то кажется что серверам на неблокирующем IO такая атака абсолютно пофигу. Т.е. если мы поставим какой-нить Nginx перед апачем/иным бэкендом, то Nginx будет спокойненько себе кешировать входящие данные по мере их поступления и, когда соберется весь Content-length, одним большим куском передаст бэкенду.
А вот голый Апач и другие сервера которые на каждое соединение выделяют по потоку/процессу действительно запросто укладываются, т.к. заканчиваются свободные воркеры или память сервера.
Проверил на своих серверах с параметрами как на картинке в посте.
lighttpd/1.4.26 — лег сразу же
Cherokee/1.0.15 — никакого эффекта
Тут патчики для лайта. По идее в 1.4.27+ и в 1.5 ветке бага уже пофиксена.
Почему именно POST? Я так понимаю, что проблема с любым типом slow-соединения, нет?

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

Кстати, насколько я понимаю, указанная проблема существует только в условиях приёма неограниченного количества соединений с IP. Все нормальные сайты давно прикрыты nginx'ом, так что даже если вы начнёте развлекаться парочкой постов, то третий-четвёртый от вас просто не примут.
НЛО прилетело и опубликовало эту надпись здесь
Чем это отличается от медленного скармливания http-request?
НЛО прилетело и опубликовало эту надпись здесь
mod_limitipconn, по идее, не спасёт от ботнета, но спасёт от энтузиастов, желающих положить сайт с одного-двух компьютеров.
Проблема была описана по крайней мере пару лет назад, на хабре. Топик, составленный в форме вопроса, найти не получилось, но суть была в том, что автора пытались развести на бабло за прекращение атаки на его апач. Атака была описана именно так, как в этом топике. Сообщество предложило поставить 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
+сonnlimit
Ну или recent прикручивать, хотя это уже от HTTP Flood
Это решается очень просто с помощью событий и асинхронных серверов. Сам недавно написал свой асинхронный http-сервер и могу сказать, что на нём это не прокатит, т.к. он обрабатывает запросы по мере поступления, а не ждёт завершения какого-то одного медленного запроса. Сейчас почти все современные сервера работают по этой схеме (nginx, cherokee, lighttpd), разве что apache работает по устаревшему принципу с использованием блокирующих сокетов и тредов, т.е. если закончатся обработывающие треды, то апач «ляжет». Выход один — не использовать апач, т.к. по сути только он и подвержен этой атаке.
Ну ещё и IIS тоже. На своих серваках проверил и расстроился.
Если я не ошибаюсь, Windows не поддерживает нормальные методы работы с неблокирующими сокетами, только устаревший select, который потребляет много ресурсов. А значит асинхронные сервера для Windows писать не резон. Возможно там эта проблема решается каким-то другим способом, я с программированием серверов под win мало знаком, поэтому точно сказать не могу. У того же nginx на сайте в описании версии под win написано: «nginx/Windows работает с Win32 API (не эмуляция Cygwin). В качестве метода обработки соединений используется select, поэтому не стоит ожидать высокой производительности и масштабируемости.»
Мне кажется вы ошибаетесь. Асинхронные сокеты в Win существуют очень и очень давно.
Но скажу честно — предметом владею плохо.
IOCP
Мне показалось, или я несколько раз видел на хабре 503?
хмм,, nginx писал
Active connections = 243, при

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

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

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

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

Публикации

Истории