Протокол Kerberos

Протокол Kerberos был создан более десяти лет назад в Массачусетском технологическом институте в рамках проекта Athena. Однако общедоступным этот протокол стал, начиная с версии 4. После того, как специалисты изучили новый протокол, авторы разработали и предложили очередную версию — Kerberos 5, которая была принята в качестве стандарта IETF. Требования реализации протокола изложены в документе RFC 1510, кроме того, в спецификации RFC 1964 описывается механизм и формат передачи жетонов безопасности в сообщениях Kerberos.

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

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

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

Простой протокол аутентификации с секретным ключом вступает в действие, когда кто-то стучится в сетевую дверь и просит впустить его. Чтобы доказать своё право на вход, пользователь предъявляет аутентификатор ( authenticator ) в виде набора данных, зашифрованного секретным ключом. Получив аутентификатор, "привратник" расшифровывает его и проверяет полученную информацию, чтобы убедиться в успешности дешифрования. Разумеется, содержание набора данных должно постоянно меняться, иначе злоумышленник может просто перехватить пакет и воспользоваться его содержимым для входа в систему. Если проверка прошла успешно, то это значит, что посетителю известен секретный код, а так как этот код знает только он и привратник, следовательно, пришелец на самом деле тот, за кого себя выдаёт.

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

Само название протокола Kerberos говорит о том, как здесь решена проблема управления ключами. Цербер (или Кербер ) — персонаж греческой мифологии. Этот свирепый пёс о трёх головах, по поверьям греков, охраняет врата подземного царства мёртвых. Трём головам Цербера в протоколе Kerberos соответствуют три участника безопасной связи:

• Клиент — система (пользователь), делающий запрос;
• Сервер — система, которая обеспечивает сервис для систем, чью подлинность нужно подтвердить.
• Центр распределения ключей ( Key Distribution Center, KDC ) — сторонний посредник между клиентом и сервером, который ручается за подлинность клиента. В среде Windows , начиная с Windows 2000, в роли KDC выступает контроллер домена со службой каталогов Active Directory.

В среде Kerberos для входа в систему пользователь должен предоставить свое имя пользователя, пароль и имя домена (часто упоминаемое как Realm, или " Сфера", в словаре Kerberos), в который он хочет войти. Эта информация посылается KDC, который устанавливает подлинность пользователя. Если пользователь подлинный, ему предоставляется нечто, называемое " билет на получение билета " ( ticket-granting ticket, TGT ).

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

Когда вы хотите получить доступ к серверу, вы сначала должны обратиться к KDC, предъявить свой билет TGT, как подтверждение своей подлинности, а затем уже запросить " билет сеанса " для сервера, с которым вам необходим контакт. Если вы аутентифицированы, вы сможете получить доступ к серверу в соответствии с правами, которыми обладаете. Билет сеанса и TGT, которые вы получаете, имеют ограниченное время действия, которое может настраиваться в групповой политике. Значения по умолчанию составляют для TGT (также упоминаемого как билет пользователя) — 7 дней, а для билета сеанса (также упоминаемого как билет службы) — 10 часов.

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

Пример, приведенный ниже, демонстрирует шаги, необходимые для того, чтобы клиент, расположенный в домене it.company.ru, получил доступ к серверу в доменеsales.company.ru:

• клиент входит в систему как пользователь в домене it.company.ru и получает соответствующий TGT;
• клиент хочет взаимодействовать с сервером в домене sales.company.ru, он контактирует с KDC в домене it.company.ru и запрашивает билет сеанса для KDC в домене company.ru;
• после получения этого билета он контактирует с KDC в домене company.ru и запрашивает билет сеанса для KDC в домене sales.company.ru;
• после получения этого билета он контактирует с KDC в домене sales.company.ru и запрашивает билет для сервера, к которому ему необходим доступ;
• получив билет сессии для доступа к серверу, клиент имеет доступ к нему в соответствии с имеющимися у него разрешениями.

Настройка параметров безопасности (Шаблоны безопасности, Анализ и настройка безопасности)

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

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

1. Сначала откроем чистую консоль mmc.

Кнопка " Пуск " — " Выполнить " — mmc — кнопка " ОК ".

1. Добавим в новую консоль оснастки " Шаблоны безопасности " и " Анализ и настройка безопасности ".

Меню " Консоль " — " Добавить или удалить оснастку " — кнопка " Добавить " — выбрать оснастку " Анализ и настройка безопасности " — кнопка " Добавить " — выбрать оснастку " Шаблоны безопасности " — кнопка " Добавить " — кнопка "Закрыть " — кнопка " ОК " (рис. 6.57).

Рис. 6.57.

В полученной консоли (ее можно будет сохранить и использовать в дальнейшем неоднократно) можно делать следующее:

• изучить параметры стандартных шаблонов безопасности (оснастка "Шаблоны безопасности") и даже попробовать сконструировать собственные шаблоны на основе стандартных (можно сохранить какой-либо шаблон с другим именем и изменить какие-либо параметры шаблона);
• провести анализ (сравнение) текущих параметров безопасности сервера (оснастка " Анализ и настройка безопасности ").

