NetBIOS через TCP/IP

NetBIOS (Network Basic Input/Output System, Сетевая Базовая Система Ввода/Вывода) - это интерфейс для работы в локальных сетях, разработанный фирмой Sytek для компании IBM в 1983 году. Как гласит RFC1001: NetBIOS defines a software interface not a protocol. There is no "official" NetBIOS service standard. И всё же NetBIOS, по моему скромному мнению, и интерфейс и протокол, поэтому, с вашего позволения, назовем его стандартом (не смотря на то, что официально он так и не был полностью стандартизован). Довольно часто NetBIOS называют сетевым протоколом, но это не совсем корректно, поскольку NetBIOS реализован в Windows сразу в нескольких компонентах операционной системы :: в виде интерфейса в библиотеках пользовательского режима и режима ядра, и в виде модуля в стеке сетевого протокола. Интерфейс NetBIOS представляет из себя стандартный набор для разработки приложений (API), протокол NetBIOS функционирует на транспортном/сеансовом уровне стека и используется для передачи данных, управления сеансом и прочих нужд.

Особенностью NetBIOS является возможность работы "поверх" основных сетевых протоколов, таких как IPX, NetBEUI и TCP/IP. В своё время реализация протокола NetBIOS в Windows была существенно переработана и ориентирована на использование протокола TCP/IP (как наиболее перспективного), получив новое название “NetBIOS over TCP/IP” (NetBIOS через TCP/IP). NetBIOS через TCP/IP имеет псевдоним NetBT (NBT). NetBIOS через TCP/IP представляет собой промежуточный уровень между NetBIOS и TCP/IP и создан для того, чтобы приложения на базе NetBIOS могли работать в сетях TCP/IP, то есть предназначен для отображения имен NetBIOS в IP-адреса и, наоборот. Как мы уже упоминали, NetBIOS разрабатывался на заре становления сетевых технологий, и с того времени часто модифицировался, однако параллельно с ним создавались и другие стандарты сетевого взаимодействия, которые существенно опережали NetBIOS по функционалу. На данный момент NetBIOS считается устаревшим стандартом и не рекомендуется к использованию, заместо него, в части организации передачи данных по сети, Microsoft предлагает использовать сокеты (windows sockets), почтовые каналы (mailslots), именованные каналы (named pipes). Для оставшегося функционала, то есть для сервисных целей разработан новый протокол LLMNR (через PNRP):

Однако, не смотря на устаревание NetBIOS, поддержка его сохранена и по сей день, код NetBIOS через TCP/IP всё еще присутствует в составе последних версий Windows. Причиной столь огромной популярности стандарта является тот факт, что до определенного времени NetBIOS оставался основным интерфейсом программирования сетевых приложений, и с использованием функций NetBIOS было написано огромное количество разнообразного программного обеспечения.
NetBT является неотъемлемой частью сетевого стека TCP/IP ОС Windows и инсталлируется вместе с протоколом TCP/IP. Части функционала NetBT встречаются в коде библиотек, переменных окружения (%COMPUTERNAME%, %USERDOMAIN%), коде некоторых современных антивирусных продуктов, почтовых серверов, баз данных. NetBIOS до сих пор используется в алгоритме добавления рабочей станции в домен, в процедурах работы с сетевым окружением, подключения сетевых дисков. Об исключительном значении протокола NetBIOS через TCP/IP говорит уже и тот факт, что штатными средствами самой ОС протокол NetBIOS может быть только отключен, но никак не удален. Удаление же его возможно только вместе с удалением протокола TCP/IP.

Службы NetBIOS

Далее не будет лишним посмотреть, какие же сетевые порты используются сервисами NetBIOS:

Подобная структура отражает требование RFC 1001, RFC 1002, регламентирующее наличие трех базовых сервисов, которые реализуют эмуляцию NetBIOS в системе Windows.

Реализация NetBIOS

NetBIOS через TCPIP реализован в качестве драйвера уровня ядра netbt.sys, поддерживающего специализированный интерфейс TDI (общий интерфейс для взаимодействия с драйверами, который позволяет сервисам взаимодействовать с транспортными протоколами). Все сервисы, которые работают с NetBT (рабочая станция, сервер, браузер, сетевой вход в систему) используют TDI напрямую. Пользовательские приложения используют стандартный WinAPI (функции, вызовы), поддерживаемый библиотекой netapi32.dll, которая, в свою очередь, является простой "заглушкой" и перенаправляет вызовы к функциям netbios.dll. Функции библиотеки netbios.dll передают запросы к драйверу уровня ядра под названием NetBIOS-эмулятор (%SystemRoot%\System32\Drivers\netbios.sys), который транслирует команды NetBIOS, переданные приложением, в команды TDI-интерфейса.

