diff --git a/ru_RU.KOI8-R/books/handbook/advanced-networking/chapter.sgml b/ru_RU.KOI8-R/books/handbook/advanced-networking/chapter.sgml index 21c521cacc..591ffaee9d 100644 --- a/ru_RU.KOI8-R/books/handbook/advanced-networking/chapter.sgml +++ b/ru_RU.KOI8-R/books/handbook/advanced-networking/chapter.sgml @@ -1,4557 +1,4557 @@ Андрей Захватов Перевод на русский язык: Сложные вопросы работы в сети Краткий обзор Эта глава охватывает множество различных сетевых тематик повышенной сложности. После чтения этой главы вы будете знать: Основные понятия о маршрутизации и маршрутах. Как настроить IEEE 802.11 и &bluetooth;. Как заставить FreeBSD работать в качестве сетевого моста. Как настроить загрузку по сети для бездисковой машины. Как настроить трансляцию сетевых адресов. Как соединить два компьютера посредством PLIP. Как настроить IPv6 на машине FreeBSD. Как настроить ATM. Перед чтением этой главы вы должны: Понимать основы работы скриптов /etc/rc. Свободно владеть основными сетевыми терминами. Знать как настраивать и устанавливать новое ядро FreeBSD (). Знать как устанавливать дополнительное программное обеспечение сторонних разработчиков (). Coranth Gryphon Текст предоставил Сетевые шлюзы и маршруты маршрутизация шлюз подсеть Чтобы некоторая машина могла найти в сети другую, должен иметься механизм описания того, как добраться от одной машине к другой. Такой механизм называется маршрутизацией. Маршрут задаётся парой адресов: адресом назначения (destination) и сетевым шлюзом (gateway). Эта пара указывает на то, что если Вы пытаетесь соединиться с адресом назначения, то вам нужно устанавливать связь через сетевой шлюз. Существует три типа адресов назначения: отдельные хосты, подсети и маршрут по умолчанию (default). Маршрут по умолчанию (default route) используется, если не подходит ни один из других маршрутов. Мы поговорим немного подробнее о маршрутах по умолчанию позже. Также имеется и три типа сетевых шлюзов: отдельные хосты, интерфейсы (также называемые подключениями (links)) и аппаратные адреса Ethernet (MAC-адреса). Пример Для иллюстрации различных аспектов маршрутизации мы будем использовать следующий пример использования команды netstat: &prompt.user; netstat -r Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 example.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.example.com link#1 UC 0 0 224 link#1 UC 0 0 маршрут по умолчанию В первых двух строках задаются маршрут по умолчанию (который будет описан в следующем разделе) и маршрут на localhost. устройство loopback Интерфейс (колонка Netif), который указан в этой таблице маршрутов для использования с localhost и который назван lo0, имеет также второе название, устройство loopback. Это значит сохранение всего трафика для указанного адреса назначения внутри, без посылки его по сети, так как он все равно будет направлен туда, где был создан. Ethernet MAC адрес Следующими выделяющимися адресами являются адреса, начинающиеся с 0:e0:.... Это аппаратные адреса Ethernet, или MAC-адреса. FreeBSD будет автоматически распознавать любой хост (в нашем примере это test0) в локальной сети Ethernet и добавит маршрут для этого хоста, указывающий непосредственно на интерфейс Ethernet, ed0. С этим типом маршрута также связан параметр таймаута (колонка Expire), используемый в случае неудачной попытки услышать этот хост в течении некоторого периода времени. Если такое происходит, то маршрут до этого хоста будет автоматически удалён. Такие хосты поддерживаются при помощи механизма, известного как RIP (Routing Information Protocol), который вычисляет маршруты к хостам локальной сети при помощи определения кратчайшего расстояния. подсеть FreeBSD добавит также все маршруты к подсетям для локальных подсетей (10.20.30.255 является широковещательным адресом для подсети 10.20.30, а имя example.com является именем домена, связанным с этой подсетью). Назначение link#1 соответствует первому адаптеру Ethernet в машине. Отметьте отсутствие дополнительного интерфейса для этих строк. В обеих этих группах (хосты и подсети локальной сети) маршруты конфигурируются автоматически даемоном, который называется routed. Если он не запущен, то будут существовать только статически заданные (то есть введенные явно) маршруты. Строка host1 относится к нашему хосту, который известен по адресу Ethernet. Так как мы являемся посылающим хостом, FreeBSD знает, что нужно использовать loopback-интерфейс (lo0) вместо того, чтобы осуществлять посылку в интерфейс Ethernet. Две строки host2 являются примером того, что происходит при использовании алиасов в команде &man.ifconfig.8; (обратитесь к разделу об Ethernet для объяснения того, почему мы это делаем). Символ => после интерфейса lo0 указывает на то, что мы используем не просто интерфейс loopback (так как это адрес, обозначающий локальный хост), но к тому же это алиас. Такие маршруты появляются только на хосте, поддерживающем алиасы; для всех остальных хостов в локальной сети для таких маршрутов будут показаны просто строчки link#1. Последняя строчка (подсеть назначения 224) имеет отношение к многоадресной посылке, которая будет рассмотрена в другом разделе. И наконец, различные атрибуты каждого маршрута перечисляются в колонке Flags. Ниже приводится краткая таблица некоторых из этих флагов и их значений: U Up: Маршрут актуален. H Host: Адресом назначения является отдельный хост. G Gateway: Посылать все для этого адреса назначения на указанную удаленную систему, которая будет сама определять дальнейший путь прохождения информации. S Static: Маршрут был настроен вручную, а не автоматически сгенерирован системой. C Clone: Новый маршрут сгенерирован на основе указанного для машин, к которым мы подключены. Такой тип маршрута обычно используется для локальных сетей. W WasCloned: Указывает на то, что маршрут был автоматически сконфигурирован на основе маршрута в локальной сети (Clone). L Link: Маршрут включает ссылку на аппаратный адрес Ethernet. Маршруты по умолчанию маршрут по умолчанию Когда локальной системе нужно установить соединение с удаленным хостом, она обращается к таблице маршрутов для того, чтобы определить, существует ли такой маршрут. Если удаленный хост попадает в подсеть, для которой известен способ ее достижения (маршруты типа Cloned), то система определяет возможность подключиться к ней по этому интерфейсу. Если все известные маршруты не подходят, у системы имеется последняя возможность: маршрут default. Это маршрут с особым типом сетевого шлюза (обычно единственным, присутствующим в системе), и в поле флагов он всегда помечен как c. Для хостов в локальной сети этот сетевой шлюз указывает на машину, имеющую прямое подключение к внешнему миру (неважно, используется ли связь по протоколу PPP, канал DSL, кабельный модем, T1 или какой-то другой сетевой интерфейс). Если вы настраиваете маршрут по умолчанию на машине, которая сама является сетевым шлюзом во внешний мир, то маршрутом по умолчанию будет являться сетевой шлюз у Вашего провайдера Интернет (ISP). Давайте взглянем на примеры маршрутов по умолчанию. Вот типичная конфигурация: [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] Хосты Local1 и Local2 находятся в нашей сети. Local1 подключён к ISP через коммутируемое соединение по протоколу PPP. Этот компьютер с сервером PPP подключён посредством локальной сети к другому шлюзовому компьютеру через внешний интерфейс самого ISP к Интернет. Маршруты по умолчанию для каждой из ваших машин будут следующими: Хост Маршрут по умолчанию Интерфейс Local2 Local1 Ethernet Local1 T1-GW PPP Часто задаётся вопрос Почему (или каким образом) в качестве шлюза по умолчанию для машины Local1 мы указываем T1-GW, а не сервер провайдера, к которому подключаемся?. Запомните, что из-за использования PPP-интерфейсом адреса в сети провайдера Интернет с вашей стороны соединения, маршруты для всех других машин в локальной сети провайдера будут сгенерированы автоматически. Таким образом, вы уже будете знать, как достичь машины T1-GW, так что нет нужды в промежуточной точке при посылке трафика к серверу ISP. В локальных сетях адрес X.X.X.1 часто используется в качестве адреса сетевого шлюза. Тогда (при использовании того же самого примера) если пространство адресов класса C вашей локальной сети было задано как 10.20.30, а ваш провайдер использует 10.9.9, то маршруты по умолчанию будут такие: Хост Маршрут по умолчанию Local2 (10.20.30.2) Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) T1-GW (10.9.9.1) Вы можете легко задать используемый по умолчанию маршрутизатор посредством файла /etc/rc.conf. В нашем примере на машине Local2 мы добавили такую строку в файл /etc/rc.conf: defaultrouter="10.20.30.1" Это также возможно сделать и непосредственно из командной строки при помощи команды &man.route.8;: &prompt.root; route add default 10.20.30.1 Для получения дополнительной информации об управлении таблицами маршрутизации обратитесь к справочной странице по команде &man.route.8;. Хосты с двойным подключением хосты с двойным подключением Есть еще один тип подключения, который мы должны рассмотреть, и это случай, когда хост находится в двух различных сетях. Технически, любая машина, работающая как сетевой шлюз (в примере выше использовалось PPP-соединение), считается хостом с двойным подключением. Однако этот термин реально используется для описания машины, находящейся в двух локальных сетях. В одном случае у машины имеется два адаптера Ethernet, каждый имеющий адрес в разделенных подсетях. Как альтернативу можно рассмотреть вариант с одним Ethernet-адаптером и использованием алиасов в команде &man.ifconfig.8;. В первом случае используются два физически разделённые сети Ethernet, в последнем имеется один физический сегмент сети, но две логически разделённые подсети. В любом случае таблицы маршрутизации настраиваются так, что для каждой подсети эта машина определена как шлюз (входной маршрут) в другую подсеть. Такая конфигурация, при которой машина выступает в роли маршрутизатора между двумя подсетями, часто используется, если нужно реализовать систему безопасности на основе фильтрации пакетов или функций брандмауэра в одном или обоих направлениях. Если вы хотите, чтобы эта машина действительно перемещала пакеты между двумя интерфейсами, то вам нужно указать FreeBSD на включение этой функции. Обратитесь к следующей главе, чтобы узнать, как это сделать. Построение маршрутизатора маршрутизатор Сетевой маршрутизатор является обычной системой, которая пересылает пакеты с одного интерфейса на другой. Стандарты Интернет и хорошая инженерная практика не позволяют Проекту FreeBSD включать эту функцию по умолчанию во FreeBSD. Вы можете включить эту возможность, изменив значение следующей переменной в YES в файле &man.rc.conf.5;: gateway_enable=YES # Set to YES if this host will be a gateway Этот параметр изменит значение &man.sysctl.8;-переменной net.inet.ip.forwarding в 1. Если вам временно нужно выключить маршрутизацию, вы можете на время сбросить это значение в 0. Вашему новому маршрутизатору нужна информация о маршрутах для того, чтобы знать, куда пересылать трафик. Если ваша сеть достаточно проста, то вы можете использовать статические маршруты. С FreeBSD также поставляется стандартный даемон BSD для маршрутизации &man.routed.8;, который умеет работать с RIP (как версии 1, так и версии 2) и IRDP. Поддержка BGP v4, OSPF v2 и других сложных протоколов маршрутизации имеется в пакете net/zebra. Также существуют и коммерческие продукты, применяемые как более комплексное решение проблемы маршрутизации в сети, такие как &gated;. BGP RIP OSPF Al Hoang Предоставил Настройка статических маршрутов Ручная настройка Предположим, что у нас есть следующая сеть: INTERNET | (10.0.0.1/24) Default Router to Internet | |Interface xl0 |10.0.0.10/24 +------+ | | RouterA | | (FreeBSD gateway) +------+ | Interface xl1 | 192.168.1.1/24 | +--------------------------------+ Internal Net 1 | 192.168.1.2/24 | +------+ | | RouterB | | +------+ | 192.168.2.1/24 | Internal Net 2 В этом сценарии, RouterA это наш компьютер с &os;, который выступает в качестве маршрутизатора в сеть Интернет. Его маршрут по умолчанию настроен на 10.0.0.1, что позволяет ему соединяться с внешним миром. Мы будем предполагать, что RouterB уже правильно настроен и знает все необходимые маршруты (на этом рисунке все просто; добавьте на RouterB маршрут по умолчанию, используя 192.168.1.1 в качестве шлюза). Если мы посмотрим на таблицу маршрутизации RouterA, то увидим примерно следующее: &prompt.user; netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 49378 xl0 127.0.0.1 127.0.0.1 UH 0 6 lo0 10.0.0/24 link#1 UC 0 0 xl0 192.168.1/24 link#2 UC 0 0 xl1 С текущей таблицей маршрутизации RouterA не сможет достичь внутренней сети 2 (Internal Net 2). Один из способов обхода этой проблемы — добавление маршрута вручную. Следующая команда добавляет внутреннюю сеть 2 к таблице маршрутизации RouterA с 192.168.1.2 в качестве следующего узла: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 Теперь RouterA сможет достичь любого хоста в сети 192.168.2.0/24. Постоянная конфигурация Предыдущий пример прекрасно подходит для настройки статического маршрута в работающей системе. Однако, проблема заключается в том, что маршрутная информация не сохранится после перезагрузки &os;. Способ сохранения добавленного маршрута заключается в добавлении его в файл /etc/rc.conf: # Добавление статического маршрута в Internal Net 2 static_routes="internalnet2" route_internalnet2="-net 192.168.2.0/24 192.168.1.2" В переменной static_routes находятся строки, разделенные пробелами. Каждая строка означает имя маршрута. В примере выше в static_routes есть только одна строка, это internalnet2. Затем мы добавили переменную route_internalnet2, куда помещены все параметры, которые необходимо передать команде &man.route.8;. В примере выше была использована команда: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 поэтому нам потребуется "-net 192.168.2.0/24 192.168.1.2". Как было сказано выше, мы можем добавить в static_routes более чем одну строку. Это позволит создать несколько статических маршрутов. В следующем примере показано добавление маршрутов для сетей 192.168.0.0/24 и 192.168.1.0/24 (этот маршрутизатор не показан на рисунке выше: static_routes="net1 net2" route_net1="-net 192.168.0.0/24 192.168.0.1" route_net2="-net 192.168.1.0/24 192.168.1.1" Распространение маршрутов распространение маршрутов Мы уже говорили о том, как мы задаем наши маршруты во внешний мир, но не упоминали о том, как внешний мир находит нас. Мы уже знаем, что таблицы маршрутизации могут быть настроены так, что весь трафик для некоторого диапазона адресов (в нашем примере это подсеть класса C) может быть направлен заданному хосту в той сети, которая будет перенаправлять входящие пакеты дальше. При получении адресного пространства, выделенного Вашей сети, Ваш провайдер настроит свои таблицы маршрутизации так, что весь трафик для Вашей подсети будет пересылаться по PPP-соединению к Вашей сети. Но как серверы по всей стране узнают, что Ваш трафик нужно посылать Вашему ISP? Существует система (подобная распределению информации DNS), которая отслеживает все назначенные пространства адресов и определяет точку подключения к магистрали Интернет. Магистралью называют главные каналы, по которым идет трафик Интернет внутри страны и по всему миру. Каждая магистральная машина имеет копию основного набора таблиц, согласно которой трафик для конкретной сети направляется по конкретному магистральному каналу, и затем, передаваясь по цепочке провайдеров, он достигает вашей сети. Задачей вашего провайдера является объявить на магистрали о том, что он отвечает за подключение (и поэтому на него указывает маршрут) вашей сети. Этот процесс называется распространением маршрута. Устранение неполадок traceroute Иногда с распространением маршрута возникают проблемы, и некоторые сайты не могут к вам подключиться. Наверное, самой полезной командой для определения точки неверной работы маршрутизации является &man.traceroute.8;. Она также полезна и когда вы сами не можете подключиться к удаленной машине (то есть команда &man.ping.8; не срабатывает). Команда &man.traceroute.8; запускается с именем удаленного хоста, с которым вы хотите установить соединение, в качестве параметра. Она показывает промежуточные сетевые шлюзы по пути следования, в конце концов достигая адрес назначения или прерывая свою работу из-за отсутствия соединения. За дополнительной информацией обратитесь к странице Справочника по &man.traceroute.8;. Маршрутизация многоадресного трафика маршрутизация многоадресного трафика параметры ядра MROUTING FreeBSD изначально поддерживает как приложения, работающие с многоадресным трафиком, так и его маршрутизацию. Такие приложения не требуют особой настройки FreeBSD; обычно они работают сразу. Для маршрутизации многоадресного трафика требуется, чтобы поддержка этого была включена в ядро: options MROUTING Кроме того, даемон многоадресной маршрутизации, &man.mrouted.8;, должен быть настроен посредством файла /etc/mrouted.conf на использование туннелей и DVMRP. Дополнительную информацию о настройки многоадресного трафика можно найти на страницах справочной системы, посвящённых даемону &man.mrouted.8;. Eric Anderson Текст предоставил Андрей Захватов Перевёл на русский язык Беспроводные сети беспроводные сети 802.11 беспроводные сети Введение Было бы весьма полезным иметь возможность использовать компьютер без хлопот, связанных с постоянно подключенным сетевым кабелем. FreeBSD может использоваться как клиент беспроводной сети, и даже в качестве точки доступа к ней. Режимы работы беспроводной связи Существуют два варианта конфигурации устройств беспроводного доступа 802.11: BSS и IBSS. Режим BSS Режим BSS является наиболее часто используемым. Режим BSS также называют режимом инфраструктуры. В этом режиме несколько точек доступа беспроводной сети подключаются к проводной сети передачи данных. Каждое беспроводная сеть имеет собственное имя. Это имя является идентификатором SSID сети. Клиенты беспроводной сети подключаются к этим точкам доступа беспроводной сети. Стандарт IEEE 802.11 определяет протокол, используемый для связи в беспроводных сетях. Клиент сети беспроводного доступа может подключаться к некоторой сети, если задан её SSID. Клиент может также подключаться к любой сети, если SSID не задан. Режим IBSS Режим IBSS, также называемый ad-hoc, предназначен для соединений точка-точка. На самом деле существуют два типа режима ad-hoc. Один из них является режимом IBSS, называемый также режимом ad-hoc или IEEE ad-hoc. Этот режим определён стандартами IEEE 802.11. Второй режим называется демонстрационным режимом ad-hoc, или Lucent ad-hoc (или, иногда неправильно, режимом ad-hoc). Это старый, существовавший до появления 802.11, режим ad-hoc, и он должен использоваться только для старых сетей. В дальнейшем мы не будем рассматривать ни один из режимов ad-hoc. Режим инфраструктуры Точки доступа Точки доступа представляют собой беспроводные сетевые устройства, позволяющие одному или большему количеству клиентов беспроводной сети использовать эти устройства в качестве центрального сетевого концентратора. При использовании точки доступа все клиенты работают через неё. Зачастую используются несколько точек доступа для полного покрытия беспроводной сетью некоторой зоны, такой, как дом, офис или парк. Точки доступа обычно имеют несколько подключений к сети: адаптер беспроводной связи и один или большее количество сетевых ethernet-адаптеров для подключения к остальной части сети. Точки доступа могут быть либо приобретены уже настроенными, либо вы можете создать собственную при помощи FreeBSD и поддерживаемого адаптера беспроводной связи. Несколько производителей выпускают точки беспроводного доступа и адаптеры беспроводной связи с различными возможностями. Построение точки доступа с FreeBSD беспроводные сети точка доступа Требования Для того, чтобы создать беспроводную точку доступа на FreeBSD, вам нужно иметь совместимый адаптер беспроводной связи. На данный момент поддерживаются адаптеры только на основе набора микросхем Prism. Вам также потребуется поддерживаемый FreeBSD адаптер проводной сети (найти такой будет нетрудно, FreeBSD поддерживает множество различных устройств). В этом руководстве мы будем полагать, что вы будете строить сетевой мост (&man.bridge.4;) для пропуска всего трафика между устройством беспроводной связи и сетью, подключенной к обычному Ethernet-адаптеру. Функциональность hostap, которая используется FreeBSD для организации точки доступа, работает лучше всего с некоторыми версиями микрокода. Адаптеры Prism 2 должны использовать микрокод версии 1.3.4 или более новый. Адаптеры Prism 2.5 и Prism 3 должны использовать микрокод версии 1.4.9. Более старые версии микрокода могут работать нормально, а могут и некорректно. В настоящее время единственным способом обновления адаптеров является использование утилит обновления для &windows;, которые можно получить у производителя ваших адаптеров. Настройка Первым делом убедитесь, что ваша система распознаёт адаптер беспроводной связи: &prompt.root; ifconfig -a wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "FreeBSD Wireless node" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 На данном этапе не беспокойтесь о деталях, просто убедитесь, что выдаётся нечто, указывающее на установленный адаптер беспроводной связи. Если при этом у вас есть проблемы с недоступностью интерфейса беспроводной связи, и вы используете PC Card, то обратитесь к страницам справочной системы, описывающим &man.pccardc.8; и &man.pccardd.8; для получения более полной информации. Теперь вам нужно загрузить модуль для подготовки той части FreeBSD, что отвечает за организацию сетевых мостов, для работы с точкой доступа. Для загрузки модуля &man.bridge.4; просто выполните следующую команду: &prompt.root; kldload bridge При загрузке модуля никаких сообщений об ошибках быть не должно. Если это всё же произошло, вам может потребоваться вкомпилировать код для модуля &man.bridge.4; в ядро. В этом вам должен помочь раздел этого Руководства об организации сетевых мостов. Теперь, когда вы завершили с той частью, что касается организации сетевого моста, нам нужно указать ядру FreeBSD, какие интерфейсы должны объединяться в сетевом мосте. Это мы делаем при помощи &man.sysctl.8;: &prompt.root; sysctl net.link.ether.bridge.enable=1 &prompt.root; sysctl net.link.ether.bridge.config="wi0 xl0" &prompt.root; sysctl net.inet.ip.forwarding=1 В версиях &os;, предшествующих 5.2, вместо указанных нужно использовать следующие параметры: &prompt.root; sysctl net.link.ether.bridge=1 &prompt.root; sysctl net.link.ether.bridge_cfg="wi0,xl0" &prompt.root; sysctl net.inet.ip.forwarding=1 Теперь необходимо настроить адаптер беспроводной сети. Следующая команда заставит адаптер работать в режиме точки доступа: &prompt.root; ifconfig wi0 ssid my_net channel 11 media DS/11Mbps mediaopt hostap up stationname "FreeBSD AP" Строчка &man.ifconfig.8; активизирует интерфейс wi0, конфигурирует его SSID как my_net, а имя станции как FreeBSD AP. переводит адаптер в режим 11Mbps и нужен только для того, чтобы сработал параметр . Параметр переводит интерфейс в режим точки доступа. Параметр задаёт использование канала 802.11b. Страница справки по команде &man.wicontrol.8; перечисляет корректные значения каналов для ваших нужд. Теперь у вас должна получиться полнофункциональная работающая точка доступа. Настоятельно советуем прочесть страницы справочной по &man.wicontrol.8;, &man.ifconfig.8;, и &man.wi.4; для получения дополнительной информации. Также полагаем, что вы прочтёте следующий раздел о шифровании. Информация о состоянии После того, как точка доступа сконфигурирована и начала свою работу, операторам может понадобиться видеть клиентов, связанных с этой точкой. В любой момент оператор может набрать: &prompt.root; wicontrol -l 1 station: 00:09:b7:7b:9d:16 asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15 Это показывает, что имеется одна связанная станция с перечисленными характеристиками. Выдаваемое значение сигнала должно использоваться только как сравнительный индикатор его силы. Его перевод в dBm или другие единицы измерения различаются в разных версиях микрокода. Клиенты Клиент в беспроводной сети представляет собой систему, которая обращается к точке доступа или непосредственно к другому клиенту. Как правило, клиенты беспроводной сети имеют только один сетевой адаптер, а именно адаптер беспроводной сети. Существует несколько различных способов конфигурации клиента беспроводной сети. Они основаны на различных режимах работы в беспроводной сети, обычно BSS (режим инфраструктуры, который требует точки доступа) или IBSS (ad-hoc или режим одноранговой сети). В нашем примере мы будем использовать самый популярный их них, режим BSS, для связи с точкой доступа. Требования Существует только одно жёсткое условие для настройки FreeBSD в качестве клиента беспроводной сети. Вам нужен адаптер беспроводной связи, поддерживаемый FreeBSD. Конфигурация FreeBSD как клиента беспроводной сети Перед тем, как подключиться к беспроводной сети, вам нужно будет узнать о ней несколько вещей. В этом примере мы подключаемся к сети, которая называется my_net, и шифрование в ней отключено. В этом примере мы не используем шифрование, но это небезопасно. В следующем разделе вы узнаете, как её включить, почему это так важно, и почему некоторые технологии шифрования всё же не могут полностью обеспечить вашу информационную безопасность. Удостоверьтесь, что ваш адаптер распознаётся во FreeBSD: &prompt.root; ifconfig -a wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "FreeBSD Wireless node" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 Теперь мы можем изменить настройки адаптера на те, что соответствуют нашей сети: &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net Замените 192.168.0.20 и 255.255.255.0 на правильные IP-адрес и сетевую маску в вашей проводной сети. Запомните, что наша точка доступа выступает в роли моста для данных между беспроводной и проводной сетями, так что они будут доступны для других устройств, находящихся в сети, как будто они тоже находятся в проводной сети. Как только вы это выполнили, то сможете получить ping от хостов в проводной сети, как будто вы подключены посредством обычных проводов. Если вы столкнулись с проблемами при работе в беспроводной сети, удостоверьтесь, что вы ассоциированы (подключены) с точкой доступа: &prompt.root; ifconfig wi0 должна выдать некоторую информацию, и вы должны увидеть: status: associated Если статус не будет соответствовать associated, это может значить, что вы оказались вне зоны досягаемости точки доступа, включили шифрование или, возможно, имеются проблемы с конфигурацией. Шифрование беспроводные сети шифрование Шифрование в беспроводной сети имеет важное значение, потому что у вас нет больше возможности ограничить сеть хорошо защищённой областью. Данные вашей беспроводной сети вещаются по всей окрестности, так что любой заинтересовавшийся может их считать. Вот здесь используется шифрование. Шифруя данные, посылаемые в эфир, вы делаете их прямой перехват гораздо более сложным для всех любопытных. Двумя наиболее широко применяемыми способами шифрования данных между вашим клиентом и точкой доступа являются WEP и &man.ipsec.4;. WEP WEP WEP является сокращением от Wired Equivalency Protocol (Протокол Соответствия Проводной сети). WEP является попыткой сделать беспроводные сети такими же надёжными и безопасными, как проводные. К сожалению, он был взломан и сравнительно легко поддаётся вскрытию. Это означает также, что он не тот протокол, на который следует опираться, когда речь идёт о шифровании критически важных данных. Он лучше, чем ничего, так что используйте следующую команду для включения WEP в вашей новой точке доступа FreeBSD: &prompt.root; ifconfig wi0 inet up ssid my_net wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap Вы можете включить WEP на клиенте следующей командой: &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net wepmode on wepkey 0x1234567890 Отметьте, что вы должны заменить 0x1234567890 на более уникальный ключ. IPsec &man.ipsec.4; является гораздо более надёжным и мощным средством шифрования данных в сети. Этот метод определённо является предпочтительным для шифрования данных в беспроводной сети. Более детально ознакомиться с безопасностью и применением &man.ipsec.4; вы можете в разделе об IPsec этого Руководства. Утилиты Имеется несколько утилит, которые можно использовать для настройки и отладки вашей беспроводной сети, и здесь мы попытаемся описать некоторые из них и что они могут делать. Пакет <application>bsd-airtools</application> Пакет bsd-airtools представляет собой полный набор инструментов, включая инструменты для проверки беспроводной сети на предмет взлома WEP-ключа, обнаружения точки доступа и тому подобное. Утилиты bsd-airtools можно установить из порта net/bsd-airtools. Информацию + role="package">net-mgmt/bsd-airtools. Информацию об установке портов можно найти в Главе этого Руководства. Программа dstumbler является инструментом, предназначенным для обнаружения точки доступа и выдачи отношения уровня сигнала к шуму. Если у вас с трудом получается запустить точку доступа, dstumbler может помочь вам начать. Для тестирования информационной безопасности вашей беспроводной сети, вы можете воспользоваться набором dweputils (dwepcrack, dwepdump и dwepkeygen), который может помочь понять, является ли WEP подходящим решением для обеспечения ваших потребностей в информационной безопасности. Утилиты <command>wicontrol</command>, <command>ancontrol</command> и <command>raycontrol</command> Это инструменты, которые могут быть использованы для управления поведением адаптера беспроводной связи в сети. В примере выше мы выбирали &man.wicontrol.8;, так как нашим адаптером беспроводной сети был интерфейс wi0. Если у вас установлено устройство беспроводного доступа от Cisco, этим интерфейсом будет an0, и тогда вы будете использовать &man.ancontrol.8;. Команда <command>ifconfig</command> ifconfig Команда &man.ifconfig.8; может использоваться для установки многих из тех параметров, что задаёт &man.wicontrol.8;, однако работа с некоторыми параметрами в ней отсутствует. Обратитесь к &man.ifconfig.8; для выяснения параметров и опций командной строки. Поддерживаемые адаптеры Точки доступа Единственными адаптерами, которые на данный момент поддерживаются в режиме BSS (как точка доступа), являются те устройства, что сделаны на основе набора микросхем Prism 2, 2.5 или 3). Полный список можно увидеть в &man.wi.4;. Клиенты 802.11b Практически все адаптеры беспроводной связи 802.11b на данный момент во FreeBSD поддерживаются. Большинство адаптеров, построенных на основе Prism, Spectrum24, Hermes, Aironet и Raylink, будут работать в качестве адаптера беспроводной сети в режиме IBSS (ad-hoc, одноранговая сеть и BSS). Клиенты 802.11a и 802.11g Драйвер устройства &man.ath.4; поддерживает 802.11a и 802.11g. Если ваша карта основана на чипсете Atheros, вы можете использовать этот драйвер. К сожалению, все еще много производителей, не предоставляющих схематику своих драйверов сообществу open source, поскольку эта информация считается торговым секретом. Следовательно, у разработчиков FreeBSD и других операционных систем остается два варианта: разработать драйверы долгим и сложным методом обратного инжиниринга, или использовать существующие драйверы для платформ µsoft.windows;. Большинство разработчиков FreeBSD выбрали второй способ. Благодаря усилиям Билла Пола (wpaul), начиная с FreeBSD 5.3-RELEASE существует прозрачная поддержка Network Driver Interface Specification (NDIS). FreeBSD NDISulator (известный также как Project Evil) преобразует бинарный драйвер &windows; так, что он работает так же как и в &windows;. Эта возможность всё ещё относительно нова, но в большинстве тестов она работает адекватно. NDIS загрузчик NDIS драйверы &windows; Microsoft Windows Microsoft Windows драйверы устройств KLD (загружаемый объект ядра) Для использования NDISulator потребуются три вещи: Исходные тексты ядра Бинарный драйвер &windowsxp; (расширение .SYS) Файл конфигурации бинарного драйвера &windowsxp; (расширение .INF) Вам может потребоваться компиляция драйвера оболочки мини порта &man.ndis.4;. Под root: &prompt.root; cd /usr/src/sys/modules/ndis &prompt.root; make && make install Определите местоположение файлов для вашей карты. Обычно их можно найти на входящем в комплект CD или на Web-сайте поставщика. В нашем примере используются файлы W32DRIVER.SYS и W32DRIVER.INF. Следующий шаг это компиляция бинарного драйвера в загружаемый модуль ядра. Чтобы сделать это, сначала зайдите в каталог модуля if_ndis и с правами root скопируйте туда драйверы &windows;: &prompt.root; cd /usr/src/sys/modules/if_ndis &prompt.root; cp /path/to/driver/W32DRIVER.SYS ./ &prompt.root; cp /path/to/driver/W32DRIVER.INF ./ Теперь используйте утилиту ndiscvt для создания заголовка определения драйвера ndis_driver_data.h перед сборкой модуля: &prompt.root; ndiscvt -i W32DRIVER.INF -s W32DRIVER.SYS -o ndis_driver_data.h Параметры и задают соответственно файл настройки и бинарный файл. Мы используем параметр , поскольку Makefile при создании модуля будет обращаться именно к этому файлу. Некоторым драйверам &windows; для работы требуются дополнительные файлы. Вы можете включить их параметром ndiscvt . Обратитесь к странице справочной системы &man.ndiscvt.8; за дополнительной информацией. Наконец, соберите и установите модуль драйвера: &prompt.root; make && make install Для использования драйвера необходимо загрузить соответствующие модули: &prompt.root; kldload ndis &prompt.root; kldload if_ndis Первая команда загружает оболочку драйвера мини-порта NDIS, вторая загружает собственно сетевой интерфейс. Проверьте &man.dmesg.8; на предмет ошибок загрузки. Если все прошло хорошо, вывод должен быть примерно таким: ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5 ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps Начиная с этого момента вы можете использовать устройство ndis0 как любое другое беспроводное устройство (например, wi0); в этой ситуации применима информация, приведенная в начале этой главы. Pav Lucistnik Текст предоставил
pav@FreeBSD.org
 Bluetooth Bluetooth Введение Bluetooth является беспроводной технологией для создания персональных сетей на расстоянии не более 10 метров, работающей на частоте 2.4 ГГц, которая не подлежит лицензированию. Обычно такие сети формируются из портативных устройств, таких, как сотовые телефоны, КПК и лэптопы. В отличие от Wi-Fi, другой популярной беспроводной технологии, Bluetooth предоставляет более высокий уровень сервиса, например, файловые серверы типа FTP, передачу файлов, голоса, эмуляцию последовательного порта и другие. Стек протоколов Bluetooth во &os; реализован на основе технологии Netgraph (обратитесь к &man.netgraph.4;). Широкий спектр USB-устройств Bluetooth поддерживается драйвером &man.ng.ubt.4;. Устройства Bluetooth на основе набора микросхем Broadcom BCM2033 поддерживается драйвером &man.ng.bt3c.4;. Устройства Bluetooth, работающие через последовательные и UART-порты, поддерживаются драйверами &man.sio.4;, &man.ng.h4.4; и &man.hcseriald.8;. В этом разделе описывается использование Bluetooth-устройств, подключаемых через USB. Поддержка Bluetooth имеется во &os; 5.0 и более новых версиях системы. Подключение устройства По умолчанию драйверы устройств Bluetooth поставляются в виде модулей ядра. Перед подключением устройства вам необходимо подгрузить драйвер в ядро: &prompt.root; kldload ng_ubt Если Bluetooth-устройство в момент запуска системы подключено, то загружайте модуль из файла /boot/loader.conf: ng_ubt_load="YES" Подключите ваше USB-устройство. На консоли (или в журнале syslog) появится примерно такое сообщение: ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294 Стек протоколов Bluetooth запускается вручную во &os; 6.0, и во &os; 5.X, перед 5.5. Это делается автоматически через &man.devd.8; во &os; 5.5, 6.1 и в более новых версиях. Скопируйте файл /usr/share/examples/netgraph/bluetooth/rc.bluetooth в какое-нибудь подходящее место, например, в файл /etc/rc.bluetooth. Этот скрипт используется для запуска и остановки работы Bluetooth-стека. Перед отключением устройства рекомендуется остановить его работы, хотя (обычно) это не фатально. При запуске стека вы получите сообщения, подобные следующим: &prompt.root; /etc/rc.bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <Park mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Paging scheme> <Power control> <Transparent SCO data> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8 HCI Host Controller Interface (HCI) Host Controller Interface (HCI) предоставляет интерфейс для управления контроллером передатчика и менеджером соединений, а также доступ к данным о состоянии оборудования и его управляющим регистрам. Этот интерфейс предоставляет унифицированный метод доступа к передающим возможностям Bluetooth. Уровень HCI на управляющей машине обменивается данными и командами с микрокодом HCI в оборудовании Bluetooth. Драйвер для Host Controller Transport Layer (то есть физической шины) предоставляет обоим слоям HCI возможность обмениваться данными друг с другом. Для одного Bluetooth-устройства создаётся один узел Netgraph типа hci. HCI-узел обычно подключается к узлу драйвера устройства Bluetooth (входящий поток) и к узлу L2CAP (исходящий поток). Все операции с HCI должны выполняться на узле HCI, но не на узле драйвера устройства. В качестве имени по умолчанию для узла HCI используется devicehci. Дополнительные подробности можно найти на справочной странице &man.ng.hci.4;. Одной из самой часто выполняемой задач является обнаружение Bluetooth-устройств в радиусе RF-доступности. Эта операция называется опросом (inquiry). Опрос и другие операции, связанные с HCI, выполняются при помощи утилиты &man.hccontrol.8;. Пример ниже показывает, как найти доступные устройства Bluetooth. Список таких устройств должен быть получен в течение нескольких секунд. Заметьте, что удалённые устройства будут отвечать на опрос, если только они находятся в режиме обнаруживаемости (discoverable). &prompt.user; hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] BD_ADDR является уникальным адресом устройства Bluetooth, вроде MAC-адресов сетевых адаптеров. Этот адрес необходим для дальнейшей работы с устройством. Адресу BD_ADDR можно присвоить удобное для чтения имя. Файл /etc/bluetooth/hosts содержит информацию об известных хостах Bluetooth. В следующем примере показано, как получить имя, назначенное удалённому устройству: &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39 Если вы выполните опрос на другом Bluetooth-устройстве, но ваш компьютер будет опознан как your.host.name (ubt0). Имя, назначаемое локальному устройству, может быть в любой момент изменено. Система Bluetooth предоставляет услуги по соединениям типа точка-точка (при этом задействованы только два устройства Bluetooth) или точка-ко-многим-точкам. В последнем случае соединение используется совместно несколькими устройствам Bluetooth. В следующем примере показывается, как получить список активных для локального устройства соединений: &prompt.user; hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN Идентификатор соединения (connection handle) полезен, когда необходимо прекратить соединение. Заметьте, что обычно нет нужды делать это вручную. Стек будет автоматически разрывать неактивные соединения. &prompt.root; hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16] Обратитесь к помощи посредством hccontrol help для получения полного списка доступных HCI-команд. Большинство команд HCI для выполнения не требуют прав администратора системы. L2CAP Logical Link Control and Adaptation Protocol (L2CAP) Протокол L2CAP (Logical Link Control and Adaptation Protocol) предоставляет услуги по работе с данными, как ориентированные на соединения, так и без ориентации на них, протоколам более высокого уровня с возможностями мультиплексирования и обеспечением операций по сегментации и обратной сборке. L2CAP позволяет протоколам более высокого уровня и приложениям передавать и получать пакеты данных L2CAP длиной до 64 Кбайт. L2CAP основан на концепции каналов. Каналом является логическое соединение поверх соединения по радиоканалу. Каждый канал привязан к некоторому протоколу по принципу многие-к-одному. Несколько каналов могут быть привязаны к одному и тому же протоколу, но канал не может быть привязан к нескольким протоколам. Каждый пакет L2CAP, получаемый каналом, перенаправляется к соответствующему протоколу более высокого уровня. Несколько каналов могут совместно использовать одно и то же радиосоединение. Для одного Bluetooth-устройства создается один узел Netgraph типа l2cap. Узел L2CAP обычно подключается к узлу Bluetooth HCI (нижестоящий) и узлам Bluetooth-сокетов (вышестоящие). По умолчанию для узла L2CAP используется имя devicel2cap. Для получения дополнительной информации обратитесь к справочной странице по &man.ng.l2cap.4;. Полезной является программа &man.l2ping.8;, которая может использоваться для проверки связи с другими устройствами. Некоторые реализации Bluetooth могут не возвращать все данные, посылаемые им, так что 0 bytes в следующем примере - это нормально. &prompt.root; l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 Утилита &man.l2control.8; используется для выполнения различных операций с узлами L2CAP. В этом примере показано, как получить список логических соединений (каналов) и перечень радиосоединений локального устройства: &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN &prompt.user; l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN Ещё одним диагностическим инструментом является &man.btsockstat.1;. Она выполняет действия, подобные тем, что обычно выполняет &man.netstat.1;, но со структурами данных, связанных с работой в сети Bluetooth. В примере ниже описывается то же самое логическое соединение, что и с &man.l2control.8; выше. &prompt.user; btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN RFCOMM Протокол RFCOMM Протокол RFCOMM эмулирует последовательные порты поверх протокола L2CAP. Он основан на ETSI-стандарте TS 07.10. RFCOMM представляет собой простой транспортный протокол, с дополнительными возможностями по эмуляции 9 цепей последовательных портов RS-232 (EIATIA-232-E). Протокол RFCOMM поддерживает одновременно до 60 соединений (каналов RFCOMM) между двумя устройствами Bluetooth. В рамках RFCOMM полный коммуникационный маршрут включает два приложения, работающие на разных устройствах (конечные коммуникационные точки) с коммуникационным сегментом между ними. RFCOMM предназначен для сокрытия приложений, использующих последовательные порты устройств, в которых они расположены. Коммуникационный сегмент по сути является Bluetooth-связью от одного устройства к другому (прямое соединение). RFCOMM имеет дело с соединением между устройствами в случае прямого соединения, или между устройством и модемом в сетевом случае. RFCOMM может поддерживать и другие конфигурации, такие, как модули, работающие через беспроводную технологию Bluetooth с одной стороны и предоставляющие проводное соединение с другой стороны. Во &os; протокол RFCOMM реализован на уровне сокетов Bluetooth. pairing Pairing of Devices По умолчанию связь Bluetooth не аутентифицируется, поэтому любое устройство может общаться с любым другим. Устройство Bluetooth (например, сотовый телефон) может задать обязательность аутентификации для предоставления определённого сервиса (в частности, услугу доступа по коммутируемой линии). Bluetooth-аутентификация обычно выполняется через PIN-коды. PIN-код представляет из себя ASCII-строку длиной до 16 символов. Пользователь обязан ввести один и тот же PIN-код на обоих устройствах. Как только он введёт PIN-код, оба устройства сгенерируют ключ связи. После этого ключ может быть сохранён либо в самом устройстве, либо на постоянном носителе. В следующий раз оба устройства будут использовать ранее сгенерированный ключ соединения. Процедура, описанная выше, носит название подгонки пары (pairing). Заметьте, что если ключ связи потерян любой из сторон, то подбор пары должен быть повторен. За обработку всех запросов на Bluetooth-аутентификацию отвечает даемон &man.hcsecd.8;. По умолчанию файл конфигурации называется /etc/bluetooth/hcsecd.conf. Пример раздела, содержащего информацию о сотовом телефоне с явно заданным PIN-кодом 1234 приведен ниже: device { bdaddr 00:80:37:29:19:a4; name "Pav's T39"; key nokey; pin "1234"; } Кроме длины, на PIN-коды не накладывается никаких ограничений. Некоторые устройства (например, Bluetooth-гарнитуры) могут иметь фиксированный встроенный PIN-код. Параметр позволяет запустить &man.hcsecd.8; как нефоновый процесс, что облегчает просмотр происходящих событий. Задайте получение парного ключа на удалённом устройстве и инициируйте Bluetooth-соединение с этим устройством. Удалённое устройство должно подтвердить получение пары и запросить PIN-код. Введите тот же самый код, что находится в hcsecd.conf. Теперь ваш ПК и удалённое устройство спарены. Альтернативным способом является инициация процесса создания пары на удалённом устройстве. Во &os; 5.5, 6.1 и в более новых, следующая строка может быть добавлена к /etc/rc.conf, чтобы hcsecd запускался автоматически во время старта системы: hcsecd_enable="YES" Ниже даётся пример выдачи протокола команды hcsecd: hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 SDP Service Discovery Protocol (SDP) Протокол обнаружения сервисов SDP даёт возможность клиентским приложениям осуществлять поиск услуг, предоставляемых серверными приложениями, а также характеристик этих услуг. В перечень атрибутов сервиса включается тип класса предлагаемого сервиса и информация о механизме или протоколе, требуемом для использования сервиса. SDP подразумевает коммуникации между SDP-сервером и SDP-клиентом. Сервер поддерживает список сервисов, в котором описываются параметры сервисов, связанных с сервером. Каждая запись об услуге содержит информацию об одном сервисе. Клиент может запросить информацию об определённом сервисе, обслуживаемом SDP-сервером, выдавая SDP-запрос. Если клиент или приложение, связанное с клиентом, решат воспользоваться сервисом, то для его использования необходимо открыть отдельное соединение к устройству, предоставляющему сервис. SDP предоставляет механизм обнаружения услуг и их параметров, но не даёт механизма использования этих сервисов. Обычно SDP-клиент выполняет поиск услуг на основе некоторых желаемых характеристик услуг. Однако иногда возникает необходимость выяснить полный перечень типов услуг, предоставляемых SDP-сервером, не имея никакой информации об имеющихся сервисах. Такой процесс всех предлагаемых сервисов называется обзором (browsing). Bluetooth SDP сервер &man.sdpd.8; и клиент с интерфейсом командной строки &man.sdpcontrol.8; включены в стандартную поставку &os;. В следующем примере показано, как выполнять запрос на SDP-обзор. &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse Record Handle: 00000000 Service Class ID List: Service Discovery Server (0x1000) Protocol Descriptor List: L2CAP (0x0100) Protocol specific parameter #1: u/int/uuid16 1 Protocol specific parameter #2: u/int/uuid16 1 Record Handle: 0x00000001 Service Class ID List: Browse Group Descriptor (0x1001) Record Handle: 0x00000002 Service Class ID List: LAN Access Using PPP (0x1102) Protocol Descriptor List: L2CAP (0x0100) RFCOMM (0x0003) Protocol specific parameter #1: u/int8/bool 1 Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0 ... и так далее. Заметьте, что каждый сервис имеет перечень атрибутов (например, канал RFCOMM). В зависимости от сервиса вам может потребоваться где-то сохранить эти атрибуты. Некоторые реализации Bluetooth не поддерживают просмотр сервисов и могут возвращать пустой список. В этом случае возможен поиск конкретной услуги. В примере ниже показано, как выполнить поиск службы OBEX Object Push (OPUSH): &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH Во &os; предоставление сервисов клиентам Bluetooth осуществляется сервером &man.sdpd.8;. Во &os; 5.5, 6.1 и в более новых, следующая строка может быть добавлена в файл /etc/rc.conf: sdpd_enable="YES" После этого sdpd даемон может быть запущен с помощью: &prompt.root; /etc/rc.d/sdpd start Во &os; 6.0, и во &os; 5.X перед 5.5, sdpd не интегрирован в скрипты загрузки системы. Он должен запускаться автоматически командой: &prompt.root; sdpd Приложение на локальном сервере, желающее предоставить сервис Bluetooth удаленным клиентам, регистрирует сервис через локального даемона SDP. Пример такого приложения — &man.rfcomm.pppd.8;. После запуска оно регистрирует Bluetooth LAN сервис через локального даемона SDP. Список сервисов, зарегистрированных через локальный SDP сервер, может быть получен путем выдачи запроса на просмотр SDP через локальный контрольный канал: &prompt.root; sdpcontrol -l browse Доступ к сети по коммутируемой линии связи (DUN) и по протоколу PPP (LAN) Модуль работы с коммутируемым доступом к сети (DUN - Dial-Up Networking) в большинстве случаев используется с модемами и сотовыми телефонами. Этот модуль покрывает следующие случаи: сотовый телефон или модем используется вместе с компьютером в качестве беспроводного модема для подключения к серверу коммутируемого доступа в Интернет, или другой коммутируемой услуге; сотовый телефон или модем используется компьютером для приёма входящих соединений. Модуль доступа к сети по протоколу PPP (Network Access with PPP - LAN) может использоваться в следующих ситуациях: доступ к ЛВС для одного Bluetooth-устройства; доступ к ЛВС для нескольких Bluetooth-устройств; связь между двумя ПК (при помощи протокола PPP поверх эмулируемого последовательного канала связи). Во &os; оба случая реализуются при помощи сервисных программ &man.ppp.8; и &man.rfcomm.pppd.8; - это обработчик, преобразующий RFCOMM-соединения Bluetooth в нечто, с чем может работать PPP. Перед тем, как использовать любой модуль, в файле /etc/ppp/ppp.conf должна быть создана новая PPP-метка. Примеры использования можно найти в справочной странице к &man.rfcomm.pppd.8;. В следующем примере &man.rfcomm.pppd.8; будет использоваться для открытия RFCOMM-соединения к удалённому устройству с BD_ADDR 00:80:37:29:19:a4 на DUN RFCOMM-канале. Реальный номер RFCOMM-канала будет получаться с удалённого устройства через SDP. Возможно указать RFCOMM-канал вручную, и в этом случае &man.rfcomm.pppd.8; не будет выполнять SDP-запрос. Для нахождения RFCOMM-канала на удалённом устройстве используйте утилиту &man.sdpcontrol.8;. &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup Для того, чтобы организовать сервис Network Access with PPP (LAN), необходимо запустить сервер &man.sdpd.8;. В файле /etc/ppp/ppp.conf должна быть создана новая запись для клиентов LAN. Примеры можно найти в справке по &man.rfcomm.pppd.8;. Наконец, запустите RFCOMM PPP сервер на существующем номере канала RFCOMM. Сервер RFCOMM PPP автоматически зарегистрирует Bluetooth LAN сервис через локальный SDP даемон. В примере ниже показано, как запустить сервер RFCOMM PPP. &prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-server OBEX OBEX Object Push (OPUSH) Profile OBEX является широко используемым протоколом для простой передачи файлов между мобильными устройствами. В основном он используется в коммуникациях через инфракрасный порт для передачи файлов между ноутбуками или КПК, а также для пересылки визитных карточек или календарных планов между сотовыми телефонами и другими устройствами с персональными информационными менеджерами. Сервер и клиент OBEX реализованы в виде пакета стороннего разработчика obexapp, который доступен в виде порта comms/obexapp. Клиент OBEX используется для посылки или приёма объектов с сервера OBEX. Объектом, к примеру, может быть визитная карточка или указание. Клиент OBEX может получить номер RFCOMM-канала, указав вместо него имя сервиса. Поддерживаются следующие имена сервиса: IrMC, FTRN и OPUSH. Канал RFCOMM можно задать его номером. Ниже даётся пример сеанса OBEX, где с сотового телефона забирается объект с информацией об устройстве, а новый объект (визитная карточка) передаётся в каталог сотового телефона. &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get telecom/devinfo.txt devinfo-t39.txt Success, response: OK, Success (0x20) obex> put new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20) Для того, чтобы предоставить сервис OBEX Push, должен быть запущен сервер &man.sdpd.8;. Должен быть создан корневой каталог, в котором будут сохраняться все поступающие объекты. По умолчанию корневым каталогом является /var/spool/obex. Наконец, запустите OBEX сервер на существующем номере канала RFCOMM. OBEX сервер автоматически зарегистрирует сервис OBEX Object Push через локального даемона SDP. В примере ниже показано, как запустить OBEX-сервер. &prompt.root; obexapp -s -C 10 Профиль последовательного порта (SPP) Профиль последовательного порта (SPP - Serial Port Profile) позволяет Bluetooth-устройствам осуществлять эмуляцию последовательного порта RS232 (или подобного). Этот профиль покрывает случаи, касающиеся работы унаследованных приложений с Bluetooth в качестве замены кабельному соединению, при это используется абстракция виртуального последовательного порта. Утилита &man.rfcomm.sppd.1; реализует профиль последовательного порта. В качестве виртуального последовательного порта используется псевдо-терминал. В примере ниже показано, как подключиться к сервису Serial Port удалённого устройства. Заметьте, что вы не указываете RFCOMM-канал - &man.rfcomm.sppd.1; может получить его с удалённого устройства через SDP. Если вы хотите переопределить это, укажите RFCOMM-канал явно в командной строке. &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... После подключения псевдо-терминал можно использовать как последовательный порт: &prompt.root; cu -l ttyp6 Решение проблем Удалённое устройство не подключается Некоторые старые Bluetooth-устройства не поддерживают переключение ролей. По умолчанию, когда &os; подтверждает новое соединение, она пытается выполнить переключение роли и стать ведущим устройством. Устройства, которые это не поддерживают, не смогут подключиться. Заметьте, что переключение ролей выполняется при установлении нового соединения, поэтому невозможно выяснить, поддерживает ли удалённое устройство переключение ролей. На локальной машине имеется возможность отключить переключение ролей при помощи HCI-параметра: &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 Что-то идёт не так, можно ли посмотреть, что в точности происходит? Да, можно. Воспользуйтесь пакетом стороннего разработчика, hcidump который доступен в виде порта comms/hcidump. Утилита hcidump похожа на &man.tcpdump.1;. Она может быть использована для вывода на терминал содержимого Bluetooth-пакетов и сбрасывать пакеты Bluetooth в файл. Steve Peterson Текст создал Мосты Введение подсеть IP сетевой мост Иногда полезно разделить одну физическую сеть (такую, как сегмент Ethernet) на два отдельных сегмента сети без необходимости создания подсетей IP и использования маршрутизатора для соединения сегментов. Устройство, которое соединяет две сети на такой манер, называется сетевым мостом (bridge). Система FreeBSD с двумя сетевыми адаптерами может выступать в роли моста. Мост работает на основе изучения адресов уровня MAC (адресов Ethernet) устройств на каждом из своих сетевых интерфейсах. Он перенаправляет трафик между двумя сетями, только когда адреса отправителя и получателя находятся в разных сетях. По многим параметрам мост работает также, как коммутатор Ethernet с малым количеством портов. Ситуации, когда можно использовать мосты На сегодняшний день есть две ситуации, когда можно использовать мост. Большой трафик в сегменте Первая ситуация возникает, когда ваша физическая сеть перегружена трафиком, но по каким-то соображениям вы не хотите разделять сеть на подсети и соединять их с помощью маршрутизатора. Давайте рассмотрим в качестве примера газету, в которой редакторский и производственный отделы находятся в одной и той же подсети. Пользователи в редакторском отделе все используют сервер A для служб доступа к файлам, а пользователи производственного отдела используют сервер B. Для объединения всех пользователей используется сеть Ethernet, а высокая нагрузка на сеть замедляет работу. Если пользователи редакторского отдела могут быть собраны в одном сегменте сети, а пользователи производственного отдела в другом, то два сетевых сегмента можно объединить мостом. Только сетевой трафик, предназначенный для интерфейсов с другой стороны моста, будет посылаться в другую сеть, тем самым снижая уровень нагрузки на каждый сегмент сети. Сетевой экран с возможностями фильтрации/ограничения пропускной способности трафика сетевой экран NAT Второй распространённой ситуацией является необходимость в обеспечении функций сетевого экрана без трансляции сетевых адресов (NAT). Для примера можно взять маленькую компанию, которая подключена к своему провайдеру по каналу DSL или ISDN. Для неё провайдер выделил 13 глобально доступных IP-адресов для имеющихся в сети 10 персональных компьютеров. В такой ситуации использование сетевого экрана на основе маршрутизатора затруднено из-за проблем с разделением на подсети. маршрутизатор DSL ISDN Брандмауэр на основе моста может быть настроен и включен между маршрутизаторами DSL/ISDN без каких-либо проблем с IP-адресацией. Настройка моста Выбор сетевого адаптера Для работы моста требуются по крайней мере два сетевых адаптера. К сожалению, не все сетевые адаптеры во FreeBSD 4.0 поддерживают функции моста. Прочтите страницу Справочника по &man.bridge.4; для выяснения подробностей о поддерживаемых адаптерах. Перед тем, как продолжить, сначала установите и протестируйте два сетевых адаптера. Изменения в конфигурации ядра параметры ядра BRIDGE Для включения поддержки функций сетевого моста в ядре, добавьте строчку options BRIDGE в файл конфигурации вашего ядра, и перестройте ядро. Поддержка функций брандмауэра брандмауэр Если вы планируете использовать мост в качестве брандмауэра, вам нужно также добавить опцию IPFIREWALL. Прочтите , содержащую общую информацию о настройке моста в качестве брандмауэра. Если вам необходимо обеспечить прохождение не-IP пакетов (таких, как ARP) через мост, то имеется опция брандмауэра, которую можно задать. Это опция IPFIREWALL_DEFAULT_TO_ACCEPT. Заметьте, что при этом правило, используемое брандмауэром по умолчанию, меняется на разрешительное для всех пакетов. Перед тем, как задавать эту опцию, убедитесь, что вы понимаете работу вашего набора правил. Поддержка функций ограничения пропускной способности Если вы хотите использовать мост в качестве машины, ограничивающей пропускную способность, то добавьте в файл конфигурации ядра опцию DUMMYNET. Дополнительную информацию можно почерпнуть из страницы Справочника по &man.dummynet.4;. Включение функций моста Добавьте строку net.link.ether.bridge.enable=1 в файл /etc/sysctl.conf для включения функций моста во время работы системы, и строку: net.link.ether.bridge.config=if1,if2 для включения функций моста для указанных интерфейсов (замените if1 и if2 на имена двух ваших сетевых интерфейсов). Если вы хотите, чтобы проходящие через мост пакеты фильтровались посредством &man.ipfw.8;, вы должны также добавить строчку: net.link.ether.bridge.ipfw=1 Для версий &os;, предшествующих &os; 5.2-RELEASE, нужно использовать следующие строки: net.link.ether.bridge=1 net.link.ether.bridge_cfg=if1,if2 net.link.ether.bridge_ipfw=1 Дополнительные замечания Если вы хотите осуществлять удалённый доступ на мост через &man.ssh.1; из сети, то корректно назначить одному из сетевых адаптеров IP-адрес. Общепринято, что назначение адреса обоим сетевым адаптерам является не самой хорошей идеей. Если в вашей сети присутствует несколько мостов, не должно быть более одного маршрута между любыми двумя рабочими станциями. С технической точки зрения это означает отсутствие поддержки протокола spanning tree. Сетевой мост может увеличить задержки в замерах командой &man.ping.8;, особенно для трафика между двумя разными сегментами. Jean-François Dockès Текст обновил Alex Dupre Реорганизовал и улучшил Работа с бездисковыми станциями работа без диска Машина с FreeBSD может загружаться по сети и работать без наличия локального диска, используя файловые системы, монтируемые с сервера NFS. Кроме стандартных конфигурационных файлов, не нужны никакие модификации в системе. Такую систему легко настроить, потому что все необходимые элементы уже готовы: Имеется по крайней мере два возможных способа загрузки ядра по сети: PXE: Система &intel; Preboot eXecution Environment является формой загрузочного ПЗУ, встроенного в некоторые сетевые адаптеры или материнские платы. Обратитесь к справочной странице по &man.pxeboot.8; для получения более полной информации. Порт Etherboot (net/etherboot) генерирует код, который может применяться в ПЗУ для загрузки ядра по сети. Код может быть либо прошит в загрузочный PROM на сетевом адаптере, либо загружен с локальной дискеты (или винчестера), или с работающей системы &ms-dos;. Поддерживаются многие сетевые адаптеры. Примерный скрипт (/usr/share/examples/diskless/clone_root) облегчает создание и поддержку корневой файловой системы рабочей станции на сервере. Скрипт, скорее всего, потребует некоторых настроек, но он позволит вам быстро начать работу. Стандартные файлы начального запуска системы, располагающиеся в /etc, распознают и поддерживают загрузку системы в бездисковом варианте. Подкачка, если она нужна, может выполняться через файл NFS либо на локальный диск. Существует много способов настройки бездисковой рабочей станции. При этом задействованы многие компоненты, и большинство из них могут быть настроены для удовлетворения ваших вкусов. Далее будет описаны варианты полной настройки системы, при этом упор будет делаться на простоту и совместимость с стандартной системой скриптов начальной загрузки FreeBSD. Описываемая система имеет такие характеристики: Бездисковые рабочие станции совместно используют файловую систему / в режиме только чтения, а также используют /usr совместно тоже в режиме только чтения. Корневая файловая система является копией стандартной корневой системы FreeBSD (обычно сервера), с некоторыми настроечными файлами, измененными кем-то специально для бездисковых операций или, возможно, для рабочей станции, которой она предназначена. Части корневой файловой системы, которые должны быть доступны для записи, перекрываются файловыми системами &man.mfs.8; (&os; 4.X) или &man.md.4; (&os; 5.X). Любые изменения будут потеряны при перезагрузках системы. Ядро передается и загружается посредством Etherboot или PXE, и в некоторых ситуациях может быть использован любой из этих методов. Как описано, эта система не защищена. Она должна располагаться в защищенной части сети, а другие хосты не должны на нее полагаться. Вся информация этого раздела была протестирована с релизами &os; 4.9-RELEASE и 5.2.1-RELEASE. Текст структурирован преимущественно для использования с 4.X. Отличия для 5.X упоминаются особо. Общая информация Настройка бездисковых рабочих станций относительно проста, но в то же время легко сделать ошибку. Иногда сложно диагностировать эти ошибки по нескольким причинам. Например: Параметры компиляции могут по-разному проявлять себя во время работы. Сообщения об ошибках бывают загадочны или вовсе отсутствуют. В данной ситуации некоторые знания, касающиеся используемых внутренних механизмов, очень полезны при разрешении проблем, которые могут возникнуть. Для выполнения успешной загрузки необходимо произвести несколько операций: Компьютеру необходимо получить начальные параметры, такие как собственный IP адрес, имя исполняемого файла, корневой каталог. Для этого используются протоколы DHCP или BOOTP. DHCP это совместимое расширение BOOTP, используются те же номера портов и основной формат пакетов. Возможна настройка системы для использования только BOOTP. Серверная программа &man.bootpd.8; включена в основную систему &os;. Тем не менее, у DHCP есть множество преимуществ над BOOTP (лучше файлы настройки, возможность использования PXE, плюс многие другие преимущества, не относящиеся непосредственно к бездисковым операциям), и мы в основном будем описывать настройку DHCP, с эквивалентными примерами для &man.bootpd.8;, когда это возможно. Пример конфигурации будет использовать пакет ISC DHCP (релиз 3.0.1.r12 был установлен на тестовом сервере). Компьютеру требуется загрузить в локальную память одну или несколько программ. Используются TFTP или NFS. Выбор между TFTP или NFS производится во время компилирования в нескольких местах. Часто встречающаяся ошибка это указание имен файлов для другого протокола: TFTP обычно загружает все файлы с одного каталога сервера, и принимает имена файлов относительно этого каталога. NFS нужны абсолютные пути к файлам. Необходимо инициализировать и выполнить возможные промежуточные программы загрузки и ядро. В этой области существует несколько важных вариаций: PXE загрузит &man.pxeboot.8;, являющийся модифицированной версией загрузчика третьей стадии &os;. &man.loader.8; получит большинство параметров, необходимых для старта системы, и оставит их в окружении ядра до контроля передачи. В этом случае возможно использование ядра GENERIC. Etherboot, непосредственно загрузит ядро, с меньшей подготовкой. Вам потребуется собрать ядро со специальными параметрами. PXE и Etherboot работают одинаково хорошо с системами 4.X. Поскольку ядро 5.X обычно позволяет &man.loader.8; выполнить больше предварительной работы, метод PXE на системах 5.X предпочтителен. Если ваш BIOS и сетевые карты поддерживают PXE, используйте его. Однако, все же возможен запуск системы 5.X с Etherboot. Наконец, компьютеру требуется доступ к файловым системам. NFS используется во всех случаях. Обратитесь также к странице справочника &man.diskless.8;. Инструкции по настройке Конфигурация с использованием ISC DHCP DHCP бездисковые конфигурации Сервер ISC DHCP может обрабатывать как запросы BOOTP, так и запросы DHCP. Начиная с релиза 4.9, ISC DHCP 3.0 не включается в поставку системы. Сначала вам нужно будет установить порт net/isc-dhcp3-server или соответствующий пакет. После установки ISC DHCP ему для работы требуется конфигурационный файл (обычно называемый /usr/local/etc/dhcpd.conf). Вот прокомментированный пример, где хост margaux использует Etherboot, а хост corbieres использует PXE: default-lease-time 600; max-lease-time 7200; authoritative; option domain-name "example.com"; option domain-name-servers 192.168.4.1; option routers 192.168.4.1; subnet 192.168.4.0 netmask 255.255.255.0 { use-host-decl-names on; option subnet-mask 255.255.255.0; option broadcast-address 192.168.4.255; host margaux { hardware ethernet 01:23:45:67:89:ab; fixed-address margaux.example.com; next-server 192.168.4.4; filename "/data/misc/kernel.diskless"; option root-path "192.168.4.4:/data/misc/diskless"; } host corbieres { hardware ethernet 00:02:b3:27:62:df; fixed-address corbieres.example.com; next-server 192.168.4.4; filename "pxeboot"; option root-path "192.168.4.4:/data/misc/diskless"; } } Этот параметр указывает dhcpd посылать значения деклараций host как имя хоста для бездисковой машины. Альтернативным способом было бы добавление option host-name margaux внутри объявлений host. Директива next-server определяет сервер TFTP или NFS, используемый для получения загрузчика или файла ядра (по умолчанию используется тот же самый хост, на котором расположен сервер DHCP). Директива filename определяет файл, который Etherboot или PXE будут загружать для следующего шага выполнения. Он должен быть указан в соответствии с используемым методом передачи. Etherboot может быть скомпилирован для использования NFS или TFTP. &os; порт по умолчанию использует NFS. PXE использует TFTP, поэтому здесь применяются относительные пути файлов (это может зависеть от настроек TFTP сервера, но обычно довольно типично). Кроме того, PXE загружает pxeboot, а не ядро. Существуют другие интересные возможности, такие как загрузка pxeboot из каталога /boot &os; CD-ROM (поскольку &man.pxeboot.8; может загружать GENERIC ядро, это делает возможной загрузку с удаленного CD-ROM). Параметр root-path определяет путь к корневой файловой системе, в обычной нотации NFS. При использовании PXE, можно оставить IP хоста отключенным, если параметр ядра BOOTP не используется. Затем NFS сервер может использоваться так же, как и TFTP. Настройка с использованием BOOTP BOOTP бездисковые конфигурации Далее описана эквивалентная конфигурация с использованием bootpd (для одного клиента). Она будет располагаться в /etc/bootptab. Пожалуйста, отметьте, что Etherboot должен быть откомпилирован с нестандартной опцией NO_DHCP_SUPPORT для того, чтобы можно было использовать BOOTP, и что для работы PXE необходим DHCP. Единственным очевидным преимуществом bootpd является его наличие в поставке системы. .def100:\ :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ :sm=255.255.255.0:\ :ds=192.168.4.1:\ :gw=192.168.4.1:\ :hd="/tftpboot":\ :bf="/kernel.diskless":\ :rp="192.168.4.4:/data/misc/diskless": margaux:ha=0123456789ab:tc=.def100 Подготовка программы загрузки при помощи <application>Etherboot</application> Etherboot Сайт Etherboot содержит подробную документацию, в основном предназначенную для систем Linux, но несомненно, она полезна. Далее будет просто кратко описано, как вы должны использовать Etherboot в системе FreeBSD. Сначала вы должны установить пакет или порт net/etherboot. Вы можете изменить настройку Etherboot (например, для использования TFTP вместо NFS) путем редактирования файла Config в каталоге исходных текстов Etherboot. В нашей ситуации мы будем использовать загрузочную дискету. Для других методов (PROM или программа &ms-dos;) пожалуйста, обратитесь к документации по Etherboot. Для создания загрузочной дискеты, вставьте дискету в дисковод на машине, где установлен Etherboot, затем перейдите в каталог src в дереве Etherboot и наберите: &prompt.root; gmake bin32/devicetype.fd0 devicetype зависит от типа адаптера Ethernet на бездисковой рабочей станции. Обратитесь к файлу NIC в том же самом каталоге для определения правильного значения для devicetype. Загрузка с <acronym>PXE</acronym> По умолчанию, &man.pxeboot.8; загружает ядро через NFS. Он может быть скомпилирован для использования вместо него TFTP путем указания параметра LOADER_TFTP_SUPPORT в /etc/make.conf. Смотрите комментарии в /etc/defaults/make.conf (или /usr/share/examples/etc/make.conf систем 5.X) с инструкциями. Есть два не документированных параметра make.conf, которые могут быть полезны для настройки бездискового компьютера с последовательной консолью: BOOT_PXELDR_PROBE_KEYBOARD, и BOOT_PXELDR_ALWAYS_SERIAL (последняя существует только в &os; 5.X). Для использования PXE при загрузке компьютера вам обычно потребуется выбрать параметр Boot from network (загрузка по сети) в настройках BIOS, или нажать функциональную клавишу во время загрузки PC. Настройка серверов <acronym>TFTP</acronym> и <acronym>NFS</acronym> TFTP бездисковые конфигурации NFS бездисковые конфигурации Если вы используете PXE или Etherboot, настроенные для использования TFTP, вам нужно включить tftpd на файловом сервере: Создайте каталог, файлы которого будет обслуживать tftpd, например, /tftpboot. Добавьте в ваш /etc/inetd.conf такую строчку: tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot Бывает, что некоторым версиям PXE требуется TCP-вариант TFTP. В таком случае добавьте вторую строчку, заменяющую dgram udp на stream tcp. Укажите inetd на повторное чтение своего конфигурационного файла: &prompt.root; kill -HUP `cat /var/run/inetd.pid` Вы можете поместить каталог tftpboot в любом месте на сервере. Проверьте, что это местоположение указано как в inetd.conf, так и в dhcpd.conf. Во всех случаях, вам также нужно включить NFS и экспортировать соответствующую файловую систему на сервере NFS. Добавьте следующее в /etc/rc.conf: nfs_server_enable="YES" Экспортируйте файловую систему, в которой расположен корневой каталог для бездисковой рабочей станции, добавив следующую строку в /etc/exports (подправьте точку монтирования и замените margaux corbieres именами бездисковых рабочих станций): /data/misc -alldirs -ro margaux corbieres Укажите mountd на повторное чтение настроечного файла. На самом деле если вам потребовалось на первом шаге включить NFS в /etc/rc.conf, то вам нужно будет выполнить перезагрузку. &prompt.root; kill -HUP `cat /var/run/mountd.pid` Построение ядра для бездисковой рабочей станции бездисковые конфигурации настройка ядра При использовании Etherboot, вам потребуется создать конфигурационный файл ядра для бездискового клиента со следующими параметрами (вдобавок к обычным): options BOOTP # Use BOOTP to obtain IP address/hostname options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info Вам может потребоваться использовать BOOTP_NFSV3, BOOT_COMPAT и BOOTP_WIRED_TO (посмотрите LINT в 4.X или NOTES в 5.X). Эти имена параметров сложились исторически, и могут немного ввести в заблуждение, поскольку включают необязательное использование DHCP и BOOTP в ядре (возможно включение обязательного использования BOOTP или DHCP use). Постройте ядро (обратитесь к ) и скопируйте его в каталог, указанный в dhcpd.conf. При использовании PXE, сборка ядра с вышеприведенными параметрами не является совершенно необходимой (хотя желательна). Включение этих параметров приведет к выполнению большинства DHCP запросов во время загрузки ядра, с небольшим риском несоответствия новых значений и значений, полученных &man.pxeboot.8; в некоторых особых случаях. Преимущество использования в том, что в качестве побочного эффекта будет установлено имя хоста. Иначе вам потребуется установить имя хоста другим методом, например в клиент-специфичном файле rc.conf. Для включения возможности загрузки с Etherboot, в ядро 5.X необходимо включить устройство hints. Вам потребуется установить в файле конфигурации следующий параметр (см. файл комментариев NOTES): hints "GENERIC.hints" Подготовка корневой файловой системы корневая файловая система бездисковые конфигурации Вам нужно создать корневую файловую систему для бездисковых рабочих станций, в местоположении, заданном как root-path в dhcpd.conf. В следующем разделе описаны два способа, чтобы сделать это. Использование скрипта <filename>clone_root</filename> Это самый простой способ создания корневой файловой системы, но на данный момент он не поддерживается в &os; 4.X. Этот shell скрипт находится в /usr/share/examples/diskless/clone_root, и требует настройки, по крайней мере, задания того места, где будет создана файловая система (переменная DEST). Прочтите комментарии в начале скрипта для получения указаний. Там описано, как строится основная файловая система, и как файлы могут быть выборочно заменены версиями, предназначенными для работы без диска, для подсети или для отдельной рабочей станции. Также здесь даются примеры бездисковых файлов /etc/fstab и /etc/rc.conf. Файлы README в /usr/share/examples/diskless много интересной информации, но вместе с другими примерами из каталога diskless они на самом деле описывают метод настройки, который отличается от того, что используется в clone_root и стартовых скриптах системы из /etc, этим несколько запутывая дело. Используйте их только для справки, за исключением того случая, когда вы выберете метод, ими описываемый, и тогда вам нужны исправленные скрипты rc. Использование стандартной процедуры <command>make world</command> Этот метод может быть применен к &os; 4.X или 5.X и установит новую систему (не только корневую) в DESTDIR. Все, что вам потребуется сделать, это просто выполнить следующий скрипт: #!/bin/sh export DESTDIR=/data/misc/diskless mkdir -p ${DESTDIR} cd /usr/src; make world && make kernel cd /usr/src/etc; make distribution Как только это будет сделано, вам может потребоваться настроить /etc/rc.conf и /etc/fstab, помещенные в DESTDIR, в соответствии с вашими потребностями. Настройка области подкачки Если это нужно, то файл подкачки, расположенный на сервере, можно использовать посредством NFS. Один из методов, используемых для этого, не поддерживается в релизах 5.X. Подкачка по <acronym>NFS</acronym> в &os; 4.X Местоположение и размер файла подкачки могут быть указаны &os;-специфичными параметрами BOOTP/DHCP 128 и 129. Примеры файлов настройки для ISC DHCP 3.0 или bootpd приведены ниже: Добавьте следующие строки в dhcpd.conf: # Global section option swap-path code 128 = string; option swap-size code 129 = integer 32; host margaux { ... # Standard lines, see above option swap-path "192.168.4.4:/netswapvolume/netswap"; option swap-size 64000; } swap-path это путь к каталогу, где находятся файлы подкачки. Название каждого файла имеет вид swap.client-ip. Старые версии dhcpd использовали синтаксис option option-128 "..., который больше не поддерживается. Во /etc/bootptab будет использоваться такой синтаксис: T128="192.168.4.4:/netswapvolume/netswap":T129=0000fa00 В файле /etc/bootptab размер файла подкачки должен быть записан в шестнадцатеричном формате. На файловом сервере NFS создайте файл (или файлы) подкачки: &prompt.root; mkdir /netswapvolume/netswap &prompt.root; cd /netswapvolume/netswap &prompt.root; dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6 &prompt.root; chmod 0600 swap.192.168.4.6 192.168.4.6 является IP-адресом бездискового клиента. На файловом сервере NFS, в /etc/exports добавьте такую строку: /netswapvolume -maproot=0:10 -alldirs margaux corbieres Затем укажите mountd на повторное чтение файла exports, как описано ранее. Подкачка по <acronym>NFS</acronym> в &os; 4.X Положение и размер файла подкачки могут быть указаны в &os;-специфичных параметрах BOOTP/DHCP с номерами 128 и 129. Ниже приведены примеры файлов настройки для ISC DHCP 3.0 или bootpd: Добавьте следующие строки к dhcpd.conf: # Global section option swap-path code 128 = string; option swap-size code 129 = integer 32; host margaux { ... # Standard lines, see above option swap-path "192.168.4.4:/netswapvolume/netswap"; option swap-size 64000; } swap-path это путь к каталогу, где расположены файлы подкачки. Файлы называются swap.client-ip. Старые версии dhcpd используют синтаксис option option-128 "..., которые более не поддерживаются. /etc/bootptab вместо этого использует следующий синтаксис: T128="192.168.4.4:/netswapvolume/netswap":T129=0000fa00 В /etc/bootptab, размер подкачки должен вычисляться в шестнадцатеричном формате. Создайте на NFS сервере с файлами подкачки файлы: &prompt.root; mkdir /netswapvolume/netswap &prompt.root; cd /netswapvolume/netswap &prompt.root; dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6 &prompt.root; chmod 0600 swap.192.168.4.6 192.168.4.6 это IP адрес бездискового клиента. На файловом сервере NFS с файлами подкачки добавьте следующую строку к /etc/exports: /netswapvolume -maproot=0:10 -alldirs margaux corbieres Затем заставьте mountd перечитать конфигурационные файлы как было показано выше. Различные проблемы Работа с <filename>/usr</filename>, доступной только для чтения бездисковые конфигурации /usr только для чтения Если бездисковая рабочая станция настроена на запуск X, вам нужно подправить настроечный файл для XDM, который по умолчанию помещает протокол ошибок в /usr. Использование не-FreeBSD сервера Если сервер с корневой файловой системой работает не под управлением FreeBSD, вам потребуется создать корневую файловую систему на машине FreeBSD, а затем скопировать ее в нужно место, при помощи tar или cpio. В такой ситуации иногда возникают проблемы со специальными файлами в /dev из-за различной разрядности целых чисел для старшего/младшего чисел. Решением этой проблемы является экспортирование каталога с не-FreeBSD сервера, монтирование его на машине с FreeBSD и запуск скрипта MAKEDEV на машине с FreeBSD для создания правильных файлов устройств (во FreeBSD 5.0 и более поздних версиях используется &man.devfs.5; для создания файлов устройств прозрачно для пользователя, запуск MAKEDEV в этих версиях бессмысленно). ISDN ISDN Полезным источником информации о технологии ISDN и его аппаратном обеспечении является Страница Дэна Кегела (Dan Kegel) об ISDN. Быстрое введение в ISDN: Если вы живёте в Европе, то вам может понадобиться изучить раздел об ISDN-адаптерах. Если вы планируете использовать ISDN в основном для соединений с Интернет через провайдера по коммутируемому, не выделенному соединению, рекомендуется посмотреть информацию о терминальных адаптерах. Это даст вам самую большую гибкость и наименьшее количество проблем при смене провайдера. Если вы объединяете две локальные сети или подключаетесь к Интернет через постоянное ISDN-соединение, рекомендуем остановить свой выбор на отдельном мосте/маршрутизаторе. Стоимость является важным фактором при выборе вашего решения. Далее перечислены все возможности от самого дешевого до самого дорогого варианта. Hellmuth Michaelis Текст предоставил Адаптеры ISDN ISDN адаптеры Реализация ISDN во FreeBSD поддерживает только стандарт DSS1/Q.931 (или Евро-ISDN) при помощи пассивных адаптеров. Начиная с FreeBSD 4.4 поддерживаются некоторые активные адаптеры, прошивки которых поддерживают также другие сигнальные протоколы; также сюда впервые включена поддержка адаптеров ISDN Primary Rate (PRI). Пакет программ isdn4bsd позволяет вам подключаться к другим маршрутизаторам ISDN при помощи IP поверх DHLC, либо при помощи синхронного PPP; либо при помощи PPP на уровне ядра с isppp, модифицированного драйвера &man.sppp.4;, или при помощи пользовательского &man.ppp.8;. При использовании пользовательского &man.ppp.8; возможно использование двух и большего числа B-каналов ISDN. Также имеется приложение, работающее как автоответчик, и много утилит, таких, как программный модем на 300 Бод. Во FreeBSD поддерживается все возрастающее число адаптеров ISDN для ПК, и сообщения показывают, что они успешно используются по всей Европе и других частях света. Из пассивных адаптеров ISDN поддерживаются в основном те, которые сделаны на основе микросхем Infineon (бывший Siemens) ISAC/HSCX/IPAC ISDN, а также адаптеры ISDN с микросхемами от Cologne Chip (только для шины ISA), адаптеры PCI с микросхемами Winbond W6692, некоторые адаптеры с набором микросхем Tiger300/320/ISAC и несколько адаптеров, построенных на фирменных наборах микросхем, такие, как AVM Fritz!Card PCI V.1.0 и AVM Fritz!Card PnP. На данный момент из активных адаптеров ISDN поддерживаются AVM B1 (ISA и PCI) адаптеры BRI и AVM T1 PCI адаптеры PRI. Документацию по isdn4bsd можно найти в каталоге /usr/share/examples/isdn/ вашей системы FreeBSD или на домашней странице isdn4bsd, на которой также размещены ссылки на советы, замечания по ошибкам и более подробную информацию, например, на руководство по isdn4bsd. Если вы заинтересованы в добавлении поддержки для различных протоколов ISDN, не поддерживаемых на данный момент адаптеров ISDN для PC или каких-то других усовершенствованиях isdn4bsd, пожалуйста, свяжитесь с &a.hm;. Для обсуждения вопросов, связанных с установкой, настройкой и устранением неисправностей isdn4bsd, имеется список рассылки &a.isdn.name;. subscribe freebsd-isdn Терминальные адаптеры ISDN Терминальные адаптеры (TA) для ISDN выполняют ту же роль, что и модемы для обычных телефонных линий. модем Большинство TA используют стандартный набор AT-команд Hayes-модемов, и могут использоваться в качестве простой замены для модемов. TA будут работать точно так же, как и модемы, за исключением скорости соединения и пропускной способности, которые будут гораздо выше, чем у вашего старого модема. Вам потребуется настроить PPP точно также, как и в случае использования модема. Проверьте, что вы задали скорость работы последовательного порта максимально высокой. PPP Главным преимуществом использования TA для подключения к провайдеру Интернет является возможность использования динамического PPP. Так как пространство адресов IP истощается все больше, большинство провайдеров не хочет больше выдавать вам статический IP-адрес. Большинство же маршрутизаторов не может использовать динамическое выделение IP-адресов. TA полностью полагаются на даемон PPP, который используете из-за его возможностей и стабильности соединения. Это позволяет вам при использовании FreeBSD легко заменить модем на ISDN, если у вас уже настроено соединение PPP. Однако, в тоже время любые проблемы, которые возникают с программой PPP, отражаются и здесь. Если вы хотите максимальной надёжности, используйте PPP на уровне параметра ядра, а не пользовательский PPP. Известно, что следующие TA работают с FreeBSD: Motorola BitSurfer и Bitsurfer Pro Adtran Большинство остальных TA, скорее всего, тоже будут работать, производители TA прилагают все усилия для обеспечения поддержки практически всего набора стандартных AT-команд модема. Как и в случае модемов проблемой использования внешнего TA является потребность в хорошем последовательном адаптере на вашем компьютере. Вы должны прочесть учебник Последовательные устройства во FreeBSD для того, чтобы в деталях понять работу последовательных устройств и осознать различие между асинхронными и синхронными последовательными портами. TA, работающий со стандартным последовательным (асинхронным) портом PC, ограничивает вас скоростью 115.2 Кбит/с, хотя реально у вас соединение на скорости 128 Кбит/с. Чтобы использовать 128 Кбит/с, которые обеспечивает ISDN, полностью, вы должны подключить TA к синхронному последовательному адаптеру. Не обманывайте себя, думая, что покупка встроенного TA поможет избежать проблемы синхронности/асинхронности. Встроенные TA просто уже имеют внутри стандартный последовательный порт PC. Все, что при этом достигается - это экономия дополнительных последовательного кабеля и электрической розетки. Синхронный адаптер с TA по крайней мере так же быстр, как и отдельный маршрутизатор, а если он работает под управлением машины класса 386 с FreeBSD, то это гораздо более гибкое решение. Выбор между использованием синхронного адаптера/TA или отдельного маршрутизатора в большей степени является религиозным вопросом. По этому поводу в списках рассылки была некоторая дискуссия. Рекомендуем поискать в архивах обсуждение полностью. Отдельные мосты/маршрутизаторы ISDN ISDN отдельно стоящие мосты/маршрутизаторы Мосты или маршрутизаторы ISDN не так уж специфичны для FreeBSD или для любой другой операционной системы. Для более подробного описания технологий маршрутизации и работы мостов, пожалуйста, обратитесь к справочникам по сетевым технологиям. В контексте этого раздела термины маршрутизатор и сетевой мост будут использоваться как взаимозаменяемые. Вместе с падением цен на простые мосты/маршрутизаторы ISDN, они становятся все более популярными. Маршрутизатор ISDN представляет собой маленькую коробочку, которая подключается непосредственно в вашу сеть Ethernet, и поддерживает связь с другим мостом/маршрутизатором. Всё программное обеспечение для работы по PPP и другим протоколам встроено в маршрутизатор. Маршрутизатор обладает гораздо большей пропускной способностью, чем стандартный TA, так как он использует полное синхронное соединение ISDN. Основной проблемой с маршрутизаторами и мостами ISDN является то, что их совместная работа с оборудованием других производителей может оказаться под вопросом. Если вы собираетесь подключаться к провайдеру, то вы должны обсудить с ним то, что вам нужно. Если вы планируете объединить два сегмента локальной сети, например, домашнюю сеть с сетью офиса, это самое простое решение с минимальными издержками на обслуживание. Так как вы покупаете оборудование для обоих сторон соединения, то можете быть уверены, что связь будет работать нормально. Например, для соединения домашнего компьютера или сети подразделения к сети центрального офиса, может использоваться такая настройка: Офис подразделения или домашняя сеть 10 base 2 Сеть построена в топологии общей шины на основе 10 base 2 Ethernet (thinnet - тонкий Ethernet). Подключите маршрутизатор к сетевому кабелю с помощью трансивера AUI/10BT, если это нужно. ---Рабочая станция Sun | ---Машина с FreeBSD | ---Windows 95 | Отдельный маршрутизатор | Канал ISDN BRI 10 Base 2 Ethernet Если ваш домашний или удаленный офис представляет собой один компьютер, то для непосредственного подключения к маршрутизатору вы вы можете использовать витую пару с перекрестным соединениям. Центральный офис или другая локальная сеть 10 base T Сеть построена в топологии звезды на основе 10 Base T Ethernet (витая пара). -------Сервер Novell | H | | ---Sun | | | U ---FreeBSD | | | ---Windows 95 | B | |___---Отдельно стоящий маршрутизатор | Канал ISDN BRI Схема сети с ISDN Одним большим преимуществом большинства маршрутизаторов/мостов является то, что они позволяют иметь 2 отдельных независимых соединения PPP к 2 различным сайтам одновременно. Это не поддерживается в большинстве TA, кроме специальных (обычно дорогих) моделей, имеющих по два последовательных порта. Не путайте это с балансировкой нагрузки, MPP и так далее. Это может оказаться весьма полезной особенностью, например, если у вас имеется постоянное ISDN-соединение в вашем офисе, и вы хотите им воспользоваться, но не хотите задействовать дополнительный канал ISDN на работе. Маршрутизатор, расположенный в офисе, может использовать выделенное соединение по каналу B (64 Кбит/с) для Интернет, и одновременно другой канал B для отдельного соединения для передачи данных. Второй канал B может использоваться для входящих, исходящих и динамически распределяемых соединений (MPP и так далее) совместно с первым каналом B для повышения пропускной способности. IPX/SPX Мост Ethernet также позволяет вам передавать больше, чем просто трафик IP. Вы сможете передавать IPX/SPX и любые другие протоколы, которые вы используете. Chern Lee Текст предоставил Даемон преобразования сетевых адресов (natd) Обзор natd Даемон преобразования сетевых адресов (Network Address Translation) во FreeBSD, широко известный как &man.natd.8;, является даемоном, который принимает входящие IP-пакеты, изменяет адрес отправителя на адрес локальной машины и повторно отправляет эти пакеты в потоке исходящих пакетов. &man.natd.8; делает это, меняя IP-адрес отправителя и порт таким образом, что когда данные принимаются обратно, он может определить расположение источника начальных данных и переслать их машине, которая запрашивала данные изначально. совместное использование доступа в Интернет NAT Чаще всего NAT используется для организации так называемого Совместного Использования Интернет. Настройка Из-за исчерпания пространства адресов в IPv4 и увеличения количества пользователей высокоскоростных каналов связи, таких, как кабельное подключение или DSL, необходимость в решении по Совместному Использованию Интернет растёт. Возможность подключить несколько компьютеров через единственное соединение и IP-адрес делает &man.natd.8; подходящим решением. Чаще всего у пользователя имеется машина, подключенная к кабельному каналу или каналу DSL с одним IP-адресом и есть желание использовать этот единственный подключенный компьютер для организации доступа в Интернет другим компьютерам в локальной сети. Для этого машина FreeBSD, находящаяся в Интернет, должна выступать в роли шлюза. Эта шлюзовая машина должна иметь два сетевых адаптера—один для подключения к маршрутизатору Интернет, а другой для подключения к ЛВС. Все машины в локальной сети подключаются через сетевой концентратор или коммутатор. Существует много способов подсоединить локальную сеть к Internet через шлюз &os;. Этот пример показывает шлюз c двумя сетевыми картами. _______ __________ ________ | | | | | | | Hub |-----| Client B |-----| Router |----- Internet |_______| |__________| |________| | ____|_____ | | | Client A | |__________| Структура сети Подобная конфигурация часто используется для совместного использования доступа в Интернет. Одна из подключенных к локальной сети машин подключается к Интернет. Остальные машины работают с Интернет посредством этой шлюзовой машины. ядро настройка Настройка В файле конфигурации ядра должны присутствовать следующие параметры: options IPFIREWALL options IPDIVERT Дополнительно, если это нужно, можно добавить следующее: options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE В файле /etc/rc.conf должны быть такие строки: gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="fxp0" natd_flags="" Указывает машине выступать в качестве шлюза. Выполнение команды sysctl net.inet.ip.forwarding=1 приведёт к тому же самому результату. При загрузке включает использование правил брандмауэра из файла /etc/rc.firewall. Здесь задается предопределенный набор правил брандмауэра, который разрешает все. Посмотрите файл /etc/rc.firewall для нахождения дополнительных типов. Указывает, через какой интерфейс передавать пакеты (интерфейс, подключенный к Интернет). Любые дополнительный параметры, передаваемые при запуске даемону &man.natd.8;. При использовании вышеуказанных параметров в файле /etc/rc.conf при загрузке будет запущена команда natd -interface fxp0. Эту команду можно запустить и вручную. Если для передачи &man.natd.8; набирается слишком много параметров, возможно также использовать конфигурационный файл. В этом случае имя настроечного файла должно быть задано добавлением следующей строки в /etc/rc.conf: natd_flags="-f /etc/natd.conf" Файл /etc/natd.conf будет содержать перечень конфигурационных параметров, по одному в строке. К примеру, для примера из следующего раздела будет использоваться такой файл: redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 Для получения более полной информации о конфигурационном файле прочтите страницу справки по &man.natd.8; относительно параметра . Каждой машине и интерфейсу в ЛВС должен быть назначен IP-адрес из адресного пространства частных сетей, как это определено в RFC 1918, а в качестве маршрутизатора по умолчанию должен быть задан IP-адрес машины с natd из внутренней сети. Например, клиенты A и B в ЛВС имеют IP-адреса 192.168.0.2 и 192.168.0.3, а интерфейс машины с natd в локальной сети имеет IP-адрес 192.168.0.1. Маршрутизатором по умолчанию для клиентов A и B должна быть назначена машина с natd, то есть 192.168.0.1. Внешний, или Интернет-интерфейс машины с natd не требует особых настроек для работы &man.natd.8;. Перенаправление портов Минусом использования &man.natd.8; является то, что машины в локальной сети недоступны из Интернет. Клиенты в ЛВС могут выполнять исходящие соединения во внешний мир, но не могут обслуживать входящие. Это является проблемой при запуске служб Интернет на клиентских машинах в локальной сети. Простым решением является перенаправление некоторых портов Интернет машины с natd на клиента локальной сети. Пусть, к примеру, сервер IRC запущен на клиенте A, а Web-сервер работает на клиенте B. Чтобы это работало, соединения, принимаемые на портах 6667 (IRC) и 80 (Web), должны перенаправляться на соответствующие машины. Программе &man.natd.8; должна быть передана команда с соответствующими параметрами. Синтаксис следующий: -redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]aliasPORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]] В примере выше аргументы должен быть такими: -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 При этом будут перенаправлены соответствующие порты tcp на клиентские машины в локальной сети. Аргумент может использоваться для указания диапазонов портов, а не конкретного порта. Например, tcp 192.168.0.2:2000-3000 2000-3000 будет перенаправлять все соединения, принимаемые на портах от 2000 до 3000, на порты от 2000 до 3000 клиента A. Эти параметры можно указать при непосредственном запуске &man.natd.8;, поместить их в параметр natd_flags="" файла /etc/rc.conf, либо передать через конфигурационный файл. Для получение информации о других параметрах настройки обратитесь к справочной странице по &man.natd.8; Перенаправление адреса перенаправление адреса Перенаправление адреса полезно, если имеется несколько адресов IP, и они должны быть на одной машине. В этой ситуации &man.natd.8; может назначить каждому клиенту ЛВС свой собственный внешний IP-адрес. Затем &man.natd.8; преобразует исходящие от клиентов локальной сети пакеты, заменяя IP-адреса на соответствующие внешние, и перенаправляет весь трафик, входящий на некоторый IP-адрес, обратно конкретному клиенту локальной сети. Это также называют статическим NAT. К примеру, пусть IP-адреса 128.1.1.1, 128.1.1.2 и 128.1.1.3 принадлежат шлюзовой машине natd. 128.1.1.1 может использоваться в качестве внешнего IP-адреса шлюзовой машины natd, тогда как 128.1.1.2 и 128.1.1.3 будут перенаправляться обратно к клиентам ЛВС A и B. Синтаксис для таков: -redirect_address localIP publicIP localIP Внутренний IP-адрес клиента локальной сети. publicIP Внешний IP, соответствующий клиенту локальной сети. В примере этот аргумент будет выглядеть так: -redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3 Как и для , эти аргументы также помещаются в строку natd_flags="" файла /etc/rc.conf или передаются через конфигурационный файл. При перенаправлении адресов нет нужды в перенаправлении портов, потому что перенаправляются все данные, принимаемые для конкретного IP-адреса. Внешние IP-адреса машины с natd должны быть активизированы и являться синонимами для внешнего интерфейса. Обратитесь к &man.rc.conf.5;, чтобы это сделать. IP по параллельному порту (PLIP) PLIP IP по параллельному порту PLIP PLIP позволяет нам работать с TCP/IP по параллельному порту. Это полезно для машин без сетевых адаптеров или для установки на лэптопы. В этом разделе мы обсудим: создание кабеля для параллельного порта (laplink). Соединение двух компьютеров посредством PLIP. Создание параллельного кабеля Вы можете приобрести кабель для параллельного порта в большинстве магазинов, торгующих комплектующими. Если вы его не найдете, или же просто хотите знать, как он делается, то следующая таблица поможет вам сделать такой кабель из обычного принтерного кабеля для параллельного порта. Распайка кабеля для параллельного порта для сетевой работы A-name A-End B-End Описание Post/Bit DATA0 -ERROR 2 15 15 2 Data 0/0x01 1/0x08 DATA1 +SLCT 3 13 13 3 Data 0/0x02 1/0x10 DATA2 +PE 4 12 12 4 Data 0/0x04 1/0x20 DATA3 -ACK 5 10 10 5 Strobe 0/0x08 1/0x40 DATA4 BUSY 6 11 11 6 Data 0/0x10 1/0x80 GND 18-25 18-25 GND -
Настройка PLIP Прежде всего вы должны найти laplink-кабель. Затем удостоверьтесь, что на обоих компьютерах в ядро включена поддержка драйвера &man.lpt.4;: &prompt.root; grep lp /var/run/dmesg.boot lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port Управление параллельным портом должно выполняться по прерываниям. Во &os; 4.X в файле конфигурации ядра должна присутствовать строка, подобная следующей: device ppc0 at isa? irq 7 Во &os; 5.X файл /boot/device.hints должен содержать следующие строки: hint.ppc.0.at="isa" hint.ppc.0.irq="7" Затем проверьте, что файл конфигурации ядра имеет строку device plip, или загружен ли модуль ядра plip.ko. В обоих случаях интерфейс работы с сетью по параллельному порту должен присутствовать на момент использования команды &man.ifconfig.8;. &prompt.root; ifconfig plip0 plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 Подключите кабель laplink к параллельным интерфейсам на обоих компьютерах. Настройте параметры сетевого интерфейса с обеих сторон, работая как пользователь root. К примеру, если вы хотите соединить хост host1, на котором работает &os; 4.X, с хостом host2 под управлением &os; 5.X: host1 <-----> host2 IP Address 10.0.0.1 10.0.0.2 Настройте интерфейс на машине host1, выполнив: &prompt.root; ifconfig plip0 10.0.0.1 10.0.0.2 Настройте интерфейс на машине host2, выполнив: &prompt.root; ifconfig lp0 10.0.0.2 10.0.0.1 Теперь вы должны получить работающее соединение. Пожалуйста, прочтите страницы руководства по &man.lp.4; и &man.lpt.4; для выяснения деталей. Вы должны также добавить оба хоста в /etc/hosts: 127.0.0.1 localhost.my.domain localhost 10.0.0.1 host1.my.domain host1 10.0.0.2 host2.my.domain Чтобы проверить работу соединения, перейдите к каждому хосту и выполните тестирование соединения с другой машиной посредством команды ping. К примеру, на машине host1: &prompt.root; ifconfig lp0 lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 &prompt.root; netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire host2 host1 UH 0 0 lp0 &prompt.root; ping -c 4 host2 PING host2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- host2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Aaron Kaplan Первоначальный текст написал Tom Rhodes Реструктуризацию и добавления внёс Brad Davis Расширил IPv6 IPv6 (также называемый IPng IP next generation - следующее поколение IP) является новой версией широко известного протокола IP (называемого также IPv4). Как и другие современные системы *BSD, FreeBSD включает эталонную реализацию IPv6 от KAME. Так что система FreeBSD поставляется со всем, что вам нужно для экспериментирования с IPv6. Этот раздел посвящён настройке и запуску в работу IPv6. В начале 1990-х люди стали беспокоиться о быстро иссякающем адресном пространстве IPv4. Принимая во внимание темпы роста Интернет, имелись основные проблемы: Нехватка адресов. Сегодня это не такая большая проблема, так как стали применяться адресные пространства для частных сетей (RFC1918) (10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/24) и технология преобразования сетевых адресов (NAT - Network Address Translation). Таблицы маршрутов становятся чересчур большими. Это всё ещё является проблемой сегодня. IPv6 решает эти и многие другие вопросы: 128-битное адресное пространство. Другими словами, теоретически доступны 340,282,366,920,938,463,463,374,607,431,768,211,456 адреса. Это означает плотность примерно в 6.67 * 10^27 адресов IPv6 на квадратный метр нашей планеты. Маршрутизаторы будут хранить в своих таблицах только агрегированные адреса сетей, что уменьшает средний размер таблицы маршрутизации до 8192 записей. Имеется также множество других полезных особенностей IPv6, таких, как: Автоматическая настройка адреса (RFC2462) Групповые адреса (один к нескольким из многих) Обязательные адреса множественной рассылки IPsec (IP security - безопасный IP) Упрощённая структура заголовка Мобильный IP Механизмы преобразования IPv6-в-IPv4 Для получения дополнительной информации посмотрите: Обзор IPv6 на сайте playground.sun.com KAME.net 6bone.net Основы адресации IPv6 Существуют различные типы адресов IPv6: одноадресные (Unicast), групповые (Anycast) и многоадресные (Multicast). Адреса типа Unicast хорошо всем известны. Пакет, посланный на такой адрес, достигает в точности интерфейса, который этому адресу соответствует. Адреса типа Anycast синтаксически неотличимы от адресов Unicast, но они адресуют группу интерфейсов. Пакет, направленный такому адресу, попадёт в ближайший (согласно метрике маршрутизатора) интерфейс. Адреса Anycast могут использоваться только маршрутизаторами. Адреса типа Multicast идентифицируют группу интерфейсов. Пакет, посланный на такой адрес, достигнет всех интерфейсов, привязанных к группе многоадресного вещания. Широковещательные адреса IPv4 (обычно xxx.xxx.xxx.255) выражаются адресами многоадресного вещания IPv6. Зарезервированные адреса IPv6 IPv6 адрес Длина префикса (биты) Описание Заметки :: 128 бит нет описания cf. 0.0.0.0 в IPv4 ::1 128 бит loopback адрес cf. 127.0.0.1 в IPv4 ::00:xx:xx:xx:xx 96 бит встроенный IPv4 Нижние 32 бита это адрес IPv4. Также называется IPv4 совместимым IPv6 адресом ::ff:xx:xx:xx:xx 96 бит Адрес IPv6, отображенный на IPv4 Нижние 32 бита это адрес IPv4. Для хостов, не поддерживающих IPv6. fe80:: - feb:: 10 бит link-local cf. loopback адрес в IPv4 fec0:: - fef:: 10 бит site-local   ff:: 8 бит широковещательный   001 (основание 2) 3 бит global unicast Все global unicast адреса присваиваются из этого пула. Первые три бита 001.
Чтение адресов IPv6 Каноническая форма представляется в виде x:x:x:x:x:x:x:x, где каждый символ x является 16-разрядным числом в шестнадцатеричной форме. К примеру, FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 Часто в адресе присутствуют длинные строчки, заполненные нулями, поэтому одна такая последовательность на адрес может быть сокращена до ::. Кроме того, до трех ведущих 0 на шестнадцатеричную четверку могут быть пропущены. К примеру, fe80::1 соответствует канонической форме fe80:0000:0000:0000:0000:0000:0000:0001. В третьей форме последние 32 бита записываются в широко известном (десятичном) стиле IPv4 с точками . в качестве разделителей. Например, f2002::10.0.0.1 соответствует (шестнадцатеричному) каноническому представлению 2002:0000:0000:0000:0000:0000:0a00:0001, которое, в свою очередь, равнозначно записи 2002::a00:1. Теперь читатель должен понять следующую запись: &prompt.root; ifconfig rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 ether 00:00:21:03:08:e1 media: Ethernet autoselect (100baseTX ) status: active fe80::200:21ff:fe03:8e1%rl0 является автоматически настроенным локальным адресом. Он генерируется из MAC адреса в процессе автоматической конфигурации. Для получения дополнительной информации о структуре адресов IPv6 обратитесь к RFC3513. Настройка подключения На данный момент существуют четыре способа подключиться к другим хостам и сетям IPv6: Подключиться к экспериментальному 6bone Получить сеть IPv6 от вышестоящего провайдера. Для получения рекомендаций обратитесь к вашему провайдеру Интернет. Туннелировать посредством 6-в-4 (RFC3068) Использовать порт net/freenet6, если вы используете коммутируемое соединение. Здесь мы будем рассматривать подключение к 6bone, так как на данный момент это является самым популярным способом. Сначала взгляните на сайт 6bone и найдите ближайшую к вам точку подключения к 6bone. Напишите ответственному и при некоторой удаче вам дадут инструкции по настройке соединения. Обычно это касается настройки туннеля GRE (gif). Вот типичный пример настройки туннеля &man.gif.4;: &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 &prompt.root; ifconfig gif0 tunnel MY_IPv4_ADDR MY_IPv4_REMOTE_TUNNEL_ENDPOINT_ADDR &prompt.root; ifconfig gif0 inet6 alias MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR Замените слова, написанные заглавными буквами, информацией, которую вам дал вышестоящий узел 6bone. При этом установится туннель. Проверьте работу туннеля утилитой &man.ping6.8; с адресом ff02::1%gif0. Вы должны получить два положительных ответа. Если вы заинтригованы адресом ff02:1%gif0, скажем, что это адрес многоадресного вещания. %gif0 указывает на использование такого адреса с сетевым интерфейсом gif0. Так как мы выполняем ping над адресом многоадресного вещания, то другая сторона туннеля также должна ответить. Теперь настройка маршрута к вашей вышестоящей точке подключения 6bone должна быть весьма проста: &prompt.root; route add -inet6 default -interface gif0 &prompt.root; ping6 -n MY_UPLINK &prompt.root; traceroute6 www.jp.FreeBSD.org (3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets 1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms 2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms * 3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms 4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms 5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms 6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 ms Эта выдача будет отличаться от машины к машине. Теперь вы должны суметь достигнуть сайта IPv6 www.kame.net и увидеть танцующую черепаху — в случае, если ваш браузер поддерживает IPv6, как, например, www/mozilla или Konqueror, который входит в x11/kdebase3, или www/epiphany. DNS в мире IPv6 Для IPv6 использовались два типа записей DNS. IETF объявил записи A6 устаревшими. Стандартом на данный момент являются записи AAAA. Использование записей AAAA достаточно просто. Назначение вашему имени хоста нового адреса IPv6 достигается просто добавлением: MYHOSTNAME AAAA MYIPv6ADDR к вашему первичному файлу DNS зоны. В случае, если вы не обслуживаете собственные зоны DNS, обратитесь к вашему провайдеру DNS. Имеющиеся версии bind (версий 8.3 и 9) и dns/djbdns (с патчем IPv6) поддерживают записи AAAA. Внесение необходимых изменений в <filename>/etc/rc.conf</filename> Настройки клиентов IPv6 Эти установки помогут вам настроить компьютер, который будет работать в сети как клиент, а не как маршрутизатор. Для включения настройки интерфейсов через &man.rtsol.8; при загрузке, все, что вам потребуется, это добавить следующую строку: ipv6_enable="YES" Для статического присвоения IP адреса, такого как 2001:471:1f11:251:290:27ff:fee0:2093, интерфейсу fxp0, добавьте: ipv6_ifconfig_fxp0="2001:471:1f11:251:290:27ff:fee0:2093" Для назначения маршрутизатором по умолчанию 2001:471:1f11:251::1, добавьте следующую строку к /etc/rc.conf: ipv6_defaultrouter="2001:471:1f11:251::1" Настройки маршрутизатора/шлюза IPv6 Этот раздел поможет вам использовать инструкции, которые выдал провайдер туннеля, например, 6bone, и сделать эти настройки постоянными. Для восстановления туннеля при загрузке системы используйте в /etc/rc.conf нижеприведенные настройки. Задайте список туннельных интерфейсов (Generic Tunneling interfaces), которые необходимо настроить, например gif0: gif_interfaces="gif0" Для настройки интерфейса с локальным подключением на MY_IPv4_ADDR к удаленной точке REMOTE_IPv4_ADDR: gifconfig_gif0="MY_IPv4_ADDR REMOTE_IPv4_ADDR" Для включения IPv6 адреса, который был вам присвоен для использования в подключении к туннелю IPv6, добавьте: ipv6_ifconfig_gif0="MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR" Затем все, что вам потребуется сделать, это добавить маршрут по умолчанию для IPv6. Это другая сторона туннеля IPv6: ipv6_defaultrouter="MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR" Настройка туннелирования IPv6 Если сервер будет обеспечивать маршрутизацию между вашей сетью и остальным миром, то в файле /etc/rc.conf понадобится следующая строка: ipv6_gateway_enable="YES" Распространение маршрутов и автоматическая настройка хостов Этот раздел поможет вам настроить &man.rtadvd.8; для распространения маршрута IPv6 по умолчанию. Для включения &man.rtadvd.8; вам понадобится добавить в /etc/rc.conf следующую строку: rtadvd_enable="YES" Важно указать интерфейс, на котором выполняется запрос маршрутизатора IPv6. Например, для указания &man.rtadvd.8; использовать fxp0: rtadvd_interfaces="fxp0" Теперь мы должны создать файл настройки, /etc/rtadvd.conf. Вот пример: fxp0:\ :addrs#1:addr="2001:471:1f11:246::":prefixlen#64:tc=ether: Замените fxp0 на интерфейс, который вы будете использовать. Затем, замените 2001:471:1f11:246:: на префикс вашего размещения. Если у вас выделенная подсеть /64, больше ничего менять не потребуется. Иначе, вам потребуется изменить prefixlen# на корректное значение. Harti Brandt Предоставил Асинхронный режим передачи (ATM) Классическая настройка IP через ATM (PVC) Классический IP через ATM (CLIP) это простейший метод использования асинхронного режима передачи (Asynchronous Transfer Mode, ATM) с IP. Он может быть использован с коммутируемыми подключениями (switched connections, SVC) и с постоянными подключениями (permanent connections, PVC). В этом разделе будет описано как настроить сеть на основе PVC. Полностью объединенные конфигурации Первый метод для настройки CLIP с PVC это подключение каждого компьютера к каждому в сети с выделенным PVC. Хотя настройка проста, она непрактична для большого количества компьютеров. В примере предполагается, что в сети есть четыре компьютера, каждый подключенный к ATM сети с помощью карты ATM адаптера. Первый шаг это планирование IP адресов и ATM подключений между компьютерами. Мы используем: Хост IP адрес hostA 192.168.173.1 hostB 192.168.173.2 hostC 192.168.173.3 hostD 192.168.173.4 Для сборки полностью объединенной сети нам потребуется по одному ATM соединению между каждой парой компьютеров: Компьютеры VPI.VCI соединение hostA - hostB 0.100 hostA - hostC 0.101 hostA - hostD 0.102 hostB - hostC 0.103 hostB - hostD 0.104 hostC - hostD 0.105 Значения VPI и VCI на каждом конце соединения конечно могут отличаться, но для упрощения мы предполагаем, что они одинаковы. Затем нам потребуется настроить ATM интерфейсы на каждом хосте: hostA&prompt.root; ifconfig hatm0 192.168.173.1 up hostB&prompt.root; ifconfig hatm0 192.168.173.2 up hostC&prompt.root; ifconfig hatm0 192.168.173.3 up hostD&prompt.root; ifconfig hatm0 192.168.173.4 up предполагая, что ATM интерфейс называется hatm0 на всех хостах. Теперь PVC необходимо настроить на hostA (мы предполагаем, что ATM коммутаторы уже настроены, вам необходимо свериться с руководством на коммутатор за информацией по настройке). hostA&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubr Конечно, вместо UBR может быть использован другой тип, если ATM адаптер поддерживает это. В этом случае имя типа дополняется параметрами трафика. Помощь по &man.atmconfig.8; может быть получена командой: &prompt.root; atmconfig help natm add или на странице справочника &man.atmconfig.8;. Та же настройка может быть выполнена через /etc/rc.conf. Для hostA это будет выглядеть примерно так: network_interfaces="lo0 hatm0" ifconfig_hatm0="inet 192.168.173.1 up" natm_static_routes="hostB hostC hostD" route_hostB="192.168.173.2 hatm0 0 100 llc/snap ubr" route_hostC="192.168.173.3 hatm0 0 101 llc/snap ubr" route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr" Текущий статус всех маршрутов CLIP может быть получен командой: hostA&prompt.root; atmconfig natm show diff --git a/ru_RU.KOI8-R/books/handbook/security/chapter.sgml b/ru_RU.KOI8-R/books/handbook/security/chapter.sgml index c11d94240e..f02c217a2f 100644 --- a/ru_RU.KOI8-R/books/handbook/security/chapter.sgml +++ b/ru_RU.KOI8-R/books/handbook/security/chapter.sgml @@ -1,5153 +1,5156 @@ Matthew Dillon Большая часть этой главы была взята из страницы справочника security(7) которую написал Денис Пеплин Перевод на русский язык: Безопасность безопасность Краткое описание Эта глава представляет введение в основные концепции безопасности системы, некоторые эмпирические правила и более подробно обращается к отдельным темам, касающимся &os;. Большая часть затрагиваемых тем может быть применена к безопасности системы и безопасности в интернет вообще. Интернет больше не то дружественное место, где каждый хочет быть вам добрым соседом. Защита системы необходима для сохранения ваших данных, интеллектуальной собственности, времени и всего остального от хакеров и им подобных. &os; предоставляет массу утилит и механизмов для обеспечения целостности и безопасности системы и сети. После прочтения этой главы вы узнаете: Основные концепции безопасности системы, специфику &os;. О различных механизмах шифрования в &os;, таких как DES и MD5. Как настроить аутентификацию с использованием одноразовых паролей. Как настроить TCP Wrappers для использования с inetd. Как настроить KerberosIV в релизах &os; до 5.0. Как настроить Kerberos5 в релизах &os; после 5.0. Как настроить IPsec и создать VPN между компьютерами на &os;/&windows;. Как настроить и использовать OpenSSH, реализацию SSH в &os;. Что такое ACL и как их использовать. Как использовать утилиту Portaudit для проверки пакетов сторонних разработчиков, установленных из Коллекции Портов. Как работать с сообщениями безопасности &os;. Что такое Process Accounting и как активировать его во &os;. Перед чтением этой главы вам потребуется: Понимание основных концепций &os; и интернет. В этой книге рассмотрены и другие вопросы безопасности. Например, принудительный контроль доступа (Mandatory Access Control) рассматривается в , а брандмауэры в . Введение Безопасность это первая и основная функция системного администратора. Хотя все многопользовательские системы BSD &unix; уже снабжены некоторой защитой, работа по созданию и поддержке дополнительных механизмов безопасности, обеспечивающих защищенную работу пользователей, это одна из самых серьезных задач системного администратора. Компьютеры безопасны настолько, насколько вы сделаете их безопасными и требования безопасности всегда находятся в противоречии с удобством работы пользователей. Системы &unix; способны одновременно работать с огромным количеством процессов и многие из этих процессов серверные — это означает, что с ними могут взаимодействовать внешние программы. Сегодня десктопы заменили мини-компьютеры и мэйнфрэймы, и поскольку компьютеры в наши дни подключены к сети интернет, безопасность важна как никогда. Наилучшая реализация системы безопасности представима в виде послойной системы. Вообще говоря все, что нужно сделать, это создать столько слоев безопасности, сколько необходимо и затем внимательно следить за вторжениями в систему. Не переусердствуйте в настройке системы безопасности, иначе она сделает невозможной обнаружение вторжений, являющееся одним из наиболее важных аспектов механизма безопасности. Например, нет большого смысла в установке флага schg (&man.chflags.1;) на каждый исполняемый файл системы, поскольку хотя таким способом можно временно защитить исполняемые файлы, это помешает обнаружению факта взлома системы. Безопасность системы также относится к различным формам атак, имеющих своей целью вызвать крах системы, или сделать систему недоступной другим способом, но не пытающихся получить доступ к учётной записи root (break root). Угрозы безопасности могут быть поделены на несколько категорий: Отказ в обслуживании (Denial of service, DoS). Взлом пользовательских учётных записей. Взлом учётной записи root через доступные сервисы. Взлом учётной записи root через учётные записи пользователей. Создание backdoor. DoS атаки отказ в обслуживании (Denial of Service, DoS) безопасность DoS атаки отказ в обслуживании (Denial of Service, DoS) Отказ в обслуживании (Denial of Service, DoS) Атака отказ в обслуживании отбирает у машины необходимые ресурсы. Обычно DoS атаки используют грубую силу, чтобы попытаться обрушить систему или сделать ее недоступной другим способом, превысив лимиты ее сервисов или сетевого стека. Некоторые DoS атаки пытаются использовать ошибки в сетевом стеке для обрушения системы одним пакетом. Эту проблему можно решить только исправив ядро системы. Атаки зачастую можно предотвратить правильной установкой параметров, ограничивающих нагрузку на систему в неблагоприятных условиях. С атаками, использующими грубую силу, бороться сложно. Например, атака с использованием пакетов с поддельными адресами, которую почти невозможно остановить, может быстро отключить вашу систему от интернет. Возможно, она не приведет к отказу системы, но сможет переполнить соединение с интернет. безопасность взлом учётных записей Взлом учётной записи пользователя обычно встречается чаще, чем DoS атаки. Многие системные администраторы все еще используют стандартные сервисы telnetd, rlogind и ftpd на своих серверах. Эти сервисы по умолчанию не работают с зашифрованными соединениям. В результате при среднем количестве пользователей пароль одного или нескольких пользователей, входящих в систему через внешнее соединение (это обычный и наиболее удобный способ входа в систему), будет перехвачен. Внимательный системный администратор должен анализировать логи удаленного доступа на предмет подозрительных адресов пользователей даже в случае успешного входа. Кто-то может предположить, что атакующий при наличии доступа к учётной записи пользователя может взломать учётную запись root. Однако, реальность такова, что в хорошо защищенной и поддерживаемой системе доступ к учётной записи пользователя не обязательно даст атакующему доступ к root. Разница между доступом к обычной учётной записи и к root важна, поскольку без доступа к root атакующий обычно не способен скрыть свои действия, и в худшем случае сможет лишь испортить файлы пользователя или вызвать крах системы. Взлом пользовательских учётных записей встречается очень часто, поскольку пользователи заботятся о безопасности так, как системные администраторы. безопасность backdoors Системные администраторы должны помнить, что существует множество потенциальных способов взлома учётной записи root. Атакующий может узнать пароль root, найти ошибку в сервисе, работающем с привилегиями и взломать учётную запись root через сетевое соединение с этим сервисом, или узнать об ошибке в suid-root программе, позволяющей атакующему взлом root с помощью взломанной учётной записи пользователя. Если атакующий нашел способ взлома root, ему может не понадобиться установка backdoor. Многие из обнаруженных и закрытых на сегодняшний день брешей в системе, позволяющие взлом root, требуют от атакующего серьезной работы по заметанию следов, поэтому большинство атакующих устанавливают backdoor. Backdoor предоставляет атакующему простой способ восстановления доступа к системе с привилегиями root, но также дает системному администратору удобный способ обнаружения вторжения. Устранение возможности установки backdoor возможно повредит безопасности системы, поскольку это не устранит брешь, позволившую проникнуть в систему. Меры безопасности всегда должны реализовываться на нескольких уровнях, которые могут быть классифицированы следующим образом: Защита root и служебных учётных записей. Защита работающих под root сервисов и suid/sgid исполняемых файлов. Защита учётных записей пользователей. Защита файла паролей. Защита ядра, raw устройств и файловых систем. Быстрое обнаружение несанкционированных изменений в системе. Паранойя. В следующем разделе этой главы эти темы изложены более подробно. Защита &os; безопасность защита &os; Команда и протокол В этом документе мы будет использовать выделенный текст, упоминая приложение, и моноширинный шрифт, упоминая определенные команды. Для протоколов используется обычный шрифт. Это типографическое отличие полезно для таких случаев, как ssh, поскольку это и команда и протокол. В последующем разделе будут рассмотрены методы защиты системы &os;, упомянутые в предыдущем разделе этой главы. Защита учётной записи <username>root</username> и служебных учётных записей su Во-первых, не беспокойтесь о защите служебных учётных записей, если не защищена учётная запись root. В большинстве систем у учётной записи root есть пароль. Использование пароля root опасно всегда. Это не означает, что вы должны удалить пароль. Пароль почти всегда необходим для доступа по консоли. Но это означает, что вы должны сделать невозможным использование пароля не из консоли или может быть даже с помощью команды &man.su.1;. Например, убедитесь, что псевдо-терминалы в файле /etc/ttys перечислены с параметром insecure, что делает невозможным вход на них под root напрямую с помощью telnet или rlogin. При использовании других средств входа, таких как sshd, убедитесь что вход под root напрямую отключен и в них. Сделайте это, открыв файл /etc/ssh/sshd_config, и убедившись, что параметр PermitRootLogin установлен в NO. Проверьте каждый метод доступа — сервис FTP и ему подобные часто подвержены взлому. Прямой вход под root должен быть разрешен только с системной консоли. wheel Конечно, как системный администратор вы должны иметь доступ root, поэтому потребуется открыть несколько лазеек. Но убедитесь, что для доступа к ним необходим дополнительный пароль. Одним из способов доступа к root является добавление соответствующих учётных записей к группе wheel (в файле /etc/group). Это позволяет использовать su для доступа к root. Вы никогда не должны давать таким учётным записям доступ к wheel непосредственно, помещая их в группу wheel в файле паролей. Служебные учётные записи должны помещаться в группу staff, а затем добавляться к группе wheel в файле /etc/group. Только те члены группы staff, которым действительно нужен доступ к root, должны быть помещены в группу wheel. При работе с такими методами аутентификации как Kerberos, возможно также использование файла .k5login в каталоге пользователя root для доступа к учётной записи root с помощью &man.ksu.1; без помещения кого-либо в группу wheel. Это решение возможно лучше, поскольку механизм wheel все еще позволяет взлом root, если злоумышленник получил копию файла паролей и смог взломать служебную учётную запись. Хотя использование механизма wheel лучше, чем работа через root напрямую, это не обязательно самый безопасный способ. Непрямой способ защиты служебных учётных записей и конечно root это использование альтернативных методов доступа и замена зашифрованных паролей на символ *. Используя команду &man.vipw.8;, замените каждый зашифрованный пароль служебных учётных записей на этот символ для запрета входа с аутентификацией по паролю. Эта команда обновит файл /etc/master.passwd и базу данных пользователей/паролей. Служебная учётная запись вроде этой: foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh Должна быть заменена на такую: foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh Это изменение предотвратит обычный вход, поскольку зашифрованный пароль никогда не совпадет с *. После этого члены группы staff должны использовать другой механизм аутентификации, например &man.kerberos.1; или &man.ssh.1; с парой ключей: публичным и приватным. При использовании такой системы как Kerberos, потребуется защитить сервер Kerberos и рабочую станцию. При использовании пары публичного/приватного ключей с ssh, потребуется защитить компьютер, с которого происходит вход (обычно это рабочая станция). Дополнительных слой защиты может быть добавлен путем защиты пары ключей при создании их с помощью &man.ssh-keygen.1;. Возможность заменить пароли служебных учётных записей на * гарантирует также, что вход может быть осуществлен только через защищенные методы доступа, которые вы настроили. Это принуждает всех членов staff использовать защищенные, шифрованные соединения для всех входов, что закрывает большую брешь, используемую многими нарушителями: перехват паролей с другого, слабо защищенного компьютера. Более непрямой механизм безопасности предполагает, что вы входите с более защищенного сервера на менее защищенный. Например, если главный сервер работает со всеми сервисами, рабочая станция не должна работать ни с одним. Для поднятия уровня безопасности до приемлемого уровня, число запущенных на ней сервисов необходимо сократить до минимума, вплоть до отключения их всех, кроме того необходимо использовать защищенный паролем хранитель экрана. Конечно, при наличии физического доступа к рабочей станции атакующий может взломать любую систему безопасности. Это определенно проблема, которую вы должны учитывать, но учтите также тот факт, что большинство взломов совершаются удаленно, через сеть, людьми, которые не имеют физического доступа к вашим рабочим станциям или серверам. KerberosIV Использование такой системы как Kerberos дает возможность заблокировать или изменить пароль в одном месте, что сразу отразиться на всех компьютерах, где существует служебная учётная запись. Если эта учётная запись будет взломана, возможность немедленно изменить пароль на всех компьютерах нельзя недооценивать. Без этой возможности изменение паролей на N машинах может стать проблемой. Вы можете также наложить ограничения на смену паролей с помощью Kerberos: не только установить значения timeout в Kerberos, но и добавить требование смены пароля пользователем после определенного периода времени (скажем, раз в месяц). Защита работающих под root сервисов и suid/sgid исполняемых файлов ntalk comsat finger sandboxes sshd telnetd rshd rlogind Предусмотрительный системный администратор запускает только те сервисы, в которых нуждается, ни больше ни меньше. Учитывайте, что сервисы сторонних разработчиков наиболее подвержены ошибкам. К примеру, работа со старыми версиями imapd или popper это все равно что раздача доступа root всему миру. Никогда не запускайте сервисы, которые вы не проверили достаточно внимательно. Многим сервисам не требуется работа под root. Например, даемоны ntalk, comsat, и finger могут быть запущены в так называемых песочницах (sandboxes). Песочница это не идеальное решение, поскольку вызывает много проблем, но она подходит под модель послойной безопасности: если кто-то сможет взломать сервис, работающий в песочнице, ему потребуется взломать еще и саму песочницу. Чем больше уровней (слоев) потребуется пройти атакующему, тем меньше вероятность его успеха. Ошибки, позволяющие получать root доступ, находили фактически во всех сервисах, запускаемых под root, включая основные системные сервисы. Если вы обслуживаете машину, на которую входят только через sshd и никогда не входят через telnetd, rshd или rlogind, отключите эти сервисы! В &os; сервисы ntalkd, comsat и finger теперь по умолчанию работают в песочнице. Другая программа, которая может быть кандидатом на запуск в песочнице это &man.named.8;. /etc/defaults/rc.conf включает необходимые для запуска named в песочнице аргументы в закомментированой форме. В зависимости от того, устанавливаете ли вы новую систему, или обновляете старую, учётные записи пользователей, используемые этими песочницами могут не быть созданы. Предусмотрительный системный администратор должен узнать о песочницах для сервисов и установить их если есть возможность. sendmail Есть множество других сервисов, которые обычно не работают в песочницах: sendmail, popper, imapd, ftpd, и другие. Некоторым из этих сервисов есть альтернативы, но их установка может потребовать больше работы, чем вы готовы выполнить (фактор удобства). Вы можете запустить эти сервисы под root и положиться на другие механизмы обнаружения вторжений, которые могут пройти через них. Другая большая потенциальная root брешь в системе это suid-root и sgid исполняемые файлы. Большинство этих исполняемых файлов, таких как rlogin, установлены в /bin, /sbin, /usr/bin, или /usr/sbin. Хотя ничто не может быть безопасно на 100%, находящиеся по умолчанию в системе suid и sgid исполняемые файлы могут быть признаны достаточно безопасными. Но root бреши все еще обнаруживаются в этих исполняемых файлах. root брешь, обнаруженная в Xlib в 1998 делала xterm (который обычно suid) подверженным взлому. Лучше сразу принять меры предосторожности, чем сожалеть потом. Предусмотрительный системный администратор ограничит права запуска suid исполняемых файлов, которые должны запускаться пользователями группы staff, только этой группой, а также запретит доступ (chmod 000) к тем исполняемым файлам suid, которые никем не используются. Серверу без монитора обычно не требуется исполняемый файл xterm. Исполняемые sgid исполняемые файлы могут быть почти так же опасны. Если нарушитель сможет взломать sgid-kmem исполняемый файл, он возможно сможет прочесть /dev/kmem и таким образом получить файл зашифрованных паролей, что потенциально делает возможным взлом любой защищённой паролем учётной записи. Аналогично нарушитель, проникший в группу kmem, может отслеживать последовательности клавиш, отправляемые через псевдо-терминалы, включая те, что используют защищённые соединения. Нарушитель, вошедший в группу tty может сделать вывод почти на любой пользовательский терминал. Если пользователь работает с терминальной программой или эмулятором с возможностью эмуляции клавиатуры, взломщик может потенциально сгенерировать поток данных, который заставит терминал пользователя ввести команду, и она будет запущена с правами этого пользователя. Защита учётных записей пользователей Учетные записи пользователей обычно сложнее всего защитить. Вы можете ввести драконовские ограничения доступа к служебным учётным записям, заменив их пароли на символ *, но возможно не сможете сделать то же с обычными учётными записями пользователей. Если есть такая возможность, вы возможно сможете защитить учётные записи пользователей соответствующим образом. Если нет, просто более бдительно отслеживайте эти учётные записи. Использование ssh и Kerberos для учётных записей пользователей более проблематично, поскольку требует дополнительной административной работы и технической поддержки, но все же это решение лучше, чем файл с шифрованными паролями. Защита файла паролей Единственный абсолютно надежный способ это замена на * максимально возможного количества паролей и использование ssh или Kerberos для доступа к таким учётным записям. Хотя файл с шифрованными паролями (/etc/spwd.db) доступен для чтения только root, возможно, что нарушитель сможет получить доступ на чтение к этому файлу, даже если не получит права root на запись. Ваши скрипты безопасности должны всегда проверять и составлять отчет об изменениях файла паролей (обратитесь к разделу Проверка целостности файлов ниже по тексту). Защита ядра, raw устройств и файловых систем Если атакующий взломает root, он сможет сделать практически все, но есть способы усложнить его задачу. Например, в большинстве современных ядер встроено устройство перехвата пакетов. В &os; оно называется bpf. Нарушитель обычно пытается запустить перехват пакетов на взломанной машине. Вы не должны предоставлять ему такой возможности, на большинстве систем устройство bpf не должно быть встроено в ядро. sysctl Но даже если вы выключите устройство bpf, все еще остаются проблемы, связанные с устройствами /dev/mem и /dev/kmem. Нарушитель все еще может писать на дисковые raw устройства. Есть также другая возможность ядра, загрузка модулей, &man.kldload.8;. Активный нарушитель может использовать KLD модуль для установки собственного устройства bpf или другого перехватывающего устройства на работающее ядро. Для решения этих проблем запускайте ядро с большим уровнем безопасности, как минимум 1. Уровень безопасности может быть установлен с помощью sysctl через переменную kern.securelevel. После установки уровня безопасности в 1 доступ на запись в raw устройства будет запрещена и полностью заработают специальные флаги chflags, такие как schg. Убедитесь также, что флаг schg установлен на критически важных загрузочных исполняемых файлах, каталогах и файлах скриптов — на всем, что запускается до установке уровня безопасности. Это требует большого объема работы, и обновление системы на более высоком уровне безопасности может стать гораздо сложнее. Вы можете пойти на компромисс и запускать систему на высоком уровне безопасности, но не устанавливать флаг schg для каждого существующего системного файла и каталога. Другая возможность состоит в монтировании / и /usr только для чтения. Необходимо заметить, что такие правила слишком жесткие и могут помешать обнаружению вторжения. Проверка целостности файлов: исполняемые, конфигурационные файлы и т.д. Вы можете защищать только ядро, файлы настройки и управления системой только до тех пор, пока эта защита не вступит в конфликт с удобством работы в системе. Например, использование chflags для установки бита schg на большинство файлов в / вероятно может только навредить, поскольку хотя и может защитить файлы, препятствует обнаружению. Последний слой системы безопасности, возможно, наиболее важный — обнаружение. Остальные меры безопасности практически бесполезны (или, что еще хуже, могут дать вам ложное ощущение безопасности) если вы не обнаружите потенциальное вторжение. Половина функций системы безопасности направлена на замедление атакующего, а не на его остановку, для того, чтобы дать системе обнаружения возможность поймать нарушителя на месте преступления. Лучший способ обнаружения вторжения — отслеживание измененных, отсутствующих, или неожиданно появившихся файлов. Для наблюдения за измененными файлами лучше всего использовать другую (зачастую централизованную) систему с ограниченным доступом. Добавление написанных вами скриптов к этой дополнительно защищенной системе с ограниченным доступом делает ее практически невидимой для потенциальных взломщиков, и это важно. В целях достижения максимального эффекта вам может потребоваться предоставить этой системе доступ к другим машинам в сети, обычно с помощью NFS экспорта только для чтения или сгенерировав пары ключей ssh для доступа к другим машинам по ssh. Помимо большого объема сетевого трафика, NFS более скрытый метод — он позволяет контролировать файловые системы на каждом клиентском компьютере практически незаметно. Если ваш сервер с ограниченным доступом подключен к клиентским компьютерам через коммутатор, NFS метод это зачастую лучший выбор. При соединении через концентратор, или через несколько маршрутизаторов, NFS метод может стать слишком небезопасным и использование ssh может стать лучшим выбором даже несмотря на то, что ssh оставляет следы своей работы. Как только у вас появился сервер с ограниченным доступом, и как минимум доступ на чтение в клиентских системах, потребуется написать скрипты для выполнения мониторинга. При наличии доступа по NFS вы можете написать скрипты с помощью простых системных утилит, таких как &man.find.1; и &man.md5.1;. Лучше всего подсчитывать md5 файлов на клиентском компьютере как минимум один раз в день, а файлы, контролирующие запуск из /etc и /usr/local/etc даже более часто. При обнаружении расхождений в md5, контролирующий компьютер должен просигналить системному администратору проверить изменившиеся файлы. Хороший скрипт безопасности проверит также наличие несоответствующих исполняемых suid файлов и новых или измененных файлов в системных разделах / и /usr. При использовании ssh вместо NFS, написать скрипты безопасности гораздо сложнее. Вам обязательно потребуется скопировать (scp) скрипты на клиентский компьютер, сделать из невидимыми, и для безопасности потребуется также скопировать исполняемые файлы (такие как find), которые будут использоваться скриптом. Приложение ssh на клиентском компьютере может быть уже взломано. В конечном итоге, без ssh не обойтись при работе через небезопасные соединения, но его гораздо сложнее использовать. Хороший скрипт безопасности проверит также изменения в файлах настройки, работающих при подключении пользователей и служебных учётных записей: .rhosts, .shosts, .ssh/authorized_keys и так далее… файлы, которые могли не попасть в область проверки MD5. Если для пользователей выделен большой объем дискового пространства, проверка каждого файла на таких разделах может занять слишком много времени. В таком случае установка флагов монтирования для запрета suid исполняемых файлов и устройств на таких разделах это хорошая идея. Примените параметры &man.mount.8; nodev и nosuid. Проверяйте эти разделы в любом случае, хотя бы раз в неделю, поскольку необходимо обнаруживать попытки взлома, независимо от того, эффективны они или нет. Учет процессов (&man.accton.8;) это относительно несложная возможность операционной системы, которая может помочь как механизм обнаружения состоявшихся вторжений. Она особенно полезна для обнаружения пути проникновения нарушителя в систему, если файл не был затронут проникновением. Наконец, скрипты безопасности должны обработать лог файлы, которые необходимо создавать настолько защищенным способом, насколько это возможно — подключение syslog удаленно может быть очень полезным. Злоумышленник попытается уничтожить следы взлома, и лог файлы критически важны для системного администратора, пытающегося отследить время и метод первого проникновения. Один из надежных способов получения лог файлов является подключение системной консоли к последовательному порту и постоянный сбор информации через защищенную машину, отслеживающую консоли. Паранойя Немного паранойи никогда не повредит. Как правило, системный администратор может добавлять элементы безопасности в любом количестве, пока это не влияет на удобство, а также некоторое количество элементов безопасности, влияющих на удобство. Что даже более важно, системный администратор должен немного изменить их — если вы используете рекомендации, например те, что даны в этом документе, они становятся известны атакующему, который также имеет доступ к этому документу. prospective attacker who also has access to this document. Атаки DoS Отказ в обслуживании (DoS) Этот раздел охватывает DoS атаки. DoS атаки это обычно пакетные атаки. Хотя против современной атаки с подделкой пакетов, которая перегружает сеть, мало что можно сделать, вы можете ограничить повреждения, убедившись, что атака не может обрушить ваши сервера. Ограничение количества порождаемых процессов. Уменьшение последствий springboard атак (ICMP ответ, широковещательный ping и т.д.). Кэш маршрутизации ядра. Обычная DoS атака против порождающего процессы сервера пытается исчерпать ресурсы сервера по процессам, файловым дескрипторам и памяти до тех пор, пока машина не повиснет. У inetd (обратитесь к &man.inetd.8;) есть несколько параметров, позволяющих ограничить такие атаки. Необходимо учесть, что хотя можно предотвратить падение системы, в общем случае невозможно предотвратить прекращение работы сервиса. Внимательно прочтите страницу справочника и обратите особое внимание на параметры , , и . Учтите, что параметр не работает в случае атак с использованием поддельных IP пакетов, поэтому как правило необходимо использование комбинации параметров. Некоторые standalone сервисы используют собственные параметры, ограничивающие порождение процессов. У Sendmail есть собственный параметр , которая работает гораздо лучше, чем параметр sendmail, ограничивающий нагрузку. Вам необходимо задать параметр запуска sendmail MaxDaemonChildren достаточно большим, чтобы обслуживать ожидаемую нагрузку, но так, чтобы компьютер мог обслужить такое количество приложений sendmail без падения системы. Хорошей мерой является запуск sendmail в режиме очереди () и запуск даемона (sendmail -bd) отдельно от очереди (sendmail -q15m). Если вы все же хотите организовать доставку в режиме реального времени, запускайте очередь с меньшим интервалом , но убедитесь в правильной установке параметра sendmail MaxDaemonChildren для предотвращения ошибок. Syslogd может быть атакован непосредственно, настоятельно рекомендуется использовать параметр если это возможно и параметр в остальных случаях. Вы также должны быть очень осторожны с сервисами, совершающими обратное подключение, например, с TCP Wrapper и его обратным identd-запросом, который может быть атакован напрямую. По этой причине возможность TCP Wrapper генерировать обратный ident обычно не следует использовать. Правильным будет запрет доступа к внутренним сервисам из внешней сети путем соответствующей настройки брандмауэра на внешнем маршрутизаторе. Идея в том, чтобы предотвратить перегрузку сервисов атаками из внешней сети, а кроме того защитить root от взлома через сеть. Всегда настраивайте исключающий брандмауэр, т.е. закрыть все кроме портов A, B, C, D, и M-Z. Этим способом вы можете закрыть все порты нижнего диапазона, кроме явно указанных, таких как named (если вы поддерживаете интернет-зону), ntalkd, sendmail, и других сервисов, доступных из интернет. Если вы попробуете настроить брандмауэр другим способом — включающий, или разрешающий брандмауэр, есть большой шанс забыть закрыть пару сервисов, или добавить новый внутрисетевой сервис и забыть обновить брандмауэр. Вы можете открыть диапазон портов с большими номерами для обычных приложений без угрозы портам нижнего диапазона. Учтите также, что &os; позволяет вам контролировать диапазоны портов, используемые для динамической привязки через различные переменные sysctl net.inet.ip.portrange (sysctl -a | fgrep portrange), что позволяет упростить настройку брандмауэра. Например, вы можете использовать обычный диапазон портов со значениями от 4000 до 5000, и диапазон портов с большими номерами от 49152 до 65535, а затем заблокировать все до 4000 порта (конечно оставив доступ из интернет к определенным портам. Другой распространенный тип DoS атак называется springboard — сервер атакуется таким образом, что генерируемые ответы перегружают его, локальную сеть или какие-то другие компьютеры. Наиболее распространенная атака этого вида это широковещательная ICMP ping атака. Атакующий подделывает пакеты ping, подставляя IP адрес машины, которую он намеревается атаковать, и отправляет их на широковещательный адрес вашей локальной сети. Если ваш внешний маршрутизатор не настроен на отбрасывание пакетов ping на широковещательные адреса, ваша сеть начинает генерировать соответствующие ответы на поддельный адрес, что приводит к перегрузке хоста-жертвы, особенно если атакующий использует этот же трюк с множеством широковещательных адресов в множестве сетей одновременно. Были зарегистрированы широковещательные атаки свыше ста двадцати мегабит. Другая распространенная springboard атака направлена на ICMP систему сообщения об ошибках. Конструируя пакеты, вызывающие ICMP сообщения об ошибках, атакующий может нагрузить входящее соединение сервера и вынудить сервер нагрузить исходящее соединение ICMP ответами. Этот тип атаки может также обрушить сервер, когда тот исчерпает mbuf, обычно если сервер не может ограничить число ответов ICMP, когда они генерируются слишком быстро. В ядре &os; 4.X есть опция сборки , которая ограничивает эффективность этого типа атак. Более поздние ядра используют переменную sysctl net.inet.icmp.icmplim. Последний основной класс springboard атак относится к определенным внутренним сервисам inetd, таким как сервис udp echo. Атакующий просто подделывает адрес источника и адрес назначения UDP пакетов, устанавливая в их качестве соответственно echo порт сервера A и B, оба этих сервера принадлежат вашей локальной сети. Эти два сервера начинают перебрасываться этим пакетом друг с другом. Атакующий может вызвать перегрузку обеих серверов и их сетей, просто отправив несколько пакетов таким способом. Аналогичные проблемы существуют с портом chargen. Компетентный системный администратор должен отключить эти тестовые сервисы inetd. Атаки с поддельными пакетами могут также использоваться для переполнения кэша маршрутизации ядра. Обратитесь к параметрам sysctl net.inet.ip.rtexpire, rtminexpire, и rtmaxcache. Атака с поддельными пакетами, использующая произвольный IP адрес источника, заставит ядро сгенерировать временный кэшированный маршрут в таблице маршрутизации, который можно увидеть с помощью netstat -rna | fgrep W3. Эти маршруты обычно удаляются через 1600 секунд или около того. Если ядро определит, что кэшированная маршрутная таблица стала слишком большой, оно динамически уменьшит rtexpire, но никогда не станет делать его меньше чем rtminexpire. С этим связаны две проблемы: Ядро не отреагирует достаточно быстро, когда легко нагруженный сервер будет внезапно атакован. Значение rtminexpire недостаточно мало для поддержки работоспособности в условиях продолжительной атаки. Если ваши серверы подключены к интернет через линию T3 или более быструю, предусмотрительно будет изменить оба значения rtexpire и rtminexpire с помощью &man.sysctl.8;. Никогда не устанавливайте ни один из этих параметров в нуль (если только вы не хотите обрушить систему). Установка обеих параметров в значение 2 секунды должна предотвратить таблицу маршрутизации от атак. Проблемы, связанные с доступом к Kerberos и SSH ssh KerberosIV При использовании Kerberos и ssh необходимо учесть несколько возможных проблем. Kerberos V это отличный протокол аутентификации, но в адаптированных к нему приложениях telnet и rlogin есть несколько ошибок, которые могут сделать их непригодными к работе с бинарными потоками. К тому же, по умолчанию Kerberos не шифрует сессию, если вы не используете параметр . ssh шифрует все по умолчанию. ssh работает очень хорошо во всех ситуациях, но пересылает ключи по умолчанию. Это означает, что если вы работаете с защищенной рабочей станции, ключи на которой дают доступ к остальной сети, и заходите по ssh на незащищенный компьютер, эти ключи могут быть использованы для взлома. Атакующему не удастся получить сами ключи, но поскольку ssh открывает порт во время входа в систему, то если на незащищенной машине взломан root, эти ключи могут быть использованы для доступа к другим компьютерам, на которых они действуют. Мы рекомендуем использовать ssh в комбинации с Kerberos для служебных учётных записей если это возможно. ssh может быть собран с поддержкой Kerberos. Это уменьшает зависимость от потенциально подверженных взлому ssh ключей, и в то же время защищает пароли через Kerberos. Ключи ssh должны использоваться только для работы скриптов на защищенных компьютерах (там, где Kerberos использовать не получится). Мы также рекомендуем или выключить передачу ключей в настройках ssh, или использовать параметр from=IP/DOMAIN, поддерживаемый ssh в файле authorized_keys, который позволяет использовать ключи только с определенных компьютеров. Bill Swingle Частично переписал и обновил DES, MD5, и шифрование безопасность шифрование шифрование DES MD5 У каждого пользователя &unix; системы есть пароль, связанный с его учётной записью. Очевидно, что эти пароли должны быть известны только пользователю и соответствующей операционной системе. Для защиты паролей они шифруются способом, известным как односторонний хэш, то есть их можно легко зашифровать, но нельзя расшифровать. Другими словами, то, что мы сказали чуть раньше было очевидно, но не совсем верно: операционной системе сам пароль неизвестен. Ей известен только пароль в зашифрованной форме. Единственный способ получить обычный пароль это простой перебор всех возможных паролей. К сожалению, единственный способ шифрования пароля при появлении &unix; был основан на DES, Data Encryption Standard. Это не было проблемой для пользователей, живущих в США, но поскольку исходный код DES нельзя было экспортировать из США, &os; нашла способ одновременно не нарушать законов США и сохранить совместимость со всеми другими вариантами &unix;, где все еще использовался DES. Решение было в разделении библиотек шифрования, чтобы пользователи в США могли устанавливать и использовать библиотеки DES, а у остальных пользователей был метод шифрования, разрешенный к экспорту. Так &os; пришла к использованию MD5 в качестве метода шифрования по умолчанию. MD5 считается более безопасным, чем DES, поэтому установка DES рекомендуется в основном из соображений совместимости. Определения механизма шифрования До &os; 4.4 libcrypt.a была символической ссылкой на библиотеку, используемую для шифрования. В &os; 4.4 libcrypt.a была изменена для предоставления настраиваемой библиотеки аутентификации по хэшу пароля. На данный момент библиотека поддерживает хэши DES, MD5 и Blowfish. По умолчанию &os; использует для шифрования паролей MD5. Довольно легко определить какой метод шифрования используется в &os;. Один из способов это проверка файла /etc/master.passwd. Пароли, зашифрованные в хэш MD5 длиннее, чем те, что зашифрованы с помощью DES и начинаются с символов $1$. Пароли, начинающиеся с символов $2a$ зашифрованы с помощью Blowfish. Пароли, зашифрованные DES не содержат каких-то определенных идентифицирующих символов, но они короче, чем пароли MD5 и закодированы в 64-символьном алфавите, не содержащем символа $, поэтому относительно короткая строка, не начинающаяся с этого символа это скорее всего DES пароль. Формат паролей, используемых для новых паролей, определяется параметром passwd_format в /etc/login.conf, которое может принимать значения des, md5 или blf. Обратитесь к странице справочника &man.login.conf.5; за дополнительной информацией о параметрах login. Одноразовые пароли одноразовые пароли безопасность одноразовые пароли S/Key это схема с одноразовыми паролями, основанная на одностороннем хэше. &os; использует хэш MD4 для совместимости, но другие системы используют MD5 и DES-MAC. S/Key была частью базовой системы &os; начиная с версии 1.1.5 и используется также во все большем числе операционных систем. S/Key это зарегистрированная торговая марка Bell Communications Research, Inc. Начиная с &os; версии 5.0, S/Key была замещена на функциональный эквивалент — OPIE (One-time Passwords In Everything). OPIE по умолчанию использует MD5. Есть три различных вида паролей, о которых мы поговорим ниже. Первый вид это ваш обычный пароль &unix; или пароль Kerberos; мы будем называть его пароль &unix;. Второй вид это одноразовый пароль, сгенерированный программой S/Key key или программой OPIE &man.opiekey.1; и принимаемый командами keyinit или &man.opiepasswd.1; и в приглашении login; мы будем называть их одноразовыми паролями. Последний вид паролей это защищенные пароли, которые вы передаете программам key/opiekey (и иногда программам keyinit/opiepasswd), и которые эти программы используют для создания одноразовых паролей; мы будем называть его защищенными паролями или просто паролями. Защищенный пароль не имеет никакого отношения к вашему паролю &unix;; они могут быть одинаковыми, но это не рекомендуется. Защищенные пароли S/Key и OPIE не ограничены 8-ю символами, как старые &unix; паролиВ &os; стандартный пароль может быть до 128 символов длиной., они могут быть настолько длинными, насколько вы захотите. Очень часто используются пароли длиной в шесть или семь символов. По большей части система S/Key или OPIE работает полностью независимо от системы паролей &unix;. Помимо паролей, есть два других вида данных, важных для S/Key и OPIE. Первый, известный как seed или ключ, состоит из двух букв и пяти цифр. Другой, называемый счетчиком цикла, это номер от 1 до 100. S/Key создает одноразовый пароль, соединяя ключ и защищенный пароль, а затем применяя MD4/MD5 столько раз, сколько указано счетчиком цикла и выдает результат в виде шести коротких слов на английском. Эти шесть слов на английском и есть ваш одноразовый пароль. Система аутентификации (как правило PAM) хранит последний использованный одноразовый пароль, и пользователь аутентифицируется если хэш вводимого пользователем пароля совпадает с предыдущим паролем. Поскольку используется односторонний хэш, невозможно сгенерировать следующий одноразовый пароль если получен предыдущий; счетчик цикла уменьшается после каждого успешного входа для поддержки синхронизации пользователя с программой login. Когда счетчик цикла уменьшается до 1, S/Key и OPIE должны быть переинициализированы. В каждой из обсуждаемых ниже систем задействованы три программы. Программы key и opiekey получают счетчик цикла, ключ и защищенный пароль и создают одноразовый пароль или последовательный список одноразовых паролей. Программы keyinit и opiepasswd используются для инициализации S/Key и OPIE соответственно, и для смены паролей, счетчиков цикла, или ключей; они принимают защищенный пароль или счетчик цикла, ключ и одноразовый пароль. Программы keyinfo и opieinfo проверяют соответствующие файлы (/etc/skeykeys или /etc/opiekeys) и печатают текущий счетчик цикла и ключ вызывающего пользователя. Мы рассмотрим четыре вида операций. Первая это использование keyinit или opiepasswd через защищенное соединение для первоначальной настройки системы одноразовых паролей, или для изменения пароля или ключа. Вторая операция это использование в тех же целях keyinit или opiepasswd через незащищенное соединение, в сочетании с key или opiekey через защищенное соединение. Третья это использование key/opiekey для входа через незащищенное соединение. Четвертая это использование key или opiekey для генерации набора ключей, которые могут быть записаны или распечатаны для соединения из места, где защищенное соединение недоступно. Защищенная установка соединения Для первоначальной настройки S/Key, измените ваш пароль или ключ при входе через защищенное соединение (например, с консоли компьютера или через ssh), используйте команду keyinit без параметров при входе под своим именем: &prompt.user; keyinit Adding unfurl: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. Enter secret password: Again secret password: ID unfurl s/key is 99 to17757 DEFY CLUB PRO NASH LACE SOFT Для OPIE, вместо этого используется opiepasswd: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED В приглашениях Enter new secret pass phrase: или Enter secret password:, введите пароль или фразу. Запомните, это не тот пароль, с которым вы будете входить, он используется для генерации одноразовых паролей. Строка ID содержит информацию для вашего конкретного случая: имя пользователя, счетчик цикла и ключ. При входе система запомнит эти параметры и отправит их вам, поэтому их не надо запоминать. В последней строке находится одноразовый пароль, соответствующий этим параметрам и секретному паролю; если вы войдете в систему сразу, используйте этот одноразовый пароль. Незащищенная установка соединения Для инициализации или изменения защищенного пароля через незащищенное соединение, вам потребуется существующее защищенное соединение куда-то, где вы сможете запустить key или opiekey; это может быть средство доступа &macintosh; или shell на компьютере, которому вы доверяете. Вам потребуется также установить значение счетчика цикла (100 возможно подойдет), и задать ключ или использовать сгенерированный. Через незащищенное соединение (к компьютеру, на котором производится настройка), используйте команду keyinit -s: &prompt.user; keyinit -s Updating unfurl: Old key: to17758 Reminder you need the 6 English words from the key command. Enter sequence count from 1 to 9999: 100 Enter new key [default to17759]: s/key 100 to 17759 s/key access password: s/key access password:CURE MIKE BANE HIM RACY GORE Для OPIE, используйте opiepasswd: &prompt.user; opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY Чтобы принять ключ по умолчанию нажмите Enter. Затем, перед вводом пароля доступа введите те же параметры в вашем защищенном соединении или средстве доступа S/Key: &prompt.user; key 100 to17759 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <secret password> CURE MIKE BANE HIM RACY GORE Или для OPIE: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Теперь переключитесь на незащищенное соединение и скопируйте одноразовый пароль, сгенерированный соответствующей программой. Создание одного одноразового пароля Как только вы настроите S/Key или OPIE, во время входа появится приглашение вроде этого: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <username> s/key 97 fw13894 Password: Или для OPIE: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <username> otp-md5 498 gr4269 ext Password: Кроме того, у S/Key и OPIE есть полезная особенность (не показанная здесь): если вы нажмете Enter в приглашении на ввод пароля, включится эхо, и вы сможете увидеть то, что вводите. Это может быть очень полезно, если вы пытаетесь ввести пароль вручную, например с распечатки. MS-DOS Windows MacOS В этот момент вам потребуется сгенерировать одноразовый пароль, чтобы ввести его в приглашение. Это должно быть выполнено на защищенной системе, в которой вы можете запустить key или opiekey (есть версии для DOS, &windows; и &macos;). Им требуются значения счетчика цикла и ключ в качестве параметров командной строки. Вы можете скопировать и вставить их прямо из приглашения login компьютера, на который входите. В защищенной системе: &prompt.user; key 97 fw13894 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: WELD LIP ACTS ENDS ME HAAG Для OPIE: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Теперь, когда у вас есть одноразовый пароль, можете продолжить вход в систему: login: <username> s/key 97 fw13894 Password: <return to enable echo> s/key 97 fw13894 Password [echo on]: WELD LIP ACTS ENDS ME HAAG Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... Создание нескольких одноразовых паролей Иногда вы отправляетесь туда, где нет доступа к защищенному компьютеру или защищенному соединению. В этом случае, можно использовать команды key и opiekey для создания нескольких одноразовых паролей, которые вы сможете распечатать и забрать с собой. Например: &prompt.user; key -n 5 30 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <secret password> 26: SODA RUDE LEA LIND BUDD SILT 27: JILT SPY DUTY GLOW COWL ROT 28: THEM OW COLA RUNT BONG SCOT 29: COT MASH BARR BRIM NAN FLAG 30: CAN KNEE CAST NAME FOLK BILK Или для OPIE: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: <secret password> 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI Параметр запрашивает пять паролей, указывает значение последнего счетчика цикла. Обратите внимание, что пароли печатаются в обратном по сравнению с обычным использованием порядке. Если вы действительно параноик, перепишите результат вручную; иначе скопируйте и передайте его lpr. Обратите внимание, что каждая линия содержит как счетчик цикла, так и одноразовый пароль; вам может показаться удобным отрывать пароль после использования. Ограничение использования &unix; паролей S/Key может наложить ограничения на использование &unix; паролей на основе имени хоста, имени пользователя, порта терминала или IP адреса сессии. Эти ограничения можно найти в файле настройки /etc/skey.access. Страница справочника &man.skey.access.5; содержит дополнительную информацию о полном формате файла а также детали о некоторых предосторожностях, которые должны быть предприняты перед тем, как положиться в вопросах безопасности на этот файл. Если файла /etc/skey.access нет (это ситуация по умолчанию в системах &os; 4.X), всем пользователям будет разрешено входить с паролями &unix;. Если файл существует, использование S/Key станет обязательно для всех, если только параметры настройки в файле skey.access не указывают иначе. В любом случае, пароли &unix; разрешены при входе с консоли. Вот пример файла настройки skey.access, иллюстрирующий три наиболее распространенных вида параметров настройки: permit internet 192.168.0.0 255.255.0.0 permit user fnord permit port ttyd0 Первая строка (permit internet) разрешает пользователям, чей IP адрес (который подвержен подделке) соответствует заданному значению и маске, входить с использованием паролей &unix;. Это должно рассматриваться не как механизм безопасности, а как напоминание пользователям, что они работают через небезопасное соединение и должны использовать для аутентификации S/Key. Вторая строка (permit user) позволяет определенным пользователям, в данном случае fnord, всегда использовать пароли &unix;. Вообще говоря, это должно использоваться только для тех, кто не может использовать программу key, например если они работают с простых терминалов или необучаемы. Третья строка (permit port) позволяет всем пользователям, вошедшим с определенного терминала использовать пароли &unix;; этот параметр должен использоваться для подключений по dial-up. OPIE может ограничивать использование паролей &unix; на основе IP адреса как и S/Key. Соответствующий файл называется /etc/opieaccess, он существует по умолчанию в &os; 5.0 и более современных системах. Обратитесь к &man.opieaccess.5; за более подробной информацией об этом файле и о предосторожностях, которые вы должны предпринять при использовании этого файла. Вот пример файла opieaccess: permit 192.168.0.0 255.255.0.0 Эта строка позволяет пользователям, чей IP адрес (который подвержен подделке) соответствует указанному значению и маске, входить с паролем &unix;. Если ни одно из правил в opieaccess не сработало, поведением по умолчанию является запрет всех не-OPIE входов. Tom Rhodes Написал: TCP Wrappers TCP Wrappers Каждый, кто знаком с &man.inetd.8;, возможно когда-то слышал о TCP Wrappers. Но немногие полностью понимают их полезность в сетевой среде: большинство используют брандмауэр. Хотя его применимость очень широка, есть вещи, с которыми брандмауэр не может работать, такие как отправка текста обратно вызывающей стороне. Программное обеспечение уровня TCP может делать это и многое другое. В следующих нескольких разделах обсуждаются многие возможности TCP Wrappers, и, когда это необходимо, даются примеры настроек. Программное обеспечение TCP Wrappers расширяет возможность inetd по поддержке каждого даемона. С ним становится возможным протоколирование, возврат сообщений вызывающей стороне, ограничение подключений внутренней сетью и т.п. Хотя некоторые из этих возможностей могут быть реализованы брандмауэром, TCP Wrappers не только предоставляют дополнительный уровень защиты, но и дают больше контроля над системой, чем это возможно с брандмауэром. Расширенная функциональность обработчиков TCP не может заменить хороший сетевой экран. Тем не менее, обработчики TCP могут использоваться совместно с сетевым экраном и другими средствами обеспечения информационной безопасности, обеспечивая тем самым дополнительный уровень защиты системы. Поскольку рассматривается расширение к настройкам inetd, предполагается, что читатель ознакомился с разделом о настройке inetd. Хотя программы, запускаемые из &man.inetd.8;, на самом деле не соответствуют термину даемоны, существует традиция называть их именно так. Этот термин и используется в данном разделе. Начальная настройка Единственное требование для использования TCP Wrappers в &os; это наличие в rc.conf параметров запуска inetd ; это настройки по умолчанию. Конечно, ожидается также наличие правильной настройки /etc/hosts.allow, но &man.syslogd.8; отправит сообщения в системный протокол если что-то не так. В отличие от других реализаций TCP Wrappers, использование hosts.deny не поддерживается. Все параметры настройки должны быть помещены в /etc/hosts.allow. В простейшей конфигурации, политика подключения сводится к разрешению или блокированию в зависимости от параметров в /etc/hosts.allow. Настройка в &os; по умолчанию заключается в разрешении подключения к любому даемону, запущенному из inetd. Изменение этого поведения будет обсуждаться только после рассмотрения базовой настройки. Базовая настройка обычно принимает форму daemon : address : action, где daemon это имя даемона, который запускается inetd. В поле address может находиться имя хоста, IP адрес, или IPv6 адрес, заключенный в квадратные скобки ([ ]). Поле action может принимать значения allow или deny, чтобы соответственно разрешать или запрещать доступ. Помните, что поиск правил производится до первого совпадения. При обнаружении совпадения применяется соответствующее правило и поиск прерывается. Существуют и другие параметры, но они будут описаны в следующих разделах. Простая конфигурация может быть, например, такой: для разрешения соединений по протоколу POP3 к даемону mail/qpopper, в hosts.allow необходимо добавить следующие строки: # This line is required for POP3 connections: qpopper : ALL : allow После добавления этой строки, inetd необходимо перезапустить. Это можно выполнить командой &man.kill.1; или скриптом /etc/rc.d/inetd с параметром restart. Расширенная конфигурация У TCP Wrappers имеются дополнительные параметры; они дают дополнительные возможности контроля над соединениями. Иногда бывает полезно возвращать комментарий определенным хостам или при подключении к определенным даемонам. В других случаях может быть необходимо добавить запись в лог файл, или отправить письмо администратору. В определенных ситуациях сервис должен использоваться только для локальных соединений. Все это возможно с использованием параметров c шаблонами, символами подстановки и путем выполнения внешних команд. Следующие два раздела посвящены этим типам настроек. Внешние команды Предположим ситуацию, в которой соединение должно быть запрещено, а о причине необходимо сообщить вызывающей стороне. Как это можно сделать? Соответствующую возможность предоставляет параметр . При попытке подключения выполняется команда или скрипт, заданный этим параметром. Пример дан в файле hosts.allow: # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." В этом примере сообщение, You are not allowed to use daemon from hostname. будет возвращено от всех даемонов, которые не были предварительно настроены в файле доступа. Обратите внимание, что возвращаемое сообщение должно быть заключено в кавычки; из этого правила нет исключений. Возможна реализация DoS атаки, когда группа атакующих производит множество запросов на подключение. Возможно также использование параметра . Как и параметр , параметр подразумевает запрет соединения и может использоваться для запуска команд или скриптов. В отличие от , не отправляет ответ вызывающей стороне. Например, следующая конфигурация: # We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny отклонит все попытки соединения из домена *.example.com; имя хоста, IP адрес и даемон протоколируются в файл /var/log/connections.log. Помимо приведенных выше символов подстановки, например %a, существует еще несколько символов. Обратитесь к странице &man.hosts.access.5; справочной системы за полным списком. Параметры – шаблоны До этого момента в примерах использовался шаблон ALL. Существуют и другие параметры, функциональность которых в дальнейшем может быть расширена. ALL соответствует любому даемону, домену или IP адресу. Другой доступный шаблон это PARANOID, который соответствует хосту, IP адрес которого может быть подделан. Другими словами, paranoid может быть использован для определения действия с хостами, IP адрес которых не соответствует имени хоста. Вот пример применения этого параметра: # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny В этом примере все запросы на подключения к sendmail от хостов, IP адрес которых не соответствует имени хоста, будут отклонены. Использование PARANOID невозможно, если у клиента или сервера неправильно настроен DNS. В таких случаях необходимо вмешательство администратора. Более подробная информация о шаблонах и их возможностях дана на странице &man.hosts.access.5; справочной системы. Для того, чтобы любая выбранная конфигурация заработала, в hosts.allow необходимо закомментировать первую строку настройки. В начале раздела об этом не упоминалось. Mark Murray Предоставил Mark Dapoz Оригинальный текст предоставил <application>KerberosIV</application> Kerberos это сетевая дополнительная система/протокол, которая делает возможной аутентификацию пользователей через сервисы на защищенном сервере. Такие сервисы, как удаленный вход, удаленное копирование, защищенное копирование файлов между системами и другие задачи с высоким риском становятся допустимо безопасными и более контролируемыми. Последующие инструкции могут использоваться в качестве руководства по настройке поставляемого с &os; Kerberos. Тем не менее, вам могут потребоваться страницы справочника полного дистрибутива. Установка <application>KerberosIV</application> MIT KerberosIV установка Kerberos это опциональный компонент &os;. Простейший способ установки этой программы это выбор krb4 или krb5 из sysinstall во время первой установки &os;. Будет установлен eBones (KerberosIV) или Heimdal (Kerberos5) вариант Kerberos. Включение этих реализаций объясняется тем, что они разработаны вне США/Канады и доступны вне этих стран, поскольку на них не влияют ограничения на экспорт криптографического кода из США. Кроме того, реализация MIT Kerberos доступна из Коллекции Портов в виде пакета security/krb5. Создание базы данных Это необходимо сделать только на сервере Kerberos. Во-первых, убедитесь что не осталось старой базы данных Kerberos. Войдите в каталог /etc/kerberosIV и убедитесь, что в нем находятся только эти файлы: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms Если присутствуют еще какие-то файлы (такие как principal.* или master_key), используйте команду kdb_destroy для удаления старой базы данных Kerberos, или, если Kerberos не запущен, просто удалите эти файлы. Затем отредактируйте файлы krb.conf и krb.realms, введя ваши данные. В этом примере уникальный идентификатор EXAMPLE.COM, сервер grunt.example.com. Отредактируем или создадим файл krb.conf: &prompt.root; cat krb.conf EXAMPLE.COM EXAMPLE.COM grunt.example.com admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov В этом примере другие идентификаторы введены для иллюстрации настройки c несколькими хостами. С целью упрощения настройки вы можете не включать их. Первая строка содержит идентификатор, под которым работает эта система. Остальные строки связывают идентификаторы с именами хостов. Сначала указывается идентификатор, затем хост под этим идентификатором, работающий как центр распространения ключей. Слова admin server с последующим именем хоста означают, что этот хост также является сервером администрирования базы данных. За дальнейшей информацией об этих терминах обратитесь к страницам справочника по Kerberos. Мы добавили grunt.example.com к идентификатору EXAMPLE.COM и кроме того сопоставили всем хостам в домене .example.com идентификатор EXAMPLE.COM. Файл krb.realms будет выглядеть так: &prompt.root; cat krb.realms grunt.example.com EXAMPLE.COM .example.com EXAMPLE.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU Как и в предыдущем примере, другие идентификаторы добавлены только для примера. С целью упрощения настройки вы можете не включать их. В первой строке определенная система сопоставляется с идентификатором. В остальных строках показано, сопоставить идентификатору остальные системы определенного поддомена. Теперь мы готовы к созданию базы данных. Потребуется всего лишь запустить сервер Kerberos (или центр распространения ключей). Используйте для этого kdb_init: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Введите главный ключ Kerberos: Теперь мы должны сохранить ключ, чтобы сервера на локальных компьютерах могли его взять. Используйте для этого команду kstash: &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Этой командой зашифрованный главный пароль сохранен в /etc/kerberosIV/master_key. Запуск Kerberos KerberosIV первый запуск Для каждой системы, защищаемой Kerberos, в базу данных должны быть добавлены две записи. Это kpasswd и rcmd. Они добавляются вместе с именем системы. Эти даемоны, kpasswd и rcmd позволяют другим системам изменять пароли Kerberos и запускать такие команды как &man.rcp.1;, &man.rlogin.1;, &man.rsh.1;. Теперь добавим эти записи: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Создание файла настройки сервера Теперь необходимо создать все записи сервисов, которые были определены для каждого компьютера. Используем для этого команду ext_srvtab. Будет создан файл, который должен быть скопирован или перемещен безопасным способом в каталог /etc/kerberosIV каждого Kerberos клиента. Этот файл должен присутствовать на каждом сервере и клиенте, он необходим для работы Kerberos. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... Эта команда создаст временный файл, который должен быть переименован в srvtab, чтобы серверы смогли обратиться к нему. Используйте команду &man.mv.1; для перемещения его в исходной системе: &prompt.root; mv grunt-new-srvtab srvtab Если файл предназначен для клиентской системы, и сеть не безопасна, скопируйте client-new-srvtab на съемный носитель и перенесите файл с его помощью. Убедитесь, что переименовали его в srvtab в каталоге /etc/kerberosIV клиента, и что режим доступа к нему 600: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab Пополнение базы данных Теперь необходимо добавить в базу данных пользователей. Во-первых, создадим запись для пользователя jane. Используйте команду kdb_edit: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- enter a secure password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Тестирование всей системы Во-первых, запустите даемоны Kerberos. При правильном редактировании файла /etc/rc.conf они запустятся автоматически при перезагрузке. Это необходимо только на сервере Kerberos. Клиенты Kerberos получат все необходимые данные из каталога /etc/kerberosIV. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: EXAMPLE.COM &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! Теперь для получения доступа через созданного пользователя jane используйте kinit: &prompt.user; kinit jane MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane" Password: Попробуйте просмотреть имеющиеся данные с помощью klist: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@EXAMPLE.COM Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM Теперь попробуйте изменить пароль с помощью &man.passwd.1;, чтобы убедиться, что даемон kpasswd может получить информацию из базы данных Kerberos: &prompt.user; passwd realm EXAMPLE.COM Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. Включение <command>su</command> Kerberos позволяет назначить каждому пользователю, который нуждается в привилегиях root, свой собственный пароль &man.su.1;. Необходимо добавить учётную запись, которой разрешено получать root доступ через &man.su.1;. Это делается путем связывания учётной записи root с пользовательской учётной записью. Создадим в базе данных Kerberos запись jane.root с помощью kdb_edit: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- enter a SECURE password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Теперь проверим работоспособность этой записи: &prompt.root; kinit jane.root MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane.root" Password: Необходимо добавить пользователя к root файлу .klogin: &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM Теперь попробуйте выполнить &man.su.1;: &prompt.user; su Password: и посмотрите на имеющиеся данные: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@EXAMPLE.COM Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM Использование других команд В примере выше мы создали запись (principal) jane с доступом к root (instance). Она основана на пользователе с таким же именем, как и идентификатор, что принято Kerberos по умолчанию; <principal>.<instance> в форме <username>.root позволяет использовать &man.su.1; для доступа к root, если соответствующие записи находятся в файле .klogin домашнего каталога root: &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM Подобно этому, если в файле .klogin из домашнего каталога пользователя есть строки в форме: &prompt.user; cat ~/.klogin jane@EXAMPLE.COM jack@EXAMPLE.COM это позволит любому с идентификатором EXAMPLE.COM, кто аутентифицировался как jane или jack (с помощью команды kinit, см. выше) получить доступ к учётной записи пользователя jane или файлам этой системы (grunt) через &man.rlogin.1;, &man.rsh.1; или &man.rcp.1;. Например, jane может входить в другую систему используя Kerberos: &prompt.user; kinit MIT Project Athena (grunt.example.com) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Или jack входит в учётную запись jane's на этом же компьютере (файл .klogin jane настроен как показано выше, и в Kerberos настроена учётная запись jack): &prompt.user; kinit &prompt.user; rlogin grunt -l jane MIT Project Athena (grunt.example.com) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Tillman Hodgson Предоставил Mark Murray Оригинальный материал предоставил <application>Kerberos5</application> Все релизы &os; после &os;-5.1 включают поддержку только Kerberos5. Таким образом, Kerberos5 это единственная включаемая в поставку версия и его конфигурация похожа на KerberosIV во многих аспектах. Эта информация применима только к Kerberos5 из релизов после &os;-5.0. Пользователи, желающие использовать пакет KerberosIV, могут установить его из порта security/krb4. Kerberos это дополнительная сетевая система/протокол, позволяющая пользователям авторизоваться через защищенные сервисы на защищенном сервере. Такие сервисы как удаленный вход, удаленное копирование, защищенное копирование файлов между системами и другие задачи с высоким риском становятся допустимо безопасными и более контролируемыми. Kerberos может быть описана как прокси система идентификации-проверки. Она также может быть описана как защищенная внешняя система аутентификации. Kerberos предоставляет только одну функцию — защищенную аутентификацию пользователей сети. Он не предоставляет функций авторизации (что разрешено делать пользователям) или функций аудита (какой пользователь что делает). После того, как клиент и сервер использовали Kerberos для идентификации, они могут зашифровать все соединения для гарантирования собственной безопасности и целостности данных. Следовательно крайне рекомендуется использовать Kerberos с другими методами безопасности, предоставляющими сервисы авторизации и аудита. Последующие инструкции могут использоваться в качестве руководства по настройке Kerberos, поставляемого с &os;. Тем не менее, вам потребуется обратиться к соответствующим страницам справочника за полным описанием. В целях демонстрации установки Kerberos, будут применены следующие обозначения: DNS домен (зона) example.org. Уникальный идентификатор Kerberos EXAMPLE.ORG. Используйте действующие имена доменов при настройке Kerberos даже если вы будете использовать его во внутренней сети. Это позволит избежать проблем с DNS и гарантирует возможность связи с Kerberos под другими идентификаторами. История Kerberos5 история Kerberos был создан MIT в качестве решения проблем с безопасностью сети. Протокол Kerberos использует стойкую криптографию, так что клиент может идентифицироваться на сервере (и обратно) через незащищенное сетевое соединение. Kerberos это и имя сетевого протокола аутентификации и общий термин для описания программ, где он реализован (например, Kerberos telnet). Текущая версия протокола 5 описана в RFC 1510. Доступно несколько свободных реализаций этого протокола, работающих на множестве операционных систем. Massachusetts Institute of Technology (MIT), где Kerberos был первоначально разработан, продолжает разрабатывать собственный пакет Kerberos. Он обычно использовался в США как криптографический продукт, и в этом качестве попадал под действие ограничений на экспорт. MIT Kerberos доступен в виде порта (security/krb5). Heimdal Kerberos это другая реализация версии 5, которая разрабатывалась исключительно вне США для обхода экспортных ограничений (и поэтому часто включалась в некоммерческие реализации &unix;). Heimdal Kerberos доступен в виде порта (security/heimdal), его минимальный комплект включен в базовую установку &os;. В целях получения наибольшей аудитории, в этих инструкциях предполагается использование Heimdal включаемого в &os;. Настройка Heimdal <acronym>KDC</acronym> Kerberos5 центр распространения ключей Центр распространения ключей (Key Distribution Center, KDC) это централизованный сервис аутентификации, предоставляемый Kerberos — это компьютер, который предоставляет доступ через Kerberos. KDC считается доверяемым всеми другими компьютерами с определенным идентификатором Kerberos и поэтому к нему предъявляются высокие требования безопасности. Имейте ввиду, что хотя работа сервера Kerberos требует очень немного вычислительных ресурсов, из соображений безопасности для него рекомендуется отдельный компьютер, работающий только в качестве KDC. Перед началом настройки KDC, убедитесь что в файле /etc/rc.conf содержатся правильные настройки для работы в качестве KDC (вам может потребоваться изменить пути в соответствии с собственной системой): kerberos5_server_enable="YES" kadmind5_server_enable="YES" kerberos_stash="YES" Параметр существует только в &os; 4.X. Затем приступим к редактированию файла настройки Kerberos, /etc/krb5.conf: [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG Обратите внимание что в файле /etc/krb5.conf подразумевается наличие у KDC полного имени kerberos.example.org. Вам потребуется добавить CNAME (синоним) к файлу зоны, если у KDC другое имя. Для больших сетей с правильно настроенным сервером BIND DNS пример выше может быть урезан до: [libdefaults] default_realm = EXAMPLE.ORG Со следующими строками, добавленными в файл зоны example.org: _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG Чтобы клиенты могли найти сервисы Kerberos, необходимо наличие или полностью настроенного /etc/krb5.conf или минимально настроенного /etc/krb5.conf и правильно настроенного DNS сервера. Создадим теперь базу данных Kerberos. Эта база данных содержит ключи всех основных хостов, зашифрованных с помощью главного пароля. Вам не требуется помнить этот пароль, он хранится в файле (/var/heimdal/m-key). Для создания главного ключа запустите kstash и введите пароль. Как только будет создан главный ключ, вы можете инициализировать базу данных с помощью программы kadmin с ключом -l (означающим local). Этот ключ сообщает kadmin обращаться к файлам базы данных непосредственно вместо использования сетевого сервиса kadmind. Это помогает решить проблему курицы и яйца, когда обращение идет к еще не созданной базе данных. Как только вы увидите приглашение kadmin, используйте команду init для создания базы данных идентификаторов. Наконец, оставаясь в приглашении kadmin, создайте первую запись с помощью команды add. Оставьте неизменными параметры по умолчанию, вы всегда сможете изменить их позже с помощью команды modify. Обратите внимание, что вы всегда можете использовать команду ? для просмотра доступных параметров. Пример создания базы данных показан ниже: &prompt.root; kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx Теперь пришло время запустить сервисы KDC. Выполните команды /etc/rc.d/kerberos start и /etc/rc.d/kadmind start для запуска сервисов. Заметьте, что ни один из поддерживающих Kerberos даемонов на этот момент запущен не будет, но у вас должна быть возможность убедиться в том, что KDC функционирует путем получения списка доступа для пользователя, которого вы только что самостоятельно создали из командной строки самого KDC: &prompt.user; k5init tillman tillman@EXAMPLE.ORG's Password: &prompt.user; k5list Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG Сервер <application>Kerberos</application> с сервисами Heimdal Kerberos5 включение сервисов Для начала нам потребуется копия файла настройки Kerberos, /etc/krb5.conf. Просто скопируйте его с KDC на клиентский компьютер безопасным способом (используя сетевые утилиты, такие как &man.scp.1;, или физически, с помощью дискеты). Затем вам понадобится файл /etc/krb5.keytab. Это основное различие между сервером, поддерживающим Kerberos и рабочими станциями — на сервере должен быть файл keytab. В этом файле находится центральный ключ сервера, который позволяет KDC проверять все другие идентификаторы. Он должен быть помещен на сервер безопасным способом, поскольку безопасность сервера может быть нарушена, если ключ станет общедоступен. Это означает, что его передача через прозрачный канал, такой как FTP — очень плохая идея. Обычно перенос файла keytab на сервер производится с помощью программы kadmin. Это удобно, поскольку вам потребуется также создать запись хоста (KDC часть krb5.keytab) с помощью kadmin. Обратите внимание, что должны быть уже зарегистрированы в системе и необходимо наличие прав на использование интерфейса kadmin в файле kadmind.acl. Обратитесь к разделу Remote administration в info страницах Heimdal (info heimdal) за деталями по составлению списка доступа. Если вы не хотите включать удаленный доступ kadmin, можете просто подключиться к KDC через защищенное соединение (локальную консоль, &man.ssh.1; или Kerberos &man.telnet.1;) и выполнять администрирование локально с помощью kadmin -l. После добавления файла /etc/krb5.conf, вы можете использовать kadmin с сервера Kerberos. Команда add --random-key позволит вам добавить запись для сервера, а команда ext позволит перенести эту запись в собственный keytab файл сервера. Например: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/myserver.example.org kadmin> exit Обратите внимание, что команда ext (сокращение от extract) сохраняет полученный ключ в файле /etc/krb5.keytab по умолчанию. Если на KDC не запущен kadmind (возможно по соображениям безопасности) и вы не можете получить доступ к kadmin удаленно, возможно добавление записи хоста (host/myserver.EXAMPLE.ORG) непосредственно на KDC с последующим извлечением ее во временный файл (и перезаписью /etc/krb5.keytab на KDC) примерно так: &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit Затем вы можете скопировать keytab на сервер защищенным способом (например, используя scp или дискету). Убедитесь, что используемое имя keytab не совпадает с именем по умолчанию во избежание перезаписывания keytab на KDC. Теперь ваш сервер может связываться с KDC (добавлен файл krb5.conf) и идентифицировать себя (добавлен файл krb5.keytab). Теперь вы готовы к включению некоторых сервисов Kerberos. В этом примере мы включим сервис telnet, поместив в /etc/inetd.conf нижеприведенную строку и перезапустив сервис &man.inetd.8; командой /etc/rc.d/inetd restart: telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user Очень важно установить ключ -a (тип аутентификации) в user. Обратитесь к странице справочника &man.telnetd.8; за подробной информацией. Клиент <application>Kerberos</application> с Heimdal Kerberos5 настройка клиентов Настройка клиентского компьютера почти тривиально проста. Как только настройка Kerberos закончена, вам потребуется только файл настройки Kerberos, /etc/krb5.conf. Просто скопируйте его безопасным способом на клиентский компьютер с KDC. Протестируйте клиентский компьютер, попытавшись использовать kinit, klist, и kdestroy для получения, отображения и удаления списка доступа. Соединитесь с Kerberos севером используя клиент Kerberos, если соединение не работает и получение доступа является проблемой, это скорее всего проблема сервера, а не клиента или KDC. При тестировании приложения вроде telnet, попробуйте использовать программу перехвата пакетов (такую как &man.tcpdump.1;), чтобы убедиться, что ваш пароль не передается незашифрованным. Попробуйте использовать telnet с параметром -x, чтобы зашифровать весь поток данных (подобно ssh). Основные клиентские приложения Kerberos (традиционно называющиеся kinit, klist, kdestroy, и kpasswd) находятся в базовой установке &os;. Обратите внимание, что в &os; версий до 5.0 они были переименованы в k5init, k5list, k5destroy, k5passwd, и k5stash (хотя их обычно использовали лишь однократно). Различные неосновные клиентские приложения Kerberos также устанавливаются по умолчанию. Здесь проявляется минимальность базовой установки Heimdal: telnet это единственное приложение, поддерживающее Kerberos. Порт Heimdal добавляет некоторые отсутствующие клиентские приложения: поддерживающие Kerberos версии ftp, rsh, rcp, rlogin, и некоторые другие реже используемые программы. Порт MIT также содержит полный пакет клиентских приложений Kerberos. Пользовательские файлы настройки: <filename>.k5login</filename> и <filename>.k5users</filename> .k5login .k5users Учётные записи пользователя в Kerberos (например tillman@EXAMPLE.ORG) обычно связаны с локальными учётными записями (например с локальной учётной записью6 tillman). Клиентские приложения, такие как telnet, обычно не требуют указания имени пользователя или учётной записи. Тем не менее, время от времени вам может потребоваться дать доступ к локальной учётной записи кому-то, у кого нет соответствующей учётной записи Kerberos. Например, пользователю tillman@EXAMPLE.ORG может потребоваться доступ к локальной учётной записи webdevelopers. Другим учётным записям также может потребоваться доступ к этой локальной учётной записи. Файлы .k5login и .k5users, помещенные в домашний каталог пользователя, могут быть использованы подобно действенной комбинации .hosts и .rhosts для решения этой проблемы. Например, файл .k5login со следующим содержанием: tillman@example.org jdoe@example.org помещен в домашний каталог локального пользователя webdevelopers, то обе упомянутые учётные записи получат доступ к этой учётной записи без необходимости наличия общего пароля. Рекомендуется прочитать страницу справочника по этим командам. Обратите внимание, что страница справочника о ksu содержит информацию по .k5users. Подсказки, советы и решение проблем с <application>Kerberos</application> Kerberos5 решение проблем При использовании портов как Heimdal так и MIT Kerberos убедитесь, что в PATH версии Kerberos клиентов указаны перед их версиями в базовой системе. Все ли компьютеры в пределах данного realm синхронизированы по времени? Если нет, аутентификация может завершиться неудачно. описывает как синхронизировать часы с использованием NTP. MIT и Heimdal успешно взаимодействуют. За исключением kadmin, протокол для которого не стандартизован. Если вы изменяете hostname, потребуется также изменить учётную запись host/ и обновить keytab. Это также необходимо для специальных записей в keytab, таких как www/ запись модуля Apache www/mod_auth_kerb. Все хосты под общим идентификатором должны разрешаться DNS (прямое и обратное разрешение), или как минимум через /etc/hosts. Записи CNAME будут работать, но записи A и PTR должны быть корректны и находиться на своем месте. Сообщение об ошибке не всегда интуитивно понятно: Kerberos5 refuses authentication because Read req failed: Key table entry not found. Некоторые операционные системы, способные работать в качестве клиентов KDC не устанавливают права для ksu в setuid root. Это означает, что ksu не работает, что хорошо является хорошей идеей для безопасности, но неудобно. Это не ошибка KDC. С MIT Kerberos, если вы хотите продлить действие доступа до значения большего, чем десять часов по умолчанию, используйте команду modify_principal в kadmin для изменения maxlife доступа к самой учётной записи и к учётной записи krbtgt. Затем возможно использование kinit с параметром -l для запроса доступа с большим временем действия. Если вы запускаете перехватчик пакетов на KDC для разрешения проблем, а затем запускаете kinit с рабочей станции, то увидите, что TGT посылается непосредственно при запуске kinit — даже до того, как вы введете пароль! Объяснение в том, что сервер Kerberos свободно распространяет TGT (Ticket Granting Ticket) на каждый неавторизованный запрос; однако, каждый TGT зашифрован ключом, полученным из пароля пользователя. Следовательно, когда пользователь вводит свой пароль, он не отправляется на KDC, а используется для расшифровка TGT, который уже получен kinit. Если в процессе расшифровки получается правильный билет с правильным значением времени, у пользователя есть действующее удостоверение. Это удостоверение содержит ключ сессии для установления безопасного соединения с сервером Kerberos, как и действующий TGT, зашифрованный ключом сервера Kerberos. Второй уровень шифрования недоступен пользователю, но позволяет серверу Kerberos проверять правильность каждого TGT. Если вы хотите установить большое время жизни доступа (например, неделю), и используете OpenSSH для соединения с компьютером, где хранится билет, убедитесь, что параметр Kerberos установлен в no в файле sshd_config, или билеты будут уничтожены при выходе из сеанса. Запомните, что время жизни билетов хостов больше. Если время жизни билета для учётной записи пользователя составляет неделю, а время жизни учётной записи хоста, к которому вы подсоединяетесь девять часов, учётная запись хоста в кэше устареет и кэш билетов будет работать не так, как ожидается. При настройке файла krb5.dict на предотвращение использования определенных плохих паролей (страница справочника для kadmind кратко рассказывает об этом), запомните, что это применимо только к учётным записям, для которых действует политика паролей. Формат файла krb5.dict прост: одно слово на строку. Может помочь создание символической ссылки на /usr/share/dict/words. Отличия от порта <acronym>MIT</acronym> Основное различие между установками MIT и Heimdal относится к программе kadmin, которая имеет другой (но эквивалентный) набор команд и использует другой протокол. Если ваш KDC работает на MIT, вы не сможете использовать kadmin для удаленного администрирования KDC (и наоборот, по этой же причине). Опции командной строки клиентов также могут немного отличаться для одинаковых задач. Рекомендуется следование инструкциям на MIT Kerberos Web-сайте (). Будьте внимательны при определении PATH: порт MIT устанавливается по умолчанию в /usr/local/, и если в PATH вначале указаны системные каталоги, вместо приложений MIT могут быть запущены системные приложения. С портом MIT security/krb5, предоставляемым &os;, убедитесь что файл /usr/local/share/doc/krb5/README.FreeBSD установлен портом, если вы хотите понять почему вход через telnetd и klogind иногда происходит так странно. Наиболее важно, исправление incorrect permissions on cache file требует использования бинарного файла login.krb5 для аутентификации, чтобы права на переданное удостоверение передавались правильно. Преодоление ограничений, обнаруженных в <application>Kerberos</application> Kerberos5 ограничения и недостатки <application>Kerberos</application> это все или ничего Каждый сервис, работающий в сети, должен быть модифицирован для работы с Kerberos (или другим способом защищен от атак по сети) или удостоверения пользователей могут быть украдены или использованы повторно. В качестве примера может быть приведено использование Kerberos версий оболочек для удаленной работы (например через rsh и telnet), при наличии POP3 сервера, получающего пароли в незашифрованном виде. <application>Kerberos</application> предназначен для однопользовательских рабочих станций В многопользовательской среде Kerberos менее безопасен. Это потому, что он хранит билеты в каталоге /tmp, которая доступна для чтения всем. Если пользователь работает с несколькими другими пользователями одновременно на одном компьютере (т.е. в многопользовательской среде), возможна кража (копирование) билета другим пользователем. Решить проблему можно с помощью параметра командной строки -c или (предпочтительно) с помощью переменной окружения KRB5CCNAME, но это делается редко. Для преодоления ограничения достаточно сохранять билет в домашнем каталоге пользователя и использовать простые ограничения на доступ к файлам. От KDC зависит вся система Архитектура системы такова, что KDC должен быть максимально защищен, поскольку главный пароль базы данных содержится в нем. На KDC не должно быть запущено никаких других сервисов и он должен быть защищен физически. Опасность велика, поскольку Kerberos хранит все пароли зашифрованными одним ключом (главным ключом), который хранится в файле на KDC. Хорошей новостью является то, что кража главного ключа не станет такой проблемой, как может показаться. Главный ключ используется только для шифрования базы данных Kerberos и в качестве seed для генератора случайных чисел. Поскольку доступ к KDC защищен, атакующий мало что сможет сделать с главным ключом. Кроме того, если KDC станет недоступен (возможно по причине атак DoS или проблем в сети) сетевые сервисы будет невозможно использовать, поскольку аутентификация не может быть выполнена. Уменьшить последствия можно при наличии нескольких KDC (один главный и один или несколько резервных) и с аккуратно реализованной резервной аутентификацией (отлично подойдет PAM). Недостатки <application>Kerberos</application> Kerberos позволяет пользователям, хостам и сервисам производить аутентификацию друг друга. В нем нет механизма аутентификации KDC для пользователей, хостов или сервисов. Это означает, что поддельный kinit (например) может записывать все имена пользователей и паролей. Помочь решить проблему может security/tripwire или другой инструмент проверки целостности файловой системы. Ресурсы и информация для дальнейшего изучения Kerberos5 внешние ресурсы Kerberos FAQ Разработка системы аутентификации: диалог в четырех сценах RFC 1510, Kerberos Network Authentication Service (V5) Домашняя страница MIT Kerberos Домашняя страница Heimdal Kerberos Tom Rhodes Написал: OpenSSL безопасность OpenSSL Одной из программ, требующих особого внимания пользователей, является набор программ OpenSSL, включенный в &os;. OpenSSL предоставляет уровень шифрования поверх обычных уровней соединения; следовательно, он может быть использован многими сетевыми приложениями и сервисами. OpenSSL может использоваться для шифрования соединений почтовых клиентов, транзакций через интернет, например для кредитных карт, и многого другого. Многие порты, такие как www/apache13-ssl и mail/sylpheed-claws собираются с OpenSSL. В большинстве случаев в Коллекции Портов будет сделана попытка построения порта security/openssl, если только переменная WITH_OPENSSL_BASE не установлена явно в yes. Версия OpenSSL, включаемая в &os;, поддерживает сетевые протоколы безопасности Secure Sockets Layer v2/v3 (SSLv2/SSLv3), Transport Layer Security v1 (TLSv1) и может быть использована в качестве основной криптографической библиотеки. Хотя OpenSSL поддерживает алгоритм IDEA, по умолчанию он отключен из-за патентных ограничений Соединенных Штатов. Для его использования необходимо ознакомиться с лицензией, и, если ограничения приемлемы, установить в make.conf переменную MAKE_IDEA. Наиболее часто OpenSSL используется для создания сертификатов, используемых программными пакетами. Эти сертификаты подтверждают, что данные компании или частного лица верны и не подделаны. Если рассматриваемый сертификат не был проверен одним из нескольких сертификационных центров (Certificate Authorities - CA), обычно выводится предупреждение. Центр сертификации представляет собой компанию, такую, как VeriSign, которая подписывает сертификаты для подтверждения данных частных лиц или компаний. Эта процедура не бесплатна и не является абсолютно необходимой для использования сертификатов; однако может успокоить некоторых особо осторожных пользователей. Генерирование сертификатов OpenSSL генерирование сертификатов Для генерирования сертификатов доступна следующая команда: &prompt.root; openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:SOME PASSWORD An optional company name []:Another Name Ввод после приглашения Common Name содержит имя домена. Здесь вводится имя сервера для верификации; помещение в это поле чего-либо кроме этого имени приведет к созданию бесполезного сертификата. Доступны и другие параметры, например срок действия, альтернативные алгоритмы шифрования и т.д. Полный список находится на странице справочного руководства &man.openssl.1;. В текущем каталоге, из которого была вызвана вышеуказанная команда, должны появиться два файла. Файл req.pem с запросом на сертификацию может быть послан в центр выдачи сертификатов, который проверит введённые вами подтверждающие данные, подпишет запрос и возвратит сертификат вам. Второй созданный файл будет иметь название cert.pem и содержать приватный сертификационный ключ, который необходимо тщательно защищать; если он попадёт в руки посторонних лиц, то может быть использован для имитации лично вас (или вашего сервера). Когда подпись CA не требуется, может быть создан самоподписанный сертификат. Сначала создайте ключ RSA: &prompt.root; openssl dsaparam -rand -genkey -out myRSA.key 1024 Теперь создайте ключ CA: &prompt.root; openssl gendsa -des3 -out myca.key myRSA.key Используйте этот ключ при создании сертификата: &prompt.root; openssl req -new -x509 -days 365 -key myca.key -out new.crt В каталоге должно появиться два новых файла: подпись сертификата, myca.key и сам сертификат, new.crt. Они должны быть помещены в каталог, доступный для чтения только root, желательно внутри /etc. Права на каталог можно изменить chmod с параметрами 0700. Использование сертификатов, пример Итак, что могут сделать эти файлы? Хорошим применением может стать шифрование соединений для Sendmail MTA. Это сделает ненужным использование простой текстовой аутентификации для тех, кто отправляет почту через локальный MTA. Это не лучшее из возможных использований, поскольку некоторые MUA выдадут ошибку, если сертификат не установлен локально. Обратитесь к поставляемой с программой документации за информацией по установке сертификата. Следующие строки должны быть помещены в локальный файл .mc: dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/new.crt')dnl define(`confSERVER_CERT',`/etc/certs/new.crt')dnl define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl Где /etc/certs/ это каталог для локального хранения сертификата и ключей. После настройки необходимо собрать локальный файл .cf. Это легко сделать, набрав make install в каталоге /etc/mail. Затем выполните команду make restart, которая должна запустить даемон Sendmail. Если все пройдет нормально, в файле /var/log/maillog не появятся сообщения об ошибках и запустится процесс Sendmail. Для проведения простого теста подключитесь к почтовому серверу программой &man.telnet.1;: &prompt.root; telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. Если в выводе появилась строка STARTTLS, все работает правильно. Nik Clayton
nik@FreeBSD.org
 Написал IPsec VPN через IPsec Создание VPN между двумя сетями, соединенными через интернет, с использованием шлюзов FreeBSD. Hiten M. Pandya
hmp@FreeBSD.org
 Написал Принципы работы IPsec Этот раздел послужит вам руководством по настройке IPsec и его использованию в среде FreeBSD и µsoft.windows; 2000/XP, соединяемых безопасным способом. Для настройки IPsec необходимо ознакомиться с процессом сборки ядра (). IPsec это протокол, расположенный поверх слоя Internet Protocol (IP). Он позволяет двум или более хостам связываться защищенным способом (отсюда и название протокола). Сетевой стек FreeBSD IPsec основан на реализации KAME, поддерживающей оба семейства протоколов, IPv4 и IPv6. FreeBSD 5.X содержит аппаратно поддерживаемый стек IPsec, известный как Fast IPsec, заимствованный из OpenBSD. Для оптимизации производительности IPsec он задействует криптографическое оборудование (когда оно доступно) через подсистему &man.crypto.4;. Это новая подсистема и она не поддерживает всех возможностей, доступных в KAME версии IPsec. Для включения IPsec с аппаратной поддержкой необходимо добавить в файл настройки ядра следующий параметр: параметры ядра FAST_IPSEC options FAST_IPSEC # new IPsec (cannot define w/ IPSEC) Обратите внимание, что на данный момент невозможно использовать подсистему Fast IPsec вместе с KAME реализацией IPsec. Обратитесь к странице справочника &man.fast.ipsec.4; за дальнейшей информацией. IPsec ESP IPsec AH IPsec состоит из двух подпротоколов: Encapsulated Security Payload (ESP), защищающей данные IP пакета от вмешательства третьей стороны путем шифрования содержимого с помощью симметричных криптографических алгоритмов (таких как Blowfish,3DES). Authentication Header (AH), защищающий заголовок IP пакета от вмешательства третьей стороны и подделки путем вычисления криптографической контрольной суммы и хеширования полей заголовка IP пакета защищенной функцией хеширования. К пакету добавляется дополнительный заголовок с хэшем, позволяющий аутентификацию информации пакета. ESP и AH могут быть использованы вместе или по отдельности, в зависимости от обстоятельств. VPN виртуальная частная сеть VPN IPsec может быть использован или для непосредственного шифрования трафика между двумя хостами (транспортный режим); или для построения виртуальных туннелей между двумя подсетями, которые могут быть использованы для защиты соединений между двумя корпоративными сетями (туннельный режим). Последний обычно называют виртуальной частной сетью (Virtual Private Network, VPN). За детальной информацией о подсистеме IPsec в FreeBSD обратитесь к странице справочника &man.ipsec.4;. Для включения поддержки IPsec в ядре, добавьте следующие параметры к файлу настройки ядра: параметры ядра IPSEC параметры ядра IPSEC_ESP options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) параметры ядра IPSEC_DEBUG Если желательна поддержка отладки IPsec, должна быть также добавлена следующая строка: options IPSEC_DEBUG #debug for IP security Проблема Не существует стандарта VPN. Они могут быть реализованы множеством различных технологий, каждая из которых имеет свои сильные и слабые стороны. Этот раздел представляет сценарий и стратегию реализации VPN для этого сценария. Сценарий: Две сети, подключенных к интернет, работающие как одна VPN создание Исходные условия таковы: Существует как минимум две сети Внутри обеих сетей используется IP Обе сети соединены через интернет через шлюз, работающий на FreeBSD. У шлюза каждой из сетей есть как минимум один публичный IP адрес. Внутренние IP адреса двух сетей могут быть публичными или приватными, не имеет значения. На шлюзе может работать NAT, если это необходимо. Внутренние IP адреса двух сетей не должны пересекаться. Хотя вероятно теоретически возможно использование комбинации VPN технологии и NAT для настройки такой конфигурации, эта конфигурация будет кошмарна. Если две сети, которые вы пытаетесь соединить, используют один и тот же диапазон приватных адресов (например, обе используют 192.168.1.x), номера в одной из сетей необходимо изменить. Топология сети может выглядеть примерно так: Сеть #1 [ Внутренние хосты ] Приватная сеть, 192.168.1.2-254 [ Win9x/NT/2K ] [ UNIX ] | | .---[fxp1]---. Приватный IP, 192.168.1.1 | FreeBSD | `---[fxp0]---' Публичный IP, A.B.C.D | | -=-=- Интернет -=-=- | | .---[fxp0]---. Публичный IP, W.X.Y.Z | FreeBSD | `---[fxp1]---' Приватный IP, 192.168.2.1 | | Сеть #2 [ Внутренние хосты ] [ Win9x/NT/2K ] Приватная сеть, 192.168.2.2-254 [ UNIX ] Заметьте, что здесь присутствуют два публичных IP-адреса. В дальнейшем для их обозначения будут использоваться буквы. Если вы увидите эти буквы, замените их на свои публичные IP адреса. Также обратите внимание, что у обеих шлюзов внутренний адрес заканчивается на .1 и диапазоны приватных адресов двух сетей различны (192.168.1.x и 192.168.2.x соответственно). Все компьютеры локальных сетей настроены на использование в качестве шлюза по умолчанию компьютера с адресом, оканчивающимся на .1. С сетевой точки зрения замысел в том, чтобы каждая сеть видела компьютеры из другой сети так, как если бы они были непосредственно подключены к тому же самому маршрутизатору — хотя и немного медленному маршрутизатору, иногда теряющему пакеты. Это означает, что (например) компьютер 192.168.1.20 может запустить ping 192.168.2.34 и это будет прозрачно работать. Компьютеры с &windows; должны видеть компьютеры в другой сети, просматривать сетевые ресурсы, и так далее, точно так же, как и для компьютеров в локальной сети. И все это безопасным способом. Это означает, что трафик между сетями зашифрован. Создание VPN между этими двумя сетями это многошаговый процесс. Этапы создания VPN таковы: Создание виртуального сетевого подключения между двумя сетями через интернет. Тестирование подключения с помощью таких инструментов как &man.ping.8;, чтобы убедиться, что оно работает. Применение политики безопасности чтобы убедиться, что трафик между двумя сетями прозрачно шифруется и расшифровывается если необходимо. Тестирование с помощью таких инструментов как &man.tcpdump.1;, чтобы убедиться, что трафик шифруется. Настройка дополнительных программ на шлюзах &os;, чтобы компьютеры &windows; из одной сети видели компьютеры в другой через VPN. Шаг 1: Создание и тестирование <quote>виртуального</quote> сетевого подключения Предположим, что вы работаете на шлюзе сети #1 (с публичным адресом A.B.C.D, приватным адресом 192.168.1.1) и запускаете ping 192.168.2.1, т.е. на приватный адрес машины с IP адресом W.X.Y.Z. Что должно произойти, чтобы это сработало? Шлюз должен знать, как достичь 192.168.2.1. Другими словами, у него должен быть маршрут к 192.168.2.1. Приватные IP адреса, такие как диапазон 192.168.x не адресуются в интернет. Каждый пакет, отправляемый на 192.168.2.1 должен быть завернут в другой пакет. Исходным адресом пакета должен быть A.B.C.D, а адресом назначения W.X.Y.Z. Этот процесс называется инкапсуляцией. Как только этот пакет достигнет W.X.Y.Z, необходимо будет декапсулировать его и доставить к 192.168.2.1. Как вы можете увидеть, это требует туннеля между двумя сетями. Два конца туннеля это IP адреса A.B.C.D и W.X.Y.Z. Туннель используется для передачи трафика с приватными IP адресами через интернет. В FreeBSD этот туннель создается с помощью устройства generic interface, или gif. Как вы можете догадаться, интерфейс gif на каждом хосте должен быть настроен с четырьмя IP адресами; два для публичных IP адресов и два для приватных IP адресов. В ядро обеих компьютеров FreeBSD должна быть встроена поддержка устройства gif. Вы можете сделать это, добавив строку: device gif к файлу настройки ядра на обеих компьютерах, с последующей компиляцией, установкой и перезагрузкой. Настройка туннеля это двухшаговый процесс. Во-первых, необходимо задать сведения о внешнем (или публичном) IP адресе с помощью &man.gifconfig.8;. Затем о приватном IP адресе с помощью &man.ifconfig.8;. В &os; 5.X функциональность, предоставляемая утилитой &man.gifconfig.8;, была внесена в &man.ifconfig.8;. На шлюзе сети #1 для настройки туннеля вам потребуется запустить следующие две команды. gifconfig gif0 A.B.C.D W.X.Y.Z ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff На другом шлюзе подобные команды, но с IP адресами в обратном порядке. gifconfig gif0 W.X.Y.Z A.B.C.D ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff Затем вы можете запустить: gifconfig gif0 для просмотра настройки. Например, на шлюзе сети #1 вы увидите: &prompt.root; gifconfig gif0 gif0: flags=8011<UP,POINTTOPOINT,MULTICAST> mtu 1280 inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff physical address inet A.B.C.D --> W.X.Y.Z Как вы можете видеть, был создан туннель между физическими адресами A.B.C.D и W.X.Y.Z, для туннелирования разрешен трафик между 192.168.1.1 и 192.168.2.1. Это также добавляет запись к таблице маршрутизации на обеих машинах, вы можете проверить запись командой netstat -rn. Вот вывод этой команды на шлюзе сети #1. &prompt.root; netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire ... 192.168.2.1 192.168.1.1 UH 0 0 gif0 ... Как показывает значение поля Flags, это маршрут к хосту, что означает, что каждый шлюз знает, как достичь другого шлюза, но не знает как достичь остальной части соответствующей сети. Эта проблема будет быстро решена. Вероятно, на обеих машинах запущен брандмауэр. VPN должен обходить его. Вы можете разрешить весь трафик между двумя сетями, или включить правила, защищающие каждый конец соединения от другого. Это сильно упрощает тестирование настройки брандмауэра, если вы разрешаете весь трафик через VPN. Вы всегда можете Вы всегда можете усилить защиту позже. Если вы используете на шлюзах &man.ipfw.8;, команда вроде этой ipfw add 1 allow ip from any to any via gif0 разрешит весь трафик между двумя концами VPN без влияния на другие правила брандмауэра. Очевидно, вам потребуется запустить эту команду на обеих шлюзах. Этого достаточно для включения ping с одного шлюза на другой. На 192.168.1.1, вы сможете запустить ping 192.168.2.1 и получить ответ, и аналогично на другом шлюзе. Однако, машины в другой сети пока недоступны. Это из-за маршрутизации — хотя шлюзы знают, как связаться друг с другом, они не знают, как связаться с сетью за другим шлюзом. Для решения этой проблемы вы должны добавить статический маршрут на каждом шлюзе. Команда на первом шлюзе будет выглядеть так: route add 192.168.2.0 192.168.2.1 netmask 0xffffff00 Она говорит Для достижения хостов в сети 192.168.2.0, отправляйте пакеты хосту 192.168.2.1. Вам потребуется запустить похожую команду на другом шлюзе, но с адресами 192.168.1.x. IP трафик с хостов в одной сети теперь может достичь хосты в другой сети. Теперь создано две трети VPN между двумя сетями, поскольку это виртуальная (virtual) сеть (network). Она еще не приватная (private). Вы можете протестировать ее с помощью &man.ping.8; и &man.tcpdump.1;. Войдите на шлюз и запустите tcpdump dst host 192.168.2.1 В другой сессии на этом же хосте запустите ping 192.168.2.1 Вы увидите примерно такие строки: 16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply Как вы видите, ICMP сообщения пересылаются вперед и назад незашифрованными. Если вы использовали с &man.tcpdump.1; параметр для получения большего объема данных пакета, то увидите больше информации. Конечно же это неприемлемо. В следующем разделе мы обсудим защиту соединения между двумя сетями, так что весь трафик будет автоматически шифроваться. Резюме: Настройте оба ядра с device gif. Отредактируйте /etc/rc.conf на шлюзе #1 и добавьте следующие строки (подставляя IP адреса где необходимо). gifconfig_gif0="A.B.C.D W.X.Y.Z" ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff" static_routes="vpn" route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00" Отредактируйте скрипт брандмауэра (/etc/rc.firewall, или подобный) на обеих хостах и добавьте ipfw add 1 allow ip from any to any via gif0 Выполните соответствующие изменения в /etc/rc.conf на шлюзе #2, меняя порядок IP адресов. Шаг 2: Защита соединения Для защиты соединения мы будем использовать IPsec. IPsec предоставляет хостам механизм определения ключа для шифрования и для последующего использования этого ключа для шифрования данных между двумя хостами. Здесь будут рассмотрены два аспекта настройки. У хостов должен быть способ согласования используемого алгоритма шифрования. Как только хосты договорятся об этом, можно говорить об установленном между ними безопасном соединении. Должен быть механизм определения, какой трафик необходимо шифровать. Конечно, вам не требуется шифровать весь исходящий трафик — достаточно шифровать только трафик, идущий через VPN. Правила, определяющие то, какой трафик необходимо шифровать, называются политикой безопасности. Безопасное соединение и политика безопасности поддерживаются ядром, и могут быть изменены программами пользователя. Однако перед тем, как вы сможете сделать это, необходимо настроить поддержку протоколов IPsec и Encapsulated Security Payload (ESP) в ядре. Это делается добавлением в настройку ядра параметров: параметры ядра IPSEC options IPSEC options IPSEC_ESP с последующим перекомпилированием, переустановкой и перезагрузкой. Как и прежде вам потребуется сделать это с ядрами на обеих шлюзах. IKE При настройке параметров безопасности (security associations) у вас есть два варианта. Вы можете настроить их вручную для обеих хостов, задав алгоритм шифрования, ключи для шифрования и так далее, или использовать даемоны, реализующие Internet Key Exchange protocol (IKE), который сделает это за вас. Рекомендуется последнее. Помимо прочего, этот способ более прост. IPsec политики безопасности setkey Редактирование и отображение политики безопасности выполняется с помощью &man.setkey.8;. По аналогии, setkey используется для настройки таблиц политики безопасности ядра так же, как &man.route.8; используется для настройки таблиц маршрутизации ядра. setkey также может отображать текущие параметры безопасности, и продолжая аналогию дальше, это соответствует netstat -r. Существует множество даемонов для управления параметрами безопасности в FreeBSD. Здесь будет описано использование одного из них, racoon — он доступен в составе порта security/ipsec-tools в Коллекции Портов &os;. racoon Даемон racoon должен работать на обеих шлюзах. На каждом из хостов он настраивается с IP адресом другого конца VPN, и секретным ключом (по вашему выбору, должен быть одним и тем же на обеих шлюзах). Эти два даемона подключаются друг к другу, подтверждают, что они именно те, за кого себя выдают (используя секретный ключ, заданный вами). Затем даемоны генерируют новый секретный ключ и используют его для шифрования трафика через VPN. Они периодически изменяют этот ключ, так что даже если атакующий сломает один из ключей (что теоретически почти невозможно) это не даст ему слишком много — он сломал ключ, который два даемона уже сменили на другой. Настройки racoon сохраняются в файле ${PREFIX}/etc/racoon. Этот файл не требует слишком больших изменений. Другим компонентом настройки racoon, который потребуется изменить, является предварительный ключ. В настройке по умолчанию racoon ищет его в файле ${PREFIX}/etc/racoon/psk.txt. Необходимо отметить, что предварительный ключ не используется для шифрования трафика через VPN соединение это просто маркер, позволяющий управляющим ключами даемонам доверять друг другу. psk.txt содержит строку для каждого удаленного сервера, с которым происходит соединение. В этом примере два сервера, каждый файл psk.txt будет содержать одну строку (каждый конец VPN общается только с другим концом. На шлюзе #1 эта строка будет выглядеть примерно так: W.X.Y.Z secret То есть публичный IP-адрес противоположной стороны, пробел и текстовая строка c секретной фразой. Конечно, вам не стоит использовать в качестве ключевой фразы слово secret -- здесь применяются обычные правила выбора паролей. На шлюзе #2 строка будет выглядеть примерно так: A.B.C.D secret То есть публичный IP адрес удаленной стороны и та же секретная фраза. Перед запуском racoon режим доступа к файлу psk.txt должен быть установлен в 0600 (т.е. запись и чтение только для root). Вы должны запустить racoon на обоих шлюзах. Вам также потребуется добавить правила для включения IKE трафика, передающегося по UDP через порт ISAKMP (Internet Security Association Key Management Protocol). Опять же, они должны быть расположены насколько возможно ближе к началу набора правил. ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp Как только racoon будет запущен, вы можете попробовать выполнить ping с одного шлюза на другой. Соединение все еще не зашифровано, но racoon установит параметры безопасности между двумя хостами — это может занять время и вы можете заметить небольшую задержку перед началом ответа команды ping. Как только параметры безопасности установлены, вы можете просмотреть их используя &man.setkey.8;. Запустите setkey -D на любом из хостов для просмотра информации о параметрах безопасности. Это одна сторона проблемы. Другая сторона это настройка политики безопасности. Для создания разумной политики безопасности давайте вспомним, что уже было настроено. Это рассмотрение относится к обеим концам соединения. Каждый отправляемый IP пакет имеет заголовок, содержащий информацию о пакете. Заголовок включает IP адреса источника и назначения. Как мы уже знаем, приватные IP адреса, такие как 192.168.x.y, не могут появиться в интернет. Они должны быть сначала включены внутрь другого пакета. В этом пакете приватные IP адреса источника и назначения заменяются публичными IP адресами. То есть исходящий пакет, который выглядит примерно так: .----------------------------. | Src: 192.168.1.1 | | Dst: 192.168.2.1 | | <другие данные заголовка> | +----------------------------+ | <данные пакета> | `----------------------------' будет инкапсулирован в другой пакет, выглядящий примерно так: .--------------------------------. | Src: A.B.C.D | | Dst: W.X.Y.Z | | <другие данные заголовка> | +--------------------------------+ | .----------------------------. | | | Src: 192.168.1.1 | | | | Dst: 192.168.2.1 | | | | <другие данные заголовка> | | | +----------------------------+ | | | <данные пакета> | | | `----------------------------' | `--------------------------------' Этой инкапсуляцией занимается устройство gif. Как вы можете видеть, теперь у пакета есть реальный IP адрес, исходный пакет был включен в этот пакет в виде данных, которые передаются через интернет. Конечно, мы хотим зашифровать весь трафик между VPN. Вы можете сформулировать это на словах так: Если пакет отправляется с A.B.C.D, и предназначен для W.X.Y.Z, расшифровать его, используя необходимые параметры безопасности. Если пакет отправляется с W.X.Y.Z, и предназначен для A.B.C.D, расшифровать его, используя необходимые параметры безопасности. Это похоже на желаемое, но не совсем то. Если вы сделаете это, весь трафик от и к W.X.Y.Z, даже если он не является частью VPN, будет зашифрован. Правильная политика такова: Если пакет отправляется с A.B.C.D, в нем инкапсулирован другой пакет и адрес назначения W.X.Y.Z, зашифровать его, используя необходимые параметры безопасности. Если пакет отправляется с W.X.Y.Z, в нем инкапсулирован другой пакет и адрес назначения A.B.C.D, зашифровать его, используя необходимые параметры безопасности. Тонкое, но необходимое различие. Политика безопасности также устанавливается с использованием &man.setkey.8;. В &man.setkey.8; предусмотрен язык определения политики &man.setkey.8;. Вы можете или ввести инструкции по настройке со стандартного ввода, или использовать параметр для задания файла, содержащего эти инструкции. Настройка на шлюзе #1 (где есть публичный IP адрес A.B.C.D) для включения шифрования всего предназначенного W.X.Y.Z трафика: spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Поместите эти команды в файл (например, /etc/ipsec.conf) и запустите &prompt.root; setkey -f /etc/ipsec.conf указывает &man.setkey.8; добавить правило к базе данных политики безопасности. Остальная часть строки указывает какие пакеты будут соответствовать политике. A.B.C.D/32 и W.X.Y.Z/32 это IP адреса и сетевые маски, определяющие сети или хосты, к которым будет применяться данная политика. В данном случае мы хотим применить их к трафику между этими двумя хостами. Параметр сообщает ядру, что эта политика должна применяться только к пакетам, инкапсулирующим другие пакеты. Параметр сообщает, что эта политика применяется к исходящим пакетам, и — то, что пакеты будут зашифрованы. Оставшаяся часть строки определяет, как эти пакеты будут зашифрованы. Будет использоваться протокол , а параметр показывает, что пакет в дальнейшем будет инкапсулирован в IPsec пакет. Повторное использование A.B.C.D и W.X.Y.Z предназначено для выбора используемых параметров безопасности, и наконец параметр разрешает шифрование пакетов, попадающих под это правило. Это правило соответствует только исходящим пакетам. Вам потребуется похожее правило, соответствующее входящим пакетам. spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; Обратите внимание, что вместо используется и IP адреса переставлены. Другому шлюзу (с публичным IP адресом W.X.Y.Z) потребуются похожие правила. spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Наконец, вам потребуется добавить правила к брандмауэру для включения прохождения пакетов ESP и IPENCAP в обе стороны. На обеих хостах потребуется добавить следующие правила: ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D Поскольку правила симметричны, можно использовать их без изменения на обеих хостах Исходящие пакеты теперь будут выглядеть примерно так: .------------------------------. --------------------------. | Src: A.B.C.D | | | Dst: W.X.Y.Z | | | <other header info> | | Encrypted +------------------------------+ | packet. | .--------------------------. | -------------. | contents | | Src: A.B.C.D | | | | are | | Dst: W.X.Y.Z | | | | completely | | <other header info> | | | |- secure | +--------------------------+ | | Encap'd | from third | | .----------------------. | | -. | packet | party | | | Src: 192.168.1.1 | | | | Original |- with real | snooping | | | Dst: 192.168.2.1 | | | | packet, | IP addr | | | | <other header info> | | | |- private | | | | +----------------------+ | | | IP addr | | | | | <packet data> | | | | | | | | `----------------------' | | -' | | | `--------------------------' | -------------' | `------------------------------' --------------------------' Когда эти пакеты будут получены на удаленном конце VPN соединения, они будут расшифрованы (используя параметры безопасности, о которых договорился racoon). Затем они будут переданы интерфейсу gif, который развернет второй слой, оставив пакет с внутренними адресами, который сможет попасть во внутреннюю сеть. Вы можете проверить безопасность тем же &man.ping.8;, который использовался ранее. Сначала войдите на шлюз A.B.C.D и запустите: tcpdump dst host 192.168.2.1 В другой сессии на том же хосте запустите ping 192.168.2.1 В этот момент вы должны увидеть примерно это: XXX tcpdump output Теперь, как видите, &man.tcpdump.1; показывает ESP пакеты. Если вы попытаетесь просмотреть их с параметром , то вероятно увидите нечто непонятное, поскольку применяется шифрование. Поздравляем. Вы только что настроили VPN между двумя удаленными сетями. Резюме Настройте оба ядра с: options IPSEC options IPSEC_ESP Установите security/ipsec-tools. Отредактируйте ${PREFIX}/etc/racoon/psk.txt на обеих шлюзах, добавив запись для каждого IP адреса удаленного хоста и секретный ключ, который будет известен им обеим. Убедитесь, что режим доступа к файлу 0600. Добавьте к /etc/rc.conf на каждом хосте следующие строки: ipsec_enable="YES" ipsec_file="/etc/ipsec.conf" Создайте /etc/ipsec.conf на каждом хосте с необходимыми строками spdadd. На шлюзе #1 он будет таким: spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; А на шлюзе #2 таким: spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Добавьте правила к брандмауэрам обеих хостов для включения IKE, ESP и IPENCAP трафика: ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D Двух приведенных шагов должно быть достаточно для настройки и включения VPN. Машины в каждой сети смогут обращаться друг к другу по IP адресам, и весь трафик через соединение будет автоматически надежно зашифрован. Chern Lee Предоставил OpenSSH OpenSSH безопасность OpenSSH OpenSSH это набор сетевых инструментов, используемых для защищенного доступа к удаленным компьютерам. Он может быть использован в качестве непосредственной замены rlogin, rsh, rcp и telnet. Кроме того, через SSH могут быть безопасно туннелированы и/или перенаправлены произвольные TCP/IP соединения. OpenSSH шифрует весь трафик, эффективно предотвращая кражу данных, перехват соединения и другие сетевые атаки. OpenSSH поддерживается проектом OpenBSD, он основан на SSH v1.2.12 со всеми последними исправлениями и обновлениями, совместим с протоколами SSH версий 1 и 2. OpenSSH включен в базовую систему начиная с FreeBSD 4.0. Преимущества использования OpenSSH Обычно при использовании &man.telnet.1; или &man.rlogin.1; данные пересылаются по сети в незашифрованной форме. Перехватчик пакетов в любой точке сети между клиентом и сервером может похитить информацию о пользователе/пароле или данные, передаваемые через соединение. Для предотвращения этого OpenSSH предлагает различные методы шифрования. Включение sshd OpenSSH включение В &os; версии 4.X даемон sshd запускается по умолчанию; начиная с версий 5.X &os; он должен быть разрешен в процессе инсталляции. За запуск ответственна следующая строка в файле rc.conf: sshd_enable="YES" При следующей загрузке системы будет запущен &man.sshd.8;, даемон для - OpenSSH. Вы можете также запустить - sshd непосредственно, набрав в - командной строке sshd. + OpenSSH. Вы можете также воспользоваться + скриптом /etc/rc.d/sshd системы &man.rc.8; + для запуска OpenSSH: + + /etc/rc.d/sshd start + SSH клиент OpenSSH клиент Утилита &man.ssh.1; работает подобно &man.rlogin.1;. &prompt.root; ssh user@example.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'example.com' added to the list of known hosts. user@example.com's password: ******* Вход продолжится так же, как если бы сессия была инициирована с использованием rlogin или telnet. SSH использует систему опознавательных ключей для проверки подлинности сервера при подключении клиента. Пользователю предлагается yes только при первом подключении. Дальнейшие попытки входа предваряются проверкой сохраненного ключа сервера. SSH клиент сообщит вам, если сохраненный ключ будет отличаться от только что полученного. Ключи серверов сохраняются в ~/.ssh/known_hosts, или в ~/.ssh/known_hosts2 для SSH v2. По умолчанию современные серверы OpenSSH настроены на приём только соединений SSH v2. Клиент будет использовать версию 2 там, где это возможно, а затем версию 1. Также, клиент можно заставить использовать конкретную версию при помощи опций и для указания соответствующей версии протокола. Версия 1 поддерживается ради совместимости со старыми серверами. Безопасное копирование OpenSSH безопасное копирование scp Команда &man.scp.1; работает подобно &man.rcp.1;; она копирует файл с удаленного компьютера, но делает это безопасным способом. &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; Поскольку в предыдущем примере ключ сервера уже был сохранен, в этом примере он проверяется при использовании &man.scp.1;. Параметры, передаваемые &man.scp.1;, похожи на параметры &man.cp.1;, с файлом или файлами в качестве первого аргумента и приемником копирования во втором. Поскольку файлы файлы передаются по сети через SSH, один или более аргументов принимают форму . Настройка OpenSSH настройка Системные файлы настройки для даемона и клиента OpenSSH расположены в каталоге /etc/ssh. Файл ssh_config используется для настройки клиента, а sshd_config для даемона. Кроме того, параметры (по умолчанию /usr/sbin/sshd), и rc.conf дают дополнительные возможности настройки. ssh-keygen Вместо использования паролей, с помощью &man.ssh-keygen.1; можно создать ключи DSA или RSA, которыми пользователи могут аутентифицироваться: &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com &man.ssh-keygen.1; создаст пару публичного и приватного ключей, используемых для аутентификации. Приватный ключ сохраняется в ~/.ssh/id_dsa или ~/.ssh/id_rsa, а публичный в ~/.ssh/id_dsa.pub или ~/.ssh/id_rsa.pub (для ключей DSA и RSA соответственно). Для включения аутентификации по ключам публичный ключ должен быть помещен в файл ~/.ssh/authorized_keys на удаленном компьютере. Это позволяет соединяться с удаленным компьютером с помощью SSH-ключей вместо паролей. Если при генерации ключей был использован пароль, каждый раз для при использовании приватного ключа он будет запрашиваться у пользователя. Для того, чтобы избежать непрерывного набора кодовой фразы, можно использовать утилиту &man.ssh-agent.1;, как описано в разделе ниже. Параметры и имена файлов могут различаться для разных версий OpenSSH, установленных в системе, для решения проблем обратитесь к странице справочника &man.ssh-keygen.1;. Утилиты ssh-agent и ssh-add Утилиты &man.ssh-agent.1; и &man.ssh-add.1; позволяют сохранять ключи SSH в памяти, чтобы не набирать кодовые фразы при каждом использовании ключа. Утилита &man.ssh-agent.1; обеспечивает процесс аутентификации загруженными в нее секретными ключами; для этого утилита &man.ssh-agent.1; должна запустить внешний процесс. В самом простом случае это может быть шелл-процесс; в чуть более продвинутом — оконный менеджер. Для использования &man.ssh-agent.1; совместно с шеллом, &man.ssh-agent.1; должен быть запущен с именем этого шелла в качестве аргумента. После этого в его память при помощи утилиты &man.ssh-add.1; могут быть добавлены необходимые ключи; при этом будут запрошены соответствующие кодовые фразы. Добавленные ключи могут затем использоваться для &man.ssh.1; на машины, на которых установлены соответствующие публичные ключи: &prompt.user; ssh-agent csh &prompt.user; ssh-add Enter passphrase for /home/user/.ssh/id_dsa: Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) &prompt.user; Для того чтобы использовать &man.ssh-agent.1; в X11, вызов &man.ssh-agent.1;должен быть помещен в файл ~/.xinitrc. Это обеспечит поддержкой &man.ssh-agent.1; все программы, запущенные в X11. Файл ~/.xinitrc может выглядеть, например, так: exec ssh-agent startxfce4 При этом будет запущен &man.ssh-agent.1;, который, в свою очередь, вызовет запуск XFCE, при каждом старте X11. После запуска X11, выполните команду &man.ssh-add.1; для добавления ваших SSH-ключей. Туннелирование SSH OpenSSH туннелирование OpenSSH поддерживает возможность создания туннеля для пропуска соединения по другому протоколу через защищенную сессию. Следующая команда указывает &man.ssh.1; создать туннель для telnet: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; Команда ssh используется со следующими параметрами: Указывает ssh использовать версию 2 протокола (не используйте этот параметр, если работаете со старыми SSH серверами). Означает использование в не-командном режиме, только для туннелирования. Если этот параметр опущен, ssh запустит обычную сессию. Указывает ssh запускаться в фоновом режиме. Означает локальный туннель в стиле localport:remotehost:remoteport. Удаленный сервер SSH. Туннель SSH создается путем создания прослушивающего сокета на определенном порту localhost. Затем все принятые на локальном хосту/порту соединения переправляются на через SSH на определенный удаленный хост и порт. В этом примере, порт 5023 на localhost перенаправляется на порт 23 на localhost удаленного компьютера. Поскольку 23 это порт telnet, будет создано защищенное соединение telnet через туннель SSH. Этот метод можно использовать для любого числа небезопасных протоколов, таких как SMTP, POP3, FTP, и так далее. Использование SSH для создания защищенного туннеля на SMTP &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP Этот метод можно использовать вместе с &man.ssh-keygen.1; и дополнительными пользовательскими учётными записями для создания более удобного автоматического SSH туннелирования. Ключи могут быть использованы вместо паролей, и туннели могут запускаться от отдельных пользователей. Практические примеры SSH туннелирования Защищенный доступ к серверу POP3 На работе находится SSH сервер, принимающий соединения снаружи. В этой же офисной сети находится почтовый сервер, поддерживающий протокол POP3. Сеть или сетевое соединение между вашим домом и офисом могут быть или не быть полностью доверяемыми. По этой причине вам потребуется проверять почту через защищенное соединение. Решение состоит в создании SSH соединения к офисному серверу SSH и туннелирование через него к почтовому серверу. &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** Когда туннель включен и работает, вы можете настроить почтовый клиент для отправки запросов POP3 на localhost, порт 2110. Соединение будет безопасно переправлено через туннель на mail.example.com. Прохождение через Драконовский Брандмауэр Некоторые сетевые администраторы устанавливают на брандмауэрах драконовские правила, фильтруя не только входящие соединения, но и исходящие. Вам может быть разрешен доступ к удаленным компьютерам только по портам 22 и 80, для SSH и просмотра сайтов. Вам может потребоваться доступ к другому (возможно, не относящемуся к работе) сервису, такому как Ogg Vorbis для прослушивания музыки. Если этот сервер Ogg Vorbis выдает поток не с портов 22 или 80, вы не сможете получить к нему доступ. Решение состоит в создании SSH соединения с компьютером вне брандмауэра и использование его для туннелирования сервера Ogg Vorbis. &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* Клиентскую программу теперь можно настроить на localhost порт 8888, который будет перенаправлен на music.example.com порт 8000, успешно обойдя брандмауэр. Параметр ограничения пользователей <varname>AllowUsers</varname> Зачастую хорошие результаты даёт ограничение того, какие именно пользователи и откуда могут регистрироваться в системе. Задание параметра AllowUsers является хорошим способом добиться этого. К примеру, для разрешения регистрации только пользователю root с машины 192.168.1.32, в файле /etc/ssh/sshd_config нужно указать нечто вроде следующего: AllowUsers root@192.168.1.32 Для разрешения регистрации пользователя admin из любой точки, просто укажите имя пользователя: AllowUsers admin Несколько пользователей должны перечислять в одной строке, как здесь: AllowUsers root@192.168.1.32 admin Важно, чтобы бы перечислили всех пользователей, которые должны регистрироваться на этой машине; в противном случае они будут заблокированы. После внесения изменений в /etc/ssh/sshd_config вы должны указать &man.sshd.8; на повторную загрузку конфигурационных файлов, выполнив следующую команду: &prompt.root; /etc/rc.d/sshd reload Дополнительная литература OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; &man.sshd.8; &man.sftp-server.8; &man.sshd.config.5; Tom Rhodes Предоставил ACL Списки контроля доступа файловой системы (ACL) В дополнение к другим расширениям файловой системы, таким как снимки (snapshots), FreeBSD 5.0 и более поздние версии системы предлагают защиту с помощью списков контроля доступа файловой системы (File System Access Control Lists, ACLs). Списки контроля доступа расширяют стандартную модель прав &unix; высоко совместимым (&posix;.1e) способом. Эта возможность позволяет администратору получить преимущество от использования более интеллектуальной модели безопасности. Для включения поддержки ACL в файловой системе UFS, следующая строка: options UFS_ACL должна быть добавлена в файл настройки ядра. Если параметр не добавлен, при попытке монтирования систем, поддерживающих ACL, появится предупреждающее сообщение. Этот параметр включен в ядро GENERIC. ACL основывается на дополнительных атрибутах, встроенных в файловую систему. Дополнительные атрибуты поддерживаются по умолчанию следующим поколением файловых систем &unix;, UFS2. Для включения дополнительных атрибутов в UFS1 требуется больше усилий по сравнению с UFS2. Производительность дополнительных атрибутов в UFS2 также существенно выше. По этим причинам для работы с списками контроля доступа предпочтительно использование UFS2 ACL включаются во время монтирования флагом , который добавляется к /etc/fstab. Этот флаг также можно сделать постоянным с помощью &man.tunefs.8;, изменив флаг ACL в заголовке файловой системы. Вообще говоря, использование флага в суперблоке предпочтительно по нескольким причинам: Постоянный ACL флаг не может быть изменен путем перемонтирования системы (&man.mount.8; ), а только через &man.umount.8; и &man.mount.8;. Это означает, что ACL нельзя включить на корневой файловой системе после загрузки. Это также означает, что вы не можете изменить флаг на используемой файловой системе. Установка флага в суперблоке приводит к постоянному монтированию файловой системы с включенным ACL, даже если нет записи в fstab или при смене порядка устройств. Это предотвращает случайное монтирование файловой системы без ACL, которое может повлечь за собой проблемы с безопасностью. Мы можем изменить поведение ACL для включения флага без полного перемонтирования, но считаем, что желательно исключить случайное монтирование без ACL, поскольку вы можете попасть в неприятную ситуацию, если включите ACL, затем выключите их, затем опять включите без сброса расширенных атрибутов. Обычно, как только вы включили ACL в файловой системе, они не должны быть выключены, поскольку получающаяся защита файлов может быть не совместима с той, что применяется пользователями системы, и повторное включение ACL может подключить предыдущие списки контроля доступа к файлам, права на которые изменены, что приведет к непредсказуемому поведению. Файловые системы с включенными ACLs показывают знак + при просмотре прав на файлы. Например: drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html Здесь мы видим, что каталоги directory1, directory2, и directory3 используют преимущества ACL. Каталог public_html их не использует. Использование <acronym>ACL</acronym> ACL файловой системы можно просмотреть с помощью утилиты &man.getfacl.1;. Например, для просмотра настроек ACL файла test, может использоваться команда: &prompt.user; getfacl test #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r-- Для изменения ACL этого файла, вызовите утилиту &man.setfacl.1;. Выполните: &prompt.user; setfacl -k test Параметр удалит все установленные на данный момент ACL из файла или файловой системы. Более предпочтительный метод это использование параметра , который оставит необходимые для работы ACL поля. &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test В вышеприведенной команде параметр использован для изменения записей ACL по умолчанию. Поскольку предустановленных записей не было (они были удалены предыдущей командой), эта команда восстановит параметры по умолчанию и задаст приведенные параметры. Имейте ввиду, при добавлении пользователя или группы, которых нет в системе, на stdout будет выведена ошибка Invalid argument. Том Родес Текст предоставил Portaudit Мониторинг вопросов безопасности в ПО сторонних разработчиков В последние годы в области информационной безопасности произошло много улучшений, касающихся выработки оценки уязвимости. Угроза проникновения в систему увеличивается вместе с установкой и настройкой утилит сторонних разработчиков, какой бы современной операционной системы это ни касалось. Оценка уязвимости является ключевым фактором обеспечения защиты, и хотя для базового комплекта &os; выпускаются бюллетени безопасности, но делать это для каждой сторонней утилиты выше возможностей участников Проекта &os;. Существует способ смягчения уязвимостей программного обеспечения сторонних разработчиков и предупреждения администраторов об известных проблемах с безопасностью. Во &os; существует утилита под названием Portaudit, которая служит исключительно этой цели. Порт security/portaudit обращается к базе данных, обновляемой и поддерживаемой Группой информационной безопасности &os; и разработчиками портов, для получения информации об известных проблемах с защитой. Для того, чтобы приступить к использованию Portaudit, необходимо установить его из Коллекции Портов: &prompt.root; cd /usr/ports/security/portaudit && make install clean В процессе установки будут обновлены конфигурационные файлы для &man.periodic.8;, в которые будет добавлена выдача Portaudit при ежедневном её запуске. Проверьте, что ежедневные сообщения электронной почты, касающиеся безопасности, которые посылаются на адрес root, прочитываются. Другой дополнительной настройки больше не понадобится. После установки администратор может обновить базу данных и посмотреть список известных уязвимостей в установленных пакетах при помощи команды &prompt.root; portaudit -Fda База данных будет автоматически обновлена при запуске &man.periodic.8;; таким образом, предыдущая команду можно полностью опустить. Она требуется только для следующих примеров. Для аудита утилит сторонних разработчиков, установленных как часть Коллекции Портов, администратору достаточно запускать только следующую команду: &prompt.root; portaudit -a Утилита portaudit выдаст примерно следующее: Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> 1 problem(s) in your installed packages found. You are advised to update or deinstall the affected package(s) immediately. Перейдя в Web-браузере по показанному URL, администратор может получить более подробную информацию о показанной уязвимости. В неё войдёт перечисление версий, затронутых соответствующей версией порта &os;, а также другие Web-сайты, которые могут содержать бюллетени безопасности. Если описывать вкратце, то Portaudit является мощной и, при использовании вместе с портом Portupgrade, чрезвычайно полезной утилитой. Tom Rhodes Предоставил Сообщения безопасности FreeBSD Сообщения безопасности &os; Как многие и высококачественные операционные системы, &os; публикует Сообщения безопасности (Security Advisories). Эти сообщения обычно отправляются по почте в списки рассылки, посвященные безопасности и публикуются в списке проблем только после выхода исправлений к соответствующим релизам. В этом разделе разъясняется, что такое сообщения безопасности, как их читать и какие меры принимать для исправления системы. Как выглядит сообщение? Сообщение безопасности &os; выглядит подобно сообщению ниже, взятому из списка рассылки &a.security-notifications.name;. ============================================================================= &os;-SA-XX:XX.UTIL Security Advisory The &os; Project Topic: denial of service due to some problem Category: core Module: sys Announced: 2003-09-23 Credits: Person@EMAIL-ADDRESS Affects: All releases of &os; &os; 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) &os; only: NO For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.FreeBSD.org/security/. I. Background II. Problem Description III. Impact IV. Workaround V. Solution VI. Correction details VII. References Поле Topic показывает в чем именно заключается проблема. Это обычно введение в сообщение безопасности, упоминающее утилиту, в которой возникла ошибка. Поле Category относится к затронутой части системы и может быть выбрана из core, contrib, или ports. Категория core означает, что уязвимость затрагивает основной компонент операционной системы &os;. Категория contrib означает, что уязвимость затрагивает программы, предоставленные проекту &os;, например sendmail. Наконец, категория ports означает, что уязвимость затрагивает программное обеспечение, доступное из Коллекции Портов. Поле Module указывает на местоположение компонента, например sys. В этом примере мы видим, что затронут модуль sys, следовательно, эта уязвимость относится к компоненту, используемому в ядре. Поле Announced отражает дату публикации сообщения безопасности, или его анонсирования. Это означает, что команда обеспечения безопасности убедилась, что проблема существует и что патч помещён в хранилище исходных текстов &os;. Поле Credits упоминает частное лицо или организацию, обнаружившую уязвимость и сообщившую о ней. Поле Affects дает информацию о релизах &os;, к которым относится данная уязвимость. Для базовой системы, просмотр вывода команды ident для файлов, затронутых уязвимостью, поможет определить ревизию. Номер версии портов приведен после имени порта в каталоге /var/db/pkg. Если система не синхронизируется с CVS-хранилищем &os; и не пересобирается ежедневно, высок шанс, что она затронута уязвимостью. Поле Corrected показывает дату, время, смещение во времени и релиз, в котором исправлена ошибка. Поле &os; only показывает, существует ли эта уязвимость только в &os;, или затрагивает и другие системы. Поле Background дает информацию именно о той утилите, для которой выпущено сообщение. Как правило информация о том, зачем утилита присутствует в &os;, для чего она используется, и немного информации о том, как появилась эта утилита. Поле Problem Description дает более глубокие разъяснения возникшей проблемы. Оно может включать информацию об ошибочном коде, или даже о том, как утилита может быть использована для создания бреши в системе безопасности. Поле Impact описывает тип воздействия, который проблема может оказать на систему. Это может быть все, что угодно, от атаки на отказ в обслуживании до получения пользователями дополнительных привилегий, или даже получения атакующим прав суперпользователя. Поле Workaround предлагает тем, системным администраторам, которые не могут обновить систему, обходной путь решения проблемы. Он может пригодиться при недостатке времени, отсутствии подключения к сети или по массе других причин. В любом случае, к безопасности нельзя относиться несерьезно, и необходимо либо применить указанный обходной путь, либо исправить систему. Поле Solution предлагает инструкции по исправлению затронутой системы. Это пошаговое руководство, протестированный метод восстановления безопасности системы. Поле Correction Details показывает ветвь CVS (имя релиза с точками, замененными на символы подчеркивания). Здесь также показан номер ревизии каждого файла из каждой ветви. Поле References обычно упоминает другие источники информации. Это могут быть Web-страницы, книги, списки рассылки и группы новостей. Том Родес Текст предоставил Учёт используемых ресурсов Учёт используемых ресурсов Учёт используемых процессами ресурсов представляет собой метод защиты, при котором администратор может отслеживать использование системных ресурсов и их распределение между пользователями для нужд системного мониторинга и минимального отслеживания команд пользователей. На самом деле здесь есть свои положительный и отрицательные моменты. Положительной стороной является то, что проникновение может быть отслежено до первоначальной точки входа. Отрицательной стороной является объём протоколов, который генерируется при мониторинге, и соответствующие требования к дисковому пространству. В этом разделе администратору даются основы учёта ресурсов процессов. Активация и использование учёта ресурсов Прежде чем использовать систему учёта ресурсов, её необходимо активировать. Для этого выполните следующие команды: &prompt.root; touch /var/account/acct &prompt.root; accton /var/account/acct &prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf После активации система учёта ресурсов начнёт отслеживать статистику CPU, команд и так далее. Все протоколы учёта ведутся в формате, недоступном для чтения человеком, и могут просматриваться при помощи утилиты &man.sa.8;. Запущенная без параметров, sa выдаст информацию, относящуюся к количеству вызовов в расчёте на каждого пользователя, общее затраченное время в минутах, общее время CPU и пользователя в минутах, среднее количество операций ввода/вывода и так далее. Для просмотра информации о запущенных командах, необходимо воспользоваться утилитой &man.lastcomm.1;. Команду lastcomm можно использовать, например, для выдачи списка директив, выданных пользователями определённого терминала &man.ttys.5;: &prompt.root; lastcomm ls trhodes ttyp1 Эта команда выдаст все зафиксированные использования команды ls пользователем trhodes на терминале ttyp1. Существует многие другие полезные параметры, которые описаны на соответствующих справочных страницах &man.lastcomm.1;, &man.acct.5; и &man.sa.8;.