31.12.2005

20 Способов усиления безопасности Apache Web сервера

В статье описываются 20 способов усиления безопасности конфигурации Apache Web сервера.

В статье описываются 20 способов усиления безопасности конфигурации Apache Web сервера.

Предупреждение: Описанные ниже методы не дают гарантий полной безопасности и автор не несет ответственности за последствия их выполнения. Эти действия помогут сделать ваш Web сервер более безопасным, но они не являются панацеей от всех бед.

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

Сначала проверьте, установили ли вы последние обновления безопасности

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

Скройте информацию о  версии Apache и другую чувствительную информацию

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

Две записи, которые необходимо добавить или исправить в файле httpd.conf:

ServerSignature Off
ServerTokens Prod

ServerSignature появляется внизу страниц, сгенерированных apache, таких как 404, списки каталогов и т.д.

Запись ServerTokens используется в заголовках HTTP ответа. Изменив значение на Prod, мы получим следующий заголовок HTTP ответа:

Server: Apache

Если вы совсем параноик, то можете написать что-нибудь другое, кроме "Apache", покопавшись в исходниках или используя mod_security (см. ниже).

apache должен запускаться с отдельным пользовательским акаунтом и группой

Некоторые сборки apache запускаются как пользователь nobody. Таким образом, если Apache и почтовый сервер запущены от имени nobody, то удачная атака на Apache приведет к компрометации и почтового сервера, и наоборот.

User apache
Group apache

Убедитесь, что не обслуживаются файлы вне web каталога

Нам не нужно, чтобы apache мог изменять какие-либо файлы за пределами своего web каталога. Предположим, что все ваши веб сайты расположены в одной директории (пусть будет /web). Тогда необходимо выполнить следующие изменения:

<Directory />
Order Deny,Allow
Deny from all
Options None
AllowOverride None
</Directory>
<Directory /web>
Order Allow,Deny
Allow from all
</Directory>

Заметьте, что так как мы установили Options None и AllowOverride None, то все Options и Overrides будут отключены для сервера. Теперь вы должны добавить их для каждой директории, в которой требуется Option или Override.

Выключаем просмотр директорий

Делается это при помощи директивы Options внутри тэга Directory. Установим значение для Options в None или -Indexes.

Options -Indexes

Выключаем SSI

Это тоже делается при помощи директивы Options внутри тэга Directory. Установим значение для Options в None или -Includes.

Options -Includes

Выключаем запуск CGI

Если вы не используете CGI, выключите это в директиве Options внутри тэга Directory. Установите значение для Options в None или -ExecCGI.

Options -ExecCGI

Не позволяйте аpache следовать по символьным ссылкам

Делается аналогично предыдущим трем советам:

Options -FollowSymLinks

Отключаем множество Options

Если вы хотите отключить все Options, то просто делайте так:

Options None

Ну а если вы хотите выключить лишь некоторые из них, то пишите через пробелы:

Options -ExecCGI -FollowSymLinks -Indexes

 Отключаем поддержку .htaccess файлов

Делается в тэге Directory, но уже с помощью директивы AllowOverride. Установите значение None.

AllowOverride None

Если вам необходимо чтобы Overrides нельзя было загрузить, и/или изменить, то поменяйте имя на другое, отличное от .htaccess. Например, в .httpdoverride, и поставим запрет на загрузку всех файлов, которые начинаются с .ht:

AccessFileName .httpdoverride
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>

Запускаем mod_security

mod_security очень удачный модуль для Apache, написанный Иваном Ристиком (Ivan Ristic), автором Apache Security от O'Reilly press.

С помощью mod_security вы можете делать следующее:

  • Простое фильтрование
  • Фильтрование, основанное на регулярных выражениях
  • Проверка URL кодировки
  • Проверка Unicode кодировки
  • Аудит
  • Предотвращение атаки «Null byte»
  • Ограничение загрузки памяти
  • Маскировка сервера
  • Встроенная поддержка Chroot
  • И др.

Отключите все неиспользуемые модули

Обычно сборка Apache поставляется с несколькими модулями. Просмотрите документацию о модулях apache, чтобы узнать, что именно делает каждый установленный вами модуль. В большинстве случаев вы обнаружите, что тот или иной модуль вам не нужен.

Поищите строки в файле httpd.conf, содержащие LoadModule. Чтобы запретить загрузку модуля, можно просто добавить # в начале строки. Чтобы найти модули, запустите:

grep LoadModule httpd.conf

Вот некоторые модули, которые обычно включены в установку, но чаще всего не нужны: mod_imap, mod_include, mod_info, mod_userdir, mod_status, mod_cgi, mod_autoindex.

Проверьте, чтобы только администратор (root) имел доступ на чтение конфигурационных и бинарных файлов аpache