Принципы работы NetBIOS

Собственно, как же работает NetBIOS? Я попытаюсь дать, пока что, собственное объяснение принципов работы стандарта. Все мы понимаем, что для того, чтобы станции могли взаимодействовать по сети, они должны подчиняться определенным правилам, выполнять предписанные действия на различных этапах работы. Этими этапами являются: заявление о себе (регистрация), попытка взаимодействия (обнаружение имен, установление сеанса, управление сеансом), отключение себя (освобождение имени). Поэтому, все узлы, использующие NetBIOS через TCP/IP, применяют регистрацию, обнаружение и освобождение имен, а так же многие другие методы, предоставляемые стандартом. Давайте рассмотрим их детальнее:

• Регистрация имен. Начиная работу, узел NetBIOS пытается заявить о себе в сети, другими словами - сказать "Я есть узел такой то, с таким то именем". Регистрация имени NetBIOS происходит при помощи широковещательного или направленного только к серверу имен NetBIOS (WINS-сервер) запроса. Если какой-либо узел пробует зарегистрировать уже существующее в сети имя NetBIOS, то либо узел с данным именем, либо сервер имен NetBIOS (WINS-сервер) посылает отказ в регистрации имени, и узел, инициировавший регистрацию, получает в качестве ответа сообщение об ошибке.
• Обнаружение имен. Когда узел уже зарегистрировался, работает в сети, но вдруг хочет связаться с другим узлом, он должен узнать IP-адрес этого узла. Для этого, узел-инициатор посылает запрос на определение имени, содержащий искомое NetBIOS имя. Для запроса используется широковещательный пакет или адресный запрос серверу имен NetBIOS (WINS). Узел, которому принадлежит искомое имя, или WINS-сервер отправляют обратно положительный/отрицательный ответ об определении имени. В результате инициатор получает информацию об IP-адресе целевого узла.
• Освобождение имен. Освобождение имени происходит, если станция, приложение или служба NetBIOS прекращает работу. К примеру, если станция отключается некорректно, то она перестает отвечать на запросы, и другие станции через некоторое время прекращают попытки связаться с ней. Если в сети используется сервер имен NetBIOS, то перед корректным выключением станция посылает ему запрос на удаление информации о всех ресурсах, которые она поддерживала. В таком случае говорят, что имя NetBIOS освобождено, и доступно для использования другими узлами.
• Запуск/завершение сеанса. Вероятно, мы пытались обнаружить сетевое имя не просто так, а с какой-то целью. А что если мы хотим обменяться данными: получить/передать файлы? Для этого нам необходимо установить сеанс связи с целевой станцией.
• Надежная передача данных сеанса. После установления надежного сеанса связи с использованием транспортного протокола TCP, мы начинаем обмен данными. Например, передачу файлов.
• Ненадежная передача данных сеанса. После запроса на разрешение имени, мы начинаем передачу информации с помощью транспортного протокола UDP. Например, поиск имени.
• Возможность мониторинга и диагностики. Позволяет запрашивать статус удаленных и локальных ресурсов.

Для того, чтобы лучше понять логику работы NetBIOS через TCP/IP, давайте немного отступим от основной линии рассуждений, и рассмотрим по-отдельности некоторые сущности стандарта.

Имя NetBIOS

Одной из основных целей разработки NetBIOS являлось создание простого интерфейса, который давал бы возможность пользователям назначать станциям символьные имена вида MyComputer. Очевидно, что без подобных имен нам сложно обойтись, поскольку именно легкие имена позволяют человеку "узнать" (однозначно идентифицировать) ресурс, к которому он хочет обратиться по сети. Программам то всё-равно, вместо имен они могут использовать любые идентификаторы, однако человеку удобнее работать именно с фонетическими, понятными и легко запоминающимися маркерами - именами. В качестве имени NetBIOS используется простое одноранговое (“плоское”) имя, без какой-либо иерархической структуры (в противоположность DNS). Подобная простота и отсутствие иерархии имени имеют и оборотную сторону - имена должны быть уникальными.

Первые 15 - собственно имя, 16й - тип ресурса или суффикс (значение в диапазоне 00-FF, шестнадцатеричное представление). NetBIOS имя и имя компьютера (hostname) совпадают по первым 15 символам. Хранится это имя в параметре реестра с именем hostname, который располагается в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
С развитием сетевых технологий логическая структура сетей усложнялась, и помимо станций появились такие понятия как "рабочая группа" и "домен". Пришло осознание того, что ресурсы бывают разнотипными, а имя может быть присвоено не только станции. Опираясь на новые данные, было введено понятие "тип ресурса", который предназначался для логического разделения ресурсов по назначению, это позволило присваивать одно и то же имя нескольким ресурсам одновременно.

Ресурсы динамически регистрируются сначала в операционной системе (в которой ресурс и создается), а затем [при помощи оповещений] распространяются по сети, которой принадлежит станция. Регистрация ресурса происходит в тот момент, когда в операционной системе стартует сервис (читать: приложение), использующий NetBIOS, либо авторизуется пользователь.
Типы ресурсов стандартизованы по классам и имеют следующие значения:

• Уникальное (Unique, U) - к этому имени может быть привязан только один адрес IP;
• Групповое (Group, G) - к этому имени не привязан единственный адрес, имя может содержать множественные IP-адреса; На запрос WINS-клиента об адресе всегда возвращается limited broadcast address 255.255.255.255;
• Группа Интернет (Internet Group, Special Group, I) - к этому имени может быть привязано до 25 адресов; для каждого адреса хранится свой TTL. Используется для управления именами домена в WinNT;
• Доменное имя (Domain Name, D) - к этому имени может быть привязано множество адресов;

Поскольку NetBIOS не использует номера портов, как это делает TCP/IP, адресное пространство имен должно быть способно поддерживать множество имен для каждой системы. К примеру, если на одной станции реализованы файловый сервер, служба Exchange и сервер удаленного доступа, то каждый из этих сервисов должен иметь отличное от других имя, однозначно определяющее сам сервис. Для этой цели авторы NetBIOS придумали понятие суффикса, который фактически является аналогом порта в TCP/IP. Как было указано выше, он занимает последний, 16й байт в имени и однозначно идентифицирует сервис.

Полный перечень типов общих ресурсов NetBIOS

У имен NetBIOS имеется следующий нюанс - все имена длиной менее 15 символов дополняются пробелами (код символа 20 в шестнадцатеричном представлении), а в некоторых случаях символами BE либо BF. Поскольку к работе над NetBIOS подключались многие разработчики, то и типов общих ресурсов существует великое множество, однако в таблице я привожу только те типы, которые используются Microsoft.

Тип ресурса можно посмотреть командой nbtstat -a <имя_компьютера>:

Основное назначение этой команды - показать информацию из локальной таблицы NetBIOS имен для всех интерфейсов, установленных на станции. Имеет алиас - nbtstat -n.

Методы разрешения имени NetBIOS

Очевидно, что тут мы будем говорить о том, какими средствами NetBIOS удается найти соответствие имени и IP-адреса ресурса? Какие же методы определения имен доступны интерфейсу NetBIOS? Сразу обращу ваше внимание на то, что не все из перечисленных методов относятся непосредственно к стандарту NetBIOS. Я считаю, что к NetBIOS относятся только лишь: LMHOSTS, WINS, кеш имен NetBIOS, широковещательный запрос в подсети. Такие же понятия как HOSTS и DNS относятся уже к TCP/IP Direct Hosting. Но поскольку понятия "NetBIOS имя станции" и "имя хоста" довольно тесно взаимосвязаны в современных ОС Windows, то resolver (модуль, разрешающий имена) использует все доступные методы для нахождения соответствия, умело комбинируя разнородные методы определения имен.

• NetBIOS name cache (локальный кеш NetBIOS) - специальная структура в памяти процесса для записи результатов разрешения имен. Время жизни записей - 10 минут. Приложение смотрит в локальном кэше, нет ли там искомого имени. И правда, зачем нам тратить время на другие методы, если может статься, что мы недавно уже обращались к станции, и имя её содержится в локальном кеше. Локальный кеш NetBIOS можно посмотреть командой "nbtstat -r". Некоторые параметры, которые влияют на функционал NetBIOS name cache можно найти в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters.
• NetBIOS name server (WINS, NBNS). Если сказать иначе, WINS это DNS от Microsoft для NetBIOS. Станции с определенными типами узлов обращаются к WINS-серверу за разрешением имени.
• IP subnet broadcast - широковещательное сообщение в IP-подсети. Станции с определенными типами узлов формируют широковещательный запрос для разрешения имени.
• Локальный LMHOSTS файл. Аналог файла hosts для NetBIOS. Файл, в котором, в специальном формате, хранится таблица соответствия имен NetBIOS IP-адресам. Размещается в директории %SystemRoot%\System32\Drivers\Etc.
• Локальный HOSTS файл. Файл, в котором, в специальном формате, хранится таблица соответствия имен хостов (TCP/IP hostname) IP-адресам. Располагается в директории %SystemRoot%\System32\Drivers\etc. Этот метод непосредственно не относится к NetBIOS через TCP/IP, а относится уже к TCP/IP Direct Hosting. Если NetBIOS имя найти не удалось, то имя считается как TCP/IP hostname и разрешается уже методами HOSTS+DNS.
• DNS-сервер. Запрос к DNS-серверу. DNS-сервер возвращает запись о соответствии имени хоста IP-адресу.

Тип узла NetBIOS (NodeType)

Поскольку методы регистрации имен в сети у NetBIOS тоже не стояли на месте, и если изначально все сводилось, как мы уже упоминали, к широковещательным запросам, то со временем начали появляться и другие способы зарегистрировать имя (например, с использованием WINS-сервера). В связи с необходимостью разделять логику работы станций, было введено понятие NodeType (NBT-узел) для описания разницы в способах регистрации и распознавания имен. Проще говоря, разные типы узлов имеют свои обособленные алгоритмы разрешения имен в IP-адреса:

• B-node (тип 0x01, широковещательный). Для преобразования имен станций в IP-адреса используется только широковещательные сообщения. Минус этого типа заключается в том, что широковещательные запросы, обычно, режутся маршрутизаторами, поэтому имена могут быть разрешены только в пределах одного сетевого сегмента.
• P-node (тип 0x02, одноранговый). Для разрешения имен используются WINS-сервер (сервер имен NetBIOS). Сессии клиента длятся на три этапа: регистрация имени, обновление имени и освобождение имени. Если WINS не работает, то ни регистрации, ни разрешения не происходит.
• M-node (тип 0x04, смешанный, гибрид B- и P-узлов). Сначала действует как B-node, то есть для разрешения имен используются широковещательные сообщения. Если не получает ответа на широковещательный запрос, то переключается в P-node и использует WINS-сервер.
• H-node (тип 0x08, гибридный, гибрид B- и P-узлов). Сначала пытается стать P-node и действовать через WINS-сервер. Если WINS-сервер не доступен, переключается в B-node и пытается функционировать через широковещательные запросы. Переключается обратно в P-node, как только находит WINS-сервер.

Пополнив многообразие сетевых разработок, с 1990 года начал активно внедряться протокол DHCP, и пришлось оптимизировать NetBIOS под работу с ним. Так, если в сети используется DHCP для автоматического назначения IP-адресов, то можно установить метод разрешения имен для DHCP-клиентов. Другими словами, можно назначить тип узла (nodetype), через установку опцию DHCP-сервера 046 WINS/NBT. Либо, в случае отсутствия DHCP-сервера, можно локально задать тип узла в реестре через параметр nodetype ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters.
По умолчанию, при отсутствии WINS-сервера в сети, Windows выставляет тип узла в значение "модифицированный B-node", а при наличии WINS-сервера тип узла выставляется в гибридный, H-node.
Увидеть тип узла можно посредством команды ipconfig /all, в параметре “тип узла”:

Порядок разрешения имен NetBIOS

Это нетривиальный процесс, который во времени претерпевал большое количество изменений, связанных с введением и преобразованием протоколов, ответственных за сетевое взаимодействие. В данный момент сам процесс разрешения имен NetBIOS вызывает большое количество споров. Связано это с тем, что в сети имеется огромное количество различных источников информации, в которых приводятся довольно расплывчатые формулировки, которые зачастую неактуальны или вовсе ошибочны. Я попробую выразить свою точку зрения на вопрос разрешения имен NetBIOS в частности, и шире - на алгоритм разрешения имен в ОС Windows в общем. Надо понимать, что в Windows существуют два параллельных направления разрешения имен - через функции API Windows Sockets и через функции API NetBIOS. Код ОС , то есть приложения, сервисы, драйвера и прочее, могут использовать тот или иной API. Соответственно, сюда относятся и механизмы разрешения имен самой ОС, которые используются при обращении пользователя к сетевым ресурсам стандартными средствами, например, при использовании проводника или средства подключения сетевых дисков. Таким образом, именно от того, какой метод использует тот или иной компонент ОС и зависит, в конечном итоге, алгоритм разрешения имени.

Если приложение использует функции API Winsock

В этом случае, процесс, инициировавший разрешение имени, использует такие функции API Windows Sockets как: getaddressbyname, gethostbyname, getnameinfo, getaddrinfo, и последовательность разрешения имени, в этом случае, такова:

1. Сравнивает искомое имя с собственным. Не я ли это?;
2. Проверяется наличие записи об узле в в локальном кеше DNS-резолвера. На этом же этапе проверяются записи, присутствующие в файле hosts (%SystemRoot%\System32\Drivers\etc), поскольку они, с определенным интервалом, импортируются в кеш DNS-резолвера;
3. Делается запрос к DNS на наличие записи о хосте в зоне;
4. Проверяется локальный кеш имен NetBIOS (NetBIOS name cache);
5. Опрашивается WINS-сервер;
6. Делается широковещательный запрос;
7. Проверяется наличие записи в файле LMHOSTS. Файл располагается в директории %SystemRoot%\System32\Drivers\etc;

Как мы видим, даже при использовании функций API Winsock, в некоторых случаях, в алгоритме разрешения имени вызываются функции API NetBIOS. То есть, все вышеописанные функции API в своей логике содержат ветвления, которые могут инициировать передачу управления функциям API NetBIOS. Реализовано это с целью сохранить совместимость приложений. Однако, если исходное имя, которое должно быть разрешено:

• Представляет из себя FQDN (Full Qualified Domain Name, полностью уточненное доменное имя), то есть запись вида host.domain.ru.
• Имеет длину более 15 символов.
• Имеет символ "." в своём составе.

..то попытки разрешить имя с помощью функций API NetBIOS вообще не производится. В таком случае, вышеописанные функции в своем алгоритме по условию не вызывают функций разрешения имен API NetBIOS.
Если же имя короче 16 символов (имеет длину не более 15 символов), то в случае неудачной попытки разрешения имени с помощью HOSTS+DNS, функции API Winsock передают его в API NetBIOS (где оно дополняется пробелами) для разрешения уже логикой NetBIOS.

Если приложение использует функции API NetBIOS

В этом случае, логика разрешения имен кардинально меняется. Сперва вызывается единственная функция API NetBIOS которая имеет одноименное название Netbios:

Параметром данной функции является указатель на структуру NCB, в члене ncb_command которой, с целью поиска имени, указывается код команды NCBFINDNAME. В случае ошибки выполнения функции, производится попытка разрешения уже при помощью API Winsock (описан выше).

Например, для Модифицированного H-узла (Enchanced H-node) она следующая:

1. Локальный кеш имен NetBIOS;
2. WINS-сервер;
3. Широковещательный запрос;
4. Файл LMHOSTS;
5. Локальный кеш DNS. Файл hosts (записи из него включаются в локальный кеш DNS);
6. DNS-сервер;

То есть, как мы видим из последовательности, используется сначала логика разрешения имен NetBIOS, а потом уже, если имеется необходимость, вызываются функции API Winsock.
Исходя из всего вышеописанного, довольно сложно составить какой-то обобщенный алгоритм разрешения имен, однако я все же постараюсь это сделать. Для наглядной демонстрации описанной логики я приведу схему, описывающую собственное понимание происходящего. Стоит, однако, отметить, что в зависимости от API, которое используется для разрешения имени, части данной схемы могут меняться местами.

На этой оптимистической ноте я и хотел бы завершить теоретическую часть обзора NetBIOS через TCP/IP. Очевидно, что на данный момент NetBIOS морально устарел и содержит впечатляющее количество недоработок. К примеру, одним из существенных недостатков безопасности NetBIOS является предоставление информации о сетевых сервисах (ресурсах) любому узлу в сети в ответ на типовой запрос, то есть отсутствуют какие бы то ни было критерии разграничения доступа. Вероятно, архитектура NetBIOS уже настолько неоптимальна, что в какой-то момент разработчики MS отказались от её доработки с целью поддержки современных сетевых стандартов. Microsoft, судя по всему, всячески пытается избавиться от протокола, и подтверждением тому служит и тот факт, что был написан аналог - PNRP (LLMNR). В следующих статьям мы познакомимся с такими часто встречающимися на практике примерами, как подключение к ресурсам посредством NetBIOS, построение объектов сетевого окружения через NetBIOS.