Укрепление защиты сервера Apache

Apache является наиболее популярным сервером Web в мире. При тщательной конфигурации его можно сделать и самым защищенным.

Apache был назван так потому, что он представлял собой исправление (patch) реализации HTTP, сделанной Национальным центром суперкомпьютерных приложений (National Center for Supercomputing Applications, NCSA). По имеющимся оценкам, Apache используется на более чем шести миллионах узлов Web, как коммерческих, так и образовательных.

По данным недавнего исследования Netcraft, серверы Apache составляют около 60% всех используемых сегодня серверов Web. Второе место со значительным отставанием — ему принадлежит 20% рынка — занимает Internet Information Server компании Microsoft. Apache Software Foundation продолжает активно развивать свой полнофункциональный сервер HTTP и по-прежнему предоставляет его в виде исходных кодов. Вместе с тем, компания уделяет большое внимание обеспечению столь необходимой для крупных предприятий защиты.

Гибкость Apache позволяет основной команде разработчиков быстро реализовать новые функции и усовершенствования. Таким образом, им удается создавать продукт, намного более быстрый и эффективный, чем большинство его конкурентов (включая коммерческие продукты). Вместе с тем, не обойдется ли «бесплатность» слишком дорого, когда дело касается защиты? Подобные опасения безосновательны. Непредубежденный администратор сети незамедлительно признает преимущества выбора платформы, прошедшей полевые испытания на шести миллионах серверов Web и выполняющейся на 17 операционных системах.

Однако вопрос по-прежнему остается: насколько надежен Apache по сравнению с другими серверами HTTP? Ответ на него чрезвычайно прост: Apache можно сделать наиболее защищенным сервером, и в этой статье мы рассмотрим, как этого добиться. Заметим только, что мы сосредоточимся исключительно на версии Apache для UNIX. Отметим также, что версия для Windows NT не достигла еще уровня зрелости версии для UNIX.

БАЗОВАЯ КОНФИГУРАЦИЯ APACHE

Вы приняли решение: ваша компания готова окунуться в море открытого программного обеспечения (Apache предоставляет отличную возможность для этого), и вам предстоит загрузить последнюю стабильную версию с дистрибутива. Однако, прежде чем устанавливать программное обеспечение, вам необходимо продумать три вопроса: контроль доступа, идентификацию и конфиденциальность.

Во-первых, определите, будет ли ваш узел Web открыт для неограниченного доступа извне? Будет ли необходимо ограничить доступ к какой-либо части информационного наполнения (возможно, предоставить его только заказчикам или партнерам по бизнесу)? Будет ли доступ разрешаться в зависимости от местонахождения браузера Web (например, на основе IP-адреса клиента) или личности обращающегося к узлу человека?

Во-вторых, решите, как вы собираетесь идентифицировать своих пользователей? При помощи комбинации имя/пароль? Собираетесь ли вы использовать мощные средства идентификации, такие, как цифровые сертификаты?

В-третьих, подумайте, собираетесь ли вы продавать товары или услуги на своем узле? Надо ли будет вводить секретную информацию для навигации по вашему узлу? Если да, то вам, вероятно, потребуется защитить обмен по HTTP с помощью мощных протоколов шифрования (и идентификации), таких, как Secure Sockets Layer или Transport Layer Security (TLS).

КОНТРОЛЬ ДОСТУПА

Как и в случае любого другого сетевого сервиса, сервер Apache должен быть сконфигурирован, исходя из установки по умолчанию на отказ во всяком доступе. Сервисы следует предоставлять на индивидуальной, избирательной основе. Это достигается посредством внесения следующей записи в файл access.conf:

Deny from all
AllowOverride None

Директива Deny from all запрещает всякий доступ к вершине дерева информационного наполнения Apache, между тем как директива AllowOverride None запрещает использование альтернативных методов идентификации и контроля доступа внутри указанных каталогов.

Для начала мы откроем доступ к общедоступной части узла Web:

Allow from all

Далее мы создадим закрытую область в дереве информационного наполнения, доступ к которой будет разрешен только сотрудникам компании.

Allow from .company.com

Директива Allow from .company.com сообщает Apache о необходимости осуществить обратный поиск по DNS для нахождения IP-адреса клиента Web. Доступ будет предоставлен, только если имя хоста принадлежит к домену company.com. Прежде чем вводить директиву, не помешает убедиться, что в DNS у вас имеются записи обратных преобразований PTR (Reverse Pointer Record) для всех клиентов. Синтаксис предусматривает возможность указания отдельных IP-адресов, неполных IP-адресов и комбинации адрес/маска:

Allow from 10.10.10.1
Allow from 20.20.20.
Allow from 30.30.30.0/24

Помимо директивы Allow from сервер Apache поддерживает и директиву Deny from, а также возможность контроля за порядком проверки обеих директив. Рассмотрим два следующих примера:

Order deny,allow
Deny from 10.10.10.0/24
Allow from 10.10.10.1



Order allow,deny
Allow from 10.10.10.0/24
Deny from 10.10.10.1

В первом примере Apache проверяет операторы Deny from прежде операторов Allow from (такой порядок принят по умолчанию). Таким образом, исходной установкой является «допуск всех», после чего весь блок адресов 10.10.10.0 класса C получает отказ в доступе, за исключением хоста 10.10.10.1.

Наконец, вам может потребоваться предоставить пользователям возможность контроля за доступом к их собственным документам.

AllowOverride AuthConfig Limit
Allow from all

Обратите внимание, что такая конфигурация позволяет пользователю отменить принятую по умолчанию политику доступа посредством введения собственных правил идентификации пользователей (AuthConfig) и контроля доступа в зависимости от хоста (Limit).

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

ИДЕНТИФИКАЦИЯ

Администраторы сетей часто сталкиваются с необходимостью предоставить доступ к закрытым ресурсам Web заказчикам и партнерам по бизнесу, вне зависимости от местонахождения используемого браузера Web. Реализация такой возможности предполагает использование для идентификации пользователей дискреционных средств, таких, как комбинация «имя пользователя/пароль».

Apache поддерживает директивы идентификации пользователей c использованием ряда форматов файлов паролей. Входящий в дистрибутив Apache каталог ~bin содержит утилиту htpasswd, которую администраторы и пользователи могут использовать для работы с файлами паролей.

Например, непривилегированный пользователь может защитить с помощью пароля подкаталог в /export/home/username/public_html, создав файл .htaccess со следующим набором директив:

AuthType Basic
AuthUserFile .user-list
AuthName «Private Information»
Require valid-user

Директива AuthType сообщает, что пользователь хочет производить простую идентификацию с помощью паролей для пользователей из файла паролей .user-list. Переменная AuthName указывает на «область», используемую идентификационными модулями Apache концепцию для ссылки на соответствующие ресурсы (каталог). (Саму концепцию модулей мы рассмотрим немного ниже.) Наконец, директива Require определяет домен тех пользователей, кому разрешен доступ к этому ресурсу. В данном конкретном случае valid-user относится к любому имени пользователя, имеющемуся в файле паролей.

При такой конфигурации у пользователей Web-клиентов при каждом обращении к данному каталогу будет запрашиваться имя и пароль. Запрос представляет собой всплывающее текстовое окно в браузере Web.

% htpasswd -c .user-list firstuser

Здесь firstuser — первый включенный в файл пользователь (утилита htpasswd попросит ввести для него действительный пароль). После создания файла последующих пользователей можно ввести следующим образом:

% htpasswd .user-list newuser

Обратите внимание, что я намеренно выбрал для файла паролей имя UNIX с точкой вначале, так как такой файл не отображается при обычных командах листинга каталога. Важно помнить, что браузер передает имя пользователя и пароль открытым текстом, поэтому они могут быть перехвачены (подсмотрены).

Архитектура HTTP-сервера Apache опирается на концепцию «модулей» — отдельных функциональных блоков, взаимодействующих с ядром Apache с помощью специальных API. Благодаря такой архитектуре пользователи и независимые разработчики могут легко расширить функциональность сервера, написав свои собственные модули и скомпилировав их в исходном дереве Apache.

Рисунок 1. Модули защиты Apache обеспечивают контроль доступа и идентификацию при работе с сервером HTTP.

Следующие модули защиты включены в стандартный дистрибутив Apache и отвечают за контроль доступа и идентификационные сервисы для сервера Apache (см. Рисунок 1).

Модуль mod_access осуществляет контроль за доступом к серверу конкретных хостов. Он предоставляет доступ в зависимости от IP-адреса (номера сети) источника запроса.

Контроль за идентификацией пользователей и групп осуществляется mod_auth, для этого модуль использует обычные текстовые файлы паролей и групп. Модули mod_auth_db и mod_auth_dbm обеспечивают идентификацию с использованием файлов паролей в стиле Berkeley-DB и DBM, соответственно.

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

ЗАЩИТА СЕРВЕРА APACHE

Активизировать исполняемые программы Apache должен пользователь с правами root, но при этом сами процессы не должны выполняться с полномочиями root. Основной конфигурационный файл Apache (httpd.conf) всегда должен содержать строки User nobody и Group Nobody.

Далее, вам необходимо добавить пользователя с именем http в /etc/passwd и группу с тем же именем в /etc/group. Это позволит изменить владельца дерева информационного наполнения Apache на заданную комбинацию «имя пользователя/группа»:

% chown -Rh http:http 
/usr/local/apache/share

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

Как и в случае любого другого сервера Internet, здравый смысл диктует необходимость блокирования всех ненужных сетевых сервисов и включения в файл /etc/passwd только тех пользователей, кому необходим интерактивный доступ к серверу. Кроме того, я бы не советовал использовать один и тот же хост в качестве сервера HTTP и ftp. Создать совместимую структуру файлов информационного наполнения для обоих этих сервисов часто оказывается весьма непросто, а подобная конфигурация может вести к возникновению уязвимых мест, особенно со стороны HTTP.

ПОТЕНЦИАЛЬНО УЯЗВИМЫЕ МЕСТА

Недавний всплеск распределенных атак по типу «отказ в обслуживании» (Distributed Denial of Service, DDoS) выявил внезапный рост осведомленности в защите Web. По иронии судьбы, эти атаки обычно организуются на сетевом уровне, так что разработчики сетевых приложений мало что могут сделать для их предупреждения.

Однако одна из разновидностей атак DoS направлена непосредственно против самого сервера HTTP, в частности ей может подвергнуться и сервер Apache. Эта атака проводится посредством запроса специально (и обычно неправильно) составленного объекта HTTP с сервера. Симптомами такой атаки являются, как правило, необычайно высокий уровень загруженности процессора и памяти, неконтролируемое ветвление процессов и общее отсутствие реакции на поступающие запросы HTTP.

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

В отличие от атак DDoS, переполнение буфера можно предотвратить, периодически просматривая рекомендации CERT на http://www.cert.org и устанавливая соответствующие заплаты сразу же после их появления.

Потенциально наиболее опасным типом постороннего вмешательства является компрометация root. В этом случае атакующий пытается получить (привилегированные) полномочия root и, потенциально, установить контроль за всем хостом. Наиболее часто компрометация root происходит тогда, когда сервер Apache запускается (и продолжает выполняться) с пользовательским именем root. Последствия этого очевидны: удаленный пользователь может выполнять сценарии CGI так, как если бы они выполнялись локально пользователем root.

К компрометации root может привести следующая небольшая оплошность при конфигурации, а именно непреднамеренная привязка дерева информационного наполнения Apache к корневому каталогу системы:

% ln -s / public_html

Для получения неограниченного доступа ко всей файловой системе злоумышленнику будет достаточно указать в своем браузере URL http://localhost/~root/.

