Приветствую вас, уважаемые читатели блога.

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

Список задач

  • Создание пользователей и настройка прав доступа.
  • Установка web-сервера
  • Конфигурирование apache и php

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

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

cd /
mkdir -m 755 sites

Тем самым мы создали директорию sites с правами доступа 755. (пояснения по правам доступа будут в конце статьи.)

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

addgroup user1

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

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

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

passwd user1

(Устанавливаем пароль)

chmod 754 /sites/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.

Поставим модуль из репозиториев:

apt-get install apache2-mpm-itk

Установка стандартна, расписывать не буду. Подробнее остановлюсь на конфигурации.

Вот пример конфигурационного файла /etc/apache2/sites-available/user1

<VirtualHost *:80>

ServerName www.user1.ru

ServerAlias user1.ru  *.user1.ru

DocumentRoot /sites/user1/public_html/www/»

ErrorLog /sites/user1/error_log

CustomLog /sites/site1/access_log combined

# Важный момент, указываем, что апач будет работать от пользователя wwwdata и нашей группы site1

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

</VirtualHost>

Сохраняем конфиг, теперь активируем конфиг командой:

a2ensite user1

Далее перечитываем конфиги

/etc/init.d/apache2 reload

3. OUTRO (Пояснения по статье)

Пояснения к статье написаны для новичков, я специально вынес их в отдельный пункт.

3.1 CHMOD

Итак, для начала теория.

chmod (анг. change file mode) — изменение режима доступа к файлам в операционных системах Unix, Linux и им подобных.

Буквенное или цифровое обозначение сhmod делится на три группы:

– владелец файла

– группа

– остальные пользователи

Цифровое обозначение высчитывается следующим образом:

4 – чтение файла

2 – запись в файл

1 – выполнение файла (для директорий это обозначает возможность зайти в директорию)

eg. 755

С буквенным обозначение все еще проще

r – чтение файла

w – запись в файл

x – выполнение файла (для директорий это обозначает возможность зайти в директорию)

eg. rwxrxrx

Разберем теперь для примера одно значение прав доступа, используемое в статье.

rwxrxr–(754)

rwx – владелец файла может читать его, записывать и запускать на выполнение.

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

r– все остальные пользователи системы могут только лишь читать файл.

3.2 AssignUserId www-data site1

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

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

Действующих лиц трое: site1, site2 и wwwdata

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

  1. AssignUserId wwwdata site1
  2. AssignUserId wwwdata site2

У сайта site1 есть файл

-rwxr-x— 1 site1 site1 397 Dec 1 23:15 index.php

Обратите внимание на юзера и группу владельца файла.

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

Поясню – права доступа выставлены так, что файл сможет прочитать только лишь владелец файла и участники группы, в это число входит site1 и веб-сервер запущенный от имени www-data, т.к. он работает от группы site1. Т.е. site1 может прочитать файл, записать и выполнить, веб-сервер может только прочитать и выполнить, а site2 и веб-сервер запущенный от имени группы site2 уже не сможет прочесть важные файлы соседнего сайта, как то конфигурационный файл и т.п.

Copyrights © twost

Безопасная настройка web-сервера
9 оценок, Средняя оценка: 5 из 5

  1. У вас ошибочка в статье, chown -R user1:user1 /web/user1/, домашняя директория у юзера /sites/user1/

    Спасибо за статью!

  2. AssignUserId www-data site1
    Здесь стоит выставить и владельца, и группу как site1, иначе скрипт, запущеный от www-data, сможет прочитать важные файлы другого пользователя, созданные просессом apache.
    Например, если пользователь site1 установит какую-нибудь CMS через веб-установщик, то владельцем конфигурационных файлов CMS будет www-data. Таким вот образом пользователь site2, зная путь к этим файлам (а узнать это несложно), с помощью своего скрипта, работающего от www-data, сможет прочитать эти файлы. Так что www-data не стоит использовать. Да и кроме этой дыры будут и другие неудобства..

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *