Записи с тегом «apache»

Замечательный модуль Helicon Ape для IIS, который эмулирует среду исполнения Apache, вышел.

Появилась у меня необходимость на страницах блога HeliconTech синтаксически подсвечивать конфигурационные файлы Apache (httpd.conf и .htaccess). Первым делом я пошёл на сайт Ивана Сагалаева, но оказалось, что его замечательный highlight.js подсвечивать конфигурацию Apache не умеет. Но также выяснилось, что написать новую подсветку синтаксиса довольно просто. С сайта документации Apache я получил html-страницу, на которой были все (*почти все :) его директивы. После некоторого шаманства с регулярными выражениями из этого html-файла я получил список всех директив Apache в простом текстовом файле. Дальше, немного потрудившись, получилось и само описание синтаксиса.

Скачать highlight-apache.zip Пример работы

Для использования распакуйте архив на сайте и в html-документах внутри тега head необходимо добавить:

<link rel="stylesheet" href="apache.css">
<script src='highlight.js'></script>
<script src='apache.js'></script>
<script>hljs.initHighlightingOnLoad();</script>

Не забудьте поправить пути к файлам.

Подсветка работает. И я радуюсь.

2009-01-03 UPDATE: Иван Сагалаев добавил подсветку apache в проект highlight.js!

2009-01-04 UPDATE: сделал новый стиль - Magula. Тоже уже принят в основной бранч.

Helicon Ape - это революционный модуль для IIS, который эмулирует Apache-окружение: конфигурационную модель (httpd.conf + .htaccess`ы) и наиболее востребованные модули. Самые вкусные из них: mod_rewrite, mod_proxy, модули для basic-, digest- и хост-авторизации.

Модуль написан на .NET для IIS 7. С некоторыми ограничениями работает и на IIS 6 как ASP.NET модуль.

Качайте, пробуйте и радуйтесь!

Нашёл в apache интересную и неочевидную особенность. Имеем конфиг:

ServerName company.com
Listen 8080
Listen 8081
...
RewriteCond %{SERVER_PORT} 8080
RewriteRule .* bar.html

Правило RewriteRule никогда не отработает! Условие в RewriteCond будет всегда ложно. %{SERVER_PORT}, как видно из логов mod_rewrite, всегда возвращает 80. Сначала я подумал, что нашёл в apache баг. Но посмотрев исходники, понял, что багрепортером апача мне не быть. Серверная переменная %{SERVER_PORT} содержит не номер порта, на который пришёл запрос (что в общем вполне логично и ожидаемо), а номер порта из ServerName! Немного исправит положение ServerName company.com:8080. Но как отличать запросы, которые пришли на порт 8081?

Выяснил ещё, что в режиме FastCGI сервер IIS 7 не понимает чанковые запросы, т.е. Transfer-Encoding: chunked. А именно в режиме FastCGI рекоммендуют запускать php5.

Начнём без долгих прелюдий. Источник - Configuration Sections из документации апача и его исходники, т.к. в документации не отражены разные тонкости.

Прикаждом запросе конфигурационные секции апача применяются так: сначала сливаются (соединяются, merge) директивы из конфигурации сервера (httpd.conf) и директивы из конфигурации виртуального хоста (в соответствующеё секции <VirtualHost>), и объединённая конфигурация (merged configuration) исполняется. Затем соединяются директивы из конфигурационных секций типа Directory, Files, файлов .htaccess, и полученная объединённая конфигурация исполняется.

Допустим, что апач обрабатывает запрос http://servername/a/b/index.html, в результате которого будет выдан файл /www/servername/a/b/index.html. Вот итоговая последовательность применения конфигурационных секций:

Соединяются конфигурации

• httpd.conf
• <VirtualHost> </VirtualHost>

Выполняется соединённая конфигурация

Соединяются конфигурации

• <Directory /www/servername/> … </Directory>
• <VirtualHost> <Directory /www/servername/> … </Directory> </VirtualHost>
• /www/servername/.htaccess
• <Directory /www/servername/a/> … </Directory>
• <VirtualHost> <Directory /www/servername/a/> … </Directory> </VirtualHost>
• /www/servername/a/.htaccess
• <Directory /www/servername/a/b/> … </Directory>
• <VirtualHost> <Directory /www/servername/a/b/> … </Directory> </VirtualHost>

• /www/servername/a/b/.htaccess

• <Directory ~ | DirectoryMatch ^/www/servername/> … </DirectoryMatch>
• <VirtualHost> <Directory ~ | DirectoryMatch ^/www/servername/> … </DirectoryMatch> </VirtualHost>
• <Directory ~ | DirectoryMatch ^/www/servername/a/> … </DirectoryMatch>
• <VirtualHost> <Directory ~ | DirectoryMatch ^/www/servername/a/> … </DirectoryMatch> </VirtualHost>
• <Directory ~ | DirectoryMatch ^/www/servername/a/b/> … </DirectoryMatch>

• <VirtualHost> <Directory ~ | DirectoryMatch ^/www/servername/a/b/> … </DirectoryMatch> </VirtualHost>

• <Files | Files ~ index.html> … </Files> в порядке как они записаны в конфиге

• <VirtualHost> <Files | Files ~ index.html> … </Files> </VirtualHost> в порядке как они записаны в конфиге

• <Location | Location ~ > … </Location> в порядке как они записаны в конфиге
• <VirtualHost> <Location | Location ~ > … </Location> </VirtualHost> в порядке как они записаны в конфиге

Выполняется соединённая конфигурация

В модуле mod_auth_basic авторитарность работает следующим образом. Обычно, каждый провайдер аутентификации, перечисленный в директиве AuthBasicProvider, пытается аутентифицировать пользователя и, если пользователь не был найден модулем, доступ будет запрещён с ответом 401 Authorization Required. Выключение авторитарности модуля - AuthBasicAuthoritative Off - для таких случаев позволяет не запрещать сразу доступ, а предоставить возможность аутентифицировать пользователя другим модулям. Например, модулям сторонних производителей, которые не могут быть подключены с помощью директивы AuthBasicProvider. Порядок обработки запроса такими модулями не конфигурируется и определяется в их исходном коде.

Для модуля mod_authz_user, например, отключение авторитарности - AuthzUserAuthoritative Off - позволяет продолжить авторизацию следующим модулям (например, mod_authz_groupfile), если не нашлось информации об аутентифицированном пользователе. Пример:

...
AuthzUserAuthoritative Off
Require user john group developers

Модуль mod_authz_user не сможет авторизовать пользователя tom (так как авторизоваться может только пользователь john) и, так как он неавторитарен, позволит продолжить авторизацию следующему модулю - mod_authz_groupfile, которые проверит, принадлежит ли пользователь tom группе developers.

Если все модули в процессе авторизации не смогли авторизовать пользователя и были неавторитарными, последним отработает модуль mod_authz_default, которые запретит доступ 401 Authorization Required.

Модуль mod_authn_default является запасным последнем (fallback) модулем в процессе аутентификации. Если для запроса нет сконфигурированного модуля аутентифиукации (например, mod_auth_basic с AuthType Basic и далее) модуль mod_authn_default просто отклоняет любые аутентификационные данные и прекращает обработку запроса со стастусом 401 Authorization Required. Такое может случится, если, например, mod_auth_basic неавторитарен (AuthBasicAuthoritative Off - об этом следующем посте) и не смог аутентифицировать пользователя.

Модуль mod_authz_default является запасным последнем (fallback) модулем в процессе авторизации. Если для запроса не отработал ни один модуль авторизации (например, mod_authz_user с Require user john), а такое возможно если в Require были неопознанные требования, например, Require unknown requirement, модуль mod_authz_default просто прекращает обработку запроса со стастусом 401 Authorization Required.

Модуль mod_authn_anon позволяет аутентифицировать анонимных пользователей. В качестве имени как правило используется anonymous (но можно выбрать любые другие), в качестве пароля – email. Этот email может быть сохранён в логе. Совместно с другими провайдерами аутентификации (например, mod_authn_file) модуль mod_authn_anon даёт возможность отслеживать доступ зарегистрированных пользователей и держать сайт открытым для незарегистрированных пользователей.

Пример конфигурации с комментариями:

AuthName "Protected area"
# тип аутентификации
AuthType Basic
# список провайдеров аутентификации, работают последовательно
AuthBasicProvider file anon
# путь к файлу с пользователями для mod_authn_file
AuthUserFile /path/to/your/.htpasswd

# Параметры mod_authn_anon
# может ли имя быть пустым или любым (on или off)
Anonymous_NoUserID off
# может ли пароль (т.е. email) быть пустым (on или off)
Anonymous_MustGiveEmail on
# проверять ли, что введеный пароль есть email (on или off)
Anonymous_VerifyEmail on
# логировать ли email(on или off)
Anonymous_LogEmail on
# список имён анонимных пользователей
Anonymous anonymous guest www test welcome

Require valid-user

Модуль mod_authn_anon может работать только с Basic-аутентификацией. Проверка email (включается директивой Anonymous_MustGiveEmail on) тривиальна - в строке проверяется наличие символа ‘@’ и ‘.’.

Модуль mod_authz_groupfile обеспечивает авторизацию уже аутентифицорованного пользователя по принадлежности его к некоторой группе. Пример:

Require group developers managers

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

# file /path/to/groupfile
testers: tom tony
developers: jack john
managers: jane bill

Путь к этому файлу определяется директивой AuthGroupFile:

AuthGroupFile /path/to/groupfile

Отметим, что данный выше пример директивы Require полностью аналогичен такой:

Require user jack john jane bill

Использование модуля mod_authz_groupfile позволяет группировать пользователей в группы, и управлять доступом уже на уровне групп.

Отдельное место среди всех авторизаторов занимает модуль mod_authz_host. При обработке запроса этот модуль вызывается раньше любых других модулей аутентификации/авторизации и используется для контроля доступа на основании данных о хосте клиента (имя хоста, адрес) и характеристик запроса (через переменные окружения). Этот модуль, пожалуй, наиболее часто используемый в Апаче для контроля доступа.

Работа модуля определяется директивами: Order, Allow, Deny. Директива Order определяет порядок проверки правил:

Order allow,deny

значит, что первыми будут проверятся правила allow (т.е. разрешающие), потом - правила deny (запрещающие). Если никаких правил нет - действие по умолчанию - запретить всем. Директива

Order deny,allow

значит наоборот. Первыми будут применяться правила deny, потом - allow. Действие по умолчанию - пускать всех. Директивы Allow и Deny задают правила для проверки:

# пускать всех клиентов из зоны .org
Allow from .org
# три идентичных правила: пускать из подсети 192.168
Allow from 192.168
Allow from 192.168.0.0/16
Allow from 192.168.0.0/255.255.0.0
# не пускать с такого ipv6-адреса
Deny from 2001:db8::a00:20ff:fea7:ccea

Правила проверяются до первого совпедния. Правило “совпало”, если правило соответствует информации о клиенте. Если правило совпало в цепочке allow - доступ разрешается, если в цепочке deny - запрещается.

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

Модуль проверяет значение директивы Require. Строка

Require valid-user

означает, что модуль будет успешно авторизовать (давать доступ) всем аутентифицированным пользователям. Строка

Require user john tom

означает, что модуль будет успешно авторизовать только пользователей john и tom.

дальше будет.

Рассмотрим работу модуля mod_authn_file. Этот модуль является провайдером аутентификации для таких модулей как mod_auth_basic или mod_auth_digest. Аутентификация происходит путём поиска пары пользователь/пароль в текстовом файле. Такой файл можно создать руками, а можно с помощью утилиты htpasswd. Команда

htpasswd -c /path/to/passwdfile user1

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

user1:$apr1$9Y3.....$4fT.9GPTLwu4zwNTJ9HoE0

Для шифрования паролей утилита htpasswd для Windows по умолчанию использует md5, а для unix-систем - crypt(). Опционально пароли можно шифровать с помощью SHA1 или не шифровать вообще, например так:

user2:pass2

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

AuthBasicProvider file
# или
AuthDigestProvider file

и путь к файлу с паролями

AuthUserFile /path/to/file

Путь может быть абсолютным или относительным от ServerRoot.

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

дальше будет.

Рассмотрим как работает mod_auth_basic. Содержимое .htaccess в директории /var/www/private/, соответствующей uri /private/:

# Тип аутентификации
AuthType Basic
# Имя зоны, для которой необходима аутентификация,
# Иначе называется realm
AuthName "private zone"
# Провайдер аутентификации. В данном случае - mod_authn_file
AuthBasicProvider file
# Информация для mod_authn_file - путь к файлу с именами и паролями,
# Такой файл создаётся с помощью утилиты htpasswd или вручную - рассмотрим позже.
AuthUserFile /etc/apache2/conf/.htpasswds
# Доступ будет разрешён аутентифицированному пользователю john,
# т.е. будет авторизован только пользователь john.
Require user john

Происходит запрос в /private/. При обработке запроса на этапе проверки доступа начинает работать модуль mod_auth_basic. Он в запросе ищет заголовок Authentication. Если заголовка нет - модуль прекращает обработку запроса и сервер возвращает ответ со статусом 401 Unauthorized и заголовком WWW-Authenticate: Basic realm="private zone". Браузер, получив такой ответ, выдаёт приглашение для ввода имени пользователя и пароля для зоны ‘private zone’. Получив аутентификационные данные, браузер посылает такой же запрос с заголовком Authentication. Имя пользователя и пароль кодируются в base64-кодировку так:

base64encode('john:secret') -> 'am9objpzZWNyZXQ='

и получается такой заголовок:

Authentication: Basic am9objpzZWNyZXQ=

Теперь, при обработке запроса, mod_auth_basic из заголовка Authentication получит аутентификационные данные:

base64decode('am9objpzZWNyZXQ=') -> 'john:secret'

Эти имя пользователя и пароль mod_auth_basic передаст провайдеру аутентификации (в нашем случае mod_authn_file) для проверки. При успешной проверке, запрос продолжит обрабатываться, при неуспешной mod_auth_basic опять прекратит обработку запроса с 401 Unauthorized.

Дальще будет.

Процесс аутентификации/авторизации происходит в три этапа.

Получение аутентификационных данных. На этом этапе работает mod_auth_basic или mod_auth_digest. Они читают заголовок запроса Authentication и вытягивают оттуда аутентификационные данные (credentials). Для Basic-аутентификации это просто ‘username:password’ в base64 кодировке. Для Digest-аутентификации это md5-дайджест имени пользователя, пароля, authname и других параметров, которые мы позже рассмотрим детально.

Аутентификация (проверка аутентификационных данных). На этом этапе работают модули mod_authn_***, которые проверяют аутентификационные данные. Например, модуль mod_authn_file исчет пару username:password в текстовом файле. Результат работы этих модулей - аутентифицирован успешно (AUTH_GRANTED), доступ запрещён (AUTH_DENIED) или пользователь не найден (AUTH_USER_NOT_FOUND).

Авторизация (предоставление прав). На этом этапе работают модули mod_authz_***, которые проверяют возможность доступа для уже аутентифицированного пользователя. Например, если задано Require user tomas, то модуль mod_authz_user предоставит доступ только пользователю tomas и запретит всем остальным. Если задано Require valid-user, то модуль mod_authz_user предоставит доступ любому успешно аутентифицированному пользователю.

Дальше - mod_auth_basic.

В последнее время я вплотную занялся рассмотрением безопасности в apache. Источники: Authentication, Authorization and Access Control и исходники apache.

Для начала поймём, что такое аутентификация и авторизация:

• Аутентификация (англ. Authentication) или подтверждение подлинности — процедура проверки соответствия субъекта и того, за кого он пытается себя выдать, с помощью некой уникальной информации, в простейшем случае — с помощью имени и пароля.
• Авторизация (англ. Authorization) — процесс, а также результат процесса проверки необходимых параметров и предоставление определённых полномочий лицу или группе лиц (прав доступа) на выполнение некоторых действий в различных системах с ограниченным доступом.

В апаче за эти процессы отвечают следующие модули:

Типы аутентификации (директива AuthType):

• mod_auth_basic (Basic аутентификация)
• mod_auth_digest (Digest футентификация)

Провайдеры аутентификации (проверяют имя/пароль):

• mod_authn_alias
• mod_authn_anon
• mod_authn_dbd
• mod_authn_dbm
• mod_authn_default
• mod_authn_file
• mod_authnz_ldap

Авторизаторы (директива Require, проверяют возможность доступа для уже аутентифицированного пользователя):

• mod_authnz_ldap
• mod_authz_dbm
• mod_authz_default
• mod_authz_groupfile
• mod_authz_owner
• mod_authz_user

Дальше будет.