1.1. Оговорки

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

1.2. Местонахождение

Самая последняя версия этого документа может быть найдена на http://caliban.physics.utoronto.ca/neufeld/Domain.HOWTO/.

1.3. Copyright

Copyright (c) by Christopher Neufeld. This document may be distributed only subject to the terms and conditions set forth in the LDP License at this location.

1.4. Авторские права

Авторские права на русский перевод этого текста принадлежат © 2000 SWSoft Pte Ltd. Все права зарезервированы.

Этот документ является частью проекта Linux HOWTO.

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

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

Мы бы хотели распространить эту информацию по всем возможным каналам. Но при этом сохранить авторские права и быть уведомленными о всех планах распространения HOWTO. Если у вас возникли вопросы, пожалуйста, обратитесь к координатору проекта Linux HOWTO по электронной почте: <linux-howto@metalab.unc.edu>, или к координатору русского перевода Linux HOWTO компании SWSoft Pte Ltd. по адресу <linux-howto@asplinux.ru>

4.1. Выбор провайдера

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

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

4.2. Подготовка к установке оборудования

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

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

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

4.3. Проверка соединения

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

4.4. Использование динамических IP адресов

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

Сначала Вы, вероятно, захотите узнать законность этого. Многие компании запрещают устанавливать внешне-доступные серверы на персональных учетных записях. Они могут делать это фильтрованием пакетов, блокируя входящие соединения на порты HTTP и FTP. Также помните, что скорости соединения на персональных устройствах, типа домашнего DSL или кабельного модема могут довольно сильно отличаться. Скорость закачки обычно бывает много больше скорости отправки пакетов. Скорость отправки - это то, что наиболее важно для сервера FTP или WWW.

Если у Вас есть динамический IP-адрес, и Вы хотите иметь входящие соединения, Вы должны подписаться на услуги службы динамического хостинга, такие как DynIP, DynHOST, TZO, или fdns.net. Все они работают, используя программное обеспечение на Вашей машине, который отправляет текущий IP-адрес на сервер компании. Когда текущий IP-номер доходит до сервера компании, их DNS-таблица редактируется для сопоставления адреса с IP-адресом. Вы можете получить доменное имя под их доменным именем, например, "example.dynip.com" или ``example.dynhost.com'', или зарегистрировать Ваш собственный домен и установить первичный DNS для указания на компанию, предоставляющую данный сервис (обычно за более высокую цену).

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

Если Вы установили динамический IP-адрес и подписались на один из этих сервисов Вы должны будете несколько отступить от действий, описанных в главе Разд. 6. Если не планируется установка сервисов WWW или FTP, то, скорее всего, Вам не понадобятся услуги вышеперечисленных компаний. Если же необходимы их услуги, то нужно будет установить первичный DNS так, чтобы он указывал на сервер компании, услуги которой Вы выбрали. Не надо устанавливать демон named, отвечающий запросам из внешнего мира. Другие детали, такие как обработка электронной почты, будут зависеть от конкретной компании, о них Вам лучше всего ответят в ее службе технической поддержки.

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

6.1. Первичный сервер DNS

Когда пользователь в сети предпринимает попытку подсоединиться к машине из нового домена example.com, то между различными серверами в сети Интернет происходит обмен запросами, результатом которого является IP адрес требуемой машины, возвращаемый программе пользователя, предпринявшего эту попытку. Подробности этого обмена запросами выходят за рамки этого документа. Упрощенно это выглядит так: при обращении, к примеру, к машине fred.example.com, посылается запрос к централизованной базе данных для определения IP адреса машины, отвечающей за поддержку DNS для домена example.com (первичный DNS сервер). Затем машине по этому адресу посылается запрос на IP адрес машины fred.example.com.

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

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

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

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

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

6.2. Электронная почта

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

Плюсы и минусы использования сервера провайдера для работы со всей почтой:

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

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

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

• Для открытия нового почтового ящика приходится обращаться к провайдеру.

Плюсы и минусы своей собственной почтовой системы:

• Почта хранится на вашем собственном сервере. В случаях, когда ваш сервер не работает, или переполняется диск, почта остается на сервере провайдера.

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

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

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

Если вы решили обрабатывать почту на своем сервере, читайте раздел Разд. 7.3.

Если вы решили не обрабатывать почту своими силами, читайте Разд. 7.2.

6.3. Сервер WWW

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

Плюсы и минусы использования WWW сервера провайдера:

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

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

• Могут возникать трудности с установкой своих CGI скриптов и коммерческих пакетов на сервер.

• Скорость между сервером и вашей сетью, скорее всего, будет ниже, чем она была бы, если бы сервер стоял в вашей сети.

Плюсы и минусы установки сервера на одной из своих машин:

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

• Закрытые данные, такие как номера кредитных карт, адреса, остаются на контролируемой вами машине.

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

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

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

6.4. Сервер FTP

В общем случае, все что относится к серверу WWW, можно отнести и к серверу FTP, учитывая то, что содержимое FTP сервера неактивно и нет CGI скриптов. Большинство последних взломов ftpd базировались на переполнении буфера, в результате создания длинных имен каталогов на серверах с разрешенной для анонимных пользователей закачкой. Так что, если ваш провайдер позволяет производить закачку файлов на свой сервер и небрежно относится к обновлениям системы безопасности FTP демона, лучше установить свой FTP сервер.

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

Для wu-ftpd я рекомендовал бы следующие настройки:

• --disable-upload - если только вам не требуется закачка файлов анонимными пользователями.

• --enable-anononly - способствует использованию вашими локальными пользователями scp для передачи файлов между машинами.

• --enable-paranoid - выключить экспериментальные возможности текущей версии.

6.5. Фильтрование пакетов

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

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

Если вы решили установить фильтры пакетов в вашей сети, читайте Разд. 7.6.

7.1. Настройка разрешения имен

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

options {
        directory "/var/named";
	listen-on { 192.168.1.1 };
};

zone "." {
        type hint;
        file "root.hints";
};

zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};


zone "1.168.192.in-addr.arpa" {
        type master;
        file "pz/1.168.192";
};

zone "example.com" {
        type master;
        notify no;
        file "pz/example.com";
};

H.ROOT-SERVERS.NET.     6d15h26m24s IN A  128.63.2.53
C.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.33.4.12
G.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.112.36.4
F.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.5.5.241
B.ROOT-SERVERS.NET.     6d15h26m24s IN A  128.9.0.107
J.ROOT-SERVERS.NET.     6d15h26m24s IN A  198.41.0.10
K.ROOT-SERVERS.NET.     6d15h26m24s IN A  193.0.14.129
L.ROOT-SERVERS.NET.     6d15h26m24s IN A  198.32.64.12
M.ROOT-SERVERS.NET.     6d15h26m24s IN A  202.12.27.33
I.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.36.148.17
E.ROOT-SERVERS.NET.     6d15h26m24s IN A  192.203.230.10
D.ROOT-SERVERS.NET.     6d15h26m24s IN A  128.8.10.90
A.ROOT-SERVERS.NET.     6d15h26m24s IN A  198.41.0.4

$TTL 86400

@               IN      SOA     example.com. root.example.com. (
                                1       ; Serial
                                8H      ; Refresh
                                2H      ; Retry
                                1W      ; Expire
                                1D)     ; Minimum TTL
                        NS      dns.example.com.
1                       PTR     localhost.

$TTL 86400

@	IN	SOA		dns.example.com. root.dns.example.com. (
				1 	; Serial
				8H	; Refresh 8 hours
				2H	; Retry   2 hours
				1W	; Expire  1 week
				1D 	; Minimum 1 day
			)
		NS	dns.example.com.

1		PTR	fred.example.com.
		PTR	dns.example.com.
		PTR	mail.example.com.
2		PTR	barney.example.com.
3		PTR	wilma.example.com.

$TTL 86400

@		IN	SOA	example.com. root.dns.example.com. (
				1	; Serial
				8H	; Refresh 8 hours
				2H	; Retry   2 hours
				1W	; Expire  1 week
				1D	; Minimum 1 day
			)
			NS		dns.example.com.
	IN		A		192.168.1.1
	IN		MX	    10	mail.example.com.
	IN		MX	    20	<ISP mail machine IP>.


localhost		A	    127.0.0.1
fred			A	    192.168.1.1
			A	    10.1.1.9
dns			CNAME	    fred
mail			CNAME	    fred
barney			A	    192.168.1.2
wilma			A	    192.168.1.3
betty			A	    10.1.1.10
www			CNAME	    betty
ftp			CNAME	    betty

listen-on { 192.168.1.1 };

8.1.1.10.in-addr.arpa.     2H IN CNAME 8.8.1.1.10.in-addr.arpa.
9.1.1.10.in-addr.arpa.     2H IN CNAME 9.8.1.1.10.in-addr.arpa.
10.1.1.10.in-addr.arpa.    2H IN CNAME 10.8.1.1.10.in-addr.arpa.
и т.д.

options {
        directory "/var/named";
        listen-on { 10.1.1.9; };
};

zone "." {
        type hint;
        file "root.hints";
};

zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};


zone "8.1.1.10.in-addr.arpa" {
        type master;
        file "ext/8.1.1.10";
};

zone "example.com" {
        type master;
        notify no;
        file "ext/example.com";
};

$TTL 86400

@       IN      SOA             fred.example.com. root.fred.example.com. (
                                1               ; Serial
                                10800           ; Refresh       3 hours
                                3600            ; Retry         1 hour
                                3600000         ; Expire        1000 hours
                                86400 )         ; Minimum       24 hours
                NS      dns.example.com.
9       IN      PTR     fred.example.com.
		PTR	dns.example.com.
		PTR	mail.example.com.
10	IN	PTR	betty.example.com.
		PTR	www.example.com.
		PTR	ftp.example.com.

 $TTL 86400

@               IN      SOA     example.com. root.fred.example.com. (
                                10021   ; Serial
                                8H      ; Refresh 8 hours
                                2H      ; Retry   2 hours
                                1W      ; Expire  1 week
                                1D      ; Minimum 1 day
                        )
                        NS              fred.example.com.
        IN              A               10.1.1.9
        IN              MX          10  mail.example.com.
        IN              MX          20  <ISP Mail Machine>.


localhost               A           127.0.0.1
fred			A           10.1.1.9
betty			A	    10.1.1.10
dns			CNAME       fred
mail			CNAME	    fred
www                     CNAME       betty
ftp                     CNAME       betty

/usr/sbin/named -u dnsuser -g dnsgroup /etc/named.conf
/usr/sbin/named -u dnsuser -g dnsgroup /etc/named.ext.conf

search example.com
nameserver <DNS host 1>
nameserver <DNS host 2>

7.2. Конфигурация DNS, если Вы не используете транспорт электронной почты

Конфигурация, описанная в разделе Разд. 7.1, имеет МХ записи, указывающие на машину ``mail.example.com''. МХ запись, с наиболее низким приоритетом, указывает удаленным серверам, куда посылать электронные письма. Другие записи МХ, с более высоким приоритетом используются как резервные приемники электронных писем. Они будут держать электронные письма в течении некоторого времени, пока основной приемник писем не может их обработать по какой-либо причине. Для примера считаем, что под псевдонимом fred.example.com mail.example.com обрабатывает электронные письма домена. Если Вы хотите разрешить доступ ISP ко всем работающим у Вас адресам электронной почты, Вы должны изменить записи МХ таким образом, чтобы указать на соответствующие ISP-машины. Спросите в службе технической поддержки Вашего ISP о том, какие имена хостов можно использовать в МХ записях.

7.3. Настройка электронной почты

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

divert(-1)
#
# Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
# Copyright (c) 1983 Eric P. Allman.  All rights reserved.
# Copyright (c) 1988, 1993
#	The Regents of the University of California.  All rights reserved.
#
# Используя этот файл Вы соглашаетесь на все условия, перечисленные
# в файле с лицензией, который поставляется с дистрибутивом
# sendmail.
#
#

#
#  Ниже идет универсальный файл настройки домена. Он должен подходить
#  к вашей системе.  Если хотите перенастроить его, скопировать его в файл
#  для Вашего домена или сделать изменения, то скопируйте соответствующие
#  .mc файлы и измените `DOMAIN(generic)' чтобы сослаться на модифицированные
#  файлы.
#
divert(0)
define(`confFORWARD_PATH', `$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward')dnl
FEATURE(redirect)dnl
MASQUERADE_AS(example.com)dnl
FEATURE(masquerade_envelope)dnl

divert(-1)
#
# Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
# Copyright (c) 1983 Eric P. Allman.  All rights reserved.
# Copyright (c) 1988, 1993
#	The Regents of the University of California.  All rights reserved.
#
# Используя этот файл, Вы соглашаетесь на все условия, перечисленные
# в файле с лицензией, который поставляется с дистрибутивом
# sendmail.
#
#

#
#  Это прототип файла конфигурации, которая поддерживает только основной
#  протокол SMTP через TCP.
#
#  Вы должны изменить макрокоманду `OSTYPE' в зависимости от ОС, на
#  которой этот файл будет работать; в данном файле  Вы установите местоположение
#  различных файлов поддержки Вашей ОС. Вы можете создать файл домена в
#  ../domain и ссылаться на него, добавляя макрокоманду `DOMAIN' после
#  макрокоманды  `OSTYPE'.  Я рекомендую, скопировать данный файл
#  под другим именем, чтобы при обновлении версии sendmail Вам не приходилось
#  заново набирать его.
#

divert(0)dnl
OSTYPE(linux)dnl
DOMAIN(example.com)dnl
FEATURE(nouucp)
FEATURE(relay_entire_domain)
FEATURE(`virtusertable', `hash /etc/sendmail/virtusertable')dnl
FEATURE(`genericstable', `hash /etc/sendmail/genericstable')dnl
define(`confPRIVACY_FLAGS', ``noexpn,novrfy'')dnl
MAILER(local)
MAILER(smtp)
Cw fred.example.com
Cw example.com

divert(-1)
#
# Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
# Copyright (c) 1983 Eric P. Allman.  All rights reserved.
# Copyright (c) 1988, 1993
#	The Regents of the University of California.  All rights reserved.
#
# Используя этот файл, Вы соглашаетесь на все условия, перечисленные
# в файле с лицензией, который поставляется с дистрибутивом
# sendmail.
#
#

#
#  Это прототип для "пустого клиента" -- т.е. клиента, который не
#  делает ничего, кроме отправки всех писем в почтовый сервер. В таком
#  виде данный файл не пригоден для использования!!!
#
#  Для его использования Вы должны использовать свойство nullclient с
#  именем почтового сервера в качестве аргумента. Также определите
#  `OSTYPE', чтобы определить очередь каталогов и т.п.
#  Кроме того, выберете свойство nocanonify.  Это поможет
#  посылать адреса через SMTP соединение; обычно они посылаются с подменой имени,
#  которая по умолчанию производится сервером почты.
#
#  Данный файл не должен содержать никакие другие строки, кроме вышеперечисленных.
#

divert(0)dnl

OSTYPE(linux)
FEATURE(nullclient, fred.$m)
Cm example.com

make example.master.cf example.slave.cf

John.Public@example.com			jpublic
Jane.Doe@example.com			jdoe@somemachine.somedomain
abuse@example.com			root
Pointyhaired.Boss@example.com		#phb#@hotmail.com

jpublic                                 John.Public@example.com
janedoe                                 Jane.Doe@example.com
whgiii                                  Pointyhaired.Boss@example.com

all : genericstable.db virtusertable.db

virtusertable.db : virtusertable.src
	makemap hash virtusertable < virtusertable.src

genericstable.db : genericstable.src
	makemap hash genericstable < genericstable.src

7.4. Настройка сервера www

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

Подробности об установке самого сервера могут быть найдены в документации к apache и в документе Linux WWW HOWTO.

7.5. Настройка сервера FTP

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

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

Это обсуждается в разделе Разд. 8.1.

8.1. Конфигурирование Вашего брендмауэра

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

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

1. Инициализация карты Ethernet.

2. Брендмауэр выполняется через ipchains.

3. Пересылка включена.

4. Запускаются сетевые демоны.

Так, в качестве примера, возьмем систему Slackware, конфигурирование брендмауэра в ней происходит между rc.inet1 и rc.inet2. Далее, если возникнут любые проблемы во время конфигурации, предупреждение будет выведено на экран и Ethernet-карта отключится до загрузки сетевых демонов.

#! /bin/sh
#
# Этот скрипт использует цепочки IP. Создает фильтрацию с сетевым маскарадингом.
#

# Определим несколько переменных

IPCHAINS=/sbin/ipchains

LOCALNET="192.168.1.0/24"	# частная сеть
ETHINSIDE="192.168.1.1"		# fred.example.com's внутренний IP #
ETHOUTSIDE="10.1.1.9"		# fred.example.com's внешний IP #
LOOPBACK="127.0.0.1/8"
ANYWHERE="0/0"
OUTSIDEIF=eth1			# fred.example.com's внутренний интерфейс

FORWARD_PROCENTRY=/proc/sys/net/ipv4/ip_forward

#
# Эти две команды возвратят коды ошибок, возникающих в том случае,
# если права уже существуют (эта ситуация возникает, если Вы запустите
# скрипт больше чем один раз). Мы помещаем эти команды до "set -e"
# чтобы, в этом случае, скрипт не прервался.

$IPCHAINS -N outside
$IPCHAINS -N portmap

set -e			# Аварийное прекращение работы при возникновении
			# ошибки, связанной с установкой прав.


#
# Выключить форвардинг и очистить таблицы

echo "0" > ${FORWARD_PROCENTRY}

$IPCHAINS -F forward
$IPCHAINS -F input
$IPCHAINS -F output
$IPCHAINS -F outside
$IPCHAINS -F portmap


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

$IPCHAINS -A forward -s $LOCALNET -d $LOCALNET -j ACCEPT
$IPCHAINS -A forward -s $ETHOUTSIDE -d $ANYWHERE -j ACCEPT
$IPCHAINS -A forward -s $LOCALNET -d $ANYWHERE -j MASQ

#
# Установка флагов приритета. Минимальная задержка соединения для www, telnet,
# ftp, и ssh (только для исходящих пакетов).

$IPCHAINS -A output -p tcp -d $ANYWHERE www -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE telnet -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ftp -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ssh -t 0x01 0x10


#
# Что-нибудь из нашего локального класса С должно быть принято как
# loopback-пакеты и внешний IP.

$IPCHAINS -A input -s $LOCALNET -j ACCEPT
$IPCHAINS -A input -s $LOOPBACK -j ACCEPT
$IPCHAINS -A input -s $ETHOUTSIDE -j ACCEPT



# Создадим набор правил для пакетов, приходящих из внешнего мира
# и свяжем все внешние интерфейсы с этими правилами. Эти правила
# будут называться "внешние"
#
# Также создадим "portmap". Сокеты, используемые демонами,
# зарегистрированными с RPC portmapper не установлены и поэтому
# трудно установить правила для них. "Portmap"
# конфигурируется в отдельном скрипте.


#
# Это включает интерфейс $OUTSIDEIF и любые интерфейсы ррр, которые мы
# создадим для исходящих или входящих звонков.

$IPCHAINS -A input -i ${OUTSIDEIF} -j outside
$IPCHAINS -A input -i ppp+ -j outside


##################################################
#
#         Установка "внешних" правил             #
#
##################################################

#
# Никто из внешнего мира не может выдавать себя за внутреннего пользователя
#

$IPCHAINS -A outside -s $LOCALNET -j DENY
$IPCHAINS -A outside -s $LOOPBACK -j DENY

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

$IPCHAINS -A outside -d $LOCALNET -j DENY

#
# Блокируем входящие соединения на X порте. Блокируем порты от 6000 до 6010.

$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 6000:6010 -j DENY

#
# Блокируем NFS порты 111 и 2049

$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY

#
# Блокируем XDM пакеты из внешнего мира, порт 177 UDP

$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 177 -j DENY


#
# Блокируем YP/NIS порт 653

$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 653 -j DENY

#
# Не беспокоить регистрацией при доступе на TCP порт 80, это www порт.

$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 80 -j DENY

#
# Принятие данных FTP и контрольных соединений.

$IPCHAINS -A outside -p TCP -s $ANYWHERE 20:21 -d $ANYWHERE 1024: -j ACCEPT

#
# Принять ssh пакеты

$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE ssh -j ACCEPT

#
# Принять DNS пакеты из внешнего мира

$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT
$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT

#
# Принять SMTP из внешнего мира

$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 25 -j ACCEPT

#
# Принять NTP пакеты

$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 123 -j ACCEPT

#
# Не принимать никаких идентификационных пакетов, мы их не используем

$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 113 -j DENY

#
# Запретите и регистрируйте все другие приходящие пакеты, TCP или UDP, на специальные порты

$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE :1023 -y -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE :1023 -j DENY

#
# Проверьте установки прав относительно portmapper

$IPCHAINS -A outside -j portmap


##############################################
#
#     Конец установки "внешних" правил       #
#
##############################################


#
# Блокировать исходящие rwho пакты

$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 513 -d $ANYWHERE -j DENY

#
# Предотвратите отправку пакетов netbios

$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 137 -d $ANYWHERE -j DENY

#
# Включите пересылку

echo "1" > ${FORWARD_PROCENTRY}

#! /bin/sh
#
ANYWHERE=0/0

IPCHAINS=/sbin/ipchains

$IPCHAINS -F portmap

# Правила для предотвращения доступа к portmapped сервисам людям из внешней сети
#
/usr/bin/rpcinfo -p | tail +2 | \
	{ while read program vers proto port remainder
	  do
	  	prot=`echo $proto | tr "a-z" "A-Z"`
	  	$IPCHAINS -l -A portmap -p $prot -s $ANYWHERE -d $ANYWHERE $port -j DENY || exit 1
	  done
	} 

Эта конфигурация брендмауэра логирует наиболее подозрительные пакеты через klogd с регистрацией приоритета kern.info. Будут зарегистрированы нормальные попытки соединения так же, как и известные "хитрые" исследования сети.

#! /bin/sh
#
# Запускаем сеть, надежно
#
#
/etc/rc.d/rc.inet1		# Конфигурирование сетевых интерфейсов
				# и установка маршрутизации.
/sbin/firewall.sh || { echo "Ошибка конфигурации брендмауэра"
		       /sbin/ifconfig eth1 down }

/sbin/ipchains -I outside 1 -j DENY	# Запретить все входящие пакеты

/etc/rc.d/rc.inet2		# Запуск сетевых демонов

sleep 5				# Дадим возможность им стабилизироваться

# Безопасные сервисы portmap
/sbin/firewall.portmap.sh || { echo "Ошибка конфигурации portmap брендмауэра"
                               /sbin/ifconfig eth1 down }

/sbin/ipchains -D outside 1       # Разрешаем принимать входящие пакеты

8.2. Конфигурирование OpenSSH или SSH1

Во время написания этого раздела OpenSSH, подобно SSH1, дает возможность вставлять scp, ssh, и slogin как бинарные файлы, названные rcp, rsh, и rlogin, с переносом в ssh клиентских программах к исходным rsh, rcp, или rlogin, когда удаленная машина не выполняет sshd. Можно создать обращение rsh, вместо этого, по моему, важно сохранить безопасность при простоте использования для пользователей. Общие скрипты, rdist конфигурации, и т.п. могут работать без внесения каких-либо изменений в них если удаленная машина выполняет sshd, данные будут посылаться зашифрованными с довольно надежной аутентификацией. Если же удаленная сторона не поддерживает sshd, программа rsh выведет на экран предупреждение о том, что соединение незашифровано. Это сообщение останавливает работу rdist и, возможно, некоторых других программ. Его нельзя подавить параметрами при компиляции, или чем-то подобным. Единственное решение этой проблемы для rdist - это запускать программу с -p /usr/lib/rsh/rsh.

 ./configure --with-rsh=/usr/lib/rsh/rsh --program-transform-name='s/^s/r/' --prefix=/usr

ListenAddress 192.168.1.1	# внутренний IP шлюза
IgnoreRhosts no
X11Forwarding yes
X11DisplayOffset 10
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes

/usr/sbin/sshd

/usr/sbin/sshd -f /etc/sshd_config.ext

Затем, запретите внешнее использование telnet и shell в файле конфигурации inetd (обратите внимание, что настройка брендмауэра, перечисленная в разделе Разд. 8.1, уже обеспечит предотвращение доступа снаружи, но лучше обеспечить полную безопасность, не полагайтесь на то, что все будет работать без сбоев).

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

ssh-keygen -b 1024 -f new_rsa_key

Чтобы дать доступ через ключ RSA, необходимо создать каталог $HOME/.ssh/, для этого пользователя частной сети на шлюзе (т.е. на машине, которая будет принимать пользователя), и скопировать туда файл new_rsa_key.pub, который может быть создан командой "ssh-keygen" в файле $HOME/.ssh/authorized_keys. См. раздел ``ФОРМАТ ФАЙЛА AUTHORIZED_KEYS'' в man странице sshd для получения более подробной информации по другим опциям, которые Вы можете добавлять в ключ, например, запрос пароля при переходе с реального IP, или авторизацию ключом только при выполнении некоторых команд. В качестве примера, RSA ключ используется только при использовании команд резервного копирования, или отсылки сообщения о текущем состоянии за пределы системы.

exec "$startup"

exec ssh-agent "$startup"

ssh-add new_rsa_key

ssh-keygen -b 1024 -f /etc/ssh_host_key -N ""

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

Удобно для пользователей, если хосты частной сети упомянуты в файлах /etc/hosts.equiv. Демоны sshd будут позволять запускать rlogin и rsh без пароля и фразы прохода. При каждом соединении машины будут проверять ключи RSA друг друга на своем уровне.

Одна трудность возникает, когда пользователь, зарегистрированный в часной сети, хочет получить внешний IP-адрес. Вы можете использовать /etc/hosts.equiv или $HOME/.shosts, чтобы позволить проверку правильности пароля, т.к. пользователь входит с машины, IP адрес которой не может быть определенным, но ключи хостов не будут соответствовать. Есть два решения этой проблемы. Первое, если Вы хотите использовать методы /etc/hosts.equiv или $HOME/.shosts, пользователь должен будет регистрироваться на машине-шлюзе частной сети (fred.example.com в нашем примере), и затем переходить на требуемую машину оттуда. Другая методика заключается в использовании авторизации при помощи ключа RSA, что обеспечит независимость от игр с IP адресами и поисков имен хостов.

8.3. Конфигурирование X

xhost +

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

Установка sshd описана в секции Разд. 8.2, с установленным флагом ``X11Forwarding'', является фактически более простой в использовании альтернативной xhost. Как только Вы войдете в терминал, сможете просто выполнить rlogin для удаленной машины и запустить netscape, xv или что-нибудь другое, что Вам нравится, без установки переменной $DISPLAY или позволения явных разрешений. Во время входа в систему, автоматически будет настроен ssh абсолютно незаметно для пользователя, благодаря этому будет даже автоматическая зашифровка всех пакетов, перед их отправлением через сеть.

 /usr/X11/bin/xauth extract - $DISPLAY | rsh -l jpublic barney /usr/X11/bin/xauth merge -

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

Обратите внимание, что если rsh не шифруется ssh, xauth ключ передается в виде открытого текста. Любой, кто сможет перехватить ключ, сможет получить доступ к Вашему серверу, так что все усилия, направленные на безопасность системы, сводятся к нулу, если не используется ssh. Кроме того, если домашние каталоги экспортируются через NFS, то любому способному и любопытному человеку будут доступны все передающиеся через NFS пакеты, вне зависимости от того, используете Вы на Вашей системе ssh или нет.

8.4. Настройка совместного использования дисков

Работать с почтой, приходящей на центральную машину, и читать/посылать ее с любой машины несомненно удобно, но некоторое внимание необходимо уделить и безопасности. NFS без AUTH_DES несомненно опасен. NFS полагается на клиентскую машину, для авторизации доступа не требуется проверка пароля, пользователю необходимо разрешить доступ к его специфическим файлам. Windows-машины могут быть сконфигурированы читать экспортированные NFS разделы с любым uid, полностью обходя права на файл, установленные UNIX. Следовательно, доступ к NFS можно давать только тем машинам, котороые всегда работают только под Linux (или Unix) и никогда не могут быть загружены под Windows. Чтобы экспортировать домашний каталог в Windows, используйте samba, установив режим аудентификации ``security=USER''. Соединение машин в вашей сети с использованием хаба тоже поможет, т.к. при этом теряется всякий смысл использования снифферов на Windows-машинах. В конечном счете, невозможно гарантировать совместное использование диска в сети.

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