Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

422

Глава 11. Настройка Apache

Инструкции Order и Deny отличаются от тех, что мы видели в предшествую-

щих примерах. В данном случае инструкция Order предписывает серверу

Apache обработать сначала инструкцию Allow, а затем инструкцию Deny.

Это позволяет инструкции Deny изменять правила доступа, созданные инст-

рукцией Allow. Инструкция Allow отсутствует, а инструкция Deny запреща-

ет любой внешний доступ к файлу .htaccess.

В действительности данная инструкция Deny действует не только для фай-

лов .htaccess file. Тильда (~) в строке Files предписывает серверу Apache ин-

терпретировать имена файлов в качестве регулярных выражений. Регуляр-

ное выражение ht отбирает все файлы, имена которых начинаются с по-

следовательности символов . ht. Причиной существования такого определе-

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

файлов настройки httpd со строки . ht: например, файл паролей пользовате-

лей может называться .htpassword. Регулярное выражение вместо имени

файла в строке Files позволяет задействовать правила доступа для широкого

диапазона файлов.

Управление доступом на уровне отдельных документов

Управление доступом к отдельным документам выполняется при помощи

инструкции-контейнера Location. Вместо имени каталога (как в инструкции

Directory) в инструкции Location фигурирует имя документа из URL-адреса.

Инструкции внутри контейнера Location действуют только для указанного

alana:AslrgF/FPQvF6

sara:XsH4aRiQbEzp2

Обратите внимание, что если пароль не указан в командной строке, dbmmanage

предлагает ввести его.

Все приведенные примеры осуществляют управление доступом для отдель-

ных каталогов. Такое же управление доступом может выполняться для всех

каталогов сервера либо отдельных документов. Чтобы задействовать меха-

низмы управления доступом для всех документов сервера, достаточно прос-

то разместить инструкции управления вне контейнера Directory; инструк-

ции управления внутри контейнера Directory действуют на один каталог.

Чтобы задействовать механизмы управления для отдельных файлов или до-

кументов, достаточно поместить соответствующие инструкции внутри кон-

тейнера Files или Document.

Управление доступом на уровне отдельных файлов

В настройках Solaris присутствует пример разграничения доступа к отдель-

ным файлам. Чтобы скрыть файл .htaccess от глаз любопытного клиента,

файл httpd.conf Solaris содержит следующий контейнер Files:

Шифрование

423

документа. В следующем примере правила доступа действуют только для до-

кумента server-status:

SetHandler server-status

Order deny,allow

Deny from all

Allow from wrotethebook.com

L </Location>

Ксли сервер Apache получает запрос по адресу www.wrotethebook.com/server-

utatus, то проверяет возможность доступа по созданным правилам, /server-

ntatus - это имя документа, а не имя каталога. По сути, это специальный до-

кумент, отображающий сведения о состоянии сервера и создаваемый специ-

альным обработчиком. Правила из контейнера Location разрешают просмат-

ривать состояние сервера всем пользователям нашего домена, но запрещают

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

том, как страница server-status используется для наблюдения за состоянием

сервера. Однако прежде чем перейти к этой теме, рассмотрим последний ас-

пект системы безопасности - защиту информации, передаваемой клиентом

серверу.

Шифрование

Описанные в предшествующих разделах механизмы безопасности все до

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

сервер. Однако на сервере лежит еще и ответственность за безопасность дан-

ных клиента. Чтобы создать систему электронной коммерции, необходимо

использовать защищенный сервер, не позволяющий злоумышленникам по-

лучить доступ к личным данным покупателя, в частности к номеру его кре-

дитной карты. Для шифрования сеансов работы, в которых передаются кон-

фиденциальные данные, сервер Apache использует механизм SSL (Secure

Sockets Layer, уровень защищенных сокетов).

В сравнении с механизмами, описанными ранее, SSL и сложнее и надежнее.

Надежнее - потому, что использует шифрование с открытым ключом для ре-

ализации серьезной аутентификации и согласования шифрования в отдель-

ных сеансах. SSL позволяет защищать обмен данными между клиентом и

сервером - посредством их шифрования.

SSL сложнее, поскольку задействует шифрование с открытым ключом.

Шифрование - область в принципе сложная, а шифрование с открытым

ключом - в особенности. Работа шифрования с открытым ключом и, в част-

ности, протокола SSL описана в главе 12. Если вам необходимы дополни-

тельные сведения, прочтите указанную главу, прежде чем включать под-

держку SSL в своем сервере Apache.

Поддержка SSL в Apache реализована модулем mod_ssl. В свою очередь

mod_ssl в работе полагается на библиотеки шифрования, инструменты и ре-

ализации протоколов SSL из пакета OpenSSL. Пакет OpenSSL включен в со-

424

Глава 11. Настройка Apache

став многих систем Linux и некоторых систем Unix. Прежде чем устанавли-

вать mod_ssl, убедитесь в наличии OpenSSL в системе; если пакет отсутству-

ет, скопируйте исходные тексты с сайта http://www.openssl.org. Выполните

программу conf

ig,

поставляемую в комплекте, а затем

make,

чтобы скомпили-

ровать OpenSSL. Выполните make test и make

install,

чтобы установить пакет.

После установки OpenSSL можно устанавливать и модуль mod_ssl. Во мно-

гих системах Linux и некоторых системах Unix mod_ssl является частью ба-

зовой системы Apache. Если для вашей системы это неверно, скопируйте па-

кет mod_ssl с сайта http://www.modssl.org. Повторно скомпилируйте Apache

с ключом —with-ssl, чтобы включить в Apache поддержку расширений SSL.

Установка mod_ssl добавляет в пример файла настройки Apache (обычно он

называется httpd.conf.default) различные строки настройки SSL. Эти новые

строки помещаются внутри контейнеров IfDefine, что позволяет включать

поддержку SSL из командной строки httpd. Система Red Hat, в которой

mod_ssl интегрирован в базовую систему Apache, является хорошим приме

ром такого подхода. Вот контейнеры IfDefine для инструкций mod_ssl Load-

Module и AddModule (система Red Hat):

LoadModule ssl_module modules/libssl.so

</IfDefine>

cifDefine HAVE_SSL>

AddModule mod_ssl.c

</IfDefine>

Инструкции LoadModule и AddModule выполняются только в случае, когда

в командной строке httpd определен символ HAVE_SSL. Строка «НА-

VESSL» является произвольным выбором - в другой системе может ис-

пользоваться просто «SSL». Главное, чтобы эта строка совпадала со значени-

ем, определенным в командной строке httpd. К примеру:

« httpd -DHAVE_SSL

Назначение команды - запустить сервер SSL Apache в системе Red Hat 7.2.

Помимо контейнеров для инструкций LoadModule и AddModule, существует

контейнер IfDefine для специальных настроек сервера SSL. Вот такой кон-

тейнер из файла настройки Red Hat:

Listen 80

Listen 443

</IfDefine>

AddType application/x-x509-ca-cert ,crt

AddType application/x-pkcs7-crl .crl

</IfDefine>

Отличным справочником по компиляции сервера Apache является книга «Linux

Apache Web Server Administration», издательство Sybex.

Шифрование 425

Две строки в первом контейнере IfDefine предписывают серверу принимать

соединения через порт 443, а не только через стандартный порт 80. Порт 443

используется в работе протокола SSL. Две строки во втором контейнере IfDe-

fine связывают файловые расширения .crt и .crl с определенными файловы-

ми MIME-типами. Расширения .crt и .crl относятся к сертификатам SSL.

К сертификатам мы еще вернемся в этой главе.

Основная часть настроек сервера SSL содержится в контейнере VirtualHost.

Данные настройки виртуального узла используются, когда поступает соеди-

нение на порт сервера по умолчанию, SSL-порт 443. Специальный файл жур-

нала позволяет отслеживать SSL-запросы. Инструкции ErrorLog, Transfer-

Log и CustomLog мы уже ранее встречали. Большинство прочих инструкций

настройки действует только при работающей подсистеме SSL:

SSLEngine

Включает обработку SSL для данного виртуального узла.

SetEnvIf

Выполняет, по существу, ту же функцию, что и инструкции Browser-

Match, описанные ранее. В данном примере инструкция SetEnvIf прове-

ряет, является ли User-Agent (броузер) агентом Microsoft Internet Explo-

rer. В случае положительного ответа параметр ssl-unclean-shutdown уве-

домляет Apache, что данный броузер не умеет корректно закрывать со-

единения и что не следует использовать постоянные (keepalive) соедине-

ния при работе с броузером Internet Explorer.

SSLOptions

Определяет значения специальных параметров протокола SSL. В данном

примере разрешены StdEnvVars для каталога /var/www/cgi-bin, равно

как и для всех файлов CGI и SSI. StdEnvVars - это переменные среды, пе-

426 Глава 11. Настройка Apache

редаваемые по соединению клиенту. Извлечение значений этих перемен-

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

случаях, когда клиент способен воспользоваться значениями - как в слу-

чаях сценариев CGI или файлов SSI.

SSLCertificateFile

Указывает на файл, содержащий открытый ключ сервера.

SSLCertificateKeyFile

Указывает на файл, содержащий закрытый ключ сервера.

Шифрование с открытым ключом требует существования двух ключей шиф-

рования: открытого - и доступного всем клиентам, а также закрытого, кото-

рый держится в секрете. Открытый ключ хранится в специальном формате,

известном в качестве сертификата. Прежде чем запускать SSL на сервере,

необходимо создать оба ключа.

OpenSSL предоставляет инструменты для создания открытых и закрытых

ключей SSL. Простейшим из этих инструментов является файл сборки Ма

kefile из каталога ssl/certs

, позволяющий создавать сертификаты и ключи

по команде make. Для создания сертификатов или ключей SSL в make может

использоваться два типа аргументов. В первом типе для определения вида

сертификата или ключа используется расширение файла:

make name, key

Создает закрытый ключ и записывает его в файл пате. key.

make пате.crt

Создает сертификат с открытым ключом и сохраняет его в файле пате. crt.

make name.pem

Создает сертификат и ключ в формате РЕМ (Privacy Enhanced Mail) и со-

храняет результат в файле пате.

рет.

В главе 12 эта команда make использу-

ется в целях создания ключей для программы stunnel.

make пате.csг

Создает запрос на подпись сертификата. Сертификат может получить

цифровую подпись от доверенной инстанции, известной как сертифици-

рующий орган (certificate authority, СА), которая ручается за подлин-

ность открытого ключа, хранимого в сертификате. Подробнее - через не-

сколько абзацев.

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

Ключевые слова позволяют создавать сертификаты и ключи, предназначен-

ные для использования только в Apache:

make genkey

Создает закрытый ключ для сервера Apache. Ключ сохраняется в файле,

на который указывает переменная KEY из файла Makefile.

Путь указан относительно каталога, в котором установлен пакет OpenSSL. В на-

шей системе Red Hat полный путь выглядит так: /usr/share/ssl/certs.

Шифрование

427

make certreq

Создает запрос на подпись сертификата для сервера Apache. Запрос на

подпись сохраняется в файле, на который указывает переменная CSR из

файла Makefile.

make testcert

Создает сертификат для сервера Apache. Данный сертификат может ис-

пользоваться для загрузки и проверки сервера SSL. Однако этот сертифи-

кат не подписан действующим С А и, следовательно, не приемлем для ис-

пользования в сети Интернет. Сертификат сохраняется в файле, на кото-

рый указывает переменная CRT из файла Makefile.

В каталоге /etc/httpd,/conf системы Red Hat существует ссылка на файл

сборки Makefile, облегчающая создание ключей в том месте файловой систе-

мы, где httpd.conf ожидает их найти. Если взглянуть в каталог /etc/httpd/

conf системы Red Hat, мы обнаружим, что ключи, обозначенные инструкци-

ями SSLCertificateFile и SSLCertificateKeyFile, уже существуют, хотя мы их

не создавали.

Для создания сертификатов и ключей Makefile использует команду openssl.

Синтаксис команды openssl сложен и обширен, так что использование файла

сборки приносит реальную пользу. Однако по-прежнему остается возмож-

ность напрямую пользоваться командой openssl, чтобы решать задачи, для

которых не приспособлен файл Makefile. Например, чтобы просмотреть со-

держимое сертификата, который Red Hat поместил в каталог /etc/httpd/

conf, выполните следующую команду:

428

Глава 11. Настройка Apache

Как видите, сертификат содержит большой объем информации. Однако

лишь некоторые его фрагменты необходимы, чтобы определить, является

ли он действительным для нашего сервера:

Issuer

Issuer - это отмеченное имя организации-издателя, которая выдала и

подписала данный сертификат. Отмеченное имя записывается в формате,

спроектированном таким образом, что позволяет обозначать организации

уникальными именами. Очевидно, название организации в данном сер-

тификате - вымышленное, и является всего лишь примером.

Subject

Subject - отмеченное имя организации, получившей сертификат. В на-

шем случае поле Subject должно содержать название нашей организации.

Содержимое поля Subject в данном случае - тоже всего лишь пример.

Validity

Поле Validity содержит сведения о сроках действия сертификата. В дан-

ном случае сертификат действителен в течение года. Указанные даты

позволяют использовать сертификат для тестирования работы SSL.

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

броузером для подключения к локальному серверу. При этом начните URL с

указания протокола https://, а не http://. https позволяет подключиться че-

Шифрование 429

рез порт 443, то есть через порт SSL. Броузер отвечает предупреждением,

что сервером используется недействительный сертификат (рис. 11.4).

Кнопка View Certificate позволяет просмотреть часть той информации о сер-

тификате, с которой мы только что познакомились. Пользователь может

разрешить использование сертификата в данном сеансе и начать работу с

«защищенным документом». В данном случае защищенный документ пред-

ставлен просто тестовой страницей, поскольку мы еще не создали в своей

системе ни одного настоящего защищенного документа.

Сервер запущен и функционирует, но внешние клиенты не смогут работать с

ним, пока мы не получим действительный подписанный сертификат. Для

создания запроса на подпись сертификата вашего сервера воспользуйтесь

командой make certreq. Пример:

# cd /etc/httpd/conf

# make certreq

umask 77 ; \

/usr/bin/openssl req -new -key /etc/httpd/conf/ssl.key/server.key -out /etc/http

d/conf/ssl.csr/server.csr

Using configuration from /usr/share/ssl/openssl.cnf

You are about to be asked to enter information that will be incorporated

into your certificate request.

Рис. 11.4. Предупреждение о недействительном сертификате

430 Глава 11. Настройка Apache

Только что созданный запрос можно просмотреть при помощи команды

openssl. Обратите внимание, что в данном запросе содержится уже действи-

тельное отмеченное имя нашего сервера в поле Subject. Однако отсутствует

информация в поле Issuer. Чтобы сертификат стал действительным, он дол-

жен быть подписан признанным сертифицирующим органом.

Шифрование 431

Сертифицирующие органы работают на коммерческой основе и имеют своей

целью получение прибылей. Чтобы ваш сертификат был подписан, необхо-

димо заполнять формы, платить взносы, а также создать CSR-запрос. Ваш

веб-броузер хранит список признанных сертифицирующих органов. В бро-

узере Netscape 6.1 можно просмотреть этот список в разделе Certificate Ma-

nager меню Preferences (рис. 11.5). Каждый сертифицирующий орган под-

держивает веб-сайт, на котором доступны сведения об оплате и процессе ре-

гистрации.

Хотя сертификаты, подписанные признанным СА, используются наиболее

широко, возможно создание сертификатов с подписью автора. Впрочем, по-

добные сертификаты имеют ограниченную ценность. Как мы видели из

рис. 11.4, сертификат, который не подписан признанным СА, требует под-

тверждения от клиента. Таким образом, подписанные автором сертификаты

могут использоваться только в случае небольшого числа клиентов. Чтобы

Рис. 11.5. Список признанных сертифицирующих органов в Netscape 6.1