1 132 Военно-специальная подготовка Тема 5 Занятие 5 7

1/132 Военно-специальная подготовка Тема 5 Занятие 5. 7 Лекция 3 Сетевые сервисы ОС МСВС 3. 0 © Лялюк И. Н. , 2011

2/132 Содержание занятия • Службы разрешения имен • DNS (Domain Name Service) — служба доменных имен • Протокол динамической настройки хоста и сервер DHCP • Сетевая файловая система NFS • Samba в МСВС — защищенная сетевая файловая система • Сервер FTP • Система единого времени

3/132 1 Службы разрешения имен 1. 1 Проблема разрешения имен • Документ RFC 791: – Имя показывает искомый объект – Адрес показывает его местонахождение – Маршрут определяет способ попасть в нужную точку • Имена, адреса и маршруты в равной степени требуют внимания сетевого администратора – Как распространять имена и их соответствия адресам по сети? • Преимущество имен – их можно запоминать – Имя несет осмысленную информацию об адресате • Перевод имен в адреса нельзя считать частной проблемой – Имя должно правильно интерпретироваться в масштабе всей сети сетей – IP-адреса могут быть одинаковыми в разных локальных сетях – Это скрывается, ex, процедурой преобразования адресов – Имена должны быть преобразуемы к правильным адресам на любом узле сети

4/132 Методы перевода имен в адреса • Широкое распространение получили два метода перевода имен в адреса – Локальный – Глобальный • Локальный основан на поиске соответствия в локальном файле-базе данных узлов на данном компьютере – Этот файл получил название таблицы узлов – в ОС МСВС 3. 0 — /etc/hosts • Более современный (и глобальный) метод связан с применением распределенной базы данных DNS – Domain Name System – система доменных имен

5/132 1. 2 Таблица узлов • Файл /etc/hosts • Недостатки этого механизма разрешения имен: – Сложность сопровождения и распределения файла по большой сети – Файл не несет информации о узлах внешних сетей – Информация об изменениях не распространяется автоматически • Достоинства метода: – файл, содержащий информацию о принципиально важных узлах сети (шлюзах, серверах служб) может работать в отсутствии или при сбоях системы DNS – в маленьких сетях DNS не имеет преимущества в удобстве сопровождения перед локальным разрешением имен.

6/132 1. 3 Система доменных имен DNS • Исключает крупные недостатки таблицы узлов: – Не связана с каким-либо конкретным узлом – Хорошо масштабируется – Имеет в реализации средства резервирования и дублирования – Гарантирует распространение информации об изменениях, в том числе и о добавлении новых узлов – Информация распространяется автоматически и только по необходимости • Без чрезмерного увеличения количества локально хранимой информации (на серверах DNS) DNS умеет адресовать сотни миллионов узлов по всему миру

7/132 Принцип работы DNS • Сервер DNS, получив запрос информации о неизвестном ему узле, передает его компетентному (авторизованному) серверу • Компетентный сервер — это любой сервер, в ведении которого находится точная информация по домену, о котором идет речь в запросе • Локальный сервер, получив от компетентного сервера ответ, кэширует его для последующего использования • Получив запрос о той же информации еще раз, локальный сервер отвечает на запрос самостоятельно • Способность получать информацию об узлах из компетентных источников и автоматически распространять точные сведения дает DNS значительное преимущество перед таблицами узлов, даже в случае сетей, не подключенных к Internet

8/132 Принцип работы DNS • В DNS не существует централизованной базы данных, содержащей информацию обо всех узлах сети • Используется иерархическая идеология хранения информации • Иерархия узлов напоминает иерархию файловой системы UNIX • Каталоги файловой системы описываются с помощью путей, пролегающих от корневого каталога через промежуточные • Поиск путей к доменам и узлам в DNS также осуществляется следованием по указателям: от корневого домена — через промежуточные — к целевому • Непосредственно под корневым доменом располагаются домены верхнего уровня • Их имена могут нести информацию об организации или географическом регионе • Домены первого типа называются родовыми.

9/132 Имя домена Родовые домены верхнего уровня Описание com edu gov mil net int Коммерческие организации Образовательные учреждения Правительственные организации Военные организации Организации, обеспечивающие работу сетевой инфраструктуры Международные правительственные или околоправительственные организации org aero biz coop museum pro info name Организации, не попадающие ни в одну из перечисленных Организации авиационной промышленности Предприятия Совместные предприятия Музеи Профессионалы, такие, как медики или адвокаты Сайты, предоставляющие информацию Физические лица

10/132 Формы имен доменов • Абсолютная (полностью определенная) форма – Отражает иерархию доменов – Абсолютное имя домена записывается в направлении от частного (имя узла) к общему (домену верхнего уровня) и разделяется точками – Абсолютное доменное имя начинается с имени конкретного узла и заканчивается именем домена верхнего уровня • Форма записи относительно домена по умолчанию – Аналогично записи путей в UNIX относительно текущего рабочего каталога – При создании запроса к серверу имен DNS добавляет к вводу пользователя имя домена по умолчанию – Например, если доменом по умолчанию является company. com, пользователь может опускать расширение company. com для всех узлов этого домена – Обратиться к узлу department. company. com можно по имени deparment – Обычно, домен по умолчанию добавляется в случае, когда в воде пользователя отсутствует завершающая точка – К каждому доменному имени система добавляет точку в конце — имя корневого домена

11/132 Программное обеспечение DNS • Две категории ПО DNS – Поисковые анализаторы (resolvers, клиент DNS) – программные модули, формирующие запросы – Серверы имен – это процессы, реагирующие на запросы • Поисковый анализатор не является отдельным процессом – Это библиотека подпрограмм, которая используется любой программой, нуждающейся в функции поиска адресов – Библиотека умеет задавать серверам имен вопросы, касающиеся информации об узлах • Чистый DNS-клиент – Компьютер, на котором не работает локальный процесс сервера имен – Он полагается на другие узлы для работы со службой имен – Обычно чистыми DNS-клиентами оказываются однопользовательские системы • В любых более-менее крупных системах обычно существует локальный процесс сервера имен

12/132 Классификация серверов имен • Основана на способах их настройки • Основные (master, ведущие, первичные) – Серверы, служащие источниками всех данных по домену – Загружают информацию о домене непосредственно с диска, из файла, созданного администратором домена – Являются компетентными (authoritative), обладают полной информацией по обслуживаемым доменам и всегда дают правильные ответы – Домену нужен лишь один основной сервер для домена • Подчиненные (slave, ведомые, вторичные) – Получают полную базу данных (БД) домена от основного сервера – БД для отдельного домена называется файлом зоны; копирование этой БД на подчиненный сервер называется передачей зоны – Также являются компетентными для своих доменов

13/132 Классификация серверов имен • Кеширующие (caching-only) – Получают ответы на все запросы от других серверов имен – Получив ответ на вопрос, кешируют информацию и в будущем используют ее, чтобы самостоятельно отвечать на запросы – Большинство серверов имен практикует кеширование – Кеширующие серверы используют исключительно этот метод для построения базы данных домена – Кеширующие серверы являются некомпетентными, их информация получается из вторых рук и не полна • Система серверов имен легко масштабируется – При добавлении новой системы в сеть достаточно изменить базу данных на первичном сервере – Информация автоматически распространяется по всем сетям, сервера которых получают зону полностью, либо кешируют отдельные ответы

14/132 1. 2 Почтовые службы • Электронная почта – Жизненно важная составляющая работы любой организации, приложение, обеспечивающее общение сотрудников • Стек протоколов TCP/IP обеспечивает надежную, гибкую систему электронной почты, построенную на ряде базовых протоколов – Простой протокол передачи почты SMTP (Simple Mail Transfer Protocol) – Протокол почтовой службы. POP (Post Office Protocol) – Межсетевой протокол доступа к сообщениям IMAP (Internet Message Access Protocol) – Многоцелевые расширения почтовой службы MIME (Multipurpose Internet Mail Extensions) • Поддержка этих протоколов осуществляется рядом UNIX- (sendmail) и Linux-приложений

15/132 Простой протокол передачи почты (SMTP) • TCP/IP-протокол доставки электронных сообщений • Функционирует на базе надежной службы логических соединений протокола TCP через порт 25 – Пользователь может управлять почтовым соединением вручную, подключившись с помощью telnet к порту 25 почтового сервера • SMTP обеспечивает прямую передачу почты – Некоторые другие почтовые системы используют протоколы передачи с промежуточным хранением, за одно действие передавая почту на шаг ближе к пункту назначения, пока она не доберется до адресата – Прямая доставка позволяет SMTP доставлять почту, не полагаясь на промежуточные узлы – Если доставка невозможна, локальная система узнает об этом немедленно • Минусы прямой доставки: – Требует полной готовности к работе с почтой от систем по обе стороны соединения – Если адресат выключен, SMTP генерирует сообщение об ошибке. – Для решения этой проблемы используются возможности DNS для перенаправления почты на почтовый сервер – Затем, когда клиент вновь будет в сети, сообщение попадает к нему уже с почтового сервера

16/132 Пример ручной отправки письма (SMTP) (набор пользователя выделен жирным шрифтом)

17/132 Протокол почтовой службы (POP) • Существует два варианта почтовой службы: РОР 2 и РОРЗ • Несмотря на общую базовую функциональность, протоколы используют несовместимые наборы команд. • РОР 2 работает через порт 109 • РОРЗ работает через порт 110. • Протоколы POP проверяют регистрационное имя пользователя и пароль, а затем помещают почту пользователя с сервера в почтовый ящик локальной пользовательской программы для чтения почты • POP — простые протоколы, реализовать соединение можно также вручную через telnet, указав соответствующий порт

18/132 Протокол почтовой службы (POP) • Набор команд позволяет: – Указать имя учетной записи и пароль – Отобразить информацию о непрочитанных сообщениях, – Извлечь, поместить, удалить сообщение и выполнить другие необходимые действия – Все эти подробности обычно скрыты от пользователя за интерфейсом почтовой программы-клиента, установленной у него на компьютере • Удаление отдельных сообщений на клиентской машине никак не влияет на содержимое почтового ящика на сервере – Все сообщения считаются единым блоком, который либо удаляется, либо сохраняется после передачи писем клиенту – Клиенты электронной почты, испытывающие необходимость удаленно управлять почтовым ящиком на сервере, используют на серверах протокол IMAP

19/132 Межсетевой протокол доступа к сообщениям • IMAP является альтернативой протоколу POP – Содержит те же базовые средства, что и POP – Обладает также функциями для синхронизации почтовых ящиков – Реализует чтение отдельных сообщений как на клиентской машине, так и прямо на сервере – Тем самым обеспечивает актуальность почтовых ящиков и той, и другой системы • Для надежной, последовательной передачи данных IMAP использует протокол TCP и порт 143 (или 220) • Подобно POP, он работает по модели запрос-ответ и содержит небольшое число команд

