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

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

412

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

CacheDefaultExpire

Устанавливает значение по умолчанию устаревания данных кэша для

протоколов, не позволяющих получать подобное значение. По умолча

нию 1 час.

NoCache

Позволяет указать список серверов, страницы которых не должны кэши-

роваться. Если известно, что информация на сервере постоянно обновля-

ется, нет смысла кэшировать страницы этого сервера, поскольку в кэше

будут постоянно храниться устаревшие данные. Указание имени такого

сервера в командной строке NoCache предписывает передавать все запро-

сы напрямую серверу и не кэшировать ответы сервера.

Все эти инструкции закомментированы в настройках Solaris. По умолчанию

сервер Solaris Apache не настроен на работу в качестве прокси-сервера. Если

необходимо создать прокси-сервер, обратитесь к книге, посвященной на-

стройке Apache, например «Linux Apache Web Server Administration».

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

сервера с несколькими IP-адресами

Веб-серверы с несколькими адресами IP известны в качестве многосетевых

(multihomed). Такой сервер должен знать, на какой адрес поступают запро-

сы, подлежащие обработке. Для решения этой задачи Apache предоставляет

следующие параметры настройки:

BindAddress

Указывает адрес, используемый в работе сервера. По умолчанию имеет

значение *, то есть сервер должен отвечать на запросы к веб-службе, по-

ступившие на любой из его IP-адресов. Если в строке BindAddress указан

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

адрес.

Listen

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

нение к стандартным. Адрес и порт в каждой паре разделяются двоеточи-

ем. Например, для приема запросов через порт 8080 и IP-адрес

172.16.12.5 создайте строку Listen 172.16.12,5:8080. Если указан только

порт (без адреса), используется адрес сервера. В отсутствие инструкции

Listen httpd работает только через порт, определенный инструкцией Port.

Инструкции BindAddress и Listen в настройках Solaris закомментированы.

Создание виртуальных узлов

Некоторые из закомментированных параметров файла httpd.conf могут ис-

пользоваться, если на вашем сервере размещаются многие веб-сайты. К при-

меру, чтобы разместить веб-сайты доменов fish.edu и mammals.com на серве-

ре crab.wrotethebook.com, добавьте следующие строки в httpd.conf:

Безопасность веб-сервера

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

ных в главе 12, но привносят и собственные аспекты этой проблематики. По-

мимо защиты от обычных опасностей, веб-серверы должны способствовать

сохранению целостности информации, которую предоставляют, а также ин-

формации, полученной от клиентов.

Доступ к информации сервера разграничивается посредством механизмов

управления доступом. Файл httpd.conf позволяет администратору системы

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

зователей. Управление доступом - важный аспект защиты внутренних и

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

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

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

нять ее целостность.

Одной из опасностей, присущих только веб-серверу, является возможность

изменения информации веб-страниц злоумышленником. Нам неоднократно

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

умышленники изменяли домашнюю страницу какого-нибудь правительст-

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

графического содержания. И хотя подобные атаки не нацелены на причине-

ние серверу долгосрочного вреда, они, вне всякого сомнения, мешают работе

организации, которой принадлежит сайт.

Права доступа Unix защищают файлы и каталоги с документами. Серверу не

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

этих файлов. Плохо спроектированные исполняемые файлы всегда пред-

ставляют потенциальную угрозу безопасности.

Безопасность веб-сервера

413

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

вается ваш сервер. Чтобы такая схема заработала, псевдоним должен иметь

CNAME-определение в DNS. Наш пример требует существования CNAME-

записей, назначающих узлу crab.wrotethebook.com псевдонимы www.fish.edu

и www.mammals.com. Получив запрос, адресованный одному из этих псевдо-

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

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

чив запрос, адресованный www.fish.edu, сервер использует www.fish.edu в ка-

честве значения ServerName вместо собственного имени сервера, a /var/

apache /fish в качестве значения DocumentRoot.

414

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

Угроза CGI и SSI

Сам по себе сервер Apache надежен и достаточно защищен. Наибольшей уг-

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

сервером - как правило, речь идет о программах CGI (Common Gateway In-

terface) и SSI (Server Side Includes).

Приложения CGI могут разрабатываться на С, Perl, Python и на любом дру-

гом языке программирования. Некачественные программы CGI представля-

ют собой одну из самых серьезных угроз для безопасности сервера: злоумыш-

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

реполнении буфера или передаче команд интерпретатора через программу

системе. Защита состоит в предельно внимательном отношении к коду, ко-

торый размещается в системе. Следует лично проверять все программы, хра-

нимые в каталоге cgi-bin. Старайтесь писать программы, не принимающие

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

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

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

Чтобы облегчить задачу аудита сценариев CGI, храните все сценарии в ката-

логе ScriptAlias. Не разрешайте исполнение сценариев из любых других ка-

талогов, если нет полной уверенности, что в эти каталоги попадают только

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

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

де рассказа об инструкции Options.

Серверные включения SSI (Server Side Includes) также представляют собой

потенциальную проблему - по тем же причинам, что и программы CGI. Сер-

верные включения называют еще HTML серверной обработки (Server Parsed

HTML), а файлы SSI часто имеют расширение .shtml. Эти файлы обрабатыва-

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

либо вызывать код внешних сценариев. Если для динамического изменения

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

же видов атак, что и сценарии CGI.

Команды SSI встраиваются в комментарии HTML, а следовательно, начина-

ются символами <! — и завершаются символами -->. Команды SSI перечис-

лены в табл. 11.3.

Таблица 11.3. Команды SSI (Server Side Include)

Команда

Назначение

#config

Задает формат отображения размера файла и времени

#ecbo

Отображает значения переменных

ttexec

Исполняет сценарий CGI или команду интерпретатора

#flastmod

Отображает дату последнего изменения документа

#fsize

Отображает размер документа

ffinclude

Включает внешний файл в текущий документ

Безопасность веб-сервера 415

Наиболее безопасный режим работы требует запрета на обработку инструк-

ций SSI. Такова установка по умолчанию, изменяемая аргументами All или

Includes инструкции Options в файле httpd.conf. Существует и компромисс -

разрешить обработку SSI, но запретить команды ffinclude и #ехес. Они пред-

ставлют наибольшую опасность, поскольку #include записывает в документ

данные из внешнего файла, а #ехес позволяет исполнять сценарии и коман-

ды. Воспользуйтесь аргументом IncludesNOEXEC инструкции Options, чтобы

реализовать такую схему. Рассмотрим теперь создание инструкций Options

для отдельных каталогов.

Управление параметрами сервера

Файл httpd.conf позволяет разграничивать доступ ко всем веб-документам

либо доступ к документам в отдельных каталогах. Инструкция Options оп-

ределяет, какие возможности сервера разрешены к применению для тех или

иных документов. Инструкция Options внутри контейнера Directory дейст-

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

венно в системе Solaris:

Options FollowSymLinks

AllowOverride None

</Directory>

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

</Directory>

Options Indexes MultiViews

AllowOverride None

Order allow,deny

Allow from all

</Directory>

AllowOverride None

Options None

Order allow,deny

Allow from all

</Directory>

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

рех каталогов: корневого (/), /var/apache/htdocs, /var/apache/icons и /var/

apache/сgi-bin. В примере отражены четыре из допустимых значений инст-

рукции Options: FollowSymLinks, Indexes, None и MultiViews. Инструкция

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

All

Разрешает использовать все возможности сервера.

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

ExecCGI

Разрешает исполнение сценариев CGI из указанного каталога. Параметр

ExecCGI разрешает исполнение сценариев CGI из других каталогов, а не

только из каталога ScriptAlias. Многие администраторы устанавливают

этот параметр для каталога ScriptAlias, но это избыточное действие: инст-

рукция ScriptAlias уже определила /var/apache/cgi-bin в качестве катало-

га сценариев. В данном примере Options имеет значение None для катало-

га /var/apache/cgi-bin, что не отменяет действия инструкции ScriptAlias.

FollowSymLinks

Разрешает использование символических ссылок. Если включен данный

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

из данного каталога.

Includes

Разрешает обработку инструкций SSI (Server Side Includes).

IncludesNOEXEC

Разрешает обработку файлов SSI, не содержащих команды

#ехес

и «include.

Indexes

Разрешает передачу списка файлов каталога в отсутствие файла in-

dex.html.

MultiViews

Разрешает согласование языка документа. См. также описание инструк-

ций AddLanguage и LanguagePriority (раздел «Определение файловых

типов» выше по тексту).

None

Запрещает все возможности. Мой любимый аргумент!

SymLinksIfOwnerMatch

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

вые файлы принадлежат владельцу ссылок.

Используйте серверные параметры с осторожностью. Параметры None и

MultiViews, использованные в настройках Solaris, не должны вызывать

проблем с безопасностью, хотя MultiViews поглощает ресурсы сервера. Па-

раметр Indexes связан с легкими рисками, поскольку афиширует содержи-

мое каталога в отсутствие файла index.html, что может быть нежелательным

в отдельных случаях. FollowSymLinks потенциально связан с проблемами,

поскольку символические ссылки увеличивают общее число каталогов с до-

кументами. Чем больше каталогов, тем сложнее обеспечивать их безопас-

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

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

врежденных файлов. (В главе 12 содержится информация о Tripwire, инст-

рументе, облегчающем задачу наблюдения за файлами.)

Безопасность веб-сервера

417

Контейнеры Directory из последнего примера содержат, помимо прочего,

инструкции AllowOverride. Эти инструкции ограничивают возможности на-

стройки отдельных каталогов.

Механизмы управления уровня каталога

Оператор AccessFileName

htaccess разрешает управление доступом на уровне

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

cess. Если сервер находит файл с таким именем в каталоге, из которого из-

влекается информация, то применяет содержащиеся в файле настройки,

прежде чем передать данные. Инструкция AccessFileName передает управ-

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

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

стройки. Инструкции настройки в файле .htaccess - те же, что встречаются в

файле httpd.conf и определяют конфигурацию системы в целом. Настройки

Solaris содержат строку AccessFileName

htaccess, поэтому в системах Solaris

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

Инструкция AllowOverride может использоваться в целях ограничения степе-

ни свободы в настройках, предоставляемой отдельным каталогом. Она опре-

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

оритет, чем инструкции httpd.conf. Присутствие инструкции AllowOverride

внутри контейнера Directory ограничивает область действия AllowOverride

данным конкретным каталогом, как мы видели в предшествующем примере.

•

Инструкция AllowOverride имеет множество различных аргументов. В допол-

нение к ключевому слову All, разрешающему файлу .htaccess переопределять

любые параметры файлов настройки, а также ключевому слову None, запре-

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

рукции, переопределение которых разрешено. К примеру, чтобы разрешить

создание связей для файловых расширений в файле .htaccess, необходимо ис-

пользовать инструкцию AllowOverride

AddType.

Когда это значение использует-

ся в качестве аргумента инструкции AllowOverride, файл .htaccess данного

каталога может содержать инструкции AddType. AllowOverride позволяет

разрешить переопределение практически любого параметра в файле .htaccess.

Инструкции Options и AllowOverride ограничивают доступ к возможностям

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

ния информации. Но в некоторых случаях речь идет об информации, кото-

рая не должна получить широкого распространения. Распространение ин-

формации может пресекаться благодаря управлению доступом.

Создание правил доступа

Используйте файл httpd.conf для разграничения доступа на уровне отдель-

ных узлов и пользователей. Несколько примеров позволят вам полностью

понять возможности этого механизма. Начнем с примера разграничения до-

ступа для узлов:

418

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

Order deny,allow

Deny from all

Allow from wrotethebook.com

</Directory>

В данном случае создаются правила доступа для каталога /var/apache/ht

docs/internal. Эти правила написаны таким образом, что доступ имеют толь-

ко узлы домена wrotethebook.com. Контейнер Directory содержит три инст-

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

Order

Определяет порядок использования правил управления доступом,

deny, allow предписывает httpd использовать сначала запрещающее прави-

ло (deny), а затем разрешить исключения из него, описанные разрешаю-

щим правилом (allow). В данном примере мы заблокировали доступ всем

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

для систем, состоящих в домене wrotethebook.com, при помощи разреша-

ющего правила. Это пример правил доступа, которые могут использо-

ваться для защиты внутреннего веб-сайта.

Deny from

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

мым в каталоге /var/apache/htdocs/internal. Узлы могут обозначаться

полными или частичными именами либо адресами IP. Каждая инструк-

ция Deny from может обозначать только один источник; чтобы перечислить

несколько источников, следует использовать несколько инструкций Deny

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

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

слово all блокирует доступ с любых узлов.

Allow from

Указывает узлы, с которых разрешен доступ к документам каталога. Уз-

лы могут обозначаться полными или частичными именами либо адреса-

ми IP. Каждая инструкция Allow from может обозначать только один ис-

точник; чтобы перечислить несколько источников, следует использовать

несколько инструкций Allow from. Однако в случае использования домен-

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

го домена или сети. Ключевое слово all разрешает доступ с любых узлов.

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

узлов. Этот механизм обычно примеряется для разделения информации,

предназначенной для внутренних пользователей и внешних клиентов.

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

групп.

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

Аутентификация пользователя может быть сделана необходимым условием

для доступа к документу или каталогу. Как правило, эта возможность ис-

Безопасность веб-сервера

419

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

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

AuthName "Accounting"

AuthType Basic

AuthUserFile /etc/apache/http.passwords

AuthGroupFile /etc/apache/http.groups

Require hdqtrs rec bill pay

Order deny,allow

Deny from all

Allow from Limit>

</Directory>

Первые две инструкции в данном контейнере Directory называются AuthNa-

me и AuthType. AuthName определяет значение области идентификации

(authentication realm), которое передается клиенту в заголовке WWW-Authenti-

cate. Область - это группа ресурсов сервера с общими полномочиями досту-

па. К примеру, каталог /var/apache/htdocs/internal/accounting является

единственным элементом области Accounting. Однако области Accounting

могут принадлежать и другие документы и каталоги, защищенные паролем.

В таком случае пользователь, прошедший аутентификацию в области Acco-

unting, получает доступ ко всем ресурсам этой области.

Инструкция AuthType определяет тип аутентификации, основанной на па-

ролях. Может принимать значение Basic или Digest. Basic предписывает вы-

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

том. Digest предписывает использовать алгоритм Message Digest 5 (MD5).

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

реализован в некоторых броузерах, но больше потому, что данные, требую-

щие серьезной защиты, лучше защищать при помощи механизма безопас-

ности SSL (Secure Sockets Layer). SSL мы рассмотрим позже, в разделе

«Шифрование».

В приведенном примере доступ разрешается, если пользователь принадле-

жит к указанной группе и предоставил верный пароль. Эти группы и пароли

не имеют ничего общего с теми, что используются программой login, но оп-

ределяются и существуют только в контексте веб-сервера. Файлы, создан-

ные с целью хранения сведений и пользователях и группах, обозначаются

при помощи строк AuthUserFile и AuthGroupFile. Добавление паролей в

файл паролей веб-сервера выполняется посредством программы

htpasswd,

по-

ставляемой в составе системы Apache; добавление групп в файл групп может

выполняться при помощи любого редактора текстов. Запись файла групп со-

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

лей, входящих в группу. К примеру:

hdqtrs: amanda pat craig kathy

Инструкция Require требует от пользователя ввода веб-имени и веб-пароля.

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

420

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

щим одной из групп hdqtrs, rec, bill или pay, причем пользователь должен

ввести верный пароль. Ключевое слово valid-user в строке Require разреша-

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

не используется.

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

строку AuthGroupFile, когда работаете с парольной аутентификацией. Что-

бы не создавать пустой файл группы, просто укажите значение /dev/null.

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

что и в предыдущем. Мы предписали выполнять парольную аутентифика-

цию наряду с проверкой узлов. Последнее необязательно. Если удалить из

примера инструкции Order, Deny и Allow, доступ к документам будет разре-

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

верное имя и пароль.

Более совершенная аутентификация

Стандартный модуль аутентификации, mod_auth, хранит данные иденти-

фикации пользователей в текстовых файлах, поиск в которых осуществля-

ется последовательно. На последовательный поиск может уходить значи-

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

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

можностью индексирования.

Поддержка баз данных аутентификации осуществляется двумя модулями:

mod_auth_db, который работает с базами данных Berkeley DB, либо

mod_auth_dbm, который работает с базами данных Unix DBM. В базовой на-

стройке Solaris динамически загружается модуль mod_auth_dbm, так что

мы можем использовать базу данных паролей в системе Solaris, затратив ми-

нимум усилий.

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

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

использованию базы данных паролей, всего лишь заменив инструкцию Auth-

UserFile на инструкцию AuthDBMUserFile, а инструкцию AuthGroupFile на

AuthDBMGroupFile. Вот пример:

AuthName "Accounting"

AuthType Basic

AuthDBMUserFile /etc/apache/passwords

AuthDBMGroupFile /etc/apache/groups

Require hdqtrs rec bill pay

Order deny,allow

Deny from all

Allow from Limit>

</Directory>

Этими небольшими изменениями все и ограничивается для файла ht-

tpd.conf. Самые серьезные изменения при переходе на базы данных паролей

Безопасность веб-сервера

421

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

word. Вместо нее для создания записей паролей и групп используется коман-

да dbmmanage, синтаксис которой приведен ниже :

dbmmanage filename command username password

Элементы командной строки dbmmanage по большей части прозрачны, filename -

это имя файла базы данных, username и password - те самые данные, что

должны храниться в базе данных паролей, command - одно из ключевых слов,

определяющих назначение данной команды dbmmanage. Существуют следу-

ющие ключевые слова:

add

Добавляет имя пользователя и пароль в базу данных. Пароль должен

быть предварительно зашифрован, поскольку dbmmanage не шифрует па-

роль по ключевому слову add. См. описание ключевого слова adduser.

adduser

Добавляет имя пользователя и пароль в базу данных. Пароль записывает-

ся открытым текстом и шифруется программой dbmmanage.

check

Проверяет соответствие имени пользователя и пароля той паре, что хра-

нится в базе данных.

delete

Удаляет из базы данных имя пользователя и пароль.

import

Копирует записи username:password со стандартного потока ввода. Предпо-

лагается, что пароли уже зашифрованы.

update

Изменяет пароль для пользователя, запись которого уже существует в ба-

зе данных.

view

Отображает содержимое базы данных.

В следующем примере создается файл /etc/apache/passwords, после чего в

базу данных добавляются два новых пользователя:

# dbmmanage /etc/apache/passwords adduser sara

New password:

Re-type new password:

User sara added with password encrypted to XsH4aRiQbEzp2

# dbmmanage /etc/apache/passwords adduser alana

New password:

Re-type new password:

User alana added with password encrypted to AslrgF/FPQvF6

# dbmmanage /etc/apache/passwords view