Ars Longa, Vita Brevis » Apache

mod_rewrite и content negotiation

Wandering Soul — Fri, 25 Feb 2011 02:35:39 +0000

Если mod_rewrite работает весьма избирательно

Ситуация (из шедевров арабских программистов): есть файлы login.php, logout.php, somethinglese.php и в том же духе.

Есть такие правила mod_rewrite:

RewriteEngine On
RewriteRule ^login$ login.php
RewriteRule ^logout$ logout.php
RewriteRule ^top-questions$ top.php?what=questions
# и так далее

При этом правила, для которых существует файл, имя которого без учёта расширения совпадает с запросом, не выполняются.
Например, запросы http://example.com/login, http://example.com/logout возвращают 404 ошибку, а http://example.com/top-questions отрабатывает на ура.

Налицо некая избирательность mod_rewrite. В чём же дело?

Есть такая штука, называется Content Negotiation. Её суть вкратце сводится к тому, что web-сервер отдаёт пользователю разные документы в зависимости от заголовков Accept. В Apache поддержка данного механизма реализована модулем mod_negotiation.

Работает оно так: когда сервер получает запрос на /some/dir/foo, при этом поддержка для MultiViews для каталога /some/dir включена, а ресурс /some/dir/foo не существует, сервер ищет в кталоге файлы по маске foo.* и выбирает тот, который клиенту подходит больше всего.

Проблема в том, что Content Negotiation происходит до включения mod_rewrite в обработку запроса. Как следствие, /login — это уже не /login, в результате чего правило не выполняется.

Решения проблемы два:

Если content negotiation не нужен, его можно просто отключить: Options -MultiViews
Не использовать такие правила (и вообще с точки зрения производительности лучше обходиться минимумом правил — например, переписывая все запросы на index.php, который реализует всю эту логику внутри).

Аналогичный вопрос на Stack Overflow.

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

Заголовки 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.

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

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

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: часть 1

Vladimir — Fri, 13 Nov 2009 23:17:34 +0000

Тест страничных кэшей на виртуальном сервере абсолютного чайника

После того, как MAX’у не понравился тест с участием MaxSite Cache, я решил несколько видоизменить методику тестирования.

На этот раз я тестировал только два кэша: WP Super Cache и MaxSite Cache Lite.

Так как по словам MAX’а в реальности все ставится «из коробки», я взял виртуальный сервер (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на который поставил Ubuntu 8.04 LTS Server Edition. Затем поставил Apache (2.2.8-1ubuntu0), PHP (5.2.4-2ubuntu5.6) и MySQL (5.0.51a-3ubuntu5.4). Конфигурационные файлы брались «из коробки» (только для Apache пришлось включить mod_rewrite), в системной конфигурации абсолютно ничего не менялось. VDS абсолютного «чайника». Для мониторинга ресурсов системы установил munin (он рисует такие красивые графики).

Кому интересно, VDS конфигурировался так:

wget http://ubuntu-releases.eecs.wsu.edu/hardy/ubuntu-8.04.3-server-i386.iso
VBoxManage registerimage dvd /home/user1/ubuntu-8.04.3-server-i386.iso
VBoxManage createhd --filename TestVDS-HD1 --size 10240 --remember
VBoxManage createvm --name TestVDS --register
VBoxManage modifyvm TestVDS \
--ostype Ubuntu \
--memory 512 --vram 1 \
--acpi on --ioapic off --pae off --hwvirtex on --nestedpaging on \
--boot1 dvd \
--sata on --sataport1 TestVDS-HD1 \
--dvd /home/user1/ubuntu-8.04.3-server-i386.iso \
--floppy disabled \
--nic1 nat \
--audio none

VBoxManage setextradata TestVDS "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/Protocol" TCP
VBoxManage setextradata TestVDS "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/GuestPort" 80
VBoxManage setextradata TestVDS "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/HostPort" 8080

Затем я поставил WordPress 2.8.5 с официального сайта, импортировал в блог порядка 800 статей среднего размера (авторство статей не моё, так что выложить не могу).

Вместо Apache Bench я использовал Siege, обращение производилось ко всем страницам сайта в случайном порядке (вероятность обращения к заданной странице задавалась количеством её повторений в файле с адресами). Тестирование каждого варианта (WP Super Cache и MaxSite Cache) проводилось по 45 минут — 30 минут при низкой нагрузке и 15 минут при высокой (увы, трафик не безлимитный, и раскидываться гигабайтами трафика для теста возможности пока нет). Это имитировало постепенный наплыв пользователей на сайт. Специфика теста такова, что новый запрос не выполнялся до тех пор, пока не завершался предыдущий.

Одновременно к страницам обращалось 30 пользователей (Apache просто больше не выдерживает). Между тестами системе перезагружалась (на всякий случай). Виртуальный сервер и сервер, с которого осуществлялось тестирование, были, естественно, разными; соединены гигабитным каналом.

Результаты получились очень интересными: MaxSite Cache Lite строит кэш несколько быстрее, чем WP Super Cache (у MaxSite Cache более простая логика работы). WP Super Cache создаёт более сильную нагрузку на диск (так как файлы разбрасываются по множеству каталогов, а не кидаются в один) и, за счёт этого, чуть большую нагрузку на процессор (если сравнивать по значению idle time). Но при этом у WP Super Cache больший коэффициент параллельности (обслуживает большее число запросов одновременно).

Но при отдаче кэша и с повышением нагрузки результат меняется: WP Super Cache отдаёт данные быстрее и, как результат, обслуживает большее количество клиентов. Потребление памяти при этом чуть меньше, но загрузка процессора чуть больше. Вообще картину очень сильно портил munin — нагрузка, им создаваемая, вносила существенные погрешности в измерения (было видно в top).

Построение кэша
	WP Super Cache	MaxSite Cache
Количество транзакций	91,755	95,028
Объём данных, МБ	2,160.51	2,240.59
Среднее время ответа, с	0.05	0.04
Частота транзакций в секунду	50.97	52.79
Пропускная способность, МБ/с	1.20	1.24
Коэффициент параллельности	2.58	2.21
Максимальная длина транзакции, с	20.93	19.10
Минимальная длина транзакции, с	0.00	0.00

Использование кэша
	WP Super Cache	MaxSite Cache
Количество транзакций	219,761	206,949
Объём данных, МБ	5,129.06	4,880.30
Среднее время ответа, с	0.07	0.09
Частота транзакций в секунду	244.29	229.92
Пропускная способность, МБ/с	5.70	5.42
Коэффициент параллельности	27.89	21.58
Максимальная длина транзакции, с	21.96	21.58
Минимальная длина транзакции, с	0.00	0.00

Краткие выводы: в плане построения кэша производительность у MaxSite Cache Lite выше, что объясняется простотой его логики. Но при нагрузке и построенном кэше WP Super Cache обладает более высокой производительностью, так как web-сервер способен отдавать закэшированные данные без привлечения PHP. При одинаковом количестве запросов в секунду под нагрузкой WP Super Cache демонстрирует меньшее потребление памяти и нагрузку на процессор. При средней нагрузке на систему оба кэша ведут себя примерно одинаково — разница в потреблении памяти и нагрузке незаметна.

В следующей части: тест WP Super Cache и MaxSite Cache на грамотно настроенном сервере.

Обновление PHP до 5.2.x в CentOS 5

Vladimir — Sun, 21 Dec 2008 07:32:44 +0000

Просто, как раз-два-три

На сервере с CentOS 5.1 столкнулся с такой проблемой: Apache при открытии PHP-страниц с завидным постоянством писал в лог следующие ошибки:

*** glibc detected *** /usr/sbin/httpd: corrupted double-linked list: 0x09a939f8 ***

К сожалению, поиск в Google практических результатов не дал: ошибка могла случаться на любом железе и любой версии Linux. Больше всего жаловались (не)счастливые обладатели Zend Optimizer.

Обновил CentOS до 5.2 (в обновлении пришёл новый libc), но это не помогло. Странно, я видел много серверов, работающих на CentOS без таких ошибок.

Пытаясь найти минимальную конфигурацию, на которой бы воспроизводились ошибки, я отключал один за одним модули Apache, модули PHP, но всё тщетно. Когда же я отключил mod_php, ошибка пропала — на статических страницах всё было прекрасно.

PHP оказался старым: 5.1.6 или около того. А с обновлением были проблемы: RedHat ES5, как и CentOS, не поддерживает PHP более новых версий. Установка из исходного кода тоже не выход: на живом сервере нарушать зависимости пакетов почему-то не хотелось.

К счастью, выход нашелся довольно быстро: использовать репозиторий Remi Collet. Детали по ссылке, а мне помогло такое решение:

wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-2.noarch.rpm
wget http://rpms.famillecollet.com/el5.i386/remi-release-5-4.el5.remi.noarch.rpm
rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm
yum --enablerepo=remi update php

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

wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
wget http://rpms.famillecollet.com/el5.i386/remi-release-5-7.el5.remi.noarch.rpm
rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm
yum --enablerepo=remi update php

После чего

/etc/init.d/httpd restart
tail -f /var/log/httpd/error_log

Вуаля, ошибка исчезла! И не пришлось звать на помощь Мастерхост

Для возврата к старой версии PHP (мало ли) нужно сделать так:

yum --disablerepo=remi
yum remove php php-cli php-common
yum install php

WordPress: заменяем Apache nginx’ом

Vladimir — Tue, 25 Nov 2008 14:40:25 +0000

nginx + PHP + FastCGI + WordPress = рабочая конфигурация

Update: статья писалась давным-давно, правильная конфигурация nginx для работы с WordPress описана здесь.

Собственно, возникла идея: как заставить WordPress работать под другим web-сервером? Для начала я решил поэкспериментировать с nginx, если будет время — попробую и другие web-сервера.

Предполагается, что PHP в режиме FastCGI прослушивает 9000 порт на 127.0.0.1.

server {
listen 80;
server_name example.com;
index index.php;
root /var/www/example.com;

access_log /var/log/nginx/example.com-access.log;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/example.com$fastcgi_script_name;
include fastcgi_params;
}

location ~ /\.ht {
deny all;
}

if (!-e $request_filename) {
rewrite ^(.+)$ /index.php last;
}
}

fastcgi_params:

fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;

fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;

Как говорится, ничего сложного…

Apache: устанавливаем редирект с www.domain.com на domain.com и наоборот

Vladimir — Mon, 20 Oct 2008 23:39:58 +0000

Заезженная до дыр тема, обсуждаемая на всех форумах про Apache и mod_rewrite, но, тем не менее, не потерявшая своей актуальности до сих пор.

Правильное решение:

Перенаправление с www.domain.com на domain.com:

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*) http://%1/$1 [L,R=301]

Всё просто: если имя хоста начинается на www., отрезаем www. и выполняем редирект. Я предпочитаю перенаправление с кодом 301, у Вас могут быть свои предпочтения.
Перенаправление с domain.com на www.domain.com:

RewriteCond %{HTTP_HOST} !^$
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTP_HOST} (.+)$
RewriteRule ^(.*) http://www.%1/$1 [L,R=301]

Посложнее: проверяем, что имя хоста не пустое и не начинается на www.. Добавляем www. к имени хоста и выполняем редирект.

Разумеется, что mod_rewrite должен быть включен (RewriteEngine On). В целях повышения производительности имеет смысл помещать код не в .htaccess, а непосредственно внутрь директивы <VirtualHost> конфигурационного файла Apache.

Здесь рассмотрен простой случай: протокол HTTPS не используется. Реализация перенаправления с использованием HTTPS остаётся домашним заданием читателю

Настройка общих поддоменов (wildcard subdomains) в Apache

Vladimir — Sun, 20 Apr 2008 09:23:00 +0000

Настройка общих поддоменов за 5 минут

За последнюю неделю мне уже несколько раз приходилось рассказывать, как настраивать общие поддомены (известные как wildcard subdomains) в Apache и BIND/MaraDNS, поэтому решил написать статью, к которой можно будет отсылать интересующихся

Общие поддомены используются в силу множества причин: создание многопользовательских инсталляций блогов/форумов, где каждый пользователь получает домен вида username.domain.tld (в качестве примера можно привести известный WordPress µ), использование одной CMS для управления всеми поддоменами и т.п.

Для серверов на базе Apache процесс настройки общих поддоменов проходит в два этапа.

Создание wildcard-записи DNS
Первый шаг состоит в создании wildcard-записи DNS. Для разных DNS-серверов это будет осуществляться по-разному (в смысле, принцип один и тот же, различия лишь в синтаксисе конфигурационного файла). Рассмотрим на примере BIND (так как BIND работает и под Linux/UNIX, и под Windows).

Создание wildcard-записи очень просто: всё, что нужно — это добавить A-запись, связывающую имя вида *.domain.tld с IP-aдресом сервера.

Рассмотрим на примере одного development-сервера:
```
$TTL        86400
$ORIGIN internetnetworkmarketer.org.ua.
@  1D  IN         SOA ns1.internetnetworkmarketer.org.ua.        sjinks.internetnetworkmarketer.org.ua. (
                              2008030500 ; serial
                              24H ; refresh
                              15 ; retry
                              90w ; expire
                              15 ; minimum
                             )
                        IN  NS     ns1
                        IN  NS     ns.secondary.net.ua.
                        IN  NS     ns2.trifle.net.
                        IN  MX  10 @
                        IN  A      195.10.218.132
                        IN  TXT    "v=spf1 a mx:internetnetworkmarketer.org.ua -all"
                        IN  SPF    "v=spf1 a mx:internetnetworkmarketer.org.ua -all"
ns1                     IN  A      195.10.218.132
www                     IN  A      195.10.218.132
```
Мы видим, что домен internetnetworkmarketer.org.ua "живёт" по адресу 195.10.218.132; там же находятся два его поддомена — ns1.internetnetworkmarketer.org.ua и www.internetnetworkmarketer.org.ua (технически www.somesite.tld является поддоменом somesite.tld; в общем случае www.somesite.tld и somesite.tld могут быть совершенно разными сайтами).

На сайт был поставлен WordPress µ, вследствие чего нужно было создать общий поддомен — чтобы каждый пользователь получал блог вида username.internetnetworkmarketer.org.ua.

Добавление общего поддомена сводится к добавлению A-записи в конец файла зоны:
```
*.internetnetworkmarketer.org.ua.	IN  A      195.10.218.132
```
После чего нужно было перезапустить BIND.
После перезапуска придётся подождать некоторое время, пока новые настройки DNS "распространятся" через Internet (этот феномен называется DNS propagation).
Настройка виртуального хоста Apache
После того, как мы успешно настроили DNS, нужно указать Apache, что он должен обрабатывать адреса вида *.domain.tld (*.internetnetworkmarketer.org.ua в нашем случае).

Пусть в файле конфигурации у нас есть такая запись о виртуальном хосте:

<VirtualHost *:80>
DocumentRoot "/home/internetnetworkmarketer.org.ua"
ServerName "internetnetworkmarketer.org.ua"
ServerAlias "internetnetworkmarketer.org.ua" "www.internetnetworkmarketer.org.ua"
ErrorLog logs/internetnetworkmarketer.org.ua-error.log
CustomLog logs/internetnetworkmarketer.org.ua-access.log common
VirtualHost>

Всё, что нам надо — это добавить еще один псевдоним (alias) в директиву ServerAlias:

ServerAlias "internetnetworkmarketer.org.ua" "www.internetnetworkmarketer.org.ua" "*.internetnetworkmarketer.org.ua"

После внесения изменений Apache нужно перезапустить.

Вот так вот всё просто!