Билет керберос не был принят сервером исходящей почты astra linux

Обновлено: 05.07.2024

1: PDC Win 2003 AD
2: Fedora 8 (sendmail, cyrus-imap, squid и прочее
3: любая linux машина (много штук)
Имеем полностью работоспособную структуру, когда любой сотрудник, являющийся членом домена на "1" при посадке за любою машину "3" получает полную автоматическую преднастройку в соответствии и наследованием со своими правами (гетерогенные сетевые диски, авторизованые туннели в сеть и VPN и прочую красоту, освобождающую меня от головной боли, т.к. машин очень много). Остается одна неразрешаемая задача: как преднастроить любую произвольную почтовую программу (можно даже через Web морду), чтобы клиентская часть забирала имя и пароль из первичной авторизации при входе (т.е. pam), как это происходит при работе с дисками, интернетом и прочее. Т.е. распознавание на "2" идет для всего, кроме cyrus-imap.
вводные данные: имеем рабочую saslauthd: pam при адекватном ответе testsaslauth. imtest -m PLAIN (LOGIN) отрабатывают, что видно через debug saslauthd.
По документации saslauthd держит kerberos5 - но документации я не нашел, нативно настроит не получилось. также интересно как отрабатывает imtest -m GSSAPI ибо при всех прочих равных он даже на saslauthd не стучиться. что наверное не правильно :). есть ли у кого опыт работы с GSSAPI? Крики и опусы о том что это через одно место и можно проще не принимаются, т.к. если бы знак как можно проще - сделал бы. но при диком кол-ве Win клиентов и одновременном присутствии не меньшего кол-ва lin, при этом конкретные логины скачут как зайцы по полю в грозу в одного терминала на другой.

ок. тогда такая конкретная задача.
3 ПК: Windows PDC, Linux Mail сервер, Linux клиент
Linux клиент введен в домен. Надо чтобы любой доменный пользователь заходил на машину и без ввода пароля мог получать и отправлять свою почту (не принципиально, конкретные клиенты типа Evolution, Opera mail или же Web морда на сервере, важно глянутьь сам механизм)

P.S. Т.е. ввод пароля пользователь осуществляет только один раз, когда логинится на машину.

>ок. тогда такая конкретная задача.
>3 ПК: Windows PDC, Linux Mail сервер, Linux клиент
>Linux клиент введен в домен. Надо чтобы любой доменный пользователь заходил на
>машину и без ввода пароля мог получать и отправлять свою почту
>(не принципиально, конкретные клиенты типа Evolution, Opera mail или же Web
>морда на сервере, важно глянутьь сам механизм)
>
>P.S. Т.е. ввод пароля пользователь осуществляет только один раз, когда логинится на
>машину.
юзер логинится -- проверяется доступ -- в случае успеха получает kerberos ключик
apache легко интегрируется с kerberos -- можно сказать тут проблем вообще нет
evolution и thunderbird умеют ggsapi -- (этот самый gssapi не что иное -- как обёртка поверх kerberos -- правда с фишками)
sasl gssapi тоже умеет -- только не всегда собран с поддежкой оного
postfix dovecot/cyrus-imap имеют sasl
-- всё это работает -- знаю потому как делал -- только вот конфигов у меня (к сожалению нет)
поддержка виндовых клиентов через spa+AD
виндовый thunderbird умеет gssapi -- НО насколько я помню нужно на каждой раб/станции установить MIT kerberos for windows -- хотя давно не пробывал -- может он теперь нативно научился -- через интерфейсы масдайя

Мне одному кажется или производилель, он же держатель форума, должен принять участие в решении наших вопросов?

Mrshll

New member

GRamoboi, что-то мне подсказывает, что не должен, по причине отсутствия у него инструкции, про которую тут обсуждают. Предоставить инструкцию кто-нибудь сможет (передать в открытый доступ) - тогда, как мне кажется, вам быстрее помогут. Пока коллеги общаются непонятными п.13 и ЕПП понять сложно, что и как настроено очень проблематично (мое предположение что НТП это ntp).
P.S.
Сильно отстал от жизни видать, но в округах появились штатные админы или это все самодеятельность срочников?

Fd1501h

Moderator

Для этого есть оф.саппорт.
+ инструкцию по которой вы выполняете настройку делал не РусБиТех (на сколько я понял по обсуждению в канале телеграмм), а непонятно кто.

Rayman

New member

Но я делаю по документации РусБитТеха. Что я делаю не так, мне до сих пор не ясно.. вот

Disternis

New member

Парни, решил кто-нибудь проблему с отправкой почты во внешнюю сеть? Лок

Fd1501h

Moderator

Но я делаю по документации РусБитТеха. Что я делаю не так, мне до сих пор не ясно.. вот

Rayman

New member

Естественно, жду.
Так же не ставится галочка через ПУСК-НАСТРОЙКИ-СЕРВИСЫ-работа сервиса в режиме ЕПП. Как лечится? Через PAM ставится

New member

Парни, решил кто-нибудь проблему с отправкой почты во внешнюю сеть? Лок

проверь /etc/exim4/update-exim.conf.conf параметр dc_relay_nets должен быть равен адресу внутренней подсети. Типа такого dc_relay_nets='f.q.d.0/24'. А потом применить /usr/sbin/update-exim4.conf

New member

Есть.
В топикстартере я описал настройку сервера. Этого должно быть достаточно. Dovecot использует аутентификацию pam, который в свою очередь, при подключении почтового сервера к домену, автоматически настраивается на использование Kerberos+Ldap. Поэтому никаких дополнительных настроек не требуется.

john434

New member

Настраиваются почтовый сервер. Локально все работает. Как только настраиваются его как основной dns, ald сервер перестаёт его видеть и bind9 не рестартует, выдаёт ошибку при рестарта. В чем может быть причина?

Disternis

New member

Дак это получается что почта будет зарелеина? Если я все правильно понял.

Disternis

New member

Есть решение. Перед тем как создаёшь принципалы на сервере, пропиши на всех АРМ ald-renew-tickets on. Это будет означать что билеты будут обновляться автоматически. Затем создавай принципалы на сервере. Далее на АРМ пиши kinit "имя пользователя" это чтобы получить билеты с сервера. И все должно получиться. Если нет то пиши ald-renew-tickets now.

Делюсь опытом в описанных технологиях. Блог в первую очередь выполняет роль памяток для меня самого.

4.14.2019

Настройка Exim4 / Dovecot в Astra Linux SE 1.5

Исходные данные и задачи

Необходимо настроить сервер электронной почты, работающий в рамках домена Astra Linux 1.5 SE. Исходные данные:

Настройка сети

Отключаем графический менеджер управления сетевыми подключениями wicd .

Прописываем настройки сети в файле /etc/network/interfaces

После этого нужно выполнить перезапуск демона сети:

В документации к демону networking написано, что команда restart является устаревшей и работает не так, как ожидается.

Необходимо в файле /etc/hosts прописать соответствие FQDN сервера и его IP-адреса, а также задать hostname

Инициализация домена

Действуем согласно официальной инструкции от РусБиТех:

Появится уведомление о том, что команда init уничтожит всю базу данных LDAP и Kerberos, будут остановлены и перезапущены службы, и упадет с неба большая звезда, горящая подобно светильнику, и падет на третью часть рек и на источники вод. Отвечаем утвердительно

Попросят ввести пароли для доступа к базе данных Kerberos и пароль администратора Astra Linux Directory. Лучше записать куда-нибудь, потому что понадобится ещё не раз.

Установка и настройка почтовых сервисов.

Необходимо установить три пакета:

Отдельно отмечу, что сразу же после установки нужно будет запустить конфигурирование exim4 .

Процесс настройки exim4 не очень сложный, но нужно правильно ответить на несколько вопросов.

Теперь нужно удалить из каталога /var/mail файл с именем пользователя, созданного при установке системы (у меня обычно administrator ).

Создадим сервисы ALD для работы с почтой:

После создания файла ключей нужно предоставить доступ к нему для dovecot :

Dovecot

Выполняем настройку dovecot . Если убрать все комментарии из файлов, то получится примерно следующее (в тех файлах, где меняли):

Изучение

Протокол безопасности Kerberos стал основой современной кибербезопасности. Фактически, он настолько хорошо интегрирован, что большинство пользователей или даже разработчиков вообще забывают о нем. Этот скрытый статус может затруднить получение информации о том, что такое Kerberos и как он работает, особенно со всеми различными формами, которые этот протокол принимает сегодня.

В этой статье мы ответим, что такое Kerberos, как он работает, и рассмотрим типичные атаки, которые инженеры безопасности Kerberos должны преодолевать ежедневно.

К концу вы получите новую оценку современной сетевой безопасности и, надеюсь, пик интереса к кибербезопасности!

Что такое Kerberos?

Kerberos — это протокол проверки подлинности компьютерной сети, предназначенный для упрощения и безопасности проверки подлинности.

Основная идея Kerberos вращается вокруг использования локальной формы личной идентификации, называемой билетами, которые предоставляются сервером аутентификации. Каждый билет принадлежит определенным областям, которые определяют, к каким службам он предоставляет доступ. Эти билеты зашифрованы, и для их использования требуется несколько уровней дешифрования. Эта система билетов гарантирует, что конфиденциальная информация, такая как пароли, никогда не будет отправлена по сети.

Протокол Kerberos получил широкое признание с момента его создания в Массачусетском технологическом институте в 1980-х годах. Теперь он встроен в бесчисленное количество зависимых от безопасности реализаций в Интернете, и почти все компании ежедневно взаимодействуют по крайней мере с одной системой Kerberos.

Наиболее известное использование Kerberos — это Microsoft Active Directory, служба каталогов по умолчанию, включенная в Windows 2000 и более поздних версий для управления доменами и аутентификации пользователей.

Другие известные применения — Apple, НАСА, Google, Министерство обороны США и университеты по всей территории Соединенных Штатов.

Преимущества Kerberos

Kerberos так широко используется из-за его простоты и непревзойденной безопасности данных. Вот лишь некоторые из его преимуществ:

Взаимная аутентификация: в Kerberos оба конца связи должны быть аутентифицированы, прежде чем соединение будет разрешено. Взаимная аутентификация резко снижает возможность мошенников обманным путем заставить системы отправлять конфиденциальную информацию.

Пример взаимной аутентификации:

Пользователь в сети, использующий Kerberos, может пройти аутентификацию на почтовом сервере, чтобы доказать, что он тот, за кого себя выдает. С другой стороны, почтовый сервер также должен подтвердить, что он действительно является почтовым сервером, а не какой-либо другой службой в сети, претендующей на роль почтового сервера. Если обе стороны аутентифицированы, соединение устанавливается.

Основные компоненты Kerberos

Центр распространения ключей

Билет на выдачу билетов

Этот билет выдается KDC после успешной аутентификации клиента. TGT зашифрован и содержит разрешения на то, к каким службам может получить доступ клиент, как долго предоставляется доступ, а также ключ сеанса, используемый для связи с клиентом.

Клиенты не могут расшифровать TGT, так как у них нет ключа TGS. Следовательно, они должны слепо представить TGT желаемым службам (которые могут получить доступ к TGS) и позволить службам решить, может ли клиент получить к нему доступ.

Скрывая TGT от клиента, Kerberos предотвращает мошенническое копирование или изменение разрешений клиентом.

Сервер аутентификации

Сервер аутентификации — это первая остановка при аутентификации с помощью Kerberos. Сначала клиент должен аутентифицироваться в AS, используя имя пользователя и пароль для входа.

После этого AS перенаправляет имя пользователя в KDC, который, в свою очередь, предоставляет TGT. Без выполнения этого первого шага клиент не сможет взаимодействовать с какой-либо другой частью системы Kerberos.

Служба выдачи билетов

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

Затем TGS аутентифицирует TGT и устанавливает сеансовый ключ, совместно используемый сервером и клиентом. Если TGS подтверждает, что клиентский TGT включает доступ к желаемой службе, клиенту предоставляется доступ для запроса услуги.

Как работает Kerberos?

Проверка подлинности Kerberos состоит из 4 этапов, в зависимости от того, какие компоненты взаимодействуют между собой:

Пример процесса Kerberos

Каждый из этих этапов состоит из нескольких этапов, но в режиме реального времени процесс происходит очень быстро. Чтобы поместить то, что мы узнали выше, в контекст, давайте рассмотрим пример из реальной жизни.

В начале рабочего дня вы вводите пароль в свой клиент. Пароль аутентифицируется AS, а затем KDC предоставляет вам TGT. В этом билете есть набор ключей от dataScienceкоролевства.

Затем TGT кэшируется на вашем компьютере для дальнейшего использования. Этот доступ позволяет вам использовать любые услуги в dataScienceобласти, например, доступ к покупательскому поведению клиентов.

Затем вы можете получить доступ к этой службе в любое время без необходимости каждый раз аутентифицировать свои разрешения. Однако, если вы попытаетесь получить доступ к любой из служб из financesобласти, вам будет отказано, потому что ваш TGT не имеет ключей к этой области.

В конце рабочего дня срок действия вашего TGT истекает, и вы не сможете снова получить доступ к этим службам, пока не получите новый билет при входе в систему на следующий день.

Разбивка процесса Kerberos (16 шагов)

Теперь мы разберем каждый этап процесса, чтобы вы лучше понимали, что происходит за кулисами:

1. Войти

Пользователь вводит свое имя пользователя и пароль. Затем клиент с поддержкой Kerberos преобразует этот пароль в секретный ключ клиента.

2. Запросы клиентов на сервер выдачи билетов

введенное имя пользователя
название запрашиваемой услуги
сетевой адрес пользователя
как долго они запрашивают доступ на

3. Сервер проверяет имя пользователя.

Имя пользователя проверяется на соответствие проверенным именам пользователей, хранящимся в KDC. Если имя пользователя знакомо, программа продолжится.

4. Выдача билета. Билет возвращается клиенту.

Message A может быть расшифрован с помощью секретного ключа клиента, созданного на шаге 1. Он содержит имя TGS, временную метку, время жизни билета и вновь предоставленный сеансовый ключ сервера предоставления билетов.
Message Bявляется билетом на выдачу билета и может быть расшифрован только с помощью секретного ключа TGS. Он содержит ваше имя пользователя, имя TGS, метку времени, ваш сетевой адрес, время жизни билета и тот же ключ сеанса TGS.

5. Клиент получает сеансовый ключ TGS.

Теперь клиент расшифровывает, message Aиспользуя секретный ключ клиента, предоставляя клиенту доступ к ключу сеанса TGS. Message Bхранится локально в зашифрованном состоянии.

6. Клиент запрашивает доступ к службе с сервера

7. Сервер проверяет службу.

Затем TGS проверяет, существует ли служба запросов в KDC. Если это так, программа продолжается.

8. Сервер получает сеансовый ключ TGS.

Теперь сервер получает все еще зашифрованные message Bотправленные message C. Message B(TGT) затем расшифровывается с использованием секретного ключа TGS сервера, давая серверу сеансовый ключ TGS.

Теперь с помощью этого сеансового ключа TGS сервер может расшифровать message D.

9. Сервер генерирует служебный сеансовый ключ.

10. Клиент получает ключ сеанса обслуживания.

Используя ключ сеанса TGS, кэшированный на шаге 5, клиент расшифровывает, message Fчтобы получить ключ сеанса службы.

11. Клиент связывается с Сервисом

12. Расшифровка сервисов Message G

Затем служба расшифровывает message Hсвой секретный ключ службы, чтобы получить ключ сеанса службы изнутри. С помощью этого ключа сервис расшифровывает message G.

13. Сервис проверяет запрос

Затем служба проверяет запрос, сравнивая имена пользователей, временные метки и время жизни из messages Gи H.

14. Сервис аутентифицируется для клиента.

Затем служба отправляет message Iзашифрованные с помощью сеансового ключа службы, хранимого как службой, так и клиентом. Message I- аутентификатор, содержащий идентификатор службы и временную метку.

15. Клиент проверяет услугу.

Затем клиент расшифровывает, message Iиспользуя ключ сеанса службы, кэшированный с шага 10. Затем клиент проверяет идентификатор и временные метки, содержащиеся в нем. Если оба соответствуют ожидаемым результатам, услуга считается безопасной.

16. Свободное общение между клиентом и службой

Уверенный в том, что и клиент, и служба взаимно аутентифицированы, Kerberos позволяет клиенту связываться со службой.

Можно ли взломать Kerberos?

Хотя Kerberos по-прежнему является самым безопасным протоколом, его можно взломать, как и любой другой. Kerberos, долгое время выступавший в качестве отраслевого стандарта, дал хакерам достаточно времени для преодоления системы.

Хакеры нашли 5 основных способов обойти систему Kerberos, основанных на нацеливании на уязвимые системные настройки, слабые пароли или распространение вредоносного вредоносного ПО. Давайте рассмотрим каждый из 5 типов атак:

Pass-the-ticket: этот метод создает ложный сеансовый ключ путем подделки ложного TGT. Затем хакер может представить TGT службе как действительные учетные данные. Наличие сеансового ключа позволяет этой подделке обходить все этапы проверки Kerberos, которые предшествуют этапу предоставления сеансового ключа.
Золотой билет: этот метод подделывает билет со статусом администратора. Хакер имеет неограниченный доступ ко всему домену при использовании этого билета; доступны отдельные устройства, серверы, данные и настройки. Хакеры могут создать «золотой билет» только в том случае, если у них есть доступ к машине администратора, обычно через установленное вредоносное ПО.
Серебряный билет: Подобно атаке Золотого билета, серебряные билеты — это поддельный билет проверки подлинности службы, который предоставляет доступ к службе. Этот метод дает меньший доступ, чем атака по золотому билету, но его также труднее обнаружить. Все взаимодействия на этом этапе являются взаимодействиями клиент / служба, что позволяет хакеру избежать мер безопасности, установленных в KDC.
Грубая сила: самый очевидный метод, грубая форсировка, включает использование автоматического подбора паролей для ввода тысяч паролей до тех пор, пока не будет найден правильный. Для брутфорса не требуются украденные учетные данные, но его легко обнаружить из-за нечеловеческого поведения при входе.
Вредоносное ПО с скрытым ключом бэкдора : в этом методе хакеры устанавливают скрытый ключ-ключ доступа к бэкдору в систему, чтобы позволить им войти в систему как любой пользователь в любое время в будущем. Этот метод требует ранее успешной атаки Golden Ticket Attack, поскольку эти скелетные ключи могут быть установлены только с административным доступом. Это одни из самых сложных атак для обнаружения, поскольку взлом и атака могут произойти с разницей в годы.

Что изучать дальше

Поздравляю! Сегодня вы узнали, что такое Kerberos, для чего он используется и какие шаги необходимо предпринять для аутентификации действий.

Поскольку все больше компаний используют протоколы безопасности Kerberos, чем когда-либо прежде, это понимание откроет двери для новых карьерных путей и возможностей трудоустройства. Следующие шаги на вашем пути:

Читайте также: