Сертифікат VPN не захищає ділянку LDAP

Вхід через VPN, який перевіряє облікові дані за каталогом, включає два окремі мережеві з’єднання. З’єднання користувача зі шлюзом захищене власним сертифікатом VPN і налаштуваннями протоколу. З’єднання шлюзу з каталогом — це інша сесія з власними налаштуваннями TLS, власним сховищем довіри та власними режимами відмови. Ніщо в першому не гарантує нічого в другому.

Саме ця асиметрія стоїть за входом, який виглядає зашифрованим і все ж надсилає пароль прив’язки відкритим текстом.

Два з’єднання, два рішення про довіру

Зовнішня сесія — це те, що бачить користувач: сертифікат, прив’язаний до імені хоста VPN, перевірений клієнтом і такий, що несе обмін автентифікації. Внутрішня сесія належить клієнту каталогу всередині шлюзу, який відкриває власне з’єднання і або узгоджує TLS, або ні. Кожна сторона перевіряє співрозмовника, з яким говорить, використовуючи матеріал з іншого файлу конфігурації. Неправильно налаштована внутрішня ділянка залишається невидимою з боку користувача, бо зовнішня ділянка працює рівно так, як задумано.

Тому збій тихий, а не гучний. Шлюз, який ніколи не перевіряє сертифікат каталогу, все одно правильно автентифікує користувачів; він просто робить це через канал, який не перевірив.

StartTLS і LDAPS, обрані свідомо

StartTLS відкривається як звичайний LDAP і підвищується на місці, зазвичай на порту 389. LDAPS запускає TLS разом із з’єднанням, зазвичай на 636. Обидва варіанти законні, і адаптер має відповідати тому, що пропонує каталог. Вимагати StartTLS — не те саме, що спробувати його і продовжити, коли підвищення не вдалося, і саме в цій різниці пароль прив’язки може витекти. Налаштуйте суворий режим і не допускайте незахищеного запасного шляху для прив’язки з паролем.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

Прапорець -ZZ — у цьому вся суть: запит завершується помилкою, а не продовжується мовчки без підвищення. Імена й облікові записи в цьому рядку — приклади. Документація OpenLDAP щодо TLS описує налаштування довіри, що стоять за цим.

Яке сховище довіри читає клієнт LDAP?

Клієнтська бібліотека OpenLDAP читає власну конфігурацію довіри — із системного файлу або з налаштування конкретного плагіна. Директива CA у VPN стосується партнерів VPN і не доводить, що бібліотека LDAP читає той самий файл. Використовуйте ім’я хоста каталогу, яке сертифікат справді покриває, плюс ланцюжок видавця, якому бібліотека довіряє. У Active Directory розгорніть сертифікат служби каталогу з правильним застосуванням для автентифікації сервера, а не робіть висновки з відображуваного імені.

Кожна адреса перемикання при відмові має задовольняти ту саму політику ідентичності. Середовище, де первинний вузол перевірено, а вторинний ні, гірше за середовище без перемикання, бо слабший шлях виявляється лише під час збою.

Обліковий запис прив’язки залишається окремою проблемою

Захист транспорту не зменшує того, що може робити обліковий запис прив’язки. Обсяг пошуку в каталозі, групова авторизація та привілеї службового облікового запису — окремі рішення, і широкий обліковий запис прив’язки залишається широким після ввімкнення TLS. Використовуйте найвужчий службовий обліковий запис і базу пошуку, які потрібні інтеграції, і записуйте кінцеву точку, режим TLS, власника довіри та процес поновлення разом з конфігурацією VPN.

Коли з’являється невідповідність сертифіката, розгорніть правильний сертифікат або ланцюжок. Вимкнення перевірки перетворює видиму невідповідність на невидиму і залишає другі довірчі відносини неперевіреними.

Два з’єднання, два власники, дві дати поновлення. Саме їхня роздільність у документації тримає вхід чесним.