Необычный DDos
Столкнулся с проблемой. Не могу отсеч DDos атаки, злоумышленники не делают много запросов, с одного ip не более 10 соединений. При подключении без взяких заголовков присылают \n\r , тем самым нагружают nginx worker. Ограничения по размеру запроса срабатывают видимо после обработки заголовка, а в этом случае заголовка нет, и так происходит пока по таймауту не отключается сокет. Может быть есть какое-то ограничение по размеру считанных в данном соединении байт. Я не нашел такого параметра. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,255615,255615#msg-255615 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
poodle and broken ssl alerts
После обновления openssl с 1.0.1g до 1.0.1j В логи стали в большом количестве сыпаться сообщения вида: [crit] 767#0: *44215130 SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking, client: 192.0.0.225, server: 0.0.0.0:443 В то, что кто то пытается делать downgrade в таком масштабе я поверить не готов. Скорее всего это несовместимость изменений в openssl с какими то клиентами. Кто нибудь разбирался с этой проблемой? Возможно есть какой то workaround чтобы не терять этих клиентов? Хорошая поддержка клиентов в моем случае важнее безопасности. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: NGINX Media Server
18.12.2014 8:16, Vadim A. Misbakh-Soloviov пишет: В письме от Ср, 17 декабря 2014 23:03:11 пользователь Андрей Василишин написал: на сервер, нужен только функционал без поддержки. А чего бы тогда просто не использовать (вкомпилировать) rtmp-модуль самому? на ранних стадиях результат работы этогомодуля былплачевный, как счас - не знаю. ну и не только ртмп-модулем славен медиа сервер ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Проксирование двух приложений и шифрование
Допустим, есть два веб-приложения, которые предлагается запроксировать следующим образом: https://www.example.com/apps/app1 и https://www.example.com/apps/app2 Но вот беда: оба этих приложения используют для загрузки статических файлов (картинок там, и прочего) один и тот же путь, скажем https://www.example.com/static Штука в том, что у каждого приложения своя статика. Как их так по-умному развести, чтобы они не пересекались? При этом возможности вмешаться в код приложения и изменить путь к статике у нас нет. И еще один вопрос - возникнут ли проблемы, если при проксировании proxy_pass направить на адрес, использующий SSL (https)? И если бэкенд использует самоподписный сертификат? Нужно ли как-нибудь вносить серитфикат в исключения, или Нджинкс не проверяет, а просто шифрует и все? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,255627,255627#msg-255627 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: poodle and broken ssl alerts
Hello! On Thu, Dec 18, 2014 at 01:19:03PM +0300, Anton Yuzhaninov wrote: После обновления openssl с 1.0.1g до 1.0.1j В логи стали в большом количестве сыпаться сообщения вида: [crit] 767#0: *44215130 SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking, client: 192.0.0.225, server: 0.0.0.0:443 В то, что кто то пытается делать downgrade в таком масштабе я поверить не готов. Скорее всего это несовместимость изменений в openssl с какими то клиентами. Кто нибудь разбирался с этой проблемой? Возможно есть какой то workaround чтобы не терять этих клиентов? Для начала имеет смысл попытаться выяснить, что это за клиенты, и воспроизводится ли проблема. В теории, такое может происходить и случайно - т.к. fallback может случиться просто от того, что не удалось установить соединение с первого раза. Just in case, уровень логгирования соответствующей ошибки понижен в 1.7.8, см. http://trac.nginx.org/nginx/ticket/662. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Необычный DDos
On Thursday 18 December 2014 04:56:02 Alexey72 wrote: У себя на 4х ядерной машине смоделировал, одно подключение попадает на один из worker'ов и загружает 30% ядра(на котором работает worker). Да и канал получается тоже забьется.. если их будет больше, и их не скинуть вовремя и не добавить в бан. Я к тому, что канал забьется раньше. Едва ли такая атака критична с точки зрения ресурсов процессора. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Не отдаёт ответ пока буфер не наполнится
Стоял Apache и веб-сервис (php), который работает постоянно и выдаёт ответ в произвольные моменты небольшими кусочками, всё работало превосходно. Т.е. открываем в браузере адрес и он так может висеть часами выдавая раз в секунду или вообще в произвольное время небольшой ответ по 1 или 2 строчки. При переезде на стандартную связку Apache + Nginx всё перестало работать. Причина - Nginx не отдаёт ответ, пока не заполнится буфер. Т.е. Apache может выдать 1000 строк и клиент ничего не увидит в браузере и только на 1001 строке Nginx отправит клиенту заполненный буфер. Пока Nginx не накопит 32 килабойта ответа, клиент ничего не получит. Вот конфиг буферов: client_header_buffer_size 4k; proxy_buffer_size 32k; proxy_buffering on; proxy_buffers 4 32k; Остальные сайты, которые крутятся рядом с сервисом, стали работать заметно хуже. Если конкретно, то была потеряна отзывчивость, сайты стали открываться только через 0.2-0.5 секунд опять же таки видимо только после того, как Nginx накопит буфер. Т.е. вместо супер быстрой обработки запросов Nginx наоборот ухудшил всё что можно и видимо виноват в этом я. Я озадачен, подскажите пожалуйста что делаю не так? В goole ответа не нашел, хотя мне кажется такой вопрос уже должен был обсуждаться за столько лет. Ткните носом если есть тема с решением. Как сделать, чтобы Nginx моментально начинал отдавать ответ клиенту синхронно с Apache, а не тогда когда получит буфер? Понятное дело, что буферы в Nginx созданы чтобы максимально быстро получить ответ от Apache с PHP и освободить их, но как сделать чтобы буфер мгновенно отдавался сразу клиенту начиная с первого полученного в буфер байта? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,255640,255640#msg-255640 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не отдаёт ответ пока буфер не наполнится
В письме от Чт, 18 декабря 2014 13:00:28 пользователь sofiamay написал: но ведь при этом Nginx не будет получать максимально быстро А как будет? Не максимально быстро? :) Нет никакой магии. С буферизацией ответа NginX сначала получает ответ, потом отдаёт его. Без буферизации — отдаёт сразу как получил (естественно, трятя определённое к-во микросекунд на проход мимо себя). Если бекенд отдаёт контент быстро, то можно увеличить размер буфера, тогда NginX не будет тратить время на дамп на диск того, что не поместилось в заданный вами размер, будет хранить поступающий ответ в памяти и оттуда целиком и быстро отдавать. Если бекенд отдаёт ответ медленно, но хочется чтобы клиент не ждал полчаса — можно отключить буферизацию ответа. Теряется весь смысл в буферах и их полезности. см. выше. Я конечно же спрашиваю о другом - как настроить чтобы Nginx по прежнему принимал максимально быстро весь ответ от Апача Он итак его принимает максимально быстро, на сколько может (на сколько быстро его отдаёт бекенд + задержки на путь от бекенда до NgX + пучок микросекунд на внутренние проверки). но при этом начинал его передавать сразу же с первого байта. Это взаимоисключающие параграфы. Либо NginX принимает весь ответ в буфер и сразу после принятия отдаёт его, либо он отдаёт его сразу как получил. Или так, или так. Третьего не дано. Что я делаю не так? Не понимаете сути вещей, например :) // или плохо читаете документацию и код. Или и то и другое. Тут сложно судить не будучи телепатом. -- Best regards, mva signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не отдаёт ответ пока буфер не наполнится
Я читал документацию, даже черезчур усердно. Видимо всё дело в том, что я переоценил возможности Nginx, я думал что он может принимать ответ в буфер от Apache и при этом одновременно отдавать его медленному клиенту. Т.е. я думал что он умеет одновременно и получать и отдавать свой буфер, оказалось нет. Получается что можно либо включить буферизацию и ждать пока первый буфер полностью не заполнится, либо выключить буферизацию. А то что мне надо Nginx не умеет. Ok большое спасибо за подсказки. P.S. Товарищ мне подсказал сделать 500 буферов по 256 байт, но чую это приведёт лишь к перерасходу ресурсов, накладные расходы и т.д. и это только во вред. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,255640,255644#msg-255644 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не отдаёт ответ пока буфер не наполнится
В письме от Чт, 18 декабря 2014 13:23:56 пользователь sofiamay написал: Я читал документацию, даже черезчур усердно. Видимо всё дело в том, что я переоценил возможности Nginx, я думал что он может принимать ответ в буфер от Apache и при этом одновременно отдавать его медленному клиенту. Т.е. я думал что он умеет одновременно и получать и отдавать свой буфер, оказалось нет. А смысл от этого? Воркфлоу с буферами: создал буферы = получил = отдал = уничтожил буферы Воркфлоу без буферов: получил = отдал Смысл от буферов, если их содержимое уже у клиента? Зачем его (содержимое) тогда буферизировать? Куда его дальше девать? Получается что можно либо включить буферизацию и ждать пока первый буфер полностью не заполнится, либо выключить буферизацию. А то что мне надо Nginx не умеет. Ok большое спасибо за подсказки. А что Вам надо? Из Вашего объяснения выходит что Вам нужно чтобы клиент моментально получал то, что отдал бекенд. Куда тогда контент из буферов девать, если он уже у клиента? Между запросами буферы не пересекаются (ну, есть всякие edge кейсы с дедупликацией памяти и миллионами запросов в секунду, когда могут, но у простых смертных шанс их пересечения маловероятен. P.S. Товарищ мне подсказал сделать 500 буферов по 256 байт, но чую это приведёт лишь к перерасходу ресурсов, накладные расходы и т.д. и это только во вред. В данном случае — да. Тем более, что в случае NgX и бекенда на одной машине буферизация, так-то, не особо и нужна. P.S. В соседнем треде же говорили: используйте IIS :D -- Best regards, mva signature.asc Description: This is a digitally signed message part. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не отдаёт ответ пока буфер не наполнится
А смысл от этого? Воркфлоу с буферами: создал буферы = получил = отдал = уничтожил буферы Воркфлоу без буферов: получил = отдал Смысл от буферов, если их содержимое уже у клиента? Зачем его (содержимое) тогда буферизировать? Куда его дальше девать? Смысл очевиден, освободить драгоценный ресурс - бекенд. Всосать всё в буфер с максимальной скоростью и отпустить воркера, а отдавать медленному клиенту уже из буфера. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не отдаёт ответ пока буфер не наполнится
Смысл вопроса прост, а ответ неочевиден: если клиент медленный и отключена буферизация? Как поступит nginx? Будет в час по чайной ложке забирать у бэкенда и передавать клиенту данные, задерживая таким образом бэкенд? Или все же получит куда-то ответ полностью и будет потихоньку его отдавать? 18 декабря 2014 г., 21:38 пользователь Vadim A. Misbakh-Soloviov m...@mva.name написал: В письме от Чт, 18 декабря 2014 13:23:56 пользователь sofiamay написал: А смысл от этого? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: the http output chain is empty bug
нда, значит исправлять не собираются... печально... Posted at Nginx Forum: http://forum.nginx.org/read.php?21,250456,255648#msg-255648 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: the http output chain is empty bug
Hello! On Thu, Dec 18, 2014 at 01:53:38PM -0500, tester123 wrote: нда, значит исправлять не собираются... печально... Вас просили проверить, воспроизводится ли проблема без сторонних модулей на свежей версии nginx'а, и предоставить данные по списку. Вы предоставили? Если да, то дайте ссылку, пожалуйста, потому что я их не вижу. Спасибо. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не отдаёт ответ пока буфер не наполнится
18 декабря 2014 г., 22:41 пользователь sofiamay nginx-fo...@nginx.us написал: Aleksandr Sytar Wrote: --- А вам не кажется, что в этом случае буфера нет? Или вы путаете буферизацию с кешированием ответов, или одно из двух. Да нет, не кажется. В таком варианте буфер есть, самый что ни на есть. А вот каким боком вы сюда приплели кэширование ответов, это вызывает вопрос - вы ничего не путаете? :-) Т.е. получил первый байт в буфер и тут же начинает передавать ответ клиенту при этом продолжая получать данные в буфер. - В чем тогда практический смысл буфера, какую он роль, оп вашему выполняет? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: poodle and broken ssl alerts
Hello! On Thu, Dec 18, 2014 at 08:12:00PM +0300, Anton Yuzhaninov wrote: On 12/18/14 17:13, Maxim Dounin wrote: В теории, такое может происходить и случайно - т.к. fallback может случиться просто от того, что не удалось установить соединение с первого раза. Да, похоже так оно и происходит. Посмотрел дампы трафика - в них хендшейк обрывается по таймауту и следующая попытка идёт с TLS_FALLBACK_SCSV. Но в дампе трафика встречаются Ecnripted Alert с TLS1.2 в то время как в логах кроме inappropriate fallback ошибок не видно. В случае inappropriate fallback версия должны быть меньше чем 1.2. Ошибки логгируются на разных уровнях в зависимости от собственно ошибки. Inappropriate fallback ты можешь видеть просто потому, что они логгируются на уровне crit в старых версиях, т.к. nginx их не ожидает увидеть. Было бы проще сравнивать лог nginx и дамп трафика, если в бы в error_log вместе с IP писался клиентский порт. Это сложно сделать? Где-нибудь в ngx_http_log_error() следом за addr_text выводить, разобрав c-sockaddr. Пример кода можно посмотреть в ngx_http_variable_remote_port(). -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не отдаёт ответ пока буфер не наполнится
mva Wrote: --- см. выше. В случае быстрых клиентов это не нужно. А с медленными можно бороться. Странный ответ. Уже как несколько лет получаю рассылку, а про борьбу с медленными клиентами ничего конкретного не было. Постоянные тычки в документацию про limit conn limi req и прочее, но всё это на самом деле никак не поможет с DDOS атакой с разных IP нормально организованной. На слабом сервере отключение буферизации и правильный ddos вмиг положит сервер залипшими запросами, когда клиент запрашивает самую жирную и медленную страницу на сервере и крайне медленно её получает. Никаких лимиты тут не помогут. Апаче иссякнет и будет висеть, вместо того чтобы Nginx быстро получил ответы в буфера по моей схеме и раздавал их потиху. Решение проблемы - включение буферизации, но это заметно снижает отклик, как вы сами сказали негативно сказывается на быстрых клиентах. Но раз вы утверждаете что предполагаемая мной схема работы с буфером (которой на самом деле нет) никому не нужна и с медленными коннектами можно бороться, то у меня к вам вопрос - КАК? Посоветуйте пожалуйста конкретные методы борьбы с таким типом DDOS, такие методы которые действительно будут работать. Условия: буферизация выключена, limit conn и limit req не помогают (это только от детей защита, а нет от медленных клиентов с разных ip), и Апаче, который дохнет без буферизации Nginx. Заранее спасибо за совет, а то тут часто любят бросаться фразами типа МОЖНО БОРОТЬСЯ, а вот как, это уже типо сами ищите. А на деле то никак, кроме как буфером. То есть пустые фразы. Даже Максим Дунин помнится в рассылке кому-то советовал limit conn и limit req и по делу больше ничего не подсказал, а вы говорите есть методы борьбы, вот мне и интересно стало, уже не те ли это самые методы которые и так всем известны и помогают они слабо Моя схема работы с буфером была бы очень кстати и она никак не блокирует работу Nginx, раз уж вы говорите про прелесть неблокируемости :-) Жаль что Nginx так не умеет. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,255640,255659#msg-255659 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не отдаёт ответ пока буфер не наполнится
Aleksandr Sytar Wrote: --- Т.е. получил первый байт в буфер и тут же начинает передавать ответ клиенту при этом продолжая получать данные в буфер. - В чем тогда практический смысл буфера, какую он роль, оп вашему выполняет? Ну как какую, позволяет моментально освободить жирные до памяти и неповоротливые воркеры Апача с PHP. Это же очевидно. Мой способ работы с буфером - это та же буферизация, только с моментальной отдачей. И буфер работает и ответ не задерживается. Я же говорю, изначально думал что так и есть, просто в конфиге проблема. Оказалось что схема работы с буферами совсем иная. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,255640,255660#msg-255660 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