Приведем краткие характеристики стандартных шаблонов безопасности:

• DC security — используемые по умолчанию параметры безопасности контроллера домена;
• securedc — защищенный контроллер домена (более высокие требования к безопасности по сравнению с шаблоном DC security, отключается использование метода аутентификации LanManager );
• hisecdc — контроллер домена с высоким уровнем защиты (более высокие требования к безопасности по сравнению с шаблоном securedc, отключается метод аутентификации NTLM, включается требование цифровой подписи пакетов SMB);
• compatws — совместимая рабочая станция или совместимый сервер (ослабляет используемые по умолчанию разрешения доступа группы "Пользователи" к реестру и к системным файлам для того, чтобы приложения, не сертифицированные для использования в данной системе, могли работать в ней);
• securews — защищенная рабочая станция или защищенный сервер (аналогичен шаблону securedc, но предназначен для применения к рабочим станциям и простым серверам);
• hisecws — рабочая станция или защищенный сервер с высоким уровнем защиты (аналогичен шаблону hisecdc, но предназначен для применения к рабочим станциям и простым серверам);
• setup security — первоначальные настройки по умолчанию (параметры, устанавливаемые во время инсталляции системы);
• rootsec — установка стандартных (назначаемых во время инсталляции системы) NTFS-разрешений для папки, в которую установлена операционная система;

Теперь на примере рассмотрим, как проводить анализ настроек безопасности.

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

Щелкнем правой кнопкой мыши на значке оснастки " Анализ и настройка безопасности ", выберем " Открыть базу данных ", укажем путь и название БД (по умолчанию БД создается в папках профиля того администратора, который проводит анализ), нажмем кнопку " Открыть ", выберем нужный нам шаблон (например, hisecdc ) и нажмем " ОК " (рис. 6.58):

Рис. 6.58.

1. Выполним анализ настроек безопасности.

Щелкнем правой кнопкой мыши на значке оснастки " Анализ и настройка безопасности ", выберем " Анализ компьютера ", укажем путь и название файла с журналом ошибок (т.е. протоколом проведения анализа), нажмем "ОК", будет выполнено сравнение текущих настроек с параметрами шаблона (рис. 6.59):

Рис. 6.59.

1. Теперь можно провести уже настоящий анализ настроек безопасности.

Откроем любой раздел оснастки (например, " Политики паролей ", рис. 6.60):

На рисунке сразу видны расхождения между настройками нашего сервера (столбец " Параметр компьютера ") и настройками шаблона (столбец " Параметр базы данных ") — видно, как мы понизили настройке безопасности для проведения практических занятий.

Аналогично проводится анализ всех остальных разделов политик безопасности.

Этой же оснасткой можно одним действием привести настройки нашего компьютера в соответствии с параметрами шаблона (щелкнуть правой кнопкой мыши на значке оснастки " Анализ и настройка безопасности ", выбрать " Настроить компьютер "). Не рекомендуем это делать, не изучив в деталях, какие последствия это может повлечь для всей сети. Высокие требования к параметрам безопасности препятствуют работе в домене Active Directory компьютеров с системами Windows 95/98/ME/NT. Например, данные системы поддерживают уровень аутентификации NTLM версии 2 (который назначается шаблонами hisecdc и hisecws ) только при проведении определенных настроек на компьютерах со старыми системами. Поэтому, прежде чем принимать решение об установке более высоких параметров безопасности в сети, необходимо тщательно изучить состав сети, какие требования к серверам и рабочим станциям предъявляют те или иные шаблоны безопасности, предварительно установить нужные обновления и настроить нужные параметры на "старых" системах и только после этого применять к серверам и рабочим станциям Windows 2000/XP/2003 шаблоны с высокими уровнями сетевой безопасности.

Заметим дополнительно, что данные оснастки имеются не только на серверах, но и на рабочих станциях под управлением Windows 2000/XP Professional, и они позволяют производить аналогичный анализ и настройки на рабочих местах пользователей.

Рис. 6.60.

Резюме

Первая часть данного раздела описывает задачи служб каталогов корпоративной сети и основные понятия служб каталогов Active Directory:

• домен;
• дерево;
• лес;
• организационное подразделение.

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

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

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

Задачи сетевого администратора при управлении инфраструктурой службы каталогов:

• планирование и реализация пространства доменных имен компании или организации для службы каталогов Active Directory;
• планирование и реализация IP-сетей и сайтов AD для управления процессами репликации контроллеров домена и аутентификации пользователей в сети;
• планирование и размещение в сети контроллеров домена, выполняющих функции хозяев операций;
• планирование и реализация правил создания и именования учетных записей пользователей, компьютеров и групп;
• планирование и реализация стратегии использования групп для управления доступом к сетевым ресурсам;
• планирование и реализация иерархии организационных подразделений для делегирования административных полномочий и применения групповых политик;
• планирование и разработка набора групповых политик для управления рабочей средой пользователей и параметров компьютеров;
• проведение анализа сетевой безопасности, настройка требуемого уровня сетевой безопасности на серверах и рабочих станциях.