Хокинс С. - Администрирование Web-сервера Apache и руководст

8.2.10. Отключение прав пользователей

Опасность возникает, если вы позволите пользователям самим определять собственные права доступа. Кроме того, файлы .htaccess отрицательно влияют на производитель ность. По этой причине директивы AllowOverrides должны быть установлены в None.

AllowOverrides None

8.2.11. Кодировка конфиденциальных данных

Независимо от того, насколько безопасна ваша система, конфиденциальные данные (информация о кредитных карточках, персональная информация) нельзя хранить на ком пьютере, доступном для внешнего мира. Я рекомендую, особенно в случае хранения ин формации о номерах кредитных карточек, удалять или кодировать все хранимые вами данные. Программное обеспечение, предназначенное для кодирования данных, можно по лучить бесплатно на Web узле http://www.mit.edu/network/pgp.html.

8.3. Основы идентификации

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

8.3.1.Идентификацияпоузлу:модульmod__access

Модуль mod_acccess по умолчанию включен в стандартный дистрибутив. С его помощью реализован элементарный контроль доступа. Он заключается в возможности предоставлять права доступа на основании информации об узле, с которого поступает запрос на доступ. Узлы и домены могут задаваться как с помощью IP адреса, так и с помощью имени.

8.3.2. Директива order

Директива order предназначена для определения порядка, в соответствии с кото рым сервер Apache будет оценивать директивы deny и allow. Допустимые значения перечислены в табл. 8.1.

Таблица 8.1. Значения директивы order

8.3.3. Директива allow

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

Чтобы санкционировать доступ к каталогу /some/directory всем, кто этого захо-

чет, необходимо задать директиву.

<Directory /some/directory> allow from all

</Directory>

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

Для разрешения доступа к каталогу /some/directory всем пользователям из домена asgard.com достаточно следующих команд:

<Directory /some/directory> order deny, allow deny from all

allow from .asgard.com </Directory>

Санкционировать доступ можно на основании информации о подсети. Сервер Apache будет просматривать подсеть слева направо, начиная с самого левого октета. Например, чтобы разрешить доступ к каталогу /some/directory всем членам подсети 192.168.100, необходимо указать:

8.3.4. Директива allow from env

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

BrowserMatch ^Mozilla netscape_yes <Directory /opt/apache/htdocs >

order deny, allow deny from all

allow from env=netscape_yes </Directory>

Кроме того, переменную окружения можно установить директивой SetEnviIf для последующего использования ее в директивах allow from env и deny from env.

8.3.5. Директива deny

Варианты синтаксиса переменной deny (IP адрес, домен, частичный IP адрес, час тичный домен, слово all) подобны аналогичным конструкциям в директиве allow. Достаточно посмотреть на примеры, приведенные в отношении директивы allow.

8.3.6. Директива deny from env

Аналогично тому, как доступ может быть санкционирован на основании существо вания какой то переменной окружения (см. директиву allow from env), в доступе может быть отказано на основании значения той же самой переменной окружения.

8.4. Идентификация по пользователю

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

Независимо от выбранного метода идентификации директивы AuthName и AuthType всегда необходимы.

8.4.1. Обозначение запретной области: директива AuthName

Все механизмы идентификации используют директиву AuthName для указания ка талога, доступ к которому требуется контролировать. Указанный вами текст будет включен во всплывающее окно, которое появляется на экране. Например, чтобы включить в окно слова "Restricted Site", воспользуемся следующей директивой:

AuthName "Restricted Site"

8.4.2. Ограничение доступа: директива require

Большинство из модулей управления доступом используют директиву require. Чтобы просто включить управление доступом на основании комбинации идентификатора пользо вателя и пароля, в это й директиве можно использовать ключевое слово valid user.

require valid user

С другой стороны, можно задать перечень пользователей, которым будет разрешен доступ (после проверки их прав).

require valerie joey bobby

Кроме того, можно реализовать доступ пользователям по принадлежности к опре деленной группе пользователей. Для этого необходимо с помощью директивы Auth GroupFile создать группу и разрешить доступ пользователям по принадлежности к определенной группе. Предположим, что Valerie, Joey и Bobby известны вместе как группа mathdept. Если это так, то директива

require mathdept

будет иметь действие, аналогичное предыдущему примеру. Как задать группу, можно посмотреть в описании директивы AuthGroupFile, которое следует ниже.

8.4.3. Определение метода идентификации: директива AuthType

Директива AuthType имеет один параметр, определяющий тип идентификации (basic или digest). Параметр basic (основной) означает, что пароль будет передан от клиента на сервер в виде текстовой информации. Очевидно, что при этом возника ет угроза безопасности. Такая идентификационная информация может быть перехва чена на пути следования.

Другой вариант идентификации — digest (цифровой) — позволяет воспользовать ся кодировкой MD5 для шифровки передаваемых пакетов. К сожалению, его исполь зование ограничено тем, что этот тип идентификации поддерживается не всеми типа ми броузеров.

Чтобы задать первый тип идентификации, можно воспользоваться директивой:

AuthType basic

8.4.4. Модуль mod_auth

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

8.4.5.Создание файла идентификации с помощью команды htpasswd

Перед использованием модуля mod_auth необходимо создать файл паролей та ким образом, чтобы у модуля была информация, с которой можно сравнить реги страционные данные. Стандартный дистрибутив сервера Apache включает испол няемый файл htp asswd, функции которого заключаются только в этом. Вот син таксис работы с ним:

htpasswd с passwordfile username

Здесь опция с означает, что требуется создать новый файл паролей. Аргумент username является обязательным. Программа htpasswd работает в интерактивном режиме. Она выдает подсказку о необходимости ввода и проверки пароля:

/etc/security> htpasswd с local__passwd userguy Adding password for userguy.

Newpassword:

Re type new password: /etc/security>

Введенный пароль будет зашифрован с помощью функции crypt() и сохранен вместе с текстовым именем пользователя в указанном вами файле паролей. Если нужно добавить только нового пользователя в уже существующий файл паролей, оп цию с можно пропустить.

8.4.6.Включение режима контроля доступа: директива AuthUserFile

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

AuthUserFile /etc/security/local_passwd

8.4.7. Контроль за групповым доступом: директива AuthGroupFile

Для уменьшения списка пользователей в директиве require можно воспользоваться возможностью санкционирования группового доступа. Это файл, строки которого содер жат имя группы, двоеточие, за которым следует перечень пользователей, разделенный за пятыми. Для того, чтобы сервер Apache знал о том, что файл grouplist размещается в каталоге /etc/security, воспользуемся следующей директивой:

AuthGroupFile /etc/security/.grouplist

Теперь вместо перечня имен пользователей в директиве require можно восполь зоваться именами групп, перечисленными в этом файле.

8.4.8.Передача управления модулю нижнего ранга: AuthAuthoritative

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

AuthAuthoritative off

8.4.9. Все виды контроля одновременно: пример модуля mod_auth

Напомним, что все методы санкционирования доступа требуют использования ди ректив AuthName и AuthType и что модуль mod_auth также требует некую форму ди рективы require. Вот пример, вкотором доступ к узлу www.site2.com будет ограни чен для всех пользователей, кроме тех, кому доступ разрешен.

<Directory /home/site2>

AuthName "Example of Access Control" AuthType Basic

AuthUserFile /etc/security/.htpasswd Require valid user

</Directory>

1 Ранг определяется порядком следования в конфигурационном файле.

Напомним, что путь /home/site2 для узла www.site2.com является каталогом DocumentRoot. Когда пользователи пытаются получить доступ к узлу www. site2.com, они видны на экране, изображенном на рис. 8.1.

Рис. 8.1. Экран управления доступом модуля mod_auth

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

Рис. 8.2. Стандартное сообщение об ошибке

Замечу, что экран, который вы видите на этом рисунке, является стандартным эк раном, сообщающим о неудачной попытке доступа. Его можно видоизменить с по мощью директивы errordocument.

ErrorDocument 401 /site_error.html

8.4.10. Модуль mod_auth_dbm

Как отмечалось ранее, основное различие между модулями mod_auth_* за ключается в способе хранения пароля. Напомним, что модуль mod_auth исполь зует в своей работе простой текстовый файл, хранящий имена пользователей и закодированные пароли, известный на профессиональном жаргоне как плоский файл. Этот метод хранения предполагает, что сервер Apache производит поиск файла по дереву сверху вниз всякий раз, когда требуется идентифицировать поль зователя. Такой метод вполне подходит для осуществления поиска в небольших базах данных, но будет значительно влиять на производительность, если количе ство идентифицированных пользователей превысит определенный показатель.

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

8.4.11.Создание индексированной базы данных: директиваdbmmanage

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

dbmmanage filename [command] [username],

где command — одна из команд перечисленных в табл. 8.2.

Таблица 8.2. Команды утилиты dbmmanage

Например, чтобы добавить пользователя usertwo в базу данных dbm, находящуюся в каталоге /etc/security/httpdbase, необходимо задать команду

dbmmanage /etc/security/httpdbase adduser usertwo

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

8.4.12.Включениережимаконтролядоступаспомощью базыданныхDBM:директиваAuthDBMUserFile

После создания базы данных DBM необходимо указать ее место нахождения для сервера Apache. Абсолютный путь к базе данных DBM можно задать с помощью ди рективы AuthDBMUserFile.

AuthDBMUserFile /etc/security/httpdbase

8.4.13. Директива Auth_Dbm_Authoritative

Директивой AuthDbmAuthoritative в качестве последней инстанции в управле нии доступом для определенного каталога задается модуль mod_auth_dbm.

AuthDbmAuthoritative on

8.4.14. Директива AuthDbmGroupFile

Как и mod_auth, модуль mod_auth_dbm имеет механизм объединения наборов пользователей в группы. Файл групп DBM содержит список пользователей, разделен ных запятыми.

8.4.15. Модуль mod_auth_db

Еще одним из идентификационных модулей является модуль mod_auth_db. Он работает с DB файлами стандарта Беркли и содержит информационные пары пользо ватель пароль. Если ваша система не поддерживает стандарт DBM, он может быть единственным возможным вариантом. Директивы, связанные с этим модулем, рабо тают точно таким же образом, как директивы модуля mod_auth_dbm, и не требуют дополнительных объяснений. Приведем простой перечень.

8.4.16. Модуль mod_auth_anon

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

8.4.17.Определение действующих пользователей: директива Anonymous

Как упоминалось ранее, обобщающее имя пользователя, под которым возможен анонимный доступ, является имя "anonymous". Менее популярное, но время от времени появляющееся имя "guest". Установка анонимного доступа для пользователя с другим именем, вероятно, сильно огорчит завсегдатаев Internet. Чтобы гарантировать аноним ный доступ псевдоидентификаторам "anonymous" и "guest", необходимо ввести:

Anonymous anonymous guest

8.4.18. Регистрация доступа: директива Anonymous_LogEmail

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

Anonymous_LogEmail.

Anonymous_LogEmail on

8.4.19.Как заставить пользователей вводить какую нибудь информациюприрегистрации:директива

Anonymous_MustGiveEmail

Чтобы заставить пользователя при регистрации вводить электронный адрес вместо пароля, установите значение этой директивы в on. Однако прислушайтесь к совету: нет способа гарантировать, что пользователь ввел реальные или хотя бы правильно отформатированные данные.

Anonymous_MustGiveEmail on

8.4.20.Патетическое извинение по поводу проверки формата: директива Anonymous_VerifyEmail

Чтобы проверить, что пользователем были введены как минимум символы "@" и ".", воспользуйтесь директивой.

Anonymous_VerifyEmail on

8.4.21. Директива Anonymous_NoUserlD

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

Anonymous_NoUserID on

8.4.22. Директива Anonymous_Authoritative

