Способы разрешения имен netbios

Разрешение имени NetBIOS — это процесс определения IP-адреса по имени NetBIOS.

Имя NetBIOS представляет собой 16-байтовый адрес, используемый для идентификации в сети ресурса NetBIOS. Имя NetBIOS может быть либо уникальным (эксклюзивным), либо групповым (неэксклюзивным). Когда процесс NetBIOS соединяется с конкретным процессом на конкретном компьютере, используется уникальное имя. Когда процесс NetBIOS соединяется с несколькими процессами на нескольких компьютерах, применяется групповое имя.

Примером процесса, использующего имя NetBIOS, является служба доступа к файлам и принтерам сетей Microsoft, работающая на компьютере с Windows XP Professional;. При запуске компьютера эта служба регистрирует уникальное имя NetBIOS, основанное на имени компьютера. Имя NetBIOS этой службы состоит из 15-символьного имени компьютера плюс 16-й символ с кодом 0x20. Если имя компьютера имеет длину меньше 15 символов, оно дополняется до этой длины пробелами.

При использовании имени компьютера для установки соединения с ним для совместного использования файлов служба доступа к файлам и принтерам для сетей Microsoft на указанном файловом сервере будет иметь соответствующее имя NetBIOS. Например, при попытке подключиться к компьютеру с именем CORPSERVER имя NetBIOS, соответствующее службе доступа к файлам и принтерам сетей Microsoft этого компьютера, будет следующим:

CORPSERVER [20]
Заметьте, что имя компьютера дополняется пробелами. Перед тем как будет установлено соединение для совместного использования файлов и принтеров, должно быть создано TCP-соединение. Для создания TCP-соединения необходимо разрешить NetBIOS-имя «CORPSERVER [20]» в IP-адрес.

Процедура, используемая для разрешения имен NetBIOS в IP-адреса, определяется типом узла NetBIOS. В документе RFC 1001 «Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods» описаны типы узлов NetBIOS, вот они:

B-узел (broadcast — широковещание)
B-узел использует широковещательные запросы на регистрацию и разрешение имен NetBIOS. B-узел имеет два серьезных недостатка: (1) широковещательные запросы загружают все узлы сети и (2) маршрутизаторы обычно не передают широковещательные пакеты в другие сети, поэтому имена NetBIOS могут разрешаться только в локальной сети.

P-узел (peer-peer — равный с равным)
P-узел использует для разрешения имен NetBIOS сервер имен NetBIOS (NBNS), например WINS-сервер. P-узел не применяет широковещание; вместо этого он напрямую запрашивает сервер имен.

M-узел (mixed — смешанный)
M-узел — это комбинация B-узла и P-узла. По умолчанию M-узел работает в режиме B-узла. Если M-узел не может разрешить имя с помощью широковещательного запроса, он запрашивает сервер NBNS в режиме P-узла.

H-узел (hybrid — гибридный)
H-узел — это комбинация P-узла и B-узла. По умолчанию H-узел работает в режиме P-узла. Если H-узел не может разрешить имя с помощью сервера NBNS, он использует широковещание.

Компьютеры под управлением Windows Server 2003 по умолчанию работают в режиме B-узла и становятся H-узлами, когда на них настраивается WINS-сервер. Эти компьютеры могут также использовать для разрешения имен NetBIOS файл локальной базы данных — Lmhosts. Файл Lmhosts хранится в папке корневая_папка_системы\System32\Drivers\Etc. Дополнительные сведения см. в разделе Файлы базы данных TCP/IP.

Настоятельно рекомендуется указывать на компьютерах Windows IP-адрес WINS-сервера для разрешения удаленных имен NetBIOS. На компьютерах, использующих службу каталогов Active Directory (например, работающих под управлением Windows XP Professional; или Windows Server 2003), необходимо настроить IP-адрес WINS-сервера, если этим компьютерам требуется обмениваться данными с компьютерами под управлением Windows NT, Windows 95, Windows 98, Windows 2000 или Windows Millennium Edition, которые не используют Active Directory.

Дополнительные сведения о WINS см. в разделе Определение службы WINS.

В статье использователись материалы с сайта Microsoft.

Источник

NetBIOS в руках хакера

