Для того чтобы компьютеры, подключенные к сети TCP/IP, могли обращаться друг у другу по имени, они должны иметь возможность преобразовывать доменные имена в IP- адреса, а также выполнять обратное преобразование. Существуют различные средства, позволяющие осуществлять подобные преобразования. Наиболее часто для этой цели используется DNS-сервер (Domain Name System — система доменных имен), который часто называют сервером имен. В главе 2 рассматривались вопросы настройки компьютера для взаимодействия с сервером имен. Однако, для того, чтобы такое взаимодействие было возможным, сервер DNS должен присутствовать в сети. Следует заметить, что работа всей Internet базируется на использовании иерархии серверов DNS. Установив сервер DNS в локальной сети, вы не только обеспечите преобразование имен в ее пределах, но также предоставите возможность внешним пользователям обращаться к компьютерам вашей сети по именам.

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

Администрирование сервера DNS не занимает столько времени и не требует таких усилий, сколько требуется для управления сложными системами, например, Kerberos выполнять все же труднее, чем администрировать простой сервер, например Telnet. Прочитав данную главу, вы получите сведения, достаточные для управления простым доменом. Если же потребуется установить более сложную конфигурацию, вам придется обратиться к документации на сервер DNS либо к изданиям, специально посвященным данному вопросу. В качестве примеров можно привести книгу Элбица (Albitz) и Лиу (Liu) DNS and BIND, 4th Edition (O'Reilly, 2001) и книгу Ханта (Hunt) Linux DNS Server Administration (Sybex, 2000).

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

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

URL http://www.whitehouse.gov.

www.whitehouse.gov

www.whitehouse.gov)

.com

.gov

.uk

.gov

.gov

.gov

whitehouse.gov

whitehouse.gov

www.whitehouse.gov

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

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

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

whitehouse.gov

На заметку

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

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

http://www.granitecanyon.com

Существует специальное динамическое 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 не только предоставляет возможность внешним пользователям обращаться к компьютерам вашей локальной сети по именам. Он также выполняет преобразование символьных имен в IP-адреса для узлов локальной сети, т.е. выполняет те же функции, что и серверы, адреса которых содержатся в файле

/etc/resolv.conf

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

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

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

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

/etc/hosts

С:\WINDOWS\HOSTS

/etc/hosts

/etc/hosts

192.168.78.109 gingko.threeroomco.com gingko

При установке системы Linux в файл

/etc/hosts

localhost

/etc/hosts

/etc/hosts

/etc/hosts

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

На заметку

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

.unused

.

В настоящее время существуют два основных типа доменов верхнего уровня.

• Домен верхнего уровня на базе кода страны (ccTLD — country code top-level domain). Эти домены принадлежат конкретным странам. Например, домен

.us

.se

• Универсальный домен верхнего уровня (gTLD — generic top-level domain). Эти домены не отражают географическое положение узла сети. Примерами подобных доменов являются

.com

.net

.org

.gov

.biz

.museum

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

.com

.org

.net

http://www.NewRegistrars.com

http://www.icann.org/registrars/accredited-list.html

В некоторых доменах верхнего уровня, например в gTLD

.gov

.edu

http://www.iana.org/cctld/cctld-whois.htm

На заметку

В конце 2001 г. были изменены принципы управления доменом верхнего уровня

.us

. С начала 2002 г. появилась возможность регистрировать домены непосредственно в TLD

.us

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

.us

, вам следует обратиться по адресу

http://www.nic.us

.

Некоторые домены, в особенности ccTLD, содержат иерархию поддоменов. Например, в составе домена

.uk

.gov.uk

.со.uk

.gov.uk

.co.uk

.com

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

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

• BIND. Сервер BIND (Berkeley Internet Name Domain) — самая популярная в настоящее время программа, которая может обеспечивать функции сервера DNS в системе Linux. Именно этому серверу уделяется основное внимание в данной главе. Пакет BIND поставляется в составе многих дистрибутивных пакетов, кроме того, вы можете скопировать его с узла

http://www.isc.org/products/BIND/

• 

djbdns

djbdns

djbdns

http://cr.yp.to/djbdns.html

• 

pdnsd

djbdns

pdnsd

http://home.t-online.de/home/Moestl/

• 

dnscache

pdnsd

dnscache

pdnsd

dnscache

localhost

http://cr.yp.to/djbdns/dnscache.html

Большинство администраторов, занимающихся поддержкой компьютеров под управлением Linux, используют в качестве сервера DNS продукт BIND, поскольку он принят как стандарт и поставляется с большинством версий данной операционной системы. Администраторы, для которых вопросы безопасности системы имеют первоочередное значение, отдают предпочтение продукту

djbdns

djbdns