Этого можно легко избежать, поместив следующую запись в файле access.conf:

Deny from all
AllowOverride None

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

Другая потенциальная опасность связана со сценариями CGI. Сегодня сценарии CGI имеются практически на каждом узле Web, поскольку они предоставляют пользователям инструмент для интерактивного взаимодействия с сервером. По самой своей природе сценарии CGI подвергают защиту серьезному риску, однако этот риск можно свести к минимуму, если следовать следующим простым рекомендациям.

Прежде всего убедитесь, что сервер Apache выполняется без полномочий root. Далее, ограничьте все сценарии CGI одним конкретным каталогом. Это упростит контроль за ними. Затем проверьте, что дерево CGI не содержит записываемых файлов. Злоумышленники могут использовать их для создания и выполнения своих собственных сценариев. Наконец, предоставьте пользователям «безопасные» шаблоны CGI. Если им приходится самим изобретать велосипед, то весьма велика вероятность того, что в результате они допустят какую-нибудь чреватую неприятными последствиями для защиты ошибку.

Другим потенциально уязвимым местом Apache являются Server-Side Includes (SSI). SSI — это расширения HTML для реализации таких возможностей, как информационное наполнение реального времени (например, текущее время и дата) и выполнение внешних программ в зависимости от условий. Именно последний тип SSI создает проблемы для большинства администраторов. Подумайте об использовании в access.conf директивы Options IncludesNoExec, полностью запрещающей исполнимые SSI.

ЖУРНАЛЫ APACHE

Apache имеет весьма развитые средства протоколирования. С их помощью администраторы могут вести учет как вполне безобидных событий (таких, как успешный доступ), так и ошибочных и потенциально опасных действий. Я рекомендую регулярно просматривать следующие два журнальных файла — access_log и error_log.

Первый, access_log, содержит записи обо всех запросах на установление соединения с сервером HTTP. Записи имеют следующий общий формат:

remote_host remote_usertime_stamp 
request_type request_status

Например, следующая запись сообщает о попытке пользователя с IP-адресом клиента 10.20.3.4 обратиться к недоступному для Apache файлу (например, /etc/passwd):

10.20.3.4 - -
[08/Mar/2000:22:00:41 -0500] 
?GET /etc/passwd HTTP/1.0? 404 139
10.20.3.4 - -
[08/Mar/2000:22:00:45 -0500] 
?GET /etc/shadow HTTP/1.0? 404 139

Периодический поиск всех записей с кодом ошибки 404 («Файл не найден») может помочь выявить потенциальных злоумышленников, занимающихся поисками незащищенных ресурсов Web.

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

time_stamp error_type client_id
 error_description

Вот пример записи из error_log:

[Sat Apr 8 00:22:56 2000]
[notice] httpd: caught SIGTERM,
shutting down
[Sat Apr 8 00:22:59 2000]
[notice] Apache/1.3.12 (Unix)
configured — resuming normal operations
[Sat Apr 8 00:23:02 2000] [warn]
pid file /usr/local/apache/var/
run/httpd.pid overwritten -
Unclean shutdown of previous apache run?

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

/usr/local/apache/etc/access.conf
/usr/local/apache/etc/httpd.conf
/usr/local/apache/etc/srm.conf

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

APACHE И SSL

С появлением электронной коммерции вопрос конфиденциальности тут же вышел на передний план. В ответ на эту потребность появилось сразу несколько протоколов, наиболее популярным из которых является спецификация Secure Sockets Layer (SSL), разработанная Netscape Communications.

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

Такого рода жесткая идентификация предполагает цифровую подпись открытых ключей сервера заслуживающей доверия организацией (так называемым сертификационным центром — Certification Authority, CA). Браузер может взять этот цифровой сертификат и сравнить его подпись с общеизвестным открытым ключом CA. Браузеры и Netscape и Microsoft поставляются с уже загруженными открытыми ключами целого ряда CA, так что процедура идентификации может быть начата, по сути, немедленно.

Наиболее широко используемый в стандарте SSL алгоритм с открытыми ключами базируется на разработке компании RSA Security, держателе патента на алгоритм в Соединенных Штатах. Это негативно сказывается на возможности создания полностью функциональной связки HTTP-SSL для свободного распространения в США. Однако два таких предложения имеются за пределами Соединенных Штатов. Кроме того, по крайней мере два коммерческих сервера HTTP-SSL включают лицензию RSA, благодаря чему они могут использоваться во всем мире.

Apache-SSL — это бесплатное программное обеспечение, разработанное и распространяемое Беном Лори из Великобритании. Его предложение базируется на стандартном дистрибутиве Apache с добавлением библиотеки OpenSSL для обработки цифровых сертификатов, открытых ключей и шифрования информационного наполнения.

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

Apache-SSL можно пользоваться бесплатно как в некоммерческих, так и в коммерческих целях, оно предоставляет мощные средства шифрования (со 128-разрядным ключом) во всем мире (однако пользователям из Соединенных Штатов придется компилировать исходный код с более медленной библиотекой RSAREF, которую RSA Security бесплатно распространяет для некоммерческого использования). Если вы опасаетесь доверять свой узел Web некоммерческому программному обеспечению, то разработчики предлагают платную поддержку как для Apache, так и Apache-SSL.

Рисунок 2. Mod_ssl реализует расширение SSL в виде внешнего модуля.

Бесплатное программное обеспечение Mod_ssl было написано Ральфом С. Энгельсхаллом в апреле 1998 г. Частое путаемое с Apache-SSL (производной которого оно является), Mod_ssl представляет собой интерфейс Web к чрезвычайно популярной реализации OpenSSL Эрика Янга и Тима Хадсона. В своем творении разработчик воспользовался преимуществами модульной архитектуры Apache и реализовал расширение SSL в виде внешнего модуля для стандартного исходного дерева Apache (см. Рисунок 2). Как и Apache-SSL, Mod_ssl предлагается на условиях стандартной лицензии Berkeley Software Distribution (BSD), так что оно бесплатно доступно как для некоммерческого, так и для коммерческого использования.

Если вам больше нравится коммерческое ПО, то весьма качественный продукт предлагает C2Net Software. Ее Stronghold имеет мощные средства шифрования со 128-разрядным ключом и включает полную лицензию RSA, так что он может использоваться по всему миру. Это на настоящий момент наиболее широко распространенный мощный сервер SSL на базе Apache. Он поставляется с сертификатом, подписанным Thawte Digital Certificate Services.

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

Аналогичное предложение есть у iPlanet. Ее Web Server, Enterprise Edition, является наследником Netscape Enterprise Server (iPlanet — это альянс, созданный Netscape и Sun Microsystems). Enterprise Edition выполняется на UNIX (на большинстве платформ) и Windows NT и, в отличие от Stronghold, не опирается на исходную архитектуру Apache. Этот продукт имеет множество возможностей, в том числе поддерживает аппаратные ускорители SSL независимых поставщиков — потенциально полезная возможность для узлов электронной коммерции с большим объемом транзакций. Сервер можно сконфигурировать удаленным и притом защищенным образом из любого браузера Web, если он поддерживает протокол SSL.

ПОПУЛЯРНЫЙ И ЗАЩИЩЕННЫЙ

HTTP-сервер Apache на практике доказал, что он является эффективной платформой с крепким основанием. Архитектура сервера Apache выдержала испытание временем, и он по-прежнему остается единственным предложением в своем классе, если речь идет о создании и развертывании недорогого сервера HTTP с надежной защитой.

Как и в случае многих других серверов Internet (как коммерческих, так и бесплатных), пользователям следует быть в курсе последних выявленных уязвимых мест и позаботиться о конфигурации и функционировании сервера в соответствии с принятой в компании политикой защиты. При тщательном контроле и разумной конфигурации самый популярный в мире сервер HTTP будет и самым защищенным.

Ресурсы Internet