Kerberos аутентификация mac os

Настройка Kerberos-аутентификации с использованием смарт-карт

В продолжение давней темы про использование двухфакторной аутентификации в ОС GNU/Linux позвольте рассказать про схему работы и настройку аутентификации с помощью Kerberos. В этой статье мы рассмотрим процесс настройки MIT Kerberos для аутентификации пользователей по сертификатам и ключевым парам, находящимся на USB-токене. Также материалы, изложенные в статье, можно использовать для настройки аутентификации в домене Windows.

Краткое введение

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

Стоит отметить, что Kerberos в первую очередь является протоколом, а не конкретной системой аутентификации. Его реализации используются в различных операционных системах, в том числе и в Windows, как метод аутентификации пользователей в домене. Существует несколько open source реализаций протокола Kerberos, например оригинальная MIT Kerberos и Heimdal. Такой зоопарк возник из-за ограничений США на экспорт криптографических средств защиты информации, на сегодня эта ситуация вокруг MIT Kerberos уже улеглась. В статье мы рассмотрим процесс настройки для MIT Kerberos V5.

Терминология Kerberos

• Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
• Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
• Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
• Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
• Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM.

Файлы настроек Kerberos

На сервере:

• /etc/krb5kdc/kdc.conf — настройки KDC

На клиенте и сервере:

• /etc/kbr5.conf — настройки сервера аутентификации (описание realms, доменных имен и других настроек)

Настройка рабочего окружения

Для начала необходимо развернуть среду, в которой будет производиться аутентификация. Наиболее просто это сделать, взяв две виртуальные машины, находящиеся в одной подсети. Достаточно установить на одну виртуальную машину какую-нибудь Ubuntu (это будет наш сервер), а затем клонировать ее и получить клиента. При написании статьи я воспользовался свежей Ubuntu 12.10 (x86) и виртуальной машиной от VMWare. Чтобы виртуальным машинам было удобнее видеть друг друга по сети, стоит переключить сетевые карты в Bridged-режим.
Важно! Следите за тем, чтобы время на клиенте и сервере было синхронизировано, это необходимо для корректной работы Kerberos.

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

Клиенты Kerberos ищут свои сервера по доменным именам, поэтому необходимо настроить DNS и убедиться, что имена серверов успешно разрешаются. В нашем примере достаточно занести доменное имя сервера в /etc/hosts, что я и сделал. Схема «сети» изображена ниже.

Установка необходимых пакетов

На сервере нам потребуются:

• krb5-kdc – сервис KDC
• krb5-admin-server – административный сервер Kerberos (он ведет контроль учетных записей пользователей)
• krb5-pkinit – модуль расширения Kerberos для аутентификации по сертификатам

На клиент надо поставить следующие пакеты:

• krb5-user – базовый набор утилит для работы клиентской аутентификации
• krb5-config – файлы настроек Kerberos
• krb5-pkinit
• libpam-krb5 – модуль PAM для использования Kerberos-аутентификации
• pcscd, opensc, libengine-pkcs11-openssl – пакеты, необходимые для работы с токенами

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

• Default realm: AKTIV-TEST.RU
• Имена серверов (admin server и KDC): aktiv-test.ru (он же прописан в /etc/hosts на клиенте)
• Пользователь: testuser@AKTIV-TEST.RU

Настройка Kerberos

Базовые настройки

Настройка аутентификации по открытому ключу

На сервере:

Создадим ключевую пару и сертификат нашего «УЦ». Здесь мы сгененируем ключ УЦ и создадим самоподписанный сертификат с помощью openssl. В реальном мире ключ естественно надо надежно защитить от попадания в чужие руки.
Создадим ключевую пару для KDC, заявку на сертификат и выпишем его сами себе.
Здесь нам потребуется специальный файл расширений OpenSSL (pkinit_extensions), в котором будут указаны дополнительные поля сертификатов, используемых в Kerberos. В частности, мы зададим:

• Extended Key Usage (EKU) – идентификатор (OID), говорящий о том, как планируется использовать сертификат
• otherName – поле, задающее нашего принципала, для которого выписывается сертификат

После этого перенесем следующие файлы в /var/lib/krb5kdc/:

• kdc.pem
• kdckey.pem
• cacert.pem

На сервере отредактируем настройки Kerberos (файл /etc/krb5kdc/kdc.conf) для использования ключей и сертификатов сервера и УЦ:
Далее на сервере необходимо включить предварительную аутентификацию для нашего пользователя.

Дальнейшие действия будем выполнять на клиенте

Настройка PAM-аутентификации с использованием Kerberos

Ранее при настройке клиентской машины мы поставили пакет libpam-krb5. Он поможет нам выполнить аутентификацию в Kerberos при входе в систему, а также в приложениях, использующих системную аутентификацию (например login, lightdm и проч.). Для подключения модуля PAM достаточно выполнить команду
и выбрать в диалоге необходимые модули аутентификации. Для более тонкой настройки можно заглянуть в файл /etc/pam.d/common-auth и отредактировать его по желанию. Структуру файла я описывал в предыдущей статье.

Заключение

Применение протокола Kerberos для централизованной аутентификации в связке с централизованным созданием хранением и раздачей учетных записей (например, посредством каталога на базе OpenLDAP) позволяет создать «домен UNIX», полностью состоящий из машин под управлением свободного программного обеспечения. Такое решение может применяться в корпоративном секторе, а аутентификация по смарт-картам будет приятным бонусом как для администраторов, так и для пользователей сети компании.

Источник

How to enable Integrated Authentication on macOS and Linux using Kerberos

In order to use Integrated Authentication (aka Windows Authentication) on macOS or Linux you will need to setup a Kerberos ticket linking your current user to a Windows domain account. A summary of key steps are included below.

Pre-requsite: get the Kerberos Domain Controller (KDC) config

Find Kerberos KDC (Key Distribution Center) configuration value.

Run on: Windows PC that is joined to your Active Directory Domain,

Start cmd.exe and run nltest .

Copy the DC name which is the required KDC configuration value, in this case dc-33.domain.company.com

Setup Kerberos on Mac

Step 1: Configuring KDC in krb5.conf

Action: Edit the /etc/krb5.conf in an editor of your choice. Configure the following keys

Then save the krb5.conf file and exit

Note Domain must be in ALL CAPS

Step 2: Testing the Ticket Granting Ticket retrieval

• Use the command kinit username@DOMAIN.COMPANY.COM to get a TGT from KDC. You will be prompted for your domain password.

• Use klist to see the available tickets. If the kinit was successful, you should see a ticket.

Step 3: Connect in VSCode

Create a new connection profile

Choose Integrated as the authentication type

If all goes well and the steps above worked, you should be able to connect successfully!

Setup Kerberos on Linux

Step 1: Install krb5-user package

Action: sudo apt-get install krb5-user

PS: you may need to do the following command first:

Step 2: Configuring KDC in krb5.conf

Action: Edit the /etc/krb5.conf in an editor of your choice. Configure the following keys

Then save the krb5.conf file and exit

Note Domain must be in ALL CAPS

Step 3: Testing the Ticket Granting Ticket retrieval

• Use the command kinit username@DOMAIN.COMPANY.COM to get a TGT from KDC. You will be prompted for your domain password.

• Use klist to see the available tickets. If the kinit was successful, you should see a ticket from

Step 4: Connect in VSCode

Create a new connection profile

Choose Integrated as the authentication type

If all goes well and the steps above worked, you should be able to connect successfully!

Источник

Using the Kerberos SSO extension with macOS

Overview

On macOS, the Kerberos SSO extension proactively acquires a Kerberos TGT upon network state changes to ensure that the user is ready to authenticate when needed. The Kerberos SSO extension also helps your users manage their Active Directory accounts. Additionally, it allows users to change their Active Directory passwords and notifies them when a password is close to expiring. Users can also change their local account passwords to match their Active Directory passwords.

The Kerberos SSO extension should be used with an on-premise Active Directory domain. Azure Active Directory isn’t supported. To use the Kerberos SSO extension, devices don’t need to be joined to an Active Directory domain. Additionally, users don’t need to log in to their Mac computers with Active Directory or mobile accounts; instead, Apple recommends using local accounts.

Account use

The Kerberos SSO extension doesn’t require that your Mac be bound to Active Directory or that the user be logged in to the Mac with a mobile account. Apple suggests you use the Kerberos SSO extension with a local account. The Kerberos SSO extension was specifically created to enhance Active Directory integration from a local account. However, should you choose to continue using mobile accounts, you can still use the Kerberos SSO extension. When used with mobile accounts:

Password sync won’t work. If you use the Kerberos SSO extension to change your Active Directory password and you’re logged in to your Mac with the same user account you’re using with the Kerberos SSO extension, password changes function as they do from the Users & Groups preference pane. But if you perform an external password change—meaning you change your password on a website, or your help desk resets it—the Kerberos SSO extension can’t bring your mobile account password back in sync with your Active Directory password.

Using a password change URL with the Kerberos extension is unsupported.

User sign-in methods and options

Users must authenticate to the Kerberos SSO extension. They can begin this process in any of several ways:

If the Mac is connected to the network where your Active Directory domain is available, the user is prompted to authenticate immediately after the Extensible SSO configuration profile is installed.

Whenever the Mac is connected to a network where your Active Directory domain is available, the user is immediately prompted to authenticate.

If Safari or any other app is used to access a website that accepts or requires Kerberos authentication, the user is prompted to authenticate.

The user can select the Kerberos SSO extension menu extra, then click Sign In.

If the user chose to sign in to the Kerberos SSO extension automatically, they’re no longer prompted for credentials until they change their password. If they don’t choose to sign in automatically, they’re prompted for credentials when their Kerberos credential expires—usually in 10 hours.

