Как стать автором
Обновить

Комментарии 9

Вообще-то, в домене такие штуки работать не будут, потому что есть dns suffix. При доступе по простому имени, вместо NETBIOS запроса к NONAMESERVER будет DNS запрос к NONAMESERVER.domain.com. Собственно, даже мой провайде выдаёт dns suffix по DHCP. Ну и вообще в домене NetBIOS нет, а домашние пользователи по NetBIOS в интернет не ходят. Это раз.

Статья об особенностях работы очень старого сетевого протокола, при проектировании которого не учитывалась безопасность несёт тайное послание Windows — дырявый, Linux — безопасный. Linux поддерживающий NetBIOS уязвим ничуть не меньше. Это два.
Извините, но не смог уместить ответ в одном комментарии:
Во первых, Вы недостаточно ознакомились с текстом, либо я недостаточно полно раскрыл данную тему.
Данный метод атаки будет работать только, если жертва и атакующий находятся в ОДНОЙ ПОДСЕТИ и при условии того, что на в системе жертвы разрешен Netbios Over IP
Во вторых, Вы не знакомы с тем, как и каким образом Windows осуществляет резолвинг.
Сделал пример для Вас:

В данном примере, я пытался сделать пинг хоста google1.com
И, как Вы можете видеть:
1)Попытка резолвинга с помощью DNS qeury
2)Попытка завершилась неудачно
3)3 широковещательных запроса NBNS, т.е. попытка разрешить имя с помощью протокола NetBios
Две семёрки x64, дома и на работе. Рабочая в домен, уровень домена 2003, уровень леса 2003. Контроллёры 2008 R2, особых политик безопасности нет.

Дома, несмотря на DNS суфикс действительно есть и NetBIOS запрос. Проверил вашим Wireshark. Забавная кстати программка, показала броадкасты провайдеровских цисок.

На работе всё как я и говорил, после DNS никакого NetBIOS.
>Проверил вашим Wireshark. Забавная кстати программка, показала броадкасты >провайдеровских цисок.

Уважаемый, adontz, wireshark — это лучший анализатор из когда-либо созданных на данное время. :)
Можно взглянуть на результат, полученный на рабочей машине? Желательно в виде pcap файла
Вы путаете FQDN и Netbios name
Последовательность разрешения имен такая:
Кэш/hosts
DNS — по FQDN
NetBIOS Name Cache — по 16символьному имени NetBios
WINS
Broadcast
lmhosts
То, что Вы описали — не MITM. MITM подвержены любые протоколы, не использующие PKI (ожидаем статей «HTTP подвержен MITM», «FTP подвержен MITM», «DNS подвержен MITM», «SMTP подвержен MITM», «POP3 подвержен MITM», да чего уж там — «TCP/IP подвержен MITM»).

Что же до описанной атаки — Вам совершенно верно указали на то, что в доманах атака не выполнима. Да и IPsec никто не отменял. Непонятно, почему Вы всего лишь вскользь упомянули ARP poisoning (в контектсе блокирования DNS) при том, что это гораздо более опасно, ибо ARP является stateless протоколом (то есть «отравить» кеш жертвы можно даже не дожидаясь APR-запроса), а следовательно можно устроить MITM на любой из вышеперечисленных (и не только) протоколов.
1)Вам совершенно верно указали на то, что в доманах атака не выполнима -> не правильно указали, смотрите ответ на его комментарий
2)Вы всего лишь вскользь упомянули ARP poisoning — а целью и не было упомянуть все виды атак :)
3)То, что Вы описали — не MITM -> Да, извините, это спуфинг.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории