Програмне забезпечення OpenLDAP розроблено для функціонування в самих різних обчислювальних середовищах, від тотально-контрольованих закритих мереж до глобального Інтернет. Тому програмне забезпечення OpenLDAP підтримує безліч різних механізмів безпеки. У цьому розділі описуються дані механізми і обговорюються питання безпеки використання OpenLDAP.
Додаткова інформація в підрозділі Параметри командного рядка і slapd (8).
Зазвичай, slapd (8) слухає 389 / tcp для сесій ldap: // і порт 636 / tcp для сесій ldaps: //. Його також можна налаштувати для прослуховування інших портів.
Оскільки налаштування IP-фаевола залежать від конкретного типу IP-фаервола, тут не наводиться жодних прикладів. Дивіться документацію до Вашого IP-фаєрвол.
slapd (8) підтримує TCP Wrappers. TCP Wrappers є засновану на правилах систему розмежування доступу для контролю доступу до сервера по TCP / IP. Наприклад, правило host_options (5):
дозволяє для доступу до служби каталогів тільки вхідні з'єднання з приватної мережі 10.0.0.0 і з localhost (127.0.0.1).
Майте на увазі, що для TCP wrappers потрібно вказувати з'єднання, які будуть прийматися. Оскільки в більшості випадків, навпаки, потрібно забороняти з'єднання, краще використовувати захист IP-фаєрволом, ніж TCP wrappers.
Додаткова інформація про правила TCP wrapper в hosts_access (5).
Для забезпечення цілісності даних і захисту конфіденційності можна використовувати Transport Layer Security (TLS). OpenLDAP підтримує узгодження TLS (SSL) як через StartTLS, так і через ldaps: //. Для отримання додаткової інформації дивіться розділ Використання TLS. StartTLS -Стандартний механізм установки з'єднання.
Також, в рамках забезпечення цілісності даних і захисту конфіденційності, підтримується кілька механізмів Simple Authentication and Security Layer (SASL), таких як DIGEST-MD5 і GSSAPI. Для отримання додаткової інформації дивіться розділ Використання SASL.
Сервер використовує фактори сили безпеки (Security Strength Factor s, SSF) для вказівки відносної сили захисту. SSF рівний 0, вказує на те, що захисту не потрібно. SSF рівний 1, вказує на те, що потрібен захист цілісності. SSF більший одиниці (> 1), приблизно корелює з ефективною довжиною ключа шифрування. Наприклад, DES становить 56, 3DES становить 112, і AES - 128, 192 або 256.
В рамках сесії LDAP кількість адміністративного контролю, що накладається за допомогою SSF, асоціюється зі ступенем захисту засобами TLS і SASL.
Елементи управління security не дозволяють виконання операції, якщо не дотримується зазначена ступінь захисту. наприклад:
вимагає захисту цілісності для всіх операцій, а для операцій оновлення (таких як додавання, видалення, зміна) вимагає шифрування, еквівалентного 3DES. Детальний опис можна подивитися в slapd.conf (5).
SSF можна використовувати при контролі доступу з метою встановлення більш точного контролю. Для отримання додаткової інформації дивіться розділ Контроль доступу.
У простого методу аутентифікації LDAP три режими роботи:
- надання доступу анонімному користувачу,
- надання доступу користувачеві без проходження перевірки автентичності, і
- надання доступу користувачеві з перевіркою достовірності на ім'я користувача і паролю.
Запит анонімного доступу відбувається, коли при виконанні операції підключення за методом "simple" не передається ні імені користувача, ні пароля. Запит на надання доступу користувачеві без проходження перевірки автентичності відбувається, коли при підключенні передається тільки ім'я користувача, а пароль не передається. Нарешті, запит на надання доступу користувачеві з перевіркою достовірності відбувається, коли при підключенні передаються чинні ім'я користувача та пароль.
Примітка: Відключення механізму анонімного підключення не запобігає анонімного доступу до каталогу. Щоб для доступу до бази завжди була потрібна аутентифікація, замість наведеної вище директиви слід вказати "require authc".
Механізм підключення з перевіркою достовірності на ім'я користувача і паролю може бути повністю відключений за допомогою директиви "disallow bind_simple".
Метод аутентифікації LDAP SASL дозволяє використовувати будь-який аутентифікаційний механізм SASL. Застосування даного методу обговорюється в розділі Використання SASL.
Паролі LDAP зазвичай зберігаються в атрибуті userPassword. У RFC4519 зазначено, що паролі не повинні зберігатися в зашифрованому (або хешірованного) формі. Тим самим дозволяється використання широкого кола механізмів аутентифікації на основі паролів, таких як DIGEST-MD5. Така схема зберігання є також найбільш сумісної з реалізаціями системи аутентифікації в різних клієнтських програмах.
Однак, на практиці, найчастіше бажано все ж зберігати хеш пароля. slapd (8) працює з багатьма схем зберігання на вибір системного адміністратора.
Примітка: Значення атрибутів пароля, незалежно від використовуваної схеми зберігання, повинні захищатися також, як якщо б вони зберігалися у відкритому вигляді. Хешірованние паролі схильні до атак за словником і атакам методом повного перебору.
Атрибут userPassword може мати більше одного значення, і всі вони можуть зберігатися в різній формі. У процесі аутентифікації slapd буде послідовно проходити за значеннями, поки не знайде такого, яке відповідає запропонованим паролю, або поки значення не закінчаться. Схема зберігання вказується як префікс до значення, тобто пароль, захешірованний за схемою Salted SHA1 (SSHA) виглядає так:
Перевага хешірованних паролів полягає в тому, що зломщик, який одержує доступ до хешу, не має прямого доступу до цього паролю. На жаль, вони досить просто підбираються за допомогою атак за словником або методом повного перебору, тому таку перевагу досить примарно (ось чому всі сучасні Unix-системи використовують парольний файл shadow).
Недолік хешірованного зберігання паролів полягає в тому, що вони не є стандартними і можуть викликати проблеми з сумісністю. Це може привести до того, що використання будь-яких пральних механізмів аутентифікації, сильніше Simple (або SASL / PLAIN), взагалі виключається.
Це версія схеми SHA з "сіллю". Вона вважається найбільш безпечною схемою зберігання паролів, підтримуваної slapd.
Ці значення є один і той же пароль:
Ця схема використовує функцію хешування crypt (3) операційної системи. Як правило, в цій схемі генеруються традиційні 13-символьні хеші в стилі Unix, але на системах з glibc2 також можуть генеруватися безпечніші 34-байтниє хеші MD5.
Перевага схеми CRYPT полягає в тому, що паролі можуть бути перенесені з існуючого парольного файлу Unix він не потребує спеціальних паролі у відкритому вигляді. Обидві форми crypt використовують "сіль", тому вони мають певну стійкість до атак за словником.
Примітка: Оскільки ця схема використовує функцію хешування crypt (3) операційної системи, вона є специфічною для кожної операційної системи.
Ця схема просто бере MD5-хеш від пароля і зберігає його в base64-закодованої формі:
Це не дуже безпечна схема, хоча і безпечніше зберігання у відкритому вигляді. MD5 - швидкий алгоритм, і оскільки він не використовує "сіль", дана схема зберігання вразлива для атак за словником.
Дана схема підсилює основну схему MD5 шляхом додавання "солі" (тобто, випадкових даних), що означає, що одному і тому ж паролю у відкритому вигляді може відповідати безліч форм представлення хеша. Наприклад, обидва цих значення представляють собою один і той же пароль:
Як і схема MD5, ця схема просто пропускає пароль через процес хешування SHA. SHA вважається більш безпечним, ніж MD5, але відсутність "солі" робить її вразливою до атак за словником.
Насправді це зовсім не схема зберігання паролів. Вона використовує значення атрибута userPassword. щоб делегувати перевірку пароля іншому процесу. Подробиці дивіться нижче.
Примітка: Це не те ж саме, що і використання SASL для аутентифікації сесії LDAP.
Починаючи з OpenLDAP 2.0 у slapd з'явилася можливість делегувати перевірку пароля окремому процесу. При цьому використовується функція sasl_checkpass (3). таким чином в процесі перевірки може бути задіяний будь-який механізм, який підтримується Cyrus SASL для перевірки пароля. Вибір механізмів дуже широкий, одна з можливостей - використовувати saslauthd (8). який налаштовується на використання локальних файлів, Kerberos, сервера IMAP, іншого сервера LDAP, або чого-небудь ще, підтримуваного механізмом PAM.
Для включення наскрізний аутентифікації сервер повинен бути зібраний з опцією конфігурації --enable-spasswd.
Зауваження: Це не те ж саме, що і використання SASL для аутентифікації сесії LDAP.
Наскрізна аутентифікація працює тільки з паролями у відкритому вигляді, такими, які використовуються в механізмах аутентифікації "simple bind" і "SASL PLAIN".
Наскрізна аутентифікація відбувається вибірково: вона застосовується тільки до тих користувачам, у яких значення атрибута userPassword має префікс схеми "". Формат цього атрибута:
Користувачам, у яких включена наскрізна аутентифікація, доцільно, за допомогою контролю доступу, заборонити змінювати свої паролі через LDAP.
Для записів, що мають значення атрибута пароля зі схемою "", OpenLDAP повністю делегує процес перевірки пароля записи Cyrus SASL. Таким чином, всі настройки робляться в конфігураційних файлах SASL.
Перший файл, який потрібно розглянути, має заплутане назву slapd.conf і зазвичай знаходиться в директорії бібліотек SASL, часто розташованої в /usr/lib/sasl2/slapd.conf. Цей файл управляє роботою SASL при їх спільному використанні з slapd. а також застосовується при використанні механізмів SASL для наскрізної аутентифікації. Детальну інформацію можна знайти на сторінці options.html в документації Cyrus SASL. Ось простий приклад для сервера, який буде використовувати saslauthd для перевірки паролів:
saslauthd здатний використовувати багато різних аутентифікаційних сервісів. За деталями звертайтеся до saslauthd (8). Поширена практика - делегувати аутентифікацію, частково або повністю, іншого сервера LDAP. Ось приклад файлу saslauthd.conf для аутентифікації через Microsoft Active Directory (AD):
В цьому випадку saslauthd запускається з аутентифікаційних механізмом ldap і з зазначенням об'єднувати SASL realm з ім'ям користувача:
Це означає, що рядок "username @ realm", якою закінчується значення атрибута userPassword. буде використовуватися для пошуку в AD на збіг з фільтром "userPrincipalName = username @ realm". Після цього здійснюється перевірка пароля шляхом спроби підключення до AD з використанням запису, знайденої в процесі пошуку, і пароля, наданого клієнтом LDAP.
Як правило, тестування краще проводити зверху вниз, починаючи від кінцевого постачальника аутентифікації, і спускаючись через saslauthd і slapd до клієнтів LDAP.
У наведеному вище прикладі з AD спочатку перевіряється можливість підключення до AD c тими DN і паролем, які буде використовувати saslauthd при підключенні:
Потім перевіряється, чи може бути знайдений тестований AD-користувач:
Потім перевіряється, чи може цей користувач підключитися до AD:
Якщо все це працює, тоді і saslauthd зможе зробити те ж саме:
Тепер помістіть чарівну послідовність в потрібний запис в OpenLDAP:
Тепер можна створити з'єднання з OpenLDAP, використовуючи DN цього запису і пароль AD-користувача.