Преодоление ограничений, обнаруженных в Kerberos
Kerberos это все или ничего
Каждый сервис, работающий в сети, должен быть модифицирован для работы с Kerberos (или другим способом защищен от атак по сети) или удостоверения пользователей могут быть украдены или использованы повторно. В качестве примера может быть приведено использование Kerberos версий оболочек для удаленной работы (например через rsh и telnet), при наличии POP3 сервера, получающего пароли в незашифрованном виде.
Kerberos предназначен для однопользовательских рабочих станций
В многопользовательской среде Kerberos менее безопасен. Это потому, что он хранит билеты в каталоге /tmp, которая доступна для чтения всем. Если пользователь работает с несколькими другими пользователями одновременно на одном компьютере (т.е. в многопользовательской среде), возможна кража (копирование) билета другим пользователем.
Решить проблему можно с помощью параметра командной строки -c или (предпочтительно) с помощью переменной окружения KRB5CCNAME, но это делается редко. Для преодоления ограничения достаточно сохранять билет в домашнем каталоге пользователя и использовать простые ограничения на доступ к файлам.
От KDC зависит вся система
Архитектура системы такова, что KDC должен быть максимально защищен, поскольку главный пароль базы данных содержится в нем. На KDC не должно быть запущено никаких других сервисов и он должен быть защищен физически. Опасность велика, поскольку Kerberos хранит все пароли зашифрованными одним ключом (''главным'' ключом), который хранится в файле на KDC.
|
|
|
Хорошей новостью является то, что кража главного ключа не станет такой проблемой, как может показаться. Главный ключ используется только для шифрования базы данных Kerberos и в качестве seed для генератора случайных чисел. Поскольку доступ к KDC защищен, атакующий мало что сможет сделать с главным ключом.
Кроме того, если KDC станет недоступен (возможно по причине атак DoS или проблем в сети) сетевые сервисы будет невозможно использовать, поскольку аутентификация не может быть выполнена. Уменьшить последствия можно при наличии нескольких KDC (один главный и один или несколько резервных) и с аккуратно реализованной резервной аутентификацией (отлично подойдет PAM).
Недостатки Kerberos
Kerberos позволяет пользователям, хостам и сервисам производить аутентификацию друг друга. В нем нет механизма аутентификации KDC для пользователей, хостов или сервисов. Это означает, что поддельный kinit (например) может записывать все имена пользователей и паролей. Помочь решить проблему может security/tripwire или другой инструмент проверки целостности файловой системы.
Ресурсы и информация для дальнейшего изучения
|
|
|
• Kerberos FAQ (http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html)
• Разработка системы аутентификации: диалог в четырех сценах (http://web.mit.edu/Kerberos/www/dialogue.html)
• RFC 1510, Kerberos Network Authentication Service (V5) (http://www.ietf.org/rfc/rfc1510.txt?number=1510)
• Домашняя страница MIT Kerberos (http://web.mit.edu/Kerberos/www/)
• Домашняя страница Heimdal Kerberos (http://www.pdc.kth.se/heimdal/)
OpenSSL
Одной из программ, требующих особого внимания пользователей, является набор программ OpenSSL, включенный в FreeBSD. OpenSSL предоставляет уровень шифрования поверх обычных уровней соединения; следовательно, он может быть использован многими сетевыми приложениями и сервисами.
OpenSSL может использоваться для шифрования соединений почтовых клиентов, транзакций через интернет, например для кредитных карт, и многого другого. Многие порты, такие как www/apache13-ssl и mail/sylpheed-claws собираются с OpenSSL.
Замечание: В большинстве случаев в Коллекции Портов будет сделана попытка построения порта security/openssl, если только переменная WITH_OPENSSL_BASE не установлена явно в ''yes''.
Версия OpenSSL, включаемая в FreeBSD, поддерживает сетевые протоколы безопасности Secure Sockets Layer v2/v3 (SSLv2/SSLv3), Transport Layer Security v1 (TLSv1) и может быть использована в качестве основной криптографической библиотеки.
Замечание: Хотя OpenSSL поддерживает алгоритм IDEA, по умолчанию он отключен из-за патентных ограничений Соединенных Штатов. Для его использования необходимо ознакомиться с лицензией, и, если ограничения приемлемы, установить в make.conf переменную MAKE_IDEA.
|
|
|
Наиболее часто OpenSSL используется для создания сертификатов, используемых программными пакетами. Эти сертификаты подтверждают, что данные компании или частного лица верны и не подделаны. Если рассматриваемый сертификат не был проверен одним из нескольких сертификационных центров (''Certificate Authorities'' - CA), обычно выводится предупреждение. Центр сертификации представляет собой компанию, такую, как VeriSign (http://www.verisign.com), которая подписывает сертификаты для подтверждения данных частных лиц или компаний. Эта процедура не бесплатна и не является абсолютно необходимой для использования сертификатов; однако может успокоить некоторых особо осторожных пользователей.
Генерирование сертификатов
Для генерирования сертификатов доступна следующая команда:
# openssl req -new -nodes -out req.pem -keyout cert.pem
Generating a 1024 bit RSA private key
................++++++
.......................................++++++
writing new private key to 'cert.pem'
-----
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 code) [AU]:US
State or Province Name (full name) [Some-State]:PA
Locality Name (eg, city) []:Pittsburgh
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:Systems Administrator
Common Name (eg, YOUR name) []:localhost.example.org
Email Address []:trhodes@FreeBSD.org
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:SOME PASSWORD
An optional company name []:Another Name
Ввод после приглашения ''Common Name'' содержит имя домена. Здесь вводится имя сервера для верификации; помещение в это поле чего-либо кроме этого имени приведет к созданию бесполезного сертификата. Доступны и другие параметры, например срок действия, альтернативные алгоритмы шифрования и т.д. Полный список находится на странице справочного руководства openssl(1).
В текущем каталоге, из которого была вызвана вышеуказанная команда, должны появиться два файла. Файл req.pem с запросом на сертификацию может быть послан в центр выдачи сертификатов, который проверит введённые вами подтверждающие данные, подпишет запрос и возвратит сертификат вам. Второй созданный файл будет иметь название cert.pem и содержать приватный сертификационный ключ, который необходимо тщательно защищать; если он попадёт в руки посторонних лиц, то может быть использован для имитации лично вас (или вашего сервера).
Когда подпись CA не требуется, может быть создан самоподписанный сертификат. Сначала создайте ключ RSA:
# openssl dsaparam -rand -genkey -out myRSA.key 1024
Теперь создайте ключ CA:
# openssl gendsa -des3 -out myca.key myRSA.key
Используйте этот ключ при создании сертификата:
# openssl req -new -x509 -days 365 -key myca.key -out new.crt
В каталоге должно появиться два новых файла: подпись сертификата, myca.key и сам сертификат, new.crt. Они должны быть помещены в каталог, доступный для чтения только root, желательно внутри /etc. Права на каталог можно изменить chmod с параметрами 0700.
Дата добавления: 2018-10-26; просмотров: 166; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!