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

 

Сервер DNS, доступный из внешней сети

Работа сети Internet базируется на использовании взаимодействующих между собой серверов DNS. Чтобы понять, как сервер, установленный в локальной сети, позволяет внешним пользователям обращаться к локальным компьютерам по именам, необходимо рассмотреть процесс обмена данными между различными серверами DNS. Предположим, что к серверу DNS обратился Web-броузер, пользователь которого задал URL http://www.whitehouse.gov. Сервер DNS должен преобразовать символьное имя www.whitehouse.gov в IP-адрес узла сети. Локальный сервер DNS начинает процесс преобразования с того, что обращается к корневому серверу DNS. IP-адреса компьютеров, выполняющих функции корневых серверов, указаны в конфигурационном файле каждого сервера DNS; вероятность того, что эти адреса изменятся, крайне мала. Обращаясь к корневому серверу DNS, локальный сервер передает ему имя, предназначенное для преобразования (в данном примере это имя www.whitehouse.gov). В большинстве случаев корневой сервер не знает IP-адреса, соответствующего указанному имени, но имеет информацию о доменах верхнего уровня (TLD — top-level domain). Примерами таких доменов являются .com, .gov, .uk и т.д. Поэтому корневой сервер возвращает локальному серверу адреса компьютеров, поддерживающих DNS-сервер .gov, после чего локальный сервер передает запрос одному из компьютеров, обеспечивающих работу домена .gov. Сервер DNS .gov также не может преобразовать имя, но он знает IP-адреса компьютеров, ответственных за поддержку домена whitehouse.gov, поэтому передает их локальному серверу DNS. Сервер whitehouse.gov знает IP-адрес, соответствующий имени www.whitehouse.gov, поэтому, получив запрос локального сервера, он возвращает ему требуемую информацию. После получения IP-адреса локальный сервер DNS передает его Web-броузеру, который использует адрес при формировании запроса к Web-серверу. Процесс преобразования адресов условно показан на рис. 18.1. Детали этого процесса скрыты от пользователя. С точки зрения прикладной программы или работающего с ней пользователя дело обстоит так, как будто локальный сервер DNS имеет информацию о соответствии символьных имен и IP-адресов всех узлов Internet.

Рис. 18.1. Процесс преобразования адреса предполагает передачу запросов различным серверам DNS

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

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

На заметку

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

Вместо установки собственного сервера DNS, вы можете использовать один из серверов, предоставляющих услуги по преобразованию имен. Этим занимаются многие организации, осуществляющие поддержку DNS, и провайдеры Internet. Часто подобные услуги предоставляются бесплатно, в других случаях за них надо платить, но плата невелика (обычно она составляет несколько долларов в год). Так, например, бесплатное DNS-обслуживание предлагает организация Granite Canyon (http://www.granitecanyon.com). Советую вам не слишком полагаться на бесплатные услуги; помните правило: "Вы получите то, за что заплатите". В любом случае сторонние организации предоставят вам возможность разместить либо один, либо оба сервера DNS, необходимых для обслуживания вашей сети.

Существует специальное динамическое DNS-обслуживание, которое предоставляется в основном пользователям DSL и кабельных модемов. Организации, которые предоставляют динамическое DNS-обслуживание, поддерживают обычные серверы DNS, но они позволяют быстро обновлять записи, которые соответствуют изменяющимся IP-адресам. Многие организации предпочитают использовать статические IP-адреса и статические средства преобразования имен. Динамическое DNS-обслуживание в основном предоставляется отдельным пользователям, поддерживающим собственные серверы. Динамическое DNS-обслуживание обеспечивают многие организации. Полный их список занял бы слишком много места, поэтому здесь приводятся лишь два URL: http://www.technopagan.org/dynamic/ и http://www.oth.net/dyndns.html.

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

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

 

Работа локального сервера DNS

Локальный сервер DNS не только предоставляет возможность внешним пользователям обращаться к компьютерам вашей локальной сети по именам. Он также выполняет преобразование символьных имен в IP-адреса для узлов локальной сети, т.е. выполняет те же функции, что и серверы, адреса которых содержатся в файле /etc/resolv.conf. Использование локального сервера DNS предоставляет следующие преимущества.

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

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

Таким образом, локальный сервер не только позволяет внешним пользователям обращаться к вашим компьютерам по именам, но и может использоваться для обслуживания внутренней сети. Решение об установке сервера DNS полностью оправдано в том случае, когда ваша локальная сеть отделена от Internet брандмауэром и к ней подключено достаточно большое количество компьютеров.

В простых сетях вместо сервера DNS можно использовать другие средства преобразования адресов. Так, например, в системах Linux и UNIX для этой цели можно применить файл /etc/hosts. (Аналогичное средство доступно и в прочих системах, но соответствующий файл расположен в другом каталоге. Например, в Windows 9x/Me подобные функции выполняет файл С:\WINDOWS\HOSTS.) В составе файла /etc/hosts содержатся записи; каждая из них состоит из IP-адреса, за которыми следуют полное доменное имя и сокращенный вариант имени компьютера. Пример записи из файла /etc/hosts приведен ниже.

192.168.78.109 gingko.threeroomco.com gingko

При установке системы Linux в файл /etc/hosts помещается единственная запись, которая связывает имя localhost с адресом 127.0.0.1. Если в локальной сети содержится небольшое число компьютеров, этот файл несложно дополнить так, чтобы он определял все узлы сети. В небольшой сети отредактировать файлы /etc/hosts гораздо проще, чем настроить сервер DNS. При увеличении размеров сети для редактирования файлов /etc/hosts приходится прилагать все больше и больше усилий, в то время как затраты на поддержку сервера DNS увеличиваются лишь незначительно. Применение файла /etc/hosts теряет смысл, если в вашей сети присутствует сервер DHCP и используется динамическое распределение IP-адресов.

 

Установка конфигурации DNS предполагает решение двух задач: настройка сервера DNS (в пакете BIND функции сервера выполняет программа named) и администрирование домена. В данном разделе обсуждаются особенности выполнения первой задачи, а администрированию домена посвящен следующий раздел. (Далее в этой главе будут рассмотрены использование локального сервера DNS для кэширования результатов преобразования имен и интеграция BIND с сервером DHCP.) При настройке сервера DNS устанавливаются основные опции, указывается расположение других серверов DNS (в частности, серверов корневого домена) и задается информация о поддерживаемых зонах. Даже для небольшого домена необходим вторичный (ведомый) сервер имен. В принципе вы можете установить конфигурацию вторичного сервера, скопировав содержимое соответствующих файлов, созданных для локального сервера, но гораздо лучше настроить вторичный сервер так, чтобы от автоматически дублировал параметры первичного сервера.

 

Главный конфигурационный файл BIND

Основные опции BIND задаются в главном конфигурационном файле с именем named.conf. Этот файл обычно располагается в каталоге /etc. В некоторых дистрибутивных пакетах Linux файл с опциями, установленными по умолчанию, в каталоге /etc отсутствует. В этом случае файл-образец надо искать в каталоге, содержащем документацию BIND (обычно это каталог /usr/share/doc/bind- версия ). Пример файла named.conf приведен в листинге 18.1.

Листинг 18.1. Пример файла named.conf

options {

 directory "/var/named/";

 auth-nxdomain yes;

 forwarders {

  10.232.7.98;

  10.232.45.1;

 };

 forward first;

};

zone "." {

 type hint;

 file "named.ca";

};

zone "threeroomco.com" {

 type master;

 file "named.threeroomco.com";

};

zone "1.168.192.in-addr.arpa"{

 type master;

 file "named.192.168.1";

};

zone "0. 0.127.in-addr.arpa" {

 type master;

 file "named.local";

};

Файл named.conf состоит из нескольких разделов. В листинге 18.1 представлены раздел options и несколько разделов zone. Раздел options содержит определения глобальных опций, в частности, в нем задается каталог, в котором содержатся файлы с описанием зоны. Разделы zone описывают конкретные зоны — домены либо другие группы имен или IP-адресов. Большинство строк, содержащихся в файле named.conf, оканчиваются точкой с запятой (;). Это требование надо выполнять, в противном случае BIND может некорректно интерпретировать содержимое конфигурационного файла. В основном содержимое файла named.conf представляет собой указатели на файлы, в которых находятся дополнительные сведения о зонах. Эти файлы содержатся в каталоге /var/named либо в другом каталоге, заданном с помощью опции directory.

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

 

Расположение других серверов имен

Одна из основных задач, которые вам предстоит решить при инсталляции сервера DNS, — получить список корневых серверов. Сделать это можно несколькими способами.

• Требуемый файл может входить в поставку пакета BIND. Обычно он называется named.са или db.cache и располагается в каталоге /var/named. Если содержимое этого файла устарело, вы можете получить новый файл одним из двух описанных ниже способов.

• Файл named.са, содержащий список корневых серверов, можно скопировать посредством протокола FTP, обратившись по адресу ftp://ftp.rs.internic.net/domain/.

• Если в вашей системе установлена программа dig, вы можете задать команду dig @a.root-servers.net.ns > named.са. Эта команда копирует файл, содержащий список корневых серверов, и присваивает ему имя named.са.

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

Получив файл со списком корневых серверов, скопируйте его в каталог /var/named. Кроме того, вам следует убедиться в том, что ссылка на этот файл присутствует в конфигурационном файле /etc/named.conf. В листинге 18.1 файл, содержащий список корневых серверов, указан с помощью опции file, расположенной в разделе zone ".", (Каждое доменное имя должно оканчиваться точкой, но имя корневой зоны состоит только из точки.)

 

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

BIND осуществляет преобразование имен одним из трех описанных ниже способов.

1. Если пакет BIND настроен для поддержки запрошенного имени, сервер возвращает адрес, указанный в его конфигурационном файле.

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

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

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

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

Перенаправление запросов задается с помощью опций forwarders и forward (см. листинг 18.1). Опция forwarders позволяет задать один или несколько IP-адресов серверов DNS, к которым локальный сервер станет обращаться перед тем, как начать выполнение стандартной процедуры преобразования адресов. Опция forward допускает одно из двух значений: only или first. Если вы зададите forward only, BIND при работе будет полагаться лишь на удаленный сервер DNS, указанный с помощью опции forwarders, и не будет выполнять стандартную процедуру преобразования имен. Значение first опции forward указывает на то, что BIND должен сначала обратиться к удаленному серверу DNS, а если такое обращение не дало результатов (например, если удаленный сервер не ответил на запрос), он должен осуществить преобразование имен по стандартному алгоритму. В любом случае, если к серверу поступит запрос на преобразование имен, которые принадлежат зоне, обслуживаемой данным сервером, он будет использовать описание зоны в своем конфигурационном файле.

 

Описание зоны

При настройке BIND вы должны указать, как следует обрабатывать запросы, в которых указаны определенные домены, поддомены и диапазоны IP-адресов. Различные группы имен и адресов называются зонами. Зоной может быть домен или поддомен (например, зоной является домен threeroomco.com, указанный в листинге 18.1) либо диапазон IP-адресов (такой диапазон присутствует в имени зоны, оканчивающемся символами in-addr.arpa). Для простого сервера DNS задается лишь несколько зон.

• Корневая зона. Зона, идентифицируемая посредством точки ("."), определяет корневой узел пространства имен. В определении зоны присутствует опция type hint, которая сообщает о том, что список серверов содержится в файле, указанном посредством опции file.

• Локальный домен. Если ваш сервер DNS предназначен не только для кэширования, вам придется сконфигурировать BIND для поддержки зоны, соответствующей вашему домену. В листинге примером такой зоны является threeroomco.com.

• Обратная зона. Несмотря на то что в большинстве случаев сервер DNS используется для преобразования символьных имен в IP-адреса, сервер имен также должен поддерживать обратное преобразование. Для выполнения подобного преобразования создается зона, имя которой оканчивается на in-addr.arpa. Перед этой последовательностью символов указывается имя зоны, т.е. часть IP-адреса, заданная в обратном порядке. Например, запись для сети 192.168.1.0/24 имеет имя 1.168.192.in-addr.arpa.

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

• master. Первичный, или ведущий (master), сервер содержит описание зоны. Если вы создаете сервер DNS для небольшой сети, то, вероятнее всего, объявите локальные зоны как master. Пример зоны такого типа приведен в листинге 18.1.

• slave. Вторичный, или ведомый (slave), сервер получает информацию о зоне от другого сервера DNS. Такой сервер также может выступать в роли источника информации о зоне. В следующем разделе данный тип зоны будет рассмотрен более подробно. Простой сервер DNS может выступать для некоторых зон как ведущий, а для других зон — как ведомый.

• stub. Сервер такого типа похож на ведомый, но он копирует только записи NS, т.е. спецификации сервера имен. Данный тип зоны следует использовать в том случае, если вы хотите создать отдельный сервер DNS для поддомена. Предположим, что домен threeroomco.com содержит поддомен sub.threeroomco.com и вы хотите использовать для управления им отдельный сервер DNS. Для этого вы должны включить в состав конфигурационного файла сервера BIND для threeroomco.com определение зоны с именем sub.threeroomco.com типа stub, указывающее на сервер DNS sub.threeroomco.com. Вы можете также использовать один сервер DNS для поддержки всего домена, включая поддомен sub.threeroomco.com. В этом случае вам не понадобится формировать специальную зону sub.threeroomco.com.

• forward. Подобно опции forward в разделе options, зона forward сообщает BIND, что запросы на получение информации о зоне должны передаваться другому серверу DNS. BIND формирует собственный запрос к указанному серверу, а затем использует полученные данные для построения ответа. Используя зону такого типа, вы должны включить опцию forwarders, указывающую BIND, какому из удаленных серверов DNS должны перенаправляться запросы.

• hint. Зона этого типа используется только для описания корневых серверов имен. Она сообщает системе, где следует искать список таких серверов. BIND должен самостоятельно обновлять данный список, обращаясь к корневому серверу имен.

Простой конфигурационный файл, подобный представленному в листинге 18.1, содержит одну зону hint и несколько зон master. В случае более сложной конфигурации в конфигурационном файле могут быть указаны зоны всех типов.

 

Настройка ведомого сервера

Если вы собираетесь зарегистрировать домен, вам необходимо настроить два сервера DNS. Обычно один сервер конфигурируют как ведущий, а другой — как ведомый. Как и ведущий, ведомый сервер хранит информацию о зоне в отдельных файлах. Различие между этими серверами состоит в том, что ведомый сервер получает информацию о зонах от ведущего сервера. Для того чтобы это стало возможным, надо задать специальным образом конфигурацию зоны в файле /еtс/named.сonf. Предположим, например, что вам необходимо настроить сервер так, чтобы он выполнял функции ведомого по отношению к серверу, конфигурационный файл которого приведен в листинге 18.1. На ведомом сервере зона threeroomco.com должна быть определена следующим образом:

zone "threeroomco.com" {

 type slave;

 file "named.threeroomco.com";

 masters { 192.168.1.50; }

};

Приведенная выше запись указывает на то, что ведомый сервер должен получать содержимое конфигурационного файла для threeroomco.com с сервера DNS, расположенного по адресу 192.168.1.50. Если сервер функционирует как ведомый для нескольких доменов, в его конфигурационном файле содержится несколько подобных определений. В списке masters можно указать два и более серверов DNS; их адреса отделяются друг от друга точкой с запятой. (При необходимости ведомый сервер может синхронизировать свое содержимое посредством другого ведомого сервера.) Если сервер является ведомым для нескольких зон, различные зоны могут синхронизироваться от разных ведущих серверов. Эту возможность удобно использовать в том случае, если вы администрируете несколько доменов. Каждый домен обслуживается отдельным ведущим сервером, и для всех их роль ведомого может выполнять один сервер.

Зоны типа slave должны быть определены не только для прямого, но и для обратного преобразования адресов (зоны threeroomco.com и 1.168.192.in-addr.arpa, приведенные в листинге 18.1). Для корневых серверов имен и для обратного преобразования localhost (0.0.127.in-addr.arpa в листинге 18.1) зоны типа slave создавать не надо.

Если сконфигурировав сервер как ведомый, вы запустите его на выполнение, то вскоре увидите, что сервер создал файлы описания зоны, указанные в записях zone. Если этого не произошло, необходимо просмотреть файлы протоколов как для ведущего, так и для ведомого сервера и определить причину их некорректной работы. Возможно, что ведущий сервер сконфигурирован так, что передача зоны запрещена. Такой запрет часто устанавливается по соображениям безопасности, чтобы внешние пользователи не могли получить информацию о компьютерах, принадлежащих вашему домену. Если вы хотите ограничить право передачи зоны ведущим или ведомым сервером DNS, вам надо задать опцию allow-transfer. Сделать это можно либо в разделе options, либо в определении конкретной зоны. Например, чтобы ограничить право передачи зоны компьютерами 192.168.1.0/24 и 172.19.98.23, надо создать следующую запись:

allow-transfer {

 192.168.1/24;

 172.9.98.23;

};

 

Несмотря на то что вы создали файл /etc/named.conf, указали в нем глобальные опции и определили зоны, оказывается, что настройка ведущего сервера DNS не закончена и запускать его еще рано. Если в файле /etc/named.conf указана зона типа master, необходим также конфигурационный файл зоны. В этом файле указываются имена узлов и IP-адреса. Если сервер имен обслуживает домен, содержащий большое число узлов, создание и поддержка файла зоны составляет значительную часть работы по администрированию сети. Если же домен невелик и состояние его не изменяется, достаточно лишь один раз создать конфигурационный файл.

 

Пример конфигурационного файла зоны

В листинге 18.2 приведен пример простого конфигурационного файла зоны. Этот файл начинается с имени зоны (threeroomco.com) и раздела, в котором определяются параметры домена по умолчанию. Эти параметры детально рассматриваются ниже. За этим разделом следует набор записей, предоставляющих информацию о соответствии имен компьютеров и IP-адресов. Некоторые из записей относятся ко всему домену. Подробно структура записей будет рассмотрена позже.

Внимание

В системе DNS имена узлов должны оканчиваться точкой. Если, работая с клиентскими программами Internet (Web-броузером, клиентом FTP, программой подготовки почты), вы не укажете завершающую точку, система Linux сначала посчитает, что имя домена не указано, поэтому добавит к имени узла имя домена, заданное в /etc/resolv.conf . Если попытка преобразования такого имени окажется неудачной, система вместо имени домена добавит к имени, указанному пользователем, точку и снова попытается выполнить преобразование. Эти действия скрыты от пользователя, поэтому он может пренебрегать точкой в конце имени без ущерба для себя. Настраивая сервер DNS, администратор не может позволить себе подобной небрежности. В конфигурационном файле можно задавать либо полностью определенное доменное имя, оканчивающееся точкой, либо имя узла, не содержащее имени домена. Если вы забудете указать точку в конце полного доменного имени, система добавит к нему имя домена. Сформированное таким образом имя будет иметь вид gingko.threeroomco.com.threeroomco.com .

Листинг 18.2. Простой конфигурационный файл зоны

threeroomco.com. IN SOA spruce.threeroomco.com. \

                        admin.threeroomco.com. (

                 2002043004 ; serial (последовательный номер)

                 3600       ; refresh (обновление)

                 600        ; retry (повторное обращение)

                 604800     ; expire (срок действия)

                 86400      ; default_ttl (время жизни)

                )

gingko.threeroomco.com. IN A     192.168.1.1

birch                   IN A     192.168.1.2

spruce                  IN A     192.168.1.3

threeroomco.com.        IN A     192.168.1.4

www                     IN CNAME gingko

kelp                    IN CNAME jacques.pangaea.edu.

@                       IN MX    10 birch.threeroomco.com.

@                       IN MX    20 mail.pangaea.edu.

@                       IN NS    spruce.threeroomco.com.

Формат записи в конфигурационном файле зоны выглядит следующим образом:

имя IN тип_записи содержимое_записи

Здесь под именем подразумевается имя компьютера или псевдоимя, связанное с адресом и применяемое для обратного преобразования. Идентификатор IN сокращенно означает Internet и определяет класс записи. Кроме IN существуют и другие классы записей, но в данной главе они рассматриваться не будут. Тип записи — это код, определяющий запись для прямого или обратного преобразования адресов, или запись, используемая почтовым сервером. Содержимое записи может занимать одну или несколько строк и обычно представляет собой IP-адрес или имя узла. Если содержимое записи является описанием зоны, оно располагается в нескольких строках, в остальных случаях вся запись помещается в одной строке. Признаком комментариев является точка с запятой, текст, следующий за ней, не обрабатывается сервером.

Внимание

В различных конфигурационных файлах BIND точка с запятой интерпретируется по-разному: в файле named.conf ею заканчивается выражение, а в файле зоны она определяет комментарии. Это следует учитывать при редактировании конфигурационных файлов BIND, в противном случае сервер будет работать некорректно.

Конфигурационный файл зоны обычно помещается в каталог /var/named, и ему присваивается имя, связанное с именем зоны. Обычно для такого файла выбирается имя db. имя-зоны или named. имя-зоны . Конфигурационному файлу можно присвоить любое имя, необходимо лишь, чтобы оно совпадало с именем, указанным в /etc/named.conf.

 

Формирование описания зоны

Для описания зоны используется запись SOA (Start of Authority — начало полномочий). В поле, определяющем тип записи, указано значение SOA. Наличие этой записи означает, что сервер имен поддерживает данный домен. В поле имени указывается имя зоны, совпадающее с именем, заданным в файле /etc/named.conf (не забывайте о завершающей точке!). Содержимое записи в данном случае состоит из трех частей.

• Ведущий сервер имен. Первое имя (в листинге 18.2 это spruce.threeroomco.com.) представляет имя ведущего сервера имен для зоны. В листинге 18.2 за этим именем следует обратная косая черта (\). Как и во многих конфигурационных файлах, этот символ означает, что продолжение записи находится на следующей строке. Часто в конфигурационных файлах зоны две строки объединяются в одну, и в этом случае обратная косая черта не нужна.

• Почтовый адрес администратора. Второе имя (в листинге 18.2 это admin.threeroomco.com.) определяет почтовый адрес администратора, отвечающего за поддержку зоны. Этот адрес представляется в несколько необычном формате. Чтобы его можно было использовать, надо заменить первую точку на символ @, так, адрес admin.threeroomco.com. будет преобразован в [email protected].

• Временные соотношения. Числовые значения, помещенные в скобки и располагающиеся в последующих строках, задают информацию о временных соотношениях. В листинге 18.2 приведены комментарии, поясняющие назначение соответствующих чисел. В строке, помеченной комментариями serial, содержится последовательный номер, который необходимо увеличивать при каждом редактировании файла. Ведомый сервер на основании данного значения определяет, следует ли обновлять свой конфигурационный файл. Многие администраторы задают последовательный номер как дату (в формате YYYYMMDD), сопровождая ее номером изменений, произведенных в течение текущего дня. В строке refresh задается время в секундах между обращениями ведомого сервера к ведущему. Значение 3600, приведенное в листинге 18.2, соответствует одному часу, следовательно, ведомый сервер будет каждый час проверять, не изменились ли параметры зоны на ведущем сервере. Значение retry представляет время в секундах, по истечении которого ведомый сервер предпримет повторную попытку обращения к ведущему серверу в случае, если первая попытка окажется неудачной. Значение expire также определяет время в секундах, в течение которого запись считается действительной, если ведомому серверу не удается связаться с ведущим. По истечении указанного времени запись не может быть использована для преобразования имен. Величина expire обычно соответствует одной неделе и, конечно же, должна превышать значение refresh. Значение default_ttl задает время жизни. В течение этого времени сервер DNS должен хранить информацию о результатах преобразования. Обычно величина времени жизни составляет от одного дня (86400 в листинге до одной недели (604800). Если IP-адреса вашей сети часто изменяются или если вы предполагаете, что вскоре придется произвести много изменений, имеет смысл задать время жизни порядка часа.

 

Определение адресов и имен

Большинство записей в конфигурационном файле зоны предоставляет информацию о соответствии между именами и IP-адресами. В поле имени, как правило, задается имя компьютера либо другое имя, связанное с IP-адресом. В поле имени также можно задавать символ @, заменяющий имя домена. Данный символ обычно используют в записях MX и NS (листинг 18.2). Эти записи не несут информации о взаимосвязи имен и адресов, а определяют специальные имена для всего домена.

Ниже описаны основные типы записей.

• А. В записи A (address — адрес) в поле имени задается имя узла, а содержимое записи представляет собой IP-адрес. В качестве имени узла можно использовать полное доменное имя (с завершающей точкой), например gingko.threeroomco.com., либо имя узла без указания имени домена, например birch или spruce. Можно также в качестве имени компьютера указать имя домена, так, например, в листинге 18.2 задано соответствие между именем threeroomco.com. и IP-адресом 192.168.1.4.

• CNAME. Запись CNAME (canonical name — каноническое имя) ставит в соответствие имени другое имя. В поле содержимого может быть указано либо полное доменное имя с завершающей точкой, либо имя узла без имени домена. Если вы задаете полное доменное имя, оно не обязательно должно принадлежать домену, определяемому посредством файла зоны. Например, в листинге 18.2 имя kelp связывается с компьютером в другом домене. Записи CNAME обычно применяются в тех случаях, когда важные IP-адреса могут изменяться без вашего участия. Например, если вы размещаете Web-страницу на внешнем компьютере, то можете связать имя www с именем этой машины. Если адрес внешнего компьютера изменится, ваша запись останется корректной.

• PTR. В листинге 18.2 записи типа PTR отсутствуют. Эти записи применяются для обратного преобразования и будут рассматриваться ниже.

• NS. Запись NS (name server — сервер имен) задает сервер имен для домена. В конфигурационном файле должна присутствовать хотя бы одна запись NS, указывающая на компьютер, заданный в качестве ведущего сервера имен в записи SOA. В поле имени данной записи указывается либо имя домена, либо символ @. IP-адрес компьютера, содержащего сервер имен, задается с помощью записи А.

• MX. Запись MX (mail exchanger — обмен почтой) предоставляет информацию о почтовом сервере для зоны. В поле имени этой записи указывается символ @ либо имя домена. В поле содержимого записи содержатся два компонента: код приоритета и имя узла. Когда удаленный почтовый сервер собирается передать сообщение пользователю в домене (например, [email protected]), он запрашивает у сервера имен записи MX. Затем уделенный сервер пытается связаться с компьютером, для которого указано наименьшее значение приоритета (в листинге 18.2 это birch.threeroomco.com.). Если этот компьютер не доступен, удаленный сервер предпринимает попытку установить соединение с тем узлом, приоритет которого выражается следующим по величине значением (в листинге 18.2 это mail.pangaea.edu.). Перебор компьютеров продолжается до тех пор, пока сообщение не будет доставлено либо пока не выяснится, что все узлы, указанные в записях MX, не доступны. Очевидно, что компьютер, имя которого задано в записи MX, должен быть настроен для приема почты. Вопросы передачи почтовых сообщений будут рассматриваться в главе 19.

Совет

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

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

 

Конфигурация зоны для обратного преобразования

В листинге указано несколько зон, некоторые из них предназначены для обратного преобразования. Эти зоны позволяют серверу DNS определять доменное имя по IP-адресу. Для того чтобы это стало возможным, необходимо создать псевдодомен in-addr.arpa. В файле /etc/named.conf содержатся указатели на конфигурационные файлы, описывающие подмножества этого домена. Поскольку имя домена уточняется при движении справа налево, а IP-адрес уточняется по мере движения слева направо, в имени псевдодомена адрес должен быть указан в обратном порядке. Например, имя зоны для диапазона адресов 192.168.1.0/24 будет иметь вид 1.168.192.in-addr.arpa.

Зона для обратного преобразования, или обратная зона, настраивается подобно зоне прямого преобразования. Конфигурационный файл зоны содержит записи SOA и NS, но основное место в нем занимают записи PTR. При обратном преобразовании не возникает необходимость в записях MX, А и CNAME. В листинге 18.3 содержится конфигурационный файл обратной зоны, соответствующий файлу, приведенному в листинге 18.2.

В поле имени записи PTR указывается либо сокращенный вариант адреса (например, 1 для 192.168.1.1), либо полный IP-адрес, расположенный в обратном порядке и сопровождаемый именем in-addr.arpa. В листинге 18.3 продемонстрированы оба подхода. В поле содержимого включается полное доменное имея с точкой в конце. Поскольку обратная зона отличается от зоны, используемой для прямого преобразования, попытка задать в поле содержимого сокращенное имя приведет к некорректному преобразованию, например, при указании birch вместо birch.threeroomco.com. будет получен результат birch.1.168.192.in-addr.arpa.

Листинг 18.3. Пример конфигурационного файла обратной зоны

1.168.192.in-addr.arpa. IN SOA spruce.threeroomco.com. \

                               admin.threeroomco.com. (

                        2002043004 ; serial

                        3600       ; refresh

                        600        ; retry

                        604800     ; expire

                        86400      ; default_ttl

                        )

1                         IN PTR gingko.threeroomco.com.

2.1.168.192.in-addr.arpa. IN PTR birch.threeroomco.com.

3.1.168.192.in-addr.arpa. IN PTR spruce.threeroomco.com.

4.1.168.192.in-addr.arpa. IN PTR threeroomco.com.

@                         IN NS  spruce.threeroomco.com.

 

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

 

Маскировка адреса

При настройке почтового сервера нередко задается маскировка адреса. Согласно исходной конфигурации, устанавливаемой при инсталляции сервера SMTP, он сообщает другим серверам имя узла, которое было задано при настройке сети и возвращается по команде hostname. Это имя сервер указывает при передаче команд HELO и MAIL FROM:, оно же включается в поле From: заголовка сообщения. Кроме того, сервер сообщает имя узла, передавая другим программам ответы на полученные от них команды.

В большинстве случаев такая конфигурация устраивает системного администратора, но иногда возникает необходимость использовать для сервера другое имя. Предположим, например, что ваш почтовый сервер расположен на компьютере с именем franklin.threeroomco.com. Возможно, вы захотите, чтобы сообщения выглядели как отправленные не с конкретного компьютера, а из домена threeroomco.com. (Это может понадобиться в том случае, если вы используете для отправки и получения почты различные серверы, или для того, чтобы упростить перенос почтовых серверов на другие компьютеры.) Не исключено, что вы захотите изменить имя узла в сети, защищенной брандмауэром, чтобы сообщения, переданные в ответ, адресовались на компьютер, доступный извне. Сделать это можно, используя средства маскировки адресов. В результате их применения сервер, расположенный на компьютере franklin.threeroomco.com, будет объявлять себя как threeroomco.com. Маскировку адресов поддерживают все серверы, рассматриваемые в данной главе, но детали настройки различаются в разных продуктах. Некоторые серверы предоставляют в распоряжение администратора несколько опций, позволяющих настраивать команды, приветственные сообщения и заголовки для работы с другим именем, а в других серверах настройка осуществляется с помощью одной опции. В одних серверах относительно просто изменить заголовки существующих сообщений для отображения нового адреса, а при работе с другими решить данную задачу достаточно сложно.

На заметку

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

 

Обработка локальных сообщений

Одна из проблем, возникающих при работе почтового сервера, состоит в том, что вам необходимо сообщать ему, какие адреса должны рассматриваться как локальные. Предположим, что почтовый сервер выполняется на компьютере franklin.threeroomco.com. По умолчанию сервер SMTP настраивается для получения почты, адресованной пользователям компьютера franklin.threeroomco.com. Если при настройке домена вы указали запись MX, которая указывает на этот компьютер, он будет обрабатывать письма для пользователей домена threeroomco.com. Кроме того, вам, возможно, понадобится настроить почтовый сервер для обработки почты, направленной на другие компьютеры и в другие домены. В этом случае вам придется добавить к списку доменов, в которых сервер должен поддерживать передачу локальной почты, домен fourroomco.com.

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

 

Ретрансляция писем

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

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

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

На заметку

Пользователи, которые работают с портативными компьютерами и часто перемещаются с места на место, регистрируясь на серверах различных провайдеров, создают множество проблем для системных администраторов. Предоставлять таким пользователям доступ к почтовому серверу опасно, так как каждый, кто зарегистрировался у того же провайдера, сможет использовать ваш почтовый сервер для пересылки спама. Гораздо лучше, если пользователь, работающий с портативным компьютером, будет передавать почту через сервер того провайдера, в сети которого он зарегистрировался в настоящий момент. Если же передачу через сервер провайдера по каким-то причинам реализовать не удается, вы можете создать на своем сервере конфигурацию под названием SMTP после POP. В этом случае сервер POP сообщает серверу SMTP о том, что тот может принимать письма с определенного IP-адреса в течение ограниченного периода времени. Чтобы сервер POP сгенерировал такое сообщение, пользователь должен успешно зарегистрироваться на нем и получить свою корреспонденцию. Еще одно решение состоит в использовании SSH для регистрации в локальной системе или в настройке соответствующих средств для туннелирования SMTP-соединений.

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

Совет

Если вы сконфигурировали операционную систему для работы в сетях различных провайдеров, передача почты может быть затруднена. Большинство провайдеров настраивают почтовые серверы так, чтобы они могли перенаправлять только письма, полученные из своей сети. Таким образом, если вы настроите свой сервер SMTP для передачи сообщений почтовому серверу одного из провайдеров, серверы остальных провайдеров останутся для вас недоступными. Чтобы решить эту проблему, надо сформировать несколько конфигурационных файлов сервера SMTP (по одному для каждого провайдера) и включить в сценарий установки PPP-соединения команду, которая будет выполнять копирование требуемого файла в стандартный конфигурационный файл и перезапускать сервер. Предположим, что вы работаете с двумя провайдерами и используете sendmail . В этом случае вы должны создать два конфигурационных файла, сохранив их, например, под именами sendmail-isp1.cf и sendmail-isp2.cf . В сценарий, используемый для установки PPP-соединения, вы должны включить команду копирования требуемого файла в файл sendmail.cf .

 

Настройка сервера для борьбы со спамом

Сразу после своего появления электронная почта стала широко применяться для обмена информацией между пользователями и до сих пор остается одним из наиболее популярных средств сетевого взаимодействия. К сожалению, недобросовестные рекламодатели также оценили E-mail как чрезвычайно удобное и недорогое средство, позволяющее доставлять рекламные сообщения потенциальным покупателям. Слово "к сожалению" приводится здесь по двум причинам. Во-первых, по электронной почте в настоящее время в основном распространяется реклама чрезвычайно низкого уровня: приглашения посетить порнографические Web-узлы, приобрести продукты сомнительного качества и т.д. Во-вторых, подобные сообщения создают дополнительную нагрузку на почтовые серверы во всем мире, поэтому вред, наносимый спамом, нельзя недооценивать. Передача почтового сообщения стоит недорого; гораздо дороже обходится его получение, так как письмо занимает место на диске, получатель тратит время, чтобы прочитать или удалить его, и т.д. Если механизм спама возьмут на вооружение большинство бизнесменов, электронная почта станет практически бесполезной: нужные письма потеряются в потоке рекламных сообщений.

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

Блокирование поступающих рекламных сообщений

Вас, как системного администратора, больше всего должно заботить, чтобы спам не проник в вашу сеть. Для контроля за спамом разработаны различные способы. Наиболее популярные из них описаны ниже.

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

• Списки IP-адресов. В настоящее время некоторые организации публикуют списки IP-адресов, которые можно использовать для блокирования нежелательных почтовых сообщений. В подобном списке содержатся адреса спамеров, открытых ретрансляторов (т.е. почтовых серверов, предоставляющих всем желающим возможность передавать через них письма), компьютеров, подвергшихся взлому и используемых для распространения спама, и т.д. Многие почтовые серверы настроены для работы с одним из таких списков. Письма, переданные с адресов, указанных в списке, отвергаются. Информация о некоторых из списков IP-адресов, применяемых для борьбы со спамом, приведены в табл. 19.1.

• Сравнение с шаблоном сообщений, обработанных почтовым сервером. Система Procmail, которая будет описываться далее в этой главе, может быть использована для проверки писем на соответствие заданным шаблонам. На базе Procmail построены сложные системы, предназначенные для борьбы со спамом, например SpamBouncer (http://www.spambouncer.org). При необходимости вы можете самостоятельно сформировать фильтры Procmail.

• Сравнение с распределенными шаблонами. Одним из последних инструментов, предназначенных для борьбы со спамом, является Vipul's Razor (http://razor.sourceforge.net). Эта система использует базу данных SHA-кодов (Secure Hash Algorithm — защищенный алгоритм хеширования) сообщений спама. Вы можете сконфигурировать свой почтовый сервер для вычисления SHA-кодов полученных писем и блокировать рекламные сообщения на основании сравнения их с кодами Vipul's Razor.

Таблица 19.1. Списки IP-адресов, используемые для борьбы со спамом

Для блокирования большей части спама достаточно использовать один или два способа, например, один из списков IP-адресов и сравнение с шаблонами сообщений, обработанных почтовым сервером. Основная проблема борьбы со спамом состоит в том, что в настоящее время не существует технологии, позволяющей гарантированно распознать спам и отделить его от обычных сообщений. Большинство способов блокирования основаны на тех или иных обобщениях. Эти способы позволяют отвергать сообщения спама, но вместе с ними блокируются также некоторые корректные сообщения. Этот эффект принято называть ложными срабатываниями (false positive). Иногда с потерей некоторых писем можно смириться, в других случаях ложные срабатывания не допустимы. Для того чтобы уменьшить риск блокирования корректных сообщений, необходимо выполнять проверку на базе четко определенных критериев. Среди списков IP-адресов наименьшее число ложных срабатываний обеспечивают RBL и RSS. Списки IP-адресов RBL, RSS и DUL, поддерживаемые MAPS (Mail Abuse Prevention System — система борьбы с захватом почтовых программ), распространяются по подписке.

Как предотвратить использование вашего сервера для передачи спама

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

Если на отдельных рабочих станциях в сети установлены почтовые серверы, необходимо следить за тем, чтобы они не были сконфигурированы как открытые ретрансляторы (open relay). Открытым ретранслятором называется почтовый сервер, который принимает сообщения от любого компьютера, подключенного к Internet, и передает их по назначению. Многие дискуссии, посвященные использованию sendmail, по сути сводились к вопросу о предоставлении другим компьютерам доступа к серверу. Настраивая почтовый сервер, необходимо открыть его для некоторых систем, но при этом надо следить за тем, чтобы число таких систем не оказалось слишком велико.

Чтобы поверить, не является ли почтовый сервер открытым ретранслятором, следует с компьютера, на котором расположен этот сервер, обратиться с помощью telnet по адресу relay-test.mail-abuse.org. В результате удаленный компьютер обратится к вашему почтовому серверу и начнет проверку. Ход тестирования отобразится на экране, а в конце будет выведено сообщение о состоянии вашего сервера. Следует заметить, что этот тест не является исчерпывающим; существует конфигурация, не идеальная с точки зрения безопасности, не выявляемая при проверке.

Дополнительную информацию о конфигурациях, предназначенных для борьбы со спамом, можно найти по адресу http://mail-abuse.org/tsi/.

 

В настоящее время sendmail является самым популярным почтовым сервером в мире. Эта программа входит в состав различных дистрибутивных пакетов Linux, в том числе Caldera, Red Hat, Slackware, SuSE и TurboLinux. Несмотря на то что в Debian и Mandrake по умолчанию устанавливаются другие серверы SMTP, sendmail также входит в комплект поставки и при необходимости может заменить существующий почтовый сервер. Как было сказано ранее, в настоящее время доступна версия 8.12.2 sendmail, но некоторые дистрибутивные пакеты Linux до сих пор поставляются с 8.11.x и более ранними версиями.

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

 

Конфигурационные файлы

sendmail

Основной конфигурационный файл sendmail называется sendmail.cf; обычно он располагается в каталоге /etc. Этот файл содержит большое количество опций, представленных в виде, неудобном для восприятия, поэтому анализировать содержимое данного файла и редактировать его чрезвычайно сложно.

Обойти трудности, вызванные сложным форматом sendmail.cf, можно, создавая конфигурационный файл в простом и понятном формате, а затем преобразуя его с помощью утилиты m4 в файл sendmail.cf. Исходный файл, предназначенный для обработки программой заканчивается символами .mc, но конкретное его имя и расположение может изменяться в зависимости от версии операционной системы. В Red Hat это файл /etc/sendmail.mc, в Slackware — /usr/src/sendmail/cf/cf/linux.smtp.mc, а в SuSE — /etc/mail/linux.mc. Независимо от имени, исходный файл m4 гораздо меньше и удобнее для восприятия, чем создаваемый на его основе файл .cf. Например, если в системе SuSE 7.1 файл sendmail.cf содержит 1669 строк, то файл linux.mc состоит всего из 221 строки, причем основную часть файла занимают комментарии (строки комментариев начинаются символами dnl).

Для того чтобы создать файл sendmail.cf из файла m4, необходимо вызвать программу m4 и перенаправить ввод и вывод. В системе SuSE этот вызов имеет следующий вид:

# m4 < /etc/mail/linux.mc > /etc/sendmail.cf

На заметку

В некоторых версиях Linux перед тем как приступать к созданию файла sendmail.cf из исходного файла m4 , необходимо установить дополнительный пакет. Например, в Red Hat для создания конфигурационного файла нужен пакет sendmail-cf .

Внимание

Не следует изменять рабочий вариант файла sendmail.cf . Желательно скопировать файл sendmail.cf и исходный файл m4 в другой каталог. Если в результате редактирования вы повредите конфигурационный файл, то, используя созданную копию, вы сможете восстановить рабочую конфигурацию sendmail .

После изменения конфигурационного файла необходимо перезапустить sendmail. Во многих версиях Linux sendmail запускается с помощью сценария SysV, поэтому для перезапуска программы можно использовать опцию restart этого сценария.

Большинство записей в конфигурационном файле m4 задается в следующем формате:

ИМЯ_ХАРАКТЕРИСТИКИ (` опция1 '[, ` опция2 ' [,...])

Имя характеристики — это некоторое содержательное имя, например define или MASQUERADE_AS. В качестве опций могут быть указаны имена узлов, установки, специфические для sendmail, например always_add_domain, и т.д. В определениях некоторых характеристик одинарные кавычки можно не использовать.

Внимание

Кавычки, в которые помещаются опции, на первый взгляд выглядят несколько странно: в качестве открывающей и закрывающей используются различные типы кавычек. Необходимо следить за правильным их использованием. Если вы укажете в исходном файле обычные одинарные кавычки, то либо файл не будет обработан, либо конфигурационный файл sendmail.cf будет сформирован некорректно.

Помимо sendmail.cf, программа sendmail также использует при работе другие файлы.

• access.db. Этот двоичный файл создается на базе текстового файла access. Файл access.db определяет, какие компьютеры могут обращаться к программе sendmail. Конфигурация sendmail в качестве ретранслятора во многом зависит от содержимого этого файла. Многие сценарии запуска sendmail вызывают makemap, и если файл access изменился с момента последнего создания access.db, автоматически генерируется новый файл access.db.

• aliases.db. Этот двоичный файл также создается на базе текстового файла с аналогичным именем (aliases). Он определяет псевдонимы — имена, эквивалентные другим именам. Так, например, во многих дистрибутивных пакетах для пользователя root определяется псевдоним postmaster. Возможно, вы захотите создать псевдоним для root, чтобы просматривать почту суперпользователя посредством обычной учетной записи. Подобно файлу access.db, при выполнении многих сценариев запуска файл aliases.db генерируется автоматически.

Рассмотренные выше файлы обычно размещаются в каталоге /etc или /etc/mail. Кроме того, в этом каталоге находятся другие файлы баз данных, определяющие особенности работы sendmail.

 

Маскировка адреса sendmail

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

MASQUERADE_AS(` требуемый_адрес ')

FEATURE(masquerade_envelope)

Запись MASQUERADE_AS активизирует базовые средства маскировки, которые включают адрес в поле заголовка From: в случае, если пользовательская программа не задает имя узла. Поскольку большинство почтовых программ корректно заполняет это поле, данное средство в основном используется, если пользовательская программа сконфигурирована неправильно. Запись FEATURE(masquerade_envelope) изменяет поле From:, даже если в нем был задан адрес узла.

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

MASQUERADE_DOMAIN(` домен-источник ')

FEATURE(`limited_masquerade')

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

 

Настройка

sendmail

для получения почты

Когда удаленный сервер передает почту вашему серверу, письма адресованы конкретным пользователям, работающим на определенных компьютерах. Чтобы обеспечить доставку локальной почты, программа sendmail должна распознавать локальные адреса. Почтовый сервер sendmail поддерживает файл, в котором указываются адреса локальных узлов. В различных дистрибутивных пакетах для данного файла используются разные имена. В Red Hat это файл /etc/mail/local-host-names, а в SuSE — /etc/sendmail.cw. Если вам не удается обнаружить его, найдите в sendmail.cf запись, которая начинается символами Fw. Эта запись содержит имя файла, в котором указаны имена локальных узлов. Независимо от имени, содержимое файла представляет собой набор строк, в каждой из которых задано имя узла. Строки, начинающиеся с символа #, считаются комментариями.

 

Работа в режиме ретранслятора

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

Настройка sendmail для ретрансляции писем

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

По умолчанию почтовый сервер, инсталлированный в сети, не настроен для работы в качестве ретранслятора. При попытке передать письмо на сервер программа подготовки почты получит в ответ сообщение "relaying denied" ("ретрансляция запрещена"). Для того чтобы программа sendmail работала в качестве ретранслятора, надо активизировать соответствующие компоненты. В частности, в исходном конфигурационном файле необходимо задать записи FEATURE, указав в них следующие опции.

• relay_entire_domain. Если указана данная опция, sendmail принимает сообщения из своего домена, а также письма, адресованные пользователям в его домене. Для определения принадлежности к домену sendmail использует сервер DNS. Опция relay_entire_domain представляет собой удобное средство обеспечения ретрансляции.

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

• relay_based_on_MX. Данная опция означает, что сервер sendmail должен принимать письма в том случае, если в домене, которому принадлежит отправитель, присутствует запись MX, содержащая указание на этот сервер. Опция relay_based_on_MX обеспечивает простой и удобный способ управления ретрансляцией. Чтобы настроить почтовый сервер для поддержки еще одного домена, не надо вносить изменения в конфигурационные файлы sendmail, достаточно лишь изменить конфигурацию сервера DNS. Однако подобный подход имеет существенный недостаток. Спамеры, поддерживающие собственные домены, могут легко создать запись MX и использовать ваш сервер в своих целях.

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

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

Внимание

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

Ниже приведен пример записи в конфигурационном файле m4.

FEATURE(`access_db')

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

Как вы уже знаете, при запуске программа sendmail читает содержимое файла access.db. Этот файл обычно хранится в каталоге /etc или /etc/mail и создается на базе файла access. Пример файла access приведен ниже.

# Разрешить прием писем с localhost...

localhost.localdomain RELAY

localhost RELAY

127.0.0.1 RELAY

# Разрешить прием писем из локальной сети

192.168.99 RELAY

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

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

• OK. Эта опция сообщает sendmail о том, что локальные письма должны приниматься, несмотря на то, что другие правила требуют отвергать их.

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

• REJECT. Если вы собираетесь блокировать почту, поступающую с определенного узла или из определенного домена, вам следует использовать данную опцию. При этом письма будут возвращаться отправителю.

• DISCARD. Данная опция выполняет те же действия, что и REJECT, но письма не возвращаются отправителю.

• nnn текст . Эта опция также работает подобно REJECT, но в возвращаемое сообщение она включает код ошибки nnn и указанный текст.

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

# makemap hash /etc/mail/access.db < /etc/mail/access

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

Настройка sendmail для передачи почты через ретранслятор

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

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

FEATURE(`nullclient', `outgoing.mail.relay')

В данном случае outgoing.mail.relay — это имя компьютера, используемого для ретрансляции почты. После того как вы создадите файл sendmail.cf и перезапустите sendmail, вся исходящая почта будет передаваться через указанный почтовый сервер. Выполнив настройку sendmail, убедитесь, что письма корректно доставляются адресатам.

 

Конфигурация

sendmail

для противодействия попыткам передачи спама

Существует несколько способов настройки sendmail для блокирования поступающих рекламных сообщений и предотвращения попыток использования сервера для передачи спама. Один из способов состоит в использовании файла access и его двоичного аналога access.db. С помощью файла access.db можно блокировать спам на основании анализа адресов отправителей. Если вы зададите для некоторых доменов или компьютеров, указанных с помощью имени или IP-адреса, опции REJECT или DISCARD, сообщения из этих источников будут отвергаться. Если вы регулярно получаете рекламные сообщения с определенных адресов, этот способ позволит избавиться от них. Следуя описанному подходу, необходимо соблюдать осторожность, так как вместе со спамом будут отвергнуты и корректные сообщения, приходящие с тех же адресов или из тех же доменов. Если вы блокируете почту, поступающую из сети, которая принадлежит популярному провайдеру, вы рискуете потерять нужные вам письма.

Другой способ блокирования спама состоит в применении списков IP-адресов. Для того чтобы реализовать этот способ, надо указать в конфигурационном файле m4 опцию dnsbl.

FEATURE(dnsbl, `blackholes.mail-abuse.org', `Rejected - see \

http://www.mail-abuse.org/rbl/')

Данная запись указывает sendmail на то, что при проверке входящей почты должен использоваться список MAPS RBL. Если вы хотите использовать другой список, вам надо изменить вторую опцию в данной записи. Последнее поле записи содержит строку, которая включается в состав возвращаемого сообщения. В этой строке вы можете указать отправителю адрес Web-узла, содержащего список IP-адресов, на основании которого было отвергнуто его сообщение. Если окажется, что корректное сообщение было заблокировано по ошибке, его автор сможет принять меры для того, чтобы разрешить проблему.

На заметку

В версии 8.10 программы sendmail порядок использования списков IP-адресов был существенно изменен. В этой главе описаны правила, применяемые в этой и последующих реализациях. Дополнительную информацию по данному вопросу вы найдете по адресу http://mail-abuse.org/rbl/usage.html .

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

Внимание

Версии sendmail , предшествующие 8.9.0, настроены так, чтобы любой компьютер мог воспользоваться сервером для передачи писем. Такой сервер необходимо заменить новой версией или перенастроить его, чтобы неограниченные услуги ретранслятора не предоставлялись другим узлам. Информацию по этому вопросу вы найдете по адресу http://mail-abuse.org/tsi/ar-fix.html#sendmail_8 . Версии sendmail , предшествующие 8.8.4, перенастроить крайне сложно. Гораздо проще обновить почтовый сервер.

 

Сервер Exim применяется по умолчанию в Debian GNU/Linux и пользуется умеренной популярностью. Данный сервер можно использовать и с другими пакетами. Так, например, Exim поставляется в составе расширения PowerTools системы Red Hat, поэтому его достаточно легко установить в Red Hat и других подобных дистрибутивных пакетах. Подобно sendmail, Exim представляет собой единую программу, но формат конфигурационного файла Exim сравнительно прост. Exim обладает приблизительно такими же возможностями, как и sendmail; в данном разделе рассматриваются некоторые из них, например, маскировка адресов, обработка писем, адресованных в разные домены, и использование режима ретрансляции почты.

На заметку

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

 

Конфигурационные файлы Exim

Главный конфигурационный файл Exim называется exim.conf. Обычно он располагается в каталоге /etc. В состав этого файла входят записи, представленные в следующем формате:

опция = значение

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

Совет

При инсталляции Exim в системе Debian запускается сценарий с именем eximconfig , в процессе выполнения которого генерируется файл exim.conf . Данный сценарий можно использовать для изменения конфигурации Exim; при этом нет необходимости непосредственно редактировать файл exim.conf . Если вам надо внести лишь незначительные изменения в конфигурацию системы, удобнее модифицировать exim.conf вручную, так как при использовании eximconfig приходится отвечать на целый ряд вопросов. Во многих случаях eximconfig может оказаться очень полезным инструментом, в особенности если вы мало знакомы со структурой конфигурационного файла Exim. В частности, данный сценарий помогает выбрать значения опций, наиболее подходящие для вашей системы.

Помимо exim.conf, Exim использует в качестве источников дополнительной информации другие файлы. Файлы, применяемые данным сервером в системе Debian, перечислены ниже.

• /etc/aliases. Этот файл выполняет те же функции, что и аналогичный файл sendmail. Он позволяет связать две учетные записи так, что письмо, адресованное одному пользователю, будет направлено другому. Например, если в этом файле присутствует запись root: amelia, то письмо, адресованное root, получит пользователь amelia. В файле aliases можно также указывать адреса, не принадлежащие локальным пользователям. Например, наличие записи root: [email protected] приведет к тому, что письмо, принятое для локального пользователя root, будет перенаправлено по адресу [email protected]. В отличие от sendmail, в сервере Exim файл aliases не преобразовывается в двоичный формат.

• /etc/email-addresses. Записи в этом файле используются для изменения содержимого полей From: в заголовках исходящих сообщений. Например, наличие записи ben: [email protected] приведет к тому, что письмо, отправленное с локального компьютера пользователем ben, придет к получателю как сообщение от [email protected].

Сценарий eximconf создает в файле /etc/aliases записи, посредством которых почта, адресованная postmaster перенаправляется root, а письма, непосредственно направленные root, будут переданы пользователю, которого вы укажете. Содержимое описанных выше файлов можно удалять или модифицировать, а при необходимости вы можете включать в эти файлы новые записи. Файл /etc/email-addresses, создаваемый по умолчанию в системе Debian, содержит лишь комментарии.

 

Маскировка адресов

Как было сказано ранее, вам может потребоваться, чтобы в сообщениях вместо имени, возвращаемого по команде hostname, отображалось другое имя узла или домена. Основные средства маскировки адресов включаются посредством опции qualify_domain. С помощью данной опции задается имя домена. Если почтовая программа не сгенерирует информацию об адресе, имя домена будет автоматически включено в сообщение. Предположим, что в файле exim.conf присутствует следующая запись:

qualify_domain = threeroomco.com

Если пользователь ben отправит письмо, а программа, с помощью которой это письмо было подготовлено, не укажет в поле From: имя домена, то Exim добавит имя threeroomco.com. Если доменное имя адреса не соответствует имени threeroomco.com, то Exim заменит адрес. Таким образом, содержимое поля From: будет выглядеть так: [email protected].

Еще одна опция, которую можно использовать для маскировки адресов, называется primary_hostname. Она применяется подобно qualify_domain, и ее значение принимается в качестве значения по умолчанию для qualify_domain. Значение primary_hostname используется при переговорах о взаимодействии Exim и удаленного сервера имен. Имя, задаваемое посредством данной опции, применяется при формировании заголовка Received:.

Для более сложной маскировки адресов применяется файл /etc/email-addresses. Строго говоря, на файл /etc/email-addresses ссылается запись, расположенная в конце конфигурационного файла exim.conf. Эта запись имеет следующий вид:

*@threeroomco.com ${lookup{$1}lsearch{/etc/email-addresses}\

 {$value}fail} bcfrF

Это одна из наиболее сложных записей, содержащихся в файле exim.conf. При настройке сервера не следует редактировать ее, допустимо лишь изменить имя домена в начале строки. С помощью данной записи Exim проверяет каждый адрес на принадлежность домену threeroomco.com, а затем использует файл /etc/email-addresses для замены адреса. В первом поле записи, содержащейся в файле /etc/email-addresses (перед двоеточием), указывается почтовый адрес, предназначенный для сравнения, а во втором поле (после двоеточия) — адрес для замены. Данное средство позволяет выполнять маскировку для каждого пользователя; чтобы сделать это, достаточно лишь отредактировать файл email-addresses. При необходимости вы можете обрабатывать письма из разных доменов. Для этого надо либо продублировать приведенную выше запись в exim.conf, либо включить всю информацию, необходимую для замены адресов, в один файл email-addresses.

В данном разделе рассмотрены лишь некоторые средства маскировки адресов, предоставляемые Exim. Дополнительную информацию по этому вопросу вы можете получить в документации на Exim, обратившись по адресу http://www.exim.org/exim-html-3.30/doc/html/spec_34.html.

 

Настройка Exim для приема почты

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

• local_domains. В качестве значения данной опции задается список доменных имен, разделенных двоеточиями. Эти имена Exim должен интерпретировать как локальные. Например, запись local_domains = localhost: threeroomco.com сообщает Exim о том, что адреса localhost и threeroomco.com являются локальными и письма, в которых они указаны, необходимо непосредственно доставлять пользователям. По умолчанию значение данной опции принимается равным значению qualify_recipient. Опция qualify_recipient задает имя узла для входящих сообщений, в которых такая информация отсутствует.

• local_domains_include_host. Если значение данной опции равно true, Exim принимает письма, в адресе которых указано имя компьютера. Тот же результат можно получить, добавив имя узла к списку local_domains.

• local_domains_include_host_literals. Если значение данной опции равно true, Exim принимает письма, в которых указан IP-адрес компьютера. Например, если Exim выполняется на компьютере с адресом 172.24.98.2 и на этом компьютере имеется учетная запись пользователя ben, Exim примет письмо с адресом ben@[172.24.98.2]. Если вы не хотите, чтобы подобные письма обрабатывались сервером, необходимо установить значение false опции local_domains_include_host_literals.

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

 

Конфигурация Exim для ретрансляции писем

Подобно sendmail, в сервере Exim предусмотрен ряд опций, предназначенных как для ретрансляции писем, переданных другими программами, так и для использования в качестве ретрансляторов других серверов. Сценарий eximconfig задает администратору вопросы, касающиеся ретрансляции писем, и в большинстве случаев устанавливает приемлемую конфигурацию сервера. Уточнить настройку Exim можно с помощью непосредственного редактирования файла exim.conf.

Настройка Exim для работы в режиме ретранслятора

Основные опции exim.conf предназначенные для реализации режима ретрансляции писем, описаны ниже.

• host_accept_relay. Для того чтобы сервер Exim мог ретранслировать письма, переданные определенными компьютерами, вам надо указать в качестве значения данной опции их адреса (адреса отделяются друг от друга двоеточиями). В конфигурационном файле должно быть как минимум указано выражение host_accept_relay = localhost, позволяющее Exim передавать письма, подготовленные локальными почтовыми программами. По мере расширения списка (в котором могут быть указаны доменные имена, IP-адреса, а также использоваться символы групповых операций) увеличивается число компьютеров, которым позволено пользоваться услугами сервера для передачи почты. Например, выражение host_accept_relay = localhost:192.168.99.0/24:*.pangaea.edu указывает на то, что письма для передачи должны приниматься с локального узла, со всех узлов сети 192.168.99.0/24, а также со всех компьютеров домена pangaea.edu. Использование данной опции для указания IP-адресов компьютеров, принадлежащих домену, — один из самых безопасных способов обеспечения ретрансляции писем.

• relay_domains. В качестве значения данной опции можно указать одно или несколько имен доменов, разделенных двоеточиями. В результате сервер Exim будет обрабатывать письма, направленные с любого компьютера, принадлежащего указанным доменам. Эта опция полезна тогда, когда необходимо, чтобы сервер обслуживал несколько доменов или один большой домен. Аналогичных результатов можно добиться, включая символ групповой операции (*) в имена, задаваемые в качестве значения опции host_accept_relay.

• relay_domains_include_local_mx. Если вы зададите значение yes данной опции, доступ к почтовому серверу автоматически получат компьютеры, указанные в записях MX серверов DNS. Такой подход очень удобен, так как избавляет от необходимости перенастраивать Exim при изменении конфигурации домена. Однако в этом случае повышается опасность использования сервера спамерами, которые имеют возможность управлять доменом и включать в конфигурационный файл сервера DNS записи MX.

• sender_address_relay. В качестве значения данной опции задается список почтовых адресов, разделенных двоеточиями, для которых разрешено использование сервера в качестве ретранслятора. В обычных условиях письмо должно соответствовать как значению данной опции, так и адресу узла, указанному с помощью опции host_accept_relay. (Вы можете задать проверку на соответствие любой из этих опций, включив в конфигурационный файл выражение relay_match_host_or_sender = yes, но такая конфигурация опасна для системы, так как почтовый адрес легко подделать.) Данную опцию можно применить для того, что-бы ограничить круг пользователей, имеющих право использовать сервер в качестве ретранслятора.

Приведенные здесь опции позволяют настроить Exim для работы в режиме ретранслятора и указать, какие компьютеры локальной сети или внешних доменов имеют право доступа к данному серверу. Данные опции позволяют решать большинство задач по обеспечению ретрансляции почты. Если же вам необходимо установить специальную конфигурацию сервера, вы можете воспользоваться дополнительными опциями, например, host_auth_accept_relay (которая выполняет аутентификацию удаленной системы перед ретрансляцией писем) и tls_host_accept_relay (которая требует, чтобы удаленная система использовала средства аутентификации и кодирования TLS).

Настройка Exim для передачи почты через ретранслятор

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

smarthost:

 driver = domainlist

 transport = remote_smtp

 route_list = "* franklin.threeroomco.com bydns_a"

end

Приведенная выше группа записей сообщает Exim о том, что письма, адресованные внешним пользователям, надо передавать через узел franklin.threeroomco.com. Чтобы использовать другой ретранслятор, надо изменить значение соответствующей опции.

 

Настройка Exim для противодействия распространению спама

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

• host_reject. Данная опция задается в конфигурационном файле exim.conf. Ее значение представляет собой список имен узлов и доменов, а также IP-адресов, разделенных двоеточиями. Почта, переданная с компьютеров, указанных посредством данной опции, должна блокироваться. Например, запись host_reject = *.badspammer.net:10.16.8.0/24 указывает на то, что письма из домена badspammer.net, а также из сети 10.16.8.0/24 должны отвергаться. Система отказывается взаимодействовать с удаленным компьютером, заданным с помощью опции host_reject, уже на этапе установления соединения. В результате удаленный компьютер предпринимает повторные попытки обращения к вашему серверу, но связанная с этим дополнительная нагрузка на линии связи и компьютеры небольшая.

• host_reject_recipients. Данная опция действует так же, как host_reject, но почтовые сообщения отвергаются лишь в процессе взаимодействия с удаленной программой, в частности, в тот момент, когда она передает команду RCPT TO:. В результате попытки пересылки писем немедленно прекращаются.

• sender_reject. Данная опция блокирует письма от указанных отправителей. Роль отправителя может выполнять либо целый домен, либо отдельный пользователь в домене. Например, опция sender_reject = [email protected]:badspammer.net указывает на то, что письма из домена badspammer.net и от пользователя [email protected] должны отвергаться. Сервер Exim прекращает взаимодействие сразу же, как только сможет идентифицировать отправителя. В некоторых случаях это приводит к повторным попыткам передачи сообщений, предпринимаемым удаленными программами.

• sender_reject_recipients. Данная опция действует подобно опции sender_reject, но взаимодействие с удаленным компьютером прекращается после того, как выполняющаяся на нем программа укажет адрес получателя, т.е. передаст команду RCPT TO:. Данный подход более эффективен по сравнению с использованием опции sender_reject, так как при этом удаленная система больше не предпринимает попыток передачи сообщений.

• Фильтры, определяемые пользователем. Сервер Exim предоставляет пользователям возможность создавать собственные фильтры. Для их формирования используются файлы .forward, находящиеся в рабочих каталогах пользователей. Возможность создания новых фильтров превращает Exim в чрезвычайно мощный и гибкий инструмент. Фильтры, определяемые пользователем, во многом похожи на фильтры Procmail, которые будут рассматриваться далее в этой главе. Подробное описание средств создания пользовательских фильтров содержится файле filter.txt.gz, который поставляется в составе Exim. В Debian GNU/Linux этот файл располагается в каталоге /usr/doc/exim; распаковать его можно с помощью утилиты gunzip.

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

• rbl_domains. Значением этой опции является перечень адресов серверов, поддерживающих списки IP-адресов (эти серверы описаны в табл. 19.1). Адреса серверов разделяются двоеточиями и могут сопровождаться последовательностями символов /warn или /reject. Значение /warn указывает серверу Exim на то, что он должен добавить поле заголовка с предупреждающим сообщением (который впоследствии может быть использован фильтром Procmail), a /reject означает, что письмо должно быть отвергнуто. Кроме того, в составе данной опции могут также использоваться последовательности символов /accept (формирование "белого списка") и /skiprelay (если домен отправителя указан в опции host_accept_relay, то список IP-адресов не должен использоваться).

• rbl_hosts. По умолчанию принимается значение * данной опции; оно указывает на то, что сервер должен проверять все узлы, с которыми он взаимодействует, на соответствие спискам IP-адресов, указанных посредством опции rbl_domains. При необходимости вы можете освободить некоторые серверы от этой проверки. Чтобы сделать это, вам надо указать их имена перед символом *; каждому имени должен предшествовать символ !. Например, выражение rbl_hosts = !ok.pangaea.edu:* освобождает ok.pangaea.edu от проверки на принадлежность спискам IP-адресов.

• rbl_reject_recipients. Последовательности символов /warn и /reject в составе значения опции rbl_domains указывают, следует ли добавить к письму поле заголовка с предупреждающим сообщением или отказаться от получения письма. Если эти последовательности не указаны, Exim по умолчанию отказывается от письма. Изменить поведение сервера позволяет опция rbl_reject_recipients. Если вы зададите в конфигурационном файле выражение rbl_reject_recipients = no, Exim будет по умолчанию добавлять в заголовки писем предупреждающие сообщения.

• recipients_reject_except. Данная опция позволяет задавать исключения из списков IP-адресов. Например, если указана опция recipients_reject_except = [email protected], сервер Exim будет получать письма, адресованные пользователю [email protected], даже в том случае, если они были отправлены с компьютера, указанного в списке IP-адресов.

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

• headers_check_syntax. Exim может проверить формат сообщений и отвергнуть их, если они составлены некорректно. Серверы некоторых спамеров неправильно формируют заголовки, поэтому, отвергая подобные сообщения, вы избавляетесь от писем с рекламными сообщениями. Чтобы сервер блокировал некорректно составленные письма, необходимо задать значение true опции headers_check_syntax.

• helo_verify. В процессе взаимодействия по протоколу сервер SMTP передает команду HELO или EHLO, указывая в ее составе свое имя. Обычно Exim не требует этой команды, но при необходимости вы можете задать список узлов, которые должны соблюдать все правила взаимодействия серверов. Так, например, выражение helo_verifу = * указывает, что все удаленные серверы должны строго следовать протоколу обмена. Опция helo_verifу не только требует передавать команду HELO или EHLO, но также включает проверку соответствия IP-адресов доменным именам. Системы спамеров часто бывают неверно сконфигурированы, поэтому передаваемые ими письма не выдерживают подобной проверки. Однако следует учитывать, что серверы, с которых поступают обычные письма, также бывают некорректно настроены. В этом случае будут потеряны нужные вам сообщения.

• message_size_limit. Данная опция также имеет лишь отдаленное отношение к борьбе со спамом, но с ее помощью можно избавиться от некоторых рекламных сообщений. По умолчанию устанавливается значение 0 опции message_size_limit, которое отменяет ограничения на размер писем. Если вы зададите положительное значение данной опции, оно будет определять максимальный размер письма. Это предотвратит получение рекламных сообщений большого объема.

Средства фильтрации сообщений, предоставляемые Exim, и в особенности фильтры, определяемые пользователем, позволяют настроить систему в соответствии с вашими потребностями.

 

Как и в сервере Exim, конфигурационный файл Postfix достаточно прост. Настроить сервер Postfix сможет каждый, кто хотя бы поверхностно знает терминологию SMTP и способен понять назначение имен. Сервер Postfix имеет модульную структуру, т.е. его функции обеспечиваются совместным выполнением нескольких программ. Postfix предоставляет приблизительно те же возможности, что и Exim. Подобно другим серверам SMTP, Postfix обеспечивает маскировку адресов, прием писем, адресованных в локальные домены, работу в режиме ретрансляции почты, а также предоставляет возможность противодействия распространению спама.

Postfix по умолчанию используется в Mandrake, но также может быть установлен и в других системах, например в Debian и SuSE. Этот сервер также входит в состав PowerTools. RPM-пакет, предназначенный для Mandrake, может быть установлен в других дистрибутивных пакетах Linux, но сценарии содержащиеся в данном пакете, работать не будут. Поскольку Postfix чаще всего применяется совместно с Mandrake, материал данного раздела будет излагаться с учетом конфигурации Postfix, устанавливаемой по умолчанию для данной версии системы. Настройка Postfix для остальных систем отличается от конфигурации для Mandrake лишь отдельными деталями.

 

Конфигурационный файл Postfix

Особенности выполнения Postfix определяются содержимым конфигурационного файла main.cf, который обычно располагается в каталоге /etc/postfix. Большинство записей в этом файле представлены в следующем формате:

опция = значение

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

myhostname = franklin.threeroomco.com

myorigin = $myhostname

В первой записи переменной myhostname присваивается имя узла franklin.threeroomco.com, затем это же значение присваивается переменной myorigin. Подобные цепочки определений часто используются в Postfix, поэтому, чтобы определить значение переменной, надо проследить его, перемещаясь назад по конфигурационному файлу.

Файл main.cf в основном состоит из комментариев, которые содержатся в строках, начинающихся в символа #. Комментарии подробно описывают назначение каждой опции, поэтому вы можете достаточно подробно изучить конфигурацию Postfix, просматривая лишь содержимое конфигурационного файла.

В файле main.cf содержатся ссылки на другие файлы. Как и в сервере sendmail, некоторые из этих файлов (оканчивающиеся символами . представлены в двоичном формате. Они создаются на базе текстовых файлов с теми же именами, за исключением суффикса .db. В процессе использования сервера наиболее часто приходится редактировать файл aliases (который преобразуется в файл aliases.db). Как и в одноименном файле сервера sendmail, в файле aliases задаются псевдонимы, используемые при доставке писем. Например, запись root: amelia указывает на то, что все письма, адресованные root, должны быть доставлены пользователю amelia. Для того чтобы преобразовать текстовый файл aliases в двоичный файл aliases.db, надо вызвать команду postalias aliases, указав перед этим в качестве текущего каталог, в котором содержится файл aliases.

После того как вы модифицируете содержимое текстового файла и создадите файл .db, пройдет некоторое время перед тем, как Postfix учтет внесенные изменения. Для того чтобы ускорить этот процесс, необходимо задать команду postfix reload либо перезапустить Postfix, используя для этого сценарий SysV.

 

Маскировка адресов

Опция myorigin позволяет задать имя, под которым Postfix будет представляться при взаимодействии с другими системами. По умолчанию в качестве значения данной опции задается переменная $myhostname, которая, в свою очередь, определяет доменное имя компьютера. Конфигурация по умолчанию приемлема во многих случаях, но если вашему компьютеру соответствует несколько имен или если вы хотите вместо имени узла использовать имя домена, вам придется изменить настройку сервера. Для этого надо задать новое значение опции myorigin, например:

myorigin = threeroomco.com

При желании вы можете указать в качестве значения опции переменную, например $mydomain. По умолчанию значением переменной $mydomain является значение из которого исключен компонент, находящийся слева. Например, если переменная $myhostname имеет значение franklin.threeroomco.com, то значение $mydomain будет равно threeroomco.com. В файле main.conf содержится много закомментированных записей. В некоторых случаях вы можете изменить конфигурацию, выбрав подходящую для вас запись и удалив символ комментариев.

Опция myorigin определяет только базовые средства маскировки адресов. Значение данной опции используется лишь в ходе начальных переговоров с удаленным сервером, предусмотренных протоколом SMTP, и для указания доменного имени в поле From:, если соответствующие данные не были включены в это поле программой подготовки писем. Если ваш почтовый сервер выступает в качестве ретранслятора по отношению к другим системам вашего домена, которые, возможно, настроены для включения в заголовок полного адреса, вам потребуется выполнять более сложные действия по маскировке адресов. Предположим, например, что клиентская программа, использующая сервер Postfix для передачи писем, включает в поле From: адрес [email protected]. Предположим также, что вы хотите удалить идентификатор client так, чтобы адрес имел вид [email protected]. Учитывая, что значением переменной $mydomain является имя домена threeroomco.com, вы можете использовать для получения требуемого результата следующую запись:

masquerade_domains = $mydomain

Данная опция указывает серверу Postfix на то, что при обработке сообщения должна быть удалена часть доменного имени, не относящаяся к имени домена, указанного посредством переменной $mydomain. В результате в поля From: и To: вместо имени узла, принадлежащего домену $mydomain, будет записано имя домена.

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

sender_canonical_maps = hash:/etc/postfix/sender_canonical

В файл sender_canonical необходимо включить записи, используемые для преобразования имен. Каждая строка этого файла должна содержать адрес, который может находиться в составе заголовка, и адрес, которым он должен быть заменен. Следующие две строки заменяют имена client.threeroomco.com и localhost на threeroomco.com:

@client.threeroomco.com @threeroomco.com

@localhost @threeroomco.com

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

После создания файла sender_canonical его необходимо преобразовать в двоичный формат посредством команды postmap sender_canonical. Чтобы внесенные в файл изменения были учтены сервером Postfix, надо вызвать команду postfix reload либо перезапустить сервер.

Выполняя настройку сервера, необходимо ограничиваться минимально допустимым уровнем маскировки адресов. В большинстве случаев конфигурация, установленная по умолчанию, позволяет Postfix выполнять свои функции, иногда приходится лишь скорректировать значение myorigin. Опция masquerade_domains в основном применяется в тех случаях, когда сервер принимает для передачи письма, которые уже были обработаны почтовым сервером, выполняющимся в системе Linux или UNIX. Средства преобразования адресов воздействуют не только на заголовок From:, они также затрагивают содержимое заголовка Received:. Многие администраторы неохотно используют данные средства, но в ряде случаев они могут быть очень полезны, особенно если ваши программы требуют, чтобы имена и адреса в поле From: были представлены в специальном формате.

 

Настройка Postfix для получения почты

Подобно другим почтовым серверам, Postfix считает локальными только адреса некоторых узлов. Чтобы определить, какой из компьютеров является локальным, Postfix использует опцию mydestination. По умолчанию для данной опции приняты значения $myhostname и localhost.$mydomain. Например, если переменная $mydomain имеет значение threeroomco.com, a $myhostname — franklin.threeroomco.com, то Postfix будет принимать письма, направленные на компьютеры franklin.threeroomco.com и localhost.threeroomco.com.

При необходимости вы можете изменить или дополнить значения данной опции. Например, если почтовый сервер обслуживает домен, вам необходимо добавить переменную $mydomain. Неплохо также указать для данной опции значение localhost. Значения опции mydestination отделяются друг от друга запятыми. Например, для почтового сервера, обслуживающего один домен, в конфигурационный файл можно включить следующее выражение:

mydestination = localhost, localhost.$mydomain, $myhostname,

 $mydomain

На заметку

Для того чтобы указать, что опция mydestination занимает несколько строк, символ \ использовать не надо. Строка считается продолжением предыдущей, если она начинается с пробела или знака табуляции.

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

 

Конфигурация Postfix для ретрансляции писем

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

Настройка Postfix для работы в режиме ретранслятора

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

• Отправитель находится в одной из сетей, указанных с помощью переменной $mynetworks. По умолчанию в качестве значения этой переменной заданы адреса сетей, которым принадлежат все сетевые интерфейсы компьютера, в том числе интерфейс localhost.

• Отправитель принадлежит домену, указанному в переменной $relay_domains. По умолчанию значение данной переменной равно значению переменной $mydestination.

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

Конфигурация по умолчанию указывает на то, что Postfix должен обрабатывать почту из того домена, которому принадлежит сам сервер, и от компьютеров, непосредственно связанных с сервером, посредством сетевых интерфейсов. В большинстве случаев такая конфигурация вполне приемлема, но иногда приходится изменять ее. Чтобы сделать это, вам надо изменить значение $mynetworks или $relay_domains (либо модифицировать обе переменные). Предположим, например, что Postfix должен обслуживать рабочую станцию work.threeroomco.com. Для этого вам надо переопределить значения переменных следующим образом:

mynetworks = 127.0.0.0/8

relay_domains = work.threeroomco.com

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

mynetworks = 192.168.99.0/24, 172.24.0.0/16, 127.0.0.0/8

relay_domains = $raydestination, pangaea.edu

Данные опции сообщают о том, что письма должны приниматься из сетей 192.168.99.0/24, 172.24.0.0/16 и localhost (127.0.0.0/8), а также с компьютеров, принадлежащих доменам $mydestination и pangaea.edu.

Для управления действием mynetworks, relay_domains и некоторых других опций может использоваться опция smtpd_sender_restrictions. По умолчанию эта опция отсутствует в main.cf, но при необходимости вы можете включить ее в состав конфигурационного файла. Значение permit_mx_backup данной опции соответствует опции relay_based_on_MX сервера sendmail. Подробные сведения о smtpd_sender_restrictions вы найдете в документации на сервер Postfix.

Настройка Postfix для передачи почты через ретранслятор

В простейшем случае, чтобы сконфигурировать Postfix для передачи почты посредством другого сервера, достаточно установить значение опции relayhost. Эта опция, находящаяся в файле main.cf, указывает на компьютер, выполняющий функции ретранслятора. Если в конфигурационном файле сервера имен, управляющего доменом, присутствует запись MX, указывающая на сервер-ретранслятор, то в качестве значения опции relayhost можно задать имя этого домена. Например, если в роли ретранслятора выступает сервер, расположенный на компьютере franklin.threeroomco.com, в файл main.cf необходимо включить следующую запись:

relayhost = franklin.threeroomco.com

Если ваш сервер находится в том же домене, что и сервер-ретранслятор, и если на ретранслятор, указывает запись MX, то вместо имени franklin.threeroomco.com вы можете использовать переменную $mydomain. Такой подход предпочтительнее тем, что переносе почтового сервера, обслуживающего домен, на другой компьютер перенастраивать Postfix не приходится.

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

disable_dns_lookups = yes

Эта опция указывает серверу Postfix на то, что он не должен обращаться к серверу DNS для преобразования имен. В этом случае Postfix определяет адрес ретранслятора с помощью записи в файле /etc/hosts.

 

Настройка Postfix для противодействия распространению спама

Подобно sendmail и Exim, Postfix содержит средства, позволяющие бороться с распространением спама. Вы можете блокировать рекламные сообщения, сравнивая информацию в заголовках писем с шаблонами, либо использовать списки IP-адресов.

Инструменты для сравнения с шаблонами, предоставляемые сервером Postfix, достаточно сложны, в частности, они позволяют использовать для анализа содержимого заголовков регулярные выражения. Регулярные выражения часто указываются в отдельном файле, но при желании вы можете задавать их непосредственно в конфигурационном файле main.cf. Пример опции, предназначенной для проверки заголовков, приведен ниже.

header_checks = regexp:/etc/postfix/bad_headers

В файле bad_headers указываются регулярные выражения, подобные приведенным в листинге 19.2. Если заголовки почтового сообщения соответствуют регулярным выражениям, содержащимся в файле, и если в файле указано, что письмо должно быть отвергнуто, оно возвращается отправителю. Регулярные выражения могут задаваться либо в стиле POSIX (regeхр: описание ) , либо в стиле PCRE (pcre: описание ) .

Листинг 19.2. Файл с регулярными выражениями Postfix, используемыми для фильтрации спама

#### Поля Subject: заголовков сообщений, полученных от спамеров

/^Subject: ADV:/ REJECT

/^Subject: Accept Visa/ REJECT

#### Поля From: и Received: заголовков сообщений,

#### полученных от спамеров

/^(From|Received):.*badspammer\.net/REJECT

/^From: spammer@abigisp\ .net/ REJECT

На заметку

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

Опция header_checks предоставляет большие возможности, но она сложна в использовании. Более простое решение проблемы спама состоит в применении списков IP-адресов. Для работы с такими списками предназначены две приведенные ниже опции.

maps_rbl_domains = relays.mail-abuse.org, dialups.mail-abuse.org

smtpd_client_restrictions = reject_maps_rbl

Опция maps_rbl_domains позволяет задавать адреса серверов, управляющих списками IP-адресов (эти серверы описаны в табл. 19.1). В качестве значения данной опции можно указать несколько доменных имен, разделенных запятыми или пробелами. Опция, содержащаяся во второй из приведенных выше строк, указывает на то, что информация, предоставляемая серверами, должна использоваться как основание для блокирования писем. Кроме reject_maps_rbl, опция smtpd_client_restrictions может также принимать другие значения. Например, значение reject_unknown_client сообщает Postfix, что если для адреса отправителя не может быть выполнено обратное DNS-преобразование, письма не должны обрабатываться. Подробнее эти опции описаны в документации на Postfix.

Помимо описанных выше опций, Postfix предоставляет также опции, имеющие лишь косвенное отношение к борьбе со спамом. Некоторые из таких опций описаны ниже.

• smtpd_helo_required. По умолчанию для данной опции задается значение по. Если вы измените его на yes, Postfix будет обрабатывать письмо только в том случае, если при обмене по протоколу SMTP отправитель передаст команду HELO или EHLO. Этот подход позволяет блокировать действия некорректно написанных программ, часто используемых для распространения спама, но также отвергает обычные письма, отправляемые посредством неправильно сконфигурированного сервера SMTP.

• smtpd_helo_restrictions. Данная опция позволяет Postfix более строго контролировать использование команды HELO или EHLO при SMTP-взаимодействии. Для опции smtpd_helo_restrictions предусмотрено несколько значений. Например, reject_unknown_hostname означает, что Postfix должен прекратить взаимодействие, если для указанного доменного имени не может быть обнаружена запись А или MX. Значение reject_non_fqdn_hostname требует, чтобы отправитель указал полное доменное имя узла. Более подробное описание опции smtpd_helo_restrictions приведено в документации на сервер Postfix.

• smtpd_sender_restrictions. Если в конфигурационном файле Postfix указана данная опция, это означает, что информация в поле From: заголовка должна соответствовать определенным критериям. Например, значение reject_unknown_sender_domain указывает на то, что если в поле From: не задано имя узла, письмо должно быть отвергнуто, а значение reject_non_fqdn_sender требует, чтобы отправитель включал в адрес полностью определенное доменное имя.

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

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

 

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

 

Роль Procmail в процессе доставки почты

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

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

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

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

С помощью Procmail могут создаваться фильтры для всей системы или для отдельных пользователей. Например, фильтры, действующие в пределах системы, могут использоваться для блокирования спама и борьбы с вирусами. Отдельные пользователи могут применять Procmail для распределения сообщений по папкам и выполнения других подобных действий. Конфигурация Procmail для использования в рамках системы задается с помощью файла /etc/procmailrc. Для индивидуального применения Procmail настраивается посредством файлов .procmailrc, расположенных в рабочих каталогах пользователей. Файлы, предназначенные для отдельных пользователей, имеют тот же формат, что и файлы, ориентированные на применение во всей системе.

Внимание

В большинстве версий Linux файл /etc/procmailrc используется тогда, когда Procmail запускается по инициативе пользователя root. Поэтому надо внимательно следить за тем, чтобы команды, выполняемые Procmail, не нанесли вреда системе. Кроме того, перенаправляя почту, необходимо принимать меры для того, чтобы создаваемые файлы были доступны для чтения пользователям, которым они предназначены. При работе с файлами .procmailrc , расположенными в пользовательских каталогах, подробные проблемы не возникают, так как в этом случае Procmail выполняется с привилегиями обычного пользователя.

В конфигурационном файле Procmail содержатся записи трех типов.

• Комментарии. Как и во многих других конфигурационных файлах, строки, содержащие комментарии, начинаются с символа #.

• Записи, определяющие переменные окружения. В процессе работы Procmail использует значения переменных окружения, например $HOME (расположение рабочего каталога пользователя) и $MAILDIR (каталог, в котором содержатся пользовательские папки для хранения почтовых сообщений). Значения переменных окружения устанавливаются в конфигурационном файле так же, как и в оболочке. Например, запись MAILDIR = $HOME/Mail задает для переменной окружения $MAILDIR значение, указывающее на подкаталог Mail, находящийся в рабочем каталоге пользователя.

• Рецепты. Правила фильтрации Procmail называются рецептами (recipe). Основная работа по построению фильтра сводится к созданию рецепта. Каждый рецепт содержит правила, определяющие обработку сообщения, соответствующего некоторому регулярному выражению. Таким образом, полный набор правил состоит из многих рецептов. Рецепты разделяются на две категории: рецепты с доставкой (delivering) и рецепты без доставки (nondelivering). Рецепты с доставкой ориентированы на включение сообщения в состав почтового ящика, блокирование сообщения или обработку его с помощью другой программы. Рецепты без доставки определяют вложенные рецепты, т.е. приводят к повторной обработке сообщения с помощью Procmail.

Описанные три типа записей могут располагаться в пределах конфигурационного файла в любой последовательности. Многие конфигурационные файлы Procmail начинаются с определения переменных окружения, за которыми следует набор рецептов. В процессе обработки поступающей почты Procmail сканирует письма и проверяет их на соответствие рецептам. Если письмо не соответствует ни одному рецепту, Procmail доставляет его в файл, определяемый посредством переменной $DEFAULT. Обычно это почтовый ящик, используемый по умолчанию, например /var/spool/mail/ имя_пользователя .

 

Создание рецепта

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

:0 [ флаги ] [:[ файл_блокировки ]]

[ условия ]

действие

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

Идентификационная строка

Каждый рецепт начинается с символов :0. Цифра 0 не имеет специального значения, и рецептов, начинающихся с :1 или больших номеров, не существует. После :0 вы можете задать один или несколько флагов, которые изменяют поведение Procmail. Наиболее часто используются следующие флаги.

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

• В. Этот флаг задает сравнение тела сообщения с шаблоном.

• D. По умолчанию при сравнении с шаблоном не учитывается регистр символов. Флаг D отменяет это соглашение.

• с. Данный флаг указывает на то, что рецепт должен работать с "копией" исходного сообщения. Его "оригинал" сохраняется для обработки другими рецептами.

• w. Этот флаг сообщает о том, что Procmail должен ожидать завершения действия, указанного в рецепте. Если действие не окончилось успешно, сообщение остается в очереди для обработки посредством других рецептов.

• W. Данный флаг действует подобно w, но подавляет сообщения об ошибках.

После флагов можно указать двоеточие и имя файла блокировки. Файл блокировки — это специальный файл, который сообщает о том, что в данный момент происходит работа с другим файлом. При наличии файла Procmail откладывает обработку сообщения до тех пор, пока этот файл не будет удален. Файл блокировки удобно использовать в тех случаях, когда в очереди содержится много сообщений; ,без него может возникнуть ситуация, когда сообщения, принятые одно за другим, будут записаны в неверном порядке. По умолчанию имя файла блокировки строится на основе имени файла, в который помещается почта (этот файл указывается в строке действия). Если в строке действия задается обработка сообщения другой программой, вы можете указать имя файла блокировки после двоеточия.

Условия

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

• ^. Указывает на начало строки. Этот символ указывается во многих условиях Procmail после символа *.

• $. Данный символ указывает на конец строки.

• .. Точке соответствует любой символ, кроме символа новой строки. Например, выражению удовлетворяют dog, dig, dug и любая другая трехсимвольная последовательность, которая начинается с d и заканчивается g.

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

• a+. Это выражение выполняет те же действия, что и a*, но количество символов в последовательности не может быть нулевым.

• a?. Данное выражение означает, что указанный символ может отсутствовать.

• последовательность1 | последовательность2 . Чтобы указать на то, что в строке может присутствовать одна из двух последовательностей символов, надо разделить эти последовательности символом |. При необходимости вы можете задать выбор более чем из двух альтернативных вариантов, использовав несколько символов |.

• ( последовательность )* . Это выражение похоже на a*, но оно означает многократное повторение не одного символа, а целой последовательности.

• [ символы ] . Набор символов, помещенных в квадратные скобки, означает, что в строке должен присутствовать любой из них. Например, выражению [aeiou] соответствуют символы а, е, i, о или u. Если два символа разделены дефисом (-), они задают диапазон символов. Например, выражению [m-q] соответствуют символы m, n, о, p или q.

• \. Обратная косая черта отменяет специальное значение символа. Например, выражение \. соответствует обычной точке.

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

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

• !. Данный символ инвертирует результат сравнения. Если условие начинается с символа !, то, для того, чтобы письмо соответствовало рецепту, оно не должно соответствовать данному условию. Например, вы можете создать рецепт, которому соответствуют все сообщения, кроме адресованных пользователю postmaster.

• <. Условие применяется в том случае, если длина сообщения меньше указанного числа байтов.

• >. Условие применяется в том случае, если длина сообщения больше указанного числа байтов.

Действие

Действие в составе рецепта занимает одну строку и указывает Procmail, как следует обрабатывать сообщение. Простое действие лишь задает имя файла, в который Procmail должен поместить сообщение. Действия Procmail хорошо сочетаются с sendmail, Exim, Postfix и другими серверами, использующими формат mbox. Если же вы работаете с qmail или другим сервером, поддерживающим формат maildir, описание действия Procmail необходимо завершать косой чертой (/), которая указывает на то, что Procmail должен сохранить сообщение в формате maildir. Procmail также поддерживает еще один формат хранения сообщений, для использования которого описание действия должно заканчиваться косой чертой и точкой.

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

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

• |. В оболочках UNIX вертикальная черта используется для организации конвейерной обработки данных. В Procmail данный символ имеет аналогичное назначение. Если описание действия начинается с вертикальной черты, Procmail запускает указанную программу и передает ей сообщение для обработки. Вы можете использовать данную возможность для выполнения более сложных действий над сообщениями.

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

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

 

Пример использования рецептов

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

Листинг 19.3. Пример конфигурационного файла Procmail

MAILDIR = $HOME/Mail

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

# адресованные пользователю postmaster или отправленные им

:0

*! (From|To) : . *postmaster

{

 : 0 В

 * .*301.*S.*1618 /dev/null

 :0

 * From: .*badspammer\.net

 /dev/null

 :0

 * Subject:.*\$\$\$

 /dev/null

}

# Проверка по ключевым словам rug и david и

# перенаправление писем адресату

:0 с

* From: . *david@pangaea\.edu

* Subject: . *rug

! [email protected]

# Сообщения списков рассылки помещаются в отдельную папку

:0:

* То: . *list@mailinglist\ .example\ .com

$MAILDIR/mailinglist

Листинг 19.3 иллюстрирует некоторые важные особенности рецептов Procmail.

• Вложенные рецепты. Рецепты, выполняющие блокировку спама, содержатся в со­ставе другого рецепта, в результате эти фильтры применяются только для тех сообщений, которые адресованы пользователям, отличным от postmaster. (Это достигается посредством оператора отрицания, указанного в условиях включающего рецепта.) Аналогичный результат можно получить, включив условие *! \ То: .*postmaster в состав каждого из фильтров, предназначенных для блокирования спама. В данном простом примере это может несколько сократить объем конфигурационного файла. В более сложных фильтрах при использовании вложенных рецептов объем файла уменьшается. Кроме того, применение вложенных фильтров уменьшает вероятность ошибки, так как некоторые условия при этом указываются однократно.

• Регулярные выражения. В листинге 19.3 содержатся три рецепта, предназначенные для фильтрации рекламных сообщений. Первый из них проверяет тело сообщения (на это указывает флаг В) на наличие строки, содержащей последовательности 301, S и 1618. Этот рецепт предназначен для перехвата писем, содержащих указание на раздел 301 и номер S.1618, которые часто используются спамерами для создания иллюзии официального сообщения. Второй из рецептов, предназначенных для фильтрации спама, блокирует все письма из домена badspammer.net, а третий фильтр блокирует сообщения, содержащие в поле Subject: последовательность $$$. Обратите внимание на использование обратной косой черты для отмены специального значения символов. Все три рассматриваемых здесь рецепта направляют сообщения в файл /dev/null, т.е. удаляют их. После копирования в файл /dev/null письма уже не могут быть восстановлены. Файл блокировки для этих рецептов не требуется, так как сообщения не сохраняются ни в одной папке.

• Копирование сообщений. Вместо того чтобы записывать сообщение в файл, второй рецепт, приведенный в рассматриваемом примере, передает его другому пользователю. На это указывают флаг с и восклицательный знак в начале описания действия. Сообщение должно удовлетворять двум критериям: отправителем его должен быть пользователь [email protected], и оно должно содержать слово rug в поле заголовка Subject:. Если хотя бы одно из условий не выполняется, сообщение не копируется.

• Сортировка сообщений. Последний рецепт распределяет сообщения по папкам. Письма, адресованные [email protected], помещаются в отдельную папку, расположенную в подкаталоге рабочего каталога пользователя, предназначенного для работы с почтой. Во многих списках рассылки поле заголовка сообщения используется для идентификации самого списка, а информация о получателе сообщения включается в поле То: заголовка конверта. Для того чтобы выбрать наиболее удобный способ распределения писем по папкам, вам следует выяснить, какие данные содержатся в заголовках писем, распространяемых посредством списков рассылки.

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

 

Использование существующих наборов фильтров

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

• SpamBouncer. Этот пакет представляет собой набор фильтров Procmail, предназначенных для блокирования спама. Фильтры, входящие в состав SpamBouncer, достаточно сложны, но при необходимости вы можете адаптировать некоторые из них для решения собственных задач. Подробно эти фильтры описаны в документации, поставляемой в составе пакета. Чтобы скопировать SpamBouncer, надо обратиться на его Web-страницу, расположенную по адресу http://www.spambouncer.org.

• SmartList. Этот пакет, реализующий список рассылки, создан на основе Procmail. Дополнительную информацию о нем вы можете получить из документа SmartList FAQ, доступного по адресу http://www.hartzler.net/smartlist/SmartList-FAQ.html.

• Советы и рецепты Тимо. Тимо Салми (Timo Salmi) поддерживает Web-страницу (http://www.uwasa.fi/~ts/info/proctips.html), посредством которой он распространяет информацию о простых рецептах Procmail. Информацию, представленную на этой странице, нельзя рассматривать как готовый к использованию пакет, такой как SpamBouncer или SmartList, однако вы можете найти на ней "заготовки" для своих фильтров.

• Примеры рецептов Procmail с комментариями. Web-узел http://handsonhowto.com/pmail102.html содержит примеры рецептов Procmail, снабженные комментариями, которые поясняют их работу.

Дополнительную информацию о фильтрах и рецептах, пригодных для использования, вы получите, выполнив в Internet поиск по ключевым словам Procmail recipes. Многие полезные ссылки можно найти на Web-узле Procmail по адресу http://www.procmail.org.

Простые наборы фильтров можно разместить в рабочем каталоге пользователя в файле .procmailrc. Если фильтр должен воздействовать на систему в целом, его надо включить в файл /etc/procmailrc. Некоторые пакеты, например SpamBouncer, содержат специальные файлы, поэтому при инсталляции необходимо следить, чтобы они были установлены корректно.

Внимание

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

Совет

Как системный администратор, вы можете позволить себе роскошь создать специальную учетную запись для тестирования. Такую запись удобно использовать для проверки фильтров Procmail. Пробные сообщения можно передавать, изменив настройку программы подготовки писем и даже непосредственно взаимодействуя с сервером SMTP посредством программы telnet (для этого надо при установлении соединения указать порт 25).

 

Запуск Procmail

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

• sendmail. Чтобы настроить сервер для использования Procmail, необходимо включить в конфигурационный файл m4 три записи. Первая из них,

define(`PROCMAIL_MAILER_PATH' , `/usr/bin/procmail' ),

сообщает sendmail о том, где расположены двоичные файлы Procmail. Записи FEATURE(local_procmail) и MAILER(procmail) указывают sendmail на необходимость использования Procmail при доставке почты.

• Exim. Около двух третей конфигурационного файла exim.conf, используемого по умолчанию, занимает раздел procmail_pipe. Этот раздел посвящен использованию Procmail для доставки почты. Убедитесь, что данный раздел присутствует в конфигурационном файле и что в нем указан требуемый двоичный файл.

• Postfix. В конфигурационном файле main.cf, используемом по умолчанию, для вызова Procmail применяется опция mailbox_command. Если вы не укажете эту опцию, Postfix будет доставлять почту, минуя Procmail.

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

"|IFS=' ' &&p=/usr/bin/procmail&&test -f $p&&exec $p \

-Yf-||exit 75 # имя_пользователя "

Следите за тем, чтобы одинарные и двойные кавычки были указаны точно так, как в этом примере.

 

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

 

Конфигурационные файлы Apache

В большинстве пакетов основной конфигурационный файл Apache носит имя httpd.conf. В зависимости от версии системы этот файл может находиться в разных каталогах, но формат его остается неизменным. В системах Caldera и SuSE файл httpd.conf содержится в каталоге /etc/httpd; в Debian и Slackware он размещается в /etc/apache (Slackware предоставляет файл-образец /etc/apache/httpd.conf.default; для обеспечения работы сервера надо лишь переименовать данный файл и внести в него необходимые изменения); в Red Hat и TurboLinux файл httpd.conf размещается в каталоге /etc/httpd/conf/.

Как обычно, строки файла httpd.conf, начинающиеся с символа #, содержат комментарии. Опции, определяющие конфигурацию сервера, задаются в следующем виде:

Директива Значение

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

 Options FollowSymLinks

 AllowOverride None

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

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

• access.conf. Ссылка на этот файл формируется с помощью директивы AccessConfig и содержится в файле httpd.conf. В файле access.conf чаще всего задаются директивы , определяющие особенности доступа к указанным в них каталогам. В настоящее время этот файл обычно остается пустым, а иногда в качестве значения AccessConfig задается /dev/null, что запрещает использование access.conf.

• mime.types. Для того чтобы сообщить Web-броузеру о том, как должны обрабатываться данные, Web-сервер использует стандарт MIME (Multipurpose Internet Mail Extensions — многоцелевые почтовые расширений Internet). Например, MIME-тип text/plain означает, что данные представляют собой обычный текст, а image/jpeg определяет графические данные в формате JPEG (Joint Photographic Experts Group — объединенная группа экспертов по обработке фотоснимков). Файл mime.types содержит информацию о соответствии между MIME-типами и расширениями файлов. Например, имена файлов, оканчивающиеся .txt и .asc, связываются с MIME-типом text/plain. Если такое соответствие задано неправильно, Web-броузер будет испытывать затруднения при обработке некоторых типов файлов. Файл, поставляемый в составе пакета, обеспечивает обработку практически любых типов данных, которые могут быть помещены на Web-страницу. Если же вам надо использовать редко встречающиеся типы, вам придется добавить в этот файл новые записи.

• magic. Этот файл также позволяет определять соответствие между MIME-типами и данными. При анализе информации можно обнаружить специфические признаки того или иного типа. Так, например, многие файлы содержат специальные ключи — "магические" байтовые последовательности. Эти последовательности, преобразованные в текстовый вид, указываются в файле magic. Если вы подробно не изучили формат этого файла, вносить изменения в него не рекомендуется. Структура файла magic в данной главе рассматриваться не будет.

 

Способы запуска сервера Apache

В главе 4 были описаны различные способы запуска серверов на выполнение. Apache может быть запущен любым из этих способов; с помощью суперсервера, сценария запуска SysV либо локального сценария. В большинстве дистрибутивных пакетов предусмотрен запуск сервера с помощью сценария SysV или локального сценария, так как эти способы обеспечивают постоянное присутствие сервера в памяти и, следовательно, уменьшают задержку при генерации ответа на запрос клиента. При необходимости вы можете также обеспечить запуск Apache посредством суперсервера; программа инсталляции системы Debian даже задает вопрос о том, каким способом должен запускаться сервер. Однако при использовании суперсервера скорость обработки запросов снизится, так как, получив запрос, суперсервер должен будет загрузить Apache.

Совет

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

Если вы собираетесь изменить способ запуска Apache, вам следует скорректировать значение опции ServerType. Эта опция находится в конфигурационном файле Apache и может принимать значение standalone или inetd. Если вы неправильно укажете значение этой опции, Apache будет работать некорректно либо вовсе не будет обрабатывать запросы. Так, например, если вы захотите отказаться от сценария SysV и перейти к запуску Apache посредством inetd, вам следует сначала внести изменения в конфигурационный файл суперсервера, затем с помощью сценария SysV завершить выполнение Apache, запретить использование сценария SysV, потом отредактировать файл /etc/inetd.conf и, наконец, перезапустить inetd. Если вы забудете выполнить хотя бы одно из описанных здесь действий, сервер будет работать некорректно или продолжит работу с использованием старой конфигурации.

На заметку

В некоторых пакетах исполняемый файл Apache называется apache , в других — httpd. Если вы собираетесь изменить сценарий запуска или завершить работу сервера, необходимо правильно указать имя программы.

 

Опции общего назначения

Конфигурация, устанавливаемая по умолчанию, во многих случаях обеспечивает работоспособность сервера. После инсталляции сервера и его запуска Apache готов предоставить пользователям файлы из каталога по умолчанию (обычно это каталог /home/httpd/html). В этот каталог при установке Apache помещаются файлы, содержащие в основном информацию о том, что сервер инсталлирован, но настройка его еще не закончена. Впоследствии вы, вероятно, замените их теми файлами, которые и будут составлять содержимое Web-узла.

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

• ServerType. Эта директива уже рассматривалась ранее. Она может принимать значение standalone или inetd.

• User и Group. В системе Linux каждый сервер запускается от имени конкретного пользователя и группы. Эти директивы позволяют указать пользователя и группу, с полномочиями которых будет выполняться сервер Apache. В большинстве дистрибутивных пакетов Apache запускается от имени пользователя nobody либо с помощью учетной записи, специально созданной для данной цели и предусматривающей минимальные привилегии пользователя. Такой подход снижает вероятность того, что злоумышленник сможет воспользоваться недостатками в защите сервера для незаконного проникновения в систему. Рекомендуется принять значения этих опций, установленные при инсталляции системы.

На заметку

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

• ServerTokens. Сервер Apache предоставляет клиентской программе информацию о платформе, на которой он выполняется. В большинстве пакетов по умолчанию для этой опции задается значение ProductOnly, которое запрещает передавать клиенту сведения о системе. При желании вы можете задать значение OS или Full (эти значения расположены в порядке возрастания объема информации, передаваемой клиенту), но в целях повышения безопасности рекомендуется принять значение ProductOnly, установленное при инсталляции.

Внимание

Не следует считать, что, установив значение ProductOnly опции ServerTokens , вы лишите взломщика возможности получить данные о системе. Он по-прежнему может анализировать трафик и не только выяснить тот факт, что вы используете Linux, но и узнать версию системы. Кроме того, сведения о платформе могут предоставлять другие серверы.

• MinSpareServers и MaxSpareServers. Если Apache должен постоянно присутствовать в сети, для более эффективного обслуживания клиентских запросов в системе обычно запускается несколько экземпляров сервера. Каждый экземпляр обрабатывает отдельный запрос. Директивы MinSpareServers и MaxSpareServers позволяют задать минимальное и максимальное число экземпляров сервера, не участвующих в обработке запросов. Если число экземпляров сервера меньше, чем значение директивы MinSpareServers, то даже если они не выполняют обработку запросов, главный процесс Apache порождает новые процессы. Аналогично, если число неиспользуемых экземпляров сервера становится больше, чем значение директивы MaxSpareServers, лишние процессы завершаются. Если значения этих директив слишком малы, то в моменты интенсивных обращений к серверу время, необходимое для получения ответа на запрос, будет увеличиваться. Если же значения директив окажутся слишком большими, то памяти компьютера может оказаться недостаточно для размещения процессов сервера. При установке сервера по умолчанию задаются значения 5 и 10. Если нагрузка на сервер небольшая, вы можете уменьшить значения MinSpareServers и MaxSpareServers и проверить, как система отреагирует на это. Если же клиенты часто обращаются к серверу, вам, возможно, потребуются более высокие значения данных директив. Заметьте, что в некоторый момент времени общее число процессов Apache может превысить значение MaxSpareServers, так как некоторые из них заняты обработкой запросов клиентов и не рассматриваются как свободные. Если количество запросов к серверу велико, для поддержки всех экземпляров сервера может потребоваться большой объем области подкачки. При больших значениях MaxSpareServers требования к памяти, а следовательно, и к объему области подкачки еще более возрастают.

• MaxClients. Данная директива задает максимальное количество клиентов, которые могут одновременно поддерживать соединение с сервером. По умолчанию задается значение порядка 150. Учитывая трафик, связанный с обращением к вашему серверу, вы можете увеличить или уменьшить его. Если ваш Web-узел пользуется большой популярностью у клиентов и вы задали неоправданно большое значение MaxClients, это может привести к снижению производительности Apache. Если же значение этой директивы слишком мало, то некоторые клиенты не смогут установить соединение с сервером. Большие значения MaxClients приведут к тому, что при увеличении трафика требования к объему памяти и области подкачки возрастут.

На заметку

Число соединений, заданное с помощью директивы MaxClients , не то же самое, что число Web-броузеров, поддерживаемых Apache. Каждый Web-броузер может устанавливать несколько соединении с сервером, и все они учитываются при сравнении с MaxClients .

• Listen. По умолчанию сервер Apache принимает обращения через все активные интерфейсы, используя порт с номером 80. Данная директива позволяет изменить номер порта или ограничить число интерфейсов, через которые можно обратиться к серверу. Например, выражение Listen 192.168.34.98:8080 сообщает Apache, что обращения клиентов должны приниматься только через интерфейс, с которым связан адрес 192.168.34.98 с использованием порта 8080. Выражение Listen 8000 означает, что взаимодействие с клиентами может осуществляться через все интерфейсы посредством порта с номером 8000.

• BindAddress. Если компьютер, на котором выполняется сервер Apache, содержит несколько сетевых интерфейсов, то, используя данную директиву, вы можете связать Apache лишь с одним из интерфейсов. Например, если в конфигурационном файле задано выражение BindAddress 192.168.34.98, сервер будет использовать лишь интерфейс 192.168.34.98. При установке Apache в конфигурационный файл включается выражение BindAddress *, посредством которого Apache связывается со всеми интерфейсами.

Совет

Если вы хотите, чтобы сервер принимал обращения только с локального компьютера, вам надо задать опцию BindAddress 127.0.0.1 . При этом взаимодействие с другими компьютерами поддерживаться не будет. Для обращения к локальному серверу можно использовать URL http://127.0.0.1 или http://localhost .

• Port. Данная директива указывает Apache, какой порт должен использоваться для взаимодействия с клиентами. По умолчанию принимается номер порта 80.

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

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

• DefaultType. Если Apache не может определить MIME-тип данных ни на основании расширения файла, ни с помощью "магической" последовательности, он возвращает MIME-тип, указанный в качестве значения данной директивы. Обычно это text/plain, но при необходимости вы можете задать другое значение. Изменять DefaultType имеет смысл в том случае, если на Web-узле находится много файлов, содержащих данные определенного типа, и есть опасность, что MIME-тип некоторых файлов не будет распознан.

• HostnameLookups. Данная директива может принимать значение On или Off. Если задано значение On, Apache будет преобразовывать адреса клиентов, обращающихся к серверу, в доменные имена и записывать их в файл протокола. Это упрощает анализ информации, содержащейся в файле. Однако преобразование адреса занимает дополнительное время и сетевые ресурсы, поэтому системные администраторы часто отказываются от такой возможности.

• LogLevel. Сервер Apache записывает информацию о своих действиях в файл протокола. Объем этой информации вы можете указывать, задавая значение debug, info, notice, warn, error, crit, alert или emerg директивы LogLevel. (Здесь значения директивы перечислены в порядке убывания объема данных, записываемых в файл протокола.) По умолчанию используется значение warn.

• CustomLog. Для данной директивы задаются два значения: имя файла протокола и формат информации, записываемой в этот файл. В данном случае речь идет о файле протокола, в который помещаются сведения о клиентах, обращающихся к серверу за получением Web-страниц. Формат может быть задан с помощью ключевых слов common, agent, referer и combined. Для обеспечения большей степени гибкости в конфигурационном файле httpd.conf предусмотрены средства, позволяющие администратору определить собственный формат записи данных. Чтобы создать несколько файлов протоколов, надо включить в конфигурационный файл несколько директив CustomLog.

Помимо опций общего назначения, описанных выше, в файле httpd.conf содержатся также дополнительные опции. Многие из них не будут рассматриваться в данной книге. Если вам потребуется более подробная информация о настройке сервера, обратитесь к документации по Apache или к книгам, посвященным данному продукту.

 

Описание каталогов

В состав URL входит от двух до четырех компонентов.

• Протокол. Первый компонент URL (например, http:// или ftp://) определяет протокол, используемый для взаимодействия. В данной главе в основном обсуждаются серверы, поддерживающие протокол HTTP (в этом случае начинается с символов http://). Для обращения к защищенным узлам используются URL, начинающиеся с https://.

• Имя узла. Имя узла, входящее в состав URL, представляет собой доменное имя компьютера, на котором выполняется Web-сервер. Например, в URL http://www.threeroomco.com/thepage/index.html именем узла является www.threeroomco.com. (Одному компьютеру может соответствовать несколько доменных имен. Такая ситуация возникает в том случае, если в конфигурационном файле сервера DNS для этого компьютера задано несколько записей А или CNAME. (Настройка сервера DNS описывались в главе 18).

• Имя файла. В большинстве случаев HTTP-запрос предполагает передачу файла. В составе URL за именем узла следует имя файла (с указанием имени каталога). Например, в URL http://www.threeroomco.com/thepage/index.html ссылкой на файл является компонент thepage/index.html. Несмотря на то что имя файла отделяется от имени узла косой чертой, этот символ не является обозначением корневого каталога системы Linux. Путь к файлу начинается от корневого каталога документов, определенного для Web-узла. Если имя файла в составе URL не указано, сервер возвращает клиенту Web-страницу по умолчанию, заданную с помощью директивы DirectoryIndex.

• Дополнительная информация. Некоторые URL содержат дополнительную информацию. Например, позиции в составе Web-документа может быть присвоено имя. Это имя указывается в URL после имени файла и отделяется от него символом #. URL, в начале которого указан протокол FTP, может содержать пользовательское имя и пароль.

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

• ServerRoot. С помощью этой директивы задается корень поддерева файловой системы, используемого для хранения двоичных файлов Apache. В большинстве случаев при инсталляции сервера устанавливается значение "/usr" этой опции. Изменять его не следует.

• DocumentRoot. В каталоге, указанном с помощью этой директивы, хранятся файлы, содержащие статические Web-страницы. По умолчанию для данной опции задается "/home/httpd/html" или другое подобное значение. (В файле httpd.conf имя каталога обычно помещается в кавычки.)

Внимание

Значение директивы DocumentRoot не следует завершать косой чертой. Несмотря на то что в системе Linux такая ссылка на каталог является корректной, для Apache она приведет к возникновению ошибки.

• UserDir. Если первый из каталогов, предшествующих имени файла в составе URL, начинается с символа ~, Apache интерпретирует его имя как имя пользователя и старается найти файл в рабочем каталоге соответствующего пользователя. Директива UserDir указывает имя подкаталога, в котором следует искать файл. Предположим, что для данной директивы задано значение public_html и удаленный пользователь ввел в поле адреса броузера URL http://www.threeroomco.compilation/~abrown/photos.html. Тогда Apache попытается вернуть пользователю файл photos.html, расположенный в подкаталоге public_html рабочего каталога пользователя abrown. Если задано значение disabled данной директивы, обращение к файлам, находящимся в рабочих каталогах пользователей, запрещено. Если вы хотите запретить доступ лишь к части пользовательских каталогов, вам надо после ключевого слова disabled указать имена пользователей, рабочие каталоги которых закрыты для обращения. Данная директива часто помещается в состав директивы , которая проверяет, загружен ли модуль Apache, предназначенный для поддержки пользовательских каталогов. (Модули Apache будут рассматриваться в следующем разделе.)

• DirectoryIndex. Некоторые URL не содержат имя файла; в них указано лишь имя каталога (в некоторых случаях оно завершается косой чертой). Когда сервер Apache получает подобный URL, он сначала старается найти файл индекса, имя которого задается с помощью директивы DirectoryIndex. В большинстве случаев по умолчанию принимается имя index.html, установленное в качестве значения данной опции при инсталляции сервера. При необходимости вы можете задать другое имя файла. Если пользователь введет URL http://www.threeroomco.com/public/, Apache вернет файл index.html, находящийся в подкаталоге public каталога, указанного с помощью директивы DocumentRoot. Если вы укажете несколько файлов индекса, Apache станет поочередно искать все файлы.

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

 

Загрузка модулей Apache

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

Просмотрев содержимое конфигурационного файла httpd.conf, вы найдете в нем ссылки на модули, формируемые посредством директивы LoadModule. Пример подобной ссылки приведен ниже.

LoadModule mime_module lib/apache/mod_mime.so

В качестве значения данной директивы задается внутреннее имя модуля (в данном примере mime_module) и имя файла, в котором содержится сам модуль (lib/apache/mod_mime.so). В данном случае имя файла указывается относительно каталога, заданного посредством директивы ServerRoot, но при желании вы можете указать полный путь.

Модули, которые используются часто, можно непосредственно встраивать в двоичные файлы Apache. Чтобы определить, какие модули уже содержатся в исполняемых файлах, надо задать команду httpd -l (или apache -l). В некоторых случаях модули, встроенные в состав Apache или загруженные посредством LoadModule, необходимо активизировать, включив для этого в конфигурационный файл директиву AddModule.

AddModule mod_mime.с

В качестве значения директивы AddModule задается имя файла с исходным кодом модуля. Для важных модулей в конфигурационном файле Apache содержится как директива LoadModule, так и директива AddModule.

Как правило, администраторам не приходится включать новые модули; стандартная конфигурация Apache позволяет решать большинство задач, связанных с организацией функционирования Web-узла. Более того, чтобы уменьшить риск незаконного проникновения в систему, иногда приходится исключать некоторые модули. Удаляя модули, следует соблюдать осторожность, так как, не зная структуры Apache, нельзя заранее сказать, как отсутствие некоторых из них повлияет на работоспособность сервера.

Если Apache не может выполнить необходимые вам действия, следует прочитать описания модулей и решить, какой из них пригоден для решения этой задачи. Дополнительную информацию о доступных модулях можно получить на Web-узле Apache Module Register по адресу http://modules.apache.org. Выполнив поиск по ключевым словам, вы получите информацию о модулях, созданных сторонними организациями, и адреса Web-узлов этих организаций.

 

Несмотря на то что статические данные часто используются на Web-узлах, типы информации, с которыми может работать Web-сервер, не исчерпываются ими. Многие Web-серверы динамически генерируют Web-страницы. Например, поисковые серверы позволяют пользователю ввести данные в поле редактирования и передать их после щелчка на кнопке, а затем формируют Web-страницу, содержащую результаты поиска. Если вы хотите создать Web-узел, выполняющий подобные действия, вам надо уметь сконфигурировать его соответствующим образом. В этом разделе будут кратко рассмотрены принципы динамического создания Web-страниц и опции Apache, используемые для активизации соответствующих средств сервера. Чтобы получить более подробную информацию, обратитесь к документам, в которых описаны эти вопросы.

 

Статические данные, формы и CGI-сценарии

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

• HTML-файлы. В настоящее время основная часть данных в Internet представлена в формате HTML (Hypertext Markup Language язык разметки гипертекста). HTML-файлы имеют расширение .htm либо .html и содержат текстовую информацию с элементами разметки. Элементы разметки выполняют форматирование текста. Например, элемент

помечает начало абзаца, а

— конец абзаца. В языке HTML также предусмотрена возможность связывания Web-страниц с другими документами, расположенными в Internet (в частности, в Web). Такое связывание осуществляется посредством гипертекстовых ссылок. После щелчка на гипертекстовой ссылке ресурс, на который она указывает, автоматически воспроизводится либо сохраняется на диске. Конкретные действия по обработке ресурса зависят от настройки Web-броузера.

• Текстовые файлы. Файлы такого типа чаще всего имеют расширение .txt. Текстовые файлы, которые Web-серверы предоставляют пользователям, отображаются броузерами, но элементы форматирования и гипертекстовые ссылки в них отсутствуют.

• Графические файлы. Почти все HTML-документы содержат ссылки на графические файлы, представленные в различных форматах. Эти файлы также являются статическими. Некоторые файлы содержат анимационные данные, но несмотря на это, они все же считаются статическими файлами. Термин статический относится к содержимому файла, а не к способу его отображения.

• Документы в различных форматах. Иногда на Web-страницах содержатся ссылки на файлы PDF, Microsoft Word, архивы .zip и .tar, а также данные, представленные в других форматах. Некоторые броузеры передают эти файлы для обработки соответствующим приложениям, другие сохраняют их на диске.

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

При обработке динамических данных информация передается как от сервера клиенту, так и от клиента серверу. Работая в Internet, вы наверняка встречались с динамическими данными. Соответствующие примеры приведены ниже.

• Поисковые серверы. Если вы укажете в поле адреса броузера URL поискового сервера, этот сервер предоставит Web-страницу, содержащую форму ввода. Форма позволяет вводить данные (в случае поискового сервера — ключевые слова). После щелчка на кнопке Search (или при активизации другого интерактивного элемента, запускающего процедуру поиска) введенные вами ключевые слова передаются Web-серверу, который осуществляет поиск и создает Web-страницу для представления результатов.

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

• Web-узлы, настраиваемые с учетом интересов пользователей. Некоторые Web-узлы предоставляют пользователям специальные средства регистрации и передают данные, специально сформированные для этого пользователя. Например, обратившись на узел Slashdot (http://slashdot.org), вы можете зарегистрироваться и указать при регистрации тип и объем интересующих вас данных. При работе с подобными Web-узлами на стороне клиента создается запись cookie, которая идентифицирует клиент при последующих обращениях. (Записи cookie часто создаются и при взаимодействии с серверами электронной коммерции.)

Приведенные выше примеры представляют лишь частные случаи применения динамических Web-узлов. Возможности подобных узлов ограничены лишь воображением разработчиков и их готовностью реализовать свои планы. С точки зрения Web-сервера основное различие между динамическими и статическими Web-узлами состоит в том, что на динамическом узле HTML-документ (или документ в другом формате) создается в процессе работы сервера на основании данных, полученных от клиента. Для реализации динамических Web-узлов используются следующие средства.

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

• CGI-Сценарии. CGI (Common Gateway Interface — интерфейс общего шлюза) определяет порядок взаимодействия программ, осуществляющих динамическую генерацию HTML-документов, с Web-сервером. CGI-сценарии могут быть написаны практически на любом языке. Для их создания используются не только компилируемые, но и интерпретируемые языки, например Perl. Web-сервер запускает CGI-сценарий на выполнение в том случае, если это предусмотрено в URL. В процессе выполнения сценарий получает от Web-сервера данные, введенные пользователем, при необходимости вызывает другие программы и генерирует Web-страницу, передаваемую в ответ на запрос клиента.

• SSI (Server Side Includes — включаемые средства на стороне сервера) также предназначены для динамической генерации содержимого документа, но, в отличие от CGI-сценариев, которые формируют всю Web-страницу, SSI лишь изменяют шаблоны. SSI не обеспечивают такой гибкости, как CGI, но их удобно использовать для внесения небольших изменений в состав статических Web-страниц, например, для включения информации о текущей дате.

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

 

Поддержка CGI-сценариев

Если вы собираетесь использовать CGI-сценарии, то должны сообщить серверу Apache о своем намерении. При получении URL, содержащего имя сценария, сервер должен запустить этот сценарий, а также организовать обработку данных, переданных клиентом, формирование Web-страницы и передачу ее броузеру. При использовании CGI-сценария Apache выполняет роль посредника между клиентом и сценарием на стороне сервера. Настроить сервер для выполнения подобных функций не сложно. Вы должны лишь разрешить поддержку CGI-сценариев и сообщить Apache типы запросов, при получении которых следует запускать сценарии.

Для обеспечения работы с CGI необходимо загрузить соответствующий модуль Apache.

LoadModule cgi_module lib/apache/mod_cgi.so

Если компоненты, предназначенные для поддержки CGI-сценариев, включены в состав двоичных файлов Apache, вам надо активизировать их посредством директивы AddModule. (В некоторых случаях активизировать надо и компоненты, реализованные в виде модулей.)

AddModule mod_cgi.с

В результате сервер Apache получает возможность запускать CGI-сценарии и взаимодействовать с ними. Вам осталось лишь разрешить поддержку CGI для конкретных файлов и каталогов. Сделать это можно несколькими способами.

• ScriptAlias. Данная директива решает две задачи. Во-первых, она сообщает серверу Apache о том, что файлы, содержащиеся в указанном каталоге, должны интерпретироваться как CGI-сценарии. Во-вторых, посредством этой директивы задается соответствие между каталогом, расположенным на диске, и каталогом, который указывается в URL. Например, выражение ScriptAlias /scripts/ "/home/httpd/cgi-bin/" отображает физический каталог /home/httpd/cgi-bin/ в каталог /scripts в составе URL. В результате, если пользователь укажет URL http://www.threeroomco.com/scripts/test.pl, сервер запустит на выполнение сценарий test.pl, содержащийся в каталоге /home/httpd/cgi-bin/. Часто при инсталляции Apache опции LoadModule и AddModule по умолчанию включаются в конфигурационный файл; вероятнее всего, вы встретите их, просматривая содержимое файла httpd.conf. Для работы с CGI-сценариями часто бывает нужен модуль mod_alias. Соответствующая директива обычно по умолчанию включается в состав конфигурационного файла. При возникновении проблем, проверьте, загружен ли данный модуль.

• Options +ExecCGI. Разрешить выполнение CGI-сценариев можно, указав значение +ExecCGI директивы Options. Данная опция не должна указываться для всей системы, ее имеет смысл применять только к отдельным каталогам (т.е. она должна присутствовать только в составе директивы ).

• .htaccess. Контролировать доступ к отдельному каталогу можно, размещая в нем файл .htaccess. Если в файле .htaccess содержится запись Options +ExecCGI, Apache будет запускать CGI-сценарии, находящиеся в этом каталоге. Чтобы это произошло, в файле httpd.conf должна находиться запись AllowOverride Options; эта запись должна воздействовать как минимум на каталог, содержащий файл .htaccess.

Внимание

Наличие записей Options +ExecCGI и AllowOverride Options представляет угрозу для системы. При неправильном использовании этих средств пользователи получают возможность создавать сценарии, предоставляющие полный доступ к системе. По этой причине в большинстве дистрибутивных пакетов использование файла .htaccess запрещено.

Часто при настройке Apache в конфигурационный файл включается директива ScriptAlias, отображающая каталог /home/httpd/cgi-bin файловой системы в каталог /cgi-bin в составе URL. Такая настройка удобна для администратора. Чтобы установить CGI-сценарий и сделать его доступным для пользователя, достаточно разместить соответствующий файл в каталоге /home/httpd/cgi-bin. При этом необходимо обратить внимание на права доступа к файлу. Поскольку сценарий предназначен для выполнения, для файла, содержащего код этого сценария, должен быть установлен соответствующий признак. Если вы написали сценарий самостоятельно или скопировали его с Web- или FTP-узла, то после размещения его в каталоге /home/httpd/cgi-bin надо выполнить команду chmod a+x имя_сценария .

 

Создание CGI-сценариев

Подобно другим сценариям, CGI-сценарии представляют собой программный код, предназначенный для выполнения. Данная глава не является руководством по написанию CGI-сценариев; в этом разделе приведены лишь некоторые общие рекомендации по работе с ними. Если вам потребуется дополнительная информация о создании CGI-сценариев, обратитесь к Web-странице по адресу http://httpd.apache.org/docs/howto/cgi.html либо к одной из книг, посвященных этой теме.

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

Помимо HTML-кода, CGI-сценарий должен создать поле заголовка Content-Type и в качестве его значения указать MIME-тип данных, передаваемых клиенту. Это поле имеет следующий вид:

Content-type: text/html\r\n\r\n

В данном примере указан MIME-тип text/html, означающий, что в ответ на запрос клиента CGI-сценарий сгенерировал HTML-документ. Символы \r\n\r\n соответствуют двум переводам строки, в результате поле заголовка будет отделено от остальных данных пустой строкой. Код сценария зависит от используемого вами языка программирования. Простейший пример CGI-сценария, написанного на языке Perl, приведен в листинге 20.1. Как видно из листинга, в процессе выполнения сценарий выводит строку текста. Записав файл с этим кодом в каталог, предназначенный для размещения CGI-сценариев, установите права доступа. Если после этого вы зададите URL сценария в поле адреса броузера, то увидите строку "Hello, Web".

Листинг 20.1. Простой CGI-сценарий, написанный на языке Perl

#!/usr/bin/perl

print "Content-type: text/html\r\n\r\n";

print "Hello, Web";

С обработкой входных данных дело обстоит несколько сложнее. Ваш сценарий получит данные только в том случае, если они были введены пользователем посредством интерактивных элементов, содержащихся в форме. Данные поступают на вход сценария в виде набора пар имя-значение. Имя отделяется от значения символом =, а пары имя-значение разделяются символами &. Пример строки параметров, передаваемой CGI-сценарию, приведен ниже.

city=Oberlin&state=OH&zip=44074

Перед тем как использовать полученные данные, надо произвести разбор строки параметров. В языке Perl предусмотрены мощные средства работы со строками. Этот факт стал одной из причин популярности Perl среди разработчиков CGI-сценариев.

 

Повышение уровня защиты при использовании CGI-сценариев

Если на Web-узле присутствуют CGI-сценарии, любой пользователь, работающий с Web-броузером, имеет возможность запустить на стороне сервера программу. Это может стать источником проблем, связанных с безопасностью системы. Определенную опасность для системы представляет любой сервер, но при использовании на Web-узле CGI- сценариев шансы злоумышленников на успех существенно возрастают. Ни об одном достаточно сложном CGI-сценарии нельзя с уверенностью сказать, что он безупречен с точки зрения защиты. Разработчики серверов прилагают большие усилия для того, чтобы устранить возможность проникновения с его помощью в систему, но несмотря на это, время от времени в серверах обнаруживаются ошибки. В отличие от серверов, CGI-сценарии в основном создаются системными администраторами, которые часто не имеют большого опыта программирования. В результате сценарии получаются уязвимыми для атак извне.

Существуют способы, позволяющие уменьшить риск, связанный с использованием CGI-сценариев. Перед установкой сценариев необходимо еще раз поверить значения директив User и Group в файле httpd.conf. CGI-сценарии выполняются с полномочиями пользователя, указанного посредством этих директив, поэтому, используя учетную запись, предусматривающую минимальные права, вы ограничите возможности злоумышленника, если тому удастся получить контроль над CGI-сценарием. Идеальный вариант — создать учетную запись и группу, специально предназначенные для обеспечения работы сервера Apache; регистрация в системе с помощью этой учетной записи должна быть запрещена. Однако подобная мера не гарантирует безопасность системы. Недостатки в сценарии могут стать базой, используя которую взломщик продолжит действия по проникновению в систему.

Чтобы уменьшить опасность для системы, можно использовать готовые сценарии, поставляемые в составе библиотек. Такой подход, с одной стороны, упростит процедуру создания Web-узла, а с другой стороны, позволит избежать грубых ошибок в сценарии. Библиотеки сценариев размещены на различных Web-узлах, например, вы можете обратиться по адресу http://www.cpan.org.

Чтобы злоумышленник, получивший контроль над Web-сервером, не смог нанести существенный вред компьютерам вашей сети, надо принять дополнительные меры. Например, желательно отключить ненужные серверы и ограничить доступ с компьютера, на котором выполняется Web-сервер, к другим компьютерам сети. Действия, направленные на повышение уровня защиты системы, рассматриваются в части IV.

 

При использовании сценариев часто осуществляется шифрование передаваемых данных. Действия по кодированию и декодированию информации при обмене между Web-сервером и Web-броузером определяется протоколом SSL (Secure Sockets Layer — уровень защищенного гнезда). Протокол SSL часто используется на узлах электронной коммерции для защиты важных данных. Для поддержки SSL-кодирования при работе Apache требуется дополнительное программное обеспечение, например, mod_ssl (http://www.modssl.org) или программы, разработанные в рамках проекта Apache-SSL (http://www.apache_ssl.org). Для поддержки SSL можно также использовать продукты,

распространяемые на коммерческой основе.

 

Задачи, решаемые с помощью SSL

SSL — это технология кодирования, подобная той, которая используется при обеспечении работы протокола удаленной регистрации SSH. (Строго говоря, эти протоколы применяют одни и те же средства шифрования, так как работа популярного пакета OpenSSH основана на использовании пакета OpenSSL, который также применяется некоторыми реализациями Apache, поддерживающими SSL.) SSL позволяет решить следующие две проблемы, возникающие при обмене между Web-клиентом и Web-сервером.

• Шифрование. SSL позволяет обеим взаимодействующим сторонам выполнять шифрование данных, обеспечивая тем самым их сохранность. Это необходимо в тех случаях, когда Web-клиент должен обмениваться с Web-сервером важной информацией, например передавать номера платежных карточек и банковских счетов. Для кодирования применяется технология открытого ключа, согласно которой каждая из взаимодействующих сторон использует два ключа. Шифрование осуществляется с помощью открытого, или общего, ключа, предоставляемого другой взаимодействующей стороной, а для расшифровки применяется собственной закрытый, или личный, ключ. Таким образом, передавая данные, участник сетевого взаимодействия уверен, что расшифровать их сможет только тот, для кого они предназначены.

• Аутентификация. Даже при использовании шифрования передача важных данных по Internet связана с определенным риском. Может оказаться, что принимающий узел — не тот, за кого он себя выдает. Например, если вы ввели в поле адреса броузера URL http://www.abigretailer.com, можете ли вы быть уверены, что ваш запрос попадет на тот узел, на который вы его отправляете? Не исключено, что злоумышленнику удалось изменить настройку сервера DNS или маршрутизатора и перенаправить запрос на свой компьютер. SSL предоставляет средства аутентификации участников взаимодействия. Идентификация осуществляется посредством сертификатов, предоставляемых организацией, специализирующейся на этом. Сертификат, полученный от сертифицирующей организации (CA — certificate authority), представляет собой цифровой код, используемый для создания общего ключа. Если один участник взаимодействия передал свой сертификат, полученный от CA, то другой участник может быть уверен, что его партнер по обмену данными — именно тот, за кого он себя выдает. (В последнее время стало ясно, что даже сертификаты не позволяют гарантированно идентифицировать участников взаимодействия. Так, в 2001 г. сертификаты Microsoft были по ошибке выданы организациям, не имеющим к корпорации никакого отношения.)

На заметку

При необходимости вы сами можете выступать в роли сертифицирующей организации, однако ваши сертификаты будут пригодны только для внутреннего использования. Внешние пользователи не будут иметь никакой гарантии того, что сертификат не фальсифицирован. Поэтому, если вы собираетесь организовать узел электронной коммерции, вам необходимо получить сертификат от CA. Список CA можно найти по адресу http://www.apache-ssl.org/#Digital_Certificates . Пользователям, обращающимся к Web-узлам посредством броузеров, сертификаты не нужны, так как Web-серверы практически никогда не проверяют идентичность пользователей.

При работе посредством протокола SSL используется порт, отличный от порта 80. По умолчанию для взаимодействия по защищенному протоколу HTTP (HTTPS) применяется порт 443. Чтобы Web-броузер указал в запросе этот порт, URL, введенный пользователем, должен начинаться с символов https://. Настраивая Apache для поддержки SSL, вы можете установить один сервер, который будет по-разному реагировать на обращения через порты с номерами 80 и 443, либо использовать два сервера различных типов. Первый подход реализовать проще, но может возникнуть ситуация, при которой целесообразнее использовать два сервера (например, Apache для обработки SSL-запросов и thttpd для поддержки обычного HTTP-взаимодействия).

 

Настройка средств поддержки SSL

Для того чтобы сервер Apache мог поддерживать SSL-соединения, надо сконфигурировать SSL-пакет. В настоящее время в системе Linux чаще всего используются два таких пакета.

• SSLeay (http://www2.psy.uq.edu.au/~ftp/Crypto/ssleay/)

• OpenSSL (http://www.openssl.org)

Вскоре после своего появления OpenSSL приобрел статус стандарта в системе Linux. Он содержится в составе многих дистрибутивных пакетов Linux, включая Debian, Mandrake, Red Hat и SuSE. Пакеты SSLeay и OpenSSL выполняют одинаковые функции, но исполняемые файлы носят разные имена (ssleay и openssl) и для их настройки используются различные конфигурационные файлы.

После инсталляции OpenSSL вам необходимо получить сертификат. Для работы в Internet потребуется сертификат, выданный CA, но для тестирования сервера можно создать сертификат самостоятельно. Некоторые сценарии установки Apache SSL создают сертификат автоматически. Если в процедуре инсталляции не предусмотрено формирование сертификата, вы можете использовать следующую команду:

# openssl req $@ -new -x509 -nodes \

 -config /usr/share/doc/apache-ssl/examples/ssleay.cnf \

 -out /etc/apache-ssl/apache.pem \

 -keyout /etc/apache-ssl/apache.pem

На заметку

В данном примере предполагается, что настройка средств поддержки SSL осуществляется посредством конфигурационного файла /etc/apache-ssl , а в составе пакета поставляется образец конфигурационного файла /usr/share/doc/apache-ssl/example/ssleay.cnf . При необходимости вы можете изменить имена файлов или каталогов. Обратная косая черта указывает на то, что продолжение команды находится на следующей строке. Если вся команда помещается в одной строке, символ \ можно не использовать.

В процессе выполнения утилита openssl запросит дополнительную информацию, например имя компьютера. Эта информация включается в состав сертификата, который содержится в файле /etc/apache-ssl/apache.pem.

Впоследствии сгенерированный вами сертификат придется заменить сертификатом, который предоставит вам сертифицирующая организация. Если при использовании сертификата, созданного самостоятельно, пользователь, обратившийся к Web-узлу, увидит предупреждающее сообщение, то при наличии сертификата, выданного CA, такое сообщение не выводится. Предупреждающее сообщение, отображаемое броузером Opera в системе Linux, показано на рис. 20.2. В других броузерах формат сообщения будет отличаться от приведенного на рисунке.

Рис. 20.2. При использовании сертификата, сгенерированного самостоятельно, пользователи, взаимодействующие с узлом, увидят предупреждающее сообщение о том, что сертификат не распознан или срок его действия истек

 

Установка компонентов Apache, предназначенных для поддержки SSL

Считается, что поддержка SSL в сервере Apache осуществляется за счет дополнительных модулей. На практике для установки SSL-модулей необходимо внести некоторые изменения в структуру сервера и повторно скомпилировать Apache. В некоторых инсталляционных пакетах SSL-модули включены по умолчанию, и код сервера скомпилирован с учетом использования SSL-компонентов. Если вы попытаетесь объединить компоненты обычного сервера Apache и пакета, сформированного для обеспечения поддержки SSL, такой сервер скорее всего работать не будет.

Во многих случаях для управления сервером, созданным с учетом поддержки SSL, используется конфигурационный файл, отличный от файла, применяемого для настройки обычного сервера Apache. Например, в системе Debian сервер Apache, настроенный для поддержки SSL, использует конфигурационный файл /etc/apache-ssl, в то время как для стандартной конфигурации Apache в этой системе применяется файл /etc/apache. Конфигурационные файлы для SSL-серверов во многом совпадают с файлами для Apache без поддержки SSL, за исключением некоторых директив, значения которых вам, возможно, придется изменить. Часть этих директив описана ниже.

• ServerType. Сервер с поддержкой SSL не может запускаться посредством суперсервера, поэтому для директивы ServerType должно быть установлено значение standalone.

• Использование портов. Для взаимодействия по протоколу SSL используется порт 443. При этом необходимо учитывать, что директива Listen позволяет связать сервер с определенным номером порта.

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

• SSLRequireSSL. Включив данную директиву в состав , вы запретите доступ к каталогу для клиентов, не поддерживающих SSL. (Значения данной директивы не указываются.) Использование SSLRequireSSL позволяет предотвратить передачу важных данных по незащищенному каналу. Очевидно, что, помимо данной опции, следует применять и другие средства, ограничивающие доступ к каталогу.

• SSLEnable. Директива SSLEnable разрешает использование протокола SSL при обмене данными. Подобно SSLRequireSSL, значения для данной директивы не предусмотрены.

• SSLCACertificatePath. Эта директива указывает на каталог, содержащий сертификат. Например, в качестве значения SSLCACertificatePath может быть указано /etc/apache-ssl.

• SSLCertificateFile. В качестве значения данной директивы указывается файл, содержащий сертификат (например, /etc/apache-SSI/apache.pem).

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

Установив конфигурацию сервера, вы можете запускать его для поддержки SSL-взаимодействия. Чтобы обратиться к серверу, надо ввести в поле адреса броузера URL, начинающийся символами https://. Если вы самостоятельно сгенерировали сертификат, броузер отобразит предупреждающее сообщение, подобное тому, которое показано на рис. 20.2. Чтобы протестировать создаваемый вами узел, вы можете принять этот сертификат (некоторые броузеры позволяют задать условия дальнейшего использования сертификата).

Внимание

Работая в Internet, не следует принимать сертификаты, созданные администраторами Web-узлов. Если сервер использует сертификат, выданный сертифицирующей организацией, броузер не отображает предупреждающее сообщение. Если же подобное сообщение появилось на экране, это означает, что при использовании сертификата была допущена ошибка (например, сервер продолжает работать с сертификатом, срок действия которого истек) либо администратор вовсе не обращался к сертифицирующей организации. Появление предупреждающего сообщения также может означать, что злоумышленник пытается представить свой узел как узел официальной организации и собрать с его помощью важные данные.

 

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

 

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

Наличие виртуальных доменов позволяет Web-серверу по-разному обрабатывать запросы, в зависимости от имен, указанных в них. (Чтобы к Web-серверу можно было обращаться по разным именам, необходимо создать несколько записей в конфигурационном файле DNS-сервера.) Примеры использования виртуальных доменов описаны ниже.

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

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

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

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

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

 

Конфигурация виртуальных доменов

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

Использование VirtualDocumentRoot

VirtualDocumentRoot — одна из основных директив, используемых для настройки виртуальных доменов. Эта директива позволяет указать имя каталога, которое будет выполнять роль корневого каталога документов при указании в составе запроса определенного имени. В качестве значения VirtualDocumentRoot указывается имя каталога, которое может содержать различные переменные. (Назначение этих переменных описано в табл. 20.1.)

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

Рассмотрим в качестве примера следующую запись:

VirtualDocumentRoot /home/httpd/%0

Она сообщает серверу о том, что он должен использовать подкаталог каталога /home/httpd, имя которого соответствует полному имени сервера, указанному в составе запроса. Например, если в запросе задан URL http://www.threeroomco.com/index.html, сервер будет искать файл /home/httpd/www.threeroomco.com/index.html. Такой способ очень удобен, но если вам необходимо поддерживать большое количество Web-узлов, то придется создавать много подкаталогов с достаточно длинными именами (в данном примере все подкаталоги должны присутствовать в каталоге /home/httpd). При необходимости вы можете использовать в качестве имени каталога часть доменного имени. Пример подобного подхода иллюстрирует приведенная ниже запись.

VirtualDocumentRoot /home/httpd/%-1/%-2

Если в конфигурационном файле содержится такое выражение, то, получив запрос, в котором указан URL http://www.threeroomco.com/index.html, Apache вернет клиенту файл /home/httpd/com/threeroomco/index.html (если он имеется на сервере). Если вы хотите использовать в имени каталога лишь один символ из доменного имени, вам надо включить в состав конфигурационного файла запись наподобие следующей:

VirtualDocumentRoot /home/httpd/%-2.1/%0

Теперь при получении URL http://www.threeroomco.com/index.html Apache вернет клиенту файл /home/httpd/t/www.threeroomco.com/index.html. Переменная %-2.1 определяет первый (.1) символ в составе имени домена (-2), предшествующего имени домена верхнего уровня.

Независимо от значения директивы VirtualDocumentRoot, вам надо задать значение Off для директивы UseCanonicalName.

UseCanonicalName Off

Если директива UseCanonicalName будет иметь значение On, устанавливаемое по умолчанию при инсталляции сервера, Apache будет использовать для обработки относительных ссылок доменное имя компьютера, на котором он выполняется. Например, если в документе index.html содержится ссылка на Web-страницу products.html, Apache будет стараться извлечь ее, основываясь на своем каноническом имени. При наличии виртуальных доменов такое поведение недопустимо. Если задать значение Off директивы UseCanonicalName, то для обработки относительных ссылок Apache будет применять имя, соответствующее виртуальному домену.

Использование <VirtualHost>

Альтернативный подход к созданию виртуальных доменов предполагает непосредственное описание каждого из них. Для этого в конфигурационном файле Apache предусмотрены две специальные директивы.

• NameVirtualHost. Данная директива указывается в главном конфигурационном файле Apache и информирует сервер о том, что вы собираетесь использовать виртуальные узлы. В качестве значения этой директивы чаще всего указывается символ *; при этом необходимо определять виртуальные домены для поддержки всех типов обращения к серверу. Кроме того, значением опции NameVirtualHost может быть IP-адрес, связанный с сетевым интерфейсом; в этом случае конфигурация основного сервера применяется ко всем запросам, за исключением запросов, переданных через этот интерфейс, и запросов, соответствующих определению виртуального узла.

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

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

NameVirtualHost *

 ServerName www.threeroomco.com

 DocumentRoot /home/httpd/threeroomco/html

 ScriptAlias /cgi-bin/ "/home/httpd/threeroomco/cgi-bin/"

 ServerName www.pangaea.edu

 DocumentRoot /home/httpd/pangaea-u/html

Если сервер настроен подобным образом, то при обращении к нему посредством имени www.threeroomco.com он будет предоставлять клиенту статические файлы, которые находятся в каталоге /home/httpd/threeroomco/html, или запускать на выполнение сценарии, содержащиеся в каталоге /home/httpd/threeroomco/cgi-bin. Если же в запросе указано имя www.pangaea.edu, то статические файлы будут извлекаться из каталога /home/httpd/pangaea-u/html, а выполнение CGI-сценариев будет запрещено.

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

 

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

 

Форматы данных, используемых при создании Web-узла

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

Основу большинства Web-страниц составляет HTML-файл. Этот файл содержит текстовые данные, пригодные для редактирования с помощью обычного текстового редактора. Пример простого HTML-файла приведен в листинге 20.2. Данные, содержащиеся в HTML-файле, делятся на две категории: текст, предназначенный для отображения в окне броузера, и последовательности символов, помещенные в угловые скобки, называемые дескрипторами. Дескрипторы представляют собой элементы форматирования, а также выполняют некоторые другие функции. Большинство дескрипторов используются парами, каждая из которых состоит из открывающего и закрывающего дескрипторов. Открывающий и закрывающий дескрипторы имеют одно и то же имя, но перед именем закрывающего дескриптора указывается символ /. В состав открывающего дескриптора часто входят атрибуты, уточняющие действия дескриптора. Например, с помощью атрибутов могут задаваться размеры изображения и содержащий его файл, цвет фона и текста и т.д. Некоторые из дескрипторов формируют ссылки на документы, расположенные на том же сервере, либо на других Web-серверах.

Назначение некоторых из дескрипторов, приведенных в листинге 20.2, очевидно, другие требуют более подробного рассмотрения. Ниже представлено описание дескрипторов, наиболее часто встречающихся в HTML-документах.

Листинг 20.2. Пример HTML-файла

 

  

 

 

 

Пример Web"=страницы

 

  

Данная Web"=страница содержит <А HREF="http://www.threeroomco.com/anotherpage.html"> гипертекстовую ссылку.

 

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

• . HTML-документ делится на заголовок и тело документа. В заголовке в основном содержится информация, не предназначенная для отображения (за исключением содержимого элемента