Меню

apache mpm itk настройка

Безопасная настройка web-сервера (nginx+apache2-mpm-itk)

В данной статье я попытаюсь составить наиболее полное описание безопасной настройки web-сервера (nginx+apache), под управлением ОС Debian. А также eaccelerator для более продуктивной работы сервера.

1. Создаем пользователей, файловая система.

Для начала я бы порекомендовал отделить под сайты отдельную директорию на сервере (вместо дефолтных, а-ля /home/user/www/). Создадим к примеру директорию sites, в корне. Выполним команды:

Тем самым мы создали директорию sites с правами доступа 755.

Далее создадим пользователей в системе. (для простоты мы будем настраивать сервер на 2-х пользователей.)

(Добавляем группу для первого юзера)

useradd user1 -d /sites/user1 -g user1 -s /bin/false

(Добавляем первого юзера, устанавливаем ему домашнюю директорию, добавляем во вновь созданную группу, и убираем ему оболочку (/bin/bash))

passwd user1

(Правим права доступа к домашней директории)

mkdir -p -m 754 /sites/user1/public_html/www

(создаем веб-директорию, устанавливаем права доступа)

mkdir -p -m 777 /sites/user1/tmp

(создаем директорию для временных файлов, устанавливаем права доступа)

chown -R user1:user1 /web/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

# Важный момент, указываем, что апач будет работать от пользователя wwwdata и нашей группы 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

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

Ответ связан с предыдущим пунктом. Рассмотрим пример:

Имеется два сайта с такими конфигами:

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

location / <
proxy_pass 127.0.0.1:8080;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>

