По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет всем! В сегодняшней статье хотим рассказать о том, как защитить исходящие маршруты во FreePBX списком паролей. Мы покажем, как создать множество PIN-кодов, которые необходимо будет набрать прежде чем открылась возможность совершения вызова через тот или иной исходящий маршрут.
Как можно догадаться, для этих целей во FreePBX существует специальный модуль - PIN Sets, о нём и поговорим.
Обзор
Модуль PIN Sets позволяет создавать группы и привязывать к ним список определённых паролей (нас самом деле - PIN-кодов). Затем, через модуль Outbound Route можно сократить пользование исходящим маршрутом только до определённой группы. Получается такое расширение функций поля Route Password в настройках исходящего маршрута только вместо одного PIN-кода мы теперь можем ввести много разных.
Например, мы можем создать группу ”Sales” (Продавцы) и задать в ней 3 PIN-кода, один для руководителя отдела продаж, и ещё два для менеджеров, а затем каждому сообщить свой PIN. Потом назначить данную группу на определённый маршрут и каждый раз, когда кто-то захочет сделать внешний вызов через этот маршрут, ему будет предложено сначала ввести PIN.
Настройка
Перейдём к настройке. Модуль PIN Sets располагается в разделе Settings:
Описание модуля говорит нам, что он используется для управления PIN-кодами для доступа к “запрещённым фичам” таким как Outbound Routes (исходящие маршруты). Но на самом деле, кроме как в модуле Outbound Route функционал PIN Sets больше нигде применить нельзя.
Существует коммерческая реализация данного модуля – PIN Sets Pro. Она позволяет создавать наборы PIN-кодов индивидуально для внутренних номеров, а также строит отчёты по использованию данных PINов.
Для того, чтобы создать новую группу кликаем Add Pinset:
Перед нами открывается окно с параметрами для добавления новой группы:
Описание каждого параметра модуля:
PIN Set Description - Описание для данной группы;
Record In CDR - Параметр, отвечающий за то, записывать ли PIN-коды данной группы в CDR;
PIN List - Собственно, сами PIN коды, которые можно будет набрать прежде чем звонить через маршрут. Можно вводить несколько PIN-кодов, записывая их в линию;
После создания новой группы нажимаем Submit и Apply Config. А затем отправляемся в модуль Outbound Route, выбираем из списка маршрут, который нужно защитить и открываем его настройки. Предварительно, необходимо убедиться, что на вкладке Route Settings в поле Route Password не стоит никакого пароля.
Переходим на вкладку Additional Settings и в поле PIN Sets выбираем только что созданную группу.
Теперь, чтобы можно было воспользоваться маршрутом 79012345678 и позвонить во вне, абоненту нужно будет набрать либо PIN-код 48151 либо 62342 как настроено в PIN Sets.
Каждому исходящему маршруту может быть назначена только одна группа PIN Set. Если Вы хотите разрешить ещё одной группе пользоваться тем же маршрутом, не внося пароли из неё в первую группу, просто продублируйте маршрут и назначьте ему новую группу PIN Set.
Ищешь бесплатное решение по реализации исходящих звонков из CRM Битрикс24 в связке с Asterisk? Поздравляем, нашел. Можешь закрыть все остальные вкладки и оставить только эту – пошаговое руководство по интеграции Б24 и Астериска в статье :)
Как это работает?
Легко (на этом можно было бы закончить). Мы создаем исходящий вебхук в Битрикс, он дергает php - скрипт на Asterisk каждый раз, когда мы будем нажимать на номер телефона в лиде, сделке, контакте – где угодно. Поехали.
Попробовать Битрикс24
Подготовка
Создадим AMI (Asterisk Manager Interface)– юзера, через которого будем инициировать вызовы. Откроем файл настройки:
vim /etc/asterisk/manager.conf
Обращаем внимание на секцию [general] - параметр enabled должен быть в значении yes:
[general]
enabled = yes // вот этот параметр :)
port = 5038
bindaddr = 0.0.0.0
Проверьте, чтобы в самом конце файла manager.conf были следующие строки (если их нет, добавьте):
#include manager_custom.conf
Проверили. А теперь открываем файл /etc/asterisk/manager_custom.conf (если его нет – создайте и дайте права) и добавляем туда:
[имя]
secret = пароль
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.0
permit=ip_адрес_Asterisk/маска
read = all,system,call,log,verbose,command,agent,user,config,originate
write = all,system,call,log,verbose,command,agent,user,config,originate
имя - придумайте имя для юзера;
пароль - создайте устойчивый к взломам пароль, с помощью сервисов онлайн генерации, например;
ip_адрес_Asterisk/маска - укажите вашу подсеть. В указанной подсети должен находится IP – адрес, с которого скрипт будет обращаться к AMI. Пример записи - 192.168.1.0/255.255.255.0;
Переходим в Битрикс24 и создаем вебхуки.
Вебхуки
Первый вебхук мы сделаем входящим – по нему наш скрипт будет получать внутренний номер сотрудника по его идентификатору. Переходим в раздел Приложения → Вебхуки. Нажимаем кнопку Добавить вебхук и выбираем Входящий вебхук. Делаем вот что:
Название - любое название, как вам удобно;
Описание - нужный момент, чтобы не запутаться в вебхуках;
Права доступа - отметьте галочкой Пользователи (user);
Нажимаем сохранить. Должно получиться примерно вот так:
Обратите внимание: на скриншоте, красной линией подчеркнут URL параметра Пример URL для вызова REST. Скопируйте его ровно до последней части /profile/. Например, у нас получилось:
https://merionet.bitrix24.ru/rest/2/1a2b3c4d5e6f7g8h
Сохраните этот URL – он нам еще пригодится :) Перед тем, как мы сделаем исходящий вебхук, давайте обсудим будущий URL нашего скрипта. Так как он будет располагаться в веб директории, мы предлагаем вам сгенерировать последовательно 3 директории, в которых будет лежать скрипт. И вот о чем мы: представим, что ваш домен выглядит вот так:
http://ilovemerionet.ru/
Гуд. Давайте последовательно сгенерируем 3 уникальных названия директорий, например:
IpVy7ul85sz1Doi
C49BNGJW3Yf30eo
qBN0NBC56lj07yh
После чего, в директории /var/www/html/ создадим три вложенных папки, чтобы наш файл в конечно итоге размещался в директории:
/var/www/html/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/
Сам файл скрипта, который мы сгенерируем, будет называться index.php, тем самым, вебхук со стороны Битрикс24 будет обращаться по следующему URL:
http://ilovemerionet.ru/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/
Кажется, разобрались :) Теперь создаем исходящий вебхук – прыгаем в раздел Приложения → Вебхуки. Нажимаем кнопку Добавить вебхук и выбираем Исходящий вебхук. Делаем вот что:
Код авторизации - это наш проверочный код, который мы используем в скрипте;
Адрес обработчика - как мы привели пример выше, тут будет http://ilovemerionet.ru/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/ - у вас, само собой, свой URL :);
Название - явное название, чтобы не запутаться. Сделайте Asterisk Calls, например?;
Комментарий - можете оставить комментарий для себя, чтобы было проще разобраться;
Тип события - выбираем Инициация звонка через приложение (ONEXTERNALCALLSTART);
Великолепно. Мы выходим на финишную прямую.
Скрипт для Asterisk
Ловите скрипт, который будет принимать вебхуки от Битрикс24. Комментарии к самым важным строкам, как всегда, присутствуют:
<?php
$check_token = "Код_авторизации"; // это значение будет прилетать нам в вебхуке. А мы будем его сравнивать, чтобы быть уверенными, что это Битрикс;
$user_hook_url = "Часть_входящего_вебхука"; // нужно, для получения внутреннего номера пользователя, которые инициирует звонок;
$ami_login = "ami_логин"; // логин к AMI, который мы создавали ранее;
$ami_password = "пароль"; // пароль к AMI, который мы создавали ранее;
$strhost = "IP_адрес"; // IP - адрес вашего Asterisk;
if (strcmp($_POST['auth']['application_token'], $check_token) === 0) {
function writeToLog($data, $title = '') {
$log = "
------------------------
";
$log .= date("Y.m.d G:i:s") . "
";
$log .= (strlen($title) > 0 ?
$title : 'DEBUG') . "
";
$log .= print_r($data, 1);
$log .= "
------------------------
";
file_put_contents(getcwd() . '/hook.log', $log, FILE_APPEND);
return true; }
writeToLog($_REQUEST, 'incoming');
$UID = $_POST['data']['USER_ID'];
$bitrix_contact_url = "$user_hook_url/user.get.json?ID=$UID";
$btc = curl_init();
curl_setopt ($btc, CURLOPT_URL,$bitrix_contact_url);
curl_setopt ($btc, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6");
curl_setopt ($btc, CURLOPT_TIMEOUT, 60);
curl_setopt ($btc, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($btc, CURLOPT_RETURNTRANSFER, 1);
$bitrix_contact = curl_exec ($btc);
curl_close($btc);
$bitrix_contact_o = json_decode($bitrix_contact, true);
$cid = $bitrix_contact_o['result'][0]['UF_PHONE_INNER'];
$strport = "5038";
$timeout = "5";
$num = str_replace("+","",$_POST['data']['PHONE_NUMBER_INTERNATIONAL']);
$callid = $_POST['data']['CALL_ID'];
$c="from-internal";
$p="1";
$errno=0 ;
$errstr=0 ;
$sconn = fsockopen($strhost, $strport, &$errno, &$errstr, $timeout) or die("Connection to $strhost:$strport failed");
if (!$sconn) { echo "$errstr ($errno)
"; }
else {
$sconn1 = fsockopen($strhost, $strport, &$errno, &$errstr, $timeout) or die("Connection to $strhost:$strport failed");
if (!$sconn1) { echo "$errstr ($errno)
"; }
else {
fputs($sconn1, "Action: login
");
fputs($sconn1, "Username: $ami_login
");
fputs($sconn1, "Secret: $ami_password
");
fputs($sconn1, "Events: off
");
usleep(500);
fputs($sconn1, "Action: Setvar
");
fputs($sconn1, "Variable: B24ID
");
fputs($sconn1, "Value: $callid/$cid
");
fputs($sconn1, "Action: Logoff
");
usleep(500);
$wrets1=fgets($sconn1,128);
fclose($sconn1);}
fputs($sconn, "Action: login
");
fputs($sconn, "Username: $ami_login
");
fputs($sconn, "Secret: $ami_password
");
fputs($sconn, "Events: off
");
usleep(500);
fputs($sconn, "Action: Originate
");
fputs($sconn, "Channel: SIP/$cid
");
fputs($sconn, "Callerid: $cid
");
fputs($sconn, "Timeout: 20000
");
fputs($sconn, "Context: $c
");
fputs($sconn, "Exten: $num
");
fputs($sconn, "Priority: $p
");
fputs($sconn, "Async: yes
" );
usleep(500);
$wrets=fgets($sconn,128);
fclose($sconn);
exit;
}} else {
exit;
};
?>
Скачать скрипт интеграции
После загрузки файла, сохраните его с расширением .php
В нем вам нужно поменять 5 переменных:
$check_token - код авторизации, который вы получили на этапе создания исходящего вебхука;
$user_hook_url - та часть входящего вебхука, которая подчеркнута на скриншоте до слов /profile/;
$ami_login - логин в AMI, создавали ранее;
$ami_password - пароль в AMI;
$strhost - IP - адрес вашего Asterisk;
Чтобы скрипт заработал, нужно, как мы говорили ранее, загрузить его в директорию /var/www/html/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/ (после генерации директорий у вас будет свой путь!) и дать следующие команды:
dos2unix /var/www/html/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/index.php
chown asterisk:asterisk /var/www/html/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/index.php
chmod 775 /var/www/html/IpVy7ul85sz1Doi/C49BNGJW3Yf30eo/qBN0NBC56lj07yh/index.php
Кстати, профит этого скрипта в том, что он ведет логирование в файле hook.log, который будет располагаться в той же директории. Если кто – то из ваших менеджеров скажет, что не смог позвонить клиенту – это будет легко проверить :)
Почти готово. Остался только один штрих. Снова открываем CRM Битрикс24, переходим в сегмент Телефония → Настройки и в параметре Настройка номеров по-умолчанию выбираем созданный нами вебхук (у нас он называется Приложения: Asterisk Calls:
А вот теперь готово. Звоним
Звонит :) Но! Не закрывает карточку и не добавляет отметку об исходящем звонке в сущность CRM (запись разговора). Внимательные пользователи обратят внимание – в AMI сегменте скрипта, который обсуждали ранее, мы кинули команду Setvar (присвоение переменной) к B24ID = $callid. Тем самым, на всем протяжении звонка у нас будет идентификатор этой телефонной транзакции.
Фактически, чтобы получить отметку о звонке, запись разговора и прочее, по факту окончания разговора нужно методом telephony.externalcall.finish кинуть массив данных, где будет отметка об идентификаторе вызова (которую передаем через диалплан), телефон инициатора вызова, длительность и ссылка на запись разговора.
Если данная статья вызовет интерес, мы покажем, как это сделать. Удачи с настройкой :)
Киберпреступность — это печальная реальность современности, затрагивающая как частных пользователей, так и бизнес. Ни одна компания или организация не застрахована, и ситуация вряд ли улучшится в ближайшее время. Эксперты прогнозируют, что убытки от киберпреступлений достигнут $25 трлн к 2025 году. Forbes также предупреждает об увеличении угроз для мобильных устройств.
Эти прогнозы подчеркивают, что киберпреступность останется с нами и будет только расти. В связи с этим цифровой мир стремится разрабатывать новые стратегии для усиления кибербезопасности.
В этой статье мы рассмотрим протокол аутентификации Kerberos и узнаем, как он работает.
Что такое Kerberos?
Kerberos — это протокол безопасности компьютерных сетей, который аутентифицирует запросы между двумя или несколькими доверенными хостами в ненадежной сети, такой как интернет. Разработанный MIT для проекта Athena в конце 1980-х, он теперь используется по умолчанию в Microsoft Windows и реализован в других операционных системах, таких как Apple OS, FreeBSD, UNIX и Linux.
Как работает Kerberos
Kerberos использует криптографию с секретным ключом и доверенное третье лицо — Центр Распределения Ключей (KDC) — для аутентификации клиент-серверных приложений и проверки идентичности пользователей. KDC предоставляет услуги аутентификации и выдачи билетов, которые обеспечивают безопасную проверку идентичности, защищая от прослушивания и повторных атак.
Для чего используется Kerberos
Kerberos широко применяется в цифровом мире, особенно в системах, требующих надежного аудита и аутентификации. Он используется в аутентификации Posix, Active Directory, NFS и Samba, а также как альтернатива системам аутентификации SSH, POP и SMTP.
Основные применения Kerberos
Единый вход (SSO). Kerberos позволяет пользователям аутентифицироваться один раз и получить билет, известный как Kerberos ticket-granting ticket (TGT). Этот TGT можно использовать для запроса билетов на доступ к различным ресурсам без повторного ввода учетных данных, что упрощает работу пользователей и снижает необходимость управления множеством паролей.
Сетевая аутентификация. Kerberos предоставляет безопасный механизм для проверки подлинности сетевых служб, таких как серверы и приложения. Клиенты могут запросить билет на службу у Центра Распределения Ключей (KDC) с использованием своего TGT, а этот билет используется для аутентификации и установления защищенной сессии с запрашиваемой службой.
Взаимная аутентификация. Kerberos обеспечивает взаимную аутентификацию, что означает, что и клиент, и сервер аутентифицируют друг друга в процессе начальной аутентификации. Это предотвращает impersonation и атаки "человек посередине" путем проверки подлинности обеих сторон в коммуникации.
Авторизация. Kerberos также может использоваться для реализации политик контроля доступа. После аутентификации клиента Kerberos билет содержит информацию о его идентичности и правах доступа. Серверы могут использовать эту информацию для применения правил авторизации и предоставления или отказа в доступе к конкретным ресурсам в зависимости от привилегий клиента.
Что делает протокол аутентификации Kerberos?
MIT разработал протокол для проекта под названием Athena. Название происходит от трехголового пса Адеса из греческой мифологии, который охранял ад. Имя было выбрано, потому что протокол Kerberos представляет собой три компонента:
Клиент
Сетевой ресурс (сервер приложений)
Центр распределения ключей (KDC)
Эти три компонента позволяют Kerberos обеспечивать аутентификацию доверенных хостов в ненадежных сетях. Kerberos гарантирует, что доступ к сетевым ресурсам имеют только авторизованные пользователи. Также он обеспечивает AAA безопасность: Аутентификацию, Авторизацию и Учет.
Разработчики MIT создали Kerberos для безопасной аутентификации к требуемым системам и авторизации пользователей. В то время большинство систем передавали незашифрованные пароли, что позволяло хакерам получить несанкционированный доступ. Поэтому разработка Kerberos была необходима.
Проектом занимались S.P. Miller, B.C. Neuman, J.I. Schiller и J.H. Saltzer.
В Kerberos KDC выдает билеты, которые позволяют различным хостам подтверждать свою личность. Также разработчики предусмотрели, что аутентификация Kerberos поддерживает авторизацию. Это значит, что клиент, аутентифицированный Kerberos, также получает доступ к ресурсам.
Преимущества аутентификации Kerberos
Kerberos приносит множество преимуществ в любую настройку кибербезопасности:
Эффективный контроль доступа. Kerberos позволяет пользователям отслеживать входы и применять политику безопасности через единую точку.
Ограниченный срок действия ключевых билетов. Каждый билет Kerberos имеет метку времени, данные о сроке действия и продолжительность аутентификации, контролируемую администратором.
Взаимная аутентификация. Системы и пользователи могут аутентифицировать друг друга.
Повторное использование аутентификации. Аутентификация пользователей Kerberos повторно используется и долговечна; каждый пользователь должен быть проверен системой только один раз. Пока билет действителен, пользователю не нужно повторно вводить свои данные для аутентификации.
Сильные и разнообразные меры безопасности. Протоколы безопасности Kerberos используют криптографию, несколько секретных ключей и авторизацию третьих сторон, создавая надежную защиту. Пароли не передаются по сетям, и все секретные ключи зашифрованы.
Как работают протоколы аутентификации Kerberos?
Ниже представлена упрощенная схема работы протоколов аутентификации Kerberos:
Запрос к серверу аутентификации. Клиент запрашивает аутентификацию у KDC. Этот запрос передается в открытом виде.
Ответ сервера аутентификации. KDC отправляет TGT и сеансовый ключ, если клиент есть в базе данных. Если клиента нет в базе, аутентификация не проходит.
Запрос билета на службу. Клиент запрашивает билет на службу вместе с TGT, выданным ранее KDC.
Ответ на запрос билета. KDC отправляет билет, зашифрованный сеансовым ключом. Клиент может использовать сеансовый ключ, отправленный ранее KDC, для расшифровки билета на службу.
Запрос к серверу приложений. Клиент запрашивает доступ к серверу приложений, используя билет на службу.
Ответ сервера приложений: Сервер приложений аутентифицирует клиента и отправляет билет, который предоставляет доступ к конкретной услуге.
Билет службы имеет определенный срок действия. Вы можете использовать один и тот же билет сеанса для доступа к службам до истечения срока его действия. По умолчанию срок действия билета Kerberos составляет 600 минут.
Обзор потока протокола Kerberos
Давайте подробнее рассмотрим, что такое аутентификация Kerberos, и разберем, как она работает, разделив ее на основные компоненты.
Основные участники типичного процесса Kerberos:
Клиент действует от имени пользователя и инициирует запрос на услугу.
Сервер предоставляет услугу, к которой пользователь хочет получить доступ.
Сервер аутентификации (AS) выполняет аутентификацию клиента. Если аутентификация успешна, AS выдает клиенту билет, называемый TGT (Ticket Granting Ticket). Этот билет подтверждает другим серверам, что клиент аутентифицирован.
Центр распределения ключей (KDC): в среде Kerberos сервер аутентификации логически разделен на три части: базу данных (db), сервер аутентификации (AS) и сервер выдачи билетов (TGS). Эти три части объединены в одном сервере, называемом Центром распределения ключей (KDC).
Сервер выдачи билетов (TGS) — это сервер приложений, который выдает билеты на услуги.
Теперь разберем процесс протокола.
Существует три ключевых секретных ключа, используемых в потоке Kerberos:
Ключ клиента/пользователя: хэш, полученный из пароля пользователя.
Секретный ключ TGS: хэш пароля, использованный для определения TGS.
Секретный ключ сервера: хэш пароля, использованный для определения сервера, предоставляющего услугу.
Процесс протокола включает следующие шаги:
Шаг 1. Начальный запрос аутентификации клиента: Пользователь запрашивает у сервера аутентификации (AS) билет TGT. Этот запрос включает идентификатор клиента.
Шаг 2. KDC проверяет учетные данные клиента. AS проверяет базу данных на наличие клиента и доступность TGS. Если AS находит оба значения, он генерирует секретный ключ клиента/пользователя, используя хэш пароля пользователя.
AS затем вычисляет секретный ключ TGS и создает сеансовый ключ (SK1), зашифрованный секретным ключом клиента/пользователя. AS генерирует TGT, содержащий идентификатор клиента, сетевой адрес клиента, метку времени, срок действия и SK1. Тicket TGS секретный ключ затем шифрует билет.
Шаг 3. Клиент расшифровывает сообщение. Клиент использует секретный ключ клиента/пользователя для расшифровки сообщения и извлечения SK1 и TGT, создавая аутентификатор, который подтверждает клиента TGS.
Шаг 4. Клиент использует TGT для запроса доступа. Клиент запрашивает билет у сервера, предоставляющего услугу, отправляя извлеченный TGT и созданный аутентификатор в TGS.
Шаг 5. KDC создает билет для файлового сервера. TGS использует секретный ключ TGS для расшифровки TGT, полученного от клиента, и извлечения SK1. TGS расшифровывает аутентификатор и проверяет, соответствует ли он идентификатору клиента и сетевому адресу клиента. TGS также проверяет метку времени, чтобы убедиться, что TGT не истек.
Если все проверки пройдены успешно, KDC генерирует сеансовый ключ услуги (SK2), который делится между клиентом и целевым сервером.
Наконец, KDC создает билет услуги, включающий идентификатор клиента, сетевой адрес клиента, метку времени и SK2. Этот билет шифруется секретным ключом сервера, полученным из базы данных. Клиент получает сообщение с билетом услуги и SK2, все зашифрованное с помощью SK1.
Шаг 6. Клиент использует билет услуги для аутентификации. Клиент расшифровывает сообщение с помощью SK1 и извлекает SK2. Этот процесс создает новый аутентификатор, содержащий сетевой адрес клиента, идентификатор клиента и метку времени, зашифрованный с помощью SK2, и отправляет его вместе с билетом услуги на целевой сервер.
Шаг 7. Целевой сервер принимает расшифровку и аутентификацию. Целевой сервер использует секретный ключ сервера для расшифровки билета услуги и извлечения SK2. Сервер использует SK2 для расшифровки аутентификатора, проверяя, совпадают ли идентификатор клиента и сетевой адрес клиента из аутентификатора и билета услуги. Сервер также проверяет билет услуги на предмет его истечения.
После успешного прохождения всех проверок целевой сервер отправляет клиенту сообщение, подтверждающее, что клиент и сервер аутентифицировали друг друга. Пользователь теперь может начать защищенную сессию.
Теперь, когда мы рассмотрели, что такое Kerberos, давайте перейдем к вопросу, является ли Kerberos безошибочным.
Понятия и термины объектов Kerberos
Большинство целей Kerberos связаны с управлением паролями. Он обеспечивает, чтобы пароли не передавались по сети и не хранились на клиентских системах; система удаляет их сразу после использования. Пароли не должны храниться в открытом виде, и каждая сессия должна использовать только один пароль.
Кроме того, вся информация об аутентификации хранится на централизованном сервере, что означает:
Администратор может ограничить доступ любого клиента из централизованного сервера.
Один пароль пользователя может обеспечить доступ ко всем службам.
Защита информации пользователя становится менее сложной, так как нужно защищать только один сервер.
В Kerberos все сущности должны аутентифицироваться друг у друга по запросу.
Следующие сущности используют протоколы Kerberos:
Принципы Kerberos — это уникальный идентификатор, назначаемый билету. Для большинства пользователей это тот же идентификатор, что и имя пользователя. Kerberos идентифицирует принципала по следующей информации:
Для пользователей: это имя пользователя; для хостов: слово "host". Для служб принципал — это название службы.
Дополнительный идентификатор, указывающий имя хоста.
Имя области Kerberos, в которой работает сервер Kerberos.
Серверы приложений Kerberos предоставляют доступ к ресурсам, которые нужны клиентам.
KDC Kerberos предоставляет доступ к ресурсам, таким как эмуляция терминалов и удаленные вычисления.
База данных Kerberos содержит записи о каждом принципале. Это централизованное хранилище Kerberos, содержащее идентификацию клиентов и их доступ.
Служба аутентификации Kerberos выдает билет TGT (Ticket Granting Ticket) клиентам.
Служба выдачи билетов Kerberos аутентифицирует клиентов на основе TGT.
После аутентификации пользователь получает билет аутентификации. Клиент может использовать этот билет для получения билетов на доступ к сервисам приложений.
Kerberos против других протоколов аутентификации сети
Существуют и другие протоколы аутентификации помимо Kerberos. Рассмотрим их:
Kerberos vs. Microsoft New Technology LAN Manager (NTLM): NTLM был предыдущей технологией, используемой Windows. С Windows 2000 все версии используют Kerberos. NTLM использует аутентификацию по принципу вызова-ответа: сервер задает вопрос, на который клиент должен ответить.
Kerberos vs. Lightweight Directory Access Protocol (LDAP): LDAP позволяет поддерживать информацию о пользователях. LDAP и Kerberos могут использоваться в одной сети: LDAP предоставляет службу авторизации, а Kerberos — аутентификацию.
Kerberos vs. Remote Authentication Dial-in User Service (RADIUS): RADIUS был предназначен для удаленного доступа пользователей через модемные соединения. Однако сетевые службы используют его для учета и аутентификации наряду с Kerberos.
Является ли Kerberos безопасным?
Теперь, когда вы знаете, что такое Kerberos, возможно, вас интересует, является ли он безопасным.
Специалисты по безопасности по всему миру считают Kerberos безопасным. Он использует сильное шифрование для защиты данных. Тем не менее, исследователи безопасности обнаружили несколько способов обхода Kerberos:
Атака "Pass-the-key": хакеры подделывают клиентов, используя их учетные данные.
Атака "Pass-the-ticket": хакеры используют билет, когда KDC отправляет сеансовый билет.
Атака "Golden ticket": хакеры используют контроллеры домена Windows для создания учетных данных клиента.
Может ли Kerberos быть взломан?
Ни одна мера безопасности не является на 100% неприступной, и Kerberos не является исключением. Поскольку он существует уже долго, хакеры имели возможность найти способы обойти его, обычно подделывая билеты, делая повторные попытки угадывания паролей (грубая сила/наполнение учетных данных) и используя вредоносное ПО для понижения уровня шифрования.
Тем не менее, Kerberos все еще является лучшим доступным протоколом безопасности. Протокол достаточно гибок, чтобы использовать более надежные алгоритмы шифрования для борьбы с новыми угрозами, и если пользователи придерживаются хороших политик выбора паролей, все должно быть в порядке!
Является ли Kerberos устаревшей системой?
Долговечность не обязательно означает устаревание. Несмотря на некоторые случаи, когда киберпреступники обходили Kerberos (и мы уже установили, что ни одна система безопасности не является на 100% неприступной), Kerberos по-прежнему активно используется и пользуется хорошей репутацией.
Часто задаваемые вопросы
Что такое Kerberos и как он работает?
Kerberos — это протокол сетевой аутентификации, который обеспечивает безопасную аутентификацию в распределенных вычислительных средах. Он использует доверенную третью сторону, называемую Центром распределения ключей (KDC), для аутентификации клиентов и серверов. KDC выдает билеты, которые подтверждают личность клиентов и серверов, позволяя безопасное общение и предотвращая несанкционированный доступ.
Как применяется Kerberos?
Один из примеров применения Kerberos — это система аутентификации, используемая в Microsoft Active Directory. Kerberos является основным протоколом для аутентификации в доменах Windows, позволяя пользователям безопасно получать доступ к сетевым ресурсам и службам.
Какие преимущества есть у Kerberos?
Некоторые преимущества использования Kerberos для аутентификации включают:
Сильная безопасность. Kerberos использует шифрование и взаимную аутентификацию для обеспечения целостности и конфиденциальности обмена аутентификацией.
Единая точка входа. После аутентификации пользователи могут получить доступ к нескольким службам и ресурсам без повторного ввода учетных данных, что повышает удобство и продуктивность.
Централизованная аутентификация. Kerberos предоставляет централизованную систему аутентификации, уменьшая необходимость в управлении отдельными учетными данными для каждой службы или системы.
Масштабируемость. Kerberos может обрабатывать крупные масштабные среды и поддерживает эффективную аутентификацию для большого количества пользователей и служб.
В чем разница между Kerberos и KDC?
Kerberos относится к самому протоколу сетевой аутентификации, тогда как KDC (Key Distribution Center) представляет собой централизованный сервер, который реализует протокол Kerberos. Он состоит из двух основных компонентов: Службы аутентификации (AS) и Службы выдачи билетов (TGS). AS отвечает за начальную аутентификацию и выдачу билетов TGT (Ticket-Granting Tickets), в то время как TGS выдает билеты на доступ к конкретным службам. В общем, Kerberos — это протокол, а KDC — серверная реализация этого протокола.