No Image

Уровне проверки подлинности lan manager

СОДЕРЖАНИЕ
1 просмотров
11 марта 2020

NTLM (NT LAN Manager) – это довольно старый протокол аутентификации Microsoft, который появился еще в Windows NT. Несмотря на то, что еще в Windows 2000 Майкрософт внедрила более безопасный протокол аутентификации Kerberos, NTLM (в основном это NTLMv2) широко используется для аутентификации в Windows сетях до сих пор. В этом статье мы рассмотрим особенности процесс отключения протокола NTLMv1 и NTLMv2, и перехода на Kerberos в домене Active Directory.

Основные проблема NTLMv1 – слабое шифрование, хранение хэша пароля в оперативной памяти в службе LSA, который может извлечь различными утилитами (типа mimikatz) и использовать хэш для дальнейших атак, отсутствие взаимной проверки подлинности клиента и сервера, что делает вполне реальными атаки перехвата данных и неавторизованного доступа к ресурсам сети (утилиты типа Responder могут перехватывать данные NTLM, передаваемые по сети и использовать их для доступа к сетевым ресурсам) и ряд других уязвимостей.

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

Переключаемся на использование NTLMv2

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

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

Тип аутентификации можно задать с помощью доменной (или локальной) политики. Откройте консоль управления доменными политиками и отредактируйте Default Domain Policy. Перейдите в раздел Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options и найдите политику

Network Security: LAN Manager authentication level (Сетевая безопасность: уровень проверки подлинности LAN Manager).

В настройках политики есть 6 опций:

  • Send LM & NTLM responses;
  • Send LM & NTLM responses – use NTLMv2 session security if negotiated;
  • Send NTLM response only;
  • Send NTLMv2 response only;
  • Send NTLMv2 response only. Refuse LM;
  • Send NTLMv2 response only. Refuse LM& NTLM.

Политики использования NTLM аутентификации расположены в порядке возрастания их безопасности. По умолчанию в Windows 7 и выше используется настройка Send NTLMv2 response only (Отправлять только NTLMv2-ответ). При этой настройке клиентские компьютеры используют NTLMv2 аутентификацию, но контролеры домены принимают LM, NTLM, и NTLMv2 запросы.

Вы можете изменить значение политики на более безопасную 6 опцию — “Send NTLMv2 response only. Refuse LM & NTLM”. При этой политике контролеры домена также будут отвергать запросы LM и NTLM.

Также вы можете отключить NTLMv1 через реестр. Для этого в ветке

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLsa нужно создать параметр DWORD с именем LmCompatibilityLevel и значением от 0 до 5. Значение 5 соответствует значению политики «Отправлять только NTLMv2-ответ. Отказывать LM и NTLM».

Не забудьте применить эту политику для контроллеров домена.

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

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

Аудит событий NTLM аутентификации в домене

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

Для отслеживания учетных записей и приложение, которые используют NTLM аутентификацию, вы можете включить политики аудита на всех компьютерах с помощью GPO. В разделе Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options найдите и включите политику Network Security: Restrict NTLM: Audit NTLM authentication in this domain, установив ее значение на Enable all.

Аналогичным образом включите политику Network Security: Restrict NTLM: Audit Incoming NTLM Traffic, установив ее значение на Enable auditing for domain accounts.

После включения данных политик события использования NTLM аутентификации записываться в журнал событий Event Viewer в секцию Application and Services Logs-> Microsoft -> Windows -> NTLM.

Можно проанализировать события на каждом сервере, или собрать все события в центральный Event Log.

Вам нужно собрать события от Microsoft-Windows-Security-Auditing c Event ID 4624 – An Account was successfully logged on. Обратите внимание на информацию в секции “Detailed Authentication Information”. Если в строке Authentication Package указано NTLM, значит для аутентификации этого пользователя использовался протокол NTLM.

Теперь обратите внимание на значение Package Name (NTLM only). Здесь должно быть указано какой протокол (LM, NTLMv1 или NTLMv2) использовался для аутентификации. Таким образом вам нужно идентифицировать все сервера/приложения, которые используют устаревший протокол.

Например, для поиска всех событий аутентификации по NTLMv1 по всем контроллерам домена можно использовать такой PowerShell скрипт:

$ADDCs = Get-ADDomainController -filter * -Server winitpro.ru
$Now = Get-Date
$Yesterday = $Now.AddDays(-1)
$NewOutputFile = "c:psEvents$($Yesterday.ToString(‘yyyyMMdd’))_AD_NTLMv1_events.log"
function GetEvents($DC)<
Write-Host "Searching log on " $DC.HostName
$Events = Get-EventLog "Security" -After $Yesterday.Date -Before $Now.Date -ComputerName $DC.HostName -Message "*V1*" -instanceid 4624
foreach($Event in $Events)<
Write-Host $DC.HostName $Event.EventID $Event.TimeGenerated
Out-File -FilePath $NewOutputFile -InputObject "$($Event.EventID), $($Event.MachineName), $($Event.TimeGenerated), $($Event.ReplacementStrings),($Event.message)" -Append
>
>
foreach($DC in $ADDCs)

После того, как вы нашли пользователей и приложения, использующие NTLM в вашем домене, попробуйте перевести их на использование Kerberos (возможно с использованием SPN). Некоторые приложения достаточно донастроить для работы Kerberos авторизации (см. статьи Kerberos авторизация в IIS, использование Kerberos авторизация в браузерах). Из личного опыта: даже действительно большие коммерческие продукты иногда еще не перешли с использования NTLM на Kerberos, некоторые продукты требуют обновления или изменений конфигурации. Все сводится к определению того, какие приложения используют проверку подлинности NTLM, и теперь у вас есть способ для выяснения этого софта и устройств.

Те приложений, которые нельзя переключить на использование NTLM можно добавить в исключения, разрешив им использовать NTLM аутентификацию, даже если она отключена на уровне домена. Для этого используется политика Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain. В список исключений нужно добавить имена серверов, для аутентификации на которых можно использовать NTLM (конечно, в идеале этот список исключений должен быть пустым). Можно использовать знак подстановки *.

Читайте также:  Разделить число на цифры

Полное отключение NTLM в домене Active Directory

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

Protected Users (группа доступна, начиная с Windows Server 2012 R2), членам которой можно аутентифицироваться только по протоколу Kerberos (нельзя использовать NTLM, Digest Authentication или CredSSP). Так вы можете проверить корректность Kerberos аутентификации пользователя в различных приложениях.

Теперь вы можете полностью отключить NTLM в домене с помощью групповой политики Network Security: Restrict NTLM: NTLM authentication in this domain.

В этой политике доступно 5 опций:

  • Disable: политика отключена (NTLM аутентификация в домене разрешена);
  • Deny for domain accounts to domain servers: контролеры домена запрещают попытки аутентификации NTLM для всех серверов под доменными аккаунтами, возвращается ошибка «NTLM заблокирован»;
  • Deny for domain accounts: контролеры домена запрещают попытки NTLM аутентификации для всех учетных записей домена, возвращается ошибка «NTLM заблокирован»;
  • Deny for domain servers: запрещены запросы NTLM аутентификации для всех серверов;
  • Deny all: контроллеры домена блокируют все запросы NTLM для всех серверов и учетных записей.

Технический блог специалистов ООО"Интерфейс"

  • Главная
  • Аутентификация в системах Windows. Часть 1 – NTLM

Аутентификация в системах Windows. Часть 1 – NTLM

  • Автор: Уваров А.С.
  • 23.03.2015

Работая в среде 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.

Читайте также:  Что такое рендер видео

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

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

Наименование настройки Клиентский компьютер Контроллер домена Lm Compatibility Level
Отправлять LM- и NTLM-ответы Клиентские компьютеры используют LM и NTLM аутентификацию , и никогда не используют сеансовую безопасность NTLMv2. Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.
Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2 Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2. 1
Отправлять только NTLM-ответ Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2. 2
Отправлять только NTLMv2-ответ Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность 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.

Персональные инструменты

LAN Manager

Разработчики: Microsoft Windows Corporation
Написана на: C++
Операционная система: MS-DOS, Windows Server
Тип ПО: LAN Менеджер
Веб-сайт Официальный сайт