* ^.+\.(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, от которого он работает в группы юзеров наших проектов.

usermod -a -G site1,site2,site3 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»

Далее создадим директорию для кэша:

mkdir -p /var/cache/eaccelerator
chmod 0777 /var/cache/eaccelerator

ВАЖНО!

При установке 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

phpize
./configure —without-eaccelerator-use-inode
make
make install

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

источник

Аникин

Установка и настройка в ubuntu

Для начала установим сам модуль

# apt-get install apache2-mpm-itk

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

Читайте также:  настройки для lightroom пресеты

Затем правим конфигурационный файл apache.

Внутрь каждого виртуального хоста добавляем такие строки:

Где user1 user1 — пользователь и группа соответственно.

Установка в CentOS

Правим конфигурационные файлы

Раскомментируем и изменяем строку на такую:

LoadModule php5_module modules/libphp5.so

Меняем диррективу SuexecUserGroup на AssignUserID для существующих доменов.

# sed -i -e ‘s/SuexecUserGroup/AssignUserID/g’ /etc/httpd/conf/httpd.conf

Для вновь созданных доменов в виртуальном хосте нужно указывать

Где user1 user1 — пользователь и группа соответственно.

Вставляем настройки модуля перед виртуальными хостами

Настройка для сервера с панелью isp.

Откроем конфигурационный файл isp

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

Как проверить что все работает правильно?

В папке виртуального хоста создаем файл с расширением .php и примерно таким содержанием:

Открываем этот файл в браузере и выводом этого файла должно быть имя пользователя под которым работает этот скрипт. Так же не забываем что если сервер функционирует давно то в подкаталогах куча фалов принадлежащих пользователю www-data. Неплохо бы сделать chown -R username на каталоги сайтов.

источник

Модуль мультипроцессинга mpm-itk веб-сервера Apache

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

Зачем нужен мультипроцессинг для веб-сервера?

Поскольку к веб-серверу одновременно может быть направлено множество запросов. То естественно, необходимо некоторую часть из них принять в обработку. А оставшиеся запросы поместить в очередь ожидания. После того, как занятый обработкой запроса процесс освободится. Он получит следующий, находившийся в очереди запрос. И так далее. Сколько должно одновременно обрабатываться запросов, сколько должно находиться в очереди, а также стратегия распределения задач между процессами — определяется системной конфигурацией веб-сервера. Эти параметры настраиваются в ходе оптимизации и тестирования программно-аппартной платформы. На которой предполагается работа веб-сервера. Исходя из прогнозируемых нагрузок и специфики выполняемых задач.
Но дело ещё и в том, чтобы не просто обеспечить максимальную производительность веб-сервера за счёт тонкой и сбалансированной настройки мультипроцессинговой обработки, но также обеспечить выполнение каждого процесса в «индивидуальном» порядке. Это подразумевает выполнение каждого процесса от имени конкретного пользователя. Такой подход обеспечивает максимальную безопасность без потери производительности. При условии, что имеют место достаточное количество аппаратных ресурсов. А также грамотная оптимизация работы соответствующего программного обеспечения (ПО).

Как это работает?

Для организации выполнения процессов (точнее экземпляров) Apache от разных пользователей существуют различные модули. Одним из таких является модуль mpm-itk. Для дистрибутивов Ubuntu этот модуль доступен в стандартном репозитории в виде отдельного пакета под именем libapache2-mpm-itk.
Разные виртуальные хосты (соответствующие каталоги и их содержимое) могут принадлежать разным пользователям. По-умолчанию Apache для мультипроцессинговой обработки HTTP-запросов для виртуальных хостов использует определённое количество процессов-экземпляров самого себя, которые запускаются от имени одного (обычно это пользователь www-data, apache или http) пользователя. Такимы образом, по-умолчанию с конфигурацией «из коробки» Apache от имени одного пользователя обслуживает виртуальные хосты, принадлежащие разным пользователям. Это потенциальная дыра в безопасности. Частично проблема решается добавлением верифицированных пользователей-владельцев виртуальных хостов в группу Apache. Но, во-первых, это полностью не решает проблему с безопасностью, во-вторых, это очень неудобно. Как самим пользователям, так и администраторам.
Модуль mpm-itk позволяет запускать отдельные экземпляры Apache от имени того пользователя, к виртуальному хосту которого поступил HTTP-запрос. Таким образом, каждый виртуальный хост обслуживается процессом веб-сервера, запущенным от имени самого этого пользователя — владельца виртуального хоста. Данный подход снимает все противоречия в модели распределения доступа к ресурсам виртуальных хостов. Всё, что нужно — это указать веб-серверу, что тот или иной хост нужно обрабатывать от имени его владельца. Это делается путём указания соответствующих директив в конфигурационном файле виртуального хоста.

Читайте также:  как изменить шрифт на андроиде в настройках

Установка mpm-itk в Linux

Поскольку в большинстве дистрибутивов Linux в стандартном репозитории уже доступны многие модули Apache, в том числе и mpm-itk, то лучше воспользоваться менеджером пакетов (или системой управления пакетами СУП) используемого дистрибутива для его (модуля) установки. Например, для Ubuntu нужно установит пакет libapache2-mpm-itk:

$ sudo apt install libapache2-mpm-itk

После этого можно перезапустить Apache:

Но вообще, скрипт установки модуля должен перезапустить веб-сервер автоматически.
Если используемый дистрибутив не предоставляет готовых пакетов для модуля mpm-itk, то установку можно произвести вручную. Исчерпывающие инструкции для этого приведены на официальном сайте разработчиков модуля: http://mpm-itk.sesse.net.

Базовая настройка mpm-itk

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

Как можно видеть, директива AssignUserId определяет пользователя и группу (именно в таком порядке), указывая веб-серверу, что к данному виртуальному хосту может получить доступ процесс, принадлежащий только указанным пользователю и группе. В данном случае это пользователь john и его одноимённая группа.
Инструкция предназначена для задействования директивы AssignUserId только тогда, когда подключен соответствующий модуль, т. е. mpm-itk. Фраза «mpm_itk_module» формируется из двух составляющих: имени модуля, под которым он был подключен (в данном случае mpm_itk), а также классификатора объекта Apache – module, поскольку это подключаемый модуль. Просмотреть подключенные модули Apache (и их имена) можно в каталоге /etc/apache2/mods-enabled. А все доступные модули должны храниться в каталоге /etc/apache2/mods-available. Например, модулю mpm-itk соответствует файл mpm_itk.load.
Если теперь понаблюдать за процессами Apache, то можно убедиться, что во время обращения к пользовательскому виртуальному хосту (для которого определена директива AssignUserId) создаётся экземпляр Apache, запущенный от соответствующего пользователя.

Заключение

В заключение необходимо отметить, что модуль mpm-itk применяется в тех системах, где безопасность важнее производительности. Поскольку при использовании этого модуля процессы каждый раз при обработке виртуального хоста создаются заново и полностью уничтожаются при отсутствии к нему запросов, то ясно, что производительность от этого не увеличится. Чаще всего подобная схема используется на хостинг-площадках.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

источник

Добавить комментарий

Adblock
detector