Если вы установили apache в директорию /usr/local/apache, то делается это следующим образом:

chown -R root:root /usr/local/apache
chmod -R o-rwx /usr/local/apache

Уменьшите значение Timeout

По умолчанию значение директивы Timeout составляет 300 секунд. Уменьшение этого значения позволяет снизить воздействие потенциальных DoS атак.

Timeout 45

Ограничьте большие запросы

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

Лучше всего начать с директивы LimitRequestBody. По умолчанию ограничение отсутствует. Если вы допускаете загрузку файлов размером не более 1 МБ, установите следующее значение:

LimitRequestBody 1048576

Если вы вообще не разрешаете загрузку файлов, то установите меньшее число.

Некоторые другие директивы, на которые следует обратить внимание это LimitRequestFields, LimitRequestFieldSize и LimitRequestLine. Этим директивам по умолчанию присвоены приемлемые для большинства серверов значения, но более тонкая настройка никогда не помешает. Обратитесь к документации по этим директивам.

Ограничиваем Размер XML Body

Если у вас запущен mod_dav, то вы наверняка захотите ограничить максимальный размер тела XML запроса. Директива LimitXMLRequestBody доступна только на Apache 2, и её значение по умолчанию равно 1 миллиону байт. Во многих руководствах предлагают установить это значение в 0, чтобы можно было загружать файлы любого размера, что в принципе необходимо, если вы используете WebDAV для загрузки больших файлов, но если вы их используете только для контроля исходников, то вам наверняка подойдет значение в 10 МБ:

LimitXMLRequestBody 10485760

Ограничиваем число одновременно выполняемых операций

В Apache есть несколько настроек, которые позволяют изменить число одновременно обрабатываемых запросов. MaxClients - максимальное число дочерних процессов, которые буду созданы для обслуживания запросов. Это значение зависит от объема оперативной памяти вашего сервера.

Другие директивы, такие как MaxSpareServers, MaxRequestsPerChild, а на Apache2 ThreadsPerChild, ServerLimit, and MaxSpareThreads важны и их необходимо настроить в соответствии с вашей операционной системой и аппаратными возможностями.

Ограничиваем Доступ по  IP

Если у вас есть ресурс, который должен быть доступен только определенной сети, или IP адресу, вы можете задать параметры доступа в настройках apache. Например, если вы хотите разрешить доступ вашей внутренней сети 176.16, то пишите следующее:

Order Deny,Allow
Deny from all
Allow from 176.16.0.0/16

Подстраиваем параметры keepalive

Если верить документации по Apache, то использование Keep Alive может улучшить производительность для клиента на 50%, но будьте осторожны перед тем, как изменять эти значения, так как вы можете таким образом увеличить возможность успешного осуществления DoS-атаки.

KeepAlive включен по умолчанию, и отключать его не стоит, но можно и даже нужно поменять значение MaxKeepAliveRequests, что по умолчанию составляет 100, и KeepAliveTimeout, что по умолчанию 15. Проанализируйте ваш журнал регистрации Web сервера, чтобы определиться с оптимальными значениями.

Запускайте Apache в Chroot среде

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

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

SecChrootDir /chroot/apache

Как бы то ни было, вам в любом случае понадобятся более подробные объяснения.

или введите имя

CAPTCHA
1
06-07-2007 21:13:34
тупо, запуск от пользователя "апач", а конфиги принадлежат руту????
0 |
1
07-09-2007 16:28:07
Наркоман??? Вообще-то апач постоянно имеет несколько запущенных процессов и один из них обязательно от рута. Если не секрет, ты под каким пользователем апач устанавливал?? И нахрена тогда люди выдумывают всякие chroot, jail и им подобные?? Если бы всё так просто... Именно поэтому апач прекрасно работает с конфигами заточенными под доступ только руту, при этом людям c не совсем благими намерениями его просто не могут увидеть в силу нехватки прав. Большой минус создателям апача, что при сборке не выставляются подобные права автоматом. Соответсвенно, большой плюс автору за достаточно тонкое замечание неочевидное на первый взгляд. Статья отличная, а линки из неё ещё лучше
0 |
гость 2
18-12-2009 13:10:49
согласен статья написано грамотно, а первый комент просто от незнания
0 |
Какой-то Вася
21-02-2013 23:11:22
Chroot это песочница, из которой злоумышленнику будет невероятно трудно выбраться. Даже если (чисто гипотетически) взломщик сможет пробраться к shell, то чтобы выбраться за пределы chroot ему придётся немало попотеть. Chroot создан не из-за того, что сервер дырявый, а "на всякий случай", чтобы минимизировать ущерб если атаки будут успешны. Даже военный сайт Пентагона взламывали, чтож говорить о простых админах?
0 |