Руководство FreeBSD
Пред. | Глава 14. Безопасность | След.

# 14.8. Kerberos5

Предоставил Tillman Hodgson. Оригинальный материал предоставил Mark Murray.

Все релизы FreeBSD после FreeBSD-5.1 включают поддержку только Kerberos5. Таким образом, Kerberos5 это единственная включаемая в поставку версия и его конфигурация похожа на KerberosIV во многих аспектах. Эта информация применима только к Kerberos5 из релизов после FreeBSD-5.0. Пользователи, желающие использовать пакет KerberosIV, могут установить его из порта `security/krb4`.

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

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

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

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

В целях демонстрации установки Kerberos, будут применены следующие обозначения:

- DNS домен (''зона'') example.org.

- Уникальный идентификатор Kerberos EXAMPLE.ORG.

> Замечание: Используйте действующие имена доменов при настройке Kerberos даже если вы будете использовать его во внутренней сети. Это позволит избежать проблем с DNS и гарантирует возможность связи с Kerberos под другими идентификаторами.

## 14.8.1. История

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

Kerberos это и имя сетевого протокола аутентификации и общий термин для описания программ, где он реализован (например, Kerberos telnet). Текущая версия протокола 5 описана в RFC 1510.

Доступно несколько свободных реализаций этого протокола, работающих на множестве операционных систем. Massachusetts Institute of Technology (MIT), где Kerberos был первоначально разработан, продолжает разрабатывать собственный пакет Kerberos. Он обычно использовался в США как криптографический продукт, и в этом качестве попадал под действие ограничений на экспорт. MIT Kerberos доступен в виде порта (`security/krb5`). Heimdal Kerberos это другая реализация версии 5, которая разрабатывалась исключительно вне США для обхода экспортных ограничений (и поэтому часто включалась в некоммерческие реализации UNIX®). Heimdal Kerberos доступен в виде порта (`security/heimdal`), его минимальный комплект включен в базовую установку FreeBSD.

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

## 14.8.2. Настройка Heimdal KDC

Центр распространения ключей (Key Distribution Center, KDC) это централизованный сервис аутентификации, предоставляемый Kerberos -- это компьютер, который предоставляет доступ через Kerberos. KDC считается доверяемым всеми другими компьютерами с определенным идентификатором Kerberos и поэтому к нему предъявляются высокие требования безопасности.

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

Перед началом настройки KDC, убедитесь что в файле `/etc/rc.conf` содержатся правильные настройки для работы в качестве KDC (вам может потребоваться изменить пути в соответствии с собственной системой):

    kerberos5_server_enable="YES"
    kadmind5_server_enable="YES"

Затем приступим к редактированию файла настройки Kerberos, `/etc/krb5.conf`:

    [libdefaults]
        default_realm = EXAMPLE.ORG
    [realms]
        EXAMPLE.ORG = {
            kdc = kerberos.example.org
            admin_server = kerberos.example.org
        }
    [domain_realm]
        .example.org = EXAMPLE.ORG

Обратите внимание что в файле `/etc/krb5.conf` подразумевается наличие у KDC полного имени `kerberos.example.org`. Вам потребуется добавить CNAME (синоним) к файлу зоны, если у KDC другое имя.

> Замечание: Для больших сетей с правильно настроенным сервером BIND DNS пример выше может быть урезан до:

>     [libdefaults]
>           default_realm = EXAMPLE.ORG

> Со следующими строками, добавленными в файл зоны `example.org`:

>     _kerberos._udp      IN  SRV     01 00 88 kerberos.example.org.
>     _kerberos._tcp      IN  SRV     01 00 88 kerberos.example.org.
>     _kpasswd._udp       IN  SRV     01 00 464 kerberos.example.org.
>     _kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.example.org.
>     _kerberos           IN  TXT     EXAMPLE.ORG

> Замечание: Чтобы клиенты могли найти сервисы Kerberos, необходимо наличие или полностью настроенного `/etc/krb5.conf` или минимально настроенного `/etc/krb5.conf` и правильно настроенного DNS сервера.

Создадим теперь базу данных Kerberos. Эта база данных содержит ключи всех основных хостов, зашифрованных с помощью главного пароля. Вам не требуется помнить этот пароль, он хранится в файле (`/var/heimdal/m-key`). Для создания главного ключа запустите `kstash` и введите пароль.

Как только будет создан главный ключ, вы можете инициализировать базу данных с помощью программы `kadmin` с ключом `-l` (означающим ''local''). Этот ключ сообщает `kadmin` обращаться к файлам базы данных непосредственно вместо использования сетевого сервиса `kadmind`. Это помогает решить ''проблему курицы и яйца'', когда обращение идет к еще не созданной базе данных. Как только вы увидите приглашение `kadmin`, используйте команду `init` для создания базы данных идентификаторов.

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

Пример создания базы данных показан ниже:

    # kstash
    Master key: xxxxxxxx
    Verifying password - Master key: xxxxxxxx

    # kadmin -l
    kadmin> init EXAMPLE.ORG
    Realm max ticket life [unlimited]:
    kadmin> add tillman
    Max ticket life [unlimited]:
    Max renewable life [unlimited]:
    Attributes []:
    Password: xxxxxxxx
    Verifying password - Password: xxxxxxxx

Теперь пришло время запустить сервисы KDC. Выполните команды `/etc/rc.d/kerberos start` и `/etc/rc.d/kadmind start` для запуска сервисов. Заметьте, что ни один из поддерживающих Kerberos даемонов на этот момент запущен не будет, но у вас должна быть возможность убедиться в том, что KDC функционирует путем получения списка доступа для пользователя, которого вы только что самостоятельно создали из командной строки самого KDC:

    % k5init tillman
    tillman@EXAMPLE.ORG's Password:

    % k5list
    Credentials cache: FILE:/tmp/krb5cc_500
            Principal: tillman@EXAMPLE.ORG

      Issued           Expires          Principal
    Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG

## 14.8.3. Сервер Kerberos с сервисами Heimdal

Для начала нам потребуется копия файла настройки Kerberos, `/etc/krb5.conf`. Просто скопируйте его с KDC на клиентский компьютер безопасным способом (используя сетевые утилиты, такие как scp(1), или физически, с помощью дискеты).

Затем вам понадобится файл `/etc/krb5.keytab`. Это основное различие между сервером, поддерживающим Kerberos и рабочими станциями -- на сервере должен быть файл `keytab`. В этом файле находится центральный ключ сервера, который позволяет KDC проверять все другие идентификаторы. Он должен быть помещен на сервер безопасным способом, поскольку безопасность сервера может быть нарушена, если ключ станет общедоступен. Это означает, что его передача через прозрачный канал, такой как FTP -- очень плохая идея.

Обычно перенос файла `keytab` на сервер производится с помощью программы `kadmin`. Это удобно, поскольку вам потребуется также создать запись хоста (KDC часть `krb5.keytab`) с помощью `kadmin`.

Обратите внимание, что должны быть уже зарегистрированы в системе и необходимо наличие прав на использование интерфейса `kadmin` в файле `kadmind.acl`. Обратитесь к разделу ''Remote administration'' в info страницах Heimdal (`info heimdal`) за деталями по составлению списка доступа. Если вы не хотите включать удаленный доступ `kadmin`, можете просто подключиться к KDC через защищенное соединение (локальную консоль, ssh(1) или Kerberos telnet(1)) и выполнять администрирование локально с помощью `kadmin -l`.

После добавления файла `/etc/krb5.conf`, вы можете использовать `kadmin` с сервера Kerberos. Команда `add --random-key` позволит вам добавить запись для сервера, а команда `ext` позволит перенести эту запись в собственный keytab файл сервера. Например:

    # kadmin
    kadmin> add --random-key host/myserver.example.org
    Max ticket life [unlimited]:
    Max renewable life [unlimited]:
    Attributes []:
    kadmin> ext host/myserver.example.org
    kadmin> exit

Обратите внимание, что команда `ext` (сокращение от ''extract'') сохраняет полученный ключ в файле `/etc/krb5.keytab` по умолчанию.

Если на KDC не запущен `kadmind` (возможно по соображениям безопасности) и вы не можете получить доступ к `kadmin` удаленно, возможно добавление записи хоста (`host/myserver.EXAMPLE.ORG`) непосредственно на KDC с последующим извлечением ее во временный файл (и перезаписью `/etc/krb5.keytab` на KDC) примерно так:

    # kadmin
    kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org
    kadmin> exit

Затем вы можете скопировать keytab на сервер защищенным способом (например, используя `scp` или дискету). Убедитесь, что используемое имя keytab не совпадает с именем по умолчанию во избежание перезаписывания keytab на KDC.

Теперь ваш сервер может связываться с KDC (добавлен файл `krb5.conf`) и идентифицировать себя (добавлен файл `krb5.keytab`). Теперь вы готовы к включению некоторых сервисов Kerberos. В этом примере мы включим сервис `telnet`, поместив в `/etc/inetd.conf` нижеприведенную строку и перезапустив сервис inetd(8) командой `/etc/rc.d/inetd restart`:

    telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user

Очень важно установить ключ `-a` (тип аутентификации) в user. Обратитесь к странице справочника telnetd(8) за подробной информацией.

## 14.8.4. Клиент Kerberos с Heimdal

