|
|
| Рядок 17: |
Рядок 17: |
| | и что бы при каждом старте запускался | | и что бы при каждом старте запускался |
| | '''chkconfig ldap on''' | | '''chkconfig ldap on''' |
| − |
| |
| − |
| |
| − |
| |
| − | == Защита LDAP при помощи SSL. ==
| |
| − |
| |
| − | В LDAP существует возможность защиты данных, передаваемых по
| |
| − | сети. При этом используется два метода: TLS и SASL. Первый из них не меняет
| |
| − | порта, на котором слушает LDAP(336), а просто организует аутентификацию
| |
| − | асимметрическим шифрованием, SASL же меняет порт LDAP на ldaps:// и соединение
| |
| − | идёт по-другому механизму: через туннель SASL. TLS намного проще в настройке,
| |
| − | поэтому я расскажу именно о нём. Для начала надо сгенерировать серверную пару
| |
| − | ключей асимметрического шифрования. Для этого в Linux удобно воспользоваться
| |
| − | единым центром сертификации OpenSSL(об этом я уже писал на страницах 2-го номера):
| |
| − |
| |
| − | а) создаем rsa ключ длиной 1024 бита и сохраняем его в файле ldap.key
| |
| − |
| |
| − | $ openssl genrsa -out ldap.key 1024
| |
| − |
| |
| − | б) создаём запрос на сертификацию
| |
| − |
| |
| − | $ openssl req -new -config .cfg -key ldap.key -out ldap.csr
| |
| − |
| |
| − | в) создаём сертификат, которому будем доверять(CACertificate); вначале делаем
| |
| − | ключ длиной 2048 бит:
| |
| − |
| |
| − | $ openssl genrsa -des3 -out ca.key 2048
| |
| − |
| |
| − | г) создаём self-signed сертификат сроком действия на год на основе сгенерированного ключа
| |
| − |
| |
| − | $ openssl req -new -x509 -days 365 -key ca.key -out ca.cert
| |
| − |
| |
| − | д) теперь на основе созданного для LDAP ключа и доверенного сертификата создаём
| |
| − | сертификат LDAP
| |
| − |
| |
| − | $ openssl x509 -req -in ldap.csr -out ldap.cert -CA ca.cert -CAkey ca.key -CAcreateserial \
| |
| − | -days 365 -extfile .cfg
| |
| − |
| |
| − | При этом файл конфигурации .cfg должен содержать следующие расширения:
| |
| − |
| |
| − | [ v3_req ]
| |
| − | subjectAltName = email:copy
| |
| − | basicConstraints = CA:false
| |
| − | nsComment = "LDAP server certificate"
| |
| − | nsCertType = server
| |
| − |
| |
| − | Немного страшновато выглядит, но в ходе всех этих действий создаются два
| |
| − | сертификата: доверенный сертификат и подписанный им сертификат сервера. Таким
| |
| − | образом, сервер LDAP сможет проверить правильность своего сертификата через
| |
| − | доверенный сертификат. Кстати, если у вас уже есть доверенные
| |
| − | сертификаты, то можно воспользоваться ими: просто пропустите шаги б) и в) и на
| |
| − | шаге г) введите имя своего доверенного сертификата(можно также воспользоваться
| |
| − | моим скриптом CA).
| |
| − |
| |
| − | Итак после всех этих действий перемещаем сертификаты и ключ сервера
| |
| − | LDAP(ldap.key) куда-нибудь в /etc/ssl/ldap(принято хранить все ключи и
| |
| − | сертификаты, созданные openssl в /etc/ssl) и делаем их доступными для чтения
| |
| − | только владельцу:
| |
| − |
| |
| − | #chmod 0400 /etc/ssl/ldap/*
| |
| − |
| |
| − | и меняем владельца на ldap
| |
| − |
| |
| − | #chown ldap:ldap /etc/ssl/ldap/*
| |
| − |
| |
| − | Настройка сервера предельно проста: необходимо просто прописать пути к
| |
| − | сертификатам и ключам в файле slapd.conf следующим образом:
| |
| − |
| |
| − | # Сертификат сервера
| |
| − | TLSCertificateFile /etc/ssl/ldap/ldap.cert
| |
| − | # Ключ сервера
| |
| − | TLSCertificateKeyFile /etc/ssl/ldap/ldap.key
| |
| − | # Доверенный сертификат
| |
| − | TLSCACertificateFile /etc/ssl/ldap/ca.cert
| |
| − |
| |
| − | Сервер можно конфигурировать и альтернативным методом - через туннель stunnel
| |
| − | или ssh. Обычно применяют stunnel, но для начала опять же генерируют
| |
| − | сертификат сервера(при этом сам LDAP не должен быть настроен для поддержки SSL
| |
| − | т.к. stunnel будет заменять встроенные механизмы SSL ldapa). После генерации
| |
| − | сертификата делаем следующее:
| |
| − |
| |
| − | #stunnel -r ldap -d 636 -p /etc/ssl/stunnel/stunnel.pem
| |
| − |
| |
| − | Записываем эту команду в один из init файлов и добавляем правило iptables для
| |
| − | отбрасывния сетевого трафика с порта 389 с целью повышения безопасности(это
| |
| − | запрещает доступ по сети к серверу ldap без механизма ssl). Для генерации
| |
| − | сертификата в данном случае можно применить скрипт для генерации stunnel
| |
| − | сертификатов, который обычно поставляется вместе с stunnel. Можно также
| |
| − | применить следующее:
| |
| − |
| |
| − | $ openssl req -new -x509 -days 365 -nodes -config stunnel.cnf \
| |
| − | -out stunnel.pem -keyout stunnel.pem
| |
| − | $ openssl gendh 512 >> stunnel.pem
| |
| − |
| |
| − | для генерации self-signed сертификата и параметров для ключей
| |
| − | Дифлемана-Хельмана.
| |
| − |
| |
| − | На самом деле через туннель у меня все работало просто на ура, а встроенные
| |
| − | механизмы работали несколько странно, хотя я перечитал все маны и руководства,
| |
| − | но это не помогло...
| |
| − |
| |
| − | Теперь перезапускаем slapd и настраиваем клиентов. Для настройки клиентов надо
| |
| − | прописать в файле ldap.conf следующие строки:
| |
| − |
| |
| − | # Аутентификация через TLS
| |
| − | ssl start_tls
| |
| − | # По умолчанию клиент пытается использовать обычное соединение, закомментировав
| |
| − | # следующую строчку мы ставим жирный крест на его безобразиях
| |
| − | #ssl off
| |
