Все, что нужно знать про Apache Basic authorization
Часто бывает нужно ограничить доступ пользователей к определенным зонам вашего сайта. Например, к административной части. Часто это делают, создавая свой механизм авторизации. Однако, существует способ защитить зоны сайта с помощью встроенных средств сервера и браузера. Простейшая авторизация носит название 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
Помимо этих модулей есть также mod_authn_core и mod_authz_core . Эти модули реализуют основные директивы, которые являются основными для всех модулей auth.
Вы, вероятно, также хотите взглянуть на « Контроль доступа» , в котором обсуждаются различные способы контроля доступа к вашему серверу.
Введение
Если у вас есть информация на вашем веб-сайте, которая чувствительна или предназначена только для небольшой группы людей, методы в этой статье помогут вам убедиться, что люди, которые видят эти страницы, являются людьми, которых вы хотели их видеть.
В этой статье рассматривается «стандартный» способ защиты частей вашего веб-сайта, который большинство из вас собирается использовать.
Заметка:
Если ваши данные действительно должны быть безопасными, рассмотрите возможность использования mod_ssl в дополнение к любой аутентификации.
Предпосылки
Директивы, обсуждаемые в этой статье, должны будут отправляться либо в файл конфигурации вашего основного сервера (обычно в разделе
Если вы планируете использовать файлы.htaccess , вам нужно будет иметь конфигурацию сервера, которая позволяет устанавливать директивы аутентификации в эти файлы. Это делается с AllowOverride директивы AllowOverride , которая указывает, какие директивы, если таковые имеются, могут быть помещены в файлы конфигурации для каждого каталога.
Поскольку мы говорим здесь об аутентификации, вам понадобится директива AllowOverride например:
AllowOverride AuthConfig
Или, если вы просто собираетесь указывать директивы непосредственно в файле конфигурации основного сервера, вам, конечно же, необходимо будет иметь разрешение на запись в этот файл.
И вам нужно немного узнать о структуре каталогов вашего сервера, чтобы узнать, где хранятся некоторые файлы. Это не должно быть ужасно сложно, и я постараюсь это понять, когда мы подошли к этому моменту.
Вам также необходимо убедиться, что модули mod_authn_core и mod_authz_core либо были встроены в двоичный файл httpd, либо загружены конфигурационным файлом httpd.conf. Оба этих модуля обеспечивают основные директивы и функциональные возможности, которые имеют решающее значение для конфигурации и использования аутентификации и авторизации на веб-сервере.
Получение работы
Вот основные принципы защиты паролем каталога на вашем сервере.
Во-первых, вам нужно создать файл паролей. Именно то, как вы это сделаете, будет зависеть от того, какой именно поставщик проверки подлинности вы выбрали. Об этом позже. Для начала мы будем использовать текстовый файл паролей.
Этот файл должен быть размещен где-то недоступным из Интернета. Это значит, что люди не могут загрузить файл паролей. Например, если ваши документы поданы из /usr/local/apache/htdocs , вы можете захотеть поместить файлы с паролями в /usr/local/apache/passwd .
Чтобы создать файл, используйте утилиту htpasswd , поставляемую с Apache. Это будет находиться в каталоге bin везде, где вы установили Apache. Если вы установили Apache из стороннего пакета, это может быть в вашем пути выполнения.
Чтобы создать файл, введите:
htpasswd -c /usr/local/apache/passwd/passwords rbowen
Предоставление более чем одному лицу в
Указанные выше директивы позволяют только одному человеку (в частности, кому-то с именем пользователя rbowen) войти в каталог. В большинстве случаев вы захотите AuthGroupFile более одного человека. Здесь находится AuthGroupFile .
Если вы хотите включить более одного человека, вам нужно создать файл группы, который связывает имена групп со списком пользователей в этой группе. Формат этого файла довольно прост, и вы можете создать его с помощью своего любимого редактора. Содержимое файла будет выглядеть так:
GroupName: rbowen dpitts sungo rshersey
Это всего лишь список членов группы в длинной строке, разделенной пробелами.
Чтобы добавить пользователя в уже существующий файл паролей, введите:
htpasswd /usr/local/apache/passwd/passwords dpitts
Вы получите тот же ответ, что и раньше, но он будет добавлен к существующему файлу, а не к созданию нового файла. (Это -c делает его созданием нового файла паролей).
Теперь вам нужно изменить файл.htaccess или блок
AuthType Basic AuthName "By Invitation Only" # Optional line: AuthBasicProvider file AuthUserFile "/usr/local/apache/passwd/passwords" AuthGroupFile "/usr/local/apache/passwd/groups" Require group GroupName
Теперь любой, кто указан в группе GroupName и имеет запись в файле password , будет включен, если они введут правильный пароль.
Есть еще один способ, чтобы несколько пользователей в этом были менее конкретными. Вместо создания группового файла вы можете просто использовать следующую директиву:
Require valid-user
Использование этой, а не Require user rbowen строки Require user rbowen позволит любому, кто указан в файле паролей, и кто правильно вводит свой пароль.
Возможные проблемы
Из-за того, как указана базовая проверка подлинности, ваше имя пользователя и пароль должны быть проверены каждый раз, когда вы запрашиваете документ с сервера. Это даже если вы перезагружаете одну и ту же страницу и для каждого изображения на странице (если они происходят из защищенного каталога). Как вы можете себе представить, это немного замедляет работу. Объем, который он замедляет, пропорционален размеру файла паролей, потому что он должен открыть этот файл и перейти по списку пользователей до тех пор, пока он не получит ваше имя. И он должен делать это каждый раз, когда страница загружается.
Следствием этого является то, что существует практическое ограничение того, сколько пользователей вы можете поместить в один файл паролей. Это ограничение будет зависеть от производительности вашего конкретного сервера, но вы можете ожидать замедление после получения нескольких сотен записей и, возможно, захотите рассмотреть другой метод аутентификации в то время.
Альтернативное хранение паролей
Поскольку сохранение паролей в текстовых файлах имеет указанные выше проблемы, вы можете захотеть сохранить свои пароли в другом месте, например, в базе данных.
Использование нескольких поставщиков
С внедрением новой архитектуры аутентификации и авторизации, основанной на провайдере, вы больше не заблокированы ни одним методом проверки подлинности или авторизации. Фактически любое количество поставщиков может быть смешано и согласовано, чтобы предоставить вам именно ту схему, которая соответствует вашим потребностям. В следующем примере используются оба поставщика аутентификации на основе файлов и LDAP.
В этом примере поставщик файлов сначала попытается выполнить аутентификацию пользователя. Если он не может аутентифицировать пользователя, будет вызываться поставщик LDAP. Это позволяет расширить область проверки подлинности, если ваша организация реализует несколько хранилищ проверки подлинности. Другие сценарии аутентификации и авторизации могут включать в себя смешивание одного типа аутентификации с другим типом авторизации. Например, аутентификация в отношении файла паролей, который авторизовался в отношении каталога LDAP.
Подобно тому, как могут быть реализованы несколько поставщиков аутентификации, можно использовать несколько методов авторизации. В этом примере используется авторизация группы файлов, а также авторизация группы LDAP.
Чтобы получить авторизацию немного дальше, директивы контейнера разрешений, такие как
Помимо просто авторизации
Применение логики и упорядочения
Контроль того, как и в каком порядке будет применяться авторизация, в прошлом был загадкой. В Apache 2.2 был внедрен механизм аутентификации на основе провайдера, чтобы отделить фактический процесс аутентификации от полномочий авторизации и поддержки. Одним из побочных преимуществ было то, что поставщики аутентификации могли быть сконфигурированы и вызваны в определенном порядке, который не зависел от порядка загрузки самого модуля auth. Этот же механизм, основанный на поставщиках, был также перенесен в авторизацию. Это означает, что директива Require не только указывает, какие методы авторизации следует использовать, но также определяет порядок их вызова. Несколько методов авторизации вызывают в том же порядке, в котором в конфигурации появляются директивы Require .
С введением директив контейнера авторизации, таких как
Кэширование аутентификации
Могут быть случаи, когда аутентификация ставит неприемлемую нагрузку на поставщика или в вашу сеть. Это, скорее всего, затронет пользователей mod_authn_dbd (или сторонних / пользовательских поставщиков). Чтобы справиться с этим, HTTPD 2.3 / 2.4 вводит новый поставщик кэширования mod_authn_socache для кэширования учетных данных и снижения нагрузки на поставщиков (поставщиков) источника.
Это может значительно повысить производительность некоторых пользователей.
Больше информации
Вы также должны прочитать документацию для mod_auth_basic и mod_authz_host которые содержат дополнительную информацию о том, как все это работает. Директива также может помочь в упрощении определенных конфигураций проверки подлинности.
Различные шифры, поддерживаемые Apache для данных аутентификации, объясняются в разделе «Шифрование паролей» .
И вы можете захотеть взглянуть на « Контроль доступа» , в котором обсуждается ряд связанных тем.
Тема прозрачной авторизации в OTRS с использованием Active Directory неизменно пользуется популярностью. А так как родной средой для OTRS является *nix-среда, первым пунктом в списке стоит настройка прозрачной авторизации веб-сервером Apache пользователей из домена AD. В связи с недавним обновлением системы и переносом ее на другой сервер пришлось еще раз пройти тернистый путь. Как оказалось, есть существенно более короткий и простой путь, нежели описан в ссылках в моей . Все действия выполняются из консоли сервера с Apache и не требуют никакого обмена файлами, копи-пасты с контроллером домена и прочей фигни.Фиксирую на память и в помощь коллегам.
Внимание! Данные действия решают задачу прозрачной авторизации пользователей из домена AD на веб-сервере Apache в среде Ubuntu 16.04. Решают ли они еще какие-то задачи (например, авторизацию в консоли с помощью аккаунта из AD), я не знаю, не проверял. Сработает ли решение на другом linux, не знаю, не проверял.
Итак, поехали.
Исходное положение
- Свежеустановленная Ubuntu Server 16.04. Имя сервера ubuntuadmember , запись в DNS присутствует.
- Установленные пакеты Apache и Perl (включая модуль Perl для Apache)
- В Apache настроено исполнение perl-скриптов
- Все перечисленные ниже команды выполняются от учетки root, чтобы не плодить постоянных sudo
Для проверки, что все готово, поместите вот такой скрипт, например, в /var/www/cgi-bin/test.pl, и настройте, чтобы к нему можно было обратиться по http://ubuntuadmember/cgi-bin/test.pl . Скрипт выводит все переменные сервера, а первой строкой специально переменную REMOTE_USER, даже если она пустая. Позже пригодится.
#!/usr/bin/perl use strict; use warnings; print qq(Content-type: text/plain\n\n); print "REMOTE_USER -> $ENV{REMOTE_USER}\n\n"; foreach (keys %ENV){ print "$_ -> $ENV{$_}\n"; }
Если все работает правильно, получится приблизительно такая картинка:
Обращаю внимание, что переменная REMOTE_USER пустая (в общем списке ее вообще нет), т.е. для сервера подключение не авторизовано, анонимно. Будем устранять.
Ставим нужные пакеты
Нам понадобятся пакеты krb5-user для поддержки авторизации Kerberos в системе, libapache2-mod-auth-kerb для поддержки авторизации Kerberos в Apache и msktutil для создания учетной записи компьютера и всего сопутствующего в AD. Установим их:
Apt-get install krb5-user libapache2-mod-auth-kerb msktutil
Настраиваем подключение к AD
Исходные данные про AD:
- Домен, допустим, с названием lab.local
- Контроллер домена 1 с названием dc1.lab.local
- Контроллер домена 2 с названием dc2.lab.local
Необходимо отредактировать файл /etc/krb5.conf и добавить строки в следующие блоки:
Default_realm = LAB.LOCAL LAB.LOCAL = { kdc = dc1.lab.local kdc = dc2.lab.local default_domain = lab.local admin_server = dc1.lab.local } .lab.local = LAB.LOCAL lab.local = LAB.LOCAL
Да, именно так, с соблюдение регистра букв. В принципе, исходное содержимое /etc/krb5.conf не нужно, но я оставлял. Суеверие?
Создаем учетную запись компьютера в AD
Исходные данные
- У вас есть аккаунт с правами создавать новые учетные записи компьютеров. Пусть он называется [email protected]
- Учетная запись компьютера в AD отсутствует
- Вы планируете, что для работы с OTRS будет использовать адрес, совпадающей с именем сервера. В нашем случае имя сервера ubuntuadmember , адрес OTRS http://ubuntuadmember/otrs/index.pl
Предупреждение. В иных случаях могут потребоваться дополнительные действия, и я не знаю, какие именно.
Выполняем логин в AD с помощью аккаунта [email protected]
Kinit -V [email protected]
Если нет ошибок — проверка:
Создаем учетную запись компьютера
Msktutil -c -s host -s HTTP -s HTTP/ubuntuadmember / --computer-name ubuntuadmember --server dc1.lab.local
Эту команду разберем подробнее:
- Ключ -c указывает, что нужно создать учетную запись компьютера.
- Ключи -s указывают, какие значения нужны в атрибуте servicePrincipalName учетной записи компьютера. Если ничего не указать, то не там не будет нужных строчек с префиксом HTTP.
- Ключ —computername указывает имя учетной записи компьютера. Можно пропустить, тогда имя будет соответствовать системному имени сервера.
- Ключ —server указывает имя контроллера домена, на котором будет создана учетная запись. Можно пропустить, тогда будет предпринята попытка самостоятельно определить имя.
!!! Внимание!!! Внимание!!! Внимание!!!
У утилиты msktutil есть ключ —verbose, который призван сделать вывод результатов работы утилиты на экран более «человекочитаемым». Однако в x64 версии тулзы содержится баг, при котором запуск с ключом —verbose останавливается с ошибкой, а без него отрабатывает корректно! Вроде как в x86 версии бага нет. Не попадитесь на этот дешевый трюк, не теряйте время, как я.
Если все сработало, в AD в контейнере Computers должна появиться учетная запись, в нашем случае, ubuntuadmember.
Выставим нужные права на файл с ключами
Chown root.www-data /etc/krb5.keytab chmod 0640 /etc/krb5.keytab
Настроим Apache на авторизацию
Предупреждение . Следующие настройки включают авторизацию Kerberos для всего дефолтного сайта. Если нужно включить более тонко, курите мануалы.
Отредактируем файл /etc/apache2/sites-enabled/000-default.conf и добавим в него перед следующий блок:
Выделено красным:
- /etc/krb5.keytab — дефолтный путь к файл с ключами. Если хотите поменять, не забудьте переместить и файл
- HTTP/[email protected] — должен в точности совпадать с названием компьютера и доменом
После внесения изменений нужно рестартовать Apache
Service apache2 restart
Настройка закончена
Если все сработало, вызов http://ubuntuadmember/cgi-bin/test.pl должен показать такую картинку (скрин с реального сервера, поэтому цензура). Обратите внимание на REMOTE_USER, там доменная учетка в формате username@DOMAIN. Если делать вызов с доменной машины и от доменного пользователя, а браузер настроен (сайт в зоне Интранет), то авторизация пройдет прозрачно без лишних вопросов. В противном случае просто появится стандартный запрос на ввод логина и пароля.
Блин, хотел покороче, но получилось все равно длинно. Попробую еще раз:
### install modules apt-get install krb5-user libapache2-mod-auth-kerb msktutil ### edit /etc/krb5.conf for your AD nano /etc/krb5.conf ### login with AD admin permissions kinit -V [email protected] ### create computer account msktutil -c -s host -s HTTP -s HTTP/ubuntuadmember / --computer-name ubuntuadmember --server dc1.lab.local ### change permissions on keytab file chown root.www-data /etc/krb5.keytab chmod 0640 /etc/krb5.keytab ### edit apache config nano /etc/apache2/sites-enabled/000-default.conf ### restart apache service apache2 restart ### USE and ENJOY
Во, так гораздо лучше! Замечания/вопросы/дополнения пишите в комментах.
If you want to let more than one person in, you"ll need to create a group file that associates group names with a list of users in that group. The format of this file is pretty simple, and you can create it with your favorite editor. The contents of the file will look like this:
GroupName: rbowen dpitts sungo rshersey
That"s just a list of the members of the group in a long line separated by spaces.
To add a user to your already existing password file, type:
htpasswd /usr/local/apache/passwd/passwords dpitts
You"ll get the same response as before, but it will be appended to the existing file, rather than creating a new file. (It"s the -c that makes it create a new password file).
Mod_auth_basic and mod_authz_host which contain some more information about how this all works. The directive can also help in simplifying certain authentication configurations.
The various ciphers supported by Apache for authentication data are explained in Password Encryptions .
And you may want to look at the Access Control howto, which discusses a number of related topics.
Здесь я расскажу о возможностях 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
...
Так мы баним сайт для какого-нибудь одного IP
Контроль по имени пользователя или группе
Если вам нужно защитить сайт или часть сервера паролем, используйте следующие директивы.
Внимание! Если вы хотите использовать эти директивы в файле.htaccess, проверьте, что бы для вашего хоста директива AllowOverride корневого файла конфигурации Apache включала опцию AuthType. Так же для некоторых директив(AuthUserFile и AuthGroupFile) нужна поддержка mod_auth
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
....
Здесь доступ разрешен по тому же файлу с пользователями, но только с теми, кто входит в группы 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+, всем желающим посмотреть или присоединиться — пишите мне сюда же