В данной статье пойдёт краткое повествование о том, что нам может рассказать такая привычная с виду вещь как NetBIOS. Какую он может предоставить информацию для потенциального злоумышленника/пентестера.

Продемонстрированная область применения разведывательных техник относится к внутренним, то есть изолированным и недоступным извне сетям. Такие сети есть как правило у любой даже у самой крошечной компании.

Сам по себе NetBIOS используется, как правило, для получения сетевого имени. И этого будет достаточно, чтобы сделать как минимум 4 вещи.

Обнаружение хостов

Благодаря тому, что NetBIOS может использовать UDP в качестве транспорта, скорость его работы позволяет обнаруживать хосты в очень больших сетях. Так, например, инструмент nbtscan, входящий в одноимённый пакет, может всего за 2 секунды (может положить сеть) разресолвить адреса сети вида 192.168.0.0/16, тогда как традиционное TCP-сканирование займёт десятки минут. Эту особенность можно использовать как технику обнаружения хостов (host sweep) в очень больших сетях, о которых ничего не известно, перед тем как запускать nmap. Хотя результат и не гарантирует 100% обнаружения, т. к. преимущественно отвечать будут windows-хосты и то не все, он всё же позволит определить, в каких примерно диапазонах находятся живые хосты.

Идентификация хостов

Используя результаты получения имён из ip-адресов:

можно видеть: помимо того что имя раскрывает владельца рабочей станции (хотя такое кстати бывает далеко не всегда), один из адресов явно выделяется на фоне других. Мы можем видеть, что было получено имя KALI. Такое поведение характерно, как правило, для unix-реализации SMB/NetBIOS в составе программного пакета samba или очень старых Windows 2000.

Получение имени KALI, в то время как на других хостах это свидетельствует о наличии так называемой null-session. При дефолтных настройках SMB-сервера на linux склонны к ней. Null-session лишь позволяет абсолютно анонимно (а мы ни какие пароли не вводили, как видно на скрине) получить достаточно много дополнительной информации, такой как локальная парольная политика, список локальных пользователей, групп и список расшаренных ресурсов (шар):

Зачастую на linux SMB-серверах бывают публично доступные шары не то что на чтение, но даже на запись. Наличие и той, и другой несут в себе различные угрозы, использование которых выходит за рамки данной статьи.

NetBIOS так же позволяет получить имена всех типов, которые хранит рабочая станция:

в данном случае это позволяет узнать, что хост является ещё и контроллером домена ARRIVA.

Так же стоит еще дополнительно обратить внимание, что NetBIOS позволяет получить mac-адрес. При чём в отличие от arp-запросов, NetBIOS-запросы способны выйти за пределы подсети. Это может быть полезно если, например, требуется отыскать в сети какой-нибудь ноутбук или специфичное железо, зная его производителя. Так как первые три октета mac-адреса идентифицируют производителя, то можно рассылая подобные NetBIOS-запросы во все известные подсети попытаться найти нужное устройство (http://standards-oui.ieee.org/oui.txt).

Определение принадлежности к домену

Часто при перемещении по внутренним корпоративным сетям требуется атаковать именно рабочую станцию, включенную в домен (например, для поднятия привилегий до уровня доменного администратора) или наоборот. В данном случае NetBIOS опять-таки может помочь:

В данном случае с помощью NetBIOS были получены все имена всех типов. Среди них можно увидеть, помимо имени ПК (то что уже было получено до этого), ещё и имя рабочей группы. По дефолту для windows оно как правило что-то вроде WORKGROUP или IVAN-PC, но если рабочая станция в домене, то её рабочая группа — это и есть имя домена.

Таким образом, с помощью NetBIOS можно узнать в домене ли рабочая станция и, если да, то в каком.

Если же требуется получить список доменных хостов в пределах подсети, то хватит и одного широковещательного запроса с именем нужного домена:

в результате ответят все хосты, состоящие в данном домене.

Обнаружение multihomed хостов

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

Итак, суть в том, что даже если сеть изолирована из корпоративной сети, то зачастую некоторые администраторы, то ли по своей лени, то ли ещё как то, любят поднимать ещё одну сетевую карту на своих ПК для доступа в эту самую сеть. При этом всё это происходит конечно же в обход всяческих правил корпоративных сетевых экранов. Удобно, да, но не очень безопасно, в случае если вас взломают, тогда вы станете мостом в данную сеть и понесёте ответственность.
Однако для злоумышленника тут есть одна проблема — найти того самого администратора, который включился в защищённую сеть подобным нелегальным образом. Более того, это непростая проблема и для самих безопасников сети. На больших предприятиях это поистине сложная задача, словно отыскать иголку в стоге сена.

В данной ситуации очевидных варианта для злоумышленника было бы два:

попытаться использовать каждый ПК в корпоративной подсети в качестве шлюза до требуемой сети. Это было бы очень удобно, но такое редко встречается, т. к. на windows хостах ip forwarding почти всегда отключен. Более того подобная проверка возможна только внутри своей подсети, а также она требует от злоумышленника точно знать целевой адрес из изолированной сети
пытаться удалённо заходить на каждый хост и выполнять банальную команду ipconfig/ifconfig. И тут не всё так гладко. Даже если злоумышленник заручился правами доменного администратора, то сетевые экраны и локальные фаерволы никто не отменял. Так что данная задача не на 100% автоматизируется. В результате остаётся мучительно заходить на каждый хост, преодолевая сетевые экраны (часто блокирующие именно 445/tcp порт), в надежде увидеть наконец желанный сетевой интерфейс.

Однако всё куда проще. Существует один чрезвычайно простой приём, который позволяет получить с того или иного хоста список сетевых интерфейсов. Допустим у нас есть некий хост:

это обратный ресолв ip-адрес → сетевое имя. Если же мы теперь попытаемся сделать прямой ресолв сетевое имя → ip-адрес:

то мы узнаем, что данный хост — это ещё и шлюз (по-видимому) в какой то другой сети. Стоит отметить, что в данном случае запрос шёл широковещательно. Иными словами, его услышат хосты только из подсети злоумышленника.

Если же целевой хост находится за пределами подсети, то можно послать таргетированный запрос:

В данном случае видно, что цель находится за пределами подсети злоумышленника. С помощью ключа -B было указано, что запрос следует слать на конкретный адрес, а не на широковещательный.

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

И через несколько секунд:

Именно выделенный хост, в данном импровизированном случае стал бы первой мишенью злоумышленника, если бы он преследовал сеть 172.16.1/24.

Повторяющиеся имена на разных ip свидетельствуют о том, что хост имеет так же две сетевые карты, но уже в одной подсети. Тут стоит отметить, что NetBIOS не разглашает alias-ы (которые легко могут быть вычислены через arp-запросы как ip с одинаковым mac). В данном случае ip-адреса имеют разные mac.

Другой пример использования данного приёма — общественный Wi-Fi. Иногда можно встретить ситуацию, когда среди гостевых устройств к общественной сети подключается персонал, работающий в закрытом корпоративном сегменте. Тогда с помощью данной разведывательной техники злоумышленник очень быстро сможет наметить себе путь для прохождения в закрытую сеть:

В данном случае среди 65 клиентов общественного Wi-Fi оказались две рабочие станции, имеющие дополнительный интерфейс, вероятно относящийся к корпоративной сети.

Если иногда между сетевыми сегментами или прямо на рабочих станциях наблюдается фильтрация трафика на 445/tcp порт, препятствующая удалённому входу на систему (удалённому исполнению кода), то в данном случае для разрешения имён по NetBIOS используется 137/udp порт, сознательное блокирование которого почти не встречается, т. к. от этого сильно пострадает удобство работы в сети, например, может исчезнуть сетевое окружение и т.п.

Как говорится, enumeration is the key
Есть ли от этого защита? Её нет, т. к. это и не уязвимость во все. Это лишь штатный функционал того немного что есть по умолчанию у windows (в linux поведение немного отличается). И если вы, вдруг несогласованно, в обход правил сетевой маршрутизации включились в закрытый сегмент, то злоумышленник вас обязательно найдет и сделает это очень быстро.

Источник

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:

NETBIOS-NS (NetBIOS Name Service) — Служба имен NetBIOS . Сервис обеспечивает работу с именами: запрос на регистрацию имени, запрос на регистрацию имени группы, запрос на разрегистрацию (удаление) имени, проверку имени на существование.

NETBIOS-DGM (NetBIOS Datagram Services) — Служба дейтаграмм NetBIOS . Сервис обеспечивает рассылку дэйтаграм: адресную передачу к одной станции, широковещательную рассылку ко всем станциям, многоадресную рассылку к [определенным] станциям (с одним групповым именем).

NETBIOS-SSN (NetBIOS Sessions Services) — Служба сессий 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.

Уникальное имя (Unique name)	Суффикс	Описание
COMPUTERNAME	Регистрируется сервисом «Рабочая станция» (Workstation). Это NetBIOS-имя станции. Передается в качестве имени источника в запросе на установку NBT-сессии. Позволяет хосту подключаться к сетевым ресурсам.
COMPUTERNAME	Регистрируется сервисом Messenger. Не во всех версиях Windows. Передается в качестве имени источника в запросе на установку NBT-сессии сервисом Messenger.
COMPUTERNAME	Регистрируется сервисом Messenger. Это имя используется при обмене сообщениями (WinPopup) между хостами. Для этого используется SMB протокол.
USERNAME	Регистрируется сервисом Messenger. Используется так же, как и описанное выше правило для COMPUTERNAME , однако адресатом, вероятно, является пользователь.
COMPUTERNAME	Регистрируется сервисом RAS Server.
COMPUTERNAME	Регистрируется сервисом NetDDE
COMPUTERNAME	Регистрируется сервисом «Сервер» (Server). Позволяет хосту получать запросы на соединения от других узлов с целью подключения к ресурсам станции. Используется SMB протокол.
COMPUTERNAME	Регистрируется сервисом RAS Client.
COMPUTERNAME	Регистрируется сервисом Exchange Interchange.
COMPUTERNAME	Регистрируется сервисом Exchange Store.
COMPUTERNAME	Регистрируется сервисом Exchange Directory.
COMPUTERNAME	Регистрируется сервисом Lotus Notes Server.
COMPUTERNAME	Регистрируется сервисом Modem Sharing Server.
COMPUTERNAME	Регистрируется сервисом Modem Sharing Client.
COMPUTERNAME	Регистрируется McAfee Antivirus.
COMPUTERNAME	Регистрируется сервисом SMS Client Remote Control.
COMPUTERNAME	Регистрируется сервисом SMS Admin Remote Control Tool.
COMPUTERNAME	Регистрируется сервисом SMS Client Remote Chat.
COMPUTERNAME	Регистрируется сервисом SMS Client Remote Transfer.
COMPUTERNAME	Регистрируется сервисом DEC Pathworks TCPIP Service.
COMPUTERNAME	Регистрируется сервисом DEC Pathworks TCPIP Service.
COMPUTERNAME	Регистрируется сервисом Microsoft Exchange IMC.
COMPUTERNAME	Регистрируется сервисом Microsoft Exchange MTA.
COMPUTERNAME	Агент Network Monitor. Microsoft’s Network Monitor (NetMon).
COMPUTERNAME	Приложение Network Monitor Client. GUI для Network Monitor (NetMon).
DOMAINNAME/WORKGROUPNAME	Регистрирует станцию как Domain Master Browser. Регистрация суффикса 1B отличает PDC от остальных контроллеров домена.
DOMAINNAME	Регистрирует станцию как Master Browser (зачастую именуется как Local Master Browser). Имя уникально для локального сегмента сети.
Групповое имя (Group name)	Суффикс	Описание
DOMAINNAME/WORKGROUPNAME	Регистрирует станцию как члена рабочей группы или домена.
DOMAINNAME	Регистрирует станцию как контроллер домена. Каждый контроллер домена регистрирует это групповое имя.
DOMAINNAME/WORKGROUPNAME	Регистрируется как групповое имя. Используется при выборах Master Browser.
Forte_$ND800ZA	DCA IrmaLan Gateway Server Service
IRISMULTICAST	Lotus Notes.
IRISNAMESERVER	Lotus Notes.
[01h][02h]__MSBROWSE__[02h]	Master Browser (Local Master Browser). Групповое имя, регистрируемое всеми Master Browser в сети. Используется для поиска других LMB с целью обмена списками просмотра.

Тип ресурса можно посмотреть командой 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, в параметре “тип узла”:

Источник