Apache: Советы по безопасности

RU EN

Пункт 82. Советы по безопасности

Некоторые советы и рекомендации по вопросам безопасности при настройке веб-сервера. Некоторые из предложений будут общими, другие специфичными для Apache.

Будь в курсе

HTTP-сервер Apache хорошо зарекомендовал себя в плане безопасности, и сообщество разработчиков очень обеспокоено проблемами безопасности. Но неизбежно, что некоторые проблемы — маленькие или большие — будут обнаружены в программном обеспечении после его выпуска. По этой причине крайне важно быть в курсе обновлений программного обеспечения. Если вы получили свою версию HTTP-сервера непосредственно от Apache, мы настоятельно рекомендуем вам подписаться на список объявлений Apache HTTP-сервера, где вы можете быть в курсе новых выпусков и обновлений безопасности. Аналогичные услуги доступны у большинства сторонних дистрибьюторов программного обеспечения Apache.

Конечно, чаще всего веб-сервер скомпрометирован не из-за проблем в коде HTTP-сервера. Скорее, это происходит из-за проблем с дополнительным кодом, сценариями CGI или основной операционной системой. Поэтому вы должны быть в курсе проблем и обновлений всего программного обеспечения в вашей системе.

Атаки отказа в обслуживании (DoS)

Все сетевые серверы могут подвергаться атакам типа «отказ в обслуживании», которые пытаются помешать ответам клиентам, связывая ресурсы сервера. Невозможно полностью предотвратить такие атаки, но вы можете сделать некоторые вещи, чтобы смягчить проблемы, которые они создают.

Часто наиболее эффективным средством защиты от DoS-атак является брандмауэр или другие конфигурации операционной системы. Например, большинство брандмауэров можно настроить на ограничение количества одновременных подключений с любого отдельного IP-адреса или сети, что предотвращает ряд простых атак. Конечно, это не поможет против распределенных атак типа «отказ в обслуживании» (DDoS).

Существуют также определенные параметры конфигурации HTTP-сервера Apache, которые могут помочь смягчить проблемы:

Директива RequestReadTimeout позволяет ограничить время, которое клиент может потратить на отправку запроса.
Директива TimeOut должна быть снижена на сайтах, подверженных DoS-атакам. Установка этого значения на несколько секунд может быть уместной. Поскольку TimeOut в настоящее время используется для нескольких различных операций, установка его на низкое значение приводит к проблемам с длительными сценариями CGI.
Директива KeepAliveTimeout также может быть снижена на сайтах, подверженных DoS-атакам. Некоторые сайты даже полностью отключают поддержку активности через KeepAlive , что, конечно, имеет другие недостатки в производительности.
Значения различных директив, связанных с тайм-аутом, предоставленных другими модулями, должны быть проверены.
Директивы LimitRequestBody , LimitRequestFields , LimitRequestFieldSize , LimitRequestLine и LimitXMLRequestBody должны быть тщательно настроены, чтобы ограничить потребление ресурсов, вызванное вводом данных клиентом.
В операционных системах, которые его поддерживают, убедитесь, что вы используете директиву, AcceptFilter чтобы переложить часть обработки запроса на операционную систему. Он активен по умолчанию в Apache httpd, но может потребовать перенастройки вашего ядра.
Настройте MaxRequestWorkers директиву, чтобы позволить серверу обрабатывать максимальное количество одновременных подключений без исчерпания ресурсов. См. также документацию по настройке производительности.
Использование многопоточного mpm может позволить вам обрабатывать больше одновременных подключений, тем самым смягчая DoS-атаки. Кроме того, event mpm использует асинхронную обработку, чтобы избежать выделения потока для каждого соединения. Из-за особенностей библиотеки OpenSSL event mpm в настоящее время несовместим с mod_ssl другими входными фильтрами. В этих случаях он возвращается к поведению mpm worker .
На http://modules.apache.org/ доступен ряд сторонних модулей, которые могут ограничивать определенное поведение клиентов и тем самым смягчать проблемы DoS.

Разрешения для каталогов ServerRoot

В типичной работе Apache запускается пользователем root и переключается на пользователя, определенного директивой User для обслуживания попаданий. Как и в случае с любой командой, которую выполняет root, вы должны позаботиться о том, чтобы она была защищена от модификации пользователями без полномочий root. Не только сами файлы должны быть доступны для записи только пользователю root, но и каталоги, и родительские каталоги всех каталогов. Например, если вы решите разместить ServerRoot, /usr/local/apache рекомендуется создать этот каталог как корневой с помощью таких команд:

mkdir /usr/local/apache cd /usr/local/apache mkdir bin conf logs chown 0 . bin conf logs chgrp 0 . bin conf logs chmod 755 . bin conf logs

Предполагается, что / , /usr , и /usr/local могут быть изменены только пользователем root. Когда вы устанавливаете httpd исполняемый файл, вы должны убедиться, что он защищен аналогичным образом:

cp httpd /usr/local/apache/bin chown 0 /usr/local/apache/bin/httpd chgrp 0 /usr/local/apache/bin/httpd chmod 511 /usr/local/apache/bin/httpd

Вы можете создать подкаталог htdocs, который могут изменять другие пользователи, поскольку root никогда не выполняет никаких файлов оттуда и не должен создавать там файлы.

Если вы разрешаете пользователям без полномочий root изменять любые файлы, которые root либо выполняет, либо записывает, вы открываете свою систему для компрометации root. Например, кто-то может заменить httpd бинарник, чтобы при следующем запуске он выполнял какой-то произвольный код. Если каталог журналов доступен для записи (пользователю, не являющемуся пользователем root), кто-то может заменить файл журнала символической ссылкой на какой-либо другой системный файл, а затем root может перезаписать этот файл произвольными данными. Если сами файлы журнала доступны для записи (пользователю без полномочий root), то кто-то может перезаписать сам журнал фиктивными данными.

Сторона сервера включает в себя

Включения на стороне сервера (SSI) представляют для администратора сервера несколько потенциальных угроз безопасности.

Первый риск — повышенная нагрузка на сервер. Все файлы с поддержкой SSI должны быть проанализированы Apache, независимо от того, включены ли в файлы какие-либо директивы SSI. Хотя это увеличение нагрузки незначительно, в среде с общим сервером оно может стать значительным.

Файлы SSI также представляют те же риски, что и сценарии CGI в целом. Используя этот exec cmd элемент, файлы с поддержкой SSI могут выполнять любой сценарий или программу CGI с разрешениями пользователя и группы, от имени которых запускается Apache, как настроено в файлах apache2.conf .

Существуют способы повысить безопасность файлов SSI, сохраняя при этом преимущества, которые они предоставляют.

Чтобы изолировать ущерб, который может нанести своевольный SSI-файл, администратор сервера может включить suexec, как описано в CGI в разделе «Общие».

Включение SSI для файлов с расширениями .html или .htm может быть опасным. Это особенно актуально в среде с общим сервером или сервером с интенсивным трафиком. Файлы с поддержкой SSI должны иметь отдельное расширение, например обычное .shtml . Это помогает свести нагрузку на сервер к минимуму и упрощает управление рисками.

Другое решение — отключить возможность запуска скриптов и программ со страниц SSI. Для этого замените Includes на IncludesNOEXEC в Options директиве. Обратите внимание, что пользователи по-прежнему могут использовать <--#include virtual="..." --> для выполнения сценарии CGI, если эти сценарии находятся в каталогах, указанных в ScriptAlias директиве.

Компьютерная графика в целом

Прежде всего, вы всегда должны помнить, что вы должны доверять авторам сценариев/программ CGI или своей способности обнаруживать потенциальные дыры в безопасности в CGI, независимо от того, были ли они преднамеренными или случайными. Сценарии CGI могут запускать практически произвольные команды в вашей системе с разрешениями пользователя веб-сервера и поэтому могут быть чрезвычайно опасными, если их тщательно не проверять.

Все сценарии CGI будут выполняться от имени одного и того же пользователя, поэтому они могут конфликтовать (случайно или преднамеренно) с другими сценариями, например, пользователь A ненавидит пользователя B, поэтому он пишет сценарий для уничтожения базы данных CGI пользователя B. Одной из программ, которую можно использовать для запуска сценариев от имени разных пользователей, является suEXEC, которая включена в Apache начиная с версии 1.2 и вызывается из специальных перехватчиков в коде сервера Apache. Другой популярный способ сделать это с помощью CGIWrap.

CGI без псевдонимов сценария

Разрешение пользователям выполнять сценарии CGI в любом каталоге следует рассматривать только в том случае, если:

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

Сценарий CGI с псевдонимом

