cerber

Трехзевый Цербер, хищный и громадный,

Собачьим лаем лает на народ,

Который вязнет в этой топи смрадной.

Его глаза багровы, вздут живот,

Жир в черной бороде, когтисты руки;

Он мучит души, кожу с мясом рвет…

Данте Алигьери.

Божественная комедия, Песнь шестая

Каждый системный администратор, который хотя бы один раз сталкивался с администрированием доменных служб Active Directory, слышал о таком протоколе проверки подлинности (аутентификации) как Kerberos, позволяющем передавать данные для безопасной идентификации в открытых, или же, незащищенных, сетях. Естественно, помимо Active Directory от Microsoft, данный протокол поддерживают и FreeBSD, Mac OS X, Red Hat Linux и прочие UNIX-подобные операционные системы, но сейчас речь совсем не об этом…

Многие администраторы знают, что сейчас используется 5-я версия Kerberos с расширениями для проверки подлинности с помощью открытого ключа и паролей, так как о прекращении поддержки 4-й версии протокола официально было объявлено еще в 2006 году. Некоторые системные администраторы в курсе, что первые три версии этого протокола ни разу так и не вышли в RTM-версии и использовались исключительно в целях тестирования.

Но о чем же пойдет речь в этом цикле статей (именно в цикле, так как все сразу выдавать одним постом – это просто было бы нелогично и неправильно)? Речь пойдет о самом происхождении данного протокола, о процессе проверки подлинности, клиенте Kerberos и о Центре Распространения Ключей Kerberos. Помимо этого, из статей данного цикла вы узнаете про улучшения и о новых функциональных возможностях Kerberos в Windows Server 2012, а также кое-что о безопасности Kerberos и еще много чего интересного.

Но, обо всем по порядку…

Откуда возник Цербер или появление протокола Kerberos

Все мы когда-то читали греческую мифологию. И, я надеюсь, что не ошибусь, если предположу, что абсолютно каждый, кто читает эту статью в курсе, что согласно мифологии глубоко под землей расположено царство Аида – Тартар: царство мертвых душ, куда не проникают лучи солнца. А выход из этого царства мертвых охраняет трехглавый пес Цербер (или Кербер, Κέρβερος), на шее которого движутся с грозным шипением змеи, который не позволяет умершим возвращаться в мир живых.

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

В уже далеком 1983 году, с целью создания комплекса распределенной вычислительной среды для использования в учебных целях, консорциумом Массачусетского Технологического Института (MIT), Digital Equipment Corporation (ныне Hewlett-Packard) и IBM, был создан проект «Афина». К программным продуктам, разрабатываемым в рамках этого проекта можно отнести X Windows System, которая используется у UNIX-сообществ, Xaw widget set, Zephyr Notification Service, даже тонкие клиенты.

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

Именно по этой причине, на основании уже существующего протокола аутентификации на основе доверенной третьей стороны Нидхем-Шредер и модификаций, предложенных Дороти Денниг и Джованни Сакко (Timestamps in key distributed protocols) впервые мир увидел первую версию протокола Kerberos. Кстати, с первой по третью версию протокол разрабатывался двумя членами проекта «Афина» ­- Стивом Миллером и Клиффордом Ньюманом, а также Джеромом Салтцером и Джеффри Шиллером, в то время, как уже было сказано выше, общая масса смогла увидеть плоды их работы только, начиная с четвертой версии данного протокола аутентификации.

Ну а, ввиду того, что для поддержания безопасности и взаимодействия с другими службами безопасности, основным механизмом проверки подлинности стал созданный указанными выше людьми протокол, в проекте «Афина» этот протокол был именован в честь трехглавого пса, о котором шла речь в самом начале этого раздела. То есть, так и появился протокол Kerberos.

Теперь следует разобраться, что же именно разработали сотрудники проекта «Афина», что собой представляет Kerberos…

Kerberos – что же ты такое?

clip_image002Прежде чем говорить о том, что представляет собой Kerberos, следует разобраться с тем, что означает сам термин проверка подлинности или же «аутентификация».

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

