14. Вопросы безопасности
Программное обеспечение OpenLDAP разработано для функционирования в самых различных вычислительных средах, от тотально-контролируемых закрытых сетей до глобального Интернет. Поэтому программное обеспечение OpenLDAP поддерживает множество различных механизмов безопасности. В этом разделе описываются данные механизмы и обсуждаются вопросы безопасности использования OpenLDAP.
14.1. Сетевая безопасность
14.1.1. Выборочное обслуживание запросов
По умолчанию, slapd(8) будет обслуживать запросы на "любых" адресах как IPv4, так и IPv6. Чаще всего предпочтительно, чтобы slapd обслуживал запросы на определённых адресах/портах. Например, если указать для обслуживания только IPv4 адрес 127.0.0.1, то все внешние запросы к серверу службы каталогов будут отвергнуты:
slapd -h ldap://127.0.0.1
Хотя сервер может быть настроен на обслуживание запросов на конкретном адресе интерфейса, это не говорит о том, что он будет разрешать доступ к серверу только из тех сетей, которые доступны через данный интерфейс. Для осуществления выборочного ограничения удалённых подключений рекомендуется использовать IP-фаервол.
Дополнительная информация в подразделе Параметры командной строки и slapd(8).
14.1.2. IP-фаервол
Для ограничения доступа на основе клиентских IP-адресов и/или сетевых интерфейсов, использующихся для соединения с клиентами, можно использовать возможности
Обычно, slapd(8) слушает 389/tcp для сессий ldap:// и порт 636/tcp для сессий ldaps://. Его также можно сконфигурировать для прослушивания других портов.
Поскольку настройки IP-фаевола зависят от конкретного типа IP-фаервола, здесь не приводится никаких примеров. Смотрите документацию к Вашему IP-фаерволу.
14.1.3. TCP Wrappers
slapd(8) поддерживает
slapd: 10.0.0.0/255.0.0.0 127.0.0.1 : ALLOW
slapd: ALL : DENY
разрешает для доступа к службе каталогов только входящие соединения из частной сети 10.0.0.0 и из localhost (127.0.0.1).
Примечание: В правилах для slapd(8) обычно указываются такие IP-адреса, чтобы по ним нельзя было выполнить обратный поиск.
Имейте в виду, что для TCP wrappers требуется указывать соединения, которые будут приниматься. Поскольку в большинстве случаев, наоборот, требуется запрещать соединения, предпочтительнее использовать защиту IP-фаерволом, нежели TCP wrappers.
Дополнительная информация о правилах TCP wrapper в hosts_access(5).
14.2. Целостность данных и защита конфиденциальности
Для обеспечения целостности данных и защиты конфиденциальности можно использовать
Также, в рамках обеспечения целостности данных и защиты конфиденциальности, поддерживается несколько механизмов
14.2.1. Факторы силы безопасности
Сервер использует факторы силы безопасности (
В рамках сессии LDAP количество административного контроля, налагаемого с помощью SSF, ассоциируется со степенью защиты средствами TLS и SASL.
Элементы управления security не позволяют выполнение операции, если не соблюдается указанная степень защиты. Например:
security ssf=1 update_ssf=112
требует защиты целостности для всех операций, а для операций обновления (таких как добавление, удаление, изменение) требует шифрования, эквивалентного 3DES. Детальное описание можно посмотреть в slapd.conf(5).
SSF можно использовать при контроле доступа с целью установки более точного контроля. Для получения дополнительной информации смотрите раздел Контроль доступа.
14.3. Методы аутентификации
14.3.1. Простой ("simple") метод
У простого метода аутентификации LDAP три режима работы:
- предоставление доступа анонимному пользователю,
- предоставление доступа пользователю без прохождения проверки подлинности, и
- предоставление доступа пользователю с проверкой подлинности по имени пользователя и паролю.
Запрос анонимного доступа происходит, когда при выполнении операции подключения по методу "simple" не передаётся ни имени пользователя, ни пароля. Запрос на предоставление доступа пользователю без прохождения проверки подлинности происходит, когда при подключении передаётся только имя пользователя, а пароль не передаётся. Наконец, запрос на предоставление доступа пользователю с проверкой подлинности происходит, когда при подключении передаются корректные имя пользователя и пароль.
В результате анонимного подключения возникает авторизационная ассоциация anonymous. Механизм анонимного подключения по умолчанию включен, но его можно отключить, указав "disallow bind_anon" в slapd.conf(5).
Примечание: Отключение механизма анонимного подключения не предотвращает анонимного доступа к каталогу. Чтобы для доступа к базе всегда требовалась аутентификация, вместо приведённой выше директивы следует указать "require authc".
В результате подключения пользователя без прохождения проверки подлинности также возникает авторизационная ассоциация anonymous. Механизм подключения пользователя без прохождения проверки подлинности отключен по умолчанию, но его можно включить, указав "allow bind_anon_cred" в slapd.conf(5). Поскольку некоторые приложения LDAP ошибочно генерируют запросы на подключение без прохождения проверки подлинности вместо запросов с проверкой подлинности (то есть, не удостоверившись, ввёл ли пользователь пароль), включение данного механизма нежелательно.
В результате подключения с успешной аутентификацией по имени пользователя и паролю возникает авторизационная идентифицированная сущность пользователя, то есть определённое имя, которое будет ассоциировано с сессией. Подключение с проверкой подлинности по имени пользователя и паролю включено по умолчанию. Однако, поскольку данный механизм сам по себе не обеспечивает защиту от прослушивания (например, в случае хранения пароля в открытом виде), рекомендуется использовать его только в жёстко контролируемых системах, либо когда сессии LDAP защищаются другими средствами (например, TLS,
Механизм подключения с проверкой подлинности по имени пользователя и паролю может быть полностью отключен при помощи директивы "disallow bind_simple".
Примечание: В результате подключения с проверкой подлинности, окончившейся неудачно, всегда возникает авторизационная ассоциация anonymous.
14.3.2. Метод SASL
Метод аутентификации LDAP
14.4. Хранилище паролей
Пароли LDAP обычно хранятся в атрибуте userPassword. В RFC4519 указано, что пароли не должны храниться в зашифрованной (или хэшированной) форме. Тем самым позволяется использование широкого круга механизмов аутентификации на основе паролей, таких как DIGEST-MD5. Такая схема хранения является также наиболее совместимой с реализациями системы аутентификации в различных клиентских программах.
Однако, на практике, чаще всего желательно всё же хранить хэш пароля. slapd(8) поддерживает несколько различных схем хранения на выбор системного администратора.
Примечание: Значения атрибутов пароля, независимо от используемой схемы хранения, должны защищаться также, как если бы они хранились в открытом виде. Хэшированные пароли подвержены атакам по словарю и атакам методом полного перебора.
Атрибут userPassword может иметь более одного значения, и все они могут храниться в различной форме. В процессе аутентификации slapd будет последовательно проходить по значениям, пока не найдёт такого, которое соответствует предложенному паролю, или пока значения не закончатся. Схема хранения указывается как префикс к значению, то есть пароль, захэшированный по схеме Salted SHA1 (SSHA) выглядит так:
userPassword: {SSHA}DkMTwBl+a/3DQTxCYEApdUtNXGgdUac3
Преимущество хэшированных паролей состоит в том, что взломщик, получающий доступ к хэшу, не имеет прямого доступа к настоящему паролю. К сожалению, они довольно просто подбираются с помощью атак по словарю или методом полного перебора, поэтому такое преимущество довольно призрачно (вот почему все современные Unix-системы используют парольный файл shadow).
Недостаток хэшированного хранения паролей состоит в том, что они не являются стандартными и могут вызвать проблемы с совместимостью. Это может привести к тому, что использование любых парольных механизмов аутентификации, сильнее Simple (или SASL/PLAIN), вообще исключается.
14.4.1. Схема хранения паролей SSHA
Это версия схемы SHA с "солью" . Она считается наиболее безопасной схемой хранения паролей, поддерживаемой slapd.
Эти значения представляют собой один и тот же пароль:
userPassword: {SSHA}DkMTwBl+a/3DQTxCYEApdUtNXGgdUac3
userPassword: {SSHA}d0Q0626PSH9VUld7yWpR0k6BlpQmtczb
14.4.2. Схема хранения паролей CRYPT
Эта схема использует функцию хэширования crypt(3) операционной системы. Как правило, в этой схеме генерируются традиционные 13-символьные хэши в стиле Unix, но на системах с glibc2 также могут генерироваться более безопасные 34-байтные хэши MD5.
userPassword: {CRYPT}aUihad99hmev6
userPassword: {CRYPT}$1$czBJdDqS$TmkzUAb836oMxg/BmIwN.1
Преимущество схемы CRYPT состоит в том, что пароли могут быть перенесены из существующего парольного файла Unix без необходимости иметь пароли в открытом виде. Обе формы crypt используют "соль", поэтому они имеют определенную стойкость к атакам по словарю.
Примечание: Поскольку эта схема использует функцию хэширования crypt(3) операционной системы, она является специфичной для каждой операционной системы.
14.4.3. Схема хранения паролей MD5
Эта схема просто берёт MD5-хэш от пароля и хранит его в base64-закодированной форме:
userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
Это не очень безопасная схема, хотя и безопаснее хранения в открытом виде. MD5 - быстрый алгоритм, и поскольку он не использует "соль", данная схема хранения уязвима для атак по словарю.
14.4.4. Схема хранения паролей SMD5
Данная схема усиливает основную схему MD5 путём добавления "соли" (то есть, случайных данных), что означает, что одному и тому же паролю в открытом виде может соответствовать множество форм представления хэша. Например, оба этих значения представляют собою один и тот же пароль:
userPassword: {SMD5}4QWGWZpj9GCmfuqEvm8HtZhZS6E=
userPassword: {SMD5}g2/J/7D5EO6+oPdklp5p8YtNFk4=
14.4.5. Схема хранения паролей SHA
Как и схема MD5, эта схема просто пропускает пароль через процесс хэширования SHA. SHA считается более безопасным, чем MD5, но отсутствие "соли" делает её уязвимой к атакам по словарю.
userPassword: {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=
14.4.6. Схема хранения паролей SASL
На самом деле это вовсе не схема хранения паролей. Она использует значение атрибута userPassword, чтобы делегировать проверку пароля другому процессу. Подробности смотрите ниже.
Примечание: Это не то же самое, что и использование SASL для аутентификации сессии LDAP.
14.5. Сквозная аутентификация
Начиная с OpenLDAP 2.0 у slapd появилась возможность делегировать проверку пароля отдельному процессу. При этом используется функция sasl_checkpass(3), таким образом в процессе проверки может быть задействован любой механизм, который поддерживается Cyrus SASL для проверки пароля. Выбор механизмов очень широк, одна из возможностей - использовать saslauthd(8), который настраивается на использование локальных файлов, Kerberos, сервера IMAP, другого сервера LDAP, или чего-либо еще, поддерживаемого механизмом PAM.
Для включения сквозной аутентификации сервер должен быть собран с опцией конфигурации --enable-spasswd.
Замечание: Это не то же самое, что и использование SASL для аутентификации сессии LDAP.
Сквозная аутентификация работает только с паролями в открытом виде, такими, которые используются в механизмах аутентификации "simple bind" и "SASL PLAIN".
Сквозная аутентификация происходит выборочно: она применяется только к тем пользователям, у которых значение атрибута userPassword имеет префикс схемы "{SASL}". Формат этого атрибута:
userPassword: {SASL}username@realm
username и realm передаются механизму аутентификации SASL и используются для идентификации аккаунта, пароль которого проверяется. Это позоляет произвольно связывать записи в OpenLDAP с аккаунтами, известными сторонним механизмам аутентификации.
Пользователям, у которых включена сквозная аутентификация, целесообразно, посредством контроля доступа, запретить менять свои пароли через LDAP.
14.5.1. Настройка slapd на использование поставщика аутентификации
Для записей, имеющих значение атрибута пароля со схемой "{SASL}", OpenLDAP полностью делегирует процесс проверки пароля записи Cyrus SASL. Таким образом, все настройки делаются в конфигурационных файлах SASL.
Первый файл, который нужно рассмотреть, имеет запутанное название slapd.conf и обычно находится в директории библиотек SASL, часто расположенной в /usr/lib/sasl2/slapd.conf. Этот файл управляет работой SASL при их совместном использовании со slapd, а также применяется при использовании механизмов SASL для сквозной аутентификации. Детальную информацию можно найти на странице options.html в документации Cyrus SASL. Вот простой пример для сервера, который будет использовать saslauthd для проверки паролей:
mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/run/sasl2/mux
14.5.2. Настройка saslauthd
saslauthd способен использовать много разных аутентификационных сервисов. За деталями обращайтесь к saslauthd(8). Распространённая практика - делегировать аутентификацию, частично или полностью, другому серверу LDAP. Вот пример файла saslauthd.conf для аутентификации через Microsoft Active Directory (AD):
ldap_servers: ldap://dc1.example.com/ ldap://dc2.example.com/ ldap_search_base: cn=Users,DC=ad,DC=example,DC=com ldap_filter: (userPrincipalName=%u) ldap_bind_dn: cn=saslauthd,cn=Users,DC=ad,DC=example,DC=com ldap_password: secret
В этом случае saslauthd запускается с аутентификационным механизмом ldap и с указанием объединять SASL realm с именем пользователя:
saslauthd -a ldap -r
Это означает, что строка "username@realm", которой заканчивается значение атрибута userPassword, будет использоваться для поиска в AD на совпадение с фильтром "userPrincipalName=username@realm". После этого осуществляется проверка пароля путём попытки подключения к AD с использованием записи, найденной в процессе поиска, и пароля, предоставленного клиентом LDAP.
14.5.3. Тестирование сквозной аутентификации
Как правило, тестирование лучше проводить сверху вниз, начиная от конечного поставщика аутентификации, и спускаясь через saslauthd и slapd к клиентам LDAP.
В приведённом выше примере с AD сначала проверяется возможность подключения к AD c теми DN и паролем, которые будет использовать saslauthd при подключении:
ldapsearch -x -H ldap://dc1.example.com/ \
-D cn=saslauthd,cn=Users,DC=ad,DC=example,DC=com \
-w secret \
-b '' \
-s base
Затем проверяется, может ли быть найден тестируемый AD-пользователь:
ldapsearch -x -H ldap://dc1.example.com/ \
-D cn=saslauthd,cn=Users,DC=ad,DC=example,DC=com \
-w secret \
-b cn=Users,DC=ad,DC=example,DC=com \
"(userPrincipalName=user@ad.example.com)"
Затем проверяется, может ли этот пользователь подключиться к AD:
ldapsearch -x -H ldap://dc1.example.com/ \
-D cn=user,cn=Users,DC=ad,DC=example,DC=com \
-w userpassword \
-b cn=user,cn=Users,DC=ad,DC=example,DC=com \
-s base \
"(objectclass=*)"
Если всё это работает, тогда и saslauthd сможет сделать то же самое:
testsaslauthd -u user@ad.example.com -p userpassword testsaslauthd -u user@ad.example.com -p wrongpassword
Теперь поместите волшебную последовательность в нужную запись в OpenLDAP:
userPassword: {SASL}user@ad.example.com
Теперь можно создать соединение с OpenLDAP, используя DN этой записи и пароль AD-пользователя.