LAN Manager – это первая сетевая операционная система, разработанная для поддержки среды клиент-сервер, ключевыми компонентами LAN Manager являются редиректор [1] и сервер [2] . Особенно эффективно LAN Manager поддерживает архитектуру клиент-сервер для систем управления базами данных. LAN Manager разрешает рабочим станциям под OS/2 поддерживать сетевой сервис по технологии "равный-с-равным". Это означает, что рабочая станция может выполнять функции сервера баз данных, принт-сервера или коммуникационного сервера. Ограничением является то, что только один пользователь, кроме владельца этой рабочей станции, имеет доступ к такому одноранговому сервису.

Содержание

История

В 1984 году Microsoft выпустила свой первый сетевой продукт, называемый Microsoft Networks, который обычно неформально называют MS-NET. Некоторые концепции, заложенные в MS-NET, такие как введение в структуру базовых компонент – редиректора и сетевого сервера – успешно перешли в LAN Manager.

Большое количество независимых поставщиков имеют лицензии на эту ОС и поддерживают свои собственные версии LAN Manager как часть своих сетевых продуктов. В число этих компаний входят такие известные фирмы как:

  1. AT&T
  2. Hewlett-Packard
  3. 3Com Corporation 3+Open
  4. HP LAN Manager/X
  5. IBM LAN Server
  6. Tapestry Torus и другие

LAN Manager требует установки на файл-сервере операционной системы OS/2, рабочие станции могут работать под DOS, Windows или OS/2 [3] . LAN Manager использует 32-х битную версию файловой системы OS/2, называемую HPFS, которая оптимизирована для работы на файл-сервере за счет кэширования каталогов и данных.

Сетевая безопасность: уровень подлинности Lan Manager

Проверка подлинности LAN Manager (LM)-это протокол, используемый для проверки подлинности клиентов Windows для сетевых операций, включая соединения домена доступ к сетевым ресурсам и проверка подлинности пользователя или компьютера. Уровень проверки подлинности LM определяет, какой запрос/ответ протокол проверки подлинности согласовывается между клиентом и сервером. В частности уровень проверки подлинности LM определяет, какие протоколы проверки подлинности, клиент будет пытаться согласовывать или принимается сервером. Значение, указанное для параметра LmCompatibilityLevel определяет, какой протокол проверки подлинности запросом и подтверждением используется при входе в сеть. Это значение влияет на уровень протокола проверки подлинности, используемый клиентами, уровень согласуемой безопасности сеанса и уровень проверки подлинности, принимаемый серверами. Возможные параметры:

Значение Параметр
Отправлять Lan Manager ответы
1 Отправлять Lan Manager – использовать сеансовую безопасность NTLMv2 при согласовании
2 Отправлять только NTLM ответ
3 Отправлять только NTLMv2 ответ
4 Отправлять только NTLMv2 ответ, отказывать LM
5 Отправлять только NTLMv2 ответ, отказывать LM и NTLM

Недостатки LAN Manager

Основные недостатки протокола аутентификации LAN Manager-a являются:

  1. Пароли не чувствительны к регистру. Все пароли преобразуются в верхний регистр перед генерацией хэш-значение. Следовательно, требуется пароль, пароль, пароль, пароль и другие подобные комбинации такие же, как ПАРОЛЬ превращающего все символы в верхний регистр. Символы пароля также ограничены подмножеством набора символов ASCII.
  2. Длина пароля ограничена максимум 14 символов
  3. Пароль 14 символов разбивается на 7 + 7 символов и хэш рассчитывается для двух половин отдельно. Такой способ вычисления хэш делает его экспоненциально легче взломать, как атакующему нужно грубой силой 7 символов в два раза вместо 14 символов. Это делает эффективную силу пароля 14-символов, равной удвоенной пароля в 7 символов, что значительно менее сложным, чем прочность пароля 14 символов.
  4. Если пароль 7 знаков или меньше, то вторая половина хэша всегда будет производить ту же постоянную величину (0xAAD3B435B51404EE). Таким образом, если длина пароля меньше или равно 7 символов, то длина пароля из 7 символов или менее могут быть идентифицированы визуально, без использования инструментов.
  5. Значение хеш-функции посылается на сервер по сети без шифровки, что делает его восприимчивым к атаке "встрече по середине" [3] , таких как востановления хэша.
Комментировать
1 просмотров
Комментариев нет, будьте первым кто его оставит

Это интересно
Adblock detector