Как происходит процесс проверки подлинности, вы прекрасно знаете, поэтому опишу, буквально в двух словах:

  • Если на клиентском компьютере установлена операционная система ниже Windows Vista, служба Winlogon загружает динамическую библиотеку GINA, которая уже передает все введенные данные службе Winlogin, а последняя – передает эту же информацию локальной подсистеме безопасности (Local Security Authority, LSA).
  • С современными системами же, в свою очередь, все немного проще. Теперь библиотека GINA упразднена и в новых системах взаимодействуют поставщик учетных данных и winlogon, а для взаимодействия с пользователем в этом процесее используется LogonUI. Введенные пользователями учетные данные передаются компонентом LogonUI службе Winlogon, а затем уже все передается подсистеме LSA.

Дальше все просто. LSA применяет к указанному паролю хеш и удаляет текстовый пароль, после чего обращается к поставщику поддержки безопасности (Security Support Provider, SSP), а сам SSP, в свою очередь, связывается с контроллером домена для проверки подлинности.

Основное – это не путать аутентификацию, то есть, проверку подлинности, с авторизацией, которая представляет собой процесс определения уровня доступа к файловой системе и объектам Active Directory и выполняется уже после проверки подлинности.

Начиная с операционной системы Windows 2000, для проверки подлинности в Active Directory используются два протокола – Kerberos и NTLM, причем, Kerberos используется по умолчанию, а протокол NTLM обычно используется для обратной совместимости с Windows NT 4.0, Windows 95, а также Windows 98.

Kerberos позволяет проводить идентификацию объектов, высту­пая в роли доверительной службы аутентификации, используя процедуры трехстороннего сеанса связи, а также обусловленные заранее криптографические методы защиты информации. По сути, в Kerberos есть три компонента, а именно: клиент, получающий доступ к сетевым ресурсам, сервер, который будет предоставлять доступ к ресурсам только лишь прошедшим аутентификацию и авторизацию пользователям, а также центр распространения ключей (Key Distribution Center, KDC), который подробно будет рассмотрен в следующей статье. Забегая немного вперед, хотелось бы отметить, что центр распределения ключей Kerberos является встроенным компонентом безопасности на контроллерах домена Active Directory и в качестве базы данных учетных записей безопасности домена используется база данных самой службы каталогов.

Как вы догадались из описания процесса проверки подлинности, клиент проверки подлинности реализован в качестве поставщика SSP, а доступ к нему можно получить посредством интерфейса поставщика поддержки безопасности (Security Support Provider Interface, SSPI). Между прочим, в функциональных возможностях SSPI операционной системы Windows Server 2012 появились некоторые улучшения. Не будет новостью то, что каждый раз при попытке получения доступа к каким-либо ресурсам, подсистемой безопасности используются так называемые маркеры доступа. И в то время, когда операционная система Windows выполняет аутентификацию пользователя при помощи Kerberos, на компьютере пользователя во время входа в систему присваивается маркер доступа пользователя. В свою очередь, когда пользователь обращается к каким-либо ресурсам, маркер предоставляется пользовательским компьютером всем приложениям и потокам, которые будут запрашивать данные. Для проверки подлинности пользователя, также и приложения могут отправлять запросы на определения максимального размера маркера контекста. Это делается для выделения памяти, ведь сам маркер ни в коем случае не должен передаваться на другие компьютеры по сети.

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

А для того, чтобы вы могли централизованно определить размер маркера контекста, можно воспользоваться новыми параметрами административных шаблонов групповой политики. Для этого, в оснастке «Редактор управления групповыми политиками», следует развернуть узел Конфигурация компьютера\Политики\Административные шаблоны\Система\Kerberos и выбрать параметр политики «Установить максимальный размер буфера токена контекста KerberosSSPI». Здесь, используя специальный управляющий элемент, вы и можете определить значение, которое будет отдаваться приложениям в качестве максимального размера буфера маркера контекста, однако, не рекомендуется указывать размер буфера, превышающий 48000 байт. Диалоговое окно свойств параметра политики изображено на следующей иллюстрации:

kerb1-03

Рис. Параметр политики, отвечающий за максимальный размер буфера маркера контекста

Если же нет желания конфигурировать параметр политики, вы всегда можете изменить значение параметра «MaxTokenSize» системного реестра, который расположен в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters. Но есть ли в этом необходимость, если можно один раз настроить групповую политику? Улыбка

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

Ключевые преимущества протокола Kerberos над NTLM

По сути, по сравнению с устаревшим протоколом проверки подлинности NTLM, Kerberos предоставляет четыре основных преимущества. Рассмотрим подробно каждое такое преимущество:

  • Более эффективный доступ к ресурсам и проверка подлинности. Как в случае с проверкой подлинности при помощи NTLM, так и в случае с обращением к сетевым ресурсам, сервер, на котором хранится ресурс или же используемое приложение, обязан для проверки подлинности или проверки разрешений, подключиться к контроллеру домена. В случае с проверкой подлинности при использовании протокола Kerberos, в свою очередь, все немного иначе: здесь постоянный переход от сервера с ресурсами или приложениями к контроллеру домена не требуется. При использовании Kerberos, клиент однократно получает так называемый «билет службы» от контроллера домена, а затем этот билет будет использоваться при обращении к ресурсам на протяжении всего сеанса или до истечения своего жизненного срока;
  • Более эффективное взаимодействие с доменами в лесу. Следует помнить, что в случае с NTLM, абсолютно все доверительные связи являются нетранзитивными, односторонними, а также они должны настраиваться вручную. Естественно, это совершенно неудобно. А так как протокол Kerberos основан на спецификациях отслеживания, рекомендованных IETF, все доверительные связи автоматически конфигурируются, являются транзитивными и двухсторонними, а также поддерживаются между всеми доменами в пределах своего леса. Ну а при желании, всегда можно отконфигурировать доверительные связи Kerberos между лесами в ручном режиме;
  • Взаимная проверка подлинности. В случае использования проверки подлинности NTLM, сервер выполняет проверку подлинности клиента, однако, не разрешает клиентам или серверам проверять удостоверения других серверов, что называется односторонней проверкой подлинности. В этой среде все серверы будут считаться подлинными, что можно отнести к бреши в безопасности. В случае применения проверки подлинности Kerberos, клиенту удастся выполнить проверку подлинности самого сервера и удостовериться в том, что он получит ответ от требуемого, причем, правильного сервера;
  • Делегированная проверка подлинности. Опять же, начнем с проверки подлинности NTLM. Как уже было замечено выше, в этом случае, когда клиент подключается к серверу, последний вправе использовать полученные от клиента данные для получения доступа к любым своим ресурсам. При использовании аутентификации Kerberos, клиент сможет использовать эти же учетные данные не только на локальном сервере, а и на всех серверах, к которым ему понадобиться подключиться. Но ведь могут возникнуть и такие ситуации, когда для получения доступа к каким-то ресурсам в интрасети, необходимо для начала подключиться к внешним серверам. В этом случае следует воспользоваться делегированием проверки подлинности при помощи билетов прокси или перенаправленных билетов, что было принято в Windows 2000, либо воспользоваться возможностями ограниченного делегирования, которое появилось в более новых операционных системах Windows. Процессы делегирования проверки подлинности будут подробно рассмотрены в одной из следующих статей настоящего цикла.

Но вот, если при помощи проверки подлинности Kerberos можно обнаружить множество заплаток в плане безопасности, по сравнению с NTLM, есть ли у этого протокола хоть какие-то недостатки? Конечно, есть. Прежде всего, протокол не способен отражать атаки типа «отказ в обслужива­нии». В различных версиях протокола можно найти определенные лазейки, при помощи которых злоумышленник может препятствовать нормальной работе при­кладного процесса, используемого в обычных итерациях про­цедуры проверки подлинности. Во-вторых, протокол Kerberos не способен отражать атаки типа «распознавание па­роля». Другими словами, если ваш пользователь выберет откровенно слабый пароль, то это по­зволит злоумышленнику провести успешную автономную атаку при помощи словаря паролей путем неоднократных попыток дешифрования сообщений. И, в конце концов, участники сеанса связи должны самостоятельно и в обязатель­ном порядке обеспечивать сохранность своих ключей. А если хакеру каким-либо образом удалось украсть ключи, то он будет способен выступить в роли участника сессии или в роли какого-либо сервера для другого законного участника сессии, тем самым нанеся вред пользователю, серверу или компании в целом.

Вместо заключения

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

Реклама