From: Mor-project (Портал Программистов) <http://mor.hosting-design.net/>
Date: Mon, 23 Feb 2004 14:31:37 +0000 (UTC)
Subject: Установка защищенного Web сервера под управлением Apache
В этой статье мы шаг за шагом расскажем, как правильно устанавливать
и конфигурировать Apache 1.3.x Web сервер, для того чтобы смягчить или
избежать возможность успешного взлома, в случае обнаружения новой
уязвимости в этом популярном Web сервере.
Функциональные возможности:
Прежде чем защищать Apache, нужно определить функциональные
возможности, ожидаемые от сервера. Разнообразие в использовании Apache
делает трудным написание универсальной процедуры для защиты сервера в
каждом отдельном случае. Именно поэтому в этой статье мы будем
базироваться на следующих функциональных возможностях:
* Web-сервер будет доступен из Internet;
* Будут обслуживаться только статические HTML страницы
* Сервер будет поддерживать виртуальный механизм хостинга на основе
имен.
* Указанные Web-страницы могут быть доступны только для выбранных
IP-адресов или пользователей (базовая идентификация)
* Сервер регистрирует все Web-запросы (включая информацию о
Web-браузерах)
Стоит подчеркнуть, что вышеупомянутая модель не поддерживает PHP, JSP,
CGI и любые другие технологии, которые позволяют взаимодействовать с
Web службами. Использование таких технологий может представлять
большую угрозу защите, так даже маленький, неприметный сценарий может
радикально уменьшить уровень защиты сервера. Почему? Прежде всего,
PHP/CGI приложения могут содержать уязвимость защиты (например, SQL
инъекцию или межсайтовый скриптинг). Во вторых, опасна сама технология
(уязвимость в PHP, Perl модулях и т.д.). Именно поэтому настоятельно
рекомендуется использовать такие технологии только в тех случаях,
когда взаимодействие с Web-cайтом абсолютно необходимо.
Предложения по защите.
Одним из наиболее важных элементов каждого компьютерного проекта
является спецификация предложений по защите. Она должна быть выполнено
прежде, чем проект осуществлен. Предложения по защите для нашего
Web-сервера следующие:
* Операционная система должна быть в максимально возможной степени
защищена от локальных и удаленных нападений;
* Сервер не должен поддерживать отличные от HTTP(80/TCP) сетевые
протоколы;
* Удаленный доступ к серверу должен управляться межсетевой защитой,
которая должна блокировать все внешние подключения и разрешать
входящие подключения только через 80/TCP порт Web-сервера;
* Apache Web server должен быть единственной службой, доступной
системе;
* Необходимо разрешить использование только самых необходимых
модулей Apache;
* Должны быть выключены любые диагностические Web-страницы и
автоматические службы индексации каталога;
* Сервер должен раскрыть наименьшее количество информации о себе
(защита втемную);
* Сервер Apache должен выполняться под уникальным UID/GID, не
используемым никаким другим системным процессом;
* Процессы Apache, должны быть, ограничены доступом к системным
файлам (chrooting);
* Никакие программы-оболочки не должны присутствовать в chrooted
среде Apache (/bin/sh,/bin/csh и т.д.).
Инсталляция операционной системы
Перед установкой Apache мы должны выбрать операционную систему, на
которой будет установлен сервер. У нас имеется широкий выбор, потому
что Apache может компилироваться и устанавливаться почти каждой
операционной системе. В оставшейся части статьи мы расскажем, как
защитить Web-сервер Apache на FreeBSD (4.7). Описанные методы можно
применить в большинстве UNIX/Linux систем. Единственная операционная
система, которую не рекомендуется использовать - MS Windows - главным
образом из-за ограниченных возможностей поддержки Apache.
Первый шаг в защите Web-сервера укрепляет операционную систему.
Обсуждение укрепления операционной системы - вне возможностей этой
статьи.
После того, как система установлена и укреплена, мы должны добавить
новую группу, а пользователя назвать "apache". (пример от FreeBSD):
По умолчанию, процессы Apache выполняются с привилегиями пользователя
nobody (кроме главного процесса, который выполняется с привилегиями
root) и GID группы nogroup. Это может создать существенную угрозу
защите. В случае успешного прорыва вторгшийся может получить доступ
ко всем другим процессам, которые выполняются под тем же самым
UID/GID. Следовательно, оптимальное решение состоит в том, чтобы
выполнить Apache под UID/GID уникального пользователя/группы,
специализированного под это программное обеспечение.
Подготовка программного обеспечения
Следующий шаг заключается в загрузке самой последней версии
Web-сервера Apache http://httpd.Apache.org/. Некоторые из параметров
Apache доступны только во время компиляции, таким образом, важно
загрузить исходный код вместо двоичной версии.
После загрузки программного обеспечения, мы должны его распаковать.
Затем мы должны решить, какие модули оставить доступными. Краткое
описание всех модулей, доступных в самой последней версии Apache 1.3.x
(1.3.27) можно найти в http://httpd.Apache.org/docs/mod/.
Модули Apache
Выбор модулей - один из наиболее важных шагов защиты Apache. Нужно
действовать в соответствии с правилом: чем меньше, тем лучше. Для
выполнения функциональных возможностей и предложений по защите,
следующие модули должны остаться доступными:
httpd_core
Особенности ядра Apache, требуются при каждой установке Apache
mod_access
Обеспечивает управление доступом, основанным на имени хоста клиента,
IP-адресе и других характеристиках запроса клиента. Поскольку этот
модуль необходим, чтобы использовать директивы "order", "allow" и
"deny", он должен оставаться доступным.
mod_auth
Требуется для осуществления пользовательской идентификации (базовая
HTTP идентификация).
mod_dir
Требуется, для поиска и обслуживания каталога с индексными файлами:
"index.html", "default.htm", и т.д.
mod_log_config
Требуется для регистрации запросов, сделанных на сервер.
mod_mime
Требуется для установки набора символов, content encoding,
обработчика, content-language, и документов MIME типа.
Все другие модули Apache должны быть отключены. Мы можем их безопасно
отключать, главным образом потому, что они нам не нужны. Отключая
ненужные модули, мы можем избежать потенциального взлома, когда была
найдена новая уязвимость защиты в одном из них.
Также стоит обратить внимание на то, что два из модулей Apache могут
быть наиболее опасны, чем другие: mod_autoindex и mod_info. Первый
модуль обеспечивает автоматическую индексацию каталогов, и доступен по
умолчанию. Этот модуль удобен для проверки выполнения Apache на
сервере (например, http://server_name/icons/) и получения содержимого
каталогов Web-сервера, когда в них отсутствуют индексные файлы.
Второй модуль, mod_info, никогда не должен быть доступен из Internet,
главным образом потому он показывает конфигурацию Apache сервера.
Следующий вопрос - как правильно скомпилировать модули. Лучше
использовать статический метод. Если найдена новая уязвимость в
Apache, мы вероятно повторно скомпилируем не только уязвимые модули,
но и всю программу. Выбирая статический метод, мы устраняем
потребность в еще одном модуле - mod_so.
Компиляция программы
Сначала, если возможно, должны быть установлены все патчи защиты.
Затем, сервер должен быть скомпилирован и установлен следующим
образом:
./configure --prefix=/usr/local/apache --disable-module=all --server-
uid=apache --server-gid=apache --enable-module=access --enable-
module=log_config --enable-module=dir --enable-module=mime --enable-module=auth
make
su
umask 022
make install
chown -R root:sys /usr/local/apache
Сhrooting сервера
Следующий шаг должен ограничить доступ Apache к процессам файловой
системы. Мы можем достигнуть этого, используя chrooting httpd демона.
Вообще, средства методики chrooting, создают новую структуру корневого
каталога, перемещая в него все файлы демона, и выполняя демон в этой
новой среде. Благодаря этому, демон (и все дочерние процессы) будет
иметь доступ только к новой структуре каталога.
Мы запустим этот процесс, создавая новую структуру корневого каталога
из /chroot/httpd:
Владельцем всех каталогов должен быть корневой каталог, а права
доступа должны быть установлены в 0755. Затем, мы создадим специальный
файл устройства: /dev/null
ls -al /dev/null
crw-rw-rw- 1 root wheel 2, 2 Mar 14 12:53 /dev/null
mknod /chroot/httpd/dev/null c 2 2
chown root:sys /chroot/httpd/dev/null
chmod 666 /chroot/httpd/dev/null
Различные методы должны использоваться для создания устройства
/chroot/httpd/dev/log, которое также необходимо для правильной работы
сервера. В случае системы FreeBSD, к /etc/rc.conf должна быть
добавлена следующая строка:
syslogd_flags="-l /chroot/httpd/dev/log"
Мы должны перезапустить систему или syslogd демон непосредственно для
вступления в силу сделанных изменений. Для создания устройства
/chroot/httpd/dev/log на других операционных системах, нужно смотреть
справочное руководство (man syslogd).
В следующем шаге мы должны скопировать главную httpd программу в новое
дерево каталога со всеми необходимыми кодами и библиотеками. Для
осуществления этого, мы должны подготовить список всех требуемых
файлов. Мы можем сделать такой список, используя следующие команды (их
присутствие зависит от особенностей операционной системы):
ldd
Показывает динамические отношения исполняемых файлов или
общедоступных библиотек.
ktrace/ktruss/kdump (*BSD)
Разрешает трассировку процессов ядра . Отображает данные трассировки адра.
sotruss (Solaris)
Трассирует вызовы процедур совместно используемых библиотек
strace/ltrace (Linux)
Отслеживает системные вызовы и сигналы.
strings
Находит печатаемые строки в двоичных файлах.
trace (AIX)
Осуществляет запись выбранных системных событий.
Вышеупомянутые команды должны применяться не только для httpd
программ, но также и для всех библиотек и исходников (библиотеки часто
требуют других библиотек). В случае FreeBSD системы, следующие файлы
должны быть скопированы в новую структуру корневого каталога:
Обратите внимание, что мы должны удалить все строки из
/chroot/httpd/etc/passwords, кроме "nobody" и "apache". Подобным
способом, мы должны удалить все строки кроме "apache" и "nogroup" из
/chroot/httpd/etc/group. Затем, мы должны построить базу данных
паролей следующим образом:
cd /chroot/httpd/etc
pwd_mkdb -d /chroot/httpd/etc passwords
rm -rf /chroot/httpd/etc/master.passwd
Следующий шаг состоит в проверке правильности выполнения httpd
сервера в новой chrooted среде. Для этого, мы должны скопировать файл
apache конфигурации и index.html:
После копирования вышеупомянутых файлов, мы должны изменить директиву
DocumentRoot так, как представлено ниже (в /chroot/httpd/usr/local/apache/conf/httpd.conf):
DocumentRoot "/www"
Затем, мы можем пробовать запустить сервер:
chroot /chroot/httpd /usr/local/apache/bin/httpd
Если возникают какие либо проблемы, рекомендуется точно анализировать
логи Apache (/chroot/httpd/usr/local/apache/logs). Также может
использоваться следующая команда:
Truss программа должна показать причину проблемы. После устранения
любых возможных ошибок, мы можем конфигурировать Apache сервер.
Конфигурирование Apache
Сначала должен быть удален
/chroot/httpd/usr/local/apache/conf/httpd.conf файл и создан новый на
его месте, с следующим содержимым:
# =================================================
# Basic settings
# =================================================
ServerType standalone
ServerRoot "/usr/local/apache"
PidFile /usr/local/apache/logs/httpd.pid
ScoreBoardFile /usr/local/apache/logs/httpd.scoreboard
ResourceConfig /dev/null
AccessConfig /dev/null
# =================================================
# Performance settings
# =================================================
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 0
# =================================================
# Apache's modules
# =================================================
ClearModuleList
AddModule mod_log_config.c
AddModule mod_mime.c
AddModule mod_dir.c
AddModule mod_access.c
AddModule mod_auth.c
# =================================================
# General settings
# =================================================
Port 80
User apache
Group apache
ServerAdmin Webmaster@www.ebank.lab
UseCanonicalName Off
ServerSignature Off
HostnameLookups Off
ServerTokens Prod
<IfModule mod_dir.c>
DirectoryIndex index.html</IfModule>
DocumentRoot "/www/vhosts"
# =================================================
# Access control
# =================================================
<Directory>
Options None AllowOverride None Order deny,allow
Deny from all</Directory>
<Directory "/www/vhosts/www.ebank.lab">
Order allow,deny Allow from all</Directory>
<Directory "/www/vhosts/www.test.lab">
Order allow,deny Allow from all</Directory>
# =================================================
# MIME encoding
# =================================================
<IfModule mod_mime.c>
TypesConfig /usr/local/apache/conf/mime.types</IfModule>
DefaultType text/plain
<IfModule mod_mime.c>
AddEncoding x-compress Z AddEncoding x-gzip gz tgz
AddType application/x-tar .tgz</IfModule>
# =================================================
# Logs
# =================================================
LogLevel warn
LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%h %l %u %t "%r" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
ErrorLog /usr/local/apache/logs/error_log
CustomLog /usr/local/apache/logs/access_log combined
# =================================================
# Virtual hosts
# =================================================
NameVirtualHost *
<VirtualHost *>
DocumentRoot "/www/vhosts/www.ebank.lab"
ServerName "www.ebank.lab"
ServerAlias "www.e-bank.lab"
ErrorLog logs/www.ebank.lab/error_log
CustomLog logs/www.ebank.lab/access_log combined
</VirtualHost>
<VirtualHost *>
DocumentRoot "/www/vhosts/www.test.lab"
ServerName "www.test.lab"
ErrorLog logs/www.test.lab/error_log
CustomLog logs/www.test.lab/access_log combined
</VirtualHost>
Вышеупомянутая конфигурация включает в себя только те команды, которые
необходимы для сделанных предложений по защите и функциональным
возможностям. В представленной конфигурации присутствуют два
виртуальных хоста, поддерживаемые Web-сервером:
Наполнение вышеупомянутых сайтов физически существует в следующих
каталогах:
- /chroot/httpd/www/vhosts/www.ebank.lab
Каждый сайт имеет свои собственные журналы регистраций, которые
присутствуют в следующих каталогах:
Вышеупомянутые каталоги должны быть созданы перед первым запуском
Apache - иначе он не будет правильно выполняться. Владельцем
вышеупомянутых каталогов должен быть root:sys, и права доступа должны
быть установлены к 0755.
По сравнению с базовым файлом конфигурации Apache, были сделаны
следующие изменения:
* Было уменьшено число доступных модулей.
* Apache не раскрывает информацию о номере своей версии (директивы:
ServerTokens, ServerSignature).
* Процессы Apache (кроме корневого процесса) были установлены,
чтобы выполняться с привилегиями уникального пользователя/группы
(директивы: User, Group).
* Apache разрешает доступ только к тем каталогам, подкаталогам и
файлам, которые были явно определены в файле конфигурации
(директивы: Directory, Allow); все другие запросы будут отклонены
по умолчанию.
* Apache регистрирует большее количество информации о HTTP запросах.
Финальные шаги
В конце, мы должны создать запускающий сценарий "apache.sh",
содержание которого будет подобно следующему:
#!/bin/sh
CHROOT=/chroot/httpd/
HTTPD=/usr/local/apache/bin/httpd
PIDFILE=/usr/local/apache/logs/httpd.pid
echo -n " apache"
case "$1" in
start)
/usr/sbin/chroot $CHROOT $HTTPD
Вышеупомянутый сценарий должен быть скопирован в надлежащий каталог
(зависит от специфической UNIX системы), где по умолчанию содержаться
сценарии запуска. В случае FreeBSD это - каталог/usr/local/etc/rc.d.
Выводы
Вышеупомянутый метод позволяет достигнуть более высокого уровня защиты
Web сервера Apache, чем тот, который предлагается в заданной по
умолчанию инсталляции.
Благодаря активации только абсолютно необходимых модулей Apache,
обнаружение новой уязвимости в любом из них не должно указывать, на
то, что сервер уязвим. Сокрытие номера версии Apache, отключение
службы индексации каталогов, изменение корневой директории и
ограниченная конфигурация затрудняют успешный взлом. сhrooted среда
имеет также еще одно важное преимущество - устойчивость к большому
количеству эксплойтов, главным образом из-за недостатка оболочки
(/bin/sh,/bin/csh и т.д.). Даже если вторгшийся сможет выполнять
произвольные команды системы, выход из chrooted среды будет настоящей
проблемой.
901 Прочтений • [Установка защищенного Web сервера под управлением Apache (security apache install chroot freebsd)] [08.05.2012] [Комментариев: 0]
Vova
