Глава 3. Безопасность операционной системы UNIX

Lan manager (lm)

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

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

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

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

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

Ntlmv2

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

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

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

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

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

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

Похожее:  Личный кабинет временно недоступен | Yota

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

Глава 3. безопасность операционной системы unix

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

В UNIX роль номинального субъекта безопасности
играет пользователь. Каждому пользователю
выдается (обычно – одно) входное имя (login). Каждому входному имени
соответствует единственное число, идентификатор пользователя (User
IDentifier, UID). Это число и есть ярлык субъекта, которым
система пользуется для определения прав доступа.

Каждый пользователь входит в одну или более групп. Группа – это образование, которое имеет
собственный идентификатор группы (Group IDentifier, GID),
объединяет нескольких пользователей системы, а стало быть, соответствует понятию
множественный субъект. Значит, GID – это ярлык множественного
субъекта, каковых у действительного субъекта может быть более одного. Таким
образом, одному UID соответствует список GID.

Роль действительного (работающего с объектами) субъекта
играет процесс. Каждый процесс снабжен единственным UID:
это идентификатор запустившего процесс пользователя. Любой процесс, порожденный
некоторым процессом, наследует его UID. Таким образом, все процессы, запускаемые
по желанию пользователя, будут иметь его идентификатор. UID учитываются,
например, когда один процесс посылает другому сигнал. В общем случае разрешается
посылать сигналы «своим» процессам (тем, что имеют такой же
UID).

Роль объекта в UNIX играют многие реальные объекты, в
частности представленные в файловой системе: файлы, каталоги, устройства, каналы
и т. п.. Каждый файл снабжён UID – идентификатором
пользователя-владельца. Вдобавок у файла есть единственный GID, определяющий
группу, которой он принадлежит.

Презентация 4-06: права доступа

На уровне файловой системы в UNIX определяется
три вида доступа: чтение (read,
r), запись (write, w) и использование
(execution, x). Право на чтение из файла дает доступ к
содержащейся в нем информации, а право записи – возможность ее
изменять. При каждом файле имеется список того, что с ним может делать владелец
(если совпадает UID процесса и файла), член группы владельцев (если совпадает
GID) и кто угодно (если ничего не совпадает)
(см. Рисунок 3.2, «Базовые права доступа в UNIX»). Такой список для каждого объекта
системы занимает всего несколько байт.

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

Рассмотрим последовательность проверки прав на примере
(см. Рисунок 3.3, «Последовательнось проверки прав доступа в UNIX»). Пусть файл имеет следующие
атрибуты:

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

Презентация 4-07: последовательность проверки

Пусть файл пытается прочитать пользователь «bob». Он не является
владельцем, однако он является членом группы «users». Значит, он
имеет права на чтение этого файла.

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

Похожее:  ПФР — личный кабинет pfrf ru: вход через госуслуги, физического лица

Со временем в различных версиях UNIX стали появляться расширения прав доступа, позволяющие устанавливать права на отдельные объекты системы. Поначалу это были так называемые флаги – дополнительные атрибуты файла, не позволяющие, например, переименовывать его или удалять из него информацию при записи (можно только дописывать). Флаги не устраняют главного недостатка, зато их легко организовать без изменения файловой системы: каждый флаг занимает ровно один бит.

Многие современные файловые системы UNIX поддерживают также списки доступа (ACL), с помощью которых можно для
каждого объекта задавать права всех субъектов на доступ к нему.

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

Презентация 4-09: суперпользователь

Пользователь root (он
же суперпользователь) имеет нулевые UID и
GID и играет роль доверенного субъекта UNIX. Это значит,
что он не подчиняется законам, которые управляют правами доступа, и может по
своему усмотрению эти права изменять. Большинство настроек системы доступны для
записи только суперпользователю.

Как было сказано ранее (см. раздел «Беглый взгляд на архитектуру UNIX»),
в UNIX существует уровень доступа ядра и уровень доступа
системы. Суперпользователь работает на уровне доступа ядра, так что является по
сути продолжением самой системы.

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

Системное администрирование в UNIX производится от имени
пользователя root. При работе от этого имени следует быть
очень осторожным: выполнение неверной команды может привести к краху системы и
уничтожению информации. Поэтому даже администраторы никогда не работают в сеансе
суперпользователя всё время, а переходят в режим суперпользователя только
тогда, когда это действительно необходимо (например, с помощью
команды su).

Презентация 4-10: вход пользователя в систему

В UNIX сеанс работы пользователя
начинается с его аутентификации и заканчивается его выходом из системы. При
входе в систему выполняется следующая последовательность действий
(см. Рисунок 3.5, «Процесс входа в систему»):

При работе по сети роль getty исполняет сетевой демон,
например ssh.

В некоторых современных UNIX-системах существуют расширения систем авторизации и
аутентификации. Например, в Linux-системах этот механизм
называется подключаемые модули аутентификации (Pluggable
Authentication Modules, PAM). Эти средства выходят за рамки
данных лекций.

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

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

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

Похожее:  Проектирование программного обеспечения / Хабр

windows-authentication-1-005.jpgВ этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения 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.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector