Существуют различные схемы построения веб-серверов для передачи данных по протоколу HTTP. Среди них достойное место по производительности занимают схемы с использованием «Nginx» в качестве внешнего (кэширующего, front-end) сервера. «Nginx» разработан для отдачи статических данных, при этом, он показывает высокое быстродействие и нагрузочную способность (см. Nginx vs Cherokee vs Apache vs Lighttpd), генерировать же динамическое содержимое он не способен. Поэтому, он часто применяется в связке с внутренним (back-end) сервером для обработки динамических данных которые потом отдаются «Nginx» как статические без участия внутреннего сервера. В качестве внутреннего сервера может применяться «Apache2» или, что и рассматривается в данной статье, «PHP-FPM».

Сервер «Nginx» поставляется в одноименном пакете «nginx» и его установка производится, например, командой в терминале

sudo apt-get install nginx nginx-extras

Установку же «PHP-FPM» можно произвести, например, командой

sudo apt-get install php5-cli php5-common php5-mysql php5-gd php5-fpm php5-cgi php5-fpm php-pear php5-mcrypt

Наряду с уязвимостями присущими ПО сервера, присутствуют также те, что обусловлены неосторожностью администратора сервера. Для их устранения следует соблюдать меры предосторожности:

1. Должно быть запрещено выполнение PHP-кода из открытых для записи директорий. Например, директории для загрузки аватаров, файлов или директории доступные также FTP-серверу, который позволяет произвести запись в них.
2. Следует следить за логами работы сервера, это позволяет выявить попытку взлома как можно раньше и минимизировать угрозу дальнейшего ущерба.
3. Необходимо обновлять ПО (в том числе «CMS» — системы управления содержимым сайтов), но не обязательно тогда когда выходят новые версии (они тоже могут содержать новые уязвимости), а, прежде всего, тогда, когда обновление связано с устранением серьезной уязвимости.
4. Обязательное наличие файлов для отката состояния сервера (в том числе, конфигурационных файлов).
5. Осторожное и осмотрительное следование подобным инструкциям (см. Don’t trust the tutorials: check your configuration!)

Настройка состоит из двух этапов — настройки «Nginx» и «PHP-FPM». Для начала необходимо остановить процессы (демоны) «Nginx» и «PHP-FPM», например, командами

sudo service nginx stop
sudo service php5-fpm stop

Прежде всего, следует открыть файл «/etc/php5/fpm/php.ini» для редактирования, например, командой

sudo nano /etc/php5/fpm/php.ini

после чего, найти строчку содержащую «cgi.fix_pathinfo», которая по-умолчанию выглядит так (закомментирована)

;cgi.fix_pathinfo = 1

и привести её к виду

cgi.fix_pathinfo = 0

Это призвано устранить опасность неправильно трактования (и возникающей уязвимости) запросов вида «/image.gif/foo.php» (см. Don’t trust the tutorials: check your configuration!, Nginx 0day exploit for nginx + fastcgi PHP).

Если планируется загрузка больших файлов (важно для ownCloud версий < 8, в новой версии 8 и выше имеется отдельный файл для этих настроек), то можно увеличить максимальный объем загружаемых данных, например, до 200 МБ

post_max_size = 200M

и ниже

upload_max_filesize = 200M

Затем сохранить изменения в файле.

Далее, необходимо отрыть для редактирования файл «/etc/php5/fpm/pool.d/www.conf», например, командой

sudo nano /etc/php5/fpm/pool.d/www.conf

найти строчку с параметров «security.limit_extensions» и привести её к виду

security.limit_extensions = .php .php3 .php4 .php5

Эта настройка ограничит выполнение файлов по расширению имени. В этом же файле найти строчку с параметром «listen» и привести её к виду

listen = /var/run/php5-fpm.sock

Это определит файл для связи «Nginx» с «PHP-FPM» (сокет). В целях безопасности запрещаем какой-попало программе писать в сокет (см. Обновление PHP 5.5.12 с устранением уязвимости в PHP-FPM ) путём указания прав доступа к сокету. Находим строчки с описанием параметров «listen.owner», «listen.group» и «listen.mode» (по-умолчанию они закомментированы) и приводим их к виду

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Следует сохранить изменения в файле и перезапустить «PHP-FPM», например, командой

sudo service php5-fpm restart

Можно убедится в том, что права доступа к сокету установлены верно:

ls -la /var/run/php5-fpm.sock

Права доступа должны быть «srw-rw—-», владелец «www-data» (группа «www-data»), например,

srw-rw---- 1 www-data www-data 0 May  2 16:36 /var/run/php5-fpm.sock

Основные настройки «Nginx» хранятся в файле «/etc/nginx/nginx.conf». Настройки базового сайта хранятся в файле «/etc/nginx/sites-available/default». Базовый конфигурационный файл сайта принято помещать в папку «/etc/nginx/sites-available/» и затем включить его путём добавления символической ссылки на этот файл в папке «/etc/nginx/sites-enabled/». Например, создадим конфигурационный файл для сайта с доменным именем (для примера выбрано «example.com») в названии для удобства

sudo touch /etc/nginx/sites-available/example.com
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

и откроем его для редактирования

sudo nano /etc/nginx/sites-available/example.com

Описывать конфигурацию сайта в одном файле не очень удобно, для увеличения читабельности конфигурационного файла и гибкости настройки можно воспользоваться директивой «include» позволяющей указать «Nginx», что следует загрузить другой конфигурационный файл и затем продолжить чтение текущего. Создадим в папке «/etc/nginx/» каталог «common», где будут хранится общие настройки для сайта, которые затем будут подгружаться из основного конфигурационного файла «/etc/nginx/sites-available/example.com» с помощью директивы «include»

sudo mkdir /etc/nginx/common

Некоторые запросы «Nginx» будет перенаправлять к «PHP-FPM», который в данном случае называется сервером выгрузки данных (upstream). Укажем как следует это делать. Создадим файл конфигурации с описанием серверов выгрузки данных

sudo touch /etc/nginx/common/upstream

и откроем его для редактирования

sudo nano /etc/nginx/common/upstream

и добавим в него строчки

upstream php-fpm
{
	# PHP5-FPM сервер
	server unix:/var/run/php5-fpm.sock;
}

где «php-fpm» – название для сервера выгрузки данных, для удобства.

Редактируем файл «/etc/nginx/sites-available/example.com». Добавляем строчку

include common/upstream;

для загрузки созданого выше конфигурационного файла. Как можно видеть – допускается указание относительного пути к файлу.

Далее описываем перенаправление от HTTP к HTTPS, если, конечно, это планируется. В таком случае необходимо наличие сертификатов для HTTPS (см. Сертификаты)

server
{
	listen 80;
	server_name example.com www.example.com;
	return 301  https://$server_name$request_uri;
}

иначе, можно опустить эти строчки.

Начинаем описывать конфигурацию сайта

server
{

Сетевой порт для приема соединений: 80 — обычный HTTP; 443 — HTTPS (см. выше)

	# Порты
	listen	80;
	listen	443	ssl;	# использовать шифрование для этого порта

Корневая директория сайта работающего на данном сервере

	root			/var/www;

Возможные имена индексных файлов (их «Nginx» пытается открыть если он получил запрос вида «example.com/», вместо явного «example.com/index.html»)

	index			index.php index.html index.htm;

Имя сервера – обычно доменное имя Вашего сервера

	server_name		example.com www.example.com;

Необходимо наличие сертификата «*.crt» или «*.pem» и приватного секретного ключа «*.key» (см. Сертификаты). Самоподписанный сертификат можно сгенерировать командой в терминале (см. man openssl, man req)

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout example.com_nginx.key -out example.com_nginx.crt

При этом программа запросит данные, среди них «commmon name» — следует указать доменное имя сервера. Можно использовать шаблон, если необходимо учесть домены нижнего уровня, например, «*example.com». Иначе могут возникнуть проблемы с некоторыми программами, например, «davfs2» (см man davfs2.conf).

Но можно пойти дальше и воспользоваться сервисом «StartSSL» где выдают бесплатные сертификаты для личного пользования (см. startssl.com и Получение и установка бесплатного SSL-сертификата), но сам приватный ключ (который нельзя никому показывать) лучше сгенерировать самому, например, так

openssl genrsa -out example_nginx.com.key 4096

затем сформировать файл запроса на подпись (при этом прийдётся вводить те же данные что и для генерации самоподписанного сертификата, но это не важно, т.к. сервис «StartSSL» проигнорирует все кроме публичного ключа)

 openssl req -new -sha256 -key example.com_nginx.key -out example.com.csr

открыть полученный файл текстовым редактором

 nano example.com.csr

и скопировать его содержимое в текстовое поле на сайте «StartSSL» для запроса сертификата (см. ссылки на подробные инструкции выше). Файл *.csr больше не нужен. Затем загружаем подписанный сертификат (например, файл называется signed.crt) и объединяем его с сертификатом того кто этот сертификат подписал

wget https://www.startssl.com/certs/sub.class1.server.ca.pem
cat signed.crt sub.class1.server.ca.pem > example.com_nginx.crt

Файл «signed.crt» можно удалить.

Копируем секретный ключ в системную папку и выставляем права доступа

sudo cp example.com_nginx.key /etc/ssl/private/
sudo chown www-data:www-data /etc/ssl/private/example.com_nginx.key
sudo chmod 400 /etc/ssl/private/example.com_nginx.key

И в соседнюю папку сам сертификат

sudo cp example.com_nginx.crt /etc/ssl/certs/

Для пущей надежности можно сгенерировать ключ Диффи-Хеллмана (тоже секретный файл который очень долго генерируется)

openssl dhparam -out example.com.dh.key 4096
sudo cp example.com_nginx.dh.key /etc/ssl/private/
chown www-data:www-data example.com_nginx.dh.key
chmod 400 example.com_nginx.dh.key

Продолжаем редактировать конфигурационные файлы.

Для удобства описываем настройки шифрования во внешнем файле «/etc/nginx/common/ssl»

sudo touch /etc/nginx/common/ssl

Редактируем файл «/etc/nginx/common/ssl»

sudo nano /etc/nginx/common/ssl

Файлы сертификатов для «HTTPS»

ssl_certificate /etc/ssl/certs/example.com_nginx.crt;		# сертификат (можно свободно распространять)
ssl_certificate_key /etc/ssl/private/example.com_nginx.key;	# приватный ключ (секретный файл - НИКОМУ НЕ ПОКАЗЫВАТЬ)

Дополнительные параметры требуемые для «HTTPS»

ssl_dhparam				/etc/ssl/private/example.com_nginx.dh.key;	# писать эту строчку только если файл есть
ssl_session_timeout			20m;	# время 20 минут
ssl_session_cache			shared:SSL:20m;	# размер кеша 20МБ
ssl_protocols				TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers		on;
ssl_ciphers				ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK;

На этом настройки «SSL» в «Nginx» завершены, сохраняем и закрываем файл. После завершения описания конфигурации (см. ниже) можно будет проверить надежность сервисом «SSLLabs»

Продолжаем редактировать файл «/etc/nginx/sites-available/example.com». Подгружаем созданный выше конфигурационный файл с описанием настроек SSL

	# Настройка шифрования SSL
	include common/ssl;

Указание максимального размера запроса – необходимо если сервер будет использоваться для загрузки больших файлов (например, для построения небольшого облачного хранилища на основе «ownCloud», эта строчка по сути делает то же что и указанные выше при настройке «PHP-FPM», только теперь для «Nginx»)

	client_max_body_size		200m;	# увеличение максимального объема файла для загрузки до 200МБ

Ещё одна опция

	# Buffers
	fastcgi_buffers 64 4K;

Опишем настройки безопасности в отдельном файле

sudo touch /etc/nginx/common/security
sudo nano /etc/nginx/common/security

И укажем в нём

add_header		X-Frame-Options		"SAMEORIGIN";
add_header		X-Content-Type-Options	"nosniff"; 

Сохраним и закроем файл, а затем подключим его строкой

	include common/security;

Для экономии трафика лучше включить сжатие (иногда со влючённым сжатием могут возникать проблемы, например, у «ownCloud», см. ниже). Опишем настройки сжатия в отдельном файле

sudo touch /etc/nginx/common/gzip
sudo nano /etc/nginx/common/gzip

и введём

gzip		on;
gzip_disable	"msie6";
gzip_comp_level	6;
gzip_min_length	1100;
gzip_buffers	16 8k;
gzip_proxied	any;
gzip_types	text/plain application/xml text/css text/js text/xml application/x-javascript text/javascript application/javascript application/json application/xml+rss; 

Следует сохранить, закрыть и затем подключить этот файл срочкой

	include common/gzip;

Далее указание директорий сайта и правил работы с ними с использованием директив «location». Данная директива может обрабатывать регулярные выражения «Perl» (см. Регулярные выражения (шаблоны))

Корневая директория

	location "/"
		{
		index index.php index.html index.htm;	# варианты индексных файлов если имя файла в запросе не задано
		try_files	$uri $uri/	=404;	# проверить есть ли файл из запроса на диске, иначе - вернуть ошибку 404
		}

К примеру, если хочется построить сайт на основе «WordPress», то можно описать корневую директорию так

	location "/"
	{
		index index.php index.html index.htm;
		try_files	$uri $uri/ /wordpress/;	# проверяем существования файла или папки, иначе перенаправляем к example.com/wordpress
		rewrite "^/$" "/wordpress/" redirect;	# перенаправляем запрос example.com/ к example.com/wordpress
	}

Соответственно сам сайт должен размещаться в каталоге «/var/www/wordpress/»

Некая директория «/var/www/restricted» доступная только авторизованным пользователям сервера. Создадим для неё файл конфигурации «/etc/nginx/common/locations/restricted»

sudo mkdir /etc/nginx/common/locations
sudo touch /etc/nginx/common/locations/restricted
sudo nano /etc/nginx/common/locations/restricted

со строчками

location ^~ "/restricted/"
{
	auth_basic				"Access to this forlder is restricted";
	auth_basic_user_file	htpasswd;
	autoindex on;
	allow all;
	try_files	$uri $uri/	=404;
}

Синтаксис «^~» указывает, что при совпадении регулярные выражения ниже проверятся не будут. Это необходимо, иначе возможно выполнение PHP-скриптов внутри этой папки без запроса пароля.

Этот конфигурационный файл подключим в «/etc/nginx/sites-available/example.com»

	# Restricted
	include common/locations/restricted;

Для более полной информации по настройке «Nginx» для «WordPress» следует обратиться к официальной документации (см. codex.wordpress.org/Nginx и wiki.nginx.org/WordPress)

Натройки «Wordpress», который, в данном примере, находится в папке «/var/www/wordpress» будут описаны в файле «/etc/nginx/common/locations/wordpress»

sudo touch /etc/nginx/common/locations/wordpress
sudo nano /etc/nginx/common/locations/wordpress

Ограничиваем доступ к секретной информации

location ~* "^/wordpress/(wp-config.php)((/.*)?)$"
{
	deny all;
	return 404;
}

Описываем директорию «example.com/wordpress»

location "/wordpress/"
{
	index index.php;
	try_files	$uri $uri/ @wordpress;	# попробовать прочитать файл или папку
	# если не существует, то перенаправить запрос к WordPress
}

где «@wordpress» – виртуальный путь, который используется для удобства и читабельности и описан ниже как

location @wordpress
{
	# Перенаправление 
	rewrite "^/wordpress/(.*)$" "/wordpress/index.php?q=$1" last;
}

Подключаем этот конфигурационный файл строчкой

include common/locations/wordpress;

в файле «/etc/nginx/sites-available/example.com».

Ограничение доступа к базе данных и настройкам «Dokuwiki» (см. Web Access Security), который, к примеру, находится в папке «/var/www/dokuwiki»

	location ~* "^/dokuwiki/(data|conf|bin|inc)((/.*)?)$"
	{
		deny all;	# запретить все для всех
		return 404;	# вернуть код ошибки
		index /dokuwiki/doku.php;	# индексный файл
	}

Ограничение доступа к файлам «MediaWiki» который, к примеру, находится в папке «/var/www/mediawiki»

location ~* "^/mediawiki/(cache|maintenance|includes|tests|serialized|extensions/Math/math|languages)((/.*)?)$"
{
	deny all;										# запретить все для всех
	return 404;										# вернуть код ошибки
}

Ограничение доступа к файлам «Simple Machines Forum», который, к примеру, находится в папке «/var/www/smf»

	location ~* "^/smf/(cache|Packages|attachments)((/.*)?)$"
	{
		deny all;	# запретить все для всех
		return 404;	# вернуть код ошибки
	}

Ограничение доступа к файлам «phpBB», который, к примеру, находится в папке «/var/www/phpbb»

	location ~* "^/phpbb/(images/avatars/upload|files|cache|includes|store|config.php|common.php)((/.*)?)$"
	{
		deny all;	# запретить все для всех
		return 404;	# вернуть код ошибки
	}

Настройки для сайта на основе «Drupal», который, к примеру, находится в папке «/var/www/drupal» и ограничение доступа к его файлам

	location "/drupal/"
	{
		index /drupal/index.php;	# индексный файл
		try_files $uri $uri/ =404;	# проверить есть ли файл из запроса на диске, иначе - вернуть ошибку
		error_page 404 /drupal/index.php;	# разрешить PHP сайту самому обрабатывать ошибку
	}

	location ~* "^/drupal/(.*\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)|(\..*|Entries.*|Repository|Root|Tag|Template))((/.*)?)$"
	{
		deny all;	# запретить все для всех
		error_page 404 /drupal/index.php;	# разрешить PHP сайту самому обрабатывать ошибку
		return 404;	# вернуть код ошибки
	}

Для наиболее полной информации следует обратится к официальному руководству «OwnCloud» (см. Nginx Configuration). К примеру, «ownCloud» находится в папке «/var/www/owncloud».

Создадим файл настроек для «ownCloud» и отредактируем его

sudo touch /etc/nginx/common/locations/owncloud
sudo nano /etc/nginx/common/locations/owncloud

Добавим строчки базовых настроек

location "/owncloud/"
{
	index index.php index.html index.htm;
	try_files	$uri $uri/ =404;
	error_page 403 /owncloud/core/templates/403.php;
	error_page 404 /owncloud/core/templates/404.php;
}

И также строчки для ограничения доступа

location ~* "^/owncloud/(data|config|db_structure\.xml|README)((/.*)?)$"
{
	deny all;
	error_page 403 /owncloud/core/templates/403.php;
	error_page 404 /owncloud/core/templates/404.php;
	return 404;
}

Иначе пользователь может загрузить php-скрипт в «/owncloud/data/files/user/» и выполнить его вызвав «example.com/owncloud/data/user/files/foo.php».

Подключаем этот конфигурационный файл строчкой

include common/locations/owncloud;

в файле «/etc/nginx/sites-available/example.com».

Начиная с версии «ownCloud» 8 появился отдельный файл для переопределения некоторых настроек «PHP-FPM» взамен указанных в «/etc/php5/fpm/php.ini». Открыть его можно командой

sudo nano /var/www/owncloud/.user.ini

и в нем найти строчки

upload_max_filesize=513M
post_max_size=513M

и поменять значения на требуемые.

Далее идет запрет доступа к определенным каталогам, подкаталогам и файлам сайта (или «CMS», на основе которых он построен). Опишем это в конфигурационном файле «/etc/nginx/common/locations/deny»

sudo touch /etc/nginx/common/locations/deny
sudo nano /etc/nginx/common/locations/deny

# Ограничение доступа к разным файлам и папкам которые часто используются для хранения важной информации
location ~* "/(engine|inc|data|conf|config|bin|info|install|module|profile|theme)((/.*)?)$"
{
	deny all;
	return 404;
}

# Запрет доступа к .htaccess и .htpasswd файлам
location ~* "/\.(htaccess|htpasswd)$"
{
	deny all;		# запретить все для всех
	return 404;		# вернуть код ошибки
}

Следует переписать все файлы «.htaccess» в директивы «Nginx». Найти эти файлы среди файлов сайта можно, например, командой

sudo find /var/www/ -name .htaccess

Подключаем этот конфигурационный файл строчкой

include common/locations/deny;

в файле «/etc/nginx/sites-available/example.com».

На этом описание директорий завершено

Далее идет перенаправление обработки php-скриптов внутреннему серверу «PHP-FPM»

Добавляем в файл «/etc/nginx/sites-available/example.com» строчки, к примеру

	# Направление PHP-скрипта для обработки FastCGI или PHP-FPM серверу
	location ~ "^(/index\.php|/info\.php|/(wordpress|owncloud)/.+?\.php)(/.*)?$"
	{
		# Решение проблемы с уязвимостью (см. http://forum.nginx.org/read.php?2,88845,page=3)
		# Не будет работать (ошибка 404) если файлы хранятся на другом сервере
		try_files	$1 $uri $uri/ $uri/index.php?q=$uri&$args $uri/index.php	=404;

где «$1» – отсылка к 1-й скобке регулярного выражения в директиве «location …» и т.д.

Создаём файл с описанием настроек перенаправления к «PHP-FPM»

sudo touch /etc/nginx/common/php-fpm
sudo nano /etc/nginx/common/php-fpm

И в него добавляем строчки

# Настройки порта или сокета PHP-FPM производятся в файле "/etc/php5/fpm/pool.d/www.conf"
fastcgi_pass	php-fpm;
# Порядок важен - строчка "include fastcgi_params" должна быть первой
include fastcgi_params;
fastcgi_split_path_info			^(.+?\.php)(/.*)?$;
# Вместо переменной "$document_root" можно указать адрес к корневому каталогу сервера и это желательно (см. http://wiki.nginx.org/Pitfalls)
fastcgi_param	SCRIPT_FILENAME		$document_root$fastcgi_script_name;
fastcgi_param	PATH_TRANSLATED		$document_root$fastcgi_script_name;
# См. http://trac.nginx.org/nginx/ticket/321
set		$path_info		$fastcgi_path_info;
fastcgi_param	PATH_INFO		$path_info;
# Указание дополнительных переменных окружения PHP
fastcgi_param	SERVER_ADMIN		admin@example.com;
fastcgi_param	SERVER_SIGNATURE	nginx/$nginx_version;
fastcgi_index	index.php;

Сохраняем и закрываем файл, подключаем его строчкой

	include common/php-fpm;

в файле «/etc/nginx/sites-available/example.com». Закрываем фигурные скобки директивы «location»

	}

Если на сервере используется система мониторинга «Nagios», то обеспечение работы её веб-интерфейса тоже можно возложить на «Nginx», точнее на связку «Nginx+PHP-FPM/FastCGIWrap». Установим дополнительное ПО «FastCGIWrap»

sudo apt-get install fcgiwrap

это позволит открывать «*.cgi» файлы.

Открываем описанный выше файл со списком серверов выгрузки данных (upstream)

sudo nano /etc/nginx/common/upstream

и добавим в него строчки

upstream fcgiwrap
{
	# FastCGIWrap сервер
	server unix:/var/run/fcgiwrap.socket;
}

Создаём файл с параметрами для «FastCGIWrap»

sudo touch /etc/nginx/common/fcgiwrap
sudo nano /etc/nginx/common/fcgiwrap

где укажем

# Отключаем сжатие для быстродействия
gzip			off;

# Стандартные параметры
include			fastcgi_params;

# Доп. параметры
fastcgi_param	SCRIPT_FILENAME		$document_root$fastcgi_script_name;
fastcgi_param	PATH_TRANSLATED		$document_root$fastcgi_script_name;
fastcgi_param	SERVER_ADMIN		admin@example.com;
fastcgi_param	SERVER_SIGNATURE	nginx/$nginx_version;

# Направление запроса к upstream-серверу
fastcgi_pass	fcgiwrap;

Создаём файл с описанием настроек для «Nagios»

sudo touch /etc/nginx/common/locations/nagios

и откроем его для редактирования

sudo nano /etc/nginx/common/locations/nagios

И укажем необдимые параметры. В «Ubuntu» «Nagios» устанавливается в разные папки, «PHP»-файлы веб-интерфейса обычно находятся в «/usr/share/nagios3/htdocs/»

location "/nagios/"
{
	index		index.php index.html;
	try_files	$uri $uri/	/nagios/index.php;
	alias		"/usr/share/nagios3/htdocs/";
}

«CSS»-файлы для веб-инрфейса находятся в «/etc/nagios3/stylesheets/»

location ^~ "/nagios/stylesheets/"
{
	alias		"/etc/nagios3/stylesheets/";
}
location ^~ "/nagios3/stylesheets/"
{
	alias		"/etc/nagios3/stylesheets/";
}

Картинки тоже прийдется описать отдельно

location ^~ "/nagios/images/"
{
	alias		"/usr/share/nagios3/htdocs/images/";
}
location ^~ "/nagios3/images/"
{
	alias		"/usr/share/nagios3/htdocs/images/";
}

«JS»-скрипты

location ^~ "/nagios/js/"
{
	alias		"/usr/share/nagios3/htdocs/js/";
}
location ^~ "/nagios3/js/"
{
	alias		"/usr/share/nagios3/htdocs/js/";
}

Перенаправление «PHP»-скриптов уже было описано выше, но тут требуется сделать дополнительные настройки, опишем все заново

location ~ "^/nagios/(.+?\.php)(/.*)?$"
{
	# Папки nagios в /var/www нет, так что требуется сделать внутренне перенаправление в папку /usr/share/nagios3/htdocs/
	root		"/usr/share/nagios3/htdocs/";
	# Проверка существования файла на диске
	# $1 - отсылка к первой скобке регулярного выражения в location
	# Если ничего не найдено, то открыть /nagios/index.php (можно поменять на =404)
	try_files	$1 $uri $uri/	/nagios/index.php;
	# Собственно перенаправление
	rewrite		"^/nagios/(.+?\.php)(/.*)?$"	/$1$2		break;
	# Авторизация
	auth_basic	"Authorization required to access Nagios";
	auth_basic_user_file	htpasswd;
	
	# Перенаправление запросов к PHP-FPM
	include		common/php-fpm;
}

Подобным образом описываем перенаправление запросов к «CGI»-сприптам серверу «FastCGIWarp»

location ~* ^/cgi-bin/nagios3/(.+?\.cgi)$
{
	root		"/usr/lib/cgi-bin/nagios3";
	try_files	$1 $uri $uri/	=404;
	rewrite		"^/cgi-bin/nagios3/(.+?\.cgi)$"	/$1		break;

	auth_basic	"Authorization required to access Nagios";
	auth_basic_user_file	htpasswd;

	# Передаём скрипту параметры аутентификации
	fastcgi_param	AUTH_USER	$remote_user;
	fastcgi_param	REMOTE_USER	$remote_user;
	
	include		common/fcgiwrap;
}

Сохраняем и закрываем файл.

А в файле «/etc/nginx/sites-available/example.com» дописываем

	# Nagios
	include common/locations/nagios;

Выше были описаны параметры аутентификации для доступа к «Nagios», однако сам файл с пользователем и хеш-суммой от пароля хранится в неизвестном для «Nginx» файле «/etc/nagios3/htpasswd.users». Просто перенесём эти настройки в известный для «Nginx» файл «/etc/nginx/htpasswd», например, командой выполненной от корневого пользователя «root»

cat /etc/nagios3/htpasswd.users >> /etc/nginx/htpasswd

хотя, конечно, лучше это сделать вручную.

Сайт работает значительно лучше когда часть контента сохранена на стороне клиента с прошлого посещения сайта. Не все файлы можно кешировать. Поэтому описание кеширования производится в самом конце (т.е. эти настройки будут иметь наименьший приоритет и есть шанс что это не повлияет на правильную работу сайта). Создаём файл с параметрами для кеширования

sudo touch /etc/nginx/common/cache
sudo nano /etc/nginx/common/cache

где укажем

location ~* ".+\.(?:ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|css|swf|js|atom|jpe?g|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$"
	{
		access_log	off;
		log_not_found	off;
		expires		max;
	}

и указываем считывать этот файл строчкой в «/etc/nginx/sites-available/example.com»

	include common/cache;

Закрываем фигурные скобки директивы «server» в «/etc/nginx/sites-available/example.com»

}

На этом правка файла «/etc/nginx/sites-available/example.com» завершена. Убедитесь в том, что все фигурные скобки «{ }» закрыты корректно и части файла верно вложены друг в друга («location» внутри «server» и т.п.).

Сохраняем все изменённые файлы.

Теперь можно перезапустить демоны

sudo service nginx restart
sudo service php5-fpm restart

• Обсуждение статьи на форуме forum.ubuntu.ru
• Сравнение быстродействия и нагрузочной способности веб-серверов Nginx vs Cherokee vs Apache vs Lighttpd
• Рекомендации по безопасности при развертывании веб-сервера на основе «Nginx» и «PHP-FPM» Don’t trust the tutorials: check your configuration!
• Настройка Nginx с поддержкой PHP-FPM в Ubuntu 12.04
• Синтаксис конфигурации «Nginx» HttpCoreModule
• Пример настройки связки «Nginx + PHP-FastCGI» PHPFcgiExample
• Рекомендации по написанию удачной конфигурации для «Nginx» Pitfalls
• Работа с сертификатами в «Ubuntu» Сертификаты
• Рекомендации по обеспечению безопасности при работе с сайтом на основе «Dokuwiki» Web Access Security
• Рекомендации по обеспечению безопасности при настройке облачного хранилища на основе «ownCloud» Webserver Notes