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

В данной статье рассматривается установка и настройка связки Nginx и 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

Настройка PHP-FPM

Прежде всего, следует открыть файл «/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

Основные настройки «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

При редактировании данного файла необходимо учитывать синтаксис конфигурации «Nginx» (см. HttpCoreModule), готовые советы по настройке связки «Nginx + PHP-FPM» (см. PHPFcgiExample) и следовать некоторым правилам/рекомендация для достижения эффективной работы сервера (см. Pitfalls).

Описывать конфигурацию сайта в одном файле не очень удобно, для увеличения читабельности конфигурационного файла и гибкости настройки можно воспользоваться директивой «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» (см. location)

Блокировать доступ к файлам и подпапкам обычно следует посредством регулярных выражений

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

	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/»

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

	include common/locations/*.inc;

которая укажет «Nginx», что нужно подключить все файлы в директории «/etc/common/locations/» которые соответствуют шаблону «*.inc», таким образом, если один из файлов нужно будет временно отключить, то его можно просто переименовать убрав расширение в имени. Создадим директорию где будут хранится эти файлы

sudo mkdir /etc/nginx/common/locations

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

sudo touch /etc/nginx/common/locations/restricted.inc
sudo nano /etc/nginx/common/locations/restricted.inc

со строчками

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

Синтаксис «^~» указывает, что при совпадении здесь директивы «location» ниже проверяться не будут.

Этот конфигурационный файл подключится автоматически, за счёт шаблона (см. выше).

Wordpress

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

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

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

Указываем виртуальную директорию (используется для удобства и читабельности) в которую будут перенаправляться запросы при необходимости

location @wordpress
{
	rewrite "^/wordpress/(.*)$" "/wordpress/index.php?q=$1" last;
}

Аналогично примеру выше предотвращаем обработку остальных директив «location»

location ^~ "/wordpress/"
{
	root		"/var/www";
	index		index.php;
	try_files	$uri $uri/ @wordpress;	# проверить существует ли файл, иначе направить в виртуальную директорию
	
	# Ограничение доступа к секретному файлу
	location ~* "^/wordpress/wp-config.php(/.*)?$"
	{
		deny all;
		return 404;
	}
	# Ни в коем случае не выполнять файлы php в папках куда их может кто-то загрузить
	# Проще всего просто заблокировать любые операции с такими файлами регулярным выражением
	location ~* "/(uploads|files)/.*\.php.?(/.*)?$"
	{
		deny all;
		return 404;
	}
	# Перенаправление php-файлов к серверу «PHP-FPM» см. ниже по статье
	location ~ "^(/wordpress/.+?\.php)(/.*)?$"
	{
		# Проверяем существование файлов, пробуем исправить если нет, иначе выдаём ошибку
		# $1 указывает на первую скобку в регулярном выражении выше - собственно адрес запрошенного php файла
		try_files	$1 $uri $uri/ $uri/index.php	=404;
		include common/php-fpm;
	}
	# Другие настройки, см. ниже по статье
	include common/deny;
	include common/cache;
}

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

ownCloud

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

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

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

Многое аналогично примеру для «Wordpress»

location ^~ "/owncloud/"
{
	root		"/var/www"; 
	index index.php index.html index.htm;
	try_files	$uri $uri/ =404;
	# ownCloud предоставляет свои красивые страницы для ошибок 404 и 403 - используем их
	error_page 403 /owncloud/core/templates/403.php;
	error_page 404 /owncloud/core/templates/404.php;
 
	# Отключаем сжатие - оно создаёт проблемы для клиента синхронизации ownCloud
	gzip			off;
	# Переопределяем глобальную настройку описанную в главном файле
	# увеличиваем максимальный размер загружаемых файлов
	client_max_body_size	16G;
	# Запрещаем читать секретные файлы
	location ~* "^/owncloud/(\.user\.ini|data|config|db_structure\.xml|README)(/.*)?$"
	{
		deny all;
		return 404;
	}
	location ~ "^(/owncloud/.+?\.php)(/.*)?$"
	{
		try_files	$1 $uri $uri/ $uri/index.php	=404;
		include common/php-fpm;
	}
	include common/deny;
	include common/cache;
}

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

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

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

upload_max_filesize=513M
post_max_size=513M

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

Базовые ограничения

Выше была написана строчка для подключение файла «/etc/nginx/common/deny»

include common/deny;

рассмотрим его содержание. В нём идет запрет доступа к некоторым стандартным файлам. Создадим этот файл

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

с содержанием

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

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

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

sudo find /var/www/ -name .htaccess

Вызов PHP-FPM

В примерах выше использовался файл «/etc/nginx/common/php-fpm» — в нём идет перенаправление обработки php-скриптов внутреннему серверу «PHP-FPM»

В файле «php.ini» должно быть установлено «cgi.fix_pathinfo = 0;» Также, в файле »/etc/php5/fpm/pool.d/www.conf» должно присутствовать ограничение на разширение имени исполняемых скриптов - «security.limit_extensions = .php .php3 .php4 .php5»

Создаём этот файл

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;
# Additional variables
fastcgi_param	SERVER_ADMIN		email@example.com;
fastcgi_param	SERVER_SIGNATURE	nginx/$nginx_version;
fastcgi_index	index.php;

Кеширование

Выше, в примерах, был упомянут файл «/etc/nginx/common/cache»

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

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;
	}

Окончание

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

}

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

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

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

sudo service nginx restart
sudo service php5-fpm restart

Проверка

Проверить свой сайт можно создав файл «info.php» с содержанием

<?php
phpinfo();
?>

затем скопировав его, например, в «/var/www/wordpress/wp-content/uploads/», затем открыв адрес в браузере «http://example.com/wordpress/wp-content/uploads/info.php», если он выполнится вместо того чтобы просто сохранится — то что-то настроено неправильно, в этой директории php файлы выполняться не должны ни в коем случае (она доступна для загрузки)

Проверить свой сайт на скорость и прочее можно тут:

Ссылки