20/132 Межсетевой протокол доступа к сообщениям • Протокол IMAP сложнее протокола POP • IMAP вплотную подходит к той границе, за которой набор команд вручную уже неэффективен • На практике ручной набор применяется редко • Единственной возможно необходимой проверкой является проверка работоспособности сервера imapd – Чтобы выполнить такой запрос, надо соединиться с помощью telnet с соответствующим портом (143 или 220) – Признаком работоспособности является факт установления соединения – Соединение можно мягко разорвать с помощью команды LOGOUT

21/132 Многоцелевые расширения почтовой службы • MIME (Multipurpose Internet Mail Extentions) — расширение существующей почтовой системы TCP/IP • Занимается различением характера данных, а не способами доставки • Дополняет почтовые протоколы в двух аспектах, не определенных стандартом RFC 822: – Поддержка различных типов данных • Почтовая система, определяемая стандартом, доставляет 7 -битные ASCII-данные • Этого не достаточно для пересылки данных в других алфавитах или бинарных данных – Поддержка сложного наполнения сообщений • В стандарте подробно описаны заголовки сообщений, но нет достаточно подробного описания тела электронного сообщения

22/132 Многоцелевые расширения почтовой службы • MIME определяет методы кодирования, позволяющие передавать различные виды данных, и структуру сообщения, позволяющую передавать в одном письме несколько объектов – MIME устанавливает типы данных, перенос которых не планировался при разработке SMTP – Чтобы справиться с новшествами, был разработан метод расширения протокола — SMTP Service Extentions • Документ RFC 1869 определяет простой механизм, позволяющий системам SMTP согласовывать использование расширений – В частности, определена новая команда приветствия — EHLO, и приемлемые ответы на эту команду – Получив такое приветствие, система может выдать список расширений, которые она поддерживает – Реализации, понимающие команду EHLO, известны в качестве систем ESMTP (расширенный SMTP) – ESMTP и MIME — важные механизмы для передачи с помощью электронной почты данных, отличных от ASCII-текста

23/132 1. 3 Серверы файлов и печати. Совместный доступ к файлам Сетевая прозрачность доступа к файлам (NFS и SMB) • Корректно построенная система совместного доступа к файлам не требует копирования файлов по сети – Она организует доступ к файлам на уровне отдельных записей, позволяя клиенту прочитать запись из файла, хранимого на удаленном сервере, изменить эту запись и снова записать ее в файл, не копируя файл целиком с сервера на локальную систему и обратно • Совместный доступ к файлам прозрачен для пользователя и прикладных программ, работающих в системе пользователя – Совместный доступ позволяет пользователям и программам обращаться к файлам так, как если бы они хранились локально • В идеальной среде совместного доступа к файлам пользователь вообще не знает и не стремиться узнать, где на самом деле хранятся файлы

24/132 Совместный доступ к файлам по протоколу TCP/IP в гетерогенных средах • Net. BIOS/Server Message Block (Net. BIOS/Блок серверных сообщений) – Базовая система сетевого ввода-вывода разработки IBM, используется в Windows – UNIX-системы способны действовать в качестве файловых серверов и серверов печати для клиентов Windows при помощи программного пакета Samba, который реализует протоколы Net. BIOS и SMB • Сетевая файловая система NFS (Network File System) – Разработка Sun Microsystems в целях поддержки бездисковых рабочих станций – Используется преимущественно для приложений в локальных сетях • Реализации Samba и NFS имеются в ОС МСВС 3. 0

25/132 Копирование файлов по сети (FTP) • Протокол передачи файлов FTP (File Transfer Protocol) – Более архаичная и простая служба в отличие от систем, осуществляющих совместный доступ к файлам на условиях сетевой прозрачности – Позволяет копировать файлы по сети из хранилищ общего доступа или в них – Не безопасный протокол – В случае авторизованного доступа к серверу передает пароли по сети в открытом виде • Злоумышленник, получивший доступ в сеть, прослушивая сеть может отследить эти пароли – Если пользователи беспечны и имеют общие пароли и для доступа к FTP, и к почте, и к более безопасным серверам, таким как SSH, потенциальному нарушителю будет где развернуться

26/132 Копирование файлов по сети (FTP) • Протокол до сих пор широко применяется и не до конца вытеснен более безопасными протоколами, такими, как SFTP, т. к. – Набор команд FTP прост и стандартен для множества реализаций серверов – Имеются встроенные клиенты в файловые менеджеры, например, Midnight Commander – К одному серверу FTP легко организовать доступ из различных ОС • Для повышения безопасности FTP рекомендуется – Настраивать сервера на анонимный доступ (чтобы открытые пароли не передавались по сети) – Ограничивать права пользователей • Можно разрешить всем записывать и читать из определенного каталога, но запретить стирать файлы • Можно использовать серверы как общедоступные хранилища файлов только для чтения

27/132 Серверы настройки • Мощные возможности стека протоколов TCP/IP повышают также и их сложность – TCP/IP требует информации об аппаратной части, адресах и маршрутах в процессе инициализации стека (в большинстве случаев — в процессе загрузки системы) – Стек TCP/IP не зависит от аппаратной части, значит, информацию нельзя зашить в оборудование, как это делается в других системах – Информация должна исходить от администратора сети • Серверы настройки позволяют администратору распространять информацию о сетевых настройках централизованно – Конечный пользователь избавляется от необходимости быть в курсе сетевой политики – Повышается качество информации о настройках

28/132 Протоколы распространения информации о сетевых настройках • Протокол обратного разрешения адресов RARP – Возвращает IP-адрес по аппаратному адресу • Протокол сетевой загрузки ВООТР – Осуществляет распространение большего объема информации и позволяет себя наращивать • Протокол динамического конфигурирования хоста DHCP – – Развитие протокола ВООТР Он в основном и используется Сервер DHCP поддерживает также клиентов ВООТР Позволяет распространять полный набор данных настройки – Как правило, это не требуется, потому что TCP/IP позволяет использовать многие значения по умолчанию – Для администратора интересен главным образом своим алгоритмом автоматического выделения адресов

29/132 Выделение адресов DHCP • Способы выделения адресов DHCP: 1. Выдача администратором фиксированных постоянных адресов – При этом DHCP способен исключить адреса из диапазонов адресов, выдаваемых автоматически 2. Ручное выделение адресов – Как это делается в протоколе ВООТР (например, клиентам ВООТР) 3. Автоматическое выделение из диапазона выдаваемых адресов 4. Динамическое выделение адресов – – – Сервер назначает адрес клиенту на ограниченное время (аренда адреса) По окончании этого периода сервер может возвратить адрес в пул выдаваемых адресов Наиболее эффективное применение DHCP

30/132 Динамическое выделение адресов DHCP • Полезно в сетях с добавлением и удалением узлов – Адреса используются только по необходимости, нет «мертвых» адресов – Но использовать динамическое выделение для всех систем невозможно – Серверы имен, почтовые серверы, прочие системы совместного доступа должны иметь постоянный адрес • Сервер DHCP передает настройки клиенту в результате обмена служебными пакетами между портами UDP 67 (сервер) и UDP 68 (клиент) – Это отличает DHCP от других клиент-серверных архитектур, где клиенты используют эфемерный порт – В начале обмена клиент еще не знает своего IP-адреса, поэтому сервер посылает первичный ответ всем узлам сети на определенный порт – Это гарантирует получение информации адресатом

31/132 Порядок обмена служебными пакетами DHCP • Клиент посылает широковещательный запрос серверу • Сервер отвечает широковещательным ответом, содержащим параметры настройки, на порт 68 всем машинам сети • Клиент отвечает согласием на настройки • Поскольку используется UDP, клиент может получить несколько пакетов настройки одного содержания, но отвечает только одним пакетом • Сервер подтверждает получение согласия на настройки • Если в цепочке обмена где-то произойдет сбой (например, потеря пакета), протокол сработает заново, воспроизведя весь обмен сначала • DHCP предоставляет гибкие инструменты для настройки сетевых параметров машин сети • Проблема взаимодействия сервера имен DNS и сервера динамической настройки: – При смене IP-адреса хост не меняет свое сетевое имя – Решается в системе DDNS (динамический DNS)

32/132 2 Служба доменных имен DNS 2. 1 Служба DNS в ОС МСВС 3. 0 • В ОС МСВС 3. 0 система DNS присутствует в виде пакета BIND (Berkeley Internet Name Domain) • BIND — это программный пакет, работающий по модели клиент-сервер • Клиентская часть называется DNS-клиентом • Клиент генерирует запросы информации, связанной с доменными именами, и передает их серверу • Сервер DNS отвечает на эти запросы • Серверная сторона BIND реализована в виде демона named

33/132 Настройка DNS-клиента • Настройка клиента производится посредством файла /etc/resolv. conf • DNS-клиент (resolver) не является самостоятельным отдельным процессом: – Это библиотека подпрограмм сетевых процессов • Чтение файла /etc/resolv. conf происходит в начале работы процесса, нуждающегося в DNS-клиенте, и на время жизни этого процесса кэшируется • Если файл настройки не найден, DNS-клиент пытается подключиться к DNS-серверу на локальном узле • И хотя такой подход часто срабатывает, опытные администраторы не советуют им пользоваться – Применение настроек по умолчанию лишает администратора возможности полного контроля над DNS-клиентом и делает его уязвимым для различий в установках по умолчанию, которые могут отличатся в различных ОС – На любой системе, работающей с BIND, следует создавать собственную версию файла настройки DNS-клиента

34/132 Настройка DNS-сервера • Сводится к двум группам действий: – Настройке сервера DNS; – Созданию файлов базы данных сервера имен (файлов зон) • Зона — это сегмент пространства доменных имен, который входит в компетенцию определенного сервера имен – Не может содержать домен, делегированный другому серверу – Здесь домен — это часть иерархии доменов, обозначенная именем домена, зона — пакет информации о домене, хранящийся в файле базы данных DNS – Файл зоны – это файл содержащий информацию о домене • Вариант настройки сервера определяется типом службы, доступ к которой необходимо обеспечить – – Чистый клиент (сервер не запущен и не используется) Специальный кэширующий сервер Основной сервер (ведущий, master) Подчиненный сервер (вторичный, slave) • Три последних варианта требуют запуска на локальной системе серверного процесса named

35/132 Основной сервер имен DNS • Является компетентным (авторитетным) источником сведений о конкретной зоне • Загружает информацию из локального дискового файла, создаваемого администратором домена – Этот файл (файл зоны) содержит наиболее актуальную информацию о сегменте иерархии доменов, подчиненных данному серверу имен • Является компетентным – Может ответить на любой запрос относительно зоны с полной уверенностью • Его настройка требует полного набора файлов: – – Файлов зон или зон прямого и обратного отображения Файла named. conf Файла корневых указателей Кольцевого файла • Ни один другой вариант настройки не требует столь обширного набора файлов

36/132 Подчиненный сервер имен DNS • Подчиненный (вторичный) сервер имен получает всю информацию зоны от основного сервера – Данные зоны передаются основным сервером и сохраняются подчиненным сервером в локальном файле – Такая передача называется передачей зоны – Подчиненный сервер хранит полную копию всех данных зоны – Является компетентным сервером (может компетентно отвечать на запросы относительно этой зоны) • Настройка подчиненного сервера имен не требует создания локальных файлов зон – Эти файлы копируются с основного сервера • Однако должны обязательно присутствовать – Файл загрузки – Файл кэширования – Кольцевой файл

37/132 Специальный кэширующий сервер имен DNS • Не хранит файлы зон • Узнает все ответы на запросы от других серверов • Кэширует полученный ответ и использует впоследствии для ответа на идентичные запросы – В принципе, все серверы используют кэшированную информацию, но только специальный кеширующий сервер имен полностью полагается на этот метод • Кэширующий сервер не считается компетентным – Получаемая от него информация — не из первых рук • Требует только присутствия загрузочного файла и файла кэширования – Однако обычно присутствует еще и кольцевой файл • Наиболее распространенный вариант настройки • После варианта чистого DNS-клиента является самым простым

38/132 Файлы настройки сервера named • Настройка демона named требует присутствия нескольких файлов • Полный набор файлов настройки – – – Файл настройки Файл корневых указателей Кольцевой файл Файл прямого отображения зоны Файл обратного отображения зоны • Всем этим файлам администратор может дать любые имена • Однако, для того, чтобы облегчить коллегам сопровождение системы, следует придерживаться неких общих соглашений и наглядных имен файлов

39/132 Файлы настройки сервера named • Файл настройки named. conf – Определяет общие аспекты работы named и указывает источники данных базы DNS, используемой этим сервером – Источниками могут служить локальные дисковые файлы, либо удаленные серверы • Файл корневых указателей named. ca – Указывает на серверы корневых зон • Кольцевой файл named. local – Используется для локального разрешения кольцевого адреса • Файл прямого отображения зоны – Файл зоны, содержащий отображения имен узлов в IP-адреса – Содержит основной массив информации о зоне – Файл зоны обычно имеет наглядное имя, позволяющее понять, данные какой зоны хранятся в файле, например, os. vniins. hosts. • Файл обратного отображения зоны – Файл зоны, содержащий отображения IP-адресов в имена узлов – Файл обратной зоны обычно имеет наглядное имя, позволяющее понять, какие адреса он обслуживает, например, 172. 16. rev

40/132 Файл named. conf • Файл named. conf указывает демону named источники информации DNS – Некоторые из источников представлены локальными файлами – Другие — удаленными серверами – Создавать следует только те файлы, на которые указывают операторы master и cache • Структура команд настройки файла named. conf похожа на структуру программ языка С – Оператор заканчивается точкой с запятой – Константы заключаются в кавычки – Родственные элементы группируются при помощи фигурных скобок – Комментарий может ограничиваться парами символов /* и */, как в языке С, или начинаться символами // или # • Содержимое файла named. conf определяет роль сервера: – Основной сервер зоны – Подчиненный сервер зоны – Специальный кэширующий сервер

41/132 Директивы файла настройки named. conf acl Определяет список управления доступом, состоящий из IP-адресов include Включает содержимое внешнего файла в файл настройки key Определяет ключи проверки подлинности logging Определяет состав журнала сообщений и способ хранения options Определяет глобальные параметры настройки и умолчания server Определяет свойства удаленного сервера zone Определяет зону • Приводимой информации достаточно, чтобы разобраться в примерах конфигурационных файлов • Однако в сложных случаях (например, настройка корневых серверов) может потребоваться полное описание команд (содержится в полном руководстве BIND) • Примеры настроек рассмотрим на групповом занятии

42/132 Стандартные записи ресурсов • Описанные выше команды настройки используются только в файле named. conf • Все прочие файлы, задействованные в настройке демона, хранят информацию базы данных DNS – – Файл зоны Файл обратной зоны named. local named. ca • Эти файлы имеют схожее строение и состоят из записей одних и тех же типов – RR‑записей – стандартных записей ресурсов • RR-записи определены документом RFC 1033, а также другими документами

43/132 Стандартные записи ресурсов Текстовое название RR-записи Начало компетенции (Start of Authority) Тип записи SOA Сервер имен NS (Nameserver) Адрес А (Addres) Указатель PTR (Pointer) Почтовый ретранслятор MX (Mail Exchange) Каноническое имя (Canonical Name) Текст (Text) Назначение Отмечает начало данных зоны и определяет параметры, влияющие на зону в целом Указывает сервер имен домена CNAME Обеспечивает преобразование имени узла в адрес Обеспечивает преобразование адреса в имя узла Указывает, куда следует доставить почту, предназначенную определенному доменному имени Определяет псевдоним для имени узла TXT Хранит произвольные текстовые строки • Основу файлов зон составляют стандартные записи ресурсов • Кроме того, в BIND существует ряд директив файла зон, которые используются при создании базы данных DNS

44/132 Формат RR-записи DNS • [имя] [ttl] IN тип данные • имя – Имя доменного объекта, с которым связана запись – Это может быть конкретный узел либо целый домен – Строка в поле имени интерпретируется относительно текущего домена, за исключением случая, когда заканчивается точкой – Пустое поле имени (т. е. содержащее исключительно пробелы) означает, что запись относится к последнему из упомянутых доменных объектов – Например, если за адресной (А) записью для узла следует МХ-запись с пустым полем имени, считается, что обе записи относятся к вышеописанному узлу

45/132 Формат RR-записи DNS • [имя] [ttl] IN тип данные • ttl – Время жизни определяет продолжительность хранения записи в кэше удаленной системы в секундах – Как правило, это поле остается пустым, и в таком случае используется время жизни по умолчанию, установленное для всей зоны в целом при помощи директивы $TTL • IN – Указывает, что запись имеет класс Internet. Существуют и другие классы, но они редко применяются. • тип – Указывает тип записи • данные – Информация, присущая данному типу RR-записи. Например, в случае адресной (А) записи поле данных содержит IP-адрес

46/132 Директивы файла зон • Директива $TTL – Задает значение времени жизни по умолчанию для RRзаписей, не содержащих явного указания параметра TTL – Значение времени может определятся в секундах либо сочетаниями чисел и букв – Недельное время жизни по умолчанию определяется в численном формате таким образом: $TTL 604800 – Одна неделя эквивалентна 604800 секундам – Посредством алфавитно-цифрового формата одну неделю можно задать проще: $TTL lw • Допустимые значения алфавитно-цифрового формата: – – – w — неделя d — день h — час m — минута s — секунда

47/132 Директивы файла зон • Директива $ORIGIN – Устанавливает текущую зону, т. е. доменное имя, которым дополняются все относительные доменные имена – Относительным доменным именем считается любое имя, которое не заканчивается точкой – По умолчанию $ORIGIN принимает значение доменного имени, указанного в операторе zone • Директива $INCLUDE – Включает содержимое внешнего файла в качестве фрагмента файла зоны – Внешний файл включается в файл зоны в точке присутствия директивы • Директива $GENERATE – Используется для создания серий RR-записей – Записи ресурсов, создаваемые посредством этой директивы, практически идентичны и различаются только числовыми индексами

48/132 Директивы файла зон • Пример: $ORIGIN 20. 16. 172. in-addr. arpa $GENERATE 1 -4 $ CNAME $. 1 to 4 – За ключевым словом $GENERATE следует диапазон записей, которые необходимо создать – В данном случае диапазон охватывает индексы от 1 до 4 – За диапазоном следует шаблон RR-записей – В данном случае шаблон выглядит так: $ CNAME $. 1 to 4. • Таким образом, данная директива приводит к созданию следующих записей: CNAME 1. 1 to 4 CNAME 2. 1 to 4 CNAME 3. 1 to 4 CNAME 4. 1 to 4

49/132 Директивы файла зон • Учитывая, что текущей зоной является 20. 16. 172. in-addr. arpa, данные записи ресурсов идентичны следующим записям: 1. 20. 16. 172. in-addr. arpa CNAME 1. 1 to 4. 20. 16. 172. in-addr. arpa. 2. 20. 16. 172. in-addr. arpa CNAME 2. 1 to 4. 20. 16. 172. in-addr. arpa. 3. 20. 16. 172. in-addr. arpa CNAME 3. 1 to 4. 20. 16. 172. in-addr. arpa CNAME 4. 1 to 4. 20. 16. 172. in-addr. arpa. • Эти записи полезны для делегирования обратных поддоменов • За исключением named. conf, все файлы настройки BIND состоят из стандартных записей ресурсов и директив • Все четыре оставшихся файла настройки — файлы базы данных • Два из них, named. ca и named. local существуют на каждом сервере независимо от его типа

50/132 Файлы инициализации кэша • Оператор zone в файле named. conf, имеющий тип hints, указывает на файл инициализации кэша • Каждый сервер, кэширующий данные, имеет такой файл • Файл содержит информацию, позволяющую начать построение кэша данных имен после загрузки процесса сервера имен • Корневой домен обозначается в операторе zone одной точкой в поле имени домена, поскольку файл инициализации кэша содержит имена и адреса корневых серверов • Файл named. ca называют файлом указателей потому, что он содержит указания, позволяющие демону named инициализировать кэш • Указатели предоставляют данные об именах и адресах корневых серверов имен • Файл указателей помогает локальному серверу обнаружить корневой сервер во время запуска

51/132 Файлы инициализации кэша • Когда найден один корневой сервер, локальный сервер получает от него официальный перечень корневых серверов • Указатели используются вновь только в случае принудительного перезапуска локального сервера • Информация из файла named. ca используется нечасто, но она критична для начального этапа работы сервера • Простейший файл named. ca содержит NS-записи с именами и А-записи с адресами корневых серверов

52/132 Файлы инициализации кэша • Данный файл содержит только NS- и А-записи – Каждая NS-запись определяет сервер имен для корневого домена (. ) – Соответствующая А‑запись содержит адрес для каждого корневого сервера – Значение TTL для всех записей равно 3600000, что примерно соответствует 42 дням • Файл named. ca должен обновляться раз в несколько месяцев, чтобы информация о корневых серверах всегда была актуальной (кроме случаев, когда DNS-сервер работает в локальной сети без выхода в Интернет) • Если сеть не имеет выхода во внешний мир, named. ca должен хранить информацию о крупных серверах локальной сети

53/132 Файл named. local • Файл named. local позволяет осуществить преобразование адреса 127. 0. 0. 1 в имя localhost и является файлом зоны обратного домена 0. 0. 127. in-addr. arpa • Поскольку адрес 127. 0. 0. 1 используется в качестве «кольцевого» во всех системах, содержание этого файла идентично практически для всех серверов

54/132 Файл named. local 2 3 4 Записи SOA и NS определяют зону и сервер имен зоны Первая запись PTR связывает сеть 127. 0. 0. 0 с именем loopback. Это альтернатива созданию подобной связи в файле /etc/networks Вторая запись PTR — самая главная в этом файле. Она связывает узел с адресом 1 в сети 127. 0. 0 с именем localhost 1 Директива $TTL устанавливает значение времени жизни по умолчанию для всех записей ресурсов данной зоны. Значение может переопределяться для каждой в отдельности записи явным указанием TTL.

55/132 1 Запись начала компетенции (SOA) обозначает узел serv. os. vniins. в качестве сервера, распространяющего данные зоны Файл named. local 2 Почтовый адрес vlad. os. vniins. определяется в качестве контактных координат, которыми можно воспользоваться, если возникнут какие-либо вопросы относительно зоны 3 Доменные имена оканчиваются точками, т. е. являются абсолютными и не подлежащими дополнением доменным именем по умолчанию 4 Запись NS также содержит имя узла. Изменив эти три поля данных, можно воспользоваться этим файлом на любом узле

56/132 Файлы инициализации кэша • Итак, изменив только три поля данных, можно воспользоваться файлом инициализации кэша на любом узле • Файлы named. conf, named. ca и named. local позволяют полностью настроить кэширующий сервер или подчиненный сервер • Простейший способ создать файлы — скопировать образцы, изменив их под свои условия • Оставшиеся файлы настройки более сложны, но и менее востребованы, если брать общее число всех серверов имен • Полный набор файлов настройки нужен лишь основному серверу домена, а в каждом домене основной сервер только один

57/132 Файл обратной зоны • Файл обратной зоны весьма схож строением с файлом named. local • Оба файла преобразуют IP-адреса в имена узлов, поэтому оба содержат записи PTR • Файл 172. 16. rev в нашем случае является файлом обратной зоны для домена 16. 172. in-addr. arpa. • Администратор домена создает этот файл на узле serv • Все прочие узлы, нуждающиеся в хранимой информации, обращаются к серверу serv

58/132 Файл обратной зоны • В качестве первой записи в файле обратной зоны выступает запись SOA • Символ @ в поле имени SOAзаписи является ссылкой на текущую зону • Поскольку данный файл зоны не содержит директивы $ORIGIN, явным образом задающей текущую зону, текущей зоной является домен 16. 172. in-addr. arpa, обозначенный оператором zone этого файла в файле named. conf: zone "16. 172. in-addr. arpa" { type master; file "172. 16. rev"; };

59/132 Файл обратной зоны • Символ @ в SOA-записи позволяет оператору zone определять домен для файла зоны • Точно такая же запись используется для всех зон • Она всегда ссылается на верное имя домена, поскольку ссылается на домен, определенный для данной текущей зоны в файле named. conf • Изменение имени узла и почтового адреса администратора домена позволит использовать запись в любом другом файле зоны

60/132 Файл обратной зоны • NS-записи, следующие за SOA-записью, определяют серверы имен домена • Как правило, серверы имен перечисляются сразу после SOA-записи с пустыми полями имен • Пустое поле имени означает, что запись находится в области действия последнего упомянутого доменного имени • Таким образом, последующие NS-записи относятся к тому же домену, что и запись SOA

61/132 Файл обратной зоны • Основу файла обратной зоны составляют записи PTR • Они используются для преобразования адресов в имена узлов • Записи PTR в текущем примере обеспечивают преобразование адреса в имя для узлов 12. 1, 12. 2, 12. 3, 12. 4 и 2. 1 сети 172. 16 • Поскольку значения в полях имен PTR-записей не заканчиваются точкой, они интерпретируются относительно текущего домена • Например, значение 3. 12 интерпретируется как 3. 12. 16. 172. in-addr. arpa • В поле данных PTR-записи содержится абсолютное имя узла, что предотвращает интерпретацию имени в качестве относительного для текущего имени домена и поэтому оканчивается точкой • Использую информацию в этой PTR-записи, named преобразует 3. 12. 16. 172. in-addr. arpa в edu. os. vniins.

62/132 Файл обратной зоны • Последние две строки файла содержат дополнительные NS-записи • Как любой другой домен, in-addr. arpa может содержать поддомены • Две последние записи реализуют как раз создание поддомена • Они указывают узлы linux и devel в качестве серверов имен для поддомена 6. 172. in-addr. arpa. • Любой запрос, касающийся информации поддомена 6. 172. inaddr. arpa, направляется к этим серверам • NS-записи, указывающие на серверы поддомена, должны быть размещены в домене более высокого уровня, прежде чем к поддомену можно будет обращаться

63/132 Файл обратной зоны • Доменные имена — сущность не тождественная IP-адресам • Структура этих объектов различна • Когда IP-адрес преобразуется в доменное имя in-addr. arpa, 4 байта адреса интерпретируются в качестве 4 компонентов одного имени • IP-адрес — 32 непрерывных бита, а не 4 отдельных байта • Подсети разделяют адресное пространство IP, а маски подсетей — побитовые, то есть не ограниченные рамками отдельных байтов • Ограничение поддоменов рамками байтов делает их менее гибкими, чем подсети, которые эти поддомены должны поддерживать. • В текущем примере домен in-addr. arpa делегирует поддомен по границе байта, то есть каждый байт адреса считается самостоятельным «именем» • Таков простейший механизм делегирования обратных поддоменов, но в отдельных случаях он может оказаться недостаточно гибким

64/132 Использование директивы $GENERATE • Использование директивы $GENERATE позволяет сделать делегирование обратных доменов более гибким • Она может создавать CNAME-записи, отображающие диапазон адресов домена in-addr. arpa в другой домен, с более гибкими правилами для доменных имен • Доменные имена in-addr. arpa должны состоять из четырех числовых полей, соответствующим четырем байтам IPадреса, и строки in-addr. arpa. • Можно связать эти имена с более длинными и более гибкими именами посредством директивы $GENERATE:

65/132 Использование директивы $GENERATE • Эти четыре команды $GENERATE выполняют отображение 256 численных имен домена 30. 168. 192. in-addr. arpa в четыре других домена, по 64 численных имени в каждом • Когда удаленный сервер запрашивает PTR-запись для 52. 30. 168. 192. in-addr. arpa, он получает уведомление, что каноническое имя этого узла 52. 1 st 64. 30. 168. 192. in-addr. arpa. • Директива фактически разделяет один домен 30. 168. 192. in-addr. arpa на ряд доменов • После разделения каждый из фрагментов может быть делегирован произвольному серверу имен • Делегирование поддоменов может осложнить работу с обратными доменами • Однако, в большинстве случаев файл обратной зоны проще, чем файл прямого отображения зоны

66/132 Файл прямого отображения зоны • Содержит большую часть доменной информации • Обеспечивает преобразование имен узлов в IP-адреса • Поэтому содержит преимущественно А-записи, но также и записи типов MX, CNAME и других • Как и файл обратной зоны, создается только для основного сервера имен • Все прочие серверы получают информацию от него • Подобно файлу обратной зоны начинается с записи SOA и нескольких записей NS, которые определяют домен и сервер домена • Содержит более представительный набор RR-записей

67/132 Файл прямого отображения зоны • Первая МХ-запись – Обозначает узел serv в качестве почтового сервера домена os. vniins со значением приоритета 10 – Почтовые сообщения с адресом вида user@os. vniins передаются узлу serv для доставки – Успешная доставка почты узлом serv подразумевает его настройку в качестве почтового сервера – Запись MX только часть процесса настройки • Вторая запись MX – Обозначает узел edu. os. vniins в качестве почтового сервера домена os. vniins со значением приоритета 20 – Значения приоритета позволяют создавать указатели на альтернативные почтовые серверы – Чем ниже приоритет, тем более предпочтителен почтовый сервер – Если основной сервер почты недоступен, почта доставляется через альтернативный

68/132 Файл прямого отображения зоны • Приведенные МХ-записи осуществляют перенаправление почты, адресованной в домен os. vniins • Однако почта для user@vlad. os. vniins будет направлена напрямую узлу vlad. os. vniins • Данный вариант настройки позволяет направлять почту напрямую отдельным узлам • Первая А-запись определяет адрес узла localhost, выполняя задачу, противоположную той, что возложена на соответствующую запись PTR из файла named. local • Адресная запись позволяет пользователям домена os. vniins набрать имя localhost и получить доступ к системе по адресу 127. 0. 0. 1 через систему доменных имен

69/132 Файл прямого отображения зоны • Следующая А-запись определяет IP-адрес узла serv, который является основным сервером домена • За этой адресной записью следует запись CNAME, определяющая имя loghost в качестве псевдонима узла serv • За адресной записью узла vlad следует МХ-запись и CNAMEзапись • МХ-запись направляет всю почту, адресованную user@vlad. os. vniins, на узел serv • Наличие этой записи объясняется тем, что первая МХ-запись перенаправляет всю почту в том случае, если она адресована user@os. vniins

70/132 Файл прямого отображения зоны • Поле имени CNAME-записи содержит псевдоним официального имени узла • Каноническое имя содержится в поле данных этой записи • Приведенные CNAME-записи позволяют обращаться к узлу serv по имени loghost, а к узлу vlad — по имени mouse • Псевдоним loghost — обобщенное имя узла, позволяющее направлять вывод демона syslogd узлу serv • Псевдонимы узлов не следует использовать в других RRзаписях • Файл зоны можетт быть гораздо больше, чем данный, но будет содержать в большинстве случаев подобные записи • Если доступны имена и адреса узлов домена, администратор уже обладает достаточным объемом информации для создания файлов настройки named

71/132 Управление процессом named • После создания файла named. conf и необходимых файлов зон процесс может быть запущен • named обычно запускается в процессе загрузки системы из загрузочного сценария /etc/rc. d/init. d/named. • Загрузочный сценарий, как обычно, может выполнятся с помощью команды service named с параметрами start, stop, status и тому подобными • Более эффективным средством управления сервером DNS является программа ndc в составе пакета BIND 8 или rndc в составе BIND 9 • При первом запуске named администратору следует обращать внимание на сообщения об ошибках, которые процесс заносит в файл /var/log/messages • Как только сервер заработает, нужно воспользоваться программой nslookup, чтобы обратиться к серверу и убедиться, что он предоставляет корректные сведения

72/132 Параметры программы ndc status Отображает состояние серверного процесса named dumpdb Записывает образ кэша в файл nameddump. db reload Перезагружает сервер имен stats Записывает статистику в файл named. stats trace Включает запись отладочной информации в файл named. run notrace Отключает запись отладочной информации в файл named. run Переключает регистрацию запросов. При включенной querylog регистрации запросов поступающие запросы фиксируются посредством демона syslogd start Запускает named stop Останавливает named restart Останавливает текущий процесс named и запускает новый

73/132 2. 3 Клиентские программы системы имен • nslookup — это инструмент отладки, который входит в состав пакета BIND • Программа позволяет пользователю напрямую обращаться к серверу имен с запросами и получать любую информацию, хранимую в распределенной базе данных DNS • Команда nslookup позволяет определить факт работоспособности сервера и корректировать его настройки, а также запросить информацию, которой владеют удаленные серверы • Программа позволяет выполнять запросы в диалоговом режиме либо при помощи параметров командной строки • Однако чаще всего nslookup используется в интерактивном режиме • Чтобы приступить к работе в диалоговом режиме, необходимо выполнить команду nslookup без аргументов • Завершается диалоговый сеанс с помощью горячих клавиш Ctrl+D или набором exit в приглашении nslookup

