Ars Longa, Vita Brevis » nginx

Заголовки HTTP для обеспечения безопасности сайта

Wandering Soul — Mon, 03 Jan 2011 12:28:06 +0000

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

Безопасность сайта — это бесконечная битва между веб-мастерами и хакерами. В зарегистрировано около 40,000 сайтов, подверженных атакам XSS. XSS-атаки позволяют злоумышленникам красть cookie, личную информацию, взламывать аккаунты и многие другие вещи.

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

В данной статье будет показан один из вариантов защиты — основанный на использовании заголовков HTTP.

Современные браузеры сами предоставляют довольно мощную защиту для своих пользователей… Единственное «но» — сайт должен попросить браузер включить эту защиту. К счастью, это довольно просто.

Для Apache:

# Запретить всем сайтам загружать страницу через /
Header set X-Frame-Options DENY

# Разрешить выполнение JavaScript, загруженного только с нашего домена.
# Не выполнять встроенный (inline) JavaScript
Header set X-Content-Security-Policy "allow 'self';"

# Включение предотвращения XSS-атак в IE 8
Header set X-XSS-Protection "1; mode=block"

Для nginx:

add_header X-Frame-Options DENY;
add_header X-Content-Security-Policy "allow 'self';";
add_header X-XSS-Protection "1; mode=block";

X-Frame-Options

Данный заголовок указывает браузеру, можно ли загружать страницы сайта через <frame>/<iframe>.

Значение DENY запретит загрузку через фреймы, значение SAMEORIGIN разрешит загрузку через фреймы, но только если и фрейм, и страница, его загружающая, находятся на одном домене (Same Origin Policy).

основная функция данной защиты — предотвращение кликджекинга; в качестве дополнительного бонуса это позволит предотвратить атаку, описанную Ben Schmidt.

Заголовок воспринимается Internet Explorer 8.0+, Firefox 3.6.9+ (Gecko 1.9.2.9+), Opera 10.50+, Safari 4.0+, Chrome 4.1.249.1042+.

Подробное описание приведено здесь.

X-Content-Security-Policy

Данный заголовок указывает, как контент на сайте взаимодействует с самим сайтом. При помощи данного заголовка можно указывать, откуда можно загружать картинки, JavaScript, фреймы, шрифты, объекты, таблицы стилей, медиаконтент и многое другое.

Приведённый в примере выше заголовок разрешает загрузку контента только с того же домена, на котором располагается загружаемая страница. При этом браузеру запрещается выполнение встроенного JavaScript (скрипты внутри блоков <script>…</script>, обработчики событий и т.п.), создание кода из строк (например, через функцию eval(), а также передача строк в функции setTimeout(), setInterval() и т.п.), использование протокола data:.

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

X-Content-Security-Policy: allow https://*:443

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

X-XSS-Protection

Данный заголовок работает исключительно в Internet Explorer: он включает встроенную в браузер защиту от XSS-атак (по умолчанию она отключена, так как может некорректно работать с некоторыми сайтами). Подробная информация о принципах работы защиты от XSS-атак в IE приведена в The Windows Internet Explorer Weblog.

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

Оригинал статьи.

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

WordPress: кэширование средствами nginx

Vladimir — Fri, 10 Dec 2010 12:08:15 +0000

Уменьшение потребления ресурсов во много раз

Много было сказано про кэширование в WordPress… Сегодня я хочу рассказать о действительно эффективном методе, позволяющем сильно снизить нагрузку.

Метод основан на использовании кэша FastCGI web-сервера nginx.

Идея состоит в генерации статических страниц и отдачи их пользователям, не имеющим cookie комментатора. Зарегистрированным пользователям, а также комментаторам всегда отдаётся свежая страница. Так как читателей, ни разу не оставлявших комментарий, как правило, гораздо больше, чем комментаторов, то подобный использование кэша позволяет значительно снизить нагрузку на WordPress/PHP. Знакомые с принципом работы WP Super Cache заметят, что WPSC использует тот же принцип работы.

В чем же преимущество перекладывания работы на Web-сервер (nginx)?

PHP — интерпретируемый язык. Как следствие, аналогичный код на компилируемом языке будет во много раз быстрее.
WordPress во многом bloatware От момента начала загрузки страницы до окончания выполнения стадии init выполняется очень много «лишнего» кода.
В зависимости от нагрузки на сервер от запроса страницы до выполнения PHP-кода может пройти некоторое время: всё зависит от загруженности PHP (если все дочерние процессы PHP заняты обработкой запроса, новому запросу придётся ждать освобождения одного из процессов. Если за приемлемое время ни один процесс не освободился, пользователь видит сообщение о печально знаменитой ошибке 504).
Когда обслуживанием кэша занимается web-сервер, шансы на возникновение подобной ситуации

Теперь переходим от теории к практике.

fastcgi_cache_path /var/lib/nginx/myblog levels=2 keys_zone=myblog:10m max_size=512m inactive=20m;
server {
server_name example.com;
root /path/to/blog;
index index.php;
if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
set $do_not_cache 1;
}
fastcgi_cache_bypass $do_not_cache;
fastcgi_no_cache $do_not_cache;
fastcgi_pass_header Cookie;
fastcgi_cache myblog;
fastcgi_cache_key $request_method|$host|$request_uri;
fastcgi_cache_valid 301 8h;
fastcgi_cache_valid 404 1h;
fastcgi_cache_valid 200 15m;
if ($http_user_agent !~ FeedBurner) {
# Здесь идут перенаправления для FeedBurner
}
error_page 404 = @wordpress;
log_not_found off;
location ^~ /files/ {
rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
}
location ~ ^/(wp-admin/.*\.php|wp-login\.php|wp-register\.php|(feed|comment/feed)(/.*)?)$ {
try_files $uri @wordpress;
set $do_not_cache 1;
fastcgi_cache_bypass 1;
fastcgi_no_cache 1;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_index index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location @wordpress {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_NAME /index.php;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_index index.php;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
if ($do_not_cache != "1") {
add_header Vary Cookie;
}
}
location ~ \.php$ {
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
try_files $uri @wordpress;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
if ($do_not_cache != "1") {
add_header Vary Cookie;
}
}
location ^~ /blogs.dir/ {
internal;
root /path/to/blog/wp-content/;
}
}

Документация по использованию FastCGI в nginx приведена здесь, поэтому я не буду подробно останавливаться на том, что конкретно каждая директива делает.

Основная магия происходит в строка 8—10: здесь определяются условия, при которых отдаётся свежая страница. В данном случае проверяется наличие авторизационных cookie и cookie комментатора. Важно, чтобы в случае отказа от кэширования переменная $do_not_cache устанавливалась в 1.

Строка 16 задаёт ключ, по которому страница доступна в кэше. В ключе присутствует $request_method, чтобы различать запросы GET и HEAD (для HEAD данные не возвращаются, только заголовки).

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

В строке 32 задаётся маска для страниц, которые не должны кэшироваться (например, админка, страницы логина и регистрации, фиды).

Так как содержимое страницы может отличаться в зависимости от cookie пользователя, в строках 49 и 59 для закэшированных страниц принудительно выставляется заголовок Vary: Cache. Если используются другие правила (например, фильтрация по User-Agent), нужно добавлять соответствующее правило.

Строки 21—23: подробнее описано в статье «Перенаправление RSS в WordPress на FeedBurner для nginx»

Строки 28—30, 63—66 подробнее описаны в статье «WordPress MultiSite, nginx и X-Accel-Redirect»

Вроде бы ничего не забыл. Теперь о том, какую производительность мы получаем:

$ ab -n 10000 -c 100 http://blog.sjinks.pro/
Server Software: nginx
Server Hostname: blog.sjinks.pro
Server Port: 80

Document Path: /
Document Length: 50294 bytes

Concurrency Level: 100
Time taken for tests: 46.925 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 504940000 bytes
HTML transferred: 502940000 bytes
Requests per second: 213.10 [#/sec] (mean)
Time per request: 469.254 [ms] (mean)
Time per request: 4.693 [ms] (mean, across all concurrent requests)
Transfer rate: 10508.28 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 16 94 76.9 94 3125
Processing: 118 373 81.7 360 1334
Waiting: 17 69 38.5 57 422
Total: 156 467 105.0 445 3535

Percentage of the requests served within a certain time (ms)
50% 445
66% 454
75% 471
80% 494
90% 541
95% 589
98% 655
99% 768
100% 3535 (longest request)

Сервер зафлудили 10,000 запросами в 100 параллельных потоков. Сервер выдал практически полгигабайта за 47 секунд; в среднем сервер обрабатывал 213 запросов в секунду, при этом 99% запросов были обработаны за 768 мс (при том, что на сервере несколько сайтов в Alexa Top 100,000)! Нагрузка на сервер была минимальной (изменений Load Average замечено не было).

UPDATE: есть один небольшой нюанс: CAPTCHA. Если вы их используете, убедитесь, что они работают. Дело в том, что страница со статьёй будет отдаваться непосредственно из кэша nginx, PHP загружаться не будет. Поэтому если CAPTCHA полагается на использование сессии, она может работать неправильно. Здесь всё зависит от используемого плагина.

WordPress MultiSite, nginx и X-Accel-Redirect

Vladimir — Sat, 04 Dec 2010 09:25:34 +0000

Ускорение загрузки файлов с дочерних блогов

Одна из основных особенностей WordPress 3.0 — поддержка конфигурации MultiSite.

При использовании FastCGI с WordPress MultiSite может выявиться одно слабое место: загруженные файлы (которые uploads) дочерних блогов отдаются PHP-скриптом (wp-includes/ms-files.php). Если количество процессов FastCGI небольшое, а загружаемые файлы большие и при этом имеется медленные клиенты, проблемы с производительностью гарантированы: дело в том, что один процесс FastCGI в один момент времени может обслуживать только одного клиента. Если запущено 5 процессов php-cgi, и имеется пять медленных клиентов, качающих файлы, все остальные клиенты будут ждать освобождения процессов PHP. Если клиенты медленные, а файлы большие, ждущие клиенты будут получать ошибку 504.

К счастью, при использовании nginx проблема легко решается.

nginx поддерживает метод, при котором приложение (в данном случае WordPress) может переложить ответственность за отдачу файла клиенту на nginx. Это достигается путём использования специального заголовка, X-Accel-Redirect (интересующимся подробностями рекомендую статью Алексея Ковырина). WordPress полностью поддерживает данный метод. Но по умолчанию данный метод не используется, так как сначала нужно правильно настроить nginx.

Базовая настройка nginx для использования с WordPress приведена в соответствующей статье, здесь же мы рассмотрим изменения, необходимые для поддержки multisite.

Загруженные файлы дочерних блогов располагаются в каталогах /wp-content/blog.dir//; WordPress же для отдачи файлов использует URL вида http://site.blog.com/files/. Отдачей файла клиенту занимается файл /wp-includes/ms-files.php:

server {
#...

location ^~ /files/ {
rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
}

#...
}

В такой конфигурации отдавать файл клиенту будет сам WordPress (PHP), и при достаточной нагрузке мы столкнёмся с проблемами производительности. Поэтому настроим возможность отдачи файлов клиенту средствами nginx:

server {
#...

location ^~ /files/ {
rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
}

location ^~ /blogs.dir/ {
internal;
root /path/to/blog/wp-content/;
}

#...
}

Директива internal защищает файлы от прямых обращений, минуя /wp-includes/ms-files.php.

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

Затем добавляем следующую строку в /wp-config.php:

define('WPMU_ACCEL_REDIRECT', true);

После этого WordPress будет передавать заголовок X-Accel-Redirect с именем файла nginx, а nginx будет отдавать его клиенту. В результате скрипт PHP будет завершаться очень быстро и сможет обслуживать других клиентов.

Конфигурация nginx для работы с Simple Machines Forum

Wandering Soul — Thu, 23 Sep 2010 01:32:18 +0000

Настройка pretty permalinks в Simple Machines Forum при использовании nginx

Simple Machines Forum (SMF) — бесплатный интернет-форум, написанный на PHP и использующий базу данных MySQL.

«Дружественные URL» (ЧПУ) поддерживает только для Apache; для nginx, как водится, официальной поддержки нет. Поэтому в данной статье пойдёт речь именно о том, как заставить работать ЧПУ в nginx.

Начнём с того, что ЧПУ в SMF работают только через PATHINFO (ссылки вида index.php/something/goes/here). Это досадное недоразумение, к счастью, лечится.

Начнём с конфигурации виртуального хоста:

server {
server_name forum.example.com;

root /var/www/forum.example.com;
index index.php;

rewrite ^/index\.php/([a-z]+),([0-9]+)\.(\w+)/(\w+),(\w+)/(\w+)\.html /index.php?$1=$2.$3&$4=$5&$6 last;
rewrite ^/index\.php/([a-z]+),([0-9]+)\.(\w+)/(\w+),(\w+)\.html /index.php?$1=$2.$3&$4=$5 last;
rewrite ^/index\.php/([a-z]+),([0-9]+)\.(\w+)/(\w+)/(\w+)\.html /index.php?$1=$2.$3&$4&$5 last;
rewrite ^/index\.php/([a-z]+),([0-9]+)\.(\w+)/(\w+)\.html /index.php?$1=$2.$3&$4 last;
rewrite ^/index\.php/([a-z]+),([0-9]+)\.(\w+)\.html /index.php?$1=$2.$3 last;

rewrite ^/([a-z]+),([0-9]+)\.(\w+)/(\w+),(\w+)/(\w+)\.html /index.php?$1=$2.$3&$4=$5&$6 last;
rewrite ^/([a-z]+),([0-9]+)\.(\w+)/(\w+),(\w+)\.html /index.php?$1=$2.$3&$4=$5 last;
rewrite ^/([a-z]+),([0-9]+)\.(\w+)/(\w+)/(\w+)\.html /index.php?$1=$2.$3&$4&$5 last;
rewrite ^/([a-z]+),([0-9]+)\.(\w+)/(\w+)\.html /index.php?$1=$2.$3&$4 last;
rewrite ^/([a-z]+),([0-9]+)\.(\w+)\.html /index.php?$1=$2.$3 last;

location ~ \.php$ {
fastcgi_index index.php;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}
}

Я сознательно сделал два блока rewrite: первый (который содержит index\.php) предназначен для PATHINFO-ссылок; второй блок предназначен для нормальных ЧПУ. В принципе, достаточно только одного из блоков — в зависимости от того, какой тип ссылок планируется использовать.

Тем не менее, после конфигурирования nginx и включения «Дружественных URL» в панели управления форумом SMF всё равно продолжает использовать «человеконепонятные» URL. В чём причина? В движке форума: разработчики постарались, чтобы «Дружественные URL» работали только в Apache. Чтобы решить проблему, нужно немного подправить исходный код форума.

Открываем файл Sources/QueryString.php, в нём ищем функцию ob_sessrewrite (в 1.1.11 это самая последняя функция, располагается в конце файла).

В файле ищем такие строки:

// This should work even in 4.2.x, just not CGI without cgi.fix_pathinfo.
if (!empty($modSettings['queryless_urls']) && (!$context['server']['is_cgi'] || @ini_get('cgi.fix_pathinfo') == 1) && $context['server']['is_apache'])

Исправляем условие в if:

// This should work even in 4.2.x, just not CGI without cgi.fix_pathinfo.
if (true || !empty($modSettings['queryless_urls']) && (!$context['server']['is_cgi'] || @ini_get('cgi.fix_pathinfo') == 1) && $context['server']['is_apache'])

Сохраняем; после этого форум будет генерировать PATHINFO-ссылки. Если же index.php в ссылках смотрится некрасиво, то код нужно еще немного поправить:

// This should work even in 4.2.x, just not CGI without cgi.fix_pathinfo.
if (true || !empty($modSettings['queryless_urls']) && (!$context['server']['is_cgi'] || @ini_get('cgi.fix_pathinfo') == 1) && $context['server']['is_apache'])
{
// Let's do something special for session ids!
if (defined('SID') && SID != '')
$buffer = preg_replace('/"' . preg_quote($scripturl, '/') . '\?(?:' . SID . ';)((?:board|topic)=[^#"]+?)(#[^"]*?)?"/e', "'\"' . \$scripturl . '/' . strtr('\$1', '&;=', '//,') . '.html?' . SID . '\$2\"'", $buffer);
else
$buffer = preg_replace('/"' . preg_quote($scripturl, '/') . '\?((?:board|topic)=[^#"]+?)(#[^"]*?)?"/e', "'\"' . \$scripturl . '/' . strtr('\$1', '&;=', '//,') . '.html\$2\"'", $buffer);
}

Перед закрывающей скобкой нужно дописать две строчки:

// This should work even in 4.2.x, just not CGI without cgi.fix_pathinfo.
if (true || !empty($modSettings['queryless_urls']) && (!$context['server']['is_cgi'] || @ini_get('cgi.fix_pathinfo') == 1) && $context['server']['is_apache'])
{
// Let's do something special for session ids!
if (defined('SID') && SID != '')
$buffer = preg_replace('/"' . preg_quote($scripturl, '/') . '\?(?:' . SID . ';)((?:board|topic)=[^#"]+?)(#[^"]*?)?"/e', "'\"' . \$scripturl . '/' . strtr('\$1', '&;=', '//,') . '.html?' . SID . '\$2\"'", $buffer);
else
$buffer = preg_replace('/"' . preg_quote($scripturl, '/') . '\?((?:board|topic)=[^#"]+?)(#[^"]*?)?"/e', "'\"' . \$scripturl . '/' . strtr('\$1', '&;=', '//,') . '.html\$2\"'", $buffer);
$buffer = str_replace('index.php/', '', $buffer);
$buffer = str_replace('index.php', '', $buffer);
}

После этого можно использовать нормальные ЧПУ.

Конфигурация nginx для работы с FUDforum

Wandering Soul — Mon, 13 Sep 2010 02:32:01 +0000

Настройка PATHINFO и pretty permalinks в FUDforum при использовании nginx

FUDforum (Fast Uncompromising Discussion forum, Быстрый бескомпромиссный дискуссионный форум) — бесплатный интернет-форум с открытым кодом, обладающий широкими возможностями настройки и имеющий большой набор всяких плюшек и вкусностей.

В данной статье пойдёт речь о том, как подружить форум с nginx.

Официальный FAQ говорит о том, что FUDforum поддерживает как традиционные (со строкой запроса), так и PATHINFO-ссылки (то есть ссылки вида index.php/something/goes/here).

Традиционные ссылки используются для максимальной совместимости с различными web-серверами и, как следствие, никакие изменения в конфигурации nginx не требуются. Но SEO’шники не любят некрасивые ссылки, поэтому в FUDforum встроена «изкоробочная» поддержка красивых ссылок. В простейшем случае при использовании PATHINFO-ссылок для Apache ничего не нужно настраивать — всё работает из коробки, а для nginx нужно приложить некоторые усилия.

Итак, пусть у нас есть такая начальная конфигурация виртуального хоста форума:

server {
server_name forum.site.com;

root /home/site.com/forum;
index index.php;

location ~ \.php$ {
fastcgi_index index.php;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}
}

Для того, чтобы добавить поддержку PATHINFO, придётся переписать блок location. Дело в том, что nginx придётся явно указывать, где заканчивается имя скрипта и начинается PATHINFO.

Блок location будет выглядеть примерно так:

location ~ ^(.+\.php)(.*)$ {
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_index index.php;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
include /etc/nginx/fastcgi_params;
}

Изменилось регулярное выражение в location (так как в случае PATHINFO-ссылок имя php-скрипта будет находиться в середине URL), добавились директивы fastcgi_split_path_info и fastcgi_param PATH_INFO $fastcgi_path_info (первая указывает, как разбить URL на имя скрипта и PATHINFO, вторая передаёт PATHINFO php-скрипту).

Перезапускаем nginx, устанавливаем теме набор шаблонов path_info, перестраиваем тему, получаем красивые ссылки. Но index.php в URL выглядит не очень красиво, было бы неплохо убрать и его.

Это сложнее, но решаемо:

server {
server_name forum.site.com;

root /home/site.com/forum;
index index.php;

log_not_found off;
error_page 404 = @forum;

location ~ ^(.+\.php)(.*)$ {
try_files $uri @forum;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_index index.php;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
include /etc/nginx/fastcgi_params;
}

location @forum {
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param PATH_INFO $uri;
fastcgi_param SCRIPT_NAME /index.php;
}
}

После этого открываем файл FUDdata/include/compiler.inc (где FUDdata — каталог с внутренними данными форума — задаётся при инсталляции), ищем строку

$cmpl['ROOT'] = 'index.php';

изменяем на

$cmpl['ROOT'] = '.';

После чего сохраняем, перестраиваем тему и любуемся красивыми ссылками.

FogBugz 7 и nginx

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

Рабочая конфигурация nginx для FogBugz 7

На днях переводил один сервер с 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-сервера, что менее ресурсоёмко и чуть быстрее. Спички