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

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

Работать с последними версиями

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

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

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

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

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

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

• Директива RequestReadTimeout позволяет ограничить время, которое клиент может потратить на отправку запроса.
• Директива TimeOut должна быть снижена на сайтах, которые подвергаются атакам DoS. Возможно, значение, равное нескольким секундам, будет подходящим. Так как TimeOut в настоящее время используется для нескольких различных операций, установка низкого значения приводит к проблемам с долго выполняющимися CGI-скриптами.
• Директива KeepAliveTimeout также может быть снижена на сайтах, подверженных атакам DoS. Некоторые сайты даже полностью отключают keep-alive через KeepAlive, что, конечно, имеет другие недостатки для производительности.
• Следует проверить значения различных директив, связанных с тайм-аутами, предоставляемых другими модулями.
• Директивы LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, и LimitXMLRequestBody должны быть тщательно настроены для ограничения потребления ресурсов, вызванных вводом клиента.
• В операционных системах, которые это поддерживают, убедитесь, что вы используете директиву AcceptFilter для перегрузки части обработки запросов на операционную систему. По умолчанию это включено в Apache httpd, но может потребовать переконфигурации вашего ядра.
• Настройте директиву MaxRequestWorkers для того, чтобы сервер мог обрабатывать максимальное количество одновременных подключений без исчерпания ресурсов. См. также документацию по настройке производительности performance tuning documentation.
• Использование потоковой mpm может позволить обрабатывать больше одновременных подключений, тем самым смягчая атаки DoS. Кроме того, event mpm использует асинхронную обработку, чтобы не выделять поток для каждого подключения. Из-за особенностей библиотеки OpenSSL event mpm в настоящее время несовместим с mod_ssl и другими фильтрами ввода. В таких случаях он возвращается к поведению worker mpm.
• Существует ряд сторонних модулей, которые могут ограничивать определённое поведение клиентов и тем самым смягчать проблемы с DoS.

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

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

Например, если вы решите разместить ServerRoot в /usr/local/apache, рекомендуется создать этот каталог как root, используя такие команды:

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) предоставляют администратору сервера несколько потенциальных рисков безопасности.

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

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

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

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

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

Другое решение — запретить выполнение скриптов и программ из страниц SSI. Для этого замените Includes на IncludesNOEXEC в директиве Options.

Обратите внимание, что пользователи всё ещё могут использовать <--#include virtual="..." --> для выполнения CGI-скриптов, если эти скрипты находятся в каталогах, указанных в директиве ScriptAlias.

CGI в целом

Прежде всего, всегда нужно помнить, что необходимо доверять авторам 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, которые могут переопределять функции безопасности, которые вы настраивали. Вот один из способов сделать это.

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

<Directory "/">
    AllowOverride None
</Directory>

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

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

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

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

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

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

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

<Directory "/">
    Require all denied
</Directory>

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

<Directory "/usr/users/*/public_html">
    Require all granted
</Directory>
<Directory "/usr/local/httpd">
    Require all granted
</Directory>

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

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

UserDir disabled root

Наблюдение за логами

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

Вот несколько примеров:

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

Первый пример покажет количество атак, пытающихся использовать уязвимость Apache Tomcat Source.JSP Malformed Request Information Disclosure Vulnerability, второй пример покажет десять последних заблокированных клиентов, например:

[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"

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

<Files ".ht*">
    Require all denied
</Files>

Слияние разделов конфигурации

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

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