Re: Защита от шелов
точнее шелл правильно показывает высшую папку, как сервер рут и папку с сайтом, как документ рут. Но как сделать open_basedir?Хостинг Ру-Центр. 18.08.2013, 10:30, "Русанов Олег" lavan...@ya.ru:Здравствуйте. Есть ли способ предотвратить просматривать шелом другие сайты на виртуальном хосте?В конфиге сайта рут - папка где index.php, а шелл показывает, что root - это папка где все сайты находятся.Может быть в этом дело? -- С уважением,Олег Русанов.,___nginx-ru mailing listnginx-ru@nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением,Олег Русанов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Защита от шелов
Вам нужно добиться, чтобы php-скрипты запускались с правами пользователя, которому принадлежит сайт. На остальные сайты соответственно поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы они могли читать файлы. Как добиться? Разные способы есть. Например использование вместо mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к апачу типа mod_suid, mod_ruid которые работают совместно с mod_php. 18 августа 2013 г., 10:29 пользователь Русанов Олег lavan...@ya.ruнаписал: Здравствуйте. Есть ли способ предотвратить просматривать шелом другие сайты на виртуальном хосте? В конфиге сайта рут - папка где index.php, а шелл показывает, что root - это папка где все сайты находятся. Может быть в этом дело? -- С уважением, Олег Русанов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Защита от шелов
Это слишком сложно, как я это сделаю на хостинге Ру-Центра? В конфиг Апача не помогает:Directory /home/идентификатор/домен/docsphp_admin_value open_basedir /home/идентификатор/домен/docsphp_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp/Directoryможет это надо как-то в конфиг Энджиникса прописать? 18.08.2013, 10:45, "Виктор Вислобоков" corocho...@gmail.com:Вам нужно добиться, чтобы php-скрипты запускались с правами пользователя, которому принадлежит сайт. На остальные сайты соответственно поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы они могли читать файлы. Как добиться? Разные способы есть. Например использование вместо mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к апачу типа mod_suid, mod_ruid которые работают совместно с mod_php.18 августа 2013 г., 10:29 пользователь Русанов Олег lavan...@ya.ru написал:Здравствуйте. Есть ли способ предотвратить просматривать шелом другие сайты на виртуальном хосте?В конфиге сайта рут - папка где index.php, а шелл показывает, что root - это папка где все сайты находятся.Может быть в этом дело? -- С уважением,Олег Русанов.___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru,___nginx-ru mailing listnginx-ru@nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением,Олег Русанов.___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Защита от шелов
Directory /home/идентификатор/домен/docsphp_admin_value open_basedir /home/идентификатор/домен/docsphp_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp/Directory Вот это работает все-таки, только если прописывать не в /home/user/d.ru/conf/virtual.conf.manual, а в /home/user/etc/httpd.confИ права должны быть выключены "для других". а Ру-Центр неплохой хостинг, у них еще в Амстердаме площадка открылась,так что по-моему они - лучший вариант. 18.08.2013, 11:03, "Artem Vasiliev" artem.vasil...@gmail.com:Сменить хостингWBRArtem V. VasilievSent from Mailbox for iPhoneOn Sun, Aug 18, 2013 at 10:58 AM, Русанов Олег lavan...@ya.ru wrote:Это слишком сложно, как я это сделаю на хостинге Ру-Центра? В конфиг Апача не помогает:Directory /home/идентификатор/домен/docsphp_admin_value open_basedir /home/идентификатор/домен/docsphp_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp/Directoryможет это надо как-то в конфиг Энджиникса прописать? 18.08.2013, 10:45, "Виктор Вислобоков" corocho...@gmail.com:Вам нужно добиться, чтобы php-скрипты запускались с правами пользователя, которому принадлежит сайт. На остальные сайты соответственно поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы они могли читать файлы.Как добиться? Разные способы есть. Например использование вместо mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к апачу типа mod_suid, mod_ruid которые работают совместно с mod_php.18 августа 2013 г., 10:29 пользователь Русанов Олег lavan...@ya.ru написал:Здравствуйте. Есть ли способ предотвратить просматривать шелом другие сайты на виртуальном хосте?В конфиге сайта рут - папка где index.php, а шелл показывает, что root - это папка где все сайты находятся.Может быть в этом дело? -- С уважением,Олег Русанов.___ nginx-ru mailing listnginx-ru@nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru,___nginx-ru mailing listnginx-ru@nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением,Олег Русанов.___nginx-ru mailing listnginx-ru@nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru,___nginx-ru mailing listnginx-ru@nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением,Олег Русанов.___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Защита от шелов
Да, отруби ты уже этот html. Глаза сломать можно. On Sun, Aug 18, 2013 at 10:58:13AM +0400, Русанов Олег wrote: divЭто слишком сложно, как я это сделаю на хостинге Ру-Центра? /divdiv /divdivВ конфиг Апача не помогает:/divdivspan style=background-color:#f9f9f9;font-family:verdana,arial,sans-serif;font-size:11px;lt;Directory /home/идентификатор/домен/docsgt;/span/divdivspan style=font-family:verdana,arial,sans-serif;font-size:11px;background-color:#f9f9f9;php_admin_value open_basedir /home/идентификатор/домен/docs/spanbr style=font-family:verdana,arial,sans-serif;font-size:11px; /span style=font-family:verdana,arial,sans-serif;font-size:11px;background-color:#f9f9f9;php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp/spanbr style=font-family:verdana,arial,sans-serif;font-size:11px; /span style=font-family:verdana,arial,sans-serif;font-size:11px;background-color:#f9f9f9;lt;/Directorygt;/span/divdivможет это надо как-то в конфиг Энджиникса прописать?/divdiv /divdiv18.08.2013, 10:45, Виктор Вислобоков lt;corocho...@gmail.comgt;:/divblockquote type=citedivdivВам нужно добиться, чтобы php-скрипты запускались с правами пользователя, которому принадлежит сайт. На остальные сайты соответственно поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы они могли читать файлы.br / /divКак добиться? Разные способы есть. Например использование вместо mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к апачу типа mod_suid, mod_ruid которые работают совместно с mod_php./divdivbr /br /div18 августа 2013 г., 10:29 пользователь Русанов Олег spanlt;a href=mailto:lavan...@ya.ru; target=_blanklavan...@ya.ru/agt;/span написал:br /blockquote style=margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex;divЗдравствуйте. Есть ли способ предотвратить просматривать шелом другие сайты на виртуальном хосте?/divdivВ конфиге сайта рут - папка где index.php, а шелл показывает, что root - это папка где все сайты находятся./divdivМожет быть в этом дело?/divdiv /divdiv /divdiv-- br /С уважением,br /Олег Русанов./divbr /___br / nginx-ru mailing listbr / a href=mailto:nginx-ru@nginx.org;nginx-ru@nginx.org/abr / a href=http://mailman.nginx.org/mailman/listinfo/nginx-ru; target=_blankhttp://mailman.nginx.org/mailman/listinfo/nginx-ru/a/blockquote/div/div,p___br /nginx-ru mailing listbr /a href=mailto:nginx-ru@nginx.org;nginx-ru@nginx.org/abr /a href=http://mailman.nginx.org/mailman/listinfo/nginx-ru;http://mailman.nginx.org/mailman/listinfo/nginx-ru/a/p/blockquotediv /divdiv /divdiv-- br /С уважением,br /Олег Русанов./div ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кеширование проблема: перестает кешировать
продолжаю играться с кешированием на тестах (в том числе конкурентных, ab) все было хорошо - попробовали под нагрузкой. nginx 1.2.1 да видимо есть бага какая-то. причем похоже бага с обработкой 'X-Accel-Expires' прорывает кеш периодически и на бакенд идет толпища запросов. убрал в nginx возможность управлять кешом со стороны бакенда proxy_ignore_headers 'X-Accel-Expires'; и стало работать нормально: на бакенд проходит 1 запрос в секунду на nginx - 500-600. а когда управляли кешированием с бакенда, всегда выдавая X-Accel-Expires: 30 то периодически на бакенд прорывается один и тот же запрос с частотой 200-300 в секунду (при 500-600 на фронтенде) да, в 1.2.1 прорывается кеш и в случае использования Accel-Expires тега и в случае его неиспользования. сапгрейдил nginx до 1.4. смотрим, ждем. видимо надо свое кеширование писать, раз даже в nginx не могут его запилить чтобы работало :( -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re[2]: set на уровне http
Здравствуйте, Maxim.
set на уровне http был бы очень удобен порой. Обходить это через
map 1 $var {
default value;
}
неудобно.
http://nginx.org/en/docs/faq/variables_in_config.html
Признаюсь, что не въехал в ответ по ссылке. Все слова знакомые, а
собранные вместе смысл никакой в моей голове не приобретают. Тупею,
видимо. :-)
Опишу задачу. Мне надо было как-то писать в аксес-лог кэш-зону, чтобы
потом по логам считать эффективность каждой кэш-зоны. Встроенную
переменную я не знаю, поэтому решил создать переменную через set. Там,
где запросы проксируются, я присваивал через set соответствующей
переменной значение, равное имени кэшзоны. Но не все запросы
проксируются и в логе вместо значения переменной пишется пустая
строка, что неудобно для парсинга лога. Брать переменную в кавычки
тоже неудобно.
Для таких запросов я хотел присвоить этой переменной дефолтное
значение -. Писать в каждом блоке server{} set или include посчитал
лишним и вставил в http{} вот такие строчки:
# set нельзя делать на уровне http, поэтому делаем присваивание
через map
map 1 $cache_zone_for_logging {
default -;
}
Т.е. я хотел использовать set для инициализации переменной, которая
потом может меняться.
На мой примитивный взгляд кажется нелогичным иметь иерархию блоков
конфига, иметь наследование с вышестоящих уровней иерархии и разрешать
set-у работать на уровне http{}.
Всмысле - _не_ разрешать?
Да. Ошибся.
Проблема состоит в том, что set - это директива модуля rewrite,
которая не наследуется, выполняется вместе с остальными директивами
в rewrite-фазе и т.п.
Это всё тонкости реализации не ясные 99% процентам пользователей
nginx-а.
Ну вынесите её в отдельный модуль mod_set или ещё как-то проблему
наверняка можно исправить.
Вводить директиву set на уровне http с совершенно другой семантикой
- это не очень хорошая идея.
Зачем другая семантика. Оставить всё как есть, только дать возможность
писать в конфиге set на уровне http{}. Это удобно, логично, упрощает
конфиг, избавляет от копипасты. Во всяком случае мне так видится. Хотя
судя по активности в треде это больше никому не надо. Так что можете
забить, если реально много писать, тестировать и многое поломается.
--
С уважением,
Михаил mailto:postmas...@softsearch.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: одноразовые пароли в basic authentication
Hello! On Sun, Aug 18, 2013 at 01:34:03PM +0400, Vladislav Shabanov wrote: Добрый день. Подскажите, пож-ста, есть ли какое-нибудь готовое решение для аутентификации одноразовыми паролями в nginX. Предполагается использовать что-то наподобие вот этого: http://www.aladdin-rd.ru/catalog/etoken/pass/ Есть готовое решение для Apache (mod_authn_otp), но переходить на Apache 2.x не хочется. Встраивать проверку непосредственно в приложения совсем не хочется, т.к. их несколько на разных языках. Варианты, которые рассматривал: 1.готовый модуль nginX: не нашёл 2.модуль для PAM: нашёл, но непонятно как кэшировать пароль на сервере так, чтобы при загрузке каждой страницы он заново не требовал нового одноразового пароля. 3.модуль для Radius: вроде как есть такой зверь где-то, но опять непонятно, может ли Radius или модуль к nginX кэшировать одноразовый пароль + IP с которого была успешная аутентификация в течение заданный интервала времени. Есть у кого-нибудь работающее решение этой задачи? Из банальных решений - взять auth request[1], и написать бекенд и/или использовать Apache с нужными модулями в роли такового. [1] http://mdounin.ru/hg/ngx_http_auth_request_module -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кеширование проблема: перестает кешировать
Hello! On Sun, Aug 18, 2013 at 11:42:24PM +0400, Dmitry E. Oboukhov wrote: продолжаю играться с кешированием на тестах (в том числе конкурентных, ab) все было хорошо - попробовали под нагрузкой. nginx 1.2.1 да видимо есть бага какая-то. причем похоже бага с обработкой 'X-Accel-Expires' прорывает кеш периодически и на бакенд идет толпища запросов. убрал в nginx возможность управлять кешом со стороны бакенда proxy_ignore_headers 'X-Accel-Expires'; и стало работать нормально: на бакенд проходит 1 запрос в секунду на nginx - 500-600. а когда управляли кешированием с бакенда, всегда выдавая X-Accel-Expires: 30 то периодически на бакенд прорывается один и тот же запрос с частотой 200-300 в секунду (при 500-600 на фронтенде) да, в 1.2.1 прорывается кеш и в случае использования Accel-Expires тега и в случае его неиспользования. сапгрейдил nginx до 1.4. смотрим, ждем. видимо надо свое кеширование писать, раз даже в nginx не могут его запилить чтобы работало :( Сторонние модули выпилили, или как в прошлый раз? Ждать, что кеширование будет работать, если в логах вполне однозначно написано, что из-за стороннего модуля cache manger умер - несколько наивно. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Защита от шелов
php_value open_basedir /home/user/1.ru/docs такое спасает только от PHP. Но если запустить perl или ещё чего - проблема остаётся, потому что на них ограничения PHP не распространяются. Так что правильное решение - это разделение прав доступа по сайтам - всё остальное лишь полумеры 18 августа 2013 г., 12:44 пользователь Русанов Олег lavan...@ya.ruнаписал: На счет прав не знаю теперь, это у меня из кэша шелл грузился. оказывается, а так выше папки сайта не может выйти, если в в /home/user/etc/httpd.conf прописать. В общем работает и удобнее всего, наверное, это: в .htaccess добавить: php_value open_basedir /home/user/1.ru/docs 18.08.2013, 11:19, Русанов Олег lavan...@ya.ru: Directory /home/идентификатор/домен/docs php_admin_value open_basedir /home/идентификатор/домен/docs php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp /Directory Вот это работает все-таки, только если прописывать не в /home/user/ d.ru/conf/virtual.conf.manual, а в /home/user/etc/httpd.conf И права должны быть выключены для других. а Ру-Центр неплохой хостинг, у них еще в Амстердаме площадка открылась, так что по-моему они - лучший вариант. 18.08.2013, 11:03, Artem Vasiliev artem.vasil...@gmail.com: Сменить хостинг WBR Artem V. Vasiliev Sent from Mailbox for iPhone On Sun, Aug 18, 2013 at 10:58 AM, Русанов Олег lavan...@ya.ru wrote: Это слишком сложно, как я это сделаю на хостинге Ру-Центра? В конфиг Апача не помогает: Directory /home/идентификатор/домен/docs php_admin_value open_basedir /home/идентификатор/домен/docs php_admin_value upload_tmp_dir /home/идентификатор/домен/docs/tmp /Directory может это надо как-то в конфиг Энджиникса прописать? 18.08.2013, 10:45, Виктор Вислобоков corocho...@gmail.com: Вам нужно добиться, чтобы php-скрипты запускались с правами пользователя, которому принадлежит сайт. На остальные сайты соответственно поставите права 0750 а апача и nginx добавите в группу пользователя, чтобы они могли читать файлы. Как добиться? Разные способы есть. Например использование вместо mod_php для PHP режимов suexec или fastCGI. Есть ещё и всякие модули к апачу типа mod_suid, mod_ruid которые работают совместно с mod_php. 18 августа 2013 г., 10:29 пользователь Русанов Олег lavan...@ya.ru написал: Здравствуйте. Есть ли способ предотвратить просматривать шелом другие сайты на виртуальном хосте? В конфиге сайта рут - папка где index.php, а шелл показывает, что root - это папка где все сайты находятся. Может быть в этом дело? -- С уважением, Олег Русанов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru , ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Олег Русанов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru , ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Олег Русанов. , ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением, Олег Русанов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
trouble building nginx from dotdeb
I'm trying to follow this tutorial: http://www.howtoforge.com/using-ngx_pagespeed-with-nginx-on-debian-wheezy to build nginx with ngx_pagespeed on a Debian Wheezy machine. Unfortunately so far I have been using nginx from dotdeb so I'm trying to use their sources. The error occurs when building: debuild -us -uc . . . make: *** [config.status.full] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc failed the rules file has only 319 lines though and ends with: .PHONY: build clean binary-indep binary-arch binary install so I'm not sure what the exact problem is. Any hints how to further diagnose this error? Posted at Nginx Forum: http://forum.nginx.org/read.php?2,241972,241972#msg-241972 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: trouble building nginx from dotdeb
Use the official instructions from https://github.com/pagespeed/ngx_pagespeed and you'll have no problems. Well, I haven't upgraded from 1.4.1 yet, but that works fine. Steve On 18/08/13 19:46, ovidiu wrote: I'm trying to follow this tutorial: http://www.howtoforge.com/using-ngx_pagespeed-with-nginx-on-debian-wheezy to build nginx with ngx_pagespeed on a Debian Wheezy machine. Unfortunately so far I have been using nginx from dotdeb so I'm trying to use their sources. The error occurs when building: debuild -us -uc . . . make: *** [config.status.full] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc failed the rules file has only 319 lines though and ends with: .PHONY: build clean binary-indep binary-arch binary install so I'm not sure what the exact problem is. Any hints how to further diagnose this error? Posted at Nginx Forum: http://forum.nginx.org/read.php?2,241972,241972#msg-241972 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: trouble building nginx from dotdeb
Thanks, I knew about those instructions but I was trying to build it hte Debian way :-( Found this page with some more instructions/hints: http://wiki.debian.org/IntroDebianPackaging but no luck. So I guess if nobody can help me do it this way, in a few days I'll give it a try with the instructions you linked to. Posted at Nginx Forum: http://forum.nginx.org/read.php?2,241972,241974#msg-241974 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
multiple nginx
Hi, Is is alright to have two installations of nginx on the same machine? I have a running instance of nginx with php installed from distribution package manager. Instead of writing another config, I would like to compile and install nginx from source code and run as second instance. The second instance is to optimize for load balancing, reverse proxy, cache and modsecurity. My concerns is would this break the system on debian squeeze? Thanks for answering. Edwin Lee ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: multiple nginx
you could specify the configure file by -c option or even specify prefix by -p and could compile anther nginx instance by --prefix configure option 2013/8/18 Edwin Lee edwin...@proxyy.biz Hi, Is is alright to have two installations of nginx on the same machine? I have a running instance of nginx with php installed from distribution package manager. Instead of writing another config, I would like to compile and install nginx from source code and run as second instance. The second instance is to optimize for load balancing, reverse proxy, cache and modsecurity. My concerns is would this break the system on debian squeeze? Thanks for answering. Edwin Lee ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
Hi,
Thanks for the insight.
Finally I solved by:
if ($scheme = https) {
gzip off;
}
Separating into two servers require to duplicate the rules like rewrite,
which is cumbersome.
Thanks anyway
On Sat, Aug 17, 2013 at 8:43 PM, Igor Sysoev i...@sysoev.ru wrote:
On Aug 17, 2013, at 8:59 , howard chen wrote:
Hi,
As you know, due the breach attack (http://breachattack.com), HTTP
compression is no longer safe (I assume nginx don't use SSL compression by
default?), so we should disable it.
Yes, modern nginx versions do not use SSL compression.
Now, We are using config like the following:
gzip on;
..
server {
listen 127.0.0.1:80 http://127.0.0.1/ default_server;
listen 127.0.0.1:443 default_server ssl;
With the need to split into two servers section, is it possible to turn
off gzip when we are using SSL?
You have to split the dual mode server section into two server server
sections and set gzip off
SSL-enabled on. There is no way to disable gzip in dual mode server
section, but if you really
worry about security in general the server sections should be different.
--
Igor Sysoev
http://nginx.com/services.html
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
I thought that if statements slowed nginx down?
On Sun, Aug 18, 2013 at 6:27 AM, howard chen howac...@gmail.com wrote:
Hi,
Thanks for the insight.
Finally I solved by:
if ($scheme = https) {
gzip off;
}
Separating into two servers require to duplicate the rules like rewrite,
which is cumbersome.
Thanks anyway
On Sat, Aug 17, 2013 at 8:43 PM, Igor Sysoev i...@sysoev.ru wrote:
On Aug 17, 2013, at 8:59 , howard chen wrote:
Hi,
As you know, due the breach attack (http://breachattack.com), HTTP
compression is no longer safe (I assume nginx don't use SSL compression by
default?), so we should disable it.
Yes, modern nginx versions do not use SSL compression.
Now, We are using config like the following:
gzip on;
..
server {
listen 127.0.0.1:80 http://127.0.0.1/ default_server;
listen 127.0.0.1:443 default_server ssl;
With the need to split into two servers section, is it possible to turn
off gzip when we are using SSL?
You have to split the dual mode server section into two server server
sections and set gzip off
SSL-enabled on. There is no way to disable gzip in dual mode server
section, but if you really
worry about security in general the server sections should be different.
--
Igor Sysoev
http://nginx.com/services.html
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
Igor Sysoev Wrote: --- Yes, modern nginx versions do not use SSL compression. [...] You have to split the dual mode server section into two server server sections and set gzip off SSL-enabled on. There is no way to disable gzip in dual mode server section, but if you really worry about security in general the server sections should be different. If modern versions do not use ssl compression why split a dual mode server? If gzip is on in the http section, what happens then to the ssl section of a dual mode server? Posted at Nginx Forum: http://forum.nginx.org/read.php?2,241953,241984#msg-241984 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
On 18 August 2013 18:09, itpp2012 nginx-fo...@nginx.us wrote: Igor Sysoev Wrote: --- Yes, modern nginx versions do not use SSL compression. [...] You have to split the dual mode server section into two server server sections and set gzip off SSL-enabled on. There is no way to disable gzip in dual mode server section, but if you really worry about security in general the server sections should be different. If modern versions do not use ssl compression why split a dual mode server? If gzip is on in the http section, what happens then to the ssl section of a dual mode server? +1 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
I think you mistake ssl/tls level compression with gzip http compression, both are different. If you put gzip in http section, all server sections under this http will inherits this gzip config. This is why Igor recommends you to split the server config for SSL and non-SSL, and put 'gzip on' only at the non-SSL one. On Mon, Aug 19, 2013 at 12:15 AM, Jonathan Matthews cont...@jpluscplusm.com wrote: On 18 August 2013 18:09, itpp2012 nginx-fo...@nginx.us wrote: Igor Sysoev Wrote: --- Yes, modern nginx versions do not use SSL compression. [...] You have to split the dual mode server section into two server server sections and set gzip off SSL-enabled on. There is no way to disable gzip in dual mode server section, but if you really worry about security in general the server sections should be different. If modern versions do not use ssl compression why split a dual mode server? If gzip is on in the http section, what happens then to the ssl section of a dual mode server? +1 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx -- regards, Nurahmadie -- ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
This discussion started regarding concerns about the BREACH, which (if you documented about it) attacks SSL-encrypted HTTP-level-compressed data, thus implying the discussion around gzip. --- *B. R.* ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx reload problem
Hello! On Sat, Aug 17, 2013 at 12:36:38PM -0400, B.R. wrote: Hello, On Sat, Aug 17, 2013 at 7:37 AM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! I don't think that calling nginx -t as a mandatory step before configuration reload is a good idea: nginx binary running and nginx binary on disk might be different, and nginx -t result might be incorrect because of this, in some cases rejecting valid configurations. Additionally, it does duplicate work by parsing/loading a configuration which will be again parsed by a master process during configuration reload. While in most cases it's not significant, I've seen configurations taking more than 1m to load due to big geo module bases used. In that case, the server admin has a problem, since he has no way to test the configuration other the calling 'reload' on the running instance and check the logs for errors, hoping they are not already crawling under production-related log messages... One way or another, you test the configuration against an existing binary because you want to start or reload this binary with the conf. There is no point in having a running instance having already deleted its disk binary file: If you are in transition between 2 versions of Nginx, you shouldn't also make big changes to the conf... That's a 2-steps procedures I'd say: One thing at a time. Making any changes to the configuration isn't something significant: even without changes at all new binary on disk might not consider an old configuration as a valid e.g. due to some module not compiled in. And a reload might be required for various external reasons. I don't say it's a normal situation, but it's possible, and proposed change to init script will prevent init script from working in such situation. Testing conf is of course a duplicate of work, but that's a safe operation. The command output will determine if your new configuration will work without having to carefully watch logs with anxiety. As I already tried to explain, watching logs is required anyway. There is the upgrade command in the init script shipped with nginx.org linux packages. Ok, so could Li have used the 'upgrade' command insted of 'reload' to reload the configuration and change the allocated memory? Yes. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
Igor said: You have to split the dual mode server section into two server server sections and set gzip off SSL-enabled on. There is no way to disable gzip in dual mode server section, but if you really worry about security in general the server sections should be different. Adie said: This is why Igor recommends you to split the server config for SSL and non-SSL, and put 'gzip on' only at the non-SSL one. So I can be clear, I have 'gzip_vary on' in my http block and in subsequent HTTPS blocks (I separate HTTP from HTTPS) I have 'gzip_vary' off. Am I doing it right? ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
On Sun, Aug 18, 2013 at 12:31 PM, Paul N. Pace paulnp...@gmail.com wrote: Igor said: You have to split the dual mode server section into two server server sections and set gzip off SSL-enabled on. There is no way to disable gzip in dual mode server section, but if you really worry about security in general the server sections should be different. Adie said: This is why Igor recommends you to split the server config for SSL and non-SSL, and put 'gzip on' only at the non-SSL one. So I can be clear, I have 'gzip_vary on' in my http block and in subsequent HTTPS blocks (I separate HTTP from HTTPS) I have 'gzip_vary' off. Am I doing it right? 'gzip_vary' was supposed to be 'gzip' ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
I think we could all benefit from a nginx recommendation on using gzip with single and dual mode server sections regarding a hardening approach against breach. Maxim? Posted at Nginx Forum: http://forum.nginx.org/read.php?2,241953,241993#msg-241993 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx reload problem
Hello, On Sun, Aug 18, 2013 at 3:14 PM, Maxim Dounin mdou...@mdounin.ru wrote: Making any changes to the configuration isn't something significant: even without changes at all new binary on disk might not consider an old configuration as a valid e.g. due to some module not compiled in. And a reload might be required for various external reasons. I don't say it's a normal situation, but it's possible, and proposed change to init script will prevent init script from working in such situation. OK I think I got it. 'reload' deals with a running instance while 'upgrade' starts a new one from the binary on disk, so it makes sense to check the configuration against the binary when upgrading but not when reloading in case the binary on disk changed in between. The latter is a weirdest-case scenario (since you change the binary when you want to upgrade something, which won't result in a 'reload' call), though possible... You decision makes sense and is the safest. Thanks for your lights on that. Testing conf is of course a duplicate of work, but that's a safe operation. The command output will determine if your new configuration will work without having to carefully watch logs with anxiety. As I already tried to explain, watching logs is required anyway. ... if you had changes between the binary on disk and the one being run. Which is highly unlikely to happen as calling 'reload' on the current process would mean applying the configuration made for the new binary to the old running one (which needs to be replaced ASAP since it can't resist to a server restart...). But yeah, in that weird case, you'll watch the logs. There is the upgrade command in the init script shipped with nginx.org linux packages. Ok, so could Li have used the 'upgrade' command insted of 'reload' to reload the configuration and change the allocated memory? Yes. Thanks. Your input has been much appreciated, as always... --- *B. R.* ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx reload problem
Hello! On Sun, Aug 18, 2013 at 05:29:11PM -0400, B.R. wrote: [...] Testing conf is of course a duplicate of work, but that's a safe operation. The command output will determine if your new configuration will work without having to carefully watch logs with anxiety. As I already tried to explain, watching logs is required anyway. ... if you had changes between the binary on disk and the one being run. Which is highly unlikely to happen as calling 'reload' on the current process would mean applying the configuration made for the new binary to the old running one (which needs to be replaced ASAP since it can't resist to a server restart...). But yeah, in that weird case, you'll watch the logs. Quote from my first messages in this thread: : What is very wrong is to assume that sending : a HUP signal to nginx is enough for a reload. For various : reasons, ranging from configuration syntax errors to out of memory : problems, configuration reload might fail. Even if the binary on disk matches one in memory, and configuration syntax is ok - it's always possible that system will run out of memory or file descriptors (or will reach per-process limits), or newly configured listening sockets will conflict with some other services running (or previously configured sockets in case of Linux, which doesn't allow wildcard and non-wildcard sockets to coexists), or something else will happen (including cases when reload is not possible due to requested configuration changes, see original question). Questions why nginx can't reload configuration appear in mailing lists on a regular basis. In addition to this thread, this week seen at least once in nginx-ru@, see [1]. Correct answer is usually the same - Try looking into error log. [1] http://mailman.nginx.org/pipermail/nginx-ru/2013-August/051677.html -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: ssl_cipher for mail not working
Hello! On Wed, Aug 14, 2013 at 06:56:32AM -0400, MKl wrote: Hello, to increase security of SSL I added some eliptic-curves-ciphers to the chain. For HTTPS it's working fine, but for the mail proxy it does not work, I only always get RC4-SHA instead of the ECDH ciphers. See configuration at the end of this message. I'm testing it with: openssl s_client -cipher 'ECDH:DH' -connect domain.de:443 openssl s_client -cipher 'ECDH:DH' -connect imap.domain.de:993 The first command gives me a successful connection with ECDHE-RSA-RC4-SHA, so for HTTPS the cipherlist is used. The second command fails with an error: sslv3 alert handshake failure, the IMAPS server does not provide ECDH support. I used exactly the same ssl_cipher line for HTTPS and the mail proxy. When using the following command without forcing any ciphers on the client I can see that RC4-SHA is the best cipher that is supported and used: openssl s_client -connect imap.domain.de:993 Anybody has an idea where the problem is? Looks like the problem fixed by this changeset: http://trac.nginx.org/nginx/changeset/32fe021911c9/nginx Should work fine in nginx 1.5.1+. [...] -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
On Aug 18, 2013, at 21:09 , itpp2012 wrote: Igor Sysoev Wrote: --- Yes, modern nginx versions do not use SSL compression. [...] You have to split the dual mode server section into two server server sections and set gzip off SSL-enabled on. There is no way to disable gzip in dual mode server section, but if you really worry about security in general the server sections should be different. If modern versions do not use ssl compression why split a dual mode server? If gzip is on in the http section, what happens then to the ssl section of a dual mode server? These are different vulnerabilities: SSL compression is subject to CRIME vulnerability while HTTP/SSL compression is subject to BREACH vulnerability. -- Igor Sysoev http://nginx.com/services.html ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: How to turn off gzip compression for SSL traffic
On Aug 18, 2013, at 14:27 , howard chen wrote:
Hi,
Thanks for the insight.
Finally I solved by:
if ($scheme = https) {
gzip off;
}
This does not work on server level. And on location level it may work in wrong
way.
Separating into two servers require to duplicate the rules like rewrite,
which is cumbersome.
I believe that dual mode server block may be subject to vulnerabilities due to
site map,
so BREACH is the least of them.
--
Igor Sysoev
http://nginx.com/services.html
On Sat, Aug 17, 2013 at 8:43 PM, Igor Sysoev i...@sysoev.ru wrote:
On Aug 17, 2013, at 8:59 , howard chen wrote:
Hi,
As you know, due the breach attack (http://breachattack.com), HTTP
compression is no longer safe (I assume nginx don't use SSL compression by
default?), so we should disable it.
Yes, modern nginx versions do not use SSL compression.
Now, We are using config like the following:
gzip on;
..
server {
listen 127.0.0.1:80 default_server;
listen 127.0.0.1:443 default_server ssl;
With the need to split into two servers section, is it possible to turn off
gzip when we are using SSL?
You have to split the dual mode server section into two server server
sections and set gzip off
SSL-enabled on. There is no way to disable gzip in dual mode server section,
but if you really
worry about security in general the server sections should be different.
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