Настройка клиентского компьютера почти тривиально проста. Как только настройка Kerberos закончена, вам потребуется только файл настройки Kerberos, `/etc/krb5.conf`. Просто скопируйте его безопасным способом на клиентский компьютер с KDC.

Протестируйте клиентский компьютер, попытавшись использовать `kinit`, `klist`, и `kdestroy` для получения, отображения и удаления списка доступа. Соединитесь с Kerberos севером используя клиент Kerberos, если соединение не работает и получение доступа является проблемой, это скорее всего проблема сервера, а не клиента или KDC.

При тестировании приложения вроде `telnet`, попробуйте использовать программу перехвата пакетов (такую как tcpdump(1)), чтобы убедиться, что ваш пароль не передается незашифрованным. Попробуйте использовать `telnet` с параметром `-x`, чтобы зашифровать весь поток данных (подобно `ssh`).

Основные клиентские приложения Kerberos (традиционно называющиеся `kinit`, `klist`, `kdestroy`, и `kpasswd`) находятся в базовой установке FreeBSD. Обратите внимание, что в FreeBSD версий до 5.0 они были переименованы в `k5init`, `k5list`, `k5destroy`, `k5passwd`, и `k5stash` (хотя их обычно использовали лишь однократно).

Различные неосновные клиентские приложения Kerberos также устанавливаются по умолчанию. Здесь проявляется ''минимальность'' базовой установки Heimdal: `telnet` это единственное приложение, поддерживающее Kerberos.

Порт Heimdal добавляет некоторые отсутствующие клиентские приложения: поддерживающие Kerberos версии `ftp`, `rsh`, `rcp`, `rlogin`, и некоторые другие реже используемые программы. Порт MIT также содержит полный пакет клиентских приложений Kerberos.

## 14.8.5. Пользовательские файлы настройки: `.k5login` и `.k5users`

Учётные записи пользователя в Kerberos (например `tillman@EXAMPLE.ORG`) обычно связаны с локальными учётными записями (например с локальной учётной записью6 `tillman`). Клиентские приложения, такие как `telnet`, обычно не требуют указания имени пользователя или учётной записи.

Тем не менее, время от времени вам может потребоваться дать доступ к локальной учётной записи кому-то, у кого нет соответствующей учётной записи Kerberos. Например, пользователю `tillman@EXAMPLE.ORG` может потребоваться доступ к локальной учётной записи `webdevelopers`. Другим учётным записям также может потребоваться доступ к этой локальной учётной записи.

Файлы `.k5login` и `.k5users`, помещенные в домашний каталог пользователя, могут быть использованы подобно действенной комбинации `.hosts` и `.rhosts` для решения этой проблемы. Например, файл `.k5login` со следующим содержанием:

    tillman@example.org
    jdoe@example.org

помещен в домашний каталог локального пользователя `webdevelopers`, то обе упомянутые учётные записи получат доступ к этой учётной записи без необходимости наличия общего пароля.

Рекомендуется прочитать страницу справочника по этим командам. Обратите внимание, что страница справочника о `ksu` содержит информацию по `.k5users`.

## 14.8.6. Подсказки, советы и решение проблем с Kerberos

- При использовании портов как Heimdal так и MIT Kerberos убедитесь, что в `PATH` версии Kerberos клиентов указаны перед их версиями в базовой системе.

- Все ли компьютеры в пределах данного realm синхронизированы по времени? Если нет, аутентификация может завершиться неудачно. Разд. 26.10 описывает как синхронизировать часы с использованием NTP.

- MIT и Heimdal успешно взаимодействуют. За исключением `kadmin`, протокол для которого не стандартизован.

- Если вы изменяете hostname, потребуется также изменить учётную запись `host/` и обновить keytab. Это также необходимо для специальных записей в keytab, таких как `www/` запись модуля Apache `www/mod_auth_kerb`.

- Все хосты под общим идентификатором должны разрешаться DNS (прямое и обратное разрешение), или как минимум через `/etc/hosts`. Записи CNAME будут работать, но записи A и PTR должны быть корректны и находиться на своем месте. Сообщение об ошибке не всегда интуитивно понятно: “`Kerberos5 refuses authentication because Read req failed: Key table entry not found`”.

- Некоторые операционные системы, способные работать в качестве клиентов KDC не устанавливают права для `ksu` в setuid `root`. Это означает, что `ksu` не работает, что хорошо является хорошей идеей для безопасности, но неудобно. Это не ошибка KDC.

- С MIT Kerberos, если вы хотите продлить действие доступа до значения большего, чем десять часов по умолчанию, используйте команду `modify_principal` в `kadmin` для изменения maxlife доступа к самой учётной записи и к учётной записи `krbtgt`. Затем возможно использование `kinit` с параметром `-l` для запроса доступа с большим временем действия.