If the user enabled the password sync feature, they’re asked for their current Active Directory and local passwords. After they enter both and then click OK, the passwords are synced.

Источник

Kerberos за 5 минут: знакомство с сетевой аутентификацией

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

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

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

Что такое Kerberos?

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

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

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

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

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

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

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

• Безопасность: Kerberos никогда не передает пароли по сети. Вместо этого Kerberos подтверждает личность пользователя, отправляя ограниченные по времени криптографические сообщения, которые становятся недействительными по истечении установленного периода. Даже сообщения были перехвачены и расшифрованы, они были бы бесполезны в считанные минуты!
• Единый вход: Kerberos требует, чтобы пользователь вводил пароль только один раз при первой аутентификации клиента. С этого момента пользователь имеет доступ ко всем керберизованным службам в области Kerberos без необходимости повторно вводить свой пароль. Единый вход упрощает работу с несколькими службами, устраняя необходимость в нескольких требованиях входа в систему.

Надежная третья сторона: Kerberos использует централизованный сервер аутентификации, известный как Центр распространения ключей (KDC), которому по умолчанию доверяют все другие устройства в сети. Все запросы аутентификации, такие как криптографические сообщения, маршрутизируются через этот сервер. Такой аутсорсинг гарантирует, что конфиденциальная информация не будет храниться на локальном компьютере.

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

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

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

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

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

Центр распространения ключей (KDC) — это центральный процесс Kerberos, содержащий сервер аутентификации (AS) и службу выдачи билетов (TGS). Его основная функция — быть посредником между этими двумя, ретранслируя сообщения от AS, выдает билет на выдачу билетов (TGT), а затем передает его для шифрования с помощью TGS. После этого KDC мало влияет на процесс аутентификации.

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

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

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

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

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

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

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

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

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

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

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

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

• Вход пользователя / клиента: на этом этапе происходит взаимодействие между пользователем и клиентом. Пользователь вводит в клиент свое имя пользователя и пароль. Затем клиент преобразует этот пароль в ключ шифрования, хранящийся локально. Если это завершится правильно, клиент может начать аутентификацию с помощью AS.
• Аутентификация клиента / AS: на этом этапе клиент и сервер аутентификации подключаются для аутентификации имени пользователя и проверки того, что они являются частью системы. Затем AS проверяет, что имя пользователя уже задокументировано в системе. В этом случае Клиент и AS обмениваются зашифрованными проверочными сообщениями для проверки друг друга. В конце оба аутентифицируются, соединение устанавливается, и клиент может перейти к аутентификации с помощью службы.
• Аутентификация клиента / службы: на этом этапе клиент и сервер должны аутентифицировать друг друга в соответствии с практикой взаимной аутентификации. Клиент и сервер обмениваются зашифрованными проверочными сообщениями, как на предыдущем этапе. Если все это проходит, клиент и служба аутентифицируются, и клиент получает разрешение запросить их службу.
• Клиент / запрос службы: наконец, клиент может запросить именованную службу у сервера службы. Затем сервисный сервер проверяет, доступна ли запрошенная услуга. Если да, сервер службы предоставляет услугу клиенту. Поскольку клиент прошел аутентификацию на всех этапах этого процесса, он может продолжать использовать службу до истечения срока действия разрешений.

Пример процесса 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. Клиент запрашивает доступ к службе с сервера

Теперь клиент отправляет обратно два сообщения:

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

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

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

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

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

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

Теперь у сервера есть отметка времени и имя из message Bи message D(сообщения аутентификатора). Сервер следит за тем, чтобы имена и временные метки совпадали, чтобы предотвратить мошеннические сообщения. Он также проверяет метку времени на соответствие времени жизни билета, чтобы убедиться, что время ожидания не истекло.

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

Затем сервер генерирует случайный ключ сеанса службы и еще два сообщения.

• Message E зашифрован с помощью секретного ключа службы и содержит ваше имя, имя запрошенной службы, метку времени, ваш сетевой адрес, время жизни билета и ключ сеанса службы.
• Message Fшифруется с помощью сеансового ключа TGS, хранимого как клиентом, так и сервером. Это сообщение содержит всю ту же информацию, message Eкроме вашего имени пользователя и сетевого адреса.

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

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

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

Теперь клиент отправляет еще два сообщения, на этот раз службе:

• Message G- еще одно сообщение аутентификатора, на этот раз зашифрованное с помощью сеансового ключа службы. Он содержит ваше имя и метку времени.
• Message Hявляется копией message E, которая все еще зашифрована служебным секретным ключом.

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, чем когда-либо прежде, это понимание откроет двери для новых карьерных путей и возможностей трудоустройства. Следующие шаги на вашем пути:

• Управление целостностью сообщения
• Шифрование с открытым ключом
• Методы предотвращения атак
• Меры реагирования на атаки

Источник