Ограничение CGI специальными каталогами дает администратору контроль над тем, что входит в эти каталоги. Это неизбежно более безопасно, чем CGI без псевдонимов сценария, но только если пользователи с доступом для записи в каталоги являются доверенными или администратор готов протестировать каждый новый сценарий/программу CGI на наличие потенциальных брешей в безопасности.

Большинство сайтов выбирают этот вариант вместо CGI-подхода без псевдонимов сценариев.

Другие источники динамического контента

Встроенные параметры сценариев, которые запускаются как часть самого сервера, такие как mod_php , mod_perl , mod_tcl и mod_python , запускаются под идентификатором самого сервера (см. директиву User ), и поэтому сценарии, выполняемые этими механизмами, потенциально могут получить доступ ко всему, что может получить пользователь сервера. Некоторые скриптовые движки могут предоставлять ограничения, но лучше перестраховаться и предположить, что нет.

Безопасность динамического контента

При настройке динамического содержимого, такого как mod_php , mod_perl или mod_python , многие соображения безопасности выходят за рамки самих httpd себя, и вам необходимо обращаться к документации по этим модулям. Например, PHP позволяет настроить безопасный режим, который обычно отключен по умолчанию. Другой пример — Suhosin, надстройка PHP для большей безопасности. Для получения дополнительной информации о них обратитесь к документации каждого проекта.

На уровне Apache модуль с именем mod_security можно рассматривать как брандмауэр HTTP, и при условии, что вы правильно настроите его, он может помочь вам повысить безопасность динамического содержимого.

Защита системных настроек

Чтобы управлять действительно жестким кораблем, вам нужно запретить пользователям настраивать .htaccess файлы, которые могут переопределить настроенные вами функции безопасности. Вот один из способов сделать это.

В файле конфигурации сервера поместите

 <Каталог "/">
 Аллововеррайд
</Каталог>

Это предотвращает использование .htaccess файлов во всех каталогах, кроме специально разрешенных.

Обратите внимание, что этот параметр используется по умолчанию, начиная с Apache 2.3.9.

Защита файлов сервера по умолчанию

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

Например, рассмотрим следующий пример:

# cd /; ln -s / public_html Accessing http://localhost/~root/

Это позволит клиентам пройти через всю файловую систему. Чтобы обойти это, добавьте следующий блок в конфигурацию вашего сервера:

 <Каталог "/">
 Требовать все отказано
</Каталог>

Это запретит доступ по умолчанию к расположениям файловой системы. Добавьте соответствующие Directory блоки, чтобы разрешить доступ только в тех областях, которые вы хотите. Например,

 <Каталог "/usr/users/*/public_html">
 Требовать все предоставленные
</Каталог>
<Каталог "/usr/local/httpd">
 Требовать все предоставленные
</Каталог>

Обратите особое внимание на взаимодействие Location и Directory директивы; например, даже если <Directory "/"> доступ запрещен, <Location "/"> директива может отменить его.

Также будьте осторожны, играя в игры с UserDir директивой; установка его на что-то вроде ./ будет иметь тот же эффект для root, что и в первом примере выше. Мы настоятельно рекомендуем вам включить следующую строку в файлы конфигурации вашего сервера:

 UserDir отключенный корень

Просмотр ваших журналов

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

Несколько примеров:

grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log grep "client denied" error_log | tail -n 10

В первом примере будет перечислено количество атак, пытающихся использовать уязвимость Apache Tomcat Source.JSP, связанная с раскрытием информации о искаженном запросе, во втором примере будут перечислены десять последних отклоненных клиентов, например:

[Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd

Как видите, файлы журнала сообщают только о том, что уже произошло, поэтому, если бы клиент мог получить доступ к файлу, .htpasswd вы бы увидели что-то похожее на это:

foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"

в вашем журнале доступа. Это означает, что вы, вероятно, закомментировали следующее в файле конфигурации вашего сервера:

 <Файлы ".ht*">
 Требовать все отказано
</файлы>

Объединение разделов конфигурации

Объединение разделов конфигурации сложно и иногда зависит от директивы. Всегда проверяйте свои изменения при создании зависимостей от того, как объединяются директивы.

Для модулей, которые не реализуют никакой логики слияния, таких как mod_access_compat , поведение в последующих разделах зависит от того, содержит ли последний раздел какие-либо директивы из модуля. Конфигурация наследуется до тех пор, пока не будет внесено изменение, после чего конфигурация заменяется , а не объединяется.