Linux netbios name как узнать

linux и NetBIOS-имя

Уже ни один день бьюсь над большой проблемой, вкратце:

есть сеть 192.168.0.0/24 без домена, есть два хоста NAS(ds1) и CentOS 7(s1),последний со всеми update, и несколько виндовых машин. так вот..

Что я уже только не делал. сейчас на таком этапе что

Это вроде бы всё понятно, т.к. s1 получает настройки по DHCP (зарезервированный IP). А ds1 настройки статикой прописаны. А DHCP и NS на роутере.

А теперь вот с чем борюсь в данный момент(office виндовый хост):

Теперь со стороны ds1:

Пока что вот так. Мне нужно чтобы

NETBIOS и DNS — это разные службы, что бы машина была видна по NETBIOS имени нужно в smb.conf этой машины в секции [global] задать параметр

После чего перезапустить samba.

Ну либо создай на DNS сервере соответствующие записи, либо пропиши в hosts файле.

На s1 в секции [global] прописал netbios name = s1. Перезапустил samba и .

Ручками прописать в DNS и в hosts отбросил сразу, т.к. на ds1 это всё работает без всяких записей.

А да и я знаю что это разные службы) Но в данной ситуации они делают одну работу разрешают короткое имя. А вот полного механизма этого разрешения в linux я пока не понимаю. Предложения через WINS решить тоже пока не рассматриваю. Не могу понять в чем разница работы разрешения в двух конкретных машинах.

У тебя nsswitch-то настроен на проверку имен через wins? Если нет — ping не будет работать разрешать имена через netbios от слова совсем

в /etc/nsswitch.conf строчка хостов такая

Может быть есть источники где расписан механизм расширения имён в linux’ах? Я вот что-то конкретного и полного пока не нашёл. только по отдельности про samba dns netbios.

есть источники где расписан механизм расширения имён в linux’ах?

man nsswitch.conf и дальше по man-ам соответствующих функций glibc(например man gethostbyname — которая как раз и используется для резолва хостов)

Ужас как ничего не понятно вот просто что сейчас в голове NetBIOS, wins, winbind, libnss_wins, Samba(Samba4WINS), NSS (nsswitch.conf). Что к чему, куда и как так и не разобрался. Вот сеейчас изучу этот вопрос и напишу всё подробно и понятно, для таких как я. Ещё уже узнал замечательное решение, что можно на DNS прикрутить nmblookup и Net-BIOS-имена будут разрешаться через DNS сервак, это гениально! я считаю)

Буду потихоньку ликбезить.

Даже если не указано имя явно, на работу по короткому имени это не влияет:

netbios name. С помощью этого параметра задается NetBIOS-имя, заявляемое сервером. Если этот параметр не задан, то по умолчанию используется часть DNS-имени компьютера, соответствующая имени хоста; например, если DNS-имя компьютера tunesmith.example.com, то NetBIOS-именем будет TUNESMITH

Спасение утопающих, дело рук самих утопающих.

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

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

Поэтому пропускаем это мимо ушей и идём дальше. Как выяснилось чтобы nmblookup сработал, нужно снести одно правило в iptables с действием REJECT в chain(цепочке) INPUT

в /etc/nsswitch.conf в строке hosts: указан wins! в /etc/samba/smb.conf указана в разделе [global] строка

Чудо произошло.

Не знаю почему, не знаю как, не знаю что с этим CentOs! Но, nmb smb winbind — не были запущены. (точка!) вроде бы samba установлена, и чего бы ей не работать. но факт остался фактом, после установки. smbclient работал замечательно, а демоны не были запущены, хост ребутался правда переодически, но я блин был в полной уверенности что samba установлена. это мне урок на многие годы) Надеюсь всё делалось не зря, всем спасибо!

Источник

Как узнать сетевое имя машины, если есть ее IP?

Вот, собсна, сабж. Можно ли как-то узнать сеевое имя машины по ее АЙПИ-адресу? SMB-сеть, машины все под виндой кроме одной, на которой убунту. З.Ы. думал, мот nmap подойдет — но че-то не нашел я там, как имя хоста вывести.

Re: Как узнать сетевое имя машины, если есть ее IP?

Re: Как узнать сетевое имя машины, если есть ее IP?

На входе имя/ip, на выходе ip/имя соответственно.

Если в скрипте, то resolveip -s (т.е. без сопроводительного текста)

Re: Как узнать сетевое имя машины, если есть ее IP?

Да, речь о доменном имени конечно, т.е. оно просто делает запрос в dns

Re: Как узнать сетевое имя машины, если есть ее IP?

Если тебя netbios-имя интересует, тогда

nmblookup -A ipaddr

Re: Как узнать сетевое имя машины, если есть ее IP?

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

Re: Как узнать сетевое имя машины, если есть ее IP?

третий кур, предмет «Компьютерные сети»
man arp

Re: Как узнать сетевое имя машины, если есть ее IP?

> вендовское имя машины в рабочей группе
Тогда однозначно nmblookup

Источник

nbtscan. Узнаем NETBIOS имена в локальной сети

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

В поисках нам могут помочь имена ПК. Узнать имена большинства ПК и других устройств можно с помощью протокола NETBIOS и утилиты nbtscan.

Использование утилиты очень простое:

nbtscan 192.168.1.0/24

где, 192.168.1.0/24 это интересующая нас подсеть.
На выходе мы получим список IP адресов и NETBIOS имен.

Так же есть пара полезных ключей:
-v подробный вывод всех найденных имен ПК с указанием сервиса, от которого было получено имя (Workstation Service, File Server Service, Master Browser, Browser Service Elections и т.д.)
-h написать читаемое имя сервиса (используется только с параметром -v)

Остальные ключи касаются формата вывода полученной информации и в основном нужны для формирования списков для дальнейшего использования и их можно посмотреть запустив nbtscan без параметров.
Например командой:

nbtscan -v -s : 192.168.1.0/24

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

Заказать Аудит Безопасности или Пентест Вашей IT-инфраструктуры

Быть уверенным в своей IT-инфраструктуре — это быть уверенным в завтрашнем дне.

Источник

Как узнать NETBIOS имена в локальной сети.

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

В поисках нам могут помочь имена ПК. Узнать имена большинства ПК и других устройств можно с помощью протокола NETBIOS и утилиты nbtscan.

Использование утилиты очень простое:

где, 192.168.1.0/24 это интересующая нас подсеть.
На выходе мы получим список IP адресов и NETBIOS имен.

Так же есть пара полезных ключей:
-v подробный вывод всех найденных имен ПК с указанием сервиса, от которого было получено имя (Workstation Service, File Server Service, Master Browser,Browser Service Elections и т.д.)
-h написать читаемое имя сервиса (используется только с параметром -v)

Остальные ключи касаются формата вывода полученной информации и в основном нужны для формирования списков для дальнейшего использования и их можно посмотреть запустив nbtscan без параметров.
Например командой:

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

Источник

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 хостов

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

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

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

1. попытаться использовать каждый ПК в корпоративной подсети в качестве шлюза до требуемой сети. Это было бы очень удобно, но такое редко встречается, т. к. на windows хостах ip forwarding почти всегда отключен. Более того подобная проверка возможна только внутри своей подсети, а также она требует от злоумышленника точно знать целевой адрес из изолированной сети
2. пытаться удалённо заходить на каждый хост и выполнять банальную команду 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 поведение немного отличается). И если вы, вдруг несогласованно, в обход правил сетевой маршрутизации включились в закрытый сегмент, то злоумышленник вас обязательно найдет и сделает это очень быстро.

Источник