Установка конфигурации DNS предполагает решение двух задач: настройка сервера DNS (в пакете BIND функции сервера выполняет программа

named

Основные опции BIND задаются в главном конфигурационном файле с именем

named.conf

/etc

/etc

/usr/share/doc/bind-версия

named.conf

Листинг 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

options

zone

options

zone

named.conf

;

named.conf

/var/named

directory

В последующих разделах информация, содержащаяся в файле

named.conf

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

• Требуемый файл может входить в поставку пакета BIND. Обычно он называется

named.са

db.cache

/var/named

• Файл

named.са

ftp://ftp.rs.internic.net/domain/

• Если в вашей системе установлена программа

dig

dig @a.root-servers.net.ns > named.са

named.са

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

Получив файл со списком корневых серверов, скопируйте его в каталог

/var/named

/etc/named.conf

file

zone "."

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

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

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

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

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

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

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

forwarders

forward

forwarders

forward

only

first

forward only

forwarders

first

forward

При настройке BIND вы должны указать, как следует обрабатывать запросы, в которых указаны определенные домены, поддомены и диапазоны IP-адресов. Различные группы имен и адресов называются зонами. Зоной может быть домен или поддомен (например, зоной является домен

threeroomco.com

in-addr.arpa

• Корневая зона. Зона, идентифицируемая посредством точки (

"."

ype hint

file

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

threeroomco.com

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

in-addr.arpa

1.168.192.in-addr.arpa

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

• 

master

• 

slave

• 

stub

threeroomco.com

sub.threeroomco.com

threeroomco.com

sub.threeroomco.com

stub

sub.threeroomco.com

sub.threeroomco.

sub.threeroomco.com

• 

forward

forward

options

forward

forwarders

• 

hint

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

hint

master

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

/еtс/named.сonf

threeroomco.com

zone "threeroomco.com" {

 type slave;

 file "named.threeroomco.com";

 masters { 192.168.1.50; }

};

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

threeroomco.com

Зоны типа

slave

threeroomco.com

1.168.192.in-addr.arpa

0.0.127.in-addr.arpa

slave

Если сконфигурировав сервер как ведомый, вы запустите его на выполнение, то вскоре увидите, что сервер создал файлы описания зоны, указанные в записях

zone

allow-transfer

options

allow-transfer {

 192.168.1/24;

 172.9.98.23;

};

Несмотря на то что вы создали файл

/etc/named.conf

/etc/named.conf

master

В листинге 18.2 приведен пример простого конфигурационного файла зоны. Этот файл начинается с имени зоны (

threeroomco.com

Внимание

В системе 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

IN

Внимание

В различных конфигурационных файлах 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 это

admin.threeroomco.com.

@

admin.threeroomco.com.

admin@threeromco.com

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

serial

refresh

retry

expire

expire

refresh

default_ttl

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

@

MX

NS

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

• 

А

A

gingko.threeroomco.com.

birch

spruce

threeroomco.com.

• 

CNAME

CNAME

kelp

CNAME

www

• 

PTR

PTR

• 

NS

NS

NS

SOA

@

А

• 

MX

MX

@

lorax@threeroomco.com

birch.threeroomco.com.

mail.pangaea.edu.

MX

MX

Совет

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

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

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

in-addr.arpa

/etc/named.conf

1.168.192.in-addr.arpa

Зона для обратного преобразования, или обратная зона, настраивается подобно зоне прямого преобразования. Конфигурационный файл зоны содержит записи

SOA

NS

PTR

MX

CNAME

В поле имени записи PTR указывается либо сокращенный вариант адреса (например, 1 для 192.168.1.1), либо полный IP-адрес, расположенный в обратном порядке и сопровождаемый именем

in-addr.arpa

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.

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

localhost

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

Основной конфигурационный файл сервера, предназначенного лишь для кэширования, имеет тот же формат, что и файл, представленный в листинге 18.1, однако в нем присутствует лишь определение зоны, предназначенной для обратного преобразования

localhost

0.0.127.in-addr.arpa

.

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

forwarders

forward

options

forwarders

forward first

forward only

forwarders

Внимание

Если вы включите в состав конфигурационного файла корневую зону и зададите опцию

forward first

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

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

dnscache

pdnsd

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

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

birch.threeroomco.com

В главе 5 рассматривалась конфигурация сервера DHCP для совместной работы с сервером DNS. Чтобы соответствующим образом настроить BIND, вам надо внести изменения в файл

named.conf

allow-update

zone "threeroomco.com" {

 type master;

 file "named.threeroomco.com";

 allow-update { 192.168.1.1; }

};

Теперь BIND будет принимать информацию об IP-адресах от компьютера с адресом 192.168.1.1. Как нетрудно догадаться, это должен быть адрес узла сети, на котором выполняется сервер DHCP. Аналогичные изменения надо внести в определение обратной зоны.

Внимание

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

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

Для тестирования сервера имен хорошо подходит инструмент

host

host

bind-utils

host

/etc/resolv.conf

$ host www.awl.com

www.awl.com is a nickname for awl.com

awl.com has address 165.193.123.224

В данном примере первая строка, отображаемая программой, сообщает о том, что

www.awl.com

CNAME

awl.com

-t

MX

$ host -t MX awl.com

awl.com mail is handled by 100 mailhost.uu.net.

awl.com mail is handled by 10 oldtms702.pearsontc.com.

awl.com mail is handled by 20 oldtms701.pearsontc.com.

Данная проверка показывает, что в домене com определены три почтовых сервера:

oldtms702.pearsontc.com

oldtms701.pearsontc.com

mailhost.uu.net

$ host www.awl.com spruce

Using domain server:

Name: spruce.threeroomco.com

Address: 192.168.1.3

Aliases:

www.awl.com is a nickname for awl.com

awl.com has address 165.193.123.224

При этом выводятся те же данные, что и в предыдущем примере, кроме того, отображается подтверждение того, что программа

host

Дополнительную информацию о программе

host

nslookup

host

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

В главе 11 рассматривались протоколы POP и IMAP, которые частично решают задачу доставки писем. Эти и другие протоколы получения почты позволяют пользователю копировать адресованные ему сообщения с центрального сервера на свой компьютер. Для того чтобы обеспечить доставку писем, надо решить еще две задачи: копирование сообщений на центральный почтовый сервер и передачу их адресатам. Обе эти задачи решаются посредством протоколов передачи почты. При использовании этих протоколов сообщения передаются по инициативе сервера. Взаимосвязь между протоколами передачи и получения почты рассматривалась в главе 11.

Из протоколов передачи почты в настоящее время наиболее популярным является SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты). Все письма, передаваемые в среде Internet, проходят как минимум через один сервер SMTP. Обычно серверы получения и передачи почты выполняются на одном и том же компьютере, так что письмо, полученное сервером SMTP, может быть в любой момент передано на пользовательский компьютер. Если в системе Linux предполагается обработка почты, сервер SMTP выполняет при этом основную роль. В состав каждого дистрибутивного пакета Linux входит по меньшей мене один сервер SMTP, однако различные системы содержат разные серверы. В данной главе рассматриваются наиболее популярные в настоящее время серверы SMTP:

sendmail

Часто для обеспечения работы сервера в сети достаточно внести лишь минимальные изменения в состав его конфигурационного файла, но в некоторых случаях приходится выполнять сложные действия по настройке сервера. Для тех, кому необходима дополнительная информация о серверах SMTP, можно порекомендовать следующие книги: Косталес (Costales) и Эллмен (Allman) Sendmail (O'Reilly, 1997), Хант (Hunt) Linux Sendmail Administration (Sybex, 2001), Хэзел (Hazel) Exim: The Mail Transfer Agent (O'Reilly, 2001), Блюм (Blum) Posfix (Sams, 2001), Стилл (Sill) The qmail Handbook (APress, 2001) и Маккарти (McCarthy) The Procmail Companion (Addison Wesley, 2001).

Серверы SMTP часто называют агентами передачи почты (MTA — mail transfer agent). В процессе обмена почтой подобная программа может выступать как в роли клиента, так и в роли сервера. Сервер SMTP может получить сообщение, переданное другим сервером, поддерживающим этот протокол. Сервер хранит полученные сообщения на локальном компьютере, а при необходимости может передать их другому серверу SMTP. Возможные варианты использования сервера SMTP в системе Linux описаны ниже.

• Получение почты. Чаще всего сервер SMTP выполняет функции центрального почтового сервера сети. Письма, полученные сервером SMTP, могут быть просмотрены с помощью специальных программ (например,

pine

mutt

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

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

root

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

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

• 

sendmail

sendmail

sendmail

sendmail

sendmail

http://www.sendmail.org

• Exim. Формат конфигурационного файла данного сервера проще, чем у

sendmail

http://www.exim.org

• Postfix. Как

sendmail

sendmail

http://www.postfix.org

• 

qmail

qmail

qmail

sendmail

sendmail

sendmail

qmail

qmail

sendmail

qmail

http://www.qmail.org

Помимо перечисленных выше, в системе Linux могут использоваться и другие почтовые серверы. В качестве примера можно привести Smail (

http://www.gnu.org/software/smail/smail.html

http://www.courier-mta.org

http://www.openmail.com/cyc/om/00/

sendmail

qmail

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

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

sendmail

sendmail

sendmail

sendmail

sendmail

mbox

sendmail

qmail

maildir

qmail

sendmail

qmail

Многие почтовые серверы получают почту с внешних компьютеров. Существуют два способа адресации почтового сервера.

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

mail.threeroomco.com

jennie@mail.threeroomco.com

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

MX

MX

threeroomco.com

MX

mail.threeroomco.com

jennie@threeroomco.com

mail.threeroomco.com

MX

Формат конфигурационного файла сервера DNS, в частности структура записей

MX

mail.threeroomco.com

MX

@ IN MX 10 mail.threeroomco.com.

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

/var/named

@

IN

MX

На заметку

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

Для того чтобы понять материал данной главы, надо хотя бы в общих чертах представлять себе принцип передачи почтовых сообщений с помощью протокола SMTP. В частности, необходимо знать различия между заголовками конверта (envelope header), заголовками сообщения (message header) и телом сообщения (message data). Заголовком конверта считаются поля

From

То

То

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

From:

To:

Received:

Subject:

На заметку

В заголовке сообщения значение поля отделяется от его имени двоеточием. В заголовке конверта двоеточие обычно не используется. Если сервер SMTP использует формат

maildir

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

From

и

То

заголовка конверта, сохранялись в составе поля

Received:

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

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

telnet

telnet

Листинг 19.1. Пример SMTP-сеанса

$ telnet louiswu.rodsbooks.com

25 Trying 192.168.1.5...

Connected to louiswu.rodsbooks.com.

Escape character is '^]'.

220 louiswu ESMTP Exim 3.12 #1 Wed, 30 Oct 2002 12:01:29 -0500

HELO nessus.rodsbooks.com

250 louiswu Hello nessus.rodsbooks.com [192.168.1.3]

MAIL FROM:<rodsmith@nessus.rodsbooks.com>

250 <rodsmith@nessus,rodbooks.com> is syntactically correct

RCPT TO:<rodsmith@louiswu.rodsbooks.com>

250 <rodsmith@louiswu.rodsbooks.com> is syntactically correct

DATA

354 Enter message, ending with "." on a line by itself

From: <rodsmith@nessus.rodsbooks.com>

To: <rodsmith@louiswu.rodsbooks.com>

Subject: A Sample SMTP Session

This is the text of the message.

.

250 OK id=15z87H-OOOOCX-00

QUIT

221 louiswu closing connection

Connection closed by foreign host.

В большинстве случаев SMTP-соединение начинается по инициативе клиентской программы, в роли которой выступает программа подготовки писем или другой сервер SMTP (в сеансе, представленном в листинге 19.1, действия клиентской программы имитирует пользователь с помощью программы

telnet

HELO

EHLO

MAIL FROM:

RCPT ТО:

From

То

DATA

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

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

HELO

MAIL FROM

From:

MAIL FROM

HELO

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

То

To:

То

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

RCPT TO:

RCPT

• Предоставление информации о сервере. При проведении сеанса, приведенного в листинге 19.1, отправитель получает лишь частичную информацию о сервере и никаких других данных. В данном примере сервер объявляет себя как Exim 3.12. Некоторые программы позволяют скрыть номер версии; если в средствах защиты сервера имеются недостатки, такая мера повышает безопасность системы. Сохраняя в секрете номер реализации сервера, вы лишаете хакера информации о возможных путях незаконного проникновения в систему. В листинге 19.1 в ответ на команды

MAIL FROM:

RCPT TO:

is syntactically correct

RCPT TO:

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

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

hostname

HELO

MAIL FROM:

From:

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

franklin.threeroomco.com

threeroomco.com

franklin.threeroomco.com

threeroomco.com

На заметку

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

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

franklin.threeroomco.com

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

• Сравнение с распределенными шаблонами. Одним из последних инструментов, предназначенных для борьбы со спамом, является Vipul's Razor (

http://razor.sourceforge.net

Таблица 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

sendmail

Формат конфигурационного файла

sendmail

sendmail

sendmail

Основной конфигурационный файл

sendmail

sendmail.cf

/etc

Обойти трудности, вызванные сложным форматом

sendmail.cf

m4

sendmail.cf

.mc

/etc/sendmail.mc

/usr/src/sendmail/cf/cf/linux.smtp.mc

/etc/mail/linux.mc

m4

.cf

sendmail.cf

linux.m

dnl

Для того чтобы создать файл

sendmail.cf

m4

m4

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

На заметку

В некоторых версиях Linux перед тем как приступать к созданию файла

sendmail.cf

из исходного файла

m4

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

sendmail-cf

.

Внимание

Не следует изменять рабочий вариант файла

sendmail.cf

. Желательно скопировать файл

sendmail.cf

и исходный файл

m4

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

sendmail

.

После изменения конфигурационного файла необходимо перезапустить

sendmail

sendmail

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

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

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

FEATURE(masquerade_envelope)

Запись

MASQUERADE_AS

From:

FEATURE(masquerade_envelope)

From:

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

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

FEATURE(`limited_masquerade')

Эти опции сообщают

sendmail

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

sendmail

sendmail

/etc/mail/local-host-names

/etc/sendmail.cw

sendmail.cf

Fw

#

Как было сказано ранее, ретрансляция является важным режимом работы почтового сервера. Как правило, настраивая

sendmail

sendmail

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

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

relaying denied

sendmail

FEATURE

• 

relay_entire_domain

sendmail

sendmail

relay_entire_domain

• 

relay_local_from

sendmail

From:

relay_local_from

From:

• 

relay_based_on_MX

sendmail

MX

relay_based_on_MX

sendmail

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

• 

OK

sendmail

• 

RELAY

• 

REJECT

• 

DISCARD

REJECT

• 

nnn текст

Отредактировав файл

access

makemap

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

При инсталляции

sendmail

sendmail

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

sendmail

sendmail

В большинстве случаев конфигурация

sendmail

m4

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

В данном случае

outgoing.mail.relay

sendmail.cf

sendmail

sendmail

Существует несколько способов настройки

sendmail

access

access.db

access.db

REJECT

DISCARD

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

m4

dnsbl

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

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

Данная запись указывает

sendmail

MAPS RBL

На заметку

В версии 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

sendmail

На заметку

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

Главный конфигурационный файл Exim называется

exim.conf

/etc

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

Как обычно, строки, содержащие комментарии, начинаются с символа

#

Совет

При инсталляции Exim в системе Debian запускается сценарий с именем

eximconfig

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

exim.conf

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

exim.conf

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

exim.conf

вручную, так как при использовании

eximconfig

приходится отвечать на целый ряд вопросов. Во многих случаях

eximconfig

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

Помимо

exim.conf

• 

/etc/aliases

sendmail

root: amelia

root

amelia

aliases

root: amelia@pangaea.edu

root

amelia@pangaea.edu

sendmail

aliases

• 

/etc/email-addresses

From:

ben: bfranclin@pangaea.edu

ben

bfranclin@pangaea.edu

Сценарий

eximconf

/etc/aliases

postmaster

root

root

/etc/email-addresses

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

hostname

qualify_domain

exim.conf

qualify_domain = threeroomco.com

Если пользователь

ben

From:

threeroomco.com

threeroomco.com

From:

ben@threeroomco.com

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

primary_hostname

qualify_domain

qualify_domain

primary_hostname

Received:

Для более сложной маскировки адресов применяется файл

/etc/email-addresses

/etc/email-addresses

exim.conf

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

 {$value}fail} bcfrF

Это одна из наиболее сложных записей, содержащихся в файле

exim.conf

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.conf

• 

local_domains

local_domains = localhost: threeroomco.com

localhost

threeroomco.com

qualify_recipient

qualify_recipient

• 

local_domains_include_host

true

local_domains

• 

local_domains_include_host_literals

true

ben

ben@[172.24.98.2]

false

local_domains_include_host_literals

Сценарий

eximconfig

Подобно

sendmail

eximconfig

exim.conf

Основные опции

exim.conf

• 

host_accept_relay

host_accept_relay = localhost

host_accept_relay = localhost:192.168.99.0/24:*.pangaea.edu

pangaea.edu

• 

relay_domains

*

host_accept_relay

• 

relay_domains_include_local_mx

MX

MX

• 

sender_address_relay

host_accept_relay

relay_match_host_or_sender = yes

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

host_auth_accept_relay

tls_host_accept_relay

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

eximconfig

eximconfig

smarthost:

 driver = domainlist

 transport = remote_smtp

 route_list = "* franklin.threeroomco.com bydns_a"

end

Приведенная выше группа записей сообщает Exim о том, что письма, адресованные внешним пользователям, надо передавать через узел

franklin.threeroomco.com

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

• 

host_reject

exim.conf

host_reject = *.badspammer.net:10.16.8.0/24

badspammer.net

host_reject

• 

host_reject_recipients

host_reject

RCPT TO:

• 

sender_reject

sender_reject = spammer@abigisp.com:badspammer.net

badspammer.net

spammer@abigisp.com

• 

sender_reject_recipients

sender_reject

RCPT TO:

sender_reject

• Фильтры, определяемые пользователем. Сервер Exim предоставляет пользователям возможность создавать собственные фильтры. Для их формирования используются файлы

.forward

filter.txt.gz

/usr/doc/exim

gunzip

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

exim.conf

• 

rbl_domains

/warn

/reject

/warn

/reject

/accept

/skiprelay

host_accept_relay

• 

rbl_hosts

*

rbl_domains

*

!

rbl_hosts = !ok.pangaea.edu:*

ok.pangaea.edu

• 

rbl_reject_recipients

/warn

/reject

rbl_domains

rbl_reject_recipients

rbl_reject_recipients = no

• 

recipients_reject_except

recipients_reject_except = posmaster@threeroomco.com

postmaster@threeroomco.com

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

• 

headers_check_syntax

true

headers_check_syntax

• 

helo_verify

HELO

EHLO

helo_verifу = *

helo_verifу

HELO

EHLO

• 

message_size_limit

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 определяются содержимым конфигурационного файла

main.cf,

/etc/postfix

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

Некоторые записи

main.cf

$

myhostname = franklin.threeroomco.com

myorigin = $myhostname

В первой записи переменной

myhostname

franklin.threeroomco.com

myorigin

Файл

main.cf

#

В файле

main.cf

sendmail

.db

aliases

aliases.db

sendmail

aliases

root: amelia

amelia

aliases

aliases.db

postalias aliases

aliases

После того как вы модифицируете содержимое текстового файла и создадите файл

.db

postfix reload

Опция

myorigin

$myhostnam

myorigin

myorigin = threeroomco.com

При желании вы можете указать в качестве значения опции переменную, например

$mydomain

$mydomain

$myhostname

franklin.threeroomco.com

$mydomain

threeroomco.com

main.conf

Опция

myorigin

ben@client.threeroomco.com

ben@client.threeroomco.com

$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 reload

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

myorigin

masquerade_domains

Received:

From:

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

mydestination

$myhostname

localhost.$mydomain

$mydomain

threeroomco.com

$myhostname

franklin.threeroomco.com

franklin.threeroomco.com

localhost.threeroomco.com

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

$mydomain

localhost

mydestination

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

 $mydomain

На заметку

Для того чтобы указать, что опция

mydestination

занимает несколько строк, символ

\

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

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

mydestination

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

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

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

$mynetworks

localhost

• Отправитель принадлежит домену, указанному в переменной

$relay_domains

$mydestination

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

$relay_domains

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

$mynetworks

$relay_domains

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

$mydestination

pangaea.edu

Для управления действием

mynetworks

relay_domains

smtpd_sender_restrictions

main.cf

permit_mx_backup

relay_based_on_MX

sendmail

smtpd_sender_restrictions

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

relayhost

main.cf

MX

relayhost

franklin.threeroomco.com

main.cf

relayhost = franklin.threeroomco.com

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

MX

franklin.threeroomco.com

$mydomain

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

/etc/hosts

disable_dns_lookups = yes

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

/etc/hosts

Подобно

sendmail

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

main.cf

header_checks = regexp:/etc/postfix/bad_headers

В файле

bad_headers

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

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_clien

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

• 

smtpd_helo_required

yes

HELO

EHLO

• 

smtpd_helo_restrictions

HELO

EHLO

smtpd_helo_restrictions

reject_unknown_hostname

А

MX

reject_non_fqdn_hostname

smtpd_helo_restrictions

• 

smtpd_sender_restrictions

From:

reject_unknown_sender_domain

From:

reject_non_fqdn_sender

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

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

sendmail

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

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

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

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

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

egrep

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

/etc/procmailrc

.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

:1

:0

• 

H

• 

В

• 

D

D

• 

с

• 

w

• 

W

w

После флагов можно указать двоеточие и имя файла блокировки. Файл блокировки — это специальный файл, который сообщает о том, что в данный момент происходит работа с другим файлом. При наличии файла 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

mbox

qmail

maildir

/

maildir

Помимо записи писем в папки, 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

! amy@threeroomco.com

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

: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

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

с

david@pangaea.edu

rug

Subject:

• Сортировка сообщений. Последний рецепт распределяет сообщения по папкам. Письма, адресованные

list@mailinglist.example.com

То:

Рецепты, приведенные в листинге 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 с комментариями. Web-узел

http://handsonhowto.com/pmail102.html

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

Procmail recipes

http://www.procmail.org

Простые наборы фильтров можно разместить в рабочем каталоге пользователя в файле

.procmailrc

/etc/procmailrc

Внимание

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

Совет

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

telnet

(для этого надо при установлении соединения указать порт 25).

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

• 

sendmail

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

сообщает

sendmail

FEATURE(local_procmail)

MAILER(procmail)

sendmail

• Exim. Около двух третей конфигурационного файла

exim.conf

procmail_pipe

• Postfix. В конфигурационном файле

main.cf

mailbox_command

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

.forward

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

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

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

Электронная почта — одна из наиболее важных служб Internet. Linux обеспечивает работу самых различных почтовых серверов, как всем известного

sendmail

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

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

Организовать выполнение основных функций Web-сервера в системе Linux не трудно, но разобраться с опциями, предназначенными для поддержки расширенных возможностей сервера, достаточно сложно. Описать эти опции в одной главе невозможно. Если вам потребуется подробная информация о работе Web-сервера, вам следует обратиться к документации на программный продукт, который вы собираетесь использовать, или к изданиям, специально посвященным этому вопросу: Энгельскелла (Engelschall) Apache Desktop Reference (Addison Wesley, 2001) или Олда (Auld) Linux Apache Server Administration (Sybex, 2001). Есть также книги, в которых описываются специальные функции Web-сервера. В качестве примера можно привести книгу Мелцера (Meltzer) и Микалски (Michalski), Writing CGI Applications with Perl (Addison Wesley, 2001).

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

Web-сервер — это программа, реализующая обмен данными посредством HTTP (Hypertext Transfer Protocol — протокол передачи гипертекстовой информации). Web-сервер принимает запросы от клиентов через некоторый порт (как правило, это порт с номером 80). HTTP-клиент (обычно его называют Web-броузером) передает Web-серверу запрос на получение документа. Получив запрос, Web-сервер читает документ с жесткого диска, или, если запрос предполагает вызов CGI-сценария, получает документ, сгенерированный этим сценарием. Затем документ передается клиенту. В протоколе HTTP предусмотрена также возможность передачи Web-серверу данных для обработки.

Web-сервер используется для организации Web-узла — набора документов, к которым пользователи могут обращаться, указывая URL (Uniform Resource Locator — унифицированный локатор ресурса). (Следует различать понятия Web-узел и узел сети. Если Web-узел представляет собой набор документов, то узел сети — это лишь компьютер или другое устройство, подключенное к сети.) Чаще всего URL начинаются с

http://

ftp://

http://

https://

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

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

Следует хорошо представлять себе различия между Web-узлом и Web-сервером. Web-узел, как было сказано выше, — это набор документов, представленных в Web, при обращении к которым пользователи указывают URL. В этих URL содержится доменное имя, которое часто отражает название организации. В отличие от Web-узла, Web-сервер — это набор программных или аппаратных средств, обеспечивающих поддержку Web-узла. При желании можно организовать работу Web-узла, не устанавливая в локальной сети Web-сервер. Для этого надо воспользоваться услугами сторонней организации, предоставляющей дисковое пространство своего Web-сервера для размещения на нем требуемых документов и программ. Как вы узнаете из данной главы, Web-сервер можно настроить так, чтобы его действия зависели от имени, указанного в запросе. Чтобы при указании имени, принадлежащего вашему домену, обращение осуществлялось к внешнему серверу, на котором размещены ваши документы, вам надо специальным образом настроить сервер DNS (настройка сервера DNS описывалось в главе 18). Например, если вы разместили документы на Web-сервере по адресу 10.102.201.1 и хотите связать с этим сервером имя

www

www IN A 10.102.201.1

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

Размещение данных на внешнем сервере имеет ряд преимуществ по сравнению с поддержкой собственного Web-сервера. Например, пропускная способность линии, посредством которой ваша локальная сеть подключена к Internet, может быть недостаточной для организации обмена данными с Web-сервером. (Так, например, линия с пропускной способностью 200 Кбод, которая может находиться в нерабочем состоянии до пяти часов в месяц, хороша для домашнего использования, но не подходит для большой компании, такой как IBM.) Размещая данные на сервере другой организации (например, на сервере провайдера), вы избавлены от необходимости поддерживать собственный Web-сервер. Недостатком такого подхода является необходимость платить деньги за аренду дискового пространства на сервере (от нескольких долларов до нескольких тысяч долларов в месяц, в зависимости от объема данных и трафика). Кроме того, некоторые внешние серверы не обеспечивают необходимых ресурсов. Например, может оказаться, что сервер не поддерживает CGI или SSL.

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

http://www.abigisp.net/~имя/

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

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

• Apache. Этот продукт поставляется в составе каждого дистрибутивного пакета Linux. Как правило, процедура установки системы запрашивает пользователя, следует ли инсталлировать сервер Apache. По данным Netcraft (

http://www.netcraft.com

http://httpd.apache.org

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

http://www.roxen.com/products/webserver/

• 

thttpd

thttpd

http://www.acme.com/software/thttpd/thttpd.html

• Zeus. Большинство Web-серверов, предназначенных для работы в системе Linux, бесплатно распространяются в исходных кодах, но Zeus является исключением. Это коммерческий продукт; его цена составляет 1700 долларов. Согласно информации, опубликованной на Web-узле Zeus (

http://www.zeus.co.uk/products/zws/

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

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

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

Как правило, требованиям большинства администраторов вполне удовлетворяет сервер Apache, поставляемый в комплекте со всеми версиями Linux. Если по каким-то причинам вам необходимо минимизировать объем памяти, занимаемый сервером, рассмотрите возможность использования сервера

thttpd

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

thttpd

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

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

В большинстве пакетов основной конфигурационный файл Apache носит имя

httpd.conf

httpd.conf

/etc/httpd

/etc/apache

/etc/apache/httpd.conf.default

httpd.conf

/etc/httpd/conf/

Как обычно, строки файла

httpd.conf

#

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

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

<Directory /home/httpd/html>

 Options FollowSymLinks

 AllowOverride None

</Directory>

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

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

httpd.conf

• 

access.conf

AccessConfig

httpd.conf

access.conf

<Directory>

AccessConfig

/dev/null

access.conf

• 

mime.types

text/plain

image/jpeg

mime.types

.txt

.asc

text/plain

• 

magic

magic

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

Совет

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

thttpd

или Web-сервер, выполняющийся как процесс ядра.

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

ServerType

standalone

inetd

inetd

/etc/inetd.conf

inetd

На заметку

В некоторых пакетах исполняемый файл Apache называется

apache

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

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

/home/httpd/html

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

• 

ServerType

standalone

inetd

• 

User

Group

nobody

На заметку

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

root

.

• 

ServerTokens

ProductOnly

OS

Full

ProductOnly

Внимание

Не следует считать, что, установив значение

ProductOnly

опции

ServerTokens

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

• 

MinSpareServers

MaxSpareServers

MinSpareServers

MaxSpareServers

MinSpareServers

MaxSpareServers

MinSpareServers

MaxSpareServers

MaxSpareServers

MaxSpareServers

• 

MaxClients

MaxClients

MaxClients

На заметку

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

MaxClients

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

MaxClients

.

• 

Listen

Listen 192.168.34.98:8080

192.168.34.98

8080

8000

8000

• 

BindAddress

BindAddress 192.168.34.98

BindAddress *

Совет

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

BindAddress 127.0.0.1

. При этом взаимодействие с другими компьютерами поддерживаться не будет. Для обращения к локальному серверу можно использовать URL

http://127.0.0.1

или

http://localhost

.

• 

Port

• 

ServerAdmin

webmaster

• 

ServerName

• 

DefaultType

text/plain

DefaultType

• 

HostnameLookups

On

Off

On

• 

LogLevel

debug

info

notice

warn

error

crit

alert

emerg

LogLevel

warn

• 

CustomLog

common

agent

referer

combined

httpd.conf

CustomLog

Помимо опций общего назначения, описанных выше, в файле

httpd.conf

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

• Протокол. Первый компонент URL (например,

http://

ftp://

http://

https://

• Имя узла. Имя узла, входящее в состав URL, представляет собой доменное имя компьютера, на котором выполняется Web-сервер. Например, в URL

http://www.threeroomco.com/thepage/index.html

www.threeroomco.com

А

CNAME

• Имя файла. В большинстве случаев HTTP-запрос предполагает передачу файла. В составе URL за именем узла следует имя файла (с указанием имени каталога). Например, в URL

http://www.threeroomco.com/thepage/index.html

thepage/index.html

DirectoryIndex

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

#

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

• 

ServerRoot

"/usr"

• 

DocumentRoot

"/home/httpd/html"

httpd.conf

Внимание

Значение директивы

DocumentRoot

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

• 

UserDir

~

UserDir

public_html

http://www.threeroomco.compilation/~abrown/photos.html

photos.html

public_html

abrown

disabled

disabled

<IfModule>

• 

DirectoryIndex

DirectoryIndex

index.html

http://www.threeroomco.com/public/

index.html

DocumentRoot

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

LoadModule

AddModule

AddModule mod_mime.с

В качестве значения директивы

AddModule

LoadModule

AddModule

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

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

http://modules.apache.org

В системах, подобных UNIX, и, в частности, в Linux, можно выделить два типа процессов: процессы ядра (kernel space processes) и пользовательские процессы (user space processes). Процесс ядра запускается очень быстро, а для запуска пользовательского процесса требуется относительно много времени, кроме того, пользовательский процесс часто должен осуществлять обмен важными данными с ядром. На практике такая особенность пользовательских процессов приводит к возникновению проблем, так как основная обработка информации осуществляется в пространстве пользовательского процесса. Задержка, связанная с запуском процесса, оправдывается повышением уровня безопасности и стабильности. Процессы ядра пользуются привилегиями при взаимодействии с аппаратными средствами, файловой системой и другими ресурсами, поэтому ошибка в программе или несанкционированное вмешательство извне могут привести к разрушению системы.

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

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

Для того чтобы оптимизировать обслуживание HTTP-запросов, были созданы простые Web-серверы, выполняющиеся как процессы ядра. В результате исчезла необходимость постоянного взаимодействия ядра и пользовательского процесса, и скорость обработки запросов клиента существенно увеличилась. Начиная с версии 2.4.x в состав ядра входят компоненты, реализующие Web-сервер kHTTPd. Подробная информация о таких компонентах находится по адресу

http://www.fenrus.demon.nl

/proc/sys/net/khttpd

1. Включите поддержку kHTTPd при конфигурации ядра Linux. Для этого используется опция Kernel HTTPd Acceleration, находящаяся в меню Networking Options. Вы можете сформировать требуемый компонент в виде модуля или непосредственно включить его в состав ядра.

2. Измените конфигурацию Apache так, чтобы этот сервер использовал для приема обращений клиентов порт 8080 или любой другой, отличный от порта 80.

3. Перезагрузите систему или загрузите модуль ядра kHTTPd. В зависимости от конфигурации он либо загрузится автоматически, либо вам придется использовать команду

insmod khttpd

4. Укажите серверу kHTTPd на то, что он должен принимать запросы клиентов через порт 80. Для этого надо выполнить команду

echo 80 > /proc/sys/net/khttpd/serverport

5. Введите команду

echo 8080 > /proc/sys/net/clientport

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

echo /home/httpd/html > /proc/sys/net/khttpd/documentroot

/home/httpd/html

httpd.conf

DocumentRoot

7. Если на вашем Web-узле содержатся PHP3 или защищенные HTML-документы, повторите предыдущее действие, но поместите имя каталога в файл

/proc/sys/net/khttpd/dynamic

8. Введите команду

echo 1 > /proc/sys/net/khttpd/start

При желании вы можете создать сценарий SysV или локальный сценарий, который автоматизировал бы выполнение этапов 4-8 описанной выше процедуры. Независимо от того, будет ли сервер запущен вручную или с помощью сценария, он будет поддерживать простые запросы, предполагающие передачу клиентам статических файлов, находящихся в указанном каталоге. Запрос который не может быть обработан средствами kHTTPd (например, запрос, предполагающий запуск CGI-сценария), будет передан Web-серверу, выполняющемуся как пользовательский процесс. При этом будет использован номер порта, указанный на этапах 2 и 5. Такая передача запроса связана с большими накладными расходами, поэтому если Web-узел предполагает в основном выполнение CGI-сценариев, использовать для его поддержки сервер kHTTPd нецелесообразно. Более того, применять kHTTPd имеет смысл только в том случае, если сервер Apache не справляется с нагрузкой. Если же интенсивность обращений к серверу не велика, предпочтительнее использовать один из серверов, выполняющихся как пользовательский процесс. Следует также помнить, что kHTTPd официально считается экспериментальным продуктом, поэтому он не может обеспечить такой надежности, как Apache или другие подобные серверы. Поскольку kHTTPd выполняется как процесс ядра, ошибка в программе может нанести системе гораздо больше вреда, чем ошибка в сервере, выполняющемся как пользовательский процесс. Таким образом, если у вас нет веских оснований применять kHTTPd, лучше использовать вместо него хорошо отлаженный и зарекомендовавший себя в работе сервер Apache.

Сервер kHTTPd — не единственный продукт подобного типа, реализованный как процесс ядра. В системе Red Hat применяется сервер TUX, кроме того, в настоящее время ведется работа над созданием других серверов, предназначенных для выполнения в виде процессов ядра Linux.

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

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

• HTML-файлы. В настоящее время основная часть данных в Internet представлена в формате HTML (Hypertext Markup Language язык разметки гипертекста). HTML-файлы имеют расширение

.htm

.html

<P>

</P>

• Текстовые файлы. Файлы такого типа чаще всего имеют расширение

.txt

• Графические файлы. Почти все 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-узлов. Возможности подобных узлов ограничены лишь воображением разработчиков и их готовностью реализовать свои планы. С точки зрения 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-сценарии, то должны сообщить серверу 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

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

/home/httpd/cgi-bin/

/scripts

http://www.threeroomco.com/scripts/test.pl

test.pl

/home/httpd/cgi-bin/

LoadModule

AddModule

httpd.conf

mod_alias

• 

Options +ExecCGI

+ExecCGI

<Directory

• 

.htaccess

.htaccess

.htaccess

Options +ExecCGI

httpd.con

AllowOverride Options

.htaccess

Внимание

Наличие записей

Options +ExecCGI

и

AllowOverride Options

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

.htaccess

запрещено.

Часто при настройке Apache в конфигурационный файл включается директива

ScriptAlias

/home/httpd/cgi-bin

/cgi-bin

/home/httpd/cgi-bin

/home/httpd/cgi-bin

chmod a+x имя_сценария

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

http://httpd.apache.org/docs/howto/cgi.html

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

Помимо HTML-кода, CGI-сценарий должен создать поле заголовка

Content-Type

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

В данном примере указан MIME-тип

text/html

\r\n\r\n

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

#!/usr/bin/perl

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

print "Hello, Web";

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

=

&

city=Oberlin&state=OH&zip=44074

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

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

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

User

Group

httpd.conf

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

http://www.cpan.org

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

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

mod_ssl

http://www.modssl.org

http://www.apache_ssl.org

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

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

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

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

http://www.abigretailer.com

На заметку

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

http://www.apache-ssl.org/#Digital_Certificates

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

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

https://

thttpd

Для того чтобы сервер 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. При использовании сертификата, сгенерированного самостоятельно, пользователи, взаимодействующие с узлом, увидят предупреждающее сообщение о том, что сертификат не распознан или срок его действия истек

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

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

etc/apache-ssl

/etc/apache

• 

ServerType

ServerType

standalone

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

Listen

• Загрузка модулей. В качестве значений директив

LoadModule

AddModule

• 

SSLRequireSSL

<Directory>

SSLRequireSSL

• 

SSLEnable

SSLEnable

SSLRequireSSL

• 

SSLCACertificatePath

SSLCACertificatePath

/etc/apache-ssl

• 

SSLCertificateFile

/etc/apache-SSI/apache.pem

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

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

https://

Внимание

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

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

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

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

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

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

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

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

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

VirtualDocumentRoot

VirtualDocumentRoot

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

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

VirtualDocumentRoot /home/httpd/%0

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

/home/httpd

http://www.threeroomco.com/index.html

/home/httpd/www.threeroomco.com/index.html

/home/httpd

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

Если в конфигурационном файле содержится такое выражение, то, получив запрос, в котором указан URL

http://www.threeroomco.com/index.html

/home/httpd/com/threeroomco/index.html

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

Теперь при получении URL

http://www.threeroomco.com/index.html

/home/httpd/t/www.threeroomco.com/index.html

%-2.1

.1

-2

Независимо от значения директивы

VirtualDocumentRoot

Off

UseCanonicalName

UseCanonicalName Off

Если директива

UseCanonicalName

On

index.html

products.html

Off

UseCanonicalName

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

• 

NameVirtualHost

*

NameVirtualHost

• 

<VirtualHost>

NameVirtualHost

</VirtualHost>

В составе блока, сформированного с помощью

<VirtualHost>

ServerName

DocumentRoot

NameVirtualHost *

<VirtualHost *>

 ServerName www.threeroomco.com

 DocumentRoot /home/httpd/threeroomco/html

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

</VirtualHost>

<VirtualHost *>

 ServerName www.pangaea.edu

 DocumentRoot /home/httpd/pangaea-u/html

</VirtualHost>

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

www.threeroomco.com

/home/httpd/threeroomco/html

/home/httpd/threeroomco/cgi-bin

www.pangaea.edu

/home/httpd/pangaea-u/html

В отличие от

VirtualDocumentRoot

<VirtualHost>

VirtualDocumentRoot

<VirtualHost>

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

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

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

/

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

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

<!DOCTYPE html public "-//IETF//DTD HTML 2.0//EN">

<HTML>

 <HEAD>

  <TITLE>Пример Web"=страницы</TITLE>

 </HEAD>

 <BODY BGCOLOR="#FFFFFFF" TEXT="#000000">

  <CENTER><H1 ALIGN= "CENTER">Пример Web"=страницы</H1></CENTER>

  <IMG SRC="graphics/logo.jpg" ALT="Logo" WIDTH="197" HEIGHT="279">

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

 </BODY>

</HTML>

• 

<HTML>

• 

<HEAD>

<TITLE>

<HEAD>

• 

<TITLE>

• 

<BODY>

<BODY>

• 

<H1>

<H1>

<H6>

<H1>

ALIGN

<CENTER>

• 

<CENTER>

<H1>

ALIGN

<CENTER>

<CENTER>

ALIGN

• 

<IMG>

<IMG>

<IMG>

SRC

SRC

ALT

WIDTH

HEIGHT

• 

<P>

• 

<А HREF>

<А>

HREF

HREF

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

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

<IMG>

mime.types

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

• GIF. Graphics Interchange Format (формат обмена графическими данными) приобрел популярность в 1980-х. В данном формате используется схема сжатия без потери информации. Это означает, что изображение, полученное после распаковки, будет в точности совпадать с исходным изображением. Для представления цвета в GIF-изображениях используется до 8 битов, т.е. такое изображение может содержать максимум 256 цветов.

• PNG. Portable Network Graphic (переносимые сетевые графические данные) также использует схему сжатия без потери информации. В отличие от GIF, PNG позволяет представлять цвет посредством большего количества битов (обычно применяется 24-битовое представление, но PNG дает возможность использовать для этой цели до 64 битов). Недостатком PNG является тот факт, что данный формат поддерживается не всеми броузерами. Более подробную информацию о PNG можно получить по адресу

http://www.libpng.org/pub/png/

• JPEG. В формате Joint Photographic Expert Group (объединенная группа экспертов по обработке фотоснимков) используется сжатие с потерей информации. В результате достигается большая степень сжатия по сравнению с форматами GIF и PNG, но распакованное изображение отличается от исходного. Для представления цвета в JPEG может применяться до 24 битов.

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

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

Несмотря на то что HTML-документы можно создавать с помощью обычных текстовых редакторов, многие Web-дизайнеры предпочитают использовать для этой цели специализированные инструменты с графическим пользовательским интерфейсом. Данные инструменты позволяют редактировать текст документа подобно текстовым процессорам WYSIWYG (what you see is what you get); при этом для выравнивания, создания абзацев, отображения текста полужирным шрифтом и выполнения других подобных действий используются кнопки, расположенные на панели инструментов. Поскольку при работе сервера Apache не имеет значения, каким способом были сформированы Web-страницы, нет никаких оснований отказываться от использования специализированных инструментальных средств. Единственным исключением является редактор Microsoft Front Page. Этот инструмент создает Web-страницы, ориентированные на конкретный сервер, поэтому при работе с Apache лучше отказаться от его использования.

На заметку

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

Ниже описаны некоторые инструменты, которые могут быть использованы при создании Web-страниц.

• Текстовые процессоры. Многие современные текстовые процессоры предоставляют возможность экспортировать документы в формате HTML. (Поскольку средства форматирования текстовых процессоров мощнее, чем соответствующие средства, предусмотренные в языке HTML, при сохранении документа в виде HTML-файла внешний вид текста может несколько измениться.) Для тех, кто привык работать с текстовыми процессорами, они могут стать удобными инструментами подготовки Web-страниц. В системе Linux возможность экспортирования в HTML-формат предоставляют программы Applix Words, StarOffice и WordPerfect.

• Web-броузеры. Многие популярные Web-броузеры, выполняющиеся в системе Linux, в частности Netscape, содержат средства для подготовки HTML-документов. Такие средства лучше подходят для создания Web-страниц, чем текстовые процессоры.

• Независимые программы подготовки Web-страниц. Единственным назначением этих инструментов является создание HTML-документов. В качестве примеров подобных программ, работающих в системе Linux, можно привести ASHE (

http://www.cs.rpi.edu/pub/puninj/ASHE/

http://www.lls.se/~johanb/august/

http://bluefish.openoffice.nl

http://www-4.ibm.com/software/webservers/hpbuilder/

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

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

<CENTER>

ALIGN

Поскольку броузеры по-разному интерпретируют HTML-код, желательно проверять созданные вами Web-страницы в различных броузерах. Как минимум вы должны выяснить, как отображаются ваши документы в наиболее популярных на сегодняшний день клиентских Web-программах: Netscape Navigator и Microsoft Internet Explorer. По возможности следует проверить качество воспроизведения документа в различных версиях этих броузеров. Следует также учитывать, что в последнее время среди пользователей Linux стали популярны броузеры Mozilla (

http://www.mozilla.org

http://www.opera.com

http://lynx.browser.org

Совет

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

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

На заметку

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

CustomLog

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

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

CustomLog

combined

combined

192.168.1.1 - - [06/Nov/2002:16:45:49 -0500] "GET /index.html \

 HTTP/1.0" 200 8597 "-" "Mozilla (X11; I; Linux 2.0.32 i586)"

Эта запись включает следующие компоненты.

• Доменное имя или IP-адрес клиента. Первое поле записи содержит адрес или имя клиента, от которого был получен запрос.

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

identd

• Дата и время. Apache записывает дату и время передачи запроса. В этой записи содержится локальное время с указанием временного пояса (в данном примере

-0500

• HTTP-запрос. HTTP-запрос включает команду, переданную клиентом (

GET

/index.html

1.0

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

200

• Размер объекта. Число 8597 соответствует размеру ресурса, который Apache передал клиенту в ответ на запрос. При вычислении размера объекта заголовок ответа не учитывается.

• Документ, ссылающийся на текущий ресурс. Если пользователь запросил новый ресурс щелчком на гипертекстовой ссылке в составе HTML-документа, броузер передает серверу в составе запроса URL этого документа. Полученные сведения Apache записывает в файл протокола. В приведенном выше примере в данном поле содержится дефис, означающий, что документ, ссылающийся на запрашиваемый ресурс, не определен. Это может быть в случае, если пользователь непосредственно ввел URL ресурса в поле адреса броузера.

• Клиентская программа. Последнее поле записи содержит информацию о броузере, а также сведения об операционной системе, в которой он выполняется. (Заметьте, что броузер Netscape сообщает о себе с помощью идентификатора

Mozilla

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

На заметку

В большинстве версий Linux инструмент

cron

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

cron

обычно описывается в каталоге

/etc/cron.d

или

/etc/cron.interval

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

Analog (

http://www.analog.cx

http://www.statslab.cam.ac.uk/~sret1/stats/stats.html

Работой программы Analog управляет конфигурационный файл

analog.cfg

etc.

SEARCHENGINE

LOGFILE путь_к_файлу_протокола

OUTFILE путь_к_файлу_содержащему_выходные_данные

HOSTNAME "имя_организации"

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

httpd/html/analog/index.html

HOSTNAME

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

• Конфигурационный файл. При создании некоторых пакетов Analog считается, что файл

analog.cfg

/usr/bin

/etc

/usr/bin

/etc

ln -s /etc/analog.cfg /usr/bin

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

/var/lib/analog/lang

/usr/bin/lang

ln -s /var/lib/analog/lang /usr/bin

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

/var/www/html/images

ln -s /var/ww/html/ images

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

analog-5.01-1mdk

Для запуска программы Analog на выполнение необходимо ввести команду

analog

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

cron

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

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

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

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

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

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

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

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

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

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

• Отчет о типах файлов. В данном отчете сообщается о типах файлов (JPEG, HTML и т.д.), предоставляемых Web-сервером. Эта информация может быть использована для тех же целей, что и сведения, содержащиеся в отчете о размерах файлов.

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

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

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

cron

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

http://www.reportmagic.com

Инструмент Webalizer (

http://www.webalizer.org

http://www.webalizer.org/sample/

Работой Webalizer управляет конфигурационный файл

webalizer.conf

/etc

LogFile путь_к_файлу_протокола

OutputDir путь_к_каталогу_содержащему_выходные_данные

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

file://

• 

Incremental

yes

Incremental

no

• 

HostName

ReportTitle

• 

GroupDomains

GroupDomains

gingko.pangaea.edu

birch.pangaea.edu

pangaea.edu

• 

GroupSite

GroupSite *.abigisp.net

abigisp.net

• 

HideSite

GroupSite

GroupSite

HideSite

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

Для запуска Webalizer надо ввести команду

webalizer

root

cron

yes

Incremental

Часто при инсталляции Apache, формируется задача для инструмента

cron

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

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

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

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

• URL наиболее популярных документов. Webalizer отображает две таблицы, в которых содержится информация о числе обращений и объеме скопированных данных для различных URL. (При необходимости вы можете объединять URL в группы, используя для этого рассмотренные ранее опции.) Одна таблица отображает URL документов, к которым было максимальное количество обращений, другая — URL, в результате обращения к которым были скопированы данные наибольшего объема.

• Входная и выходная страницы. Следующие две таблицы, генерируемые Webalizer, содержат сведения о наиболее популярной входной и выходной страницах. Входной страницей (entry page) называется документ, к которому обращается пользователь в начале работы с узлом, а выходной страницей (exit page) — документ, который пользователь просматривает непосредственно перед завершением работы.

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

GroupSite

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

• Наиболее часто используемые ключевые слова. Некоторые поисковые серверы, в базе данных которых учтены документы, расположенные на вашем Web-узле, включают в состав URL строку поиска. Webalizer выделяет эту информацию и представляет в отчете.

• Наиболее популярные клиентские программы. Webalizer учитывает типы Web-броузеров, наиболее часто обращающихся к вашему узлу.

• Наиболее популярные страны. В последнем разделе Webalizer предоставляет информацию об обращениях к документам из разных стран. Страна определяется на основании домена верхнего уровня, поэтому наряду с реальными странами на Web-странице встречаются US Commercial, Network и другие подобные имена.

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

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

Протокол FTP (File Transfer Protocol — протокол передачи файлов) существует давно и пользуется большой популярностью в Internet. Он обеспечивает обмен файлами между компьютерами, подключенными к сети. FTP-клиенты могут копировать файлы с сервера и, если позволяет конфигурация сервера, передавать информацию на сервер. Иногда FTP-сервер может заменить Web-сервер или файловый сервер, но в большинстве случаев его можно рассматривать как дополнение к этим средствам. В ряде ситуаций наличие FTP-сервера на компьютере не оправдано. Если вы приняли решение установить FTP-сервер, можете воспользоваться для этой цели различными программами, ориентированными на работу в системе Linux. По умолчанию программы, реализующие FTP-серверы, настроены для выполнения определенного круга задач. Возможно, вам придется изменить конфигурацию сервера. В некоторых случаях возникает необходимость в анонимном FTP-сервере, который позволяет каждому желающему копировать файлы на свой компьютер.

FTP-сервер имеет некоторое сходство с Web-сервером, рассмотренным в главе 20, а также с серверами Samba и NFS, предназначенными для разделения файлов (о них шла речь в главах 7 и 8). Все эти серверы позволяют передавать файлы с одного компьютера на другой и в некоторых ситуациях взаимозаменяемы. Однако каждый из этих протоколов имеет свои особенности, определяющие выбор сервера для решения определенного круга задач. Ниже описаны основные отличия FTP-сервера от серверов HTTP, Samba и NFS.

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

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

• Шифрование. Стандартные FTP-серверы не выполняют шифрование данных, в том числе имени пользователя и пароля. Это создает опасность при передаче информации через Internet. Исключением в данном случае являются анонимные FTP-серверы, при использовании которых шифрование информации не имеет смысла. Существуют защищенные версии FTP, поддерживающие кодирование передаваемых данных. Защиту информации, которая передается средствами FTP, обеспечивают также средства Kerberos, которые рассматривались в главе 6. В обычных условиях Web-серверы не выполняют шифрование данных, хотя при необходимости такая возможность реализуется достаточно просто. Сервер Samba может быть настроен для шифрования паролей и прочей информации. NFS не использует пароли, поэтому о кодировании паролей речь не идет. Что же касается данных, передаваемых средствами NFS, при необходимости шифрование их может осуществляться. Программы

scp

sftp

Совет

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

• Поддержка соединения. Подобно Samba и NFS, при обмене данными по протоколу FTP поддерживается постоянное соединение. Пользователь может зарегистрироваться на FTP-сервере, бездействовать в течение длительного времени (столько, сколько позволяет установленное значение тайм-аута), а затем скопировать файл с сервера. Web-серверы действуют совершенно по-другому; в рамках соединения может быть передан один, в крайнем случае несколько файлов. FTP коренным образом отличается от других протоколов подобного назначения тем, что при взаимодействии клиента и сервера используются два порта: один для передачи команд, а другой для передачи данных. Клиент обращается к серверу через порт 21. Затем в зависимости от режима (режим может быть активным или пассивным) передача данных осуществляется либо по инициативе клиента, либо по инициативе сервера. Такая особенность взаимодействия усложняет настройку брандмауэров, однако в большинстве программ, реализующих брандмауэры, предусмотрены специальные средства, позволяющие решить эту задачу.

• Непосредственная обработка файлов. Серверы, предназначенные для разделения файлов, например NFS и Samba, предоставляют возможность обрабатывать удаленные файлы так, как будто они расположены на локальном компьютере. Например, пользователь может загрузить файл с удаленной машины в текстовый редактор, внести в него необходимые изменения и снова сохранить на удаленном компьютере. При этом файл на локальный диск не копируется. Ни FTP, ни HTTP не обеспечивают подобной возможности. Если доступ к удаленному компьютеру может осуществляться только посредством протокола FTP или HTTP, то, для того, чтобы отредактировать файл, вы должны сначала скопировать его на локальную машину, внести и сохранить изменения, а затем снова передать файл на сервер. Существуют средства, позволяющие организовать разделение файлов с помощью протокола FTP. В системе Linux такую возможность предоставляет продукт Linux FTP Filesystem (

http://ftpfs.sourceforge.net

• Двунаправленная передача данных. Серверы, предназначенные для разделения файлов, и FTP-сервер позволяют передавать данные с сервера на клиентскую машину и наоборот. При необходимости системный администратор имеет возможность запретить запись файлов на диск сервера. Web-серверы в основном применяются для передачи данных с сервера на клиентский компьютер, но в протоколе HTTP предусмотрена также возможность передавать информацию на сервер.

• Работа клиентов на различных платформах. FTP- и Web-серверы взаимодействуют с клиентами, выполняющимися в любой операционной системе, поддерживающей TCP/IP; не является исключением даже система DOS. В отличие от FTP и HTTP, протоколы разделения файлов ориентированы на конкретную платформу: сервер NFS работает с клиентами UNIX и Linux, a Samba — с клиентами DOS, Windows и OS/2. Пытаясь обеспечить межплатформенную совместимость протоколов разделения файлов, вы неизбежно столкнетесь с проблемами представления прав доступа, атрибутов файлов и другими ограничениями. При этом вам также приходится обеспечивать взаимодействие с клиентскими программами, многие из которых распространяются на коммерческой основе.

• Трудозатраты при настройке сервера. По умолчанию в системе Linux устанавливается конфигурация FTP-сервера, предоставляющая пользователям такие же права чтения и записи файлов, которые они получили бы, зарегистрировавшись на компьютере. Если вас устраивает подобное поведение сервера, его настройка займет крайне мало времени. Чтобы обеспечить подобное взаимодействие с серверами NFS, Samba и HTTP, вам придется внести существенные изменения в их конфигурационные файлы. С другой стороны, чтобы установить анонимный FTP-сервер, надо приложить определенные усилия для его настройки, в то время как в других серверах подобный принцип взаимодействия с пользователями реализован по умолчанию.

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

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

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

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

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

• BSD FTPD. Версия BSD Unix поставляется в комплекте с FTP-сервером, который адаптирован для переноса в систему Linux. Так, например, на выполнение в Linux ориентирован пакет OpenBSD FTPD. Варианты BSD FTPD поставляются с системами Debian и SuSE. От других FTP-серверов BSD FTPD отличается более надежными средствами защиты, но, тем не менее, он не получил большой популярности среди пользователей Linux.

• ProFTPd. Пакет ProFTPd, Web-сервер которого находится по адресу

http://www.proftpd.org

• WU-FTPD. Washington University FTP Daemon (WU-FTPD) — наиболее популярный из современных FTP-серверов для Unix. Web-узел WU-FTPD расположен по адресу

http://www.wu-ftpd.org

Каждая из этих программ поддерживает основные функции и некоторые из расширенных функций FTP-сервера. В данной главе описываются только продукты ProFTPd и WU-FTPD, так как именно они пользуются наибольшей популярностью и поставляются в составе различных дистрибутивных пакетов Linux. Программа ProFTPd обладает большей гибкостью и с точки зрения безопасности превосходит WU-FTPD. Однако если в составе вашей системы поставляется только WU-FTPD либо если вы хорошо знакомы с данным продуктом, имеет смысл остановить свой выбор на нем. Если же вы склонны экспериментировать, попробуйте установить в своей системе BSD FTPD.

Инсталлировав FTP-сервер, надо обеспечить его выполнение. Как правило, в дистрибутивных пакетах, комплектуемых WU-FTPD, запуск данной программы осуществляется посредством суперсервера, а если в составе системы содержится ProFTPd, для его запуска обычно используют сценарий SysV. Если вас не устраивает подход, использованный в вашей системе, вы можете реализовать альтернативное решение. При работе со многими дистрибутивными пакетами обеспечение запуска FTP-сервера является единственным действием, необходимым для его настройки, так как конфигурация, установленная по умолчанию, позволяет использовать сервер для решения многих задач. Так, например, по умолчанию пользователь, для которого в системе существует учетная запись, имеет возможность регистрироваться на FTP-сервере и копировать файлы из своего рабочего каталога. Если в вашей системе сервер должен действовать по-другому, следует изменить его настройку. Наиболее часто используемый вариант настройки — анонимный FTP-сервер — будет рассмотрен далее в этой главе.

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

• В некоторых дистрибутивных пакетах, использующих

inetd

/etc/inetd.conf

inetd.conf

inetd

inetd.conf

• В большинстве систем, использующих xinetd для запуска FTP-сервера, в каталог

/etc/xinetd.d

disable = yes

no

disable

• Независимо от того, запускается ли FTP-сервер посредством

inetd

xinetd

Если ваш FTP-сервер часто посещают пользователи, имеет смысл запускать его с помощью сценария SysV или локального сценария запуска. В этом случае сервер будет быстрее отвечать на запросы, но, учитывая небольшие размеры программы, реализующей сервер, увеличение быстродействия будет минимальным. В некоторых версиях Linux, например в Debian и Mandrake, данный подход применяется для запуска ProFTPd. Если же ProFTPd постоянно присутствует в памяти, поддержка анонимного FTP-сервера упрощается.

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

ftp

$ ftp harding.threeroomco.com

ftp: connect: Connection refused

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

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

В большинстве случаев конфигурационные файлы, управляющие работой WU-FTPD, находятся в каталоге

/etc

ftp

• 

ftpaccess

ftpaccess

• 

ftpconversions

ftpaccess

• 

ftphosts

allow

deny

deny sjones

sjones

deny badsite.pangaea.edu

badsite.pangaea.edu

•

ftpusers

root

nobody

daemon

•

ftpservers

192.168.21.8 /etc/ftpd/trusted

/etc/ftpd/trusted

Из перечисленных выше файлов наиболее важным является

ftpaccess

ftphosts

ftpusers

ftpservers

ftpaccess

ftpconversions

Действие многих из опций, определяющих конфигурацию WU-FTPD, базируется на понятии класса. Класс — это группа пользователей, подобная группе Linux. Для определения класса в файле

ftpaccess

class

class имя_класса список_типов список_адресов

Назначение компонентов этой записи описано ниже.

• Имя класса. По умолчанию при инсталляции сервера часто создается универсальный класс с именем

all

• Список типов. В этом поле указывается список типов учетных записей, соответствующих данному классу. Ключевое слово

real

guest

• Список адресов. Данный список содержит IP-адреса, имена узлов и имена доменов, принадлежащих классу. Символ

!

*

OR

threeroomco.com

pangaea.edu

Стандартный файл

ftpaccess

class all real,guest,anonymous *

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

В файл

ftpaccess

• 

deny список_адресов файл_с_сообщением

deny

ftphosts

• 

autogroup имя_группы класс[, класс, ...]

setgid

• 

defumask umasк класс [, класс]

umask

• 

timeout ключевое_слово время_в_секундах

accept

connect

data

idle

maxidle

rfc931

• 

noretrieve [relative|absolute] [class=имя_класса] имена_файлов

relative

absolute

chroot

/

noretrieve /etc /usr

/etc

/usr

Совет

Опцию

noretrieve

часто используют для того, чтобы запретить доступ к

/etc/passwd

,

/etc/shadow

,

/etc/ftpaccess

, файлу

core

(находящемуся в любом каталоге) и другим важным файлам.

• 

allowretrieve [relative|absolute] [class=имя_класса] имена_файлов

noretrieve

noretrieve

noretrieve

• 

message имя_файла [событие] [класс]

message

login

cwd=каталог

message .message cwd=*

.message

• 

compress [yes|no] класс [,класс]

file

file.gz

ftpconversions

• 

chmod

delete

overwrite

rename

umask

yes

no

delete no guest, anonymous

guest

anonymous

• 

tar [yes|no] класс[, класс]

compress

• 

dns refuse_mismatch

• 

dns refuse_no_reverse имя_файла

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

ftpaccess

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

Главный конфигурационный файл ProFTPd называется

proftpd.conf

/etc

#

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

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

/

Limit

<Limit WRITE>

 DenyAll

 Allow from 172.21.33.

</Limit>

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

ftpusers

ftpusers

ftpusers

nobody

daemon

root

ftpusers

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

http://www.proftpd.org/docs/

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

• 

<Anonymous имя_каталога>

chroot

chroot()

• 

<Directory имя_каталога>

/

<Directory /*>

• 

<Global>

<Global>

<VirtualHost>

• 

<Limit группа_команд>

CWD

CDUP

MKD

RNFR

RNTO

DELE

RMD

RETR

STOR

READ

WRITE

DIRS

ALL

LOGIN

• 

<VirtualHost адрес>

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

• 

Allow [from] идентификаторы_узлов

<Limit>

all

none

Allow

from

Совет

Вместо имен узлов и доменов рекомендуется использовать блоки IP-адресов. Это уменьшает зависимость FTP-сервера от работы DNS-сервера.

• 

AllowAll

AllowAll

<Directory>

<Limit>

<Anonymous>

• 

AllowGroup список_групп

<Limit>

DenyAll

• 

AllowOverwrite [on|off]

• 

AllowUser список_пользователей

AllowUser

!

• 

DefaultRoot имя_каталога [список_групп]

/

~

DefaultRoot

AllowGroup

Совет

Указав глобальную опцию

DefaultRoot ~

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

• 

DefaultTransferMode [ascii|binary]

binary

ascii

DefaultTransferMode

ascii

• 

Deny [from]

Allow

<Limit>

• 

DenyAll

<Limit>

<Anonymous>

<Directory>

DenyAll

• 

DenyGroup список_групп

<Limit>

AllowGroup

• 

DenyUser список_пользователей

AllowUser

<Limit>

• 

DisplayConnect имя_файла

• 

DisplayFirstChdir имя_файла

.message

.message

• 

DisplayLogin имя_файла

DisplayConnect

• 

Group идентификатор_группы

nogroup

ftp

• 

MaxClients число | none

none

• 

MaxInstances число

MaxClients

MaxClients

MaxInstances

MaxInstances

• 

Order allow, deny|deny, allow

<Limit>

Order deny, allow

• 

RootLogin on|off

root

RootLogin on

root

root

/etc/ftpusers

• 

ServerIdent on|off ["строка-идентификатор"]

on

• 

ServerName "строка-идентификатор"

ServerIdent

ServerIdent

ServerName

• 

ServerType inetd|standalone

inetd

standalone

inetd

root

standalone

• 

SyslogLevel emerg|alert|crit|error|warn|notice|info|debug

emerg

debug

• 

TransferLog имя_файла|NONE

NONE

<Anonymous>

<VirtualHost>

<Global>

• 

Umask маска_файла [маска_каталога]

umask

• 

UseFtpUsers on|off

off

UseFtpUsers

/etc/ftpusers

on

• 

UserAlias псевдоним имя_пользователя

UserAlias rjones ronald

rjones

ronald

ftp

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

<Anonymous>

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

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

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

ftp://

ftp://ftp.threeroomco.com/pub/manual.pdf

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

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

Внимание

Несмотря на то что поддерево

chroot

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

Если FTP-сервер использует поддерево

chroot

chroot

Некоторые варианты конфигурации FTP-сервера (в особенности это касается ProFTPd) лучше работают при запуске сервера посредством сценария SysV. В других случаях нормальная работа обеспечивается и при использовании суперсервера (это справедливо для WU-FTPD). Одна из особенностей настройки FTP-сервера состоит в том, что системный вызов

chroot()

root

chroot

chroot()

Для работы анонимного FTP-сервера необходимо, чтобы некоторые файлы располагались в определенных каталогах. Этот вопрос будет подробнее рассмотрен далее в этой главе.

Поскольку анонимный FTP-сервер доступен всем желающим, он может создавать серьезную угрозу для системы. Считается, что поддерживать на компьютере анонимный FTP-сервер не более опасно, чем Web-сервер или почтовый сервер. Однако, как показывает опыт многих администраторов, риск оказывается намного больше. Одна из причин состоит в том, что в защите многих программ, реализующих FTP-серверы (и особенно в WU-FTPD) были обнаружены многочисленные недостатки. Еще один источник опасности связан с тем, что FTP-сервер обеспечивает двунаправленную передачу данных, поэтому, если взломщику удастся воспользоваться недостатками защиты и выйти за пределы поддерева

chroot

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

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

Большинство FTP-пакетов, поставляемых в составе различных версий Linux, полностью или частично сконфигурированы для функционирования в качестве анонимного FTP-сервера. Для того чтобы окончить настройку, вам надо приложить лишь минимальные усилия. В данном разделе описываются опции, позволяющие реализовать анонимный FTP-сервер как с помощью WU-FTPD, так и посредством ProFTPd. Вначале будет рассмотрено создание дерева каталогов (эта задача решается одинаково для обоих серверов), а затем — средства конфигурации для каждого из серверов.

Первый шаг по организации работы FTP-сервера — это создание поддерева каталогов. Как правило, корнем этого поддерева является каталог

/home/ftp

root

rwxr-xr-x

В большинстве случаев в составе поддерева FTP задаются следующие подкаталоги.

• 

pub

pub

• 

bin

/bin

chroot()

ls

tar

gzip

zcat

gzip

bin

/bin

• 

lib

/bin

/bin

/bin

ldd

ldd /bin/ls

• 

etc

/etc

passwd

group

/etc

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

gzip

/bin

Наиболее важные опции, используемые для создания анонимного FTP-сервера на базе продукта WU-FTPD, находятся в файле

/etc/ftpaccess

• 

class

• 

compress

tar

chmod

delete

overwrite

rename

• 

anonymous-root

chroot

В большинстве систем WU-FTPD запускается посредством суперсервера с привилегиями

root

ftp

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

proftpd.conf

<Anonymous /home/ftp>

 User      ftp

 Group     ftp

 # При регистрации пользователь может указывать имя anonymous

 # либо ftp

 UserAlias anonymous ftp

 # В пределах поддерева chroot запись данных запрещена

 <Limit WRITE>

  DenyAll

 </Limit>

</Anonymous>

• Директива

<Anonymous>

chroot

/home/ftp

• Директивы

User

Group

• Директива

UserAlias

• В блоке, созданном с помощью директивы

<Limit WRITE>

DenyAll

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

anonymous

AnonRequiresPassword on

/etc/passwd

/etc/shadow

chroot

/etc/passwd

/etc/shadow

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

/etc/ftpusers

Ранее FTP-серверы представляли собой чрезвычайно важный компонент Internet, но в настоящее время некоторые их функции взяли на себя Web-серверы. Однако и сейчас FTP-серверы широко используются как средства для обеспечения удаленного доступа пользователей к своим файлам (в этом случае поддерживается двунаправленный обмен информацией) и поддержки анонимных обращений (при этом чаще всего осуществляется передача данных с сервера на клиентские машины). Наибольшей популярностью в Linux пользуются FTP-серверы WU-FTPD и ProFTPd. Обе программы предоставляют широкий набор возможностей и обслуживают как пользователей, регистрирующихся на сервере, так и анонимных пользователей. Настраиваются эти программы по-разному. Структура конфигурационных файлов ProFTPd напоминает структуру файлов Apache. При установке большинство серверов настраивается для регистрации пользователей. Незначительно изменив содержимое конфигурационных файлов, вы можете настроить их для работы в качестве анонимных FTP-серверов.