Основы межсетевого обмена

Основы межсетевого обмена в сетях TCP/IP

Структура стека протоколов TCP/IP

При рассмотрении процедур межсетевого взаимодействия всегда опираются на стандарты, разработанные International Standard Organization (ISO). Эти стандарты получили название "Семиуровневой модели сетевого обмена" или в английском варианте "Open System Interconnection Reference Model" (OSI Ref.Model). В данной модели обмен информацией может быть представлен в виде стека, представленного на рисунке 2.1. Как видно из рисунка, в этой модели определяется все - от стандарта физического соединения сетей до протоколов обмена прикладного программного обеспечения.

Рис. 2.1 Семиуровневая модель протоколов межсетевого обмена OSI

Физический уровень данной модели определяет характеристики физической сети передачи данных, которая используется для межсетевого обмена. Это такие параметры, как: напряжение в сети, сила тока, число контактов на разъемах и т.п. Типичными стандартами этого уровня являются, например RS232C, V35, IEEE 802.3 и т.п.

К канальному уровню отнесены протоколы, определяющие соединение, например, SLIP (Strial Line Internet Protocol), PPP (Point to Point Protocol), NDIS, пакетный протокол, ODI и т.п. Речь идет о протоколе взаимодействия между драйверами устройств и устройствами, с одной стороны, а с другой стороны, между операционной системой и драйверами устройства. Такое определение основывается на том, что драйвер - это, фактически, конвертор данных из оного формата в другой, но при этом он может иметь и свой внутренний формат данных.

К сетевому (межсетевому) уровню относятся протоколы, которые отвечают за отправку и получение данных, или, другими словами, за соединение отправителя и получателя. К этому уровню в TCP/IP относят протокол IP (Internet Protocol). Именно здесь определяется отправитель и получатель, именно здесь находится необходимая информация для доставки пакета по сети.

Транспортный уровень отвечает за надежность доставки данных, и здесь, проверяя контрольные суммы, принимается решение о сборке сообщения в одно целое. В Internet транспортный уровень представлен двумя протоколами TCP (Transport Control Protocol) и UDP (User Datagramm Protocol). Если предыдущий уровень (сетевой) определяет только правила доставки информации, то транспортный уровень отвечает за целостность доставляемых данных.

Рекомендуемые материалы

Уровень сессии определяет стандарты взаимодействия между собой прикладного программного обеспечения. Это может быть некоторый промежуточный стандарт данных или правила обработки информации. Условно к этому уровню можно отнеси механизм портов протоколов TCP и UDP и Berkeley Sockets.

Уровень обмена данными с прикладными программами (Presentation Layer) необходим для преобразования данных из промежуточного формата сессии в формат данных приложения. В Internet это преобразование возложено на прикладные программы.

Уровень прикладных программ или приложений определяет протоколы обмена данными этих прикладных программ. В Internet к этому уровню могут быть отнесены такие протоколы, как: FTP, TELNET, HTTP, GOPHER и т.п.

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

Рис. 2.2. Структура стека протоколов TCP/IP

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

Драйвер - программа, непосредственно взаимодействующая с сетевым адаптером.

Сетевой интерфейс - физическое устройство, подключающее компьютер к сети. В нашем случае - карта Ethernet.

Кадр - это блок данных, который принимает/отправляет сетевой интерфейс.

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

UDP-датаграмма - блок данных, которым обменивается модуль IP с модулем UDP.

TCP-сегмент - блок данных, которым обменивается модуль IP с модулем TCP.

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

Информационные сервисы Internet

Система Доменных Имен

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

Если речь идет о системе типа Unix, то этот файл (hosts) расположен в директории /etc и имеет следующий вид:

Рис. 1 Пример таблицы имен хостов (файл /etc/hosts)

Файл hosts — текстовый файл, содержащий базу данных доменных имен и используемый при их трансляции в сетевые адреса узлов. Запрос к этому файлу имеет приоритет перед обращением к DNS-серверам. В отличие от DNS, содержимое файла контролируется администратором компьютера. С помощью файла hosts возможно осуществлять фильтрацию рекламы, путём перенаправления доменных адресов баннеров на адрес 127.0.0.1.

Пользователь для обращения к машине может использовать как IP-адрес машины, так и ее имя или синоним (alias). синонимов может быть много, и, кроме того для разных IP-адресов может быть указано одно и то же имя.

В локальных сетях файлы hosts используются достаточно успешно до сих пор. Практически все операционные системы от различных клонов Unix до Windows NT поддерживают эту систему соответствия IP-адресов доменным именам.

