Перейти к содержанию

Вопрос

Опубликовано (изменено)

Добрый день, предлагаю добавить LLMNR в прошивку.

1. Во всех актуальных версиях Windows он включен по умолчанию, при этом имеет больший приоритет чем разрешение имен через NetBIOS протокол(DNS -->  LLMNR --> WINS/NetBIOS --> LMHOST)

2. При отключении протокола smb1 в актуальных версиях windows также удаляется и протокол netbios (через удаление/установку компонентов windows)

3 На последней версии Windows 10 1709 smbv1/netbios отключены по умолчанию, так же при обновлении на эту версию со старых этот компонент удаляется автоматически при не использовании

https://support.microsoft.com/ru-ru/help/4034314/smbv1-is-not-installed-windows-10-and-windows-server-version-1709

Поэтому считаю возможным рассмотреть внедрение в кинетике более актуального в среде windows протокола разрешения имен LLMNR

Изменено пользователем r13
  • Спасибо 1
  • Лайк 5

Рекомендуемые сообщения

  • 0
Опубликовано (изменено)

@Le ecureuil @ndm работает, спасибо, проверил в WIndows 10 Pro 1709. ниже в скрытом дамп.

Frame 789: 84 bytes on wire (672 bits), 84 bytes captured (672 bits) on interface 0
Ethernet II, Src: ZyxelCom_3a:77:1c (60:31:97:3a:xx:xx), Dst: LiteonTe_25:b6:b0 (d0:df:9a:25:xx:xx)
Internet Protocol Version 4, Src: 192.168.230.1, Dst: 192.168.230.49
User Datagram Protocol, Src Port: 5355, Dst Port: 59154
Link-local Multicast Name Resolution (response)
    Transaction ID: 0x1231
    Flags: 0x8000 Standard query response, No error
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .0.. .... .... = Conflict: The name is considered unique
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Tentative: Not tentative
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 0
    Queries
        ENPA: type A, class IN
    Answers
        ENPA: type A, class IN, addr 192.168.230.1
 

Изменено пользователем enpa
  • Спасибо 1
  • 0
Опубликовано
34 минуты назад, r13 сказал:

Добрый день, предлагаю добавить LLMNR в прошивку.

1. Во всех актуальных версиях Windows он включен по умолчанию, при этом имеет больший приоритет чем разрешение имен через NetBIOS протокол(DNS -->  LLMNR --> WINS/NetBIOS --> LMHOST)

2. При отключении протокола smb1 в актуальных версиях window также удаляется и протокол netbios (через удаление/установку компонентов windows)

3 На последней версии Windows 10 1709 smbv1/netbios отключены по умолчанию, так же при обновлении на эту версию со старых этот компонент удаляется автоматически при не использовании

https://support.microsoft.com/ru-ru/help/4034314/smbv1-is-not-installed-windows-10-and-windows-server-version-1709

Поэтому считаю возможным рассмотреть внедрение в кинетике более актуального в среде windows протокола разрешения имен LLMNR

Ок, подумаем.

  • Спасибо 4
  • 0
Опубликовано (изменено)

@r13 поддерживаю инициативу. @ndm @Le ecureuil не помешала бы поддержка LLMNR, т.к. в свое время столкнулся лично с проблемой работы smb1\netbios в Windows 10.

и пришлось кардинально решать вопрос через правку реестра. Если бы была поддержка, думаю, не пришлось бы "капать" в глубь реестра Windows. 

Изменено пользователем enpa
  • Лайк 2
  • 0
Опубликовано (изменено)

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

Плюсанул.

Изменено пользователем MDP
  • 0
Опубликовано
12 минуты назад, MDP сказал:

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

Плюсанул.

Если правильно понял, эта штука с обозревателем никак не связана, она изначально однораговая.

  • 0
Опубликовано
2 часа назад, r13 сказал:

Добрый день, предлагаю добавить LLMNR в прошивку.

Плюс - есть готовая реализация демона, склонировал, скомпилировал  - бинарник x86 занимает 29 килобайт. Висит тихо в памяти, выдает информацию. Минус - можно организовать MITM. Может, сперва в entware это?..

  • 0
Опубликовано (изменено)
37 минут назад, vadimbn сказал:

Плюс - есть готовая реализация демона, склонировал, скомпилировал  - бинарник x86 занимает 29 килобайт. Висит тихо в памяти, выдает информацию. Минус - можно организовать MITM. Может, сперва в entware это?..

Ну в общем то по MITM там паритет с NetBIOS который уже есть, так что не критично.

Если пугает MITM то надо DNS использовать.

Изменено пользователем r13
  • 0
Опубликовано (изменено)
34 минуты назад, MDP сказал:

ак как в сети может быть и другой обозреватель.

С обозревателем оно не связано, это отдельный протокол, похож на DNS, но занимает другой порт, UDP 5355. Висит тихо демон на этом порту, при широковещательном запросе шлет информацию о хосте вида "host_name IN A IP.address "

Изменено пользователем vadimbn
  • 0
Опубликовано
52 минуты назад, r13 сказал:

Если пугает MITM то надо DNS использовать

а вот ответ dns не подделать и не разрешить на mitm, еще и ttl наподольше предложить можно.

  • 0
Опубликовано (изменено)
6 часов назад, r13 сказал:

Добрый день, предлагаю добавить LLMNR в прошивку.

1. Во всех актуальных версиях Windows он включен по умолчанию, при этом имеет больший приоритет чем разрешение имен через NetBIOS протокол(DNS -->  LLMNR --> WINS/NetBIOS --> LMHOST)

2. При отключении протокола smb1 в актуальных версиях windows также удаляется и протокол netbios (через удаление/установку компонентов windows)

3 На последней версии Windows 10 1709 smbv1/netbios отключены по умолчанию, так же при обновлении на эту версию со старых этот компонент удаляется автоматически при не использовании

https://support.microsoft.com/ru-ru/help/4034314/smbv1-is-not-installed-windows-10-and-windows-server-version-1709

Поэтому считаю возможным рассмотреть внедрение в кинетике более актуального в среде windows протокола разрешения имен LLMNR

Зачем???

Цитата

LLMNR (UDP/5355, Link-Local Multicast Name Resolution — механизм широковещательного разрешения имен) – протокол присутствует во всех версиях Windows, начиная с Vista и позволяет IPv6 и IPv4 клиентам за счет широковещательных запросов в локальном сегменте сети L2 разрешать имена соседних компьютеров без использования DNS сервера. Этот протокол также автоматически используется при недоступности DNS. Соответственно, при работающих DNS-серверах в домене, этот протокол абсолютно не нужен.

Протокол NetBIOS over TCP/IP или NBT-NS (UDP/137,138;TCP/139) – является широковещательным протоколом-предшественником LLMNR и используется в локальной сети  для публикации и поиска ресурсов. Поддержка NetBIOS over TCP/IP по умолчанию включена для всех интерфейсов во всех ОС Windows.

Для чего Windows знать о соседних ПК это понятно, вопрос зачем это для роутера ?

Второе ранее уже упоминалось

Цитата

https://technet.microsoft.com/ru-ru/library/security/ms11-030.aspx?f=255&MSPPError=-2147217396

2011 г. | Дата обновления: 13 марта 2012 г.

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

Это обновление для системы безопасности имеет уровень серьезности "критический" для всех поддерживаемых выпусков Windows Vista, Windows Server 2008, Windows 7 и Windows Server 2008 R2 и уровень серьезности "существенный" для всех поддерживаемых выпусков Windows XP и Windows Server 2003. Дополнительные сведения см. в подразделе Подвержены и не подвержены уязвимости этого раздела.

2013г. https://xakep.ru/2013/12/11/easy-hack-173/

LLMNR (Link-local Multicast Name Resolution) — это протокол от Microsoft, который используется для того, чтобы резолвить имена хостов, находящихся в той же подсети, что и хостпосылающий пакет. Как говорит M$, это может быть очень полезно в сетях, где применение DNS-сервера либо неудобно, либо невозможно. Например, во «временных» сетях, типа Wi-Fi-точек.