Установка этой директивы в состояние on соответствует ситуации, когда для рас сматриваемого каталога возможно применение другого механизма управления досту пом. Последнее слово в управлении доступом остается за модулем mod_auth_anon.

Anonymous_Authoritative on

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

Anonymous_Authoritative off

8.5. Протокол SSL

Протоколы передачи данных TCP/IP создавались с целью обеспечения надежного механизма передачи данных. В этом направлении разработчики создали достаточно интеллектуальные механизмы маршрутизации, способные из множества путей из точ ки А в точку В выбрать наиболее оптимальный в данный момент путь. Следовательно, не существует способа предсказать маршрут, которым передаваемые пакеты достигнут пункта назначения. С точки зрения безопасности вполне можно предположить, что все пакеты накапливаются и собираются произвольным количеством умных негодяев, лелеющих надежду приобрести стимуляторы или детскую порнографию за ваши деньги. Совершенно очевидно, что такое положение вещей неприемлемо.

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

Sockets Layer или SSL. Протокол SSL был создан компанией Netscape Corporation как

средство поддержки электронной коммерции. В нем применяется система шифрования

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

Возможность безопасной передачи информации по мировой сети является крити ческом моментом для электронной коммерции и может пригодиться для многих дру гих Web приложений. Может возникнуть вопрос, почему возможность работы с про токолом SSL не включена в стандартный дистрибутив Apache. Такая ситуация сложи лась в результате позиции правительства США по этому вопросу. Во времена холодной войны было принято законодательство, запрещающее экспорт шифроваль ных технологий за пределы США. Даже в пределах США публикация статей или книг, посвященных шифровальным технологиям, была ограничена. Во времена учебы в колледже (1987 1993) я взялся за написание научной статьи, посвященной проблеме шифрования, и был немало удивлен, обнаружив, как мало было доступной информа ции, посвященной данной теме. Помогли только архивы университетской библиоте ки2. В 1994 году мною была найдена маленькая книжка по криптографии, изданная примерно в 1950 году в одном сельском колледже в штате Джорджия.

Несколькими месяцами позднее я с удивлением столкнулся с популярным теперь изданием "Прикладная криптография" Брюса Шейнера ("Applied Cryptography" Bruce Schemer). Очевидно, что при том общественном интересе, который поднялся на волне развития Internet, больше невозможно было держать такие книги на полке3. Несмотря на то, что свобода печати распространяется на все, что напечатано на бумаге (включая твердые копии криптографического программного обеспечения), она не затрагивает само программное обеспечение. В Соединенных Штатах передача криптографиче ского программного обеспечения за рубеж по прежнему является преступлением, и, как видно по делу Фила Циммермана (Phil Zimmerman)4, нарушителей этого закона ожидает очень жесткое наказание. Кроме всего прочего, некоторые механизмы, при мененные в протоколе SSL, запатентованы. Потому включение протокола SSL в дист рибутиве Apache может привести к серьезным противоречиям с законом.

8.5.1. Шифрование с открытым ключом

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

2 Совершенно серьезно. Ни статей, ни книг, ничего даже похожего на обычные ссылки. Смутно припоминаю, что я прочитал в статье, посвященной стандарту шифрования данных (который в те времена использовался банками при кодировке фондовой информации для передачи ее в электрон ном виде), что Управление национальной безопасности препятствовало публикации материалов та кого типа. К сожалению, мне не удалось найти первоисточник, на который тогда делалась ссылка, и теперь даже не могу сказать с полной уверенностью, читал я это или это мне показалось. Если вам встречалась такая информация, напишите, пожалуйста, мне об этом.

3 Вот интересный факт, касающийся этой книги. "Прикладная криптография" ("Applied Cryptography") является бестселлером № 13 в Чешской Республике и № 6 в Венгрии, следуя в местном рейтинге сразу же за изданием "Руководство современной домохозяйки по обогащению ядерного топлива" ("The Modern Housewife's Guide to Refining Fissionable Material").

4 Фил Циммерман разработал PGP и разместил его в Internet, предоставив возможность ко пировать иностранцам.