Все, что нужно знать про Apache Basic authorization. Простое ограничение доступа по паролю

Первое, что я попытался сделать – это использовать модуль Apache authnz_ldap_module, по использованию которого в интернете полно информации. Сначала я столкнулся с тем, что авторизация не проходит и сервер отвечает на запрос страницы внутренней ошибкой. Немного покопавшись я сообразил, что все дело в кодировках: локаль у меня koi8-r, а в AD используется, как известно, utf8. Набросав небольшой скрипт на perl, я перевел конфиг Apache в кодировку utf8. После этой операции я смог авторизовать любого пользователя домена (Require valid-user), конкретного пользователя домена (Require ldap-user), но почему-то не смог авторизовать по группе. Потратив n-ное количество времени я понял, что пользователь должен находится в том же OU, что и группа. Это меня очень удивило, так как не совсем понятно, зачем нужна такая странная авторизация. Может я что-то делал не правильно, но в итоге решил отказаться от использования модуля authnz_ldap_module и сделать авторизацию приблизительно на такой же основе, как и авторизацию Squid, используя Samba и модуль auth_ntlm_winbind_module.

Сразу скажу, что готового пакета под FreeBSD я не нашел и пришлось пользоваться тем, что нашлось на просторах интернета, но об этом ниже.

Для успешного разрешения задачи мне понадобилось установить из портов Apache, heimdal, Samba 3 и найти в интернете архив с модулем auth_ntlm_winbind_module. Итак, по порядку.

Первое – это установка Apache. В этом нет ничего сложного и ужасного, особенно при установке портов: make config и make install clean.

Теперь производим манипуляции с конфигурационными файлами. Сначала разберемся с Kerberos, создав файл /etc/krb5.conf, заполнив его приблизительно следующим содержимым:

ticket_lifetime = 24000
default_realm = DOMAIN.RU
dns_lookup_realm = false
dns_lookup_kdc = false

DOMAIN.RU = {
kdc = server1.domain.ru:88
kdc = server2.domain.ru:88
}

.domain.ru = DOMAIN.RU
domain.ru = DOMAIN.RU

pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

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

Следующий файл – это файл с настройками Samba. Мне не нужна вся функциональность Samba, поэтому дефолтовый конфигурационный файл я переименовал в smb.conf.old и создал новый /usr/local/etc/smb.conf:

workgroup = DOMAIN
netbios name = svn
realm = domain.ru
server string = svn
hosts allow = 192.168 127.0.0.1

winbind separator =+

winbind use default domain = yes
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes

template homedir = /tmp/winnt/%D/%U
template shell = /bin/bash

max log size = 50
security = ADS
auth methods = winbind

password server = server1 server2
passdb backend = smbpasswd
case sensitive = no

Теперь нужно получить билет Kerberos при помощи команды kinit:

kinit –p administrator

Теперь добавляем в файл /etc/rc.conf автозапуск Apache (если до этого не добавили) и демонов Samba:

apache22_enable="YES"
smbd_enable="YES"
nmbd_enable="YES"
winbindd_enable="YES"

И пробуем запуcтить smbd, nmbd, winbindd вручную.Теперь проверяем работу winbindd при помощи команды wbinfo –p, на которую правильной реакцией является ответ «Ping to winbindd succeeded on fd 4».

Следующим шагом будет добавление машины в домен. Эта простая операция выполняется следующей командой:

net rpc join –S server1 –w DOMAIN –U administrator

Итак, наша машина теперь – полноправный член домена.

Как я уже говорил выше, найти модуль под FreeBSD не удалось, но зато нашелся модуль под Debian. Самое главное, чтобы в найденном архиве был файлик mod_auth_ntlm_winbind.с, который нужно скомпилировать и установить. Делаем это следующим образом:

/usr/local/sbin/apxs -DAPACHE2 -c -i mod_auth_ntlm_winbind.c

Теперь приступаем к последней стадии – настройке конфигурационного файла Apache. Перед этим создаем тестовую директорию /usr/local/www/apache22/data/test, в которой создаем тестовый файл index.html с любым содержанием. Итак, добавляем в конфиг /usr/local/etc/apache22/httpd.conf строку загрузки нашего модуля:

LoadModule auth_ntlm_winbind_module libexec/apache22/mod_auth_ntlm_winbind.s o

и правила доступа к нашей тестовой директории, в виде вот такого блока:

Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
AuthName "NTLM Authentication"
AuthType NTLM
NTLMAuth on
NTLMAuthHelper "/usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of=SID "
NTLMBasicAuthoritative
AuthType NTLM
require valid-user

Где SID – это SID группы, которой требуется доступ к этой папке.

Ну и напоследок покажу как при помощи PowerShell быстренько получить SID нужной нам группы:

$sid = (new-object system.security.principal.NtAccount("gro up_name "))
$sid.translate() | Format-List Value

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

Базовая аутентификация

В данной статье будет рассмотрен самый простой и доступный способ защиты - базовая аутентификация.

Замечание

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

Рассмотрим, как работает базовая аутентификация.
При обращении посетителя в защищаемую директорию, сервер Apache в ответ на запрос посылает заголовок с кодом 401 (401 authentication required header). Браузер посетителя принимает заголовок с кодом 401 и выводит окно с полями для ввода имени пользователя и пароля. После ввода имени и пароля эти данные отсылаются назад серверу, который проверяет имя пользователя на предмет нахождения в специальном списке, а пароль на правильность. Если все верно, то посетитель получает доступ к ресурсу. Вместе с заголовком браузеру посылается специальной имя, называемое областью действия. Браузер кэширует не только имя и пароль, чтобы передавать их при каждом запросе, но и область действия. Благодаря этому, ввод имени и пароля в защищаемой директории осуществляется только раз. В противном случае их необходимо было бы вводить при каждом запросе к защищаемой директории. Кэширование параметров аутентификации (имя, пароль, область действия), обычно осуществляет только в пределах одного сеанса.

Замечание

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

Замечание

WEB-сервер Apache поддерживает еще один вид защиты - digest-аутентификацию. При digest-аутентификации пароль передается не в открытом виде, а в виде хеш-кода, вычисленному по алгоритму MD5. Поэтому пароль не может быть перехвачен при сканировании трафика. Но, к сожалению, для использования digest-аутентификации необходимо установить на сервер специальный модуль - mod_auth_digest. А это находится только в компетенции администрации сервера. Также, до недавнего времени, digest-аутентификация поддерживалась не всеми видами браузеров.

Защита сайта - это просто

Для того чтобы защитить сайт, нужно выполнить следующую последовательность действий: создать файл с паролями, переписать его на сервер, создать файл.htaccess и тоже переписать его на сервер.
Для организации защиты понадобится.

WEB-сайт и FTP-доступ к нему.
Права на создание файлов.htpaccess и организацию защиты с помощью них.
Утилита генерации паролей htpasswd.exe

Проверка работы файла.htaccess на сервере

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

Замечание

Удобно создавать файлы.htaccess с помощью встроенного редактора в оболочках Far, WindowsCommander, TotalCommander и т.п., а также в редакторе Блокнот.

Замечание

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

Рис. Сохранение файлов.htaccess в блокноте

Проверка работы.htaccess

AuthType Basic
AuthName admin
require valid-user

Затем, через FTP-доступ, перепишите файл.htaccess на сайт, в ту директорию, которую вы хотите защитить.

Замечание

Действие файлов.htaccess распространяется не только на ту директорию, где лежит файл, но и на все поддиректрии, лежащие уровнем ниже.

Далее через браузер обратитесь к этой директории. Если Вы защищаете директорию admin и переписали туда файл.htaccess, то для проверки Вам следует вписать в адресную строку браузера следующий URL: http://www.mysite.ru/admin/.

Если после этого Вам открылся запрос на ввод логина и пароля, как на рисунке ниже, то тестирование прошло успешно и можно продолжать защиту директории.

Рис. Окно ввода логина и пароля

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

Замечание

Если по каким либо причинам Вы не можете удалить файл.htaccess, то создайте пустой файл.htaccess и замените им файл, лежащий на сервере.

Создание файла с паролями.htpasswd

Файл с паролями создается утилитой htpasswd.exe . Если у Вас на машине установлен WEB-сервер Apache, то данная утилита находится в директории с установленным Apache -ем в подкаталоге bin .

Замечание

Если у Вас не установлен Apache, то утилиту htpasswd.exe можете скачать по ссылке: .

Для работы с утилитой htpasswd.exe необходим интерфейс работы с командной строкой. Интерфейсом работы с командной строкой обладают такие программы как Far, WindowsCommander и т.п. Здесь будет рассмотрена работа с командной строкой с помощью утилиты cmd, которая входит в поставку Windows 2000/XP и т.п.
Нажмите "Пуск"->"Выполнить" , введите в строку ввода cmd и нажмите ОК . Вам откроется окно утилиты CMD.

Рис. Окно утилиты CMD

Далее необходимо перейти в директорию, где находится утилита htpasswd.exe . Допустим, сервер Apache установлен в директории с:/Apache2, тогда введите в командную строку команду: cd../../apache2/bin и нажмите ввод.

Вы перешли в директорию с:Apache2in. Теперь нужно дать команду на создание файла с паролем. Введите в командную строку следующее:

Htpasswd -cm .htpasswd admin

-cm - это ключи для утилиты. Ключ с - указывает, что необходимо создать новый файл с паролями. Если файл с таким именем уже существует, то он будет перезаписан. Ключ m - определяет шифрование по алгоритму MD5.
.htpasswd - имя файла с паролями (можете использовать любое имя).
admin - имя посетителя, которому будет разрешен доступ в закрытую область сайта.

В ответ, должен появится запрос на ввод пароля и его повтор. Если все правильно, то в завершении появится сообщение: Adding password for user admin. И в директории c:Apache2in появится файл.htpasswd, к котором будет находиться строка с именем пользователя и хеш-кодом его пароля. Для того, что бы в тот же файл.htpasswd добавить еще одного пользователя следует убрать ключ -c из команды запуска утилиты htpasswd.exe

Htpasswd -m .htpasswd admin

Замечание

Если файл с паролями не был создан, то возможно, некоторые ключи утилиты не поддерживаются в Вашей операционной системе. Например, иногда не поддерживается ключ m. В этом случае, Вам нужно ввести htpasswd -c .htpasswd admin
Для того, чтобы посмотреть ключи и параметры работы утилиты введите htpasswd.exe /? Вам будет выдано описание интерфейса.

Итак, файл с паролями создан. Теперь Вам необходимо переписать его на сервер. Файлы с паролями очень желательно класть выше корневой директории сайта - туда, куда не будет доступа посетителям.
Если это невозможно, то файлы с паролями следует обязательно защитить. Это можно сделать с помощью файлов.htaccess. Чтобы защитить файлы с паролями создайте файл со строками, представленными в следующем листинге.

Защита файлов.htpasswd

deny from all

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

Создание файла.htaccess

Для защиты директории могут использоваться следующие директивы:

AuthType - Тип используемой аутентификации. Для базовой аутентификации эта директива должна иметь значение: Basic
AuthName - Имя области действия аутентификации. Текст, помогающий посетителю понять, куда он пытается получить доступ. Например, может быть написано: "Private zone. Only for administrator!"
AuthUserFile - путь к файлу с паролями (.htpasswd).
AuthGroupFile - путь к файлу групп, если он существует.
Require - Одно или несколько требований, которые должны быть выполнены для получения доступа к закрытой области.

Пример файла.htaccess

AuthType Basic

require group admins

Следует более подробно описать директивы AuthUserFile и AuthGroupFile. В них прописываются абсолютные пути к соответствующим файлам от корня сервера.

Внимание!

Относительные пути работать не будут!

Путь от корня сервера, можно узнать, спросив у администрации сервера, либо можно попробовать выяснить его самим. Для этого выполните функцию phpinfo(). На экран будет выведена фиолетовая таблица. Значение абсолютного пути от корня сервера можно посмотреть в переменных: doc_root, open_basedir, DOCUMENT_ROOT.
Директива Require определяет кому разрешен доступ к закрытой области. Например,

require valid-user - разрешен доступ всем прошедшим проверку
require user admin alex mango - разрешен доступ только посетителям с именами admin, alex, mango. Естественно, они должны пройти аутентификацию.
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require valid-user
Доступ только пользователям admin и root

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require user admin root

Доступ только пользователей из группы admins

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
AuthGroupFile /usr/host/mysite/group
require group admins

Запрет доступа только к файлу private.zip

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require valid-user

Часто бывает нужно ограничить доступ пользователей к определенным зонам вашего сайта. Например, к административной части. Часто это делают, создавая свой механизм авторизации. Однако, существует способ защитить зоны сайта с помощью встроенных средств сервера и браузера. Простейшая авторизация носит название Apache Basic authorization. Это будет большая статья, так что приготовьтесь к основательному чтению. Но зато в ней будет все, что вам когда-нибудь понадобится для работы с этим видом авторизации.

Как это работает

Сначала, мы кладем на сервере файл.htaccess. В нем мы указываем, какую зону (или конкретный файл) хотим запаролить. Это может выглядеть примерно так:

AuthType Basic #тип авторизации
AuthName "Name" #имя авторизации
#местоположение файла с паролями
AuthUserFile /usr/host/mysite/.htpasswd
#пропускать любого пользователя,
#который ввел верные логин и пароль
require valid-user

Кроме того, на сайте может присутствовать файл паролей. У него простая структура:

логин:зашифрованный пароль
логин:зашифрованный пароль
...

Путь к этому файлу указывается в htaccess.

Разговор с сервером под увеличительным стеклом

Теперь давайте предположим, что кто-то набрал адрес запароленой директории. Что при этом произойдет? А вот что:

1. Браузер просит у сервера страницу по адресу http://сайт/secret.
Сервер видит, что для этой страницы установлена защита. Он посылает браузеру заголовки:

WWW-Authenticate: Basic realm="My Realm"
Status: 401 Unauthorized
HTTP-Status: 401 Unauthorized

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

2. Получив эти заголовки, браузер рисует на экране форму запроса логина и пароля. Если пользователь нажимает "Cancel", браузер выдает все те данные, что шли за этими заголовками.

3. Если пользователь ввел логин и пароль, то они отсылаются серверу. Тот лезет в файл с паролями и смотрит там такую пару. Если находит, то посылает в ответ ту страницу, которую просил браузер в самом начале. Если нет, то вновь посылает заголовки авторизации.

4. В случае, если пользователь ввел верные логин и пароль, а сервер ответил запрашиваемой страницей, браузер запоминает введенные логин и пароль для этой зоны.

5. Затем, если браузер посылает серверу любой (!!!) запрос, он прикрепляет к нему пару — логин и пароль. Выглядит это так:

Authorization: Basic base64(login:pass)

То есть, пара логин-пароль зашифрована в base64. Еще раз обращу внимание — логин и пароль посылается теперь с любым запросом браузера. Для картинок, файлов стилей, скриптов, favico и всего остального. По сути, для получения каждого файла, вы проходите авторизацию. Только браузер это делает за вас.

6. Сервер, когда получает запрос, проверяет, не идут ли с ним еще и логин с паролем. Если идут, то сразу проводит проверку на авторизованность.

Запрос авторизации на Perl и PHP

Теперь настало время разобраться, как же вывести окно авторизации апача не силами htaccess, а силами скрипта на Perl или PHP. Я специально поставил эти два решения, на двух разных языках под один заголовок. Потому что теперь, зная механику, мы можем быстро прийти к выводу, что для появления окошка запроса авторизации, нужно лишь послать нужные заголовки. Этим и займемся.

#Perl
print "WWW-Authenticate: Basic realm=\"My Realm\"\n";
print "Status: 401 Unauthorized\n";
print "HTTP-Status: 401 Unauthorized\n";
print "Content-type: text/html\n\nCancel";

#PHP
header("WWW-Authenticate: Basic realm=\"My Realm\"");
header("Status: 401 Unauthorized");
header("HTTP-Status: 401 Unauthorized");
print "Вы нажали Cancel";

Результатом и в том и в другом случае, будет форма запроса авторизации.

Перехват авторизации на Perl

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

Возникает затруднение: апач не передает в переменных окружения введенные логин и пароль. То есть, получить к ним доступ из Perl проблематично. Но возможно. Самое простое решение — использовать mod_rewrite. Допишите в файл htaccess строки:

RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) —

Они добавят новую переменую окружения. Из Perl она будет видна как $ENV{HTTP_CGI_AUTHORIZATION}. Она будет содержать пару логин-пароль, закодированную в base64. Конечно, придется немного повозиться с тем, чтобы их перекодировать обратно, но это уже кое-что. Тем более, что возни там, собственно, не много:

$ENV{HTTP_CGI_AUTHORIZATION} =~ s/basic\s+//i;
my ($REMOTE_USER,$REMOTE_PASSWD) = split(/:/,decode_base64($ENV{HTTP_CGI_AUTHORIZATION}));

Теперь у нас есть две переменные $REMOTE_USER и $REMOTE_PASSWD, с помощью которых можно проводить авторизацию силами скрипта, сверяя логин и пароль с чем душе угодно.

Перехват авторизации на PHP

Поддержка сессии на Perl и PHP

Кроме всего прочего, после того, как авторизация прошла успешно, в переменной окружения будет находиться логин авторизованного пользователя, который вызывает исполняемый скрипт. То есть, вы всегда будете знать кто именно сейчас запустил скрипт. Логин содержится в переменных:

#perl
$ENV{REMOTE_USER}
#php
$_SERVER

Вот такие дела

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

Ссылки по теме

htaccess и htpasswd — как сделать авторизаию только силами апача
htaccess.net.ru — сайт, посвященный возможностям управления сервером, при помощи файлов htaccess

Здесь я расскажу о возможностях Apache защищать содержимое сервера либо его частей.

Директивы Apache для контроля доступа

Контроль по IP

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

Внимание! Если вы хотите использовать эти директивы в файле.htaccess, проверьте, что бы для вашего хоста директива AllowOverride корневого файла конфигурации Apache включала опцию Limit

Order

Значения: Order (allow,deny | deny,allow)

Директива Order указывает порядок, в котором будет производиться чтение из директив Allow и Deny

* Allow,deny — сначала читаются директивы Allow. Если пользователя нет в этом списке, то он блокируется. Если же он есть, то далее считываются директивы Deny(процесс еще не закончен). Если же пользователь есть и там, то он блокируется. Если его там нет, то он пропускается. Т.е пользователь пропускается только при наличии только в списке Allow, но не в Deny
* Deny,allow — сначала обрабатываются директивы Deny и отсеиваются те пользователи, которые есть в этом списке. Любые другие пропускаются. Т.е пользователь пропускается всегда, но если его нет в списке Deny

Формат директив: (Allow | Deny) from (IP | IPs | all) (IP | IPs | all) : (IP | IPs | all)

Директивы Allow и Deny определяют клиентов, которым разрешить или запретить доступ к серверу.

Директивы допускают использование:

* Одиночного IP(IP) — обычный вид IP, например, 127.0.0.1
* Группы IP(IPs) — группа IP, например, для доступа, только из локальной сети, 192.168.1.0/24
* Любого IP(all) — обозначает любой IP

После слова from может идти любое количество указанных директив, разделенных пробелом

Файл.htaccess

Order allow,deny # Deny from all # если вы это напишите, то даже те адреса, # которые указаны в директивах Allow не будет пропущены Allow from 192.168.1.0/24 11.11.11.12

В этом файле указывается доступ только для клиентов из локальной сети или с IP 11.11.11.12

Часть файла httpd.conf

... Order deny,allow Deny from 33.250.11.25 ...

Так мы баним сайт для какого-нибудь одного IP
Контроль по имени пользователя или группе

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

AuthType

Значения: AuthType (Basic | Digest)

Apache поддерживает 2 типа защиты содержания (директива AuthType):

* Basic — базовая авторизация. Шифрование используется я на обеих сторонах, но клиент передает пароль не надежно зашифрованным, т. к не используется ключ шифрования. Это крупный недостаток этого метода. Применяется алгоритм шифрования Base64
* Digest — аутентификация специальным кодом (дайджестом), который использует ключ, конкретно, имя пользователя, пароль, область, требующая аутентификацию, различную информацию о запросе и уникальный код данного запроса, который Apache присваивает каждому соединению. Это однонаправленный метод, и для того, что бы расшифровать это, стороннему человеку требуется слишком много информации об обеих сторонах. Но главный недостаток этого метода в том, что его не поддерживает ни один пользовательский браузер, хотя сейчас это уже, наверное, не так (данные на 2000 год). Этот метод обычно используется в специализированных системах

AuthName

Формат директивы: AuthName "String"

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

AuthUserFile, AuthGroupFile

Формат директив: (AuthUserFile | AuthGroupFile) "String"

Внимание! Для работы этих директив необходим модуль Apache mod_auth, который подключается по умолчанию

Эти директивы определяют, соответственно, путь (абсолютный) к файлу, хранящему связки Имя:DES и путь (тоже абсолютный) к файлу, хранящему связки Группа:Имя Имя: Имя

AuthUserFile

Содержит информацию о допустимых именах пользователей и их паролях в формате Имя:DES, где DES — это название алгоритма шифрования. Файл можно создать стандартной консольной программой, входящей в состав Apache, htpasswd. Описание ее использования смотрите ниже

AuthGroupFile

Эту директиву нужно указывать только, если вы указали значение для директивы Request(смотрите ниже) равном group

Этот файл содержит информацию о допустимых группах пользователях для входа. Формат файла: Группа:Имя Имя: Имя. Т.е только те пользователи, которые существуют и которые входят в группы, описанные в директиве Require(смотрите ниже), смогут войти

Require

Значения: Require (user Имя Имя: Имя | group Группа Группа: Группа | valid-user

Эта директива определяет принцип аутентификации:

* User — только пользователи, указанные следующими через пробел, и указавшие верный пароль, смогут войти
* Group — только пользователи, входящие в группы, указанные следующие через пробел, и указавшие верный пароль, смогут войти. Указание директивы AuthGroupFile обязательно
* Valid-user — любой пользователь, существующий в файле AuthUserFile, и указавший верный пароль, сможет войти

На этом директивы, необходимые для метода AuthType Basic, перечислены. Другие директивы, относящиеся к методу AuthType Digest, я перечислять не буду, т. к они имеют узконаправленное действие и в общих системах не используются
Утилита Apache htpasswd

Эта консольная программа создает файлы, указываемые в директиве AuthUserFile. Файл хранит связки Имя:Пароль для доступа к защищенной части сайта

Обычно программа поставляется вместе с Apache и находиться в папке bin ее корневой папки

Формат вызова утилиты:

htpasswd [-cdpsb] ПутьКФайлуПаролей ИмяНужногоПользователя

Параметры командной строки

* -с — создать новый файл. Если этот параметр не указан, и файл не существует, утилита выдаст ошибку и аварийно завершит работу. Внимание! Если файл уже существовал, он будет перезаписан
* -d — утилита будет использовать алгоритм шифрования DES (в C это функция crypt()). По умолчанию используется во всех ОС, но не в Windows
* -m — использовать алгоритм шифрования MD5, который является шифром по умолчанию в Windows
* -p — сохранить пароль в чистом виде, без шифрования. Работает только в Windows
* -s — утилита будет использовать алгоритм шифрования SHA
* -b — в нормальном режиме, без этой опции, утилита получает пароль вводом в стандартный входной поток. При использовании этой опции, после пути к файлу паролей должен идти пароль, и утилита получит пароль из этой опции. Утилита не будет ждать пользовательского ввода, она сразу возвратит управление в оболочку. Пример: htpasswd -b .htpasswd smhtpass

Примеры паролирования

Файл.htaccess

AuthType Basic AuthName "You are entering Private area. Please enter your login and password" AuthUserFile /home/Site.ru/www/PrivateDir/.htpasswd # AuthGroupFile .htgroup # эта директива здесь не нужна, # т. к мы используем аутентификацию по пользователям, но не по группам Require user My root UUCP hacker guest

Здесь доступ разрешен по файлу.htpasswd для пользователей My, root, UUCP, hacker и guest. Тип авторизации Basic

Часть файла httpd.conf

.... AuthType Basic AuthName "This is only my area" AuthUserFile /home/Site.ru/www/PrivateDir/.htaccess AuthGroupFile /home/Site.ru/www/My/.htgroup Require group my root ....

Здесь доступ разрешен по тому же файлу с пользователями, но только с теми, кто входит в группы my или root, определенные в файле.htgroup

Для создания файла паролей для первого примера

Входим в shell и пишем такие команды

; Считаем, что текущая папка установлена на папку с утилитой htpasswd ; Так же считаем, что файл паролей, который требуется создать, еще не существует # htpasswd -cb /home/Site.ru/www/PrivateDir/.htpasswd root rootpasswd # htpasswd -b /home/Site.ru/www/PrivateDir/.htpasswd UUCP pass_rootcp # htpasswd /home/Site.ru/www/PrivateDir/.htpasswd My Password: mypasswd Repeat password: mypasswd Password created OK ; Аналогично создаем записи для пользователей hacker и guest

Заключение

На этом я закончу свое описание здесь средств защиты данных web-сервером Apache. Все пожелания или вопросы можете оставлять по нижеследующим координатам

На данное время (Июль 2006 года) я пишу Content Managing System(CMS) под PHP 4+, MySQL 3.23.xx+ и Apache 1.3+, всем желающим посмотреть или присоединиться — пишите мне сюда же