- > Замечание: Если вы запускаете перехватчик пакетов на KDC для разрешения проблем, а затем запускаете `kinit` с рабочей станции, то увидите, что TGT посылается непосредственно при запуске `kinit` -- даже до того, как вы введете пароль! Объяснение в том, что сервер Kerberos свободно распространяет TGT (Ticket Granting Ticket) на каждый неавторизованный запрос; однако, каждый TGT зашифрован ключом, полученным из пароля пользователя. Следовательно, когда пользователь вводит свой пароль, он не отправляется на KDC, а используется для расшифровка TGT, который уже получен `kinit`. Если в процессе расшифровки получается правильный билет с правильным значением времени, у пользователя есть действующее ''удостоверение''. Это удостоверение содержит ключ сессии для установления безопасного соединения с сервером Kerberos, как и действующий TGT, зашифрованный ключом сервера Kerberos. Второй уровень шифрования недоступен пользователю, но позволяет серверу Kerberos проверять правильность каждого TGT.

- Если вы хотите установить большое время жизни доступа (например, неделю), и используете OpenSSH для соединения с компьютером, где хранится ''билет'', убедитесь, что параметр Kerberos `TicketCleanup` установлен в `no` в файле `sshd_config`, или билеты будут уничтожены при выходе из сеанса.

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

- При настройке файла `krb5.dict` на предотвращение использования определенных плохих паролей (страница справочника для `kadmind` кратко рассказывает об этом), запомните, что это применимо только к учётным записям, для которых действует политика паролей. Формат файла `krb5.dict` прост: одно слово на строку. Может помочь создание символической ссылки на `/usr/share/dict/words`.

## 14.8.7. Отличия от порта MIT

Основное различие между установками MIT и Heimdal относится к программе `kadmin`, которая имеет другой (но эквивалентный) набор команд и использует другой протокол. Если ваш KDC работает на MIT, вы не сможете использовать `kadmin` для удаленного администрирования KDC (и наоборот, по этой же причине).

Опции командной строки клиентов также могут немного отличаться для одинаковых задач. Рекомендуется следование инструкциям на MIT Kerberos Web-сайте (http://web.mit.edu/Kerberos/www/). Будьте внимательны при определении `PATH`: порт MIT устанавливается по умолчанию в `/usr/local/`, и если в `PATH` вначале указаны системные каталоги, вместо приложений MIT могут быть запущены системные приложения.

> Замечание: С портом MIT `security/krb5`, предоставляемым FreeBSD, убедитесь что файл `/usr/local/share/doc/krb5/README.FreeBSD` установлен портом, если вы хотите понять почему вход через `telnetd` и `klogind` иногда происходит так странно. Наиболее важно, исправление ''incorrect permissions on cache file'' требует использования бинарного файла `login.krb5` для аутентификации, чтобы права на переданное удостоверение передавались правильно.

## 14.8.8. Преодоление ограничений, обнаруженных в Kerberos

### 14.8.8.1. Kerberos это все или ничего

Каждый сервис, работающий в сети, должен быть модифицирован для работы с Kerberos (или другим способом защищен от атак по сети) или удостоверения пользователей могут быть украдены или использованы повторно. В качестве примера может быть приведено использование Kerberos версий оболочек для удаленной работы (например через `rsh` и `telnet`), при наличии POP3 сервера, получающего пароли в незашифрованном виде.

### 14.8.8.2. Kerberos предназначен для однопользовательских рабочих станций

В многопользовательской среде Kerberos менее безопасен. Это потому, что он хранит билеты в каталоге `/tmp`, которая доступна для чтения всем. Если пользователь работает с несколькими другими пользователями одновременно на одном компьютере (т.е. в многопользовательской среде), возможна кража (копирование) билета другим пользователем.

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

### 14.8.8.3. От KDC зависит вся система

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

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

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

### 14.8.8.4. Недостатки Kerberos

Kerberos позволяет пользователям, хостам и сервисам производить аутентификацию друг друга. В нем нет механизма аутентификации KDC для пользователей, хостов или сервисов. Это означает, что поддельный `kinit` (например) может записывать все имена пользователей и паролей. Помочь решить проблему может `security/tripwire` или другой инструмент проверки целостности файловой системы.

## 14.8.9. Ресурсы и информация для дальнейшего изучения

- Kerberos FAQ

- Разработка системы аутентификации: диалог в четырех сценах

- RFC 1510, Kerberos Network Authentication Service (V5)

- Домашняя страница MIT Kerberos

- Домашняя страница Heimdal Kerberos

Пред. | Начало | След.
KerberosIV | Уровень выше | OpenSSL

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.