что такое служба netbios
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 хостов
И наконец ещё одна вероятно очень мало известная техника, которая является просто незаменимой для нахождения путей в защищённые, возможно даже изолированные физически, сети. Это могут быть цеховые сети предприятий, напичканные контроллерами. Доступ к этой сети для злоумышленника означает возможностью влиять на технологический процесс, а для предприятия риск понести колоссальные убытки.
Итак, суть в том, что даже если сеть изолирована из корпоративной сети, то зачастую некоторые администраторы, то ли по своей лени, то ли ещё как то, любят поднимать ещё одну сетевую карту на своих ПК для доступа в эту самую сеть. При этом всё это происходит конечно же в обход всяческих правил корпоративных сетевых экранов. Удобно, да, но не очень безопасно, в случае если вас взломают, тогда вы станете мостом в данную сеть и понесёте ответственность.
Однако для злоумышленника тут есть одна проблема — найти того самого администратора, который включился в защищённую сеть подобным нелегальным образом. Более того, это непростая проблема и для самих безопасников сети. На больших предприятиях это поистине сложная задача, словно отыскать иголку в стоге сена.
В данной ситуации очевидных варианта для злоумышленника было бы два:
это обратный ресолв ip-адрес → сетевое имя. Если же мы теперь попытаемся сделать прямой ресолв сетевое имя → ip-адрес:
то мы узнаем, что данный хост — это ещё и шлюз (по-видимому) в какой то другой сети. Стоит отметить, что в данном случае запрос шёл широковещательно. Иными словами, его услышат хосты только из подсети злоумышленника.
Если же целевой хост находится за пределами подсети, то можно послать таргетированный запрос:
Теперь осталось лишь быстро собрать информацию со всей интересующей подсети, а не с одного адреса. Для этого можно использовать небольшой 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 в Windows, как включить службу или приостановить её работу
Во время установки операционной системы Windows пользователем задаётся имя компьютера, к которому в дальнейшем будут обращаться программы, устройства, соединённые локальной сетью, веб-сервер, FTP и другие сетевые службы. Протокол NetBIOS крайне важен для работы системы, поэтому рекомендуется знать о его устройстве и выполняемых функциях, чтобы лучше понимать, как происходит обмен данными между процессами, приложениями или компьютерами.
NetBIOS – устройство и принцип работы
Windows использует данный интерфейс в качестве основной системы сетевого ввода-вывода, а также для возможности установки общего доступа к сетевым устройствам и файлам. Пакеты данных передаются по локальной сети через сеансы эталонной модели взаимодействия открытых систем, и через сетевые протоколы приложения могут обмениваться информацией по ним. Простыми словами, данная система является сетевым протоколом, предназначенным для работы в локальных сетях и обмена сведениями, значениями и другими данными внутри них. Начиная с Windows 2000 модуль поддержки NetBIOS через TCP/IP носит название NetBT.
По протоколу программы находят нужные им ресурсы, передают запросы на получение информации либо отдают собственные данные. Сперва открывается сессия с NetBIOS запросом, задаётся IP-адрес, система определяет подходящий порт для проведения конкретного типа операции (служба имён использует порт 137, дейтаграмм – 138, а сессий – 139), происходит обмен пакетами данных, когда поток прекращается – сессия закрывается. Одно сообщение может занимать до 131071 байт или 131 КБ. В одно время может быть установлено несколько уникальных сессий. NetBIOS адрес имеет следующий вид: IP.**.**.**.**, где под звёздочками – IP-адрес, а под IP – тип осуществляемой операции. Протокол использует собственные команды для проведения обмена данными (send, receive, call, remote program load, session status, reset, hang up, cancel и другие), а также особые примитивы для взаимодействия с дейтаграммами (receive datagram, send datagram, receive broadcast datagram, send broadcast datagram). Крайние узлы NetBIOS подразделяются на следующие типы:
В зависимости от IP-адреса, используется конкретный вид запроса, к примеру, для осуществления передачи данных узлами P- и M- будет использован NBNS сервер имён и NBDD сервер распределения дейтаграмм.
Службы NetBIOS
Для работы протокол использует NetBIOS-NS (служба имён), NetBIOS-SSN (сеансовая служба) и NetBIOS-DGM (служба рассылки дейтограмм). NS выполняет функцию регистрации и разрешения имён, DGM подходит для передачи данных без установки соединения, а последняя служба, SSN — передаёт пакеты с установлением соединения.
Протокол обеспечивает команды и поддержку следующих служб, предоставляя им доступ к сеансам эталонной модели взаимодействия открытых систем OSI:
Сперва служба имён осуществляет регистрацию имени приложения в NetBIOS, перед тем как запустить сеанс либо начать распространение дейтаграмм. Используются примитивы «add name» (регистрация имени), «add group name» (запись имени группы NetBIOS), «delete name» (удаление регистрации имени приложения либо группы), «find name» (поиск имени NetBIOS в сети).
Служба рассылки дейтаграмм работает на порту UDP 138 и отвечает за режим обмена без установки соединения. С помощью примитивов «send datagram» (отправка дейтаграммы на удалённое имя), «receive datagram» (переход в режим ожидания получения пакета), «send broadcast datagram» (отправка датаграммы всем зарегистрированным именам из сети NetBIOS), а также «receive broadcast datagram» (ожидание получения пакета данных из сессии отправки широковещательной дейтаграммы) – происходит обмен информацией без установленного соединения.
В сеансовом режиме используется SSN служба (TCP порт 139), которая позволяет установить соединение между двумя компьютерами и обмениваться сообщениями (охват сразу нескольких пакетов), а также отвечающая за обеспечение диагностики и исправления ошибок. Сеанс происходит с использованием данных типов примитивов:
Компьютер, инициирующий сеанс, должен отправить запрос Open, после чего должен запросить запуск сеанса с помощью Call. Принимающий отвечает на каждый передаваемый пакет положительно (ACK), либо отрицательно (NAK). Чтобы сессия была закрыта, компьютер, который не является инициирующим должен отправить запрос Hang Up на завершение и получить подтверждение от инициатора.
Запуск и отключение службы NetworkBIOS
Перед тем, как прекратить работу NetBIOS через TCP/IP, помните, что служба является относительно важной для компьютера и после проведения данной операции не сможет правильно функционировать возможность доступа к сетевому компьютеру по NetBIOS-имени. Если персональный компьютер подключен к сети, не рекомендуется отключать данную службу, чтобы не возникало ошибок.
Пользователи задаются вопросом, как узнать статус службы в Windows 10 (и других выпусках). Для того чтобы это сделать, необходимо вызвать системное приложение «Выполнить» при помощи комбинации Win + R, затем ввести в поле «Запустить» значение «services.msc» и нажать ОК. Для удобного поиска можете отсортировать список в алфавитном порядке, щёлкнув на колонку «Имя». Здесь необходимо найти интересующую службу, в нашем случае это «Модуль поддержки NetBIOS» через TCP/IP». Колонка «Состояние» отображает, запущена ли в текущий момент служба или нет. По умолчанию данный модуль находится в запущенном состоянии, если компьютер подключен к сети.
Чтобы отключить NetBIOS, необходимо щёлкнуть правой кнопкой мыши по соответствующему элементу в списке и выбрать пункт «Свойства» в контекстном меню. В настройках службы NetBIOS следует нажать на кнопку «Остановить», а затем установить тип запуска «Отключена» чуть выше (если нужно запустить, то должно быть выбрано «Вручную» либо «Автоматически). Примените изменения, после чего нажмите «ОК и закройте приложение «Службы». Теперь запустите редактор реестра, воспользовавшись комбинацией Win + R и запросив запуск «regedit.exe». Перейдите в каталог «HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/lmhosts» и измените значение атрибута «Start» на «4» (2 – автоматически, 3 – вручную и 4 – отключить, выбирайте в соответствии с желаемым действием) и нажмите ОК, затем нажмите кнопку F5 на клавиатуре. Перезагрузите компьютер и удостоверьтесь, что NetBIOS больше не запускается автоматически.
Надеемся, вы разобрались с принципом работы этого важного сетевого протокола, ранее имевшего статус первой необходимости на каждом компьютере (сейчас это время прошло, теперь используется исключительно соединение Service Message Block или SMB). Если остались какие-либо вопросы, связанные с данной темой, либо возникли проблемы во время отключения сетевого компонента Windows – записывайте свои ответы в комментарии. Не забывайте и про рейтинг, оцените статью с помощью специальной формы.
[Конспект админа] Домены, адреса и Windows: смешивать, но не взбалтывать
Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.
Дедушка NetBIOS
NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:
регистрация и проверка сетевых имен;
установление и разрыв соединений;
связь с гарантированной доставкой информации;
связь с негарантированной доставкой информации;
В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.
Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.
Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255
Интересная особенность в том, что можно привязывать имя не к хосту, а к сервису. Например, к имени пользователя для отправки сообщений через net send.
Пример работы кэша для разрешения имени узла «хр».
Что происходило при этом с точки зрения сниффера.
В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.
В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.
В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.
Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.
Стандарт наших дней – DNS
DNS (Domain Name System) – распределенная иерархическая система для получения информации о доменах. Пожалуй, самая известная из перечисленных. Механизм работы предельно простой, рассмотрим его на примере определения IP адреса хоста www.google.com:
если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;
сервер DNS смотрит запись у себя, и если у него нет информации даже о домене google.com – отправляет запрос на вышестоящие сервера DNS, например, провайдерские. Если вышестоящих серверов нет, запрос отправляется сразу на один из 13 (не считая реплик) корневых серверов, на которых есть информация о тех, кто держит верхнюю зону. В нашем случае – com.
после этого наш сервер спрашивает об имени www.google.com сервер, который держит зону com;
Наглядная схема прохождения запроса DNS.
Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.
Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.
DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.
Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.
В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.
На скриншоте видно, что сразу после чистки кэша в него добавляется содержимое файла hosts, и иллюстрировано наличие в кэше неудачных попыток распознавания имени.
При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.
Настройка политики разрешения имен через GPO.
При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.
Порядок разрешения имен
Операционная система Windows пытается разрешить имена в следующем порядке:
проверяет, не совпадает ли имя с локальным именем хоста;
смотрит в кэш DNS распознавателя;
если в кэше соответствие не найдено, идет запрос к серверу DNS;
если имя хоста «плоское», например, «servername», система обращается к кэшу NetBIOS. Имена более 16 символов или составные, например «servername.domainname.ru» – NetBIOS не используется;
если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;
если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;
Для удобства проиллюстрирую алгоритм блок-схемой:
Алгоритм разрешения имен в Windows.
То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути. В этом легко убедиться, запустив простейший скрипт:
Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.
Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.
Отдельного упоминания заслуживают доменные сети – в них запрос с коротким именем отработает чуть по-другому.
Active Directory и суффиксы
Active Directory тесно интегрирована с DNS и не функционирует без него. Каждому компьютеру домена создается запись в DNS, и компьютер получает полное имя (FQDN — fully qualified domain name) вида name.subdomain.domain.com.
Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.
При попытке запуска команды ping servername система проделает следующее:
если в кэше DNS имя не существует, система спросит у DNS сервера о хосте servername.subdomain.domain.com;
При этом к составным именам типа www.google.com суффиксы по умолчанию не добавляются. Это поведение настраивается групповыми политиками.
Настройка добавления суффиксов DNS через групповые политики.
Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.
Суффиксы DNS и их порядок в выводе ipconfig /all.
Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам. Посмотреть, что именно происходит внутри nslookup можно, включив диагностический режим директивой debug или расширенный диагностический режим директивой dc2. Для примера приведу вывод команды для разрешения имени ya.ru:
Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:
Это поведение иногда приводит в замешательство начинающих системных администраторов.
Лично сталкивался с такой проблемой: в домене nslookup выдавал всегда один и тот же адрес в ответ на любой запрос. Как оказалось, при создании домена кто-то выбрал имя domain.com.ru, не принадлежащее организации в «большом интернете». Nslookup добавляла ко всем запросам имя домена, затем родительский суффикс – com.ru. Домен com.ru в интернете имеет wildcard запись, то есть любой запрос вида XXX.com.ru будет успешно разрешен. Поэтому nslookup и выдавал на все вопросы один ответ. Чтобы избежать подобных проблем, не рекомендуется использовать для именования не принадлежащие вам домены.
При диагностике стоит помнить, что утилита nslookup работает напрямую с сервером DNS, в отличие от обычного распознавателя имен. Если вывести компьютер из домена и расположить его в другой подсети, nslookup будет показывать, что всё в порядке, но без настройки суффиксов DNS система не сможет обращаться к серверам по коротким именам.
Отсюда частые вопросы – почему ping не работает, а nslookup работает.
В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.
Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.
Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.