Однако такой способ присвоения символьных имен был хорош до тех пор, пока Internet был маленьким. По мере роста сети стало затруднительным держать большие списки имен на каждом компьютере. Для того, что бы решить эту проблему, были придуманы DNS (Domain Name System).

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

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

Принципы организации DNS

Любая DNS является прикладным процессом, который работает над стеком TCP/IP. Таким образом, базовым элементом адресации является IP-адрес, а доменная адресация выполняет роль сервиса.

DNS сервис - это информационный сервис Internet, и, следовательно, протоколы его реализующие относятся к протоколам прикладного уровня согласно стандартной модели OSI. Однако с точки зрения операционной системы поддержка DNS может входить в нее как компонента ядра, которая прикладным пользовательским процессом не является. Пользовательские программы общаются с ней при помощи системных вызовов. Такое положение вещей справедливо практически для всех Unix-систем. Другое дело системы на базе MS-DOS и Windows 3.x. В этих системах DNS (точнее ее клиентская часть) реализована как прикладная программа.

Система доменных адресов строится по иерархическому принципу. Однако иерархия эта не строгая. Фактически, нет единого корня всех доменов Internet. Если быть более точным, то такой корень в модели DNS есть. Он так и называется "ROOT". Однако, единого администрирования этого корня нет. Администрирование начинается с доменов верхнего, или первого, уровня. В 80-е годы были определены первые домены этого уровня: gov, mil, edu, com, net. Позднее, когда сеть перешагнула национальные границы США появились национальные домены типа: uk, jp, au, ch, и т.п. Для СССР также был выделен домен su. После 1991 года, когда республики союза стали суверенными, многие из них получили свои собственные домены: ua, ru, la, li, и т.п. Однако Internet не СССР, и просто так выбросить домен su из сервера имен нельзя, на основе доменных имен строятся адреса электронной почты и доступ ко многим другим информационным ресурсам Internet. Поэтому гораздо проще оказалось ввести новый домен к существующему, чем заменить его. Таким образом в Москве существуют организации с доменными именами, оканчивающимися на su (например, kiae.su) и оканчивающимися на ru (msk.ru).

Наиболее популярной программой поддержки DNS является named, которая реализует Berkeley Internet Name Domain (BIND). Но эта программа не единственная. Так в системе Windows NT 4.0 есть свой сервер доменных имен, который поддерживает спецификацию BIND. Определена в документе RFC 1033-1035.

BIND (Berkeley Internet Name Domain)

BIND был создан студентами в начале 1980-х на грант, выданный DARPA и впервые был выпущен в BSD 4.3. Версия 9 была переписана заново компанией Nominum (англ.), релиз был выпущен в сентябре 2000 года. Версия 10 содержит большое количество кода на Python. Ранние версии BIND хранили информацию только в текстовых файлах зон (англ.). Начиная с версии 9.4, в качестве хранилища можно использовать LDAP, Berkeley DB, PostgreSQL,MySQL и ODBC. В версиях до 9 было выявлено немало серьёзных проблем с безопасностью.

BIND или Berkeley Internet Name Domain - это сервер доменных имен реализованный в университете Беркли, который широко применяется на Intenet'е. Он обеспечивает поиск доменных имен и IP-адресов для любого узла Сети. BIND обеспечивает рассылку сообщений электронной почты через узлы Internet. Если говорить более точно BIND обеспечивает поиск доменного адреса машины пользователя, которому адресована почта, и определение IP-адреса доменному адресу. Эта информация используется программой рассылки почтовых сообщений sendmail, которая выступает в качестве почтового сервера. BIND реализован по схеме "клиент/сервер". Собственно BIND - это сервер, а функции клиента выполняет name resolver или просто resolver.

Регистрация доменных имен

Для того, чтобы получить зону надо отправить заявку в РосНИИРОС, который отвечает за делегирование поддоменов в пределах домена ru. В заявке указывается адрес компьютера-сервера доменных имен, почтовый адрес администратора сервера, адрес организации и ряд другой информации.

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

domain: vega.ru

descr: International Agency VEGA

descr: Kurchatov sq. 1

descr: 115470 Moscow

descr: Russian Federation

admin-c: Pavel B Khramtsov

zone-c: Pavel B Khramtsov

tech-c: Pavel B Khramtsov

nserver: vega-gw.vega.ru

nserver: ns.relarn.ru

nserver: polyn.net.kiae.su

dom-net: 194.226.43.0

changed: paul@kiae.su 961018

source: RIPN

person: Pavel B Khramtsov

address: International Agency Vega

address: Kurchatov sq. 1

address: 115470 Moscow

address: Russian Federation

phone: +7 095 1969124

fax-no: +7 095 9393670

e-mail: paul@kiae.su

changed: paul@kiae.su 961018

source: RIPN

В строке описания поля "domain:" указывается имя домена, которое вы просите зарегистрировать. РосНИИРОС регистрирует только поддомены домена ru.

В строке описания поля "descr:" указывают название и адрес организации, которая запрашивает домен. Так как на одной строке эта информация не может разместиться, то команд descr может быть несколько.

В строке описания поля "admin-c:" указывается персона, которая осуществляет администрирование домена. Поле имеет обязательный формат: <имя> <первая буква отчества> <фамилия>. Таких строк может быть несколько, если лиц отвечающих за администрирование домена больше одного. Вместо указанного выше формата можно использовать также и идентификатор персоны, если таковой имеется. Идентификатор называют nichandle, или персональный код.  zone-c и tech-c . Обычно для наших доменов admin-c, zone-c и tech-c один и тот же человек. Поле "tech-c:" указывается для технического администратора домена, к которому обращаются в случае экстренных ситуаций. Формат этого поля совпадает с форматом команды admin-c. и «zone-c» . Мало кто может позволить роскошь держать сразу трех разных специалистов на обслуживании сервиса доменных имен. Учитывая отечественные реалии, можно со всей ответственностью утверждать, что кроме неразберихи ни к чему другому большое количество администраторов не приводит.

В строке описания поля "nserver:" указывают доменные имена серверов зоны. Как правило, таких строк в заявке бывает несколько. Первым указывается primary или главный сервер домена. На этом сервере хранится база данных домена. Вторым указывается secondary или дублирующий сервер домена. Дублирующие сервера призваны повысить надежность работы всей системы доменных имен, поэтому дублирующих серверов может быть несколько. Если существуют другие дублирующие сервера, то указываются и они. При указании дублирующих серверов первым следует указывать тот, который наиболее надежно обслуживает запросы к домену. Если хотя бы один из них не откликается на запросы автомата, то заявка отклоняется.

Поле "sub-dom:" описывает поддомены домена.

Поле "dom-net:" указывает на список IP-сетей данного домена. Если у организации, которая заводит свой собственный домен имеется в наличии несколько сетей, то эти сети можно указать в этом поле, разделяя их пробелами.

Поле "changed:" является обязательным и служит указателем на то лицо, которое последним вносило изменения в заявку. В качестве значения поля после символа ":" указывается почтовый адрес этого лица и, через пробел дата внесения изменения в формате ГГММДД (Г-год, М-месяц, Д-день).

Последняя запись в заявке - это поле source, которое отделяет различные записи во входном потоке данных программы робота. Значение этого поля - RIPN.

Вслед за записью заявки следует запись описания персоны. Именно эта запись позволяет связывать поля admin-c, zone-c, tech-c с информацией о конкретном лице, которая содержится в записи описания персоны.

Запись описания персоны начинается с поля "person:". В данном поле указывается информация о лице (персоне). Обычно, данное поле имеет следующий формат:

 <имя> <первая буква отчества> <фамилия>.

Поле "address:" вслед за полем "person:". Данное поле состоит из нескольких строк, каждая из которых начинается с имени поля. Первым указывается организация, во второй строке - улица и номер дома, в третьей - почтовый индекс и название города или поселка, в последней строке - название страны. Одним словом - это типичный американский почтовый адрес.

За адресом следует поле "phone:". В нем указывается номер телефона, по которому можно связаться с указанным лицом. Номер задается с указанием номера страны и кода города. Для Москвы - +7 095 ___ __ __. Телефонов можно указать несколько.

Все выше сказанное для поля "phone:" относится и к полю "fax-no:". В этом поле указывается номер телефакса.

"e-mail:", хотя оно и не является обязательным полем заявки.

В поле "nic-hdl:" указывается персональный номер пользователя, если он у данного пользователя есть. Поле не является обязательным, но, как подчеркивается в инструкции по заполнению заявок "крайне желательно".

Последним полем в описании персоны, является поле "source:". В заявке можно указать несколько персон, что породит для каждой из них свою собственную запись в базе данных описания доменов. Информация о зоне и лицах, которые ответственны за ведение зоны (и не только о них) можно найти используя сервис whois ,например, на

whois.ripn.net <имя зоны или персоны>

% By submitting a query to RIPN's Whois Service

% you agree to abide by the following terms of use:

% http://www.ripn.net/about/servpol.html#3.2 (in Russian)

% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:        URFU.RU

nserver:       ns1.urfu.ru. 212.193.66.21

nserver:       ns2.urfu.ru. 212.193.82.21

nserver:       ns3.urfu.ru. 212.193.72.21

state:         REGISTERED, DELEGATED, VERIFIED

org:           federalnoe gosudarstvennoe avtonomnoe obrazovatelnoe uchrezhdenie visshego professionalnogo obrazovaniya "UrFU imeni pervogo Prezidenta Rossii B.N.Elcina"

registrar:     REGRU-REG-RIPN

admin-contact: http://www.reg.ru/whois/admin_contact

created:       2008.12.16

paid-till:     2013.12.16

free-date:     2014.01.16

source:        TCI

nic-hdl:       REGRU-REG-RIPN

org:           Domain Registrar REG.RU

phone:         +7 495 5801111

fax-no:        +7 495 4915553

e-mail:        info@reg.ru

www:           http://www.reg.ru/whois/admin_contact

whois:         whois.reg.ru

source:        TCI

Last updated on 2013.03.04 20:36:36 MSK

Теперь после описания самой заявки перейдем к описанию ее регистрации. После того как заявка отправлена, следует настроить и запустить сервер в локальном режиме. Администратор РосНИИРОС обычно извещает о том, что у администрации домена ru нет претензий к вашей заявке и разрешает запустить ваш сервер для тестирования. Если в домене есть уже запрашиваемый вами поддомен или у администрации домена ru есть другие возражения по поводу регистрации вашего домена, то администрация домена ru вас об этом известит.

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

Так, например, регистрация домена vega.ru длилась почти два месяца из-за того, что в начале были ошибки в заявке, потом были выявлены несоответствия заявки и описания зоны, затем сломался автомат регистрации и заявка была утеряна. Затем возникли проблемы с дублирующим сервером зоны (слишком большое время отклика, из-за которого автомат отклонял заявку).

При размещении сервера домена следует позаботиться о том, чтобы существовал вторичный (secondary) сервер имен вашего домена. Согласно большинству рекомендаций, следует иметь от 2-х до 4-х серверов на случай отказа основного сервера доменных имен.

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

Если система не может разрешить доменное имя, то она сообщает - "unknown host", т.е. система такого компьютера не знает. Если же доменное имя успешно транслируется в IP-адрес, то, в случае потери связи, система сообщает - "host un-reachable", т.е. система знает о такой машине, но в данный момент достичь эту машину нет никакой возможности.

В РосНИИРОС регистрируют не только "прямую" зону, но также и "обратную". Это две самостоятельные заявки. Понятие "прямая" зона - с английского - forward zone, а понятие "обратная" зона - reverse zone. "Прямая" зона определяет соответствие доменного имени IP-адресу, в то время, как "обратная" зона определяет обратное соответствие IP-адреса доменному имени.

Серверы доменных имен

Речь пойдет о программе, которая называется named. Именно она используется в большинстве Unix-систем в качестве реализации Berkeley Internet Name Domain - BIND.

Как и любой другой сервис прикладного уровня, а система доменных имен - это сервис прикладного уровня, программа named использует транспорт TCP и UDP (порты 53). Сервис BIND строится по схеме "клиент-сервер". В качестве клиентской части выступает процедура разрешения имен - resolver, а в качестве сервера, в нашем случае, программа named.

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

На запросы описанных выше функций в системах Unix отвечает программа named. Идея этой программы проста - обеспечить как разрешение, так называемых, "прямых" запросов, когда по имени ищут адрес, так и "обратных", когда по адресу ищут имя. Управляется named специальной базой данных, которая состоит из нескольких фалов, и содержит соответствия между адресами и именами, а также адреса других серверов BIND, к которым данный сервер может обращаться в процессе поиска имени или адреса.

DNS и безопасность

В сентябре 1996 года многие компьютерные издания Москвы опубликовали материал, в котором рассматривался случай подмены доменных адресов World Wide Web сервера агенства InfoART, что привело к тому, что подписчики этого сервиса в течении некоторого времени вместо страниц этого агенста просматривали картинки "для взрослых".

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

Администрирование DNS осуществляла компания Demos, поэтому пресс-конферению по поводу этого случая Demos и InfoArt проводили совместно. Разъяснения провайдера главным образом свелись к тому, что в базе данных DNS самого Demos никаких изменений не проводилось, а за состояние баз данных secondary серверов Demos ответственности не несет. Почему такое заявление вполне оправдывает провайдера?

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

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

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

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

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