74/132 Программа nslookup • nslookup позволяет: – Запрашивать RR-записи любого из стандартных типов – Напрямую обращаться к компетентным серверам доменов – Записывать содержимое файла зоны в локальный файл для анализа – Для получения информации о других возможностях программы, следует воспользоваться командой help в приглашении nslookup • По умолчанию выполняет запрос А-записей • При помощи команды set type можно запросить любой тип записей, либо выполнить специальный запрос с типом ANY – ANY позволяет получить все доступные RR-записи для конкретного узла • При помощи команды server можно изменить сервер, к которому обращены запросы – Особенно полезно в случае необходимости обратиться за информацией непосредственно к компетентному серверу

75/132 3 Протокол и сервер DHCP 3. 1 Протоколы начальной инициализации хостов • Протокол начальной инициализации ВООТР (Bootstrap Protocol) – первый протокол всесторонней настройки • ВООТР предоставляет всю информацию, обычно необходимую для настройки TCP/IP, начиная с адреса IP-клиента и заканчивая сервером печати • ВООТР простой и эффективный протокол • Положен в основу протокола динамической настройки узлов DHCP (Dynamic Host Configuration Protocol) • DHCP работает через те же порты, что и ВООТР – 67 и 68 UDP-порты • Этот протокол обладает всеми возможностями ВООТР и имеет ряд важных расширений

76/132 Главные особенности DHCP • Обратная совместимость с протоколом инициализации ВООТР – Сервер DHCP способен поддерживать клиентов ВООТР • Полноценная настройка – Сервер DHCP предоставляет клиентам полный набор параметров настройки TCP/IP – Администратор получает возможность управлять всеми настройками пользователей • Динамическое назначение адресов – Сервер DHCP позволяет выделять постоянные адреса вручную либо автоматически, а временные адреса — динамически – Администратор сети выбирает механизм назначения адресов, исходя из нужд сети и систем клиентов • В операционных системах ВНИИНС используются серверы dhcpd версии 3. 0

77/132 3. 2 Настройка сервера DHCP файл dhcpd. conf • Настройки dhcpd хранятся в файле /etc/dhcpd. conf • Файл настройки содержит инструкции, которые определяют, какие подсети и узлы обслуживает сервер и какую информацию настройки он им предоставляет • dhcpd. conf — обычный текстовый файл, сходный по форме с файлом исходного текста на языке С • Все строки, начинающиеся символом решетки, являются комментариями • Конструкция каждой строки есть реализация шаблона параметр — значение • Параметр может быть общим, или предваряться ключевым словом option • Параметры, следующие за словом option — это ключи настройки • Они также состоят из имени ключа и его значения • Имена параметров и ключей имеют описательный характер, поэтому об их назначении легко догадаться

78/132 Файл dhcpd. conf • Кроме общих параметров существуют еще так называемые операторы топологии сети • Иногда в документации такие операторы называются «объявлениями» , поскольку декларируют определенные факты, относящиеся к топологии сети • Каждый из операторов топологии может многократно встречаться в файле настройки • Операторы определяют иерархическую структуру, sharednetwork содержит подсети, а подсети включают хосты • Настройка сервера DHCP, обычно сводящаяся к редактированию файла конфигурации, редко вызывает сложности • Запуск сервера можно осуществить с помощью команды services dhcpd start или включить одним из известных способов в список служб, запускаемых при старте системы • Пример файла dhcpd. conf и описание параметров и ключей рассмотрим на групповом занятии

79/132 4 Сетевая файловая система NFS 4. 1 Возможности и ограничения NFS • NFS предназначена для прозрачного доступа к удаленным файлам на уровне записей (без необходимости копирования всего файла по сети) – В идеальном случае пользователь даже не обязан знать, где именно в сети и на каком сервере файлы хранятся • NFS может использоваться только для обработки несекретной информации или для загрузки по сети ОС на бездисковые рабочие станции • NFS основана на технологии Sun RPC – обеспечиваются условия, при которых вызов удаленной процедуры выглядит с точки зрения пользователя как вызов локальной процедуры (в данном случае — файловой операции) • Такая прозрачность доступа к удаленным файловым системам является как достоинством (простота использования и настройки), так и недостатком (небезопасная архитектура в плане возможных злонамеренных действий)

80/132 Возможности и ограничения NFS • NFS (как и другие службы Sun RPC) использует перенаправление портов с помощью редиректора портов portmap • Доступ к порту 111, который слушает portmap, можно ограничить посредством TCP_Wrappers • Для этого необходимо в файле /etc/hosts. deny задать запись вида – portmap : ALL • Это означает запрет доступа к порту 111 всем клиентам, кроме тех, кто описан в файле /etc/hosts. allow с помощью записей вида – portmap : 192. 168. 1 (разрешить доступ из сети 192. 168. 1. 0/24) • Таким образом, для запуска на сервере NFS, необходимо: – Запустить сервер NFS – Запустить демон, ожидающий запросы монтирования от удаленных систем (грс. mountd) – Запустить службу portmap – Настроить доступ к публичным каталогам

81/132 Возможности и ограничения NFS • При распределенном хранении файлов имеется как минимум 2 файла, отвечающих за отображение имен пользователей – /etc/passwd на сервере NFS – /etc/passwd на клиентской машине • Возможны два случая – Пользователь является владельцем каких-либо файлов на сервере NFS (он обязан иметь учетную запись на сервере и возникает задача глобальной синхронизации UID и GID пользователей в масштабе всей локальной сети ) – Пользователь не имеет собственно своих файлов на сервере (учетная запись пользователя на сервере не обязательна) • Администратор сети должен согласовать идентификаторы пользователей на локальных машинах и файловых серверах – Синхронизировать UID можно вручную или с помощью файла соответствий идентификаторов – При этом серверу NFS нужно указать положение этого файла и задать соответствующую опцию в файле настройки сервера

82/132 4. 2 Настройка доступа к публичным каталогам (файл /etc/exports) • Для управления сервером NFS используется файл /etc/exports • В этом файле содержится набор записей, каждая из которых определяет экспортируемый каталог • Запись занимает одну строку и имеет следующий формат: каталог клиент1(опции)[клиент2(опции)][клиент3(опции)][. . . ] • Имя экспортируемого каталога может иметь вид /home или /pub • В принципе, можно экспортировать любой каталог, однако выкладывать такие каталоги, как /etc, /ргос бессмысленно и небезопасно • При описании каталогов указываются отдельные клиенты или группы клиентов

83/132 Способы задания записей для клиентов NFS Вид Описание идентификатора Идентификатор Если задать только список опций, помещенный в отсутствует скобки, доступ к каталогу получит любой клиент. Такая конфигурация исключительно небезопасна и может применяться только в специальных случаях. vlad. edu. vniins Имя одного компьютера, указанное в качестве клиента, дает возможность процессам этого компьютера обратиться к каталогу. Если имя домена не указано, предполагается, что хост имеет тот же домен, что и сервер. *. edu. vniins или ? ? ? . edu. vniins Первый идентификатор описывает все компьютеры домена edu. vniins, второй — все компьютеры этого домена, имена которых состоят из трех символов. Звездочка не заменяет точку, поэтому первый идентификатор не описывает хосты поддоменов. 172. 19. 0. 1/16 IP-адрес одного хоста, доступ получит этот хост. Сеть класса В. Доступ получат все машины сети.

84/132 Способы задания записей для клиентов NFS • С точки зрения безопасности клиентов лучше описывать с использованием IP-адресов • В случае подмены записей DNS имена могут быть переопределены злоумышленником • С другой стороны, использование IP-адресов может быть неудобным в случае частой смены адресов • Для каждого клиента или группы клиентов можно задать набор опций • Эти опции помещаются в скобки и отделяются друг от друга запятыми без пробелов • После идентификатора клиента также нет пробела

85/132 Опции файла /etc/exports Опция sync или async Описание Синхронный или асинхронный режим выполнения операций. При записи в асинхронном режиме сервер может сообщить клиенту, что запись произведена, в то время, как она еще продолжается. Ускоряет работу, но создает угрозу потери данных в результате внезапного разрыва связи. wdelay или no_wdelay secure или unsecure го или rw Кэширование процедуры записи сервером, если алгоритм предполагает возможное изменение данных при последующих запросах (wdelay, по умолчанию). unsecure разрешает доступ с портов с номерами выше 1024. Используется для отладки клиентских программ. Соответственно, каталог только для чтения или для чтения-записи. hide или nohide Скрывать или не скрывать подкаталоги экспортированного каталога. noaccess Запрещает доступ к каталогу. Используется для запрещения доступа к подкаталогам экспортированного каталога. По умолчанию сервер NFS отвергает обращения от пользователя root (rootsquash). В некоторых случаях, например, при удаленной загрузке операционной системы на бездисковые станции или при создании резервных копий такой доступ надо разрешить (no_root_squash). root_squash или no_root_squash anonuid и anongid Анонимным пользователем, обращения которого отвергаются, обычно считается nobody. Эту установку можно переопределить, указав идентификатор пользователя или группы. В этом случае пользователю root на удаленном компьютере будет предоставлен доступ с привилегиями указанного пользователя. Синтаксис опции: anonuid=504.

86/132 Пример файла /etc/exports • В данном примере экспортируется каталог /home по следующим правилам – Доступ хостов из домена edu. vniins производится с правами чтения-записи, причем изменения производятся немедленно – Хосты из сегмента сети класса В с сетевым адресом 192. 168. имеют право только на чтение – Доступа к подкаталогу /home/secure не имеет никто из клиентов • Для того, чтобы экспортировать описанные каталоги в текущей сессии, надо отдать команду: exportfs -а, которая экспортирует все каталоги, переписывая их листинг • Он хранится в каталоге /var/lib/nfs, в файле, имя которого зависит от конкретной системы • Этот листинг читается вспомогательным демоном mountd при каждом запуске службы NFS

87/132 4. 3 Средства синхронизации идентификаторов пользователей на стороне сервера • Фактически существует два основных способа синхронизировать UID и GID пользователей на клиентских машинах и серверах NFS – Ручная работа администратора в масштабе всей локальной сети, что бывает не очень удобно при большом количестве учетных записей на каждой клиентской машине – Файл синхронизации на сервере • Чтобы согласовать идентификаторы пользователей и групп на клиентской машине и сервере, на сервере создается специальный файл, в котором описываются соответствия идентификаторов • Затем на этот файл надо сослаться в опциях экспортируемого каталога, указав в качестве клиента нужный хост • Основное возникающее при этом способе неудобство – Файлов соответствий будет столько, сколько хостов-клиентов – Записей в файле /etc/exports также будет столько, сколько хостов-клиентов

88/132 Примеры файлов /etc/exports • Запись опции-ссылки на файл соответствий в файле /etc/exports • В данном случае опция map_static ссылается на файл /etc/nfs/vlad-map, в котором содержатся пары UID для пользователей данного хоста соответственно их UID на сервере • Содержимое файла

89/132 Способы задания записей для клиентов NFS • В таком файле необходимо задать идентификаторы всех пользователей – Например, в примере указан UID 501, который отображается в тот же идентификатор на сервере – Отсутствующий UID приведет к некорректному отображению и станет источником проблем – В примере также явным образом указано, что попытки обращений процессов с UID меньше 100 должны отвергаться – Аналогичное правило задано для идентификаторов групп • Как и в случае синхронизации вручную, имена пользователей и групп на клиенте и сервере могут различаться • Как видно из примера, имена в файле соответствий отсутствуют • Несмотря на то, что данная ситуация не мешает нормальной работе, во избежание путаницы желательно все же согласовать имена пользователей в масштабе всей локальной сети

90/132 4. 4 Запуск NFS • После того, как экспортированные каталоги описаны в файле /etc/exports и перезаписана таблица доступных каталогов с помощью команды exportfs, можно запустить сервис NFS • Поскольку службы NFS основаны на технологии Sun RPC, для работы необходим запуск редиректора портов portmap • Все служебные процессы NFS запускаются вместе с сервером nfsd, portmap нужно запускать отдельно • Если имеется ввиду запускать сервер NFS при каждом старте машины, следует сделать соответствующие настройки с помощью утилит ntsysv или chkconfig • При запуске сервиса NFS стартуют также следующие службы – – – Демон квот NFS rpc. quotad Несколько экземпляров демона nfsd Служба блокировки открытых файлов lockd Демон ввода-вывода программ RPC - rpciod Демон удаленного монтирования грс. mountd

91/132 Запуск NFS • Если по каким-либо причинам необходимо запускать демон nfsd из командной строки или из служебных скриптов, ему можно передать два параметра с помощью опций – Опция -р указывает демону слушать порт, отличный от порта по умолчанию (2049) – Опция nproc передает количество экземпляров процесса nfsd, запускаемых при старте • Собственного конфигурационного файла кроме /etc/exports у nfsd нет • Сервисы NFS и portmap имеют стартовые скрипты, поэтому запуск служб NFS сводится к вводу двух команд: которые и запустят все необходимые процессы

92/132 4. 5 NFS со стороны клиента • На стороне клиента экспортируемые каталоги выглядят как разделы диска • Для их монтирования используется команда mount, при ее вызове указывается сервер NFS и монтируемый каталог • Эти данные задаются в формате сервер: путь_к_каталогу • Если точно неизвестно, какие каталоги экспортированы, можно воспользоваться утилитой showmount, которая показывает все каталоги NFS на удаленной машине • Введя вышеуказанную команду для проверки работы служб NFS на своей локальной машине, увидим примерно такой вывод, как в примере • Он означает, что на своем сервере NFS мы отредактировали файл /etc/exports следующим образом: /tmp/1 (ro) • то есть доступ к монтированию каталога /tmp/1 разрешен всем пользователям только для чтения

93/132 NFS со стороны клиента • Чтобы смонтировать удаленный каталог в своей файловой системе, надо выполнить команду mount подобно приведенной ниже: # mount serv. edu. vniins: /tmp/l /mnt/nfs-serv • Она задает монтирование каталога /tmp/1, расположенного на сервере, в точку монтирования на локальной машине (каталог /mnt/nfs-serv, перед монтированием точка монтирования должна существовать) • Далее с ресурсом NFS можно работать, как с локальным каталогом • Если требуется монтирование удаленных каталогов при запуске системы, необходимо внести соответствующую запись в файл /etc/fstab • Она может выглядеть примерно таким образом: serv. edu. vniins: /tmp/l /mnt/nfs-serv nfs defaults 0 0 • Вместо ключевого слова defaults в столбце опций монтирования можно указать специфические для монтирования каталогов NFS опции

94/132 Опции монтирования экспортированных каталогов файловой системы NFS Опция hard Описание Если сервер выходит из строя или не отвечает на запросы, программа, которая пытается обратиться к нему будет ожидать ответа неопределенно долго. Это поведение системы по умолчанию. soft Если сервер NFS часто становится недоступным, целесообразно использовать данную опцию. Она позволяет ядру возвращать программе сообщение об ошибке в том случае, если сервер не отвечает в течение установленного времени. nodev Данная опция предотвращает попытки клиента использовать файлы символьных и блочных устройств, находящихся в составе экспортируемых каталогов. Снижает риск использования файлов устройств для сетевых атак. nosuid Эта опция не позволяет клиенту обрабатывать бит SUID в файлах, находящихся в экспортируемых каталогах. Эта опция предотвращает обработку клиентом признака исполняемых файлов и пользователь не может запускать программы в составе экспортируемых каталогов. noexec • • Эти опции, а также другие стандартные опции команды mount дают в руки администратора гибкие инструменты управления поведением серверов и пользователей Все опции из таблицы могут быть также указаны в составе командной строки mount после ключа -о

95/132 5 Защищенная сетевая файловая система Samba 5. 1 Назначение и возможности • Задача прозрачного совместного доступа к файлам в защищенных специализированных средах имеет свои особенности – Если выполняется требование поддержания мандатных меток уровней и категорий для всех объектов файловой системы, должен существовать механизм, позволяющий передать эту информацию при доступе к файлам по сети • Для организации файл-серверов с поддержкой механизмов защиты ОС МСВС 3. 0 предназначена сетевая защищенная файловая система (СЗФС) – В основу СЗФС положена сетевая файловая система Samba (SMBFS), работающая по протоколу SMB – Построена как расширение файловой системы SMBFS – Предоставляет обратную совместимость обычным SMBклиентам, работающим с ней как с файловой системой SMB – Протокол СЗФС содержит в себе сообщения, которые передают информацию о стандартных и расширенных атрибутах (атрибутах безопасности), а также сообщения для передачи мандатной метки субъекта доступа

96/132 Защищенная сетевая файловая система • Условием корректного функционирования СЗФС является единое пространство пользователей • Оно обеспечивает в рамках данной сети однозначное соответствие между логическим именем пользователя и его идентификатором (а также именем группы и ее идентификатором) на всех компьютерах (рабочих станциях и серверах), на которых данный пользователь может работать • Иначе говоря, для корректной работы СЗФС необходима синхронизация UID/GID пользователей в системах клиента и сервера, так как информация о пользователях и группах передается в сеть в численных значениях • СЗФС состоит из сервера и клиента • Сервер представляет собой расширенный сервер Samba и выполняет следующие задачи – Управление разделяемыми ресурсами – Контроль доступа к разделяемым ресурсам

97/132 Защищенная сетевая файловая система • При подключении клиента сервер устанавливает классификационную метку процесса, обслуживающего запросы клиента, в соответствии с классификационной меткой этого клиента • Этим обеспечивается мандатный контроль доступа к разделяемым файлам на стороне сервера • Клиент представляет собой сетевую файловую систему в составе системы управления файлами ядра сетевой защищенной операционной системы (СЗОС) и реализует интерфейс между виртуальной файловой системой ядра СЗОС и сервером СЗФС • Клиент СЗФС выполняет следующие задачи: – Отображение каталогов и файлов смонтированного сетевого ресурса – Передача на сервер дополнительной информации о классификационной метке пользователя (процесса), работающего с разделяемым ресурсом

98/132 Защищенная сетевая файловая система • С точки зрения пользователя СЗФС выглядит как стандартная файловая система, поддерживающая все механизмы защиты СЗОС и позволяющая работать с удаленной файловой системой с помощью стандартных утилит • С точки зрения администратора управление СЗФС практически не отличается от администрирования SMBFS в других Linux-системах, однако администратору необходимо учитывать следующее – Установка флагов аудита на файлах СЗФС приводит к тому, что аудит выполняется как на сервере, так и на клиенте – На сервере аудит выполняется от имени сервера, на клиенте — от имени субъекта доступа – Проверка контроля доступа к файлам осуществляется как на клиенте, так и на сервере, поэтому повышение полномочий клиента не приводит к получению доступа к файлам уже смонтированной файловой системы – Проще говоря, для корректной работы СЗФС необходимо выполнять операцию монтирования от имени и с атрибутами того пользователя, который и будет работать с файловой системой

99/132 Защищенная сетевая файловая система • Для того, что бы обычный пользователь мог смонтировать и размонтировать файловую систему командой mount (или при помощи графической утилиты монтирования elk-esa-smb), строка о ресурсе должна присутствовать в системном файле /etc/fstab с параметром user (или users) • Для удаленного управления файлами администратор может смонтировать файловую систему от своего имени и далее производить действия над атрибутами безопасности обычным образом (с помощью команд chmac, setfaud и др. ) • Из-за наличия в СЗФС кэша запросов, при изменении расширенных атрибутов непосредственно на сервере, имеется задержка по доставке изменений на клиентскую машину. Задержка не превышает минуты. • СЗФС предоставляет следующие базовые возможности: – Разделение файловых систем ОС МСВС 3. 0 операционными системами Windows 95, Windows 98 и Windows NT и наоборот – Совместное использование принтеров, подключенных к системе ОС МСВС 3. 0, операционными системами Windows 95, Windows 98 и Windows NT и наоборот

100/132 5. 2 Состав СЗФС • Сервисная служба smbd обеспечивает работу службы печати и разделения файлов для клиентов, таких как Windows для рабочих групп, Windows NT и Lan. Manager. – Конфигурационные параметры сервисной службы smbd описываются в файле smb. conf • Сервисная служба nmbd обеспечивает работу службы имен Net. BIOS, а также может использоваться для запроса других сервисных служб имен • Служба smbclient реализует простейший клиент, который может использоваться для доступа к другим серверам и для печати на принтерах, подключенных к серверам

101/132 Состав СЗФС • Утилиты для управления Samba-пользователями smbadduser и smbpasswd – Эти пользователи заводятся администратором файлового сервера, но не имеют в системе домашнего каталога и доступа к командному интерпретатору • Утилита testparm позволяет протестировать конфигурационный файл smb. conf • Утилита smbstatus сообщает, кто в настоящее время пользуется сервером smbd • Помимо этого, в составе ОС МСВС 3. 0 находится графическая утилита elk-esa-smb, которая устанавливается по умолчанию и позволяет настроить пользовательский доступ к ресурсам СЗФС в системе графического интерфейса

102/132 5. 3 Настройка сервера СЗФС • СЗФС устанавливается одновременно с ОС МСВС 3. 0 или впоследствии с использованием RPM • Настройка СЗФС в ОС МСВС 3. 0 осуществляется посредством настройки параметров главного конфигурационного файла • Главный конфигурационный файл называется smb. conf и находится в каталоге /etc • Файл smb. conf состоит из именованных разделов, начинающихся с имени раздела в квадратных скобках (например, с [global]) • Внутри каждого раздела находится ряд параметров в виде «key = value» • Файл конфигурации содержит три специальных раздела: [global], [homes] и [printers] и несколько пользовательских разделов

103/132 Конфигурационный файл smb. conf • В разделе [global] описаны параметры, управляющие сервером smb в целом, а также находятся значения параметров по умолчанию для других разделов • Раздел [homes] позволяет пользователям подключаться к рабочим каталогам пользователей без их явного описания – При запросе клиентом определенной службы сервер ищет соответствующее ей описание в файле и, если такового нет, просматривает раздел [homes] – Если этот раздел существует, сервер просматривает файл паролей для поиска рабочего каталога пользователя, сделавшего запрос, и, найдя его, делает его доступным по сети • В разделе [printers] описаны параметры управления печатью при отсутствии иного явного описания – Раздел [printers] используется для предоставления доступа к принтерам, определенным в файле /etc/printcap • После настройки параметров сервера по умолчанию можно создать разделяемые каталоги, доступ к которым могут получать определенные пользователи, группы пользователей или все пользователи

104/132 Конфигурационный файл smb. conf • После создания конфигурационного файла необходимо протестировать его корректность при помощи утилиты testparm • Программа testparm проверяет наличие в файле /etc/smb. conf внутренних противоречий и несоответствий • Если программа не обнаружила ошибок, то можно надеяться, что при запуске smbd конфигурационный файл будет загружен без проблем • Применение testparm не дает гарантии, что все сервисы и ресурсы, описанные в конфигурации, доступны и будут корректно работать • Синтаксис утилиты следующий: testparm [configfile [hostname hostip]] – Параметр «configfile» определяет местоположение конфигурационного файла (если это не файл /etc/smb. conf) – Параметр «hostname hostip» указывает программе testparm проверить доступ к сервисам со стороны узла, определяемого параметром

105/132 Конфигурационный файл smb. conf • Если ошибки не будут обнаружены, на экране появится примерно следующее сообщение (в случае обнаружения ошибок о них будет предоставлена полная информация): • После нажатия testparm протестирует каждый раздел, определенный в конфигурационном файле

106/132 5. 4 Запуск сервера. Доступ к серверу СЗФС • Сервер состоит из двух сервисных программ – smbd обеспечивает работу службы разделения файлов и принтеров – nmbd поддерживает имена Net. BIOS • Сервер запускается либо из инициализирующих сценариев, либо из xinetd в качестве системного сервиса • Если сервер запускается из сценариев инициализации, для запуска и остановки работы сервера можно воспользоваться командой: /etc/rc. d/init. d/smb start: stop или service smb startstop • Доступ пользователей к ресурсам сервера осуществляется с помощью программы smbclient • Другой возможностью является использование графической утилиты elk-esa-smb

107/132 Запуск сервера. Доступ к серверу СЗФС • Опции командной строки smbclient позволяют сделать запрос о разделяемых ресурсах или перенести файлы – Например, для запроса списка доступных ресурсов на удаленном сервере win. edu. vniins используется командная строка: • smbclient -L -I win. edu. vniins – Здесь опция -L указывает, что требуется вывести список разделяемых ресурсов, а опция -I - что указанное далее имя следует рассматривать как имя DNS, а не Net. BIOS. • Для пересылки файла необходимо сначала подключиться к серверу с использованием команды: smbclient '\WORKGR 1PUBLIC'-I file-serv. os. vniins -U vlad – Параметр '\WORKGR 1PUBLIC' определяет удаленный сервис на другой машине (обычно это каталог файловой системы или принтер) – Опция -U позволяет определить имя пользователя для подключения к ресурсу (если необходимо, СЗФС запросит соответствующий пароль) • После подключения перед вами будет приглашение: smb: где «» означает текущий рабочий каталог. • В этой командной строке можно указать любые команды для передачи файлов и работы с ними

108/132 Команды пользователя Команда ? , help Параметры [команда] Описание Вывод справки (общей или по использованию конкретной команды). ! [команда оболочки] cd [каталог] Выполнение команды оболочки или временный выход в приглашение командной оболочки. Переход в определенный каталог на удаленной машине. Если каталог не указан, выводится текущий каталог. led [каталог] Переход в определенный каталог на локальной машине. Если каталог не указан, выводится текущий каталог. del [файлы] Удаление определенных файлов, если права доступа позволяют это сделать. Разрешается использование шаблонов. dir, Is exit, quit get [файлы] Нет [удаленный файл] [локальное имя] Вывод списка файлов в текущем каталоге. Выход из программы smbclient. Копирование удаленного файла на локальную машину. Если указано локальное имя, оно будет использовано при сохранении файла. mget [файлы] md, mdir rd, rmdir put [каталог] [файл] mput [файлы] print [файлы] Копирование указанных файлов (допускается использование шаблонов) на локальную ЭВМ. Создание каталога на удаленном сервере. Удаление каталога на удаленном сервере. Копирование определенного файла с локального компьютера на удаленный. Копирование всех указанных файлов с локального компьютера на удаленный. Печать определенного файла на удаленной машине. queue Нет Вывод списка заданий в очереди на удаленном сервере на печать.

109/132 Монтирование удаленной файловой системы на сервере СЗФС • Удаленную файловую систему на сервере СЗФС можно смонтировать на локальную файловую систему с помощью утилиты smbmount • В этом случае она будет видна в точке монтирования в любом файловом менеджере • С ней можно будет совершать файловые операции прозрачно, также, как и на локальной файловой системе • Перед выключением компьютера СЗФС должна быть отмонтирована вручную с помощью команды smbumount

110/132 5. 5 Пользователи Samba-СЗФС • Для большей безопасности файлового сервера с каталогами общего доступа по протоколу Samba-СЗФС, можно завести на сервере пользователей, которые не будут иметь доступа к командному интерпретатору • В общем случае, в таком режиме должны работать все пользователи, имеющие доступ к файловому серверу по протоколу Samba-СЗФС, то есть они не должны иметь прав локального входа • Для заведения учетных записей на таких пользователей используются стандартные средства операционной системы • При этом администратору необходимо лишить их домашнего каталога и командного интерпретатора • Также необходимо помнить, что UID пользователей на локальных машинах и на сервере должны совпадать • Это совпадение не обеспечивается никакими автоматическими средствами и должно гарантироваться администратором сети (похожая проблема имеется в использовании сетевой файловой системы NFS)

111/132 Пользователи Samba-СЗФС • После создания пользователей с ограниченными правами им надо задать пароли Samba – Это действие выполняет команда smbpasswd с ключом -а • Далее, если клиент использует smbclient, взаимодействие прозрачно и похоже на работу в консольном FTP • Если пользователь желает подмонтировать сетевой ресурс в локальную точку монтирования (в fstab должна быть соответствующая запись с опцией user), используя smbmount, тогда его права на доступ к файлам и каталогам будут проверятся в соответствии с мандатной моделью – Здесь не существует понятия «сетевая сессия» или «соединение» – Права пользователя проверяются всякий раз при запросе файловой операции – Если пользователь в течение своего локального сеанса изменит мандатные атрибуты в рамках своих диапазонов мандатных меток, его мандатные права на доступ к каталогам и файлам изменятся динамически – Они проверяются всякий раз при попытке доступа к файлам и каталогам

112/132 6 Сервер FTP • В ОС МСВС 3. 0 используются серверы WU-FTPD и vs. FTPd – vs. FTPd является более безопасной альтернативой и рекомендуется к использованию • В целях повышения безопасности администраторы используют следующие возможности: – Ограничение пользователей FTP-сервиса поддеревом каталогов, выделенным для этой цели – Настройка сервера только для загрузки файлов пользователями на локальные машины с сервера – Запрет для загрузки на сервер файлов в ASCII-формате, если пользователи имеют право копировать файлы на сервер – Анонимный FTP, не требующий передачи паролей по сети в открытом виде • Все зарегистрированные пользователи системы могут обращаться по сети к файлам и каталогам через протокол FTP, при этом получая те же права, как если бы они зарегистрировались локально – Для посторонних посетителей зарезервировано имя anonymous – Права анонимного пользователя регулируются опциями файла конфигурации

113/132 Сервер FTP • Через клиентскую утилиту ftp пользователь получает доступ к урезанному командному интерпретатору, синтаксис команд которого сходен с синтаксисом команд оболочки – Например, для просмотра содержимого каталога используется команда ls, для изменения прав доступа — chmod, и так далее – Список команд ограничен и может быть получен по команде help в приглашении ftp>, доступном после авторизации на сервере • Клиент FTP часто встраивают в различные приложения типа файловых менеджеров, в том числе и в Windows-приложениях

114/132 Сервер FTP • Протокол прикладного уровня FTP работает поверх протокола TCP, причем FTP создает два соединения: – по порту 20 для передачи данных – и по порту 21 для передачи команд • Конфигурационный файл сервера /etc/vsftp. conf задает множество опций • Настройка набора опций для конкретных задач, выполняемых сервером, может приводить к конфигурированию более защищенной или менее защищенной среды • Для контроля событий существуют опции, заведующие ведением журналов событий FTP

115/132 6. 2 Исполняемые файлы • Для работы FTP-сервера необходимы пакеты vsftpd и anonftp • Для активизации сервера при работе через xinetd необходимо активизировать вызов сервера, установив значение строки disable в по в файле /etc/xinetd. d/vsftpd • Запустить, остановить, перезапустить или возвратить статус сервера vsftpd можно командой: service vsftpd start (или, соответственно, stop, restart, status), или командой: /etc/init. d/xinetd start • Протестировать работу сервера можно, зайдя на запущенный сервер на своей машине • После вызова сервера FTP выводится приглашение, в котором надо ввести имя пользователя (зарегистрированного, или anonymous), и, в качестве пароля, пароль или адрес электронной почты для анонимного пользователя • Исполняемый файл сервера при запуске принимает единственную опцию — имя конфигурационного файла (по умолчанию — /etc/vsftp. conf)

116/132 6. 3 Конфигурационный файл • Конфигурационный файл /etc/vsftp. conf содержит множество заготовок опций, которые включаются путем удаления комментариев в начале строк. • По умолчанию конфигурация настроена на допуск к ресурсам FTP пользователей, имеющих на данной машине учетные записи, по паролю – Что не очень хорошо с точки зрения безопасности • Опции даются в нотации опция = значение • В большинстве случаев большая часть опций не является необходимой – Например, структура файла /etc/vsftp. conf по умолчанию такова, что допускает использование ресурсов FTP пользователям, имеющим локальный аккаунт, по логину и паролю

117/132 Конфигурационный файл • Можно создать набор опций, допускающих использование логина anonymous • Все анонимные пользователи могут писать в каталоги дерева FTP, удалять свои и чужие файлы, то есть имеют практически неограниченные права на файловое хранилище • Такие настройки оправданы, когда в доверенной локальной сети, не использующей модели внутреннего нарушителя, FTP-хранилище используется как средство временного хранения и быстрого обмена данными большого объема • Все остальные опции автоматически устанавливаются в значения по умолчанию • Файл-пример, который имеется в системе после ее инсталляции, содержит множество заготовок опций • Изучение комментариев к ним позволит быстро разобраться в значениях тех или иных строк и производимых ими настройках работы сервера FTP

118/132 7 Система единого времени • Для множества жизненных задач клиентам в сетях требуется знать точное время – Как правило, встроенные в компьютеры аппаратные таймеры работают не точно и погрешности их различны в различных системах • Временные серверы – Специальные программы, разработанные для того, чтобы избавить администраторов и пользователей от ручной работы по синхронизации локальных часов с какими-либо источниками точного времени – Эти программы предоставляют клиентам сведения о точном времени – Чтобы иметь точное время на всех машинах сети достаточно сконфигурировать один сервер точного времени и на всех машинах настроить клиентские программы, способные синхронизировать локальные часы с серверными данными о точном времени • Временной сервер сети может синхронизироваться со внешним временным сервером, получающим данные от эталонных источников времени

119/132 Система единого времени • Из-за особенностей процедур синхронизации, клиентские машины могут получать лишь приближение к точному времени, то есть время, близкое к эталонному • Практически это означает, что время клиентов будет отличаться от серверного на несколько тысячных секунды • Работа программы, отвечающей за предоставление и получение данных о точном времени отличается от других клиент-серверных приложений • В зависимости от ранга временного сервера, к которому обращается сервис точного времени, он может быть или сервером, или клиентом • Для минимизации резидентной нагрузки на клиентские системы на многих из них устанавливают более простые программы, являющиеся только клиентами • Чтобы текущее локальное время оставалось актуальным, необходимо вручную или с помощью планировщиков заданий периодически запускать эти программы для получения точного времени

120/132 Система единого времени • Из протоколов прикладного уровня, обеспечивающих работу временных серверов, наиболее популярным является NTP (Network Time Protocol — сетевой протокол времени) • Чтобы настроить сервер NTP, например, в ОС МСВС 3. 0, необходимо отредактировать всего один конфигурационный файл • Контроль за действиями сервера осуществляется с помощью специальных утилит • На компьютерах, находящихся на самом нижнем уровне иерархии, могут быть запущены простые клиенты точного времени • Работа временного сервера начинается с получения сведений о времени из официальных источников • Эти сведения получаются путем считывания показаний атомных часов, приема специальных радиосигналов, данных от системы GPS

121/132 Система единого времени • Атомные часы, устройства приема радиосигналов и прочее подобное оборудование принято называть эталонными временными серверами – Они имеют ранг 0 (самый высокий) – Эти серверы не поддерживают сетевых соединений, взаимодействия с аппаратным окружением через локальные физические порты • Компьютеры, подключенные к этим устройствам, называются серверами уровня 1 • Всего в иерархии устройств выделяют 7 уровней, седьмой уровень присвоен локальным аппаратным часам CMOS • В обычных условиях сервер NTP небольшой сети использует для синхронизации данные 3 внешних серверов – Число три выбрано произвольно и может быть изменено – Три внешних сервера обеспечивают избыточность данных для более надежной работы • В большинстве случаев роль внешних серверов выполняют устройства ранга 2

122/132 Система единого времени • В большинстве случаев от локальной системы требуется, чтобы она показывала локальное время • ОС МСВС 3. 0 может работать с системным таймером, отсчитывающим либо локальное время, либо UTC (Coordinated Universal Time), время, которое практически совпадает с Гринвичским, но без учета перехода на летнее время и назад – UTC не привязано к вращению Земли, только к внутренним эталонам. – Так как скорость вращения Земли изменяется в зависимости от положения на орбите, UTC может быть приведено в соответствие с текущей скоростью вращения – Локальное время отличается от UTC смещением часового пояса и поправками перехода на летнее или зимнее время. • ОС МСВС 3. 0 не корректирует аппаратный таймер при коррекции системного времени • Для приведения таймера в соответствие с системным временем можно использовать команду: hwclock -systohc -localtime • Если на локальном компьютере время хранится в формате UTC, надо заменить опцию -localtime на -utc

123/132 7. 2 Пакет ntp • Программный пакет сервера точного времени ОС МСВС 3. 0 состоит из собственно сервера ntpd и нескольких вспомогательных программ • Сервер ntpd — основная программа, реализующая серверные функции протокола NTP – Для вышестоящих рангом серверов она является клиентом, для нижестоящих — сервером • Программа ntpdate — простой клиент точного времени – Для синхронизации системного времени с сервером необходимо обеспечить ее периодический запуск • Утилита ntptrace – Следует по иерархическому дереву серверов точного времени к источнику данных о времени – Такая информация может быть полезной для отладки системы • Ntpq — программа для NTP-мониторинга • Утилита ntpstat выводит статус работы системы единого времени

124/132 7. 3 Конфигурационный файл /etc/ntp. conf • • Как и во многих других конфигурационных файлах, строки, содержащие комментарии, начинаются с # и игнорируются В остальных строках задаются различные опции NTP restrict 127. 0. 0. 1 Эта опция позволяет доступ к серверу через loopинтерфейс. Особенного значения она не имеет, но нужна для некоторых административных функций. server адрес Данная опция знает имя сервера, который используется [key ключ] для синхронизации показаний времени с помощью [version номер] протокола NTP. В качестве адреса может быть задан IP[prefer] адрес или имя узла. При необходимости в файл можно включить несколько опций server, в результате локальный сервер NTP установит соединение с каждым из указанных и выберет для синхронизации наилучший из них. В составе данной опции может задаваться дополнительная информация. Значение, следующее после key, определяет ключ аутентификации, оно указывается, если доступ к серверу ограничен. Номер версии сообщает о том, какая версия протокола должна быть использована при взаимодействии. Ключевое слово prefer указывает, что данный сервер предпочтительнее других.

125/132 Конфигурационный файл /etc/ntp. conf fudge адрес stratum номер Данная опция в основном используется для того, чтобы указать, что сервер 127. 1. 0 (локальные системные часы) должен интерпретироваться как сервер уровня 7 — сервер NTP с самым низким приоритетом. Это позволит серверу продолжать работу, даже если другие серверы недоступны. driftfile Имя файла, информация из которого используется при возобновлении работы после длительного отключения компьютера. Содержимое файла позволяет серверу скорректировать скорость хода системных часов. имя_файла broadcast адрес Если данная опция будет указана, сервер будет [key ключ] периодически передавать в широковещательном [version номер] режиме данные о текущем времени. [ttl номер] broadcastclient Данная опция указывает серверу NTP на то, что он [yes|no] должен принимать широковещательные сообщения от других локальных серверов NTP.

126/132 Конфигурационный файл /etc/ntp. conf • Образец файла /etc/ntp. conf, включенный в дистрибутив, практически обеспечивает работу сервера NTP • Администратору остается добавить одну или несколько опций server, указывающих на серверы NTP • Если необходимо иметь в сети эталон времени, необходимо установить на сервере NTP, например, устройство GPS • Тогда в сети появляется сервер уровня 1. • Для работы с таким оборудованием могут понадобиться специальные драйверы • После редактирования ntp. conf надо перезапустить сервер NTP с помощью команды: service ntpd restart • Запуск при каждом включении системы достигается через отметку соответствующего пункта в меню утилиты ntsysv

127/132 Конфигурационный файл /etc/ntp. conf • При перезапуске или первом запуске сервер не будет сразу изменять показания системных часов • Вначале ntpd несколько раз сравнит показания системных часов с данными, предоставленными удаленным сервером, а лишь затем предпримет меры для коррекции системного времени • Если ошибка превышает 1000 секунд, работа сервера завершается, так как алгоритм его работы предполагает, что данная ситуация требует непосредственного вмешательства администратора • Поэтому перед запуском сервера NTP необходимо хотя бы приблизительно установить значение системного времени • Для установки системных часов перед запуском сервера можно также использовать утилиту ntpdate • В некоторых случаях предварительный запуск утилиты ntpdate администратор предусматривает в сценарии старта сервера ntpd

128/132 7. 4 Операции ntpd • Помимо визуального контроля показаний системных часов для мониторинга операций NTP часто применяется программа ntpq – После вызова эта программа запрашивает команды, определяющие ее дальнейшую работу (выводит свое приглашение на ввод команд). – В процессе выполнения программа отображает информацию о работе сервера. – Полный список команд можно вывести, введя в приглашении утилиты help. • Программа ntpq вызывается при первоначальной настройке сервера и при изменении его конфигурации • Кроме того, с ее помощью можно периодически осуществлять контроль за его работой

129/132 Операции ntpd • Для того, чтобы все поля вывода утилиты были заполнены, требуется некоторое время работы сервера • Если против какого-либо сервера появился знак «х» , имеет смысл исключить его из файла ntp. conf • Если заметно, что показания системных часов изменяются странным образом, имеет смысл запустить ntpq и проверить состояние операций сервера – Возможно, он не получает данных из-за изменившегося IP-адреса или временного сбоя работы сети – Могут быть проблемы из-за отсутствия прав доступа, или ограничения доступа на вышестоящим сервере по ключу – Также следует позаботится об оставлении соответствующих каналов в брандмауэрах

130/132 7. 5 Клиентские средства NTP • В простой сети на подавляющем большинстве машин возможности ntpd используются лишь в небольшой степени – Этот сервер умеет синхронизировать показания системных часов с точностью до нескольких тысячных долей секунды и обеспечивает отклонение от UTC менее секунды – Кроме того, программа умеет корректировать дрейф часов постоянно • Но, как правило, потребности пользователей сети гораздо скромнее, для них вполне допустима погрешность в несколько секунд • Кроме того, ntpd — это сервер и при постоянной работе возникает угроза безопасности системы • По этой причине в большинстве случаев целесообразно заменить сервер программой ntpdate

131/132 Клиентские средства NTP • Для того, чтобы воспользоваться возможностями программы, надо запустить ее с адресом сервера времени в качестве аргумента • Можно задать несколько адресов серверов, программа автоматически выберет из них наиболее авторитетный • После запуска программа выводит различные статистические данные, в частности, уровень сервера, смещение и задержку • Если при выполнении программы не возникнет ошибка и если не была задана опция -q, ntpdate скорректирует показания системных часов, установив новое значение, либо выполнив их подстройку • Для периодического запуска программы ntpdate часто используют инструмент cron • В большинстве случаев достаточно запускать программу один раз в сутки • Периодическое выполнение ntpdate уменьшит NTP-трафик по сравнению с использованием ntpd

132/132 Заключение • Службы разрешения имен • DNS (Domain Name Service) — служба доменных имен • Протокол динамической настройки хоста и сервер DHCP • Сетевая файловая система NFS • Samba в МСВС — защищенная сетевая файловая система • Сервер FTP • Система единого времени • Задание на самоподготовку – Ознакомление с литературой – Конспект лекций по дисциплине (электронный вариант)