На самом деле LLMNR — это, по сути, аналог NetBIOS Name Service. Но есть пара интересных для нас моментов. Во-первых, это поддержка и IPv6, и IPv4, что отсутствует в NetBIOS. Во-вторых, это теоретическая поддержка длинных имен (более 15 символов, которые ограничивали NB NS). В-третьих, это совсем другой протокол. Точнее, LLMNR базируется на DNS-протоколе UDP и имеет почти такие же пакеты по формату. Но изменен порт — 5355. В-четвертых, LLMNR располагается следом за DNS в общесистемном резолве имен хостов (файл hosts, DNS, LLMNR, NB NS). Поддержка LLMNR есть начиная с висты (более поздние версии также поддерживают TCP-версию протокола).

Интересно еще, как LLMNR работает. LLMNR-запросы посылаются на специальные групповые адреса (Multicast-address). Для IPv4 это 224.0.0.252 и MAC — 01-00-5E-00-00-FC. Для IPv6 — FF02::1:3 и MAC — 33-33-00-01-00-03. То есть все виндовые хосты мониторят такие пакеты. Если хост в запросе находит свое имя, то он уже отвечает на конкретный порт и IP-адрес хоста, запрашивающего имя. Хотелось бы еще отметить, что, к сожалению, кеш LLMNR отделен от DNS’овского, так что здесь нам ничего не светит. И к тому же LLMNR работает только для простых имен хостов (то есть если в имени резолвируемого хоста отсутствуют точки).

2016г. http://www.securitylab.ru/analytics/480589.php

Подобную атаку можно осуществить и на протокол LLMNR, который используется в Windows 7 и более поздних версиях.

LLMNR (многоадресный запрос wpad)

Мы уже имеем для домашних пользователей

 663 nobody    1348 S    /usr/sbin/nlldo -u nobody
 664 nobody    1352 S    /usr/sbin/nllda -I Bridge0 -p Home -M хх:хх:хх:хх:хх:хх -x 18 -n MyK -D ZyXEL K

если еще для Home можно отключить то nlldo - нет.

Этот протокол Windows, а не роутера.

Изменено пользователем vasek00
  • 0
Опубликовано (изменено)

@vasek00 вместо выводимого из эксплуатации микрософтом netbios, чтобы роутер продолжал отзываться по имени с windows машин

Изменено пользователем r13
  • Лайк 1
  • 0
Опубликовано
1 час назад, vasek00 сказал:

Для чего Windows знать о соседних ПК это понятно, вопрос зачем это для роутера ?

Роутеру это незачем, он просто будет выдавать о себе информацию в локальную сеть по этому протоколу. Это дополнительная возможность для Windows-машин определить IP-адрес роутера по имени. Демон небольшой, памяти и процессор практически не потребляет, если исключить атаки извне. Почему нет? Сделать, чтобы можно было включать по желанию, да и пусть себе будет.

  • 0
Опубликовано
1 час назад, r13 сказал:

@vasek00 вместо выводимого из эксплуатации микрософтом netbios, чтобы роутер продолжал отзываться по имени с windows машин

a *unix там не чего не выводит? А как же быть с теми у кого дома нет windows только планшет/ТВ/смартфон? Может разрешить формировать файл host на роутере?

41 минуту назад, vadimbn сказал:

Это дополнительная возможность для Windows-машин определить IP-адрес роутера по имени.

Ну что тут сказать.

  • Лайк 1
  • 0
Опубликовано
20 минут назад, vasek00 сказал:

a *unix там не чего не выводит?

Там - это где? LLMNR изначально протокол windows, используется начиная с Windows Vista. Unix его не использует. Но есть демон, реализующий функции этого протокола под Unix. Сидит на порту 5355 и слушает широковещательные запросы. Если компьютеру с ОС Windows не удалось определить IP по имени ни в файле hosts, ни запросом к DNS-серверу, он шлет широковещательный запрос "Компьютер Витя есть в этой сети? Ищу компьютер Витя!". Буде компьютер Витя в сети, и если у него работает служба LLMNR, он отзывается "Да, я, Витя тут есть, мой IP такой-то". "Ну круто", отвечает ему запрашивающий компьютер, "тебя-то мне и надо... Я твой адрес запомню, на будущее, а ты мне сейчас выдай-ка файл по SMB-протоколу". Если нет windows-машин в сети, демон можно не включать, другие системы этот протокол, AFAIK, не используют.

  • 0
Опубликовано
8 часов назад, vadimbn сказал:

Там - это где? LLMNR изначально протокол windows, используется начиная с Windows Vista. Unix его не использует. Но есть демон, реализующий функции этого протокола под Unix. Сидит на порту 5355 и слушает широковещательные запросы. Если компьютеру с ОС Windows не удалось определить IP по имени ни в файле hosts, ни запросом к DNS-серверу .... Если нет windows-машин в сети, демон можно не включать, другие системы этот протокол, AFAIK, не используют.

Наверное надо внимательнее прочитать пост выше 31.10.2017 20:23

Речь про то что этот протокол разработала Windows для своих сетей (один, два, три и т.д. ПК).

Цитата

Если компьютеру с ОС Windows не удалось определить IP по имени ни в файле hosts, ни запросом к DNS-серверу

Повторюсь Задайте себе вопрос - он кого определяет соседа компьютера и для чего он его определяет ?

 

Может лучше подумать над SMB Over TCP/IP  или полноценной схемы SMB сервер (роутер) и SMB client. Реализация SMB клиента в настоящие время есть для любой платформы.

  • 0
Опубликовано (изменено)
23 минуты назад, vasek00 сказал:

Наверное надо внимательнее прочитать пост выше

Читал, несколько раз. Вы, извиняюсь, так умеете выражать свои мысли, что непонятно, что вы имеете в виду (или мозги у меня не той системы). Да, протокол разработан Microsoft для Windows. А еще Miсrosoft в соавторстве разработала и SMB-протокол, и CIFS, активно поддержала и дополнила PPTP, и много чего еще, что используется другими. Да, это для одноранговых сетей.

 

23 минуты назад, vasek00 сказал:

Задайте себе вопрос - он кого определяет соседа компьютера и для чего он его определяет ?

Определяет IP компьютера по имени. Если служба LLMNR на компьютере не будет запущена, никто в сети по этому протоколу про него не узнает.

 

23 минуты назад, vasek00 сказал:

Может лучше подумать над SMB Over TCP/IP  или полноценной схемы SMB сервер (роутер) и SMB client.

Я за... Какова будет цена этого, какие усилия будут затрачены, сможет ли это все взлететь на роутерах с малым количеством ОЗУ?

Изменено пользователем vadimbn
  • 0
Опубликовано
48 минут назад, vadimbn сказал:

Читал, несколько раз. Вы, извиняюсь, так умеете выражать свои мысли, что непонятно, что вы имеете в виду (или мозги у меня не той системы). Да, протокол разработан Microsoft для Windows. А еще Miсrosoft в соавторстве разработала и SMB-протокол, и CIFS, активно поддержала и дополнила PPTP, и много чего еще, что используется другими. Да, это для одноранговых сетей.

Определяет IP компьютера по имени. Если служба LLMNR на компьютере не будет запущена, никто в сети по этому протоколу про него не узнает.

Я за... Какова будет цена этого, какие усилия будут затрачены, сможет ли это все взлететь на роутерах с малым количеством ОЗУ?

По моему все понятно

На самом деле LLMNR — это, по сути, аналог NetBIOS Name Service. Но есть пара интересных для нас моментов. Во-первых, это поддержка и IPv6, и IPv4, что отсутствует в NetBIOS. Во-вторых, это теоретическая поддержка длинных имен (более 15 символов, которые ограничивали NB NS). В-третьих, это совсем другой протокол. Точнее, LLMNR базируется на DNS-протоколе UDP и имеет почти такие же пакеты по формату. Но изменен порт — 5355. В-четвертых, LLMNR располагается следом за DNS в общесистемном резолве имен хостов (файл hosts, DNS, LLMNR, NB NS). Поддержка LLMNR есть начиная с висты (более поздние версии также поддерживают TCP-версию протокола).

Вот именно что Определяет IP компьютера по имени

Берем роутер 64/16 все влезает, что-то у других.

  • 0
Опубликовано

LLMNR починили.

Оказывается, он всегда был в новой версии nqE, но из-за ошибки в коде он слушал loopback-интерфейс и не отвечал на запросы.

Начиная с этого draft винда должна нормально видеть Keenetic по LLMNR (проверял на windows 7).

Одновременно приделан фильтр, чтобы LLMNR-запросы, приходящие или хотящие уйти в public-интерфейс дропались.

  • Спасибо 1
  • Лайк 2
Гость
Эта тема закрыта для публикации ответов.
  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.