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

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

Следите за обновлениями

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

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

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

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

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

Некоторые параметры конфигурации Apache HTTP Server также могут помочь смягчить проблемы:

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

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

При обычной работе Apache запускается пользователем root, а для обработки запросов переключается на пользователя, заданного директивой User. Как и в случае с любой командой, выполняемой от имени 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) создают для администратора сервера несколько потенциальных рисков безопасности.

Первый риск — увеличение нагрузки на сервер. Apache должен обрабатывать все файлы с включённой поддержкой SSI, независимо от того, содержат ли они директивы 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 без ScriptAlias

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

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

CGI с ScriptAlias

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

Большинство сайтов предпочитают этот вариант подходу с CGI без ScriptAlias.

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

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

[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, поведение в последующих разделах зависит от того, содержит ли последующий раздел какие-либо директивы этого модуля. Конфигурация наследуется до тех пор, пока не будет внесено изменение; после этого конфигурация заменяется, а не объединяется.