Из этой статьи вы узнаете, как:
- Защитить каталог с помощью SSL и TLS
- Настроить и сгенерировать сертификаты клиента и сервера
- Рассмотрите вопросы, касающиеся работы брандмауэра
- Настроить методы доступа без аутентификации
- Настроить методы аутентификации с использованием учетных данных “пользователь/пароль”
До этого момента доступ к slapd осуществлялся по незащищенным каналам с использованием открытых, нешифрованных паролей. Этот метод называется простой аутентификацией. В данном разделе мы рассмотрим методы шифрования соединений между клиентами и сервером.
Использование SSL и TLS для защиты подключений
Вы можете быть знакомы с протоколом защищенных сокетов (Secure Sockets Layer, SSL) и протоколом защиты транспортного уровня (Transport Layer Security, TLS) как с протоколами, использующимися для защиты Web-транзакций. Всякий раз, используя ссылку URI с префиксом https, вы имеете дело с протоколом SSL или TLS. TLS является усовершенствованием протокола SSLv3 и в некоторых случаях имеет обратную совместимость с SSL. Из-за своей общей наследственности и совместимости эти два протокола часто рассматриваются вместе как единый протокол – SSL.
Протокол SSL использует сертификаты X.509 – файлы стандартизированного формата, содержащие цифровую подпись, поставляемую доверенной третьей стороной – центром сертификации (Certificate Authority, CA). Действительная цифровая подпись означает, что подписанные данные не были подделаны с момента их подписания. Если хотя бы один бит данных, содержащих цифровую подпись, будет изменен, эта подпись не сможет пройти проверку, и будет являться недействительной. Независимые участники процессов, такие как клиент и сервер, могут выполнять проверку цифровых подписей, поскольку на обоих из них настроены доверительные отношения с центром сертификации.
Сертификат сервера содержит информацию о владельце сервера, включающую в себя публичное Интернет-имя сервера. Таким образом, вы можете быть уверены, что подключаетесь именно тому серверу, к которому намереваетесь подключиться, поскольку его имя в точности соответствует имени, указанному в сертификате (при условии, что вы доверяете центру сертификации, проверившему и подписавшему сертификат). Кроме того, сертификат содержит открытый ключ сервера, который может использоваться для шифрования данных. Если данные зашифрованы таким ключом, то расшифровать и прочесть их сможет только владелец секретного (личного) ключа.
Открытый и секретный ключи формируют основу метода шифрования с использованием открытого ключа, или ассиметричного шифрования. Шифрование является ассиметричным по той причине, что информация, зашифрованная с помощью открытого ключа, может быть расшифрована только с помощью секретного ключа, и наоборот – информация, зашифрованная с помощью секретного ключа, может быть расшифрована только с помощью открытого. Для шифрования данных в традиционном понимании (например, сохранение в тайне определенного сообщения) используется первый метод – открытый ключ является публичным, а личный ключ хранится в секрете. Благодаря механизму ассиметричного шифрования, зашифровать сообщение можно с помощью секретного ключа, а любой владелец открытого ключа сможет расшифровать его – именно так работают цифровые подписи.
После того как клиент подключается к серверу и получает его сертификат, он может проверить, соответствует ли имя сервера заявленному. Это помогает защититься от атак типа man in the middle (человек посередине). Открытый ключ можно использовать в определенном протоколе, работа которого завершается тем, что клиент и сервер договариваются об использовании общего секретного ключа, который не может быть определен ни одной наблюдающей за соединением стороной. В дальнейшем этот секретный ключ используется для шифрования оставшихся данных соединения между клиентом и сервером – этот процесс называется симметричным шифрованием, поскольку для шифрования и расшифровки данных используется один и тот же ключ. Разделение на асимметричный и симметричный методы шифрования существует по той причине, что последний из них работает на порядок быстрее. Шифрование на основе открытого ключа используется для аутентификации и установления договоренности об использовании общего секретного ключа, после чего в действие вступает симметричное шифрование.
Чтобы применить все вышеизложенное к OpenLDAP, необходимо создать сертификат сервера и настроить сервер на его использование. В нашем примере будет использоваться самоподписанный сертификат, а не сертификат, выпущенный центром сертификации. Это означает, что конечный сертификат будет подписан им же самим. Такой подход не обеспечивает того уровня доверия, как в случае использования подписи ЦС, но этого оказывается вполне достаточно для целей тестирования. В листинге 14 показан процесс генерации ключей.
Листинг 14. Генерация пары ключей TLS
[root@bob ssl]# openssl genrsa -out ldap.key 1024
Generating RSA private key, 1024 bit long modulus
.................................++++++
.........................++++++
e is 65537 (0x10001)
|
В листинге 14 показан процесс генерации ключа, запущенный путем выполнения команды openssl genrsa. Длина ключа составляет 1024 бита и на сегодняшний день считается достаточной для открытых ключей (обратите внимание, что использование более длинных ключей приводит к замедлению криптографических операций и может ввести в замешательство некоторых клиентов). Далее команда openssl req берет открытую часть только что созданной пары ключей, добавляет некоторую информацию о местоположении и запаковывает получившийся результат – запрос на подписание сертификата (Certificate Signing Request, CSR), который должен быть подписан центром сертификации. Этот процесс показан в листинге 15.
Листинг 15. Создание запроса на подписание сертификата
[root@bob ssl]# openssl req -new -key ldap.key -out ldap.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter em) [GB]:CA State or Province Name (full name) [Berkshire]:Manitoba Locality Name (eg, city) [Newbury]:Winnipeg Organization Name (eg, company) [My Company Ltd]:ERTW Organizational Unit Name (eg, section) []:Directory Services Common Name (eg, your name or your server's hostname) []:masterserver.ertw.com Email Address []:sean@ertw.comPlease enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: |
Сформированный файл ldap.csr (а также платеж на довольно приличную сумму) можно послать в центр сертификации на подпись. Эта же процедура используется для генерации сертификата Web-сервера. Если вы посылаете ваш запрос на подпись в ЦС, убедитесь, что вся указанная вами информация написана без ошибок, аббревиатуры используются только для поля Country Name, а поле Common Name в точности совпадает с DNS-именем вашего сервера, которое будет использоваться клиентами для подключения к нему.
Вместо того чтобы подписать запрос CSR в центре сертификации, в нашем примере мы сделаем это самостоятельно, как показано в листинге 16.
Листинг 16. Подписывание запроса CSR
[root@bob ssl]# openssl x509 -req -days 1095 -in ldap.csr -signkey ldap.key -out ldap.cert Signature ok subject=/C=CA/ST=Manitoba/L=Winnipeg/O=ERTW/OU=Directory Services/ CN=masterserver.ertw.com/emailAddress=sean@ertw.com Getting Private key |
В листинге 16 показан процесс подписания ключа, запущенный путем выполнения команды openssl x509. Опция-req говорит команде openssl о том, что входным файлом является запрос на подписание сертификата. Срок действия сертификата составляет 1095 дней, или 3 года. Теперь у вас есть файлы ldap.key (личный ключ) и ldap.cert (сертификат и открытый ключ).
Прежде чем продолжить, добавьте в файл /etc/openldap/ldap.conf строку TLS_REQCERT allow, которая указывает клиентским утилитам LDAP игнорировать факт использования самоподписанного сертификата. Если вы не добавите эту строку, а будете использовать параметры по умолчанию, сертификат будет считаться недействительным.
Настроить OpenLDAP на использование нового ключа и сертификата несложно. Предполагая, что сгенерированные ключи хранятся в папке /etc/openldap/ssl/, строки в листинге 17 настраивают ваш сервер на использование TLS-подключений после перезапуска slapd.
Листинг 17. Настройка slapd на использование SSL
TLSCertificateFile /etc/openldap/ssl/ldap.cert TLSCertificateKeyFile /etc/openldap/ssl/ldap.key |
Команды в листинге 17 указывают службе slapd местоположение сертификата и личного ключа. Чтобы проверить работу сервера после выполнения вышеуказанных настроек, выполните команду ldapwhoami -v -x -Z, которая анонимно привязывается к безопасному порту. Если вы получите сообщение “success”, значит, все работает правильно. В противном случае опция -v поможет вам установить причину возникшей ошибки.
Таким же способом вы можете сгенерировать сертификат клиента, что не является обязательной процедурой. В этом случае вместо использования команд, приведенных в листинге 17, добавьте строки TLS_KEY и TLS_CERT с соответствующими значениями в файл ldap.conf. Эти строки указывают на местоположения ключа и сертификата, соответственно. Клиентские сертификаты необходимы только в тех случаях, когда вам требуется выполнять идентификацию клиентов на основе их сертификатов.
Вопросы, касающиеся работы брандмауэра
LDAP использует TCP-порт 389, а LDAPS (LDAP поверх SSL) – TCP-порт 636. Если между вашим сервером и клиентами работает брандмауэр, то для успешного подключения эти порты должны быть открыты. Клиенты всегда подключаются к серверам, а серверы могут подключаться к другим серверам в зависимости от вашей стратегии репликации.
Правила iptables в ОС Linux
Если для настройки брандмауэра на вашем сервере LDAP используются правила iptables, вам необходимо изменить их таким образом, чтобы позволить серверу принимать входящие подключения. Как правило, команд, приведенных в листинге 18, оказывается достаточно.
Листинг 18. Добавление правил iptables для разрешения подключений к LDAP
iptables -A INPUT -p tcp --dport 389 -j ACCEPT iptables -A INPUT -p tcp --dport 636 -j ACCEPT |
Команды листинга 18 работают, если у вас используется простая политика. Команда -A INPUT добавляет правило в таблицу INPUT, которая предназначена для проверки всех входящих пакетов. Вы можете добавить эти правила в начало списка (используя команду -I INPUT вместо -A INPUT) или использовать инструменты для работы с брандмауэром из состава вашего дистрибутива, чтобы открыть TCP-порт 389, а также порт 636 (если вам нужна функциональность LDAPS).
ваш брандмауэр Linux используется в качестве маршрутизатора (например, клиенты подключены к одному сетевому интерфейсу, а сервер LDAP – к другому), то вместо INPUT вы должны использовать цепочку FORWARD . Возможно, вы захотите определить интерфейс для входящих пакетов с помощью опции -i, например -i eth0, чтобы указать, что приниматься будут только пакеты, приходящие на интерфейс eth0. Если пакет был принят, то также будут приняты и ответные пакеты.
Защита посредством использования оболочек TCP
ной из опций конфигурирования, доступной при компиляции пакета OpenLDAP, является опция –enable-wrappers, которая связывает конечные исполняемые файлы с библиотеками оболочек TCP (TCP Wrappers). Для принятия или отклонения клиентских подключений оболочки TCP используют два файла: /etc/hosts.allow и /etc/hosts.deny соответственно.
Прежде всего, проверьте с помощью команды ldd /usr/sbin/slapd | grep libwrap, использует ли slapd оболочки TCP. Если вы получите какой-либо ответ на вышеуказанный запрос, значит, оболочки TCP используются. В противном случае необходимо выполнить повторную компиляцию slapd с опцией –enable-wrappers или использовать правила iptables, как было описано выше.
Включив поддержку TCP Wrappers, вы можете запретить доступ к серверу LDAP для всех клиентов, добавив в файл /etc/hosts.deny строку slapd: ALL. После этого вы можете разрешить доступ с определенных IP-адресов, например, добавив строку slapd: 192.168.1.,127.0.0.1, которая разрешает подключаться любым клиентам сети 192.168.1.0/24 или любым локальным клиентам. Обратите внимание на то, что отклонение клиента оболочками TCP происходит следующим образом: сначала клиент подключается, а затем автоматически отключается. Этот процесс отличается от работы брандмауэра, когда пакет отбрасывается прежде, чем он достигнет службы slapd.
Формат файлов hosts.allow и hosts.deny позволяет разрешать и отклонять подключения многими различными способами. Для получения дополнительной информации обратитесь к man-руководству hosts_access(5).
Дополнительные сведения об аутентификации
До сих пор обсуждение вопросов аутентификации не выходило за рамки рассмотрения открытых паролей, определенных в файле slapd.conf, и методов простой аутентификации между клиентом и сервером. Проблема использования нешифрованных паролей решается с помощью команды slappasswd. Введите в командной оболочке команду slappasswd, после чего вам будет предложено ввести и подтвердить пароль. На выходе вы получите безопасный хэш пароля, такой как {SSHA}oxmMsm9Ff/xVQ6zv+bgmMQjCUFL5x22+. Математические методы гарантируют, что этот хэш необратим, хотя если кто-то получит его в свои руки, он может начать пробовать перебирать различные пароли и проверять, будет ли их хэш совпадать с исходным.
Вы уже имели дело с анонимной привязкой к каталогу, когда имя пользователя и пароль не указываются, а также с привязкой на основе аутентификации, когда клиент должен указать свои действующие имя пользователя и соответствующий ему пароль. Кроме этого OpenLDAP поддерживает привязку без аутентификации, когда указывается имя пользователя, но не указывается пароль. Привязка без аутентификации обычно отключена; для ее включения необходимо добавить в файл конфигурации строку allow bind_anon_cred. Если включена привязка без аутентификации, то все подключения, выполненные таким способом, считаются анонимными.
Альтернативу простой аутентификации составляет простая аутентификация и слой безопасности (Simple Authentication and Security Layer, SASL) – платформа для поддержки подключаемых модулей аутентификации и шифрования. Более подробно архитектура SASL будет рассмотрена в руководстве, которое должно скоро появиться, а пока ограничимся тем, что SASL предусматривает различные методы аутентификации – от открытых паролей до Kerberos.
При рассмотрении списков управления доступом в предыдущей части руководства было упомянуто, что доступ может быть предоставлен на основе метода подключения, определяющего фактор уровня защиты (Security Strength Factor, SSF). Нешифрованное соединение имеет SSF, равный 0, а шифрованному соединению обычно соответствует значение SSF, равное длине ключа шифрования. Таким образом, определенное правило ACL может содержать в условии who требование к уровню защиты подключения (строка ssf=1).
Постовой
Продажа современных бытовых GYSMI (Франция) и профессиональных или промышленных SELCO (Италия) сварочных инверторов. Компактные (умещаются в кейсе), легкие и надежные сварочные инверторы помогут без особого труда быстро выполнить сварочные работы. Не требуют специальных навыков и подготовки.
One Comment