The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Как проместить Apache в chroot окружение (apache web security chroot)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: apache, web, security, chroot,  (найти похожие документы)
From: Artur Maj <http://www.securitylab.ru>; Newsgroups: http://www.securitylab.ru Date: Mon, 3 Oct 2003 14:31:37 +0000 (UTC) Subject: Как проместить Apache в chroot окружение Оригинал: http://www.securitylab.ru/?ID=38966 17 июля 2003 Защищаем Apache Web сервер Artur Maj, по материалам SecurityFocus.com В этой статье мы шаг за шагом расскажем, как правильно устанавливать и конфигурировать 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): pw groupadd apache pw useradd apache -c "Apache Server" -d /dev/null -g apache -s /sbin/nologin По умолчанию, процессы 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 сервера ------------------- Сhrooting сервера Следующий шаг должен ограничить доступ Apache к процессам файловой системы. Мы можем достигнуть этого, используя chrooting httpd демона. Вообще, средства методики chrooting, создают новую структуру корневого каталога, перемещая в него все файлы демона, и выполняя демон в этой новой среде. Благодаря этому, демон (и все дочерние процессы) будет иметь доступ только к новой структуре каталога. Мы запустим этот процесс, создавая новую структуру корневого каталога из /chroot/httpd: mkdir -p /chroot/httpd/dev mkdir -p /chroot/httpd/etc mkdir -p /chroot/httpd/var/run mkdir -p /chroot/httpd/usr/lib mkdir -p /chroot/httpd/usr/libexec mkdir -p /chroot/httpd/usr/local/apache/bin mkdir -p /chroot/httpd/usr/local/apache/logs mkdir -p /chroot/httpd/usr/local/apache/conf mkdir -p /chroot/httpd/www Владельцем всех каталогов должен быть корневой каталог, а права доступа должны быть установлены в 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 программу в новое дерево каталога со всеми необходимыми кодами и библиотеками. Для осуществления этого, мы должны подготовить список всех требуемых файлов. Мы можем сделать такой список, используя следующие команды (их присутствие зависит от особенностей операционной системы): idd Показывает динамические отношения исполняемых файлов или общедоступных библиотек. ktrace/ktruss/kdump *BSD Разрешает трассировку процессов ядра . Отображает данные трассировки адра. sotruss Solaris Трассирует вызовы процедур совместно используемых библиотек strace/ltrace Linux Отслеживает системные вызовы и сигналы. strings Находит печатаемые строки в двоичных файлах. trace AIX Осуществляет запись выбранных системных событий. trace (freeware) HP-UX <10.20 Отображает системные вызовы и трассировку kernal процессов. truss FreeBSD, Solaris, AIX 5L, SCO Unixware Отслеживает системные вызовы и сигналы. tusc (freeware) HP-UX>11 Отслеживает системные вызовы и процессы, вызванные из HP-UX 11 Ниже представлены примеры использования ldd, strings и truss команд. localhost# ldd /usr/local/apache/bin/httpd /usr/local/apache/bin/httpd: libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x280bd000) libc.so.4 => /usr/lib/libc.so.4 (0x280d6000) localhost# strings /usr/local/apache/bin/httpd| grep lib /usr/libexec/ld-elf.so.1 libcrypt.so.2 libc.so.4 localhost# truss /usr/local/apache/bin/httpd | grep open (...) open("/var/run/ld-elf.so.hints",0,00) = 3 (0x3)open("/usr/lib/libcrypt.so.2",0,027757775370) = 3 (0x3)open("/usr/lib/libc.so.4",0,027757775370) = 3 (0x3)open("/etc/spwd.db",0,00) = 3 (0x3)open("/etc/group",0,0666) = 3 (0x3)open("/usr/local/apache/conf/httpd.conf",0,0666) = 3 (0x3) (...) Вышеупомянутые команды должны применяться не только для httpd программ, но также и для всех библиотек и исходников (библиотеки часто требуют других библиотек). В случае FreeBSD системы, следующие файлы должны быть скопированы в новую структуру корневого каталога: cp /usr/local/apache/bin/httpd /chroot/httpd/usr/local/apache/bin/ cp /var/run/ld-elf.so.hints /chroot/httpd/var/run/ cp /usr/lib/libcrypt.so.2 /chroot/httpd/usr/lib/ cp /usr/lib/libc.so.4 /chroot/httpd/usr/lib/ cp /usr/libexec/ld-elf.so.1 /chroot/httpd/usr/libexec/ Используя truss команду, мы можем обнаружить, что следующие файлы конфигурации должны присутствовать в chrooted среде: cp /etc/hosts /chroot/httpd/etc/ cp /etc/host.conf /chroot/httpd/etc/ cp /etc/resolv.conf /chroot/httpd/etc/ cp /etc/group /chroot/httpd/etc/ cp /etc/master.passwd /chroot/httpd/etc/passwords cp /usr/local/apache/conf/mime.types /chroot/httpd/usr/local/apache/conf/ Обратите внимание, что мы должны удалить все строки из /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: cp /usr/local/apache/conf/httpd.conf /chroot/httpd/usr/local/apache/conf/ cp /usr/local/apache/htdocs/index.html.en /chroot/httpd/www/index.html После копирования вышеупомянутых файлов, мы должны изменить директиву DocumentRoot так, как представлено ниже (в /chroot/ httpd/ usr/ local/ apache/ conf/ htt pd.conf): DocumentRoot "/www" Затем, мы можем пробовать запустить сервер: chroot /chroot/httpd /usr/local/apache/bin/httpd Если возникают какие либо проблемы, рекомендуется точно анализировать логи Apache (/chroot/httpd/usr/local/apache/logs). Также может использоваться следующая команда: truss chroot /chroot/httpd /usr/local/apache/bin/httpd 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 Каждый сайт имеет свои собственные журналы регистраций, которые присутствуют в следующих каталогах: - /chroot/httpd/usr/local/apache/logs/www.ebank.lab - /chroot/httpd/usr/local/apache/logs/www.test.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 ;; stop) kill `cat ${CHROOT}/${PIDFILE}` ;; *) echo "" echo "Usage: `basename $0` {start|stop}" >&2 exit 64 ;;esac exit 0 Вышеупомянутый сценарий должен быть скопирован в надлежащий каталог (зависит от специфической UNIX системы), где по умолчанию содержаться сценарии запуска. В случае FreeBSD это - каталог/usr/local/etc/rc.d. Выводы Вышеупомянутый метод позволяет достигнуть более высокого уровня защиты Web сервера Apache, чем тот, который предлагается в заданной по умолчанию инсталляции. Благодаря активации только абсолютно необходимых модулей Apache, обнаружение новой уязвимости в любом из них не должно указывать, на то, что сервер уязвим. Сокрытие номера версии Apache, отключение службы индексации каталогов, изменение корневой директории и ограниченная конфигурация затрудняют успешный взлом. сhrooted среда имеет также еще одно важное преимущество - устойчивость к большому количеству эксплойтов, главным образом из-за недостатка оболочки (/bin/sh,/bin/csh и т.д.). Даже если вторгшийся сможет выполнять произвольные команды системы, выход из chrooted среды будет настоящей проблемой.

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ RSS ]
  • 1, max (?), 18:50, 26/01/2004 [ответить]  
  • +/
    conf file missing ServerName directive.  Aside of that, great article.  Thanks for help.
     
  • 3, AlexF (??), 10:33, 06/11/2006 [ответить]  
  • +/
    При вводе команды :
    chroot /chroot/httpd /usr/local/apache/bin/httpd
    Выдаёт:
    ELF interpreter /libexec/ld-elf.so.1 not found
    Abort

    Усли кто имеет опыт по этому поводу, поделитесь плиз!

     

    игнорирование участников | лог модерирования

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру