apache php admin value
Безопасная настройка web-сервера (nginx+apache2-mpm-itk)
В данной статье я попытаюсь составить наиболее полное описание безопасной настройки web-сервера (nginx+apache), под управлением ОС Debian. А также eaccelerator для более продуктивной работы сервера.
1. Создаем пользователей, файловая система.
Для начала я бы порекомендовал отделить под сайты отдельную директорию на сервере (вместо дефолтных, а-ля /home/user/www/). Создадим к примеру директорию sites, в корне. Выполним команды:
Тем самым мы создали директорию sites с правами доступа 755.
Далее создадим пользователей в системе. (для простоты мы будем настраивать сервер на 2-х пользователей.)
(Добавляем группу для первого юзера)
(Добавляем первого юзера, устанавливаем ему домашнюю директорию, добавляем во вновь созданную группу, и убираем ему оболочку (/bin/bash))
passwd user1
(Правим права доступа к домашней директории)
(создаем веб-директорию, устанавливаем права доступа)
(создаем директорию для временных файлов, устанавливаем права доступа)
(Рекурсивно меняем владельца домашней директории и всех вложенных)
2. Устанавливаем и настраиваем apache2-mpm-itk
Стандартный apache2 работает от одного юзера, что естественно критично снижает уровень безопасности, потому как apache грубо говоря имеет доступ ко всем php файлам всех сайтов. Таким образом хакер, взломавший один сайт на сервере и имеющий web-shell при стандартных условиях может прочитать файлы остальных сайтов.
Это нас естественно не устраивает, поэтому мы будем устанавливать модуль apache2-mpm-itk, что существенно повысит уровень безопасности нашего сервера.
Как гласит официальная документация:
apache2-mpm-itk (just mpm-itk for short) is an MPM (Multi-Processing Module) for the Apache web server. mpm-itk allows you to run each of your vhost under a separate uid and gid — in short, the scripts and configuration files for one vhost no longer have to be readable for all the other vhosts.
Поставим модуль из репозиториев:
Установка стандартна, расписывать не буду. Подробнее остановлюсь на конфигурации.
Вот пример конфигурационного файла /etc/apache2/sites-available/user1
ServerAlias user1.ru *.user1.ru
CustomLog /sites/site1/access_log combined
# Важный момент, указываем, что апач будет работать от пользователя www—data и нашей группы site1
# open_basedirдля домашней директории пользователя, можно добавить несколько директорий при необходимости, директории разделяются двоеточием «:»
php_admin_value open_basedir «/ sites/user1/:.»
# Включаем сейф-мод, я сделал это в каждом конфиге сайта для удобства отключения при необходимости.
php_admin_value safe_mode «on»
# Определяем нашу временную директорию как основную, вместо /tmp и устанавливаем её директорией для хранения сессий.
php_admin_value upload_tmp_dir «/ sites/user1/tmp»
php_admin_value session.save_path «/ sites/user1/tmp»
Сохраняем конфиг, теперь активируем конфиг командой:
Далее перечитываем конфиги
2.1(Пояснения)
AssignUserId www-data site1
Почему же мы указываем одного пользователя и разные группы для всех?
Ответ связан с предыдущим пунктом. Рассмотрим пример:
Имеется два сайта с такими конфигами:
У сайта site1 есть файл
-rwxr-x— 1 site1 site1 397 Dec 1 23:15 index.php
Обратите внимание на юзера и группу владельца файла.
Таким образом, веб-сервер, работающий от единого пользователя и разных групп для каждого сайта обеспечивает безопасность между пользователями.
Поясню – права доступа выставлены так, что файл сможет прочитать только лишь владелец файла и участники группы, в это число входит site1 и веб-сервер запущенный от имени www-data, т.к. он работает от группы site1. Т.е. site1 может прочитать файл, записать и выполнить, веб-сервер может только прочитать и выполнить, а site2 и веб-сервер запущенный от имени группы site2 уже не сможет прочесть важные файлы соседнего сайта, как то конфигурационный файл и т.п.
Установка nginx
Устанавливаем nginx из репозиториев (в репозиториях зачастую устаревшие версии, при желании можно установить из исходников.)
Далее нам нужно поменять порт для apache2, для этого в файле /etc/apache2/ports.conf вносим изменения:
Т.е. заставляем apache работать на порту 8080
Далее нам нужно прописать изменения в конфигурационные файлы наших проектов. Вот пример конфигурации файла /etc/apache2/sites-available/site
ServerName www. site.ru
ServerAlias site.ru *. site.ru
DocumentRoot «/sites/ site /public_html/www/»
ErrorLog /sites/site/error_log
CustomLog /sites/site/access_log combined
AssignUserId www-data site
php_admin_value open_basedir «/sites/site /:.»
php_admin_value upload_tmp_dir «/sites/site /tmp»
php_admin_value session.save_path «/sites/site /tmp»
И так каждый файл всех ваших проектов.
Далее нужно изменить конфигурацию nginx.
Пример конфигурации:
listen 000.000.000.000:80;
# вместо 000.000.000.000 ip адрес вашего сервера
server_name site.ru;
* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf|js)$ <
root /sites/site/public_html/www;
access_log /sites/site/access_log;
>
>
Данную конструкцию повторить для каждого проекта отдельно.
Таким образом мы настроили nginx фронтэндом, который будет обрабатывать статику (jpg,jpeg,gif и т.д.).
Теперь перезагружаем apache и nginx.
/etc/init.d/apache2 restart
/etc/init.d/nginx restart
ВАЖНО!
При установке nginx поверх apache2-mpm-itk я столкнулся с проблемой – т.к. апач работал от разных юзеров (точнее от разных групп) для каждого сайта, а nginx от одного юзера, то файлы статики были недоступны для nginx, не хватало прав, вследствии чего ошибка 403.
Решение:
Т.к. официального функционала у nginx с работой от разных юзеров еще нет, то пришлось добавить юзера www-data, от которого он работает в группы юзеров наших проектов.
Установка eAccelerator
Установка проста, описывать особо нечего.
cd /tmp
wget httр://bart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2
tar xvfj eaccelerator-0.9.5.3.tar.bz2
cd eaccelerator-0.9.5.3
phpize
./configure
make
make install
Далее правим конфиг акселератора /etc/php5/conf.d/eaccelerator.ini
Вот пример конфигурации:
extension=«eaccelerator.so»
eaccelerator.shm_size=«32»
eaccelerator.cache_dir=»/var/cache/eaccelerator»
eaccelerator.enable=«1»
eaccelerator.optimizer=«1»
eaccelerator.check_mtime=«1»
eaccelerator.debug=«0»
eaccelerator.filter=»»
eaccelerator.shm_max=«0»
eaccelerator.shm_ttl=«0»
eaccelerator.shm_prune_period=«0»
eaccelerator.shm_only=«0»
eaccelerator.compress=«1»
eaccelerator.compress_level=«9»
Далее создадим директорию для кэша:
ВАЖНО!
При установке eaccelerator также возникла проблема – вылетали ошибки:
PHP Warning: Unknown: open_basedir restriction in effect. File() is not within the allowed path(s): (blablabla) in Unknown on line 0
Как оказалось eaccelerator некорректно работает с open_basedir.
Решение:
При установке конфигурировать исходник с параметром —without-eaccelerator-use-inode
Расширенная настройка web сервера (Apache2 + Nginx)
В этом руководстве мы рассмотрим процедуру установки и настройки работы двух web-серверов с целью использования преимуществ каждого из них, руководство подразумевает как отдельное настраивание, так и взаимное.
В этой статье будет идти речь о настройке сервера с использованием: Apache2, Nginx, ngx_pagespeed, PHP, PHP-FPM, MariaDB и MemCached.
Nginx
HTTP-сервер и обратный прокси-сервер, почтовый прокси-сервер, а также TCP/UDP прокси-сервер общего назначения.
Установка
Установите пакеты, необходимые для подключения apt-репозитория:
Для подключения apt-репозитория для стабильной версии nginx, выполните следующую команду:
Теперь нужно импортировать официальный ключ, используемый apt для проверки подлинности пакетов:
Проверьте, верный ли ключ был импортирован:
Вывод команды должен содержать полный отпечаток ключа 573B FD6B 3D8F BC64 1079 A6AB ABF5 BD82 7BD9 BF62 :
Чтобы установить nginx, выполните следующие команды:
Настройка
Проверяем, что пользователь nginx user www-data :
Проверим работу веб-сервера. Открываем браузер и вводим в адресной строке http://«IP-адрес сервера».
В итоге мы должны увидеть заголовок «Welcome to nginx!».
PHP-FPM
FastCGI — протоколу взаимодействия веб-сервера с программами. FPM расшифровывается как Fastcgi Process Manager.
Установка
Настройка
Разрешаем автозапуск php-fpm и запускаем его:
ngx_pagespeed
ngx_pagespeed (или просто pagespeed) – это модуль Nginx, предназначенный для автоматической оптимизации работы сайта путём сокращения времени загрузки сайта в браузере. Дополнительную информацию о модуле можно найти на официальном сайте.
Установка
Устанавливаем необходимые пакеты:
Настройка
Создаем и переходим в папку, в которой будем собирать ngx_pagespeed :
Узнаем текущую версию nginx:
Скачиваем необходимую версию:
В нашем случае это nginx 1.18
Скачиваем репозиторий с ngx_pagespeed :
Скачиваем папку psol:
Собираем файл ngx_pagespeed.so :
Копируем файл ngx_pagespeed.so :
Apache2
Установка
Устанавливаем apache и модуль для php:
Настройка
Заходим в настройки портов:
И редактируем следующее:
мы настроили прослушивание на порту 8080, так как на 80 уже работает NGINX. Также мы закомментировали прослушивание по 443, так как и он будет слушаться NGINX.
по умолчанию, apache2 может быть установлен с модулем мультипроцессовой обработки mpm_event. Данный модуль не поддерживает php 7 и выше.
Разрешаем модуль мультипроцессовой обработки mpm_prefork :
Разрешаем модуль php :
Разрешаем модуль rewrite :
Разрешаем модуль setenvif :
Разрешаем автозапуск и запускаем службу:
Открываем браузер и вводим в адресную строку http://«IP-адрес сервера»:8080. Мы должны увидеть привычную страницу.
в разделе Server API мы должны увидеть Apache.
Apache2 Real IP
Запросы на apache приходят от NGINX, и они воспринимаются первым как от IP-адреса 127.0.0.1. На практике, это может привести к проблемам, так как некоторым сайтам необходимы реальные адреса посетителей. Для решения проблемы будем использовать модуль remoteip.
Установка
Создаем конфигурационный файл со следующим содержимым:
Настройка
Для проверки настройки открываем браузер и вводим в адресную строку http://«IP-адрес сервера», где откроется наша страница phpinfo.
В разделе Apache Environment мы должны увидеть внешний адрес компьютера, с которого обращаемся к серверу в опции REMOTE_ADDR.
Устанавливаем необходимые библиотеки для PHP и PHP-FPM:
Mysql (Mariadb)
Установка
Настройка
Разрешаем автозапуск и запускаем СУБД:
Зададим пароль для пользователя root:
Создаем и настраиваем пользователя:
Настраиваем возможность входа в adminer.php
Memcached
Memcached — Программное обеспечение, реализующее сервис кэширования данных в оперативной памяти на основе хеш-таблицы.
Установка
Для начала, выполняем установку пакетов:
Настройка
После разрешаем автозапуск и запускаем сервис кэширования:
Для проверки, что модуль memcached появился в PHP, открываем наш сайт в браузере — в phpinfo должна появиться новая секция Memcached.
Доступы и настройка находится в файле memcached.conf :
Настройка пользователя
Добавляем пользователя в группу www-data :
Даем права sudo пользователю:
Настройка сайта
Создаем каталог для сайта
Задаем права на папки:
Создаем индексный файл:
Настройка сайта
Nginx http
Все запросы будут переводится на локальный сервер по порту 8080, на котором работает apache, кроме обращений к статическим файлам (jpg, png, css и так далее).
apache2
Проверяем
Проверяем корректность настроек конфигурационных файлов:
https (Существующий Сертификат)
Все запросы будут переводится на локальный сервер по порту 8080, на котором работает apache, кроме обращений к статическим файлам (jpg, png, css и так далее).
Apache2
Проверяем
Проверяем корректность настроек конфигурационных файлов:
ngx_pagespeed on
Загрузка динамического модуля PageSpeed
Откройте файл nginx.conf :
Добавляем в начало:
Настраивается PageSpeed в http контексте, поэтому поместите эти директивы в новый файл конфигурации под названием example.com.conf в файле /etc/nginx/conf.d каталог.
Создаем папку для хранения кэша:
Проверяем конфигурацию Nginx и применяем настройки:
И снова о… LAMP и базово защищённый мини-хостинг своими руками
Увидев в очередной раз презренный посыл в Google в ответ на вопрос о том, как развернуть собственную LAMP’у, решил написать данный пост. Чтобы хоть как-то разбавить тонны радостных отчётов об успешной установке из блогов, суть которых сводится к одной команде aptitude install blah-blah.
Нет, ну конечно понятно, PHP самый надёжный язык, а все движки сайтов, на нём написанные, являются живым воплощением непробиваемой защиты от взлома. Тогда да — aptitude install apache2 — и будет вам счастье. Не забудьте оставить phpmyadmin по дефолтному адресу, да поставьте какое-нибудь дырявое FTP решето.
Вообще, как оказалось, многие даже не в курсе, что взломав сайт и получив возможность исполнять свой PHP код, злоумышленник на системе с дефотными настройками сможет как минимум прочитать в вашей системе почти что угодно. Оно и понятно — работая с Linux привыкаешь как-то, что по дефолту безопасность находится на вполне достаточном уровне. А тут такая дыра…
В общем — в этой статье в очередной раз описывается банальщина на тему как развернуть LAMP и дать доступ внешним пользователям к файлам и базам ваших сайтов. Т.е. как быстро сделать мини-хостинг своими руками. Однако, в отличие от, хостинг у нас будет хотя бы базово защищённым.
Те, кому тема веб-серверов надоела, возможно смогут найти в статье интересные приёмы многопользовательского ограниченного доступа к серверу по SFTP.
И нет, это не ещё одна статья с описанием установки Linux и выполнением aptitude install apache2. Скорее наоборот: в этой статье я хотел показать фатальную недостаточность данных манипуляций и мягко говоря некомпетентность тех, кто их тиражирует в интернете.
Установка
Всё будет описано на примере Debian.
Для начала нужно установить всё необходимое (кстати, для Ubuntu phpMyAdmin лучше ставить из PPA):
При установке phpMyAdmin генерируем произвольный пароль для подключения к БД, в остальном всё очевидно.
Как это будет работать
Все пользователи, которым нужно получить доступ к файлам на сервере, будут иметь локальную учётную запись с возможностью захода только по SFTP и только в папку с принадлежащими им сайтами. При этом будет поддерживаться авторизация как по паролю, так и по ключу. Интерактивный же вход по SSH будет невозможен, хотя если очень надо — его можно будет включить, причём тоже с закрытым доступом к системным файлам.
Никакого FTP не будет, хотя его и возможно легко прикрутить. SFTP надёжней (шифрование, возможность авторизации по ключу), а FTP в данном случае элементарно избыточен и является достаточно большой потенциальной дырой в безопасности.
Каждый сайт будет принадлежать некоему ‘аккаунту’, т.е. под одним ‘аккаунтом’ может быть несколько сайтов. К этим ‘аккаунтам’ привязываются SFTP пользователи, причём никто не мешает к одному ‘аккаунту’ привязать несколько пользователей. Дальше, внутри ‘аккаунта’, всё можно будет разрулить стандартными механизмами прав доступа в Linux.
Пользователи и пароли от БД никак не будут зависеть от системных пользователей, управление БД будет происходить через стандартный phpMyAdmin.
Кроме всего прочего сайты, работающие на вашем сервере, не смогут вылезти за пределы своего рабочего каталога и прочитать или изменить какие-нибудь данные, к ним не относящиеся.
Немного подробней про структуру
Все сайты будут лежать в каталогах вида /var/www/ACCOUNT/sites/SITENAME. ACCOUNT тут не обязательно означает какого-то системного пользователя, просто некий произвольный идентификатор.
У системных пользователей, которые будут подключаться по SFTP для редактирования сайтов, в качестве домашней директории будет установлено /var/www/ACCOUNT/home/USERNAME. Соответственно в зависимости от значения ACCOUNT тот или иной пользователь будет иметь доступ к тому или иному аккаунту. Создание каталога home внутри аккаунта нужно для того, чтобы иметь возможность авторизовывать SFTP пользователей по ключам.
Для всех пользователей SFTP основной группой будет установлена www-data (дефолтная группа Apache2 в deb-based). Кроме этого, все создаваемые как пользователем по SFTP, так и Apache, файлы по умолчанию будут иметь права 0660, а каталоги — 0770. Поскольку у Apache и SFTP пользователя одна и та же группа, то по-умолчанию в любой новый файл или каталог сможет писать как пользователь, так и веб-сервер, вне зависимости от того, кто его создал. Что обычно и требуется.
Базы же будут использовать свой, полностью отдельный механизм авторизации и контроля доступа. Тут всё крайне просто: создаём пользователей и даём им права только на конкретные базы. Поэтому к этому вопросу возвращаться больше не будем.
Создание ‘аккаунтов’ и системных пользователей
Размещение сайта на сервере стоит начать с подготовки места под него и создания пользователя для работы с ним. Как описано выше, для сайта нам нужна папка вида /var/www/ACCOUNT/. В качестве ACCOUNT задействуем для примера 42. Просто 42. Ок, создаём папку:
Кроме этого внутри аккаунта нам нужны каталоги home/USERNAME и sites. Создаём их:
Для будущей настройки SFTP сразу стоит убедиться, что и /var/www/42/sites, и все нижестоящие папки принадлежат root:root и ни у кого, кроме root, нет прав на запись в них.
Дальше создаём пользователя. Чтобы не путаться с обычными, полноценными пользователями сервера, SFTP пользователей можно перенести в диапазон UID от 901 до 999. Если вам это не надо — уберите соотв. параметры. Если вы хотите авторизовываться только по ключу, то добавьте параметр —disabled-password. В итоге команда такая:
Установка шелла в /bin/false гарантирует нам, что пользователь никак не сможет интерактивно зайти в систему.
Настройка SFTP
Настройка SFTP будет заключаться в том, что для всех членов группы www-data мы сделаем так, чтобы при заходе по SFTP они попадали сразу в папку sites ‘аккаунта’, в котором находится их HOME директория, без возможности выбраться выше по дереву каталогов.
Делается это просто. Достаточно в конец файла /etc/ssh/sshd_config дописать код
И ткнуть sshd для обновления конфигурации:
Этот кусочек кода для всех пользователей из группы www-data, во-первых, отключает TCP и X11 форвадинг (им незачем иметь доступ в вашу локалку). Во-вторых делает для них при заходе chroot в sites папку их ‘аккаунта’ (именно для этого нам нужно было делать sites папки доступными для записи только для root — иначе не работает chroot). Ну и в третьих меняет им обработчик SFTP на встроенный (которому не нужно полноценное окружение с шеллом и прочим), попутно говоря ему создавать все файлы и папки со значение umask в 007. То есть права по умолчанию на новые файлы будут 0660, а на каталоги — 0770.
Настройка Apache и phpMyAdmin
Как-либо специфично настраивать Apache для обеспечения базовой работы не нужно. Единственное, что в Debian пакет PHP5 идёт с интегрированным патчем Suhosin, повышающим безопасность. Он будет необходим при настройке конфигов сайта, хотя вполне можно обойтись и без него.
А так в целом для Apache нужно лишь изменить umask для создаваемых файлов и папок на такой же, который мы использовали для настройки SFTP. Делается это путём добавления в /etc/apache2/envvars строчек:
Для минимальной настройки phpMyAdmin нужно лишь поменять адрес, по которому он будет доступен, с неприлично бестолкового your.site/phpmyadmin на что-то другое. Для этого в файле /etc/phpmyadmin/apache.conf нужно заменить строчку
Не забывайте перезапускать Apache:
Добавление сайтов
Для добавления сайтов на ваш хостинг нужно сделать две вещи — во-первых, разместить файлы сайта с нужными правами на вашем сервере, а во-вторых создать конфиг апача для сайта. Кроме этого чаще всего потребуется создать БД и настроить права доступа к ней — но это тривиальная операция, поэтому рассматривать её не будем.
Для размещения файлов нужно из-под root создать каталог сайта в папке нужного ‘аккаунта’. Например:
Дальше выставить желаемые права. Как минимум у SFTP пользователя, который будет работать с этим каталогом, должны быть права на запись. К примеру, можно сделать так:
Ок, теперь пользователь может зайти и залить файлы сайта. Осталось настроить апач. Для этого, как всегда, создаём файл настроек в директории /etc/apache2/sites-available. Содержимое этого файла для сайта deep-thought.net с данными в каталоге /var/www/42/sites/deep-thought.net должно быть примерно таким:
Немного про temp: поскольку мы запрещаем PHP обращаться к файлам вне корневой директории сайта, то нам нужно указать каталог для сохранения временных файлов (файлов, загружаемых пользователями сайта на сервер через стандартный механизм загрузки из HTML формы) и файлов сессий внутри корня сайта. Каталог этот нужно, естественно, предварительно создать. Кроме этого лучше бы явно закрыть к нему доступ из интернета, что и сделано во втором блоке Directory. Иначе кто-нибудь может невзначай получить сессии ваших пользователей.
Если на сервере не установлен Suhosin, то вместо suhosin.executor.func.blacklist можно использовать стандартную опцию PHP disable_functions. Правда её нужно указывать в php.ini, т.е. она будет действовать на все сайты на вашем сервере.
Кроме этого в приведённых выше настройках не отключена функция eval. Увы, многим сайтам она зачем-то нужна, хотя всё же лучше её отключать. Обратите внимание на опции suhosin.executor.disable_eval и suhosin.executor.disable_emodifier всё того же Suhosin.
После того, как вы подготовите нужный вам конфиг, просто активируйте сайт:
И не забудьте пнуть апач:
Ну и конечно нужно залить файлы и базу данных сайта на сервер — без них вряд ли что-то заработает.
Тюнинг SSH: ключи и интерактивный вход
Для доступа пользователей SFTP по ключам нужно сделать всё тоже, что делается всегда: внутри HOME каталога создать директорию .ssh/, в ней файлик authorized_keys, в который прописать публичный ключи для пользователя.
Кроме этого, можно некоторым пользователям открыть интерактивный доступ на сервер. Для этого нужно, во-первых, подготовить в корневой папке соответствующего ‘аккаунта’ нужное chroot окружение, как минимум с интерпретатором и всеми необходимыми виртуальными ФС. Делается это стандартно и ничего сложно в этом нет.
Дальше можно создать дополнительную группу для интерактивного входа. Например, ssh-interactive:
Добавить в неё нужных пользователей, попутно сменив им SHELL на полноценный bash:
И прописать для этой группы специфические настройки в sshd_config. Для этого нужно модифицировать директиву Match, относящейся к www-data, дописав к ней !ssh-interactive, дабы она не распространялась на пользователей этой группы:
И после неё добавить ещё одну директиву Match:
Проблема только в том, что для членов группы ssh-interactive umask больше не будет выставляться в 007. Исправить это можно дописав соответствующий параметр в глобальных настройках подсистемы sftp в sshd_config. Кстати, вряд ли вы захотите перетаскивать компоненты openssh в chroot окружение, так что можно заодно сменить внешний обработчик sftp на внутреннюю реализацию:
В заключение
Меня всегда интересовал вопрос — а нет ли где-нибудь на официальных ресурсах полного списка с описанием всех PHP функций, которые так или иначе могут дать доступ скрипту к компонентам и файлам системы. Приведённый выше список честно взят из интернета, так что если кто поделится ссылочкой на списочек функций — буду премного благодарен.
Ну и да — если есть какие-то комментарии по поводу того, что ещё минимально можно сделать для обеспечения безопасной работы простейшего хостинга — пишите.