Включить автоматическую аутентификацию с помощью ntlm. Процедура аутентификации Windows. Ограничения протокола NTLM

Исследователи годами рассказывают на конференциях о том, что технологии единого входа (Single Sign-on) небезопасны. Такую систему единой аутентификации для всего и сразу уже давно применяет Microsoft, а специалисты по информационной безопасности еще в 1997 году говорили о том, что это не слишком хорошая идея. В очередной раз уязвимость единого входа в целом и в случае работы с SMB-ресурсами в частности продемонстрировал российский исследователь ValdikSS. Он описал способ, который позволяет скомпрометировать Microsoft Account жертвы, деанонимизировать пользователей Microsoft и узнать данные о VPN.

По сути, для успешной реализации атаки злоумышленнику достаточно замаскировать ссылку на собственный SMB-ресурс (сетевые ресурсы: файлы и папки, принтеры и прочее), к примеру, под картинку и заставить жертву ее открыть. Атака работает на всех современных ОС, включая Windows 10 с последними обновлениями. Причем об этих проблемах с NTLM-аутентификацией говорили не только в 1997 году, о них вспоминают регулярно. Так, этот вопрос поднимали (PDF) в прошлом году на конференции BlackHat. К сожалению, от частых упоминаний ничего не меняется.

На «Хабрахабре» пользователь ValdikSS рассказал о том, как можно эксплуатировать этот «баг из 90-х» в наши дни. Исследователь пишет:

«Как только вы пытаетесь открыть ссылку на SMB-ресурс в стандартном браузере (Internet Explorer, Edge) или любом приложении, работающем через стандартные вызовы API Windows или использующим Internet Explorer в качестве движка для отображения HTML (Outlook, проводник Windows), SMB-ресурс сразу получает данные вашей учетной записи еще до того, как вы увидите диалог ввода имени и пароля. Атакующему достаточно, например, добавить ссылку на картинку с SMB-сервера на страницу сайта, или отправить вам письмо, которое достаточно будет просто открыть, и - бум! - данные вашей учетной записи в руках злоумышленника».

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

«Из названия домена обычно несложно понять, к какой организации относится учетная запись, а дальше, в случае успешного подбора пароля, можно попробовать аутентифицироваться на корпоративных ресурсах, доступных из интернета (почта, VPN).

Но пароль не всегда необходимо подбирать. Если вы наперед знаете какой-то ресурс, куда можно входить с использованием NTLM-аутентификации, вы можете в режиме реального времени, как только клиент подключится к вашему SMB-серверу, проксировать запросы от клиента к удаленному серверу и от сервера к клиенту, и успешно на нем аутентифицируетесь!», - объясняет ValdikSS.

Ситуация также усугубляется тем, что в современные ОС Microsoft активно продвигают использование единого Microsoft Account, буквально вынуждая пользователя создать его. Для пользователей Microsoft Account подобные атаки могут быть опасны вдвойне, причем не только для организаций, но и для частных лиц. Дело в том, что в случае атаки на SMB-сервер злоумышленника будут переданы данные, которые, по сути, скомпрометируют Microsoft Account жертвы, а к нему привязано множество сервисов (Skype, Xbox, OneDrive, Office 360, MSN, Bing, Azure и так далее).

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

При этом ValdikSS описал ряд способов эксплуатации проблем с NTLM-аутентификацией. Помимо совсем очевидных вещей, исследователь предложил использовать брешь для деанонимизации пользователей:

«Эксплуатация с целью деанонимизации - поинтересней. Учетка будет отправляться со страниц сайта, если жертва использует Internet Explorer, или при клике внутри письма, в случае с Outlook. Почти все веб-интерфейсы почтовых служб фильтруют картинки со схемой file:// при выводе письма (схема file:// является аналогом схемы \\), но не Яндекс, который не считает это своей уязвимостью (что, в общем-то, корректно). Деанонимизация с использованием почты более опасна, т.к. дает связь не только IP-адреса с аккаунтом Windows, но и с почтой.

Chrome схема file:// тоже работает, но только из адресной строки. Загрузить что-либо с SMB картинкой или при нажатии на ссылку не получится. Так как Chrome гораздо популярней Internet Explorer, придется применять социальную инженерию.

Можно воровать аккаунты себе во благо. Некоторые VPN-провайдеры используют одинаковые логины и пароли как для входа в аккаунт, так и для VPN-аутентификации. Принадлежность аккаунта к тому или иному сервису можно определить по IP-адресу входящего подключения пользователя. А если вам достался Microsoft Account, и вы нашли пароль из хеша, то поздравляю - у вас есть доступ к файлам в облаке OneDrive, почте Outlook, аккаунту Skype, если он привязан к Microsoft-аккаунту, и еще куче всего».

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

192.168.0.0/16
169.254.0.0/16
172.16.0.0/12
10.0.0.0/8
fd00::/8
fe80::/10

Также в комментариях к статье пользователи предложили следующий метод:

Windows Registry Editor Version 5.00

"RestrictReceivingNTLMTraffic"=dword:00000002
"RestrictSendingNTLMTraffic"=dword:00000002

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

11.02.2011 Жан де Клерк

Любому администратору Windows, разумеется, не раз приходилось иметь дело с двумя основными протоколами аутентификации в среде Windows: Kerberos и NTLM. Данная статья посвящена тому, как Kerberos и NTLM поддерживаются в системах Windows 7 и Windows Server 2008 R2. Но для начала я хотел бы остановиться на ключевых различиях между этими протоколами.

Разработчики Microsoft впервые реализовали протокол Kerberos в системе Windows 2000. Протокол NTLM вошел в употребление гораздо раньше, во времена Windows NT. Kerberos представляет собой протокол аутентификации, базирующийся на концепции доверенной третьей стороны trusted third party (TTP), тогда как в основу протокола NTLM положен механизм «запрос-ответ» (challenge/response). Более подробно различия между двумя протоколами описаны в таблице .

При обмене данными в ходе аутентификации с использованием протокола NTLM серверный ресурс (например, файл-сервер) генерирует запрос, который направляется клиенту. Клиент формирует NTLM-ответ, включающий хеш пароля пользователя, а сервер проверяет правильность этого ответа. Если клиент использует локальную учетную запись, сервер проверяет ответ пользователя с помощью хеша пароля пользователя, который хранится в локальной базе данных диспетчера учетных записей безопасности Security Account Manager (SAM). Если же клиент применяет доменную учетную запись, сервер передает ответ для проверки контроллеру домена, ибо только контроллеры доменов хранят в своих базах данных Active Directory (AD) копии хешей пользовательских паролей.

В системе Windows Kerberos доверенной третьей стороной является контроллер домена Windows 2000 или более поздней версии, на котором размещается служба центра распространения ключей Kerberos Key Distribution Center (KDC). Центр KDC облегчает процедуру аутентификации между оснащенным средствами Kerberos клиентом и сервером. Служба KDC автоматически устанавливается как компонент системы AD и состоит из двух подсистем: службы аутентификации Authentication Service (AS) и службы предоставления билетов Ticket-Granting Service (TGS).

Когда пользователь регистрируется в домене Windows с использованием протокола Kerberos, клиент Windows первым делом проверяет подлинность пользователя на контроллере домена с помощью пользовательского пароля. В то же время клиент запрашивает билет на выдачу билета Ticket Grant Ticket (TGT) в службу аутентификации. TGT можно рассматривать как временный пароль (по умолчанию время его жизни составляет 8 часов), который будет заменять пароль пользователя в последующих запросах на аутентификацию. Когда пользователю нужно будет обратиться к серверному ресурсу, клиент представит TGT на выдачу TGT для проверки подлинности на серверном ресурсе. Имейте в виду, что, в отличие от NTLM, протокол Kerberos не используется для локальной аутентификации в диспетчере учетных записей безопасности Windows; его сфера применения ограничивается доменной аутентификацией на контроллере домена.

Kerberos - стандартный протокол аутентификации в системе Windows 2000 и в более новых версиях Microsoft. В этих операционных системах протокол аутентификации определяется с использованием механизма согласования. Если предлагаемый по умолчанию протокол Kerberos не подходит или не поддерживается одним из клиентских либо серверных компонентов, принимающих участие в аутентификации, Windows переходит на использование NTLM.

Почему Kerberos?

Kerberos более эффективен, нежели NTLM, и тому есть несколько причин. При использовании протокола Kerberos хеш пользовательского пароля экспонируется намного реже, чем в случае применения NTLM. Хеш пароля экспонируется только в том случае, когда пользователь запрашивает TGT - в сущности, один раз каждые восемь часов. С другой стороны, в случае применения NTLM хеш пароля экспонируется всякий раз, когда клиент использует NTLM для аутентификации на сервере. В этом состоит важное преимущество протокола Kerberos перед протоколом NTLM; дело в том, что существуют специальные инструменты, проверяющие сетевой трафик на наличие хешей паролей. Эти инструменты захватывают обнаруженные хеши и методом подбора восстанавливают на их основе пароли пользователей.

Еще одно достоинство Kerberos состоит в том, что этот протокол предусматривает использование отметок времени для защиты от атак с повторной передачей пакетов. Вот почему так важно наличие службы синхронизации времени, безупречно функционирующей в Kerberos-центрической среде Windows. В Windows 2000 и более новых версиях системы службы времени работают без предварительной настройки. Если компьютерные часы на разных компьютерах не синхронизированы, это может обернуться дополнительным трафиком в процессе аутентификации по стандарту Kerberos или же - в худшем случае - такая ситуация может вызвать ошибку в процессе аутентификации.

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

Служба может обращаться к удаленным ресурсам от имени пользователя с помощью механизма делегирования аутентификации. Иными словами, пользователь может предоставлять системе-посреднику право подтвердить от своего имени свою (пользователя) подлинность на сервере приложений. В результате сервер приложений получает возможность принимать решения по авторизации не на базе идентичности системы-посредника, а основываясь на идентичности пользователя. Функция делегирования проверки подлинности весьма полезна в многоуровневых приложениях, таких как доступ к базам данных с помощью внешнего интерфейса на базе Web.

Наконец, надо сказать, что, хотя специалисты Microsoft проделали большую работу по модернизации протокола NTLM, а именно создали версию NTLMv2, которая поддерживается в среде NT4 SP4 и более новых версиях, в продукте Microsoft Kerberos реализовано большее число современных алгоритмов шифрования. Я расскажу об этом подробнее в разделе, посвященном средствам шифрования протокола Kerberos

Ограничения протокола NTLM

Преимущества аутентификации средствами протокола Kerberos сомнения не вызывают. Но даже в среде AD Server 2008 Windows часто использует протокол NTLM, например, когда вы подключаетесь к системе Windows, выпущенной до появления Windows 2000, или при подключении к общедоступному ресурсу с помощью команды net use и IP-адреса (а не имени NetBIOS). Кроме того, приложения, у которых имена участников службы service principal names (SPN) не настроены должным образом, будут по-прежнему использовать протокол NTLM.

Чтобы узнать, каким протоколом - NTLM или Kerberos - вы пользуетесь в данный момент, можете визуализировать трафик NTLM с помощью утилиты netmon или другого трассировщика сети; альтернативный вариант - проверить содержимое кэша билетов Kerberos с помощью инструмента klist (который входит в комплекты поставки Windows 7 и Server 2008). В системах Windows 7 и Server 2008 специалисты Microsoft реализовали новые групповые политики, с помощью которых можно отслеживать, а также блокировать использование протокола NTLM вашими пользователями и приложениями. Всего таких политик три: одна для входящего трафика NTLM (для отслеживания и блокировки на уровне сервера), другая для исходящего трафика NTLM (для отслеживания и блокировки на уровне клиента) и третья для доменного трафика (для отслеживания и блокировки на уровне контроллера домена). Они размещаются в контейнере Security Options Group Policy Object (CPO), попасть в который можно, последовательно выбирая пункты Computer Configuration, Windows Settings, Security Settings, Local Policies (см. экран 1). Все они начинаются с элемента Network security: Restrict NTLM:.

Каждая настройка политики имеет параметры audit и block. Когда вы включаете функцию аудита NTLM, программа создает записи журнала событий с исходными данными NTLM и числами 8001, 8002, 8003 и 8004. Журнальные записи хранятся в контейнере Operational с путем доступа Event Viewer (Local), Applications And Services Logs, Microsoft, Windows, NTLM. Я рекомендую для начала провести аудит NTLM в тестовой среде и позаботиться о том, чтобы там были должным образом представлены все ваши приложения. Если начать произвольно блокировать использование протокола, скорее всего, некоторые приложения функционировать не будут. Чтобы не допустить потери событий, следует перед началом тестирования средств аудита NTLM установить решение для сбора событий аудита; можете воспользоваться встроенной службой Windows Event Collector, средствами Event Subscriptions или решением от независимого поставщика. Кроме того, я рекомендую первым делом начать мониторинг NTLM на серверах. Вы можете подключить клиенты для проведения детального анализа, после того как станет очевидно, что сервер использует протокол NTLM. Уяснив, какие приложения используют NTLM, вы можете разработать стратегию блокировки NTLM. Эта стратегия может включать в себя стратегию исключений для устаревших приложений, которые не могут быть переписаны или перенастроены и которые всегда будут требовать применения NTLM.

К сожалению, упомянутые настройки NTLM нельзя применять на старых системах Windows. Однако эти системы допускают возможность управления версиями протокола NTLM. Вы можете, например, отключить фрагмент LM протокола аутентификации NTLM (поскольку этот фрагмент слаб по самой своей природе) или задать принудительное применение протокола NTLMv2. Для этого следует воспользоваться настройкой Network Security: LAN Manager Authentication Level GPO, которая размещается в контейнере Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options GPO (см. экран 2).

Средства шифрования Kerberos

Криптографические протоколы, используемые протоколами аутентификации, играют важную роль в обеспечении безопасности последних. Как я уже отмечал, в этой области показатели Kerberos выше, чем у протокола NTLM. Алгоритм шифрования RC4 был впервые реализован в протоколе Windows Kerberos в версии Windows 2000 и по сей день поддерживается в системах Server 2008, а также Windows 7 (точнее говоря, поддерживается его версия RC4_HMAC_MD5). В системах Server 2008, Windows Vista и более новых версиях разработчики Microsoft добавили средства поддержки шифрования по стандарту Advanced Encryption Standard, AES, а системы Windows 7 и Server 2008 R2 поддерживают типы шифрования Kerberos AES (AES128_HMAC_SHA1 и AES256_HMAC_SHA1) без предварительной настройки. AES - более новый и мощный алгоритм шифрования, нежели DES. Логика Kerberos на контроллерах доменов перейдет на стандарт шифрования AES, когда вы модернизируете домен AD до уровня Windows 2008 Domain Functional Level (DFL).

В системах Windows 7 и Server 2008 R2 типы шифрования DES для протокола аутентификации Kerberos по умолчанию отключены. Из-за этого могут возникнуть проблемы совместимости, если одно из устаревших приложений жестко закодировано на шифрование только по стандарту DES или если учетная запись Windows, выполняющая ту или иную службу (учетная запись этой службы), настроена на использование только DES-шифрования. Эти службы или приложения выйдут из строя, если вы не сможете перенастроить соответствующую службу либо приложение на поддержку другого типа шифрования (RC4 или AES) либо не восстановите поддержку стандарта DES.

Чтобы выяснить, имеются ли у вас приложения либо службы, закодированные на шифрование исключительно по стандарту DES, можно запустить сетевой трассировщик при старте соответствующего приложения или службы и проверить содержимое полей Etype в заголовках аутентификации Kerberos. Чтобы определить, настроена ли учетная запись пользователя либо компьютера AD или учетная запись компьютера для применения исключительно типов шифрования DES, нужно проверить, выбран ли на вкладке Account свойств объекта параметр Use Kerberos DES encryption types for this account. К этим свойствам можно обратиться из оснастки AD Users and Computers консоли MMC.

Если вы выполните упомянутые выше проверки и окажется, что у вас возникла эта проблема, можете активировать DES-шифрование для аутентификации с помощью Kerberos на компьютерах, функционирующих под Windows 7 или Server 2008 R2, с помощью GPO настройки Network security: настройте типы шифрования, совместимые со стандартом Kerberos; эти настройки расположены в контейнере Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options GPO.

Итак, из двух протоколов аутентификации Windows предпочтительным является протокол Kerberos. Администраторам следует всегда настаивать на том, чтобы пользователи и приложения применяли именно Kerberos, а не NTLM. Новые ограничения по использованию NTLM, реализованные в системах Windows 7 и Server 2008 R2, открывают перед нами отличную возможность для достижения этой цели.

Жан де Клерк ([email protected]) - сотрудник Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft

Аутентификация в системах Windows Server 2008 R2 и Windows 7

В операционной системе Windows 7 реализовано новое поколение технологий безопасности для рабочего стола и одна из них аутентификация и авторизация. Часть технологий направлена на укрепление общей инфраструктуры Windows, а остальные на оказание помощи в управлении системой и пользовательскими данными.

Прежде чем устанавливать в Windows 7 эффективные меры безопасности, например, для совместного пользования файлами и папками, важно понимать используемые во время настройки безопасности типы учетных записей пользователей, и как сетевой протокол аутентифицирует и авторизует вход пользователей в систему.

Аутентификация - это процесс, используемый для подтверждения личности пользователя, при обращении его к компьютерной системе или дополнительным системным ресурсам. В частных и государственных компьютерных сетях (включая Интернет) наиболее часто для аутентификации предполагается проверка учетных данных пользователя; то есть, имя пользователя и пароль. Однако для типов критических транзакций, например обработка платежей, проверки подлинности имени пользователя и пароля не достаточно, так как пароли могут быть украдены или взломаны. По этой причине, основная часть интернет-бизнеса, а также многие другие сделки теперь используют цифровые сертификаты, которые выдаются и проверяются центром сертификации.

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

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

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

Процесс авторизации и аутентификации.

Для получения доступа к файлам в сети пользователи для проверки их личности должны проходить аутентификацию. Это делается во время процесса входа в сеть. Операционная система Windows 7 для входа в сеть имеет следующие методы аутентификации:

Протокол Kerberos версии 5: Основной метод аутентификации клиентов и серверов под управлением операционных систем Microsoft Windows. Он используется для проверки подлинности учетных записей пользователей и учетных записей компьютеров.
Windows NT LAN Manager (NTLM): используется для обратной совместимости с операционными системами более старыми, чем Windows 2000 и некоторых приложений. Он менее гибок, эффективен и безопасен, чем протокол Kerberos версии 5.
Сопоставление сертификатов: обычно используется для проверки подлинности при входе в сочетании со смарт-картой. Сертификат, записанный на смарт-карте, связан с учетной записью пользователя. Для чтения смарт-карт и аутентификации пользователя используется считыватель смарт-карт.

Новые функции аутентификации в Windows 7.

Целый ряд улучшений, связанных с процессами входа и проверки подлинности пользователя был добавлен еще в Windows Vista ®. Эти усовершенствования увеличили базовый набор функции проверки подлинности, чтобы помогло обеспечить лучшую безопасность и управляемость. В Windows 7 Microsoft продолжает начатые в Windows Vista усовершенствования, предоставляя следующие новые функции аутентификации:

Смарт-карты
Биометрия
Интеграция личности в Интернете.

Смарт-карты.

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

Смарт-карты Plug and Play
Личные удостоверения проверки (PIV), стандарт национального института стандартов и технологий США (NIST)
Поддержка для входа смарт-карты Kerberos.
Шифрование дисков BitLocker
Документы и электронная почта
Использование с бизнес-приложениями.

Биометрия.

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

До сих пор в Windows не было стандартной поддержки биометрических устройств. Чтобы решить эту проблему, Windows 7 вводит Windows Biometric Framework (WBF). WBF предоставляет новый набор компонентов, поддерживающий снятие отпечатка пальца с помощью биометрические устройства. Эти компоненты увеличивают безопасность пользователей.

Windows Biometric Framework упрощает пользователям и администраторам настройку и управление биометрическими устройствами на локальном компьютере или в домене.

Интеграция личности в Интернете.

Управление аккаунтом - стратегия обеспечения безопасности. Для разрешения или запрета проверки подлинности определенных компьютеров или всех компьютеров, которыми вы управляете онлайн, используется Групповая политика.

Интеграцией онлайн идентификации можно управлять политикой группы. Политика, настроенная как: “Сетевая безопасность: Позволить этому компьютеру при запросе идентификации PKU2U использовать ID онлайн”, управляет возможностью ID онлайн подтвердить подлинность этого компьютера при помощи протокола PKU2U. Этот параметр политики не влияет на способность учетных записей доменов или локальных учетных записей пользователей входить на этот компьютер.

Работая в среде Windows каждый системный администратор так или иначе сталкивается с системами аутентификации. Но для многих этот механизм представляет собой черный ящик, когда суть происходящих процессов остается неясна. В тоже время от правильной настройки аутентификации напрямую зависит безопасность сети, поэтому важно не только знать способы и протоколы, но и представлять их работу, хотя бы на общем уровне.

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

Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.

Аутентификация - происходит от английского слова authentication , которое можно перевести как идентификация или проверка подлинности . Это полностью отражает суть процесса - проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
Авторизация - перевод слова authorization означает разрешение , т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.

Чтобы проще представить себе этот процесс проведем простую аналогию. Вы находитесь за границей и вас останавливает полицейский, вы предъявляете свой паспорт. Полицейский проверяет данные в паспорте и сверяет фотографию - это процесс аутентификации. Убедившись, что вы это вы, полицейский просит показать визу - это процесс авторизации, т.е. вашего права здесь находиться.

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

Для аутентификации в компьютерных системах традиционно используется сочетания имени пользователя и некой секретной фразы (пароля), позволяющей определить, что пользователь именно тот, за кого себя выдает. Существуют также и иные способы аутентификации, например, по смарт-карте, но в данной статье мы их касаться не будем.

Локальная аутентификация

Прежде всего начнем с локальной аутентификации, когда пользователь хочет войти непосредственно на рабочую станцию, не входящую в домен. Что происходит после того, как пользователь ввел свой логин и пароль? Сразу после этого введенные данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш, хэширование - это одностороннее криптографическое преобразование, делающее восстановление исходной последовательности невозможным. В открытом виде пароль нигде в системе не хранится и не фигурирует, пользователь - единственный кто его знает.

Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).

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

В случае входа пользователя в домен, для аутентификации используются иные механизмы, прежде всего протокол Kerberos, однако, если одна из сторон не может его использовать, по согласованию могут быть использованы протоколы NTLM и даже устаревший LM. Работу этих протоколов мы будем рассматривать ниже.

LAN Manager (LM)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп , откуда перекочевал в семейство Windows 9.х . Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

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

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

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

NT LAN Manager (NTLM)

Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер - к кому обращаются.

Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера . Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

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

В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше.

В случае получения доступа к третьим ресурсам схема также немного изменяется:

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

Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

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

NTLMv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

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

Как и в NTLM, клиент при обращении к серверу сообщает ему имя пользователя и имя домена, в ответ сервер передает ему случайное число - запрос сервера . В ответ клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента . Наличие метки времени позволяет избежать ситуации, когда атакующий первоначально накапливает перехваченные данные, а потом с их помощью осуществляет атаку.

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Настройки безопасности

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

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера - Конфигурация Windows - Политики безопасности - Локальные политики - Параметры безопасности , в этом разделе найдем политику Сетевая безопасность: уровень проверки подлинности LAN Manager .

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля , которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

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

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel , который может принимать значения от 0 до 5. Рассмотрим их подробнее:

Наименование настройки	Клиентский компьютер	Контроллер домена	Lm Compatibility Level
Отправлять LM- и NTLM-ответы	Клиентские компьютеры используют LM и NTLM аутентификацию , и никогда не используют сеансовую безопасность NTLMv2.		0
Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2	Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	1
Отправлять только NTLM-ответ	Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	2
Отправлять только NTLMv2-ответ		Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	3
Отправлять только NTLMv2-ответ. Отказывать LM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2.	4
Отправлять только NTLMv2-ответ. Отказывать LM и NTLM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM и NTLM, и будут принимать только NTLMv2.	5

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

После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

Мы надеемся, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В мы подробно остановимся на устройстве и работе протокола Kerberos.

Я успешно настроил аутентификацию ntlm. К сожалению, config позволяет получить полуосновную авторизацию. Например, когда я использую черепаху svn1.8.4 (с привилегированным доступом lib), хром или веб-браузеры IE, они успешно завершают работу NTLM, не запрашивая ничего. В файле журнала я вижу пользователей, прошедших проверку подлинности. К сожалению, когда я использую например unconfigured FireFox или Maxthon, этот браузер запрашивает у меня учетные данные. Мне это не нужно, потому что та же ситуация возникает, когда я пытаюсь получить доступ из компьютера без компьютера.

Я использую сервер Windows как контроллер домена, windows7/8 как системный клиент, linux/debian как веб-сервер. Я настроил kerberos из linux do windows AD, winbind для локальной проверки подлинности NTLM и серии apache 2.2. Для клей-аутентификации apache я использую mod_auth_ntlm_winbind.so модуль apache2 и в контексте config/ntlm для поддержки связи с winbind. Это работает правильно, пример для apache:

#defaults for main www directory Options Indexes FollowSymLinks MultiViews AllowOverride None #modified, prevent for any ip access, for future add authless access from specified hosts Order deny,allow deny from all #allow from IP/mask #settings for NTLM auth with winbind helper AuthName "NTLM Authentication" NTLMAuth on NTLMAuthHelper "/usr/bin/ntlm_auth --domain=MY.WINDOWS.DOMAIN --helper-protocol=squid-2.5-ntlmssp" NTLMBasicAuthoritative on AuthType NTLM require valid-user #because ip is default deny satisfy any

Я надеялся, может быть, я могу сделать некоторое перенаправление с использованием переменной apache authtype, а затем добавил в конфигурацию выше перезаписи:

RewriteEngine on RewriteRule ^ /cgi-bin/TestAuth.pl?DollarOne=1&AUTH_TYPE=%{AUTH_TYPE}&REMOTE_USER=%{REMOTE_USER}

И пример скрипта TestAuth.pl как cgi-контент:

#!/usr/bin/perl use strict; use warnings; use Data::Dumper; #easy way for print system variables print "Content-type:text/plain\r\n"; #respectint HTML protocol print "\r\n"; print "Enviroment contains:\r\n"; print "x\r\n"; print Data::Dumper->Dump([\@ARGV,\%ENV],); #prints all script arguments and process variables

К сожалению, во всех случаях, с использованием auth ntlm на основе окон и запроса учетных данных, я всегда вижу, что AUTH_TYPE всегда является NTLM. Тогда нет способа узнать, что делает браузер. В этой ситуации я могу получить доступ от клиентов из домена.

Я попробовал обернуть ntlm hepler strace. К сожалению, я не вижу ничего важного в своем дампе с четырьмя способами, сочетающими успех/неудачу и доступ к IE, вызванный запросом ant FF. Я думаю, что такая же ситуация возникает, когда помощник ntlm аутентифицируется на локальном сервере samba, но я никогда не тестировал это.

Теперь я пытаюсь выполнить некоторую конфигурацию с несколькими типами auth, Basic и NTLM. Сначала я пытаюсь выполнить Basic и отфильтровать это, когда allways fail и перенаправить его на информационную страницу. К сожалению, в настоящее время без успеха с NTLM-микс:(NTLM всегда делается первым.

Тогда у кого-нибудь есть идея, как предотвратить учетные данные? Как отозвать доступ от приглашенных клиентов? Как распознать учетные данные из приглашения или из окна клиента api?

2 ответы

В настоящее время я решил эту проблему переключить NTLM на аутентификацию Kerberos. Все готовые к winbind работают непосредственно под kerberos, потому что я ранее настроил kerberos для winbind с коммуникацией сервера AD. Поскольку kerberos открыт, разработчики предсказывали разные субатентификаторы на конечной точке пользователя. Очень полезным является флаг в модуле apache2.2 kerberos:

KrbMethodNegotiate on KrbMethodK5Passwd off

Это то, что я хочу. Браузер получает кадр krb с атрибутом «Не всплывать пользовательские учетные данные», тогда клиент просто этого не делает. Но если да (какая-то несовместимость?), Модуль сервера Apache должен обнаружить это и должен отозвать аутентификацию.

Используя NTLM от Microsoft, это невозможно, потому что протокол испорчен. Первый кадр NTLM после возврата кода 201 веб-сайта не имеет возможности для добавления атрибута «не запрашивать пользователя для учетных данных». Затем я могу отфильтровать этот кадр после всплывающего окна или знака ключа сеанса ОС. Этот браузер всегда показывает всплывающее окно, когда ключ сеанса OS недоступен.

В конце концов это еще один шанс. Пользователь занимает некоторое время для ввода учетных данных или принимает, когда учетные данные хранятся в браузере. Я могу подсчитать время между отправкой фрейма auth в браузер и скомпонованием кадра из клиента. Когда время слишком велико, я могу отменить. К сожалению, это может сделать ложную неавторизацию на занятых компьютерах или сетях.

Я буду использовать оба метода в будущем:) Это будет забавно, если все можно будет сделать с помощью apach winbind auth module. Затем вся конфигурация может быть инкапсулирована под apache, такая же, как и для kerberos auth.

Спасибо всем за интересные, исследования и помощь:)

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

Если у пользователя нет действительных пропущенных учетных данных NTLM, им будет предложено предоставить их. Это не способ вернуться к «базовой» аутентификации.

К сожалению, невозможно определить, предоставил ли пользователь учетные данные или прошел ли они через систему.

Возможно, задайте новый вопрос о том, что вы хотите, чтобы ваши пользователи испытывали (т.е. разные сайты для внутренних и внешних пользователей), и кто-то может помочь по-другому.