Партнёры:
Хостинг:
neufeld@physics.utoronto.ca
neufeld@caliban.physics.utoronto.ca
версия 0.10. 2000-02-29.
Это предварительный документ. Я вскользь коснулся многих вещей, требующих гораздо более детального рассмотрения и, вероятно, пропустил некоторые важные разделы. Любые предложения по добавлению, удалению или изменению разделов приветствуются.
Самая последняя версия этого документа может быть найдена на http://caliban.physics.utoronto.ca/neufeld/Domain.HOWTO/.
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.
Авторские права на русский перевод этого текста принадлежат © 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>
Это руководство по настройке вашего собственного домена, состоящего из машин под управлением Linux или Windows, при наличии постоянного соединения, статического IP адреса и поименованного домена. Оно не предназначено для динамически выделяемых IP адресов или сетей, регулярно отсоединяющихся от своего провайдера на долгое время, хотя в разделе Разд. 4.4 есть несколько подсказок и на эту тему.
С увеличением доступности постоянных подключений и статических IP адресов людям и организациям, становится проще настраивать реальные домены сети Интернет изначально. Правильное планирование может избавить от многих проблем в дальнейшем.
Значительная часть этого документа посвещена технике создания системы безопасности в новой сети. Она включает в себя защиту от атак извне и от случайных атак изнутри. Документ не претендует на описание полностью защищенной системы, однако того, что есть, как правило, достаточно для защиты от менее решительных хакеров.
Это документ предназначен в основном для небольших организаций, имеющих сеть компьютеров и, возможно, dialup соединение с Интернет, и планирующих перейти на относительно высокоскоростное постоянное соединение, для повышения скорости передачи данных по сети или создания собственного WWW или FTP сайта. Также этот документ может быть полезен молодым организациям, планирующим сразу начать с высокоскоростной сети под своим собственным доменом.
Я описываю настройку свежезарегистрированного домена example.com. Этот домен зарегестрирован Internet Assigned Numbers Authority для использования в этом документе, и поэтому никогда не будет совпадать с реально используемым доменом.
Большую часть информации, представленной здесь, можно найти и в других местах. Я попытался отфильтровать материал, относящийся к созданию нового домена. Если материала на какую-либо узкоспециализированную тему недостаточно, обратитесь к другим, более исчерпывающим источникам.
Предполагается использование различных OS. В частности, я буду считать, что рабочие станции работают под управлением одной из версий Microsoft Windows, а сервера и шлюз частной сети работают под Linux.
Для различных форматов сети могут быть приведены свои аргументы за и против. Однако запросы большинства организаций могут быть удовлетворены установкой рабочих станций и серверов для внутреннего пользования в частную замаскированную подсеть, а серверов общего пользования - на корректные внешние IP адреса. Машины на корректных внешних IP адресах в этом документе будут называться "незащищенными хостами". Все вышесказанное приводит к следующей топологии (пример):
+--------------+
| | +---------------+
| Шлюз |---------------| Сервер FTP |
| ISP | | +---------------+
| | |
+--------------+ | +---------------+
|------| Сервер WWW #1 |
| +---------------+
|
| +---------------+
|------| Сервер WWW #2 |
| +---------------+
|
~
~
|
| +---------------+
|------| Шлюз в |
| частную |
| сеть |
+---------------+
|
|
|
|
+--------------------+ | +----------------------+
| Рабочая станция #1 |-----------|-------------| Внутренний сервер #1 |
+--------------------+ | +----------------------+
|
. -----------|------------- .
. | .
. -----------|------------- .
|
+--------------------+ | +----------------------+
| Рабочая станция #N |-----------|-------------| Внутренний сервер #N |
+--------------------+ +----------------------+
В этом примере шлюз ISP (Internet Service Provider (поставщик услуг Интернет)), сервер FTP, сервера WWW и "шлюз в частную сеть" имеют видимые снаружи IP адреса, а рабочие станции и внутренние сервера - IP адреса, выделенные в соответствие с RFC 1918 (зарезервированные для использования во внутренних сетях). IP адреса в вашей внутренней подсети (все, что ниже шлюза в частную сеть) должны быть уникальными не только для вашей подсети, но и для подобных подсетей ваших партнеров, с которыми вы, возможно, планируете в будущем организовать виртуальную частную сеть (virtual private network). Этому правилу стоит следовать во избежание путаницы и необходимости перенастройки сети в будущем. В соответствие с RFC, вы можете выбрать любую подсеть класса C из диапазона 192.168.0.* - 192.168.255.*, или любую подсеть класса B из 172.16.*.* - 172.31.*.*, или подсеть класса A 10.*.*.*. В этом документе я буду считать, что ваша частная сеть (если вы решили создать таковую) основана на подсети класса C 192.168.1.*, шлюз в частную сеть имеет IP адрес 10.1.1.9 - один из адресов, выделенных вам вашим провайдером (примечание: этот адрес не является корректным внешним IP адресом и используется мной лишь в качестве примера). Кроме того, я буду считать, что имеется машина betty.example.com с адресом 10.1.1.10, обслуживающая WWW и FTP запросы.
Подсчитайте количество внешних IP адресов, необходимых для ваших машин. Оно должно быть равно количеству машин вне частной сети плюс один IP адрес для шлюза в частную сеть. В это число не входят IP адреса, используемые маршрутизаторами, широковещательные IP адреса и т. п. Попросите своего провайдера выделить вам диапазон IP адресов, достаточно большой для включения в него этого числа машин. Например, в сети моего офиса из 8 IP адресов, выделенных провайдером, три не могли быть использованы моими компьютерами, что оставляло четыре IP адреса для работы вне частной сети плюс один IP адрес для шлюза.
Хотя эта топология сети подходит не для всех, она является разумной отправной точкой для многих конфигураций, не требующих решения специфических задач. Преимущества этой конфигурации:
Масштабируемость. Если вам внезапно понадобится увеличить вдвое количество рабочих станций, то не придется беспокоиться о получении нового диапазона IP адресов от провайдера и о перенастройке сетевых интерфейсов ваших машин.
Управление локальной сетью. Добавление рабочей станции в вашу частную сеть не требует общения с вашим провайдером, в отличие от незащищенных хостов, требующих, в случае предоставления ими специфических услуг, коррекции прямых и обратных записей DNS (domain name service (служба имен доменов)) - например ssh и ftpd могут "жаловаться" на отсутствие корректных DNS записей. Обратная DNS запись - это запись, описывающая имя хоста по его IP адресу.
Централизованная система безопасности. Шлюз частной сети может фильтровать пакеты и вести журнал внешних атак, принудительно обеспечивая общую систему безопасности для всей внутренней (частной) сети. В этом случае нет необходимости настраивать систему безопасности отдельно на каждой рабочей станции и сервере внутренней сети. Кроме того, фильтры могут выставляться не только на входящие, но и на исходящие пакеты, так что неправильно настроенная рабочая станция не сможет неумышленно передавать во внешний мир не предназначенные для этого данные.
Переносимость. Так как IP адреса, используемые во внутренней сети, останутся вашими до тех пор, пока вы этого хотите, то в случае перехода всей сети на новый диапазон IP адресов (например, при смене провайдера) вам не придется менять конфигурацию внутренней сети. Незащищенные хосты, в этом случае, естественно, нуждаются в перенастройке.
Прозрачный доступ в Интернет. Машины из внутренней сети по-прежнему могут использовать FTP, telnet, WWW и другие услуги, с небольшими ограничениями. Пользователи могут даже не задумываться о том, имеется ли у их машин видимый снаружи адрес IP.
Некоторые из потенциальных недостатков этой конфигурации:
Некоторые услуги не будут доступны напрямую для машин из внутренней сети. Например, синхронизация по NTP с внешним хостом; некоторые услуги, предоставляемые серверами, не имеющими поддержки маскирования в ядре; .shosts аутентификация внешними узлами для ведения журнала весьма затруднительны или невозможны. Однако почти всегда можно найти простые обходные пути.
Более высокая стоимость сетевого оборудавания. Для шлюза внутренней сети необходимы две сетевые карты. Также требуется, как минимум, два хаба/коммутатора, один для внутренней сети, другой - для видимой снаружи.
Машины, находящиеся вне внутренней сети, не могут напрямую подсоединяться к машинам, находящимся во внутренней сети. Это можно сделать, зайдя сперва на шлюз внутренней сети, а затем уже с него на машину внутренней сети. Хотя можно пропускать через firewall все пакеты в обе стороны, но не рекомендуется делать этого по соображениям безопасности (см. ниже).
Вы должны взвесить все "за" и "против" и решить, не является ли полностью видимая извне сеть более подходящим решением в вашем случае. Далее в документе я буду предполагать, что ваша сеть построена так, как указано выше. Если вы предпочли полностью видимую снаружи сеть, то некоторые детали будут отличаться. Я попытаюсь указать на эти отличия.
В особом случае, если вам не требуются внешние сервера, то шлюз провайдера может быть подключен непосредственно к внешнему интерфейсу шлюза внутренней сети, а не к хабу.
Выясните, какие услуги и в какую цену предоставляются в вашем регионе. Не везде можно подключить DSL, не везде можно установить беспроводную связь из-за особенностей строений, земной поверхности или окружающей среды. Будьте готовы предоставить свой адрес, так как скорость DSL сильно зависит от расстояния, оговорите скорость соединения со своим провайдером, узнайте какое для этого требуется оборудование. Неплохо бы определить количество необходимых вам IP адресов (помните о том, что, как правило, не все IP адреса из выделенного вам диапазона можно будет назначить вашим компьютерам). Спросите провайдера о скорости соединения между ним и остальным миром, так как оговориваемая скорость - это скорость между ним и вами. Если скорость соединения провайдера с остальным миром недостаточна, то вы будете страдать из-за появления "узкого места" в сети провайдера.
После того, как вы определились со списком кандидатов, поспрашивайте знакомых, кого они порекомендуют. Спросите, какую скорость они получают при работе с некэшированными сайтами. Если вам требуется быстрое соединение между вашим домом и новым доменом для работы или удаленного администрирования, то обязательно запустите traceroute из вашего дома до хоста провайдера. Это позволит вам узнать, сколько хостов между вами и новым доменом, а также ожидаемое время задержки. Если задержка превышает 100 - 200 миллисекунд, то вам довольно сложно будет работать из дома длительное время. traceroute должен быть запущен во время, планируемое для работы.
После того, как вы выбрали провайдера, а также услуги для вашего нового домена, уточните детали, касающиеся установки оборудования. Возможно, вам понадобится связаться с телефонной компанией и с техническим отделом провайдера. Техникам, как правило, требуется доступ к различным участкам вашего здания, поэтому проинформируйте об этом ответственного за техническое состояние здания.
До приезда технического персонала провайдера уточните параметры сети, в частности IP адрес, маску подсети, широковещательный адрес, адрес шлюза, адрес сервера DNS, а также тип кабеля, требуемый для подключения оборудования провайдера (т.е. прямой или кросс RJ45 кабель и т.п.).
Выделите одну машину для тестирования, расположив ее как можно ближе к планируемому месту подключения. Если есть такая возможность, то установите до приезда технического персонала IP адрес, маску подсети, подготовьте кабель. Все это поможет быстро установить и проверить соединение.
С помощью тестовой машины убедитесь в наличии нормального отправления пакетов (ping) до сайтов вне сети вашего провайдера. При отсутствии оного, попробуйте воспользоваться traceroute для выяснения места проблемы. Если при этом не выводится ни одного перехода (hop), то проблема в настройке тестовой машины (маршрут по умолчанию, адрес интерфейса, сетевые драйвера, DNS и т.п.). Если показывается один переход, то это может означать, что неправильно настроен ваш шлюз. Если перед сбоем выводятся несколько переходов, то проблема или у провайдера, или где-то еще - вряд ли вы сможете что-то сделать прямо сейчас.
Выгода от подключения нескольких человек через статические 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, подсоединитесь по этому адресу. Это практически то же самое, что делают платные службы, просто автоматизируют и упрощают некоторые шаги.
Для того, чтобы люди со всего мира могли найти сервера (www, ftp или почтовые) вашего домена, вам необходимо зарегистрировать его для внесения в соответствующую базу данных доменов верхнего уровня.
Будьте благоразумны при выборе имени домена. Некоторые слова и выражения могут быть запрещены но основании стандартов сообщества, некоторые - неприятны посетителям, чей язык или слэнг отличается от вашего. Имена доменов могут содержать только 26 букв латинского алфавита (без ударений), дефис (только не в начале и не в конце имени) и 10 цифр. Регистр не имеет значения, длина не должна превышать 26 символов (рассматривается вопрос о снятии этого ограничения). Постарайтесь не зарегистрировать имя, хоть как-то пересекающееся с торговыми марками, существующих компаний - суды не очень-то жалуют киберскваттеров. Кое-какую информацию об обстоятельствах, при которых ваш неосторожно выбранный домен может быть отобран у вас, можно найти по адресу: Uniform Domain Name Dispute Resolution Policy.
Многие компании регистрируют свои имена под доменами верхнего уровня ".com", ".net", and ".org". Текущий список - list of accredited registrars.
Чтобы зарегистрировать имя под доменом верхнего уровня страны, например ".ca, ".de", ".uk", ".ru" и т.д. обратитесь в соответствующую организацию, занимающуюся этим. Список можно найти по адресу: Country Code Top-Level Domains database.
Обычно вам необходимо предоставить регистрирующей организации информацию о том, как с вами связаться, IP адреса первичного и вторичного серверов DNS, согласовать схему подтверждения запроса на изменение информации о домене (вы же не хотите, чтобы любой желающий мог поменять ее), а также внести ежегодную плату. Если вас не устраивает схема подтверждения, используемая регистрирующей организацией, дайте ей об этом знать.
Большинство провайдеров предоставляют ряд услуг по поддержке доменов своих клиентов. В основном это связано с тем, что поддерживать домен под рядом популярных операционных систем для персональных компьютеров весьма проблематично. Реализовать поддержку этих услуг под Linux намного проще, причем на довольно дешевом оборудовании, поэтому решите, что вы будете поддерживать, сами. Вот список некоторых из этих услуг:
Первичный DNS сервер для вашего домена. См. раздел Разд. 6.1.
Электронная почта. См раздел Разд. 6.2.
WWW сервер. См. раздел Разд. 6.3.
FTP сервер. См. раздел Разд. 6.4.
Фильтрование пакетов. См. раздел Разд. 6.5.
Для каждой из перечиселенных услуг вам придется выбирать между удобством и возможностью управления. Если поддержкой одной или нескольких услуг занимается провайдер, то, как правило, вы можете быть уверены, что этим занимаются специалисты в этой области, а значит незачем беспокоиться и забивать себе голову лишними знаниями. С другой стороны, вы теряете контроль за этими услугами - для внесения любых изменений придется связываться с технической службой провайдера, что не всегда удобно, кроме того, задержка по времени может быть больше, чем вам хотелось бы. Нельзя также отбрасывать фактор безопасности - провайдеры, как правило, более заманчивая цель для хакеров, нежели ваш собственный сайт, так как сервера провайдеров содержат почту и/или странички десятков компаний-клиентов. Соответственно, хакер, взломавший такой сервер, получает в результате гораздо больше, чем при взломе одного из ваших собственных серверов, на котором лежат данные всего лишь одной компании.
Когда пользователь в сети предпринимает попытку подсоединиться к машине из нового домена 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 сервера вашему провайдеру.
Обычно провайдеры предоставляют клиентам почтовые ящики. Вы можете либо воспользоваться этой услугой (при этом пользователи будут просто забирать свою почту с сервера провайдера с помощью POP3 клиентов), либо обрабатывать почту на своей машине. Опять таки, вам придется выбирать из двух зол меньшее.
Плюсы и минусы использования сервера провайдера для работы со всей почтой:
Доступ к почте из дома или из других мест (во время деловой поездки, к примеру) может быть проще, впрочем, это зависит от системы безопасности, выбранной вами для защиты своего домена.
Почта хранится на сервере провайдера, что может превратиться в проблему, в случае посылки данных, предназначенных для внутреннего использования в незашифрованном виде.
Количество почтовых ящиков ограничено, за открытие дополнительных, как правило, приходится платить.
Для открытия нового почтового ящика приходится обращаться к провайдеру.
Плюсы и минусы своей собственной почтовой системы:
Почта хранится на вашем собственном сервере. В случаях, когда ваш сервер не работает, или переполняется диск, почта остается на сервере провайдера.
Количество почтовых ящиков неограничено. Вы можете сами создавать и удалять их.
Вам придется поддерживать работу с почтовыми клиентами в вашей частной сети и, возможно, работу с людьми, посылающими почту из дома.
Одно из возможных решений - поддерживать почту своими силами и, одновременно, иметь несколько ящиков на сервере провайдера для тех, кому нужен доступ к своей почте извне вашей частной сети. Это немного усложняет настройку и координирование почтовой системы, но зато дает гибкость, недоступную ни одному из вышеприведенных вариантов.
Если вы решили обрабатывать почту на своем сервере, читайте раздел Разд. 7.3.
Если вы решили не обрабатывать почту своими силами, читайте Разд. 7.2.
Ваш провайдер может предоставить вам дисковое пространство на одном из своих WWW серверов. Вы можете выбрать этот вариант, или установить WWW сервер на одну из видимых извне машин, имеющую IP адрес из диапазона, выделенного вам провайдером.
Плюсы и минусы использования WWW сервера провайдера:
Дисковое пространство, выделяемое вам провайдером под файлы WWW сервера, ограничено. В него входит не только содержимое страничек, но и данные, собираемые от посетителей сайта.
Скорость между сервером и остальным миром, почти наверняка, будет выше, чем она была бы, если бы сервер стоял на одной из ваших машин. По крайне мере, она не будет ниже.
Могут возникать трудности с установкой своих CGI скриптов и коммерческих пакетов на сервер.
Скорость между сервером и вашей сетью, скорее всего, будет ниже, чем она была бы, если бы сервер стоял в вашей сети.
Плюсы и минусы установки сервера на одной из своих машин:
Вы лучше контролируете сервер. Вы можете более тщательно настроить систему безопасности для ваших приложений.
Закрытые данные, такие как номера кредитных карт, адреса, остаются на контролируемой вами машине.
Ваша стратегия резервного копирования, по сравнению с со стратегией вашего провайдера, вероятно, не столь тщательно продумана.
Заметьте, что я не отношу к плюсам то, что провайдер имеет более мощное оборудование, у него выше пиковая скорость передачи данных и т.д. К тому времени, когда эти параметры начнут иметь значение, будут иметься в виду очень высокие скорости, и, откровенно говоря, лучше будет обратиться за консультацией к квалифицированному специалисту, а не к Linux HOWTO.
Если вы решили установить WWW сервер на своей машине, то смотрите другие документы, такие как WWW-HOWTO. Я настоятельно рекомендую, из соображений безопасности, устанавливать WWW сервер на отдельной машине, а ни в коем случае не на шлюзе сети.
В общем случае, все что относится к серверу WWW, можно отнести и к серверу FTP, учитывая то, что содержимое FTP сервера неактивно и нет CGI скриптов. Большинство последних взломов ftpd базировались на переполнении буфера, в результате создания длинных имен каталогов на серверах с разрешенной для анонимных пользователей закачкой. Так что, если ваш провайдер позволяет производить закачку файлов на свой сервер и небрежно относится к обновлениям системы безопасности FTP демона, лучше установить свой FTP сервер.
Если вы решили установить FTP сервер на свою машину, то обязательно скачайте последнюю версию FTP демона и прочитайте документацию, поставляемую с ней. Еще раз настоятельно рекомендую установить, из соображений безопасности, FTP сервер на отдельную машину, по крайней мере, не на шлюз внутренней сети.
Для wu-ftpd я рекомендовал бы следующие настройки:
--disable-upload - если только вам не требуется закачка файлов анонимными пользователями.
--enable-anononly - способствует использованию вашими локальными пользователями scp для передачи файлов между машинами.
--enable-paranoid - выключить экспериментальные возможности текущей версии.
Некоторые провайдеры устанавливают фильтрацию пакетов в своих сетях для защиты пользователей друг от друга и от внешних хакеров. В сетях на кабельных модемах и других подобных широковещательных сетях возникала следующая проблема: пользователи Windows 95 или 98 неумышленно предоставляли полный доступ к своим дискам любому желающему, поэтому была возможность просмотреть список активных серверов в сегменте сети. Иногда решением этой проблемы являлась просьба не делать этого, иногда же провайдеры устанавливали фильтры пакетов, что позволяло избежать последствий неумышленного предоставления доступа к своим данным.
Фильтрование пакетов - это то, что вам придется сделать самим. Оно легко встраивается в ядро шлюза внутренней сети и помогает вам лучше понять, что, собственно говоря, происходит в сети. Скорее всего, вы обнаружите, что нужно немного поднастроить firewall для оптимизации его работы, и что это проще сделать самому, нежели обращаться к службе технической поддержки.
Если вы решили установить фильтры пакетов в вашей сети, читайте Разд. 7.6.
Вам необходимо будет выбрать способ обращения компьютеров в сети друг к другу по имени, а также способ обращения людей со всего мира к вашим незащищенным хостам по имени. Для этого существует несколько путей.
« Примечание: если вы решили не создавать внутреннюю (частную) сеть, то переходите к разделу Разд. 7.1.4. »
В этом случае, первичный DNS сервер для вашего домена поддерживается провайдером. Тем не менее, вы используете DNS в вашей внутренней сети при общении компьютеров в ней между собой. Имена незащищенных хостов и их IP адреса передаются провайдеру. Если вы хотите, к примеру, чтобы хост betty.example.com был WWW и FTP сервером, то вам нужно попросить провайдера проставить записи CNAME для www.example.com и ftp.example.com, указывающие на betty.example.com.
Настройте DNS на шлюзе в вашу внутренню сеть. Это нормально, с точки зрения безопасности, кроме того, упрощает перенастройку, если вы решите в дальнейшем перенести первичный DNS сервер на одну из своих машин.
Я предполагаю, что машина, на которой установлен сервер имен, имеет имя dns.example.com, является шлюзом во внутреннюю сеть, псевдонимом для fred.example.com и ее IP адрес 192.168.1.1. Если в вашем случае это не так, то нужно просто внести небольшие изменения в конфигурацию. Я не буду рассматривать их в этом HOWTO, за исключением особо интересных случаев.
Вам нужно будет скачать и скомпилировать последнюю версию BIND, the Berkeley Internet Name Domain. Ее можно найти на сайте BIND. Далее нужно настроить демон. Создайте файл /etc/named.conf со следующим содержимым:
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";
};
Обратите внимание, что мы объявляем себя администратором (master) домена example.com. Между тем, наш провайдер также объявляет себя администратором для того же домена. Проблем не возникнет, если быть внимательным с настройкой. Все машины из внутренней сети должны для разрешения имен обращаться к dns.example.com. Они не должны обращаться к серверу провайдера, так как он считает себя администратором всего домена, но не знает IP адресов или имен машин из вашей внутренней сети. Аналогично, незащищенные хосты должны обращаться к серверу провайдера, а не к внутреннему серверу dns.example.com.
Теперь нужно создать различные файлы в подкаталоге /var/named.
Файл root.hints в точности соответствует описанному в документации по BIND и DNS HOWTO. К моменту создания этого документа следующие записи файла root.hints соответствовали действительности:
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
Файл pz/127.0.0 выглядит так:
$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.
Файл pz/1.168.192 выглядит так:
$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.и так далее, по одной PTR записи на каждую машину из внутренней сети. В этом примере fred.example.com имеет IP адрес 192.168.1.1, и на него указывают псевдонимы dns.example.com и mail.example.com. Машина barney.example.com имеет IP адрес 192.168.1.2 и так далее.
Файл pz/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Заметьте, что мы создаем записи как для машин из внутренней сети, так и для машин извне, так как машины из внутренней сети не будут обращаться к серверу имен провайдера для запроса, к примеру, IP адреса машины betty.example.com. Для машины fred мы указываем оба IP адреса, внешний и внутренний.
Одна строка из раздела "options" файла /etc/named.conf требует комментария:
listen-on { 192.168.1.1 };
Она указывает вашему серверу имен не отвечать на DNS запросы из внешнего мира (все такие запросы должны обслуживаться сервером провайдера, а не вашим).« Примечание: если вы решили не создавать внутреннюю сеть, то переходите к разделу Разд. 7.1.4. »
Если вы решили использовать эту конфигурацию, значит вы решили, что ваша внутренняя сеть довольно мала и не будет часто меняться. Вы решили не использовать централизованную базу данных DNS сервера, а вместо этого поддерживать разрешение имен отдельно для каждой машины. Все машины должны обращаться к DNS серверу провайдера для разрешения имен машин за пределами внутренней сети. Для разрешения имен внутренней сети, необходимо создать таблицу хостов. Для Linux это означает внесение имен и IP адресов в файл /etc/hosts на каждой машине. Каждый раз при смене IP адреса или добавлении новой машины в сеть, этот файл должен быть обновлен на каждой машине.
Как и в разделе Разд. 7.1.1, списки имен хостов и IP адреса внешних хостов, а также все псевдонимы (такие как имена для ftp и www серверов) должны быть переданы провайдеру.
Я не буду рассматривать случай использования named для разрешения имен назащищенных хостов и отдельной, для каждой машины во внутренней сети базы хотя это можно реализовать. Если вы собираетесь использовать named для внешней или для внутренней сети, то почему бы не сделать это для обеих, хотя бы для упрощения конфигурации. В этом разделе я буду предполагать, что шлюз внутренней сети занимется разрешением имен и для внешней и для внутренней сети.
Нам требуется по-разному реагировать в зависимости от того, пришел ли запрос извне (в этом случае, мы не должны посылать IP адреса машин внутренней сети), или из внутренней сети. Ко времени написания этого документа существовал пакет BIND версии 8.2.2, используя который это поведение можно было релизовать, лишь запуская два демона named с различной конфигурацией. Впрочем, ведется активное обсуждение введения нового ключего слова "views", которое, возможно, будет добавлено для этой цели в BIND. Пока же придется довольствоваться предложенным решением.
В первую очередь, настройте сервер имен для внутренней сети, как описано в разделе Разд. 7.1.1.
Далее нужно настроить DNS для домена так, как он будет виден для остального мира. Свяжитесь с вашим провайдером и выясните делегирует ли он вам обработку запросов на реверсный поиск имен (reverse lookup). Хотя изначально DNS стандарт не рассматривал возможность обслуживания реверсных запросов на подсетях меньших, чем сети класса C, позже был разработан обходной путь, работающий со всеми, соответствующими стандарту, DNS клиентами, и закрепленный в RFC 2317. Если ваш провайдер собирается делегировать вам контроль за реверсным DNS вашего диапазона IP адресов, то вам необходимо будет выяснить точное имя in-addr псевдо-домена, выбранного ими для делегирования (RFC не дает соглашений для повседневнего использования). Я буду считать, что провайдер делегировал вам контроль, и имя псевдо-домена - 8.1.1.10.in-addr.arpa. Провайдер должен будет внести записи подобные
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. и т.д.в свой файл зоны для домена 1.1.10.in-addr.arpa. Конфигурация вашего файла зоны 8.1.1.10.in-addr.arpa будет дана в этом разделе ниже.
Если провайдер собирается делегировать вам контроль за реверсным DNS, то он проставит CNAME записи в свою таблицу реверсной DNS зоны, указывающие на соответствующие записи в вашем псевдо-домене, как показано выше. Если он не собирается делегировать вам контроль, то вам придется просить его обновлять записи реверсной зоны каджый раз, когда вы будете добавлять, удалять или менять имя видимой изне машины вашего домена. Если данные реверсной DNS таблицы не соответствует данным прямой, то определенные услуги могут выдавать предупреждения или отказываться работать с машинами, для которых имеет место несоответствие.
Теперь создайте конфигурацию для второго named, который будет отвечать на запросы машин вне внутренней сети. Нужно перечислить только те хосты и IP адреса, которые видны снаружи. Ответы будут посылаться только на запросы, приходящие на внешний интерфейс шлюза.
Сперва создайте второй файл конфигурации, например /etc/named.ext.conf. В нашем случае он будет таким:
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";
};
Файлы root.hints и pz/127.0.0 , оба из каталога /var/named используются обеими демонами. Файл ext/8.1.1.10 выглядит так:
$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.
Файл ext/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Я предположил, что вы создали пользователя с ограниченными правами "dnsuser" и соответствующую группу"dnsgroup". Если в bind обнаружится ошибка, позволяющая хакеру запустить из named свой код, то он обнаружит, что может делать лишь то, что может непривелигированный пользователь. Каталог /var/named и файлы в нем должны быть недоступны для записи пользователем "dnsuser.
Машины во внутренней сети должны быть настроены на работу с dns.example.com (в нашем примере имеющем IP адрес IP 192.168.1.1), в то время, как видимые извне машины могут посылать запросы как на внешний интерфейс шлюза внутренней сети (в нашем примере IP адрес 10.1.1.9), так и на DNS сервер провайдера.
В этой конфигурации все хосты видимы снаружи. Каждая машина домена имеет реальный IP адрес. Вы предоставляете провайдеру список IP адресов машин и их имена. Провайдер дает вам адрес, как минимум, одного своего DNS сервера. Настройка разрешения имен в Linux производится в файле /etc/resolv.conf:
search example.com nameserver <DNS host 1> nameserver <DNS host 2>
Машины, работающие под Windows, настраиваются подобным же образом через диалоги настройки сети.
Если по какой-либо причине (например, смена провайдера) вы решили перенести ваш домен на новый IP адрес, то перед переносом необходимо подготовиться к нему.
Вам, наверное, хотелось бы, чтобы можно было после смены IP мгновенно перенастроить DNS со старых адресов на новые. Увы. Удаленные системы кэшируют ваши IP адреса, поэтому на последующие запросы будут возвращать ваши старые адреса, вместо того, чтобы запрашивать соответствующие сервера. В результате те, кто работал с вашим сайтом в момент смены IP адрсесов не смогут подсоединиться, хотя новые посетители будут нормально работать, так как только они получат правильные некэшированные данные. Кроме того, базовые сервера обновляются всего лишь два раза в сутки, поэтому сложно определить точное время, в которое они обновят ссылки на ваши первичный и вторичный сервер DNS.
Самый простой способ перейти на новые IP адреса - скопировать ваш сайт, по крайней мере его видимую часть, на новые IP адреса, а затем подождать, пока траффик не сместится туда полностью. Хотя этот способ не очень практичен.
Первое, что нужно сделать - договориться с вашим новым провайдером (или с вашим нынешним, если вы просто меняете IP адрес), чтобы он обновил ссылки на ваши первичный и вторичный сервер DNS. Это должно быть сделано, хотя бы за день до перемещения. Попросите его установить время жизни (TTL) на эту запись очень маленькое (минут 5, обычно это значение установлено 86400 сек. (1 день)).
По прошествии дня, присвойте вашей машине новый IP адрес. Синхронизируйте это с записями DNS у вашего провайдера. И верните TTL на прежнее значение.
Новый первичный и DNS серверы должны быть направлены на настоящий IP арес вашего сайта, с маленьким TTL.
Теперь, вы готовы к перемещению. Переместите машины на новые IP адреса Совместите это с обновлением записей DNS у провайдера. Через 5 минут (если установлен маленький TTL, до перемещения), траффик должен быть переключен на новый сайт. Теперь вы можете перестроить полномочия DNS на ваш вкус, создав первичный сервер, если вы этого хотите, и восстанавив обратно TTL на большое значение.
Конфигурация, описанная в разделе Разд. 7.1, имеет МХ записи, указывающие на машину ``mail.example.com''. МХ запись, с наиболее низким приоритетом, указывает удаленным серверам, куда посылать электронные письма. Другие записи МХ, с более высоким приоритетом используются как резервные приемники электронных писем. Они будут держать электронные письма в течении некоторого времени, пока основной приемник писем не может их обработать по какой-либо причине. Для примера считаем, что под псевдонимом fred.example.com mail.example.com обрабатывает электронные письма домена. Если Вы хотите разрешить доступ ISP ко всем работающим у Вас адресам электронной почты, Вы должны изменить записи МХ таким образом, чтобы указать на соответствующие ISP-машины. Спросите в службе технической поддержки Вашего ISP о том, какие имена хостов можно использовать в МХ записях.
Если Вы решили поднимать электронную почту для Вашего домена, нужно будет проделать несколько шагов для ее настройки. Если настройка произведена невнимательно, то вероятно, письма будут ходить очень медленно, т.к. будут находиться на одном хосте, в то время, как получатель зарегистрирован на другом. Из соображений безопасности, я рекомендую, чтобы почта, приходящая с машин, которые доступны из внешней сети, фильтровались (это поможет при борьбе с теми, кто хочет, чтобы у его настольной машины был реальный IP, а потом удивляется, почему его машина зависает дважды в день). Задача использования системы пересылки электронной почты целиком решается при помощи sendmail. Если кто-нибудь захочет рассказать о работающем решении на другом транспорте электронной почты, я только приветствую добавления.
Чтобы электронный адрес, зарегистрированный на одном хосте был виден на всех машинах, самое простое решение - экспортировать почтовую директорию, с правами на запись и чтение, по всей частной сети. Шлюз Вашей частной сети будет как собиратель и отправитель электронных писем для всей частной сети, у которой должны быть права на запись в директорию mail у root'а. Другие клиенты могут иметь или могут не иметь таких прав, по Вашему усморению. Моя личная философия безопасности - не должны предоставляться привилегии, если нет явной причины для этого. Из-за этого в моей сети root может читать почту только с определенной машины, но это не такое уж большое препятствие. Обратите внимание, что каталог почты может быть каталогом в сети, экспортируемым через NFS, или это может быть каталог на одном из внутренних серверов, экспортируемый в частную сеть. Если почтовый каталог резидентен на шлюзе частной сети, то не будет никаких проблем с правами для этой машины. Если же он находится на другом сервере, то обратите внимание, что электронные письма будут возвращаться, если с этим сервером, шлюзом или сетевым соединением возникнут проблемы.
Для Windows-машин в Вашей частной сети можно также установить РОР сервер на хосте, обслуживающем почту, или использовать samba для экспорта почты на эти машины. Windows-машины могут быть настроены для отправки и получения почты под именем пользователя Linux, типа joeuser@example.com так, чтобы адрес содержал имя хоста и доменное имя, но не имя машины такое, как barney.example.com. SMTP сервер должен быть установлен на gateway-машине частной сети, которая будет отвечать за отправку и любую пересылку почты.
Затем Вы должны настроить sendmail, чтобы отправлять письма от машин частной сети, переписывая адреса, если это необходимо. Получите исходники последней версии sendmail на sendmail.org. Соберите его, затем зайдите в подкаталог cf/domain, в каталоге с sendmail и создайте новый файл: example.com.m4
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
Этот файл определяет домен ``example.com''. Далее Вы должны создать файлы sendmail.cf, которые будут использоваться на хосте почты (шлюзе частной сети) и на других Linux-узлах частной сети.
Создайте следующий файл в поддиректории программы sendmail cf/cf: example.master.m4
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В данном примере мы заблокировали команды ``expn'' и ``vrfy''. Т.к. используя ``expn'', нападавший мог бы писать с псевдонимов, пробуя имена подобно ``staff'', ``allstaff'', ``office'', и т.п., пока ему не откроются несколько имен пользователей, для которых он затем мог бы попробовать подобрать пароли. Как сделать, чтобы вход в вашу сеть был возможен только с машин, в нее входящих, описано в разделе Разд. 8.
Другой файл, который Вы должны создать, определит sendmail.cf для зависимых машин: example.slave.m4
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
Сформируйте соответствующие файлы sendmail.cf командой:
make example.master.cf example.slave.cfи затем скопируйте на соответствующие машины под именем sendmail.cf.
Эта конфигурация преполагает помещение большинства файлов конфигурации в подкаталог /etc/sendmail/. Она заставляет sendmail анализировать и использовать два специальных файла virtusertable.db и genericstable.db. Чтобы получить эти файлы, создайте их родительские прототипы. Первый - virtusertable.src:
John.Public@example.com jpublic Jane.Doe@example.com jdoe@somemachine.somedomain abuse@example.com root Pointyhaired.Boss@example.com #phb#@hotmail.comЭто карта электронных адресов на входящую почту. Почта, посланная на John.Public@example.com будет пересылаться на jpublic на локальной Linux системе. Почта, посланная на Jane.Doe@example.com, будет перенаправляться на другой адрес, возможно другого домена. Почта, посланная на abuse@example.com, будет перенаправляться root'у. Другой файл - genericstable.src:
jpublic John.Public@example.com janedoe Jane.Doe@example.com whgiii Pointyhaired.Boss@example.comЭтот файл отвечает за адреса отправителей почты в локальной системе. Это не может не затрагивать обратный адрес для почты, посланной непосредственно с jdoe@somemachine.somedomain, это позволит Вам переписывать адрес электронной почты отправителя на абсолютно любой. Наконец, создайте следующий Makefile в /etc/sendmail/:
all : genericstable.db virtusertable.db virtusertable.db : virtusertable.src makemap hash virtusertable < virtusertable.src genericstable.db : genericstable.src makemap hash genericstable < genericstable.srcЗапустите make, чтобы создать hashed-файлы, которые сможет использовать sendmail , и не забудьте повторно запускать make, и перезапускать sendmail после любых изменений в этих ``.src'' файлах.
Я имею опыт работы только с sendmail. Если у Вас есть опыт работы с другими транспортами почты, такими как Postfix, Exim, или smail, и Вы хотели бы дописать этот раздел, пожалуйста, свяжитесь со мной.
Вы должны установить сервер, видимый из внешней сети на машине, вне частной сети, а не на машине - шлюзе частной сети, по соображениям безопасности. Если серверу необходимо обращаться к некоторым ресурсам, находящимся внутри частной сети, ситуация становится более сложной. Вы не найдете описания таких случаев в данном документе.
Подробности об установке самого сервера могут быть найдены в документации к apache и в документе Linux WWW HOWTO.
Еще раз, FTP-хост должен быть виден из внешней сети, не устанавливайте FTP-сервер на шлюз частной сети. Прочитайте руководство по установке, которое идет с FTP-сервером. Убедитесь, что используете самую последнюю версию сервера, т.к. в ранних версиях многих FTP серверов есть уязвимые места, с точки зрения безопасности. Если Вам не требуется анонимный вход на FTP-сервер, убедитесь что отключили эту функцию в Вашей конфигурации. Я рекомендую, обязывать ваших пользователей использовать scp, это позволит им делать резервные копии всех изменяемых файлов. Более подробную информацию можно найти в разделе Разд. 8.
Этот раздел описывает установку защиты для Вашего нового домена. Акцент делается на скрытых от пользователя особенностях. Если защита будет слишком навязчива или будет мешать пользователям работать, то они обязательно найдут способ, чтобы сломать защиту или вообще поставить под угрозу работу всего домена. Лучший способ избежать этого - сделать защиту настолько прозрачной, насколько это возможно, и, кроме того, поощрять пользователей, которые будут указывать на слабые места Вашего домена. Я знаю из персонального опыта, что если строить слишком жесткую политику защиты, то пользователи найдут способ обойти ее. Лучше всего, чтобы все удаленные соединения были обоснованы и одобрялись лично Вами.
Эта секция описывает как защититься от атак извне, и как оградить себя от случайных ошибок внутри Вашей сети. Обеспечение защиты от нападений изнутри - это более сложная задача, и она не описывается в данном документе.
Одно из рассмотренных направлений защиты в данном разделе - так называемая защита против ``вражеского маршрутизатора''. Маршрутизатор, предоставленный Вашим ISP, может быть удаленно настраиваемым, или, например, при тестировании специалисты технической службы могли забыть убрать какой-либо тестовый пароль. И то, и другое ставит под угрозу систему защиты ISP, а при взломе ISP, хакеры могут нанести удар и по подсети, поэтому по возможности следует рассматривать маршрутизатор ISP как потенциально враждебный. Т.к. иначе хакеры смогут использовать любой IP адрес Вашей внешней или внутренней подсети, а это позволит им перенаправлять весь проходящий трафик и исходящие пакеты.
В этом разделе рассказывается о настройке маскарадинга, пересылки и фильтрации маршрутизации. Желательно, чтобы сперва Вы прочитали IPCHAINS-HOWTO, прежде чем читать советы, приведенные ниже. В этом HOWTO подробно описываются шаги компилирования ядра с поддержкой маскарадинга и использование бинарных файлов ipchains. Вы должны разрешить работу брендмауэра на всех машинах, имеющих IP адрес.
Проверьте Ваши сценарии загрузки, чтобы удостовериться что загрузка на шлюзе происходит в следующей последовательности:
Инициализация карты Ethernet.
Брендмауэр выполняется через ipchains.
Пересылка включена.
Запускаются сетевые демоны.
Так, в качестве примера, возьмем систему Slackware, конфигурирование брендмауэра в ней происходит между rc.inet1 и rc.inet2. Далее, если возникнут любые проблемы во время конфигурации, предупреждение будет выведено на экран и Ethernet-карта отключится до загрузки сетевых демонов.
Одна стандартная проблема с брендмауэерами, это убеждение в том, что Ваши права правильно установлены для пакетов, приходящих от внутренних или внешних машин на брендмауэер. Локальные пакеты могут быть блокированы брендмауэром. Все это можно проверить только в процессе отладки, доведя настройку брендмауэра до такого уровня, чтобы все компоненты системы работали. К сожалению, это иногда приводит к появлению дырок в защите. Ниже приведен типовой скрипт, который позволит Вам избежать многих проблем при настройке брендмауэра. Это пример скрипта, /sbin/firewall.sh:
#! /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}
Обратите внимание, что мы блокируем не только входящие пакеты, но
и исходящие, которые могли бы содержать сведения о Вашей частной
сети, например, пакеты rwho и netbios.Как замечено выше, права portmapper немного отличаются, т.к. демоны регистрируются непосредственно с portmapperи указывают, с какими портами работать. Порты, используемые частью демонов могут изменяться в зависимости от изменения используемых сервисов RPC, или их порядка загрузки. Следующий скрипт, /sbin/firewall.portmap.sh создает права для portmapped-демонов:
#! /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
}
Мы можем не волноваться, относительно пакетов, приходящих по нашей частной сети, т.к. цепочка portmap предназначена только для проверки пакетов, приходящих из внешней сети.Эта конфигурация брендмауэра логирует наиболее подозрительные пакеты через 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 # Разрешаем принимать входящие пакеты
Данный файл предполагает, что интерфейс eth1 находится на видимом из внешней сети (реальном) IP адресе. Если любой из наборов правил приводит к сбою установки, будет выдано сообщение и интерфейс отключится. До старта всех демонов мы блокируем прием любых пакетов из внешнего мира, т.к. в это время права еще не вступили в силу. После того, как объявленые нами права вступают в силу, мы восстанавливаем прием пакетов.Во время написания этого раздела 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.
Возьмите пакет ssh1 с ssh web site, или OpenSSH c OpenSSH web site, и скомпилируйте его, чтобы заменить незашифрованные r-программы (rsh, rlogin, и rcp). Во-первых, скопируйте эти три файла в /usr/lib/rsh/, затем сконфигурируйте пакет ssh:
./configure --with-rsh=/usr/lib/rsh/rsh --program-transform-name='s/^s/r/' --prefix=/usrУстановите бинарные файлы, и произведите настройку, согласно документации. На машине-шлюзе частной сети убедитесь, что конфигурация sshd имеет следующие значения:
ListenAddress 192.168.1.1 # внутренний IP шлюза IgnoreRhosts no X11Forwarding yes X11DisplayOffset 10 RhostsAuthentication no RhostsRSAAuthentication yes RSAAuthentication yes PasswordAuthentication yesВы должны сконфигурировать и другие параметры, входящие в файл /etc/sshd_config, но не пытайтесь заменить эти поля. Как только Вы пропишите параметры всех полей, скопируйте этот файл в новый файл /etc/sshd_config.ext, для внешней сети. Измените всего два поля для нового файла: параметр поля ``ListenAddress'' измените на внешний адрес шлюза (в нашем случае это 10.1.1.9), и параметр поля ``PasswordAuthentication'' измените на ``no'' в /etc/sshd_config.ext. В вашем скрипте загрузки сетевых сервисов запустите sshd дважды, раз
/usr/sbin/sshdи раз
/usr/sbin/sshd -f /etc/sshd_config.extЭто создаст такую ситуацию, что будет выполняться два демона sshd. Один, работающий на внутренний интерфейс, будет позволять заходить с паролями, а второй, предназначенный для внешнего интерфейса, будет требовать ключевую проверку RSA прежде, чем кто-то сможет войти.
Затем, запретите внешнее использование telnet и shell в файле конфигурации inetd (обратите внимание, что настройка брендмауэра, перечисленная в разделе Разд. 8.1, уже обеспечит предотвращение доступа снаружи, но лучше обеспечить полную безопасность, не полагайтесь на то, что все будет работать без сбоев).
Люди, которым необходимо будет входить в Вашу частную сеть из дома или из другого города, будут нуждаться в ключе RSA. Удостоверьтесь, что они знают как им пользоваться и не потратят свою энергию на поиск другого пути, как, например, использование telnetd на закрытом порте Вашего брендмауэра.
Ключ RSA генерируется командой:
ssh-keygen -b 1024 -f new_rsa_keyВас спросят фразу прохода. Она не должна быть пустой. Человек с доступом к файлу new_rsa_key, и знающий фразу прохода имеет все для авторизации RSA. Фраза прохода может быть паролем или длинным предложением, но не делайте из нее что-то тривиальное. Файл new_rsa_key может быть скопирован на дискету или ноутбук, и, наряду с фразой прохода, может использоваться для авторизации RSA.
Чтобы дать доступ через ключ RSA, необходимо создать каталог $HOME/.ssh/, для этого пользователя частной сети на шлюзе (т.е. на машине, которая будет принимать пользователя), и скопировать туда файл new_rsa_key.pub, который может быть создан командой "ssh-keygen" в файле $HOME/.ssh/authorized_keys. См. раздел ``ФОРМАТ ФАЙЛА AUTHORIZED_KEYS'' в man странице sshd для получения более подробной информации по другим опциям, которые Вы можете добавлять в ключ, например, запрос пароля при переходе с реального IP, или авторизацию ключом только при выполнении некоторых команд. В качестве примера, RSA ключ используется только при использовании команд резервного копирования, или отсылки сообщения о текущем состоянии за пределы системы.
Осталась только одна вещь, которую необходимо сделать чтобы, предоставить пользователю максимальное удобство при работе с механизмом RSA. Если пользователю приходится за сеанс работы набирать фразу прохода больше, чем один раз, то ему, вероятно, это сильно надоест. Под Linux упорядочите их оболочку входа в систему, чтобы она вызывалась под ssh-agent. Для примера, если ноутбук компании используется в деловых поездках, выполняя xdm, измените строку в файле /var/X11R6/lib/xdm/Xsession_0 с:
exec "$startup"на:
exec ssh-agent "$startup"В моей установке xdm имеется три таких строки в одном файле, все их надо изменить. Теперь, когда пользователь вошел, он вводит команду
ssh-add new_rsa_keyпри любом приглашении, пользователь вводит фразу прохода, и больше ему не потребуется вводить ее до выхода из Х-сеанса на ноутбуке.
Выполните sshd на всех машинах Вашей частной сети. Для машин, отличных от шлюза Вашей частной сети запись ``ListenAddress'' в /etc/sshd_config может быть выставлена в ``0.0.0.0''. Вы должны установить ключи к хостам командой:
ssh-keygen -b 1024 -f /etc/ssh_host_key -N ""затем запустите make-ssh-known-hosts и распределите файл /etc/ssh_known_hosts среди всех машин Вашей частной и внешней сети.
Запретите 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 адресами и поисков имен хостов.
В продолжении настройки для удобства защиты стало обычным помещение команд
xhost +в скрипты инициализации Х-сеанса. Это допускает, что сервер Х связывается с каждым в мире. Сейчас случайный посторонний может изменить рисунок вашего основного окна на что-нибудь неприличное в то время, как Ваш босс показывает своей матери ваш офис. Этот посторонний может контролировать все нажатия на клавиатуре и получать дамп Вашего рабочего экрана на своем мониторе. Само собой, это не скажется положительно на паролях, используемых для входа на другие сайты. Сам протокол xhost весьма ограничен, поскольку даже не может предоставить разрешение использование, в зависимости от работающего пользователя, а только в зависимости от работающей машины.
Используйте xauth аутентификацию. Если у Вас установлен xdm, Вы, вероятно, уже используете xauth аудентификацию, но xhost все еще работает, и мог бы быть тем, что люди используют, запуская Х процессы между машинами. Еще раз, цель состоит в том, чтобы сделать защиту достаточно простой в использовании, т.к. пользователей больше не соблазнить использованием команды xhost.
Установка sshd описана в секции Разд. 8.2, с установленным флагом ``X11Forwarding'', является фактически более простой в использовании альтернативной xhost. Как только Вы войдете в терминал, сможете просто выполнить rlogin для удаленной машины и запустить netscape, xv или что-нибудь другое, что Вам нравится, без установки переменной $DISPLAY или позволения явных разрешений. Во время входа в систему, автоматически будет настроен ssh абсолютно незаметно для пользователя, благодаря этому будет даже автоматическая зашифровка всех пакетов, перед их отправлением через сеть.
Если Вы не можете использовать sshd X11 форвардинг по некоторым причинам, то должны использовать xauth когда разрешите доступ других машин к Х серверу. Опишите это пользователям или создайте специальные скрипты чтобы помочь им. Чтобы разрешить вход в систему ``jpublic'', на машине ``barney'', с получением доступа к Х серверу, необходимо ввести:
/usr/X11/bin/xauth extract - $DISPLAY | rsh -l jpublic barney /usr/X11/bin/xauth merge -Эту последовательность можно не использовать для Х соединений с машин, которые совместно используют общий подключенный домашний каталог NFS. Xauth ключ будет немедленно доступным для пользователей тех машин, которые будут использовать тот же самый домашний каталог.
Я бы на Вашем месте удалил xhost с машин вообще. Если это вызовет проблемы с некоторыми программами, то, по крайней мере, будете знать, что у них слабое обеспечение безопасности. Достаточно просто разработать скрипт, для замены сигнала для xhost, который использует xauth последовательность, перечисленную выше.
Обратите внимание, что если rsh не шифруется ssh, xauth ключ передается в виде открытого текста. Любой, кто сможет перехватить ключ, сможет получить доступ к Вашему серверу, так что все усилия, направленные на безопасность системы, сводятся к нулу, если не используется ssh. Кроме того, если домашние каталоги экспортируются через NFS, то любому способному и любопытному человеку будут доступны все передающиеся через NFS пакеты, вне зависимости от того, используете Вы на Вашей системе ssh или нет.
Работать с почтой, приходящей на центральную машину, и читать/посылать ее с любой машины несомненно удобно, но некоторое внимание необходимо уделить и безопасности. NFS без AUTH_DES несомненно опасен. NFS полагается на клиентскую машину, для авторизации доступа не требуется проверка пароля, пользователю необходимо разрешить доступ к его специфическим файлам. Windows-машины могут быть сконфигурированы читать экспортированные NFS разделы с любым uid, полностью обходя права на файл, установленные UNIX. Следовательно, доступ к NFS можно давать только тем машинам, котороые всегда работают только под Linux (или Unix) и никогда не могут быть загружены под Windows. Чтобы экспортировать домашний каталог в Windows, используйте samba, установив режим аудентификации ``security=USER''. Соединение машин в вашей сети с использованием хаба тоже поможет, т.к. при этом теряется всякий смысл использования снифферов на Windows-машинах. В конечном счете, невозможно гарантировать совместное использование диска в сети.
Зачем беспокоиться, если все равно не получится поностью защитить ваши диски, которые совместно используются? Эту ситуацию можно проиллюстрировать следующим примером. Если Вы оставите лист бумаги с конфиденциальной информацией на столе и кто-то в офисе ее прочитает, он может сказать, что не знал, что это за бумага и посмотрел ее просто из любопытства. Но возникает совсем другая ситуация, если этот лист лежал в картотечном блоке или в столе. Цель установления, хотя бы элементарной сетевой защиты, это гарантия того, что никто ``случайно'' не поставит под угрозу Ваши данные.
Этот докумен был написан в пределах проекта DYNACAN, как часть его развития под контролем Ministry of Human Resources Development Canada.
При написании этого документа очень помогли следующие люди:
Rod Smith (rodsmith@rodsbooks.com), кто предложил мне подробно описать процесс регистрации домена и его настройки с использованием динамических IP адресов, и указавшим мне варианты выделения динамических IP адресов.
Greg Leblanc (gleblanc@my-deja.com) сделал немало полезных предложений, облегчивших это документ для понимания.
Sami Yousif (syousif@iname.com), сказал мне о www.dhs.org.
Marc-André Dumas (m_a_dumas@hotmail.com), это тот, кто предложил мне добавить раздел о перемещении старого домена на новый IP адрес.
Osamu Aoki (aoki@pacbell.net), который рассказал мне о www.fdns.net.
Это список некоторых используемых слов и сокращений, имеющих место в данном документе.
Это программа, которая выполняется по требованию удаленной стороны, а также она генерирует содержание web-страницы. Если web-страница должна выводить не просто текст и графику, вероятно Вам надо будет написать довольно сложный cgi-скрипт. Примеры его использования можно увидеть на досках объявлений, в реализации обратной связи, электронных магазинах и т.п.
Dynamic Host Configuration Protocol. Стандарт, описанный в RFC 1531, для компьютеров сети TCP/IP, позволяет при необходимости получить от центрального сервера информацию: IP-адрес, который они используют, сетевую маску, адрес шлюза и т.п. Чтобы администратору не вводить постоянно эту информацию машина просто запрашивает ее с сервера, прежде чем подсоединиться к серверу.
Domain Name Service. Стандарт для перевода имен доменов в IP-адрес, или наоборот, система ищет данные в централизованной базе данных.
Digital Subscriber Line. Высокоскоростное сетевое подключение, использующее существующие телефонные провода.
IP-адрес, который был назначен автоматически. Нет никакой гарантии, что этот номер останется постоянным. Динамический IP-адрес может изменяться только при отключении от сети и повторном подсоединении, или он может изменяться с определенной периодичностью под DHCP. Некоторые сервисы, такие как telnet и ssh прекращают работу, если IP-адрес изменится во время сеанса связи.
DNS запрос, которой конвертирует доменное имя в IP-адрес.
File Transfer Protocol. Протокол передачи файлов. Стандартный протокол для пересылки файлов между машинами в сети Интернет.
Демон, отвечающий за предоставление сервиса FTP на хосте. Он отвечает на запросы, посланные удаленным клиентом.
См. ISP.
См. IP-адрес.
``Адрес'' конкретного сетевого устройства. Стандартный протокол адресации, называемый ipv4, состоит из четырех 8-битных значений, которые пишутся как числа в десятичной системы счисления, разделенные точками. Связь между компьютерами в Интернет основывается на передаче пакетов информации на IP-адреса.
Internet Service Provider.Провайдер Интернет. Компания, которая предоставляет вам выход в Интернет.
Форма фильтрации, при которой в пакетах, передаваемых от машины во внешний мир, перезаписываются заголовки таким образом, чтобы казалось, что эти пакеты пришли с машины, на которой стоит маскарадинг. Затем эта машина передает ответы назад, на первую машину, с которой пакет был реально послан. Результатом использования маскарадинга может быть то, что целая сеть может выходить в Интернет через одну машину, имеющую подключение и всего один IP-адрес.
Name server daemon. Демон сервера имен. Этот демон отвечает на запросы DNS, он поставляется как часть пакета BIND.
См. NTP.
Network Time Protocol. Протокол сетевого времени. Стандарт для синхронизации Ваших системных часов с ``реальным временем'', определяемого, как среднее между многими высокоточными часами по всему миру.
Operating system. Операционная система. Linux, Windows, FreeBSD, BeOS, HP-UX, и т.п.
Pointy-Haired Boss. Детище Scott Adams, известное как Dilbert.
См. ISP.
DNS запрос, который конвертирует IP-адрес в доменное имя.
Специальное аппаратное устройство, которое определяет правила пересылки пакетов, определяемые по их IP-адресам, также оно служит как мост для соединения вашей сети Ethernet с ISP.
Secure shell. Безопасная оболочка. Замена программ rlogin, telnet, ftp, и т.п. на их криптографические варианты. Защищает от spoofing-атак и sniffing-пакетов.
IP-адрес, который прикреплен к Вам постоянно. Гарантируется, что этот номер будет доступен только вам, и никакая другая машина в Интернет не сможет его использовать. В этом его отличие от динамического адреса.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |