Такакс сервер что это

TACACS+

TACACS+ (англ. Terminal Access Controller Access Control System plus ) — сеансовый протокол, результат дальнейшего усовершенствования TACACS, предпринятого Cisco.

Улучшена безопасность протокола (шифрование), а также введено разделение функций аутентификации, авторизации и учёта, которые теперь можно использовать по отдельности.

TACACS+ использует понятия сеансов. В рамках TACACS+ возможно установление трёх различных типов сеансов AAA (англ. authentication, authorization, accounting ). Установление одного типа сеанса в общем случае не требует предварительного успешного установления какого-либо другого. Спецификация протокола не требует для открытия сеанса authorization открыть сначала сеанс authentication. Сервер TACACS+ может потребовать authentication, но сам протокол этого не оговаривает.

Содержание

История

TACACS+ является протоколом последнего поколения из серии протоколов TACACS. TACACS — это простой протокол управления доступом, основанный на стандартах User Datagram Protocol (UDP) и разработанных компанией Bolt, Beranek and Newman, Inc. (BBN) для военной сети Military Network (MILNET).

Принцип работы

TACACS+ пользуется транспортным протоколом TCP. «Демон» сервера «слушает» порт 49, который является портом протокола TCP, выделенным для протокола TACACS. Этот порт зарезервирован для выделенных номеров RFC в протоколах UDP и TCP. Все текущие версии TACACS и расширенные варианты этого протокола используют порт 49.

Протокол TACACS+ работает по технологии клиент/сервер, где клиентом TACACS+ обычно является NAS, а сервером TACACS+, как правило, считается «демон». Фундаментальным структурным компонентом протокола TACACS+ является разделение аутентификации, авторизации и учёта (AAA — Authentication, Authorization, Accounting). Это позволяет обмениваться аутентификационными сообщениями любой длины и содержания, и, следовательно, использовать для клиентов TACACS+ любой аутентификационный механизм, в том числе PPP PAP, PPP CHAP, аппаратные карты и Kerberos. Аутентификация не является обязательной. Она рассматривается как опция, которая конфигурируется на месте.

Транзакции между клиентом TACACS+ и сервером TACACS+ идентифицируются с помощью общего «секрета», который никогда не передается по каналам связи. Обычно этот секрет вручную устанавливается на сервере и на клиенте. TACACS+ можно настроить на шифрование всего трафика, который передается между клиентом TACACS+ и демоном сервера TACACS+.

Аутентификация

В ходе аутентификации TACACS+ используются пакеты трех типов: START, CONTINUE и REPLY. START и CONTINUE всегда отправляются клиентом, а REPLY всегда отправляется сервером. Сообщение START описывает тип будущей аутентификации и может содержать имя пользователя и некоторые аутентификационные данные. Пакет START отправляется только в качестве первого сообщения аутентификационной сессии TACACS+ или сразу же после повторного запуска этой сессии. (Повторный запуск может проводиться по просьбе сервера, которая содержится в пакете REPLY.) Пакет START всегда имеет порядковый номер, равный единице. В ответ на пакет START сервер отправляет пакет REPLY. Сообщение REPLY указывает, завершилась ли аутентификация или ее следует продолжить. Если пакет REPLY требует продолжения аутентификации, он также указывает, какую дополнительную информацию ему нужно предоставить. Клиент собирает эту информацию и отправляет ее серверу в сообщении CONTINUE.

По завершении аутентификации клиент может начать процесс авторизации (если она требуется).

Авторизация

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

Аудит

Учет представляет собой запись действий пользователя. В системе TACACS+ учёт может выполнять две задачи. Во-первых, он может использоваться для учёта использованных услуг (например, для выставления счетов). Во-вторых, его можно использовать в целях безопасности. Для этого TACACS+ поддерживает три типа учётных записей. Записи «старт» указывают, что услуга должна быть запущена. Записи «стоп» говорят о том, что услуга только что окончилась. Записи «обновление» (update) являются промежуточными и указывают на то, что услуга все еще предоставляется. Учетные записи TACACS+ содержат всю информацию, которая используется в ходе авторизации, а также другие данные, такие как время начала и окончания (если это необходимо) и данные об использовании ресурсов.

Источник

UWiki

пятница, 7 октября 2011 г.

Протоколы RADIUS и TACACS+: сравнение и принципы функционирования

В статье на доступном языке описаны протоколы RADIUS и TACACS+. И уж точно после ее прочтения никогда не перепутаешь аутентификацию с авторизацией.

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

Поясню на рисунке:

Для начала необходимо определиться с понятиями, я их постараюсь объяснить попонятнее (как когда-то объяснили мне), без всяких там «формул» и т.д, а на обыкновенном человеческом языке.

Прежде всего, эти протоколы предоставляют возможность шифрования (пароля в случае с RADIUS’ом или всего пакета в случае с TACACS+), надежной передачи информации (квитирование), а так же оптимизированы для передачи именно 3A-информации.

RADIUS (Remote Authentication Dial In User Service)

TACACS+

А теперь хотелось бы поподробнее сравнить возможности обоих протоколов.
Для начала таблица:

Базовый протокол

Поддерживаемые сервисы

Безопасность

Поддерживаемые типы аутентификации

Возможность перенаправления запроса

Источник

Настройка cisco aaa + tac_plus (tacacs+)

Идея написать статью о примере реализации связки cisco + tac_plus возникла спонтанно, когда глядя на конфиг tac_plus’а понял, что уже не помню что, а главное зачем, я там писал несколько лет назад. Объединить накопленный опыт, набитые шишки, бессонные ночи и шаманские пляски в эдаком мини-howto, который можно будет доработать до рабочей инструкции обязательной для прочтения новому сотруднику и может оказаться полезен кому-нибудь ещё (по моему мнению наступать на описанные грабли можно либо из практического интереса, либо находясь в глубокой депрессии/приступе мазохизма). Ну и с целью разнообразить число статей в русскоязычной части интернета. Но самое главное – это понять, что выбранное направление ведет/не ведет в тупик, либо уважаемое сообщество может подсказать другие решения и подкрепить их собственными примерами.

Данный материал не претендует на полноту рассмотрения протокола tacacs+ (в данной статье он вообще не рассматривается, а исключительно эксплуатируется) и на единственно верный способ конфигурирования aaa-new model, рассчитан на людей имеющих опыт настройки и эксплуатации cisco ios устройств.

Мысли в слух

В итоге задачи по authentication (определения действительно ли пользователь именно тот за кого он себя выдает), authorization (можно ли этому пользователю выполнить эту команду) и accounting (все значимые действия пользователя записываются) на сетевом оборудовании были возложены на tac_plus.

Далее приведу ряд команд для настройки aaa с комментариями (я ни в коей мере не буду пытаться конкурировать с command reference для вашего релиза, посему в случае расхождения не судите строго, а обратитесь к первоисточнику)

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

Пример конфигурации tac_plus.conf

В примере конфигурации созданы две группы: admin и service. Основное отличие в политике применяемой по-умолчанию. Permit означает, что пользователю будут разрешены все команды его privilege level если команда явно не запрещена, а deny соответственно наоборот запрещены все команды, если не указано иное. Это позволяет очень гибко настраивать разрешения на использование команд. В данном примере есть пользователь auditor. Несмотря на то, что он имеет privilege level 15 ему запрещено выполнение явно деструктивных команд. На все попытки их ввести, он получит, например:

Другой вариант применения – пользователь event_manager. В ios есть встроенный механизм, позволяющий выполнять некие действия, реагировать на изменения и т.д. Эти действия выполняются от назначаемого имени пользователя (в данном примере event_manager в ios конфигурации (config)#event manager session cli username event_manager) и этот виртуальный пользователь имеет точно такие же права на исполнения своих команд. Одним из вариантов контролировать происходящее поместить этого пользователя в группу (service в данном примере) с запретом по-умолчанию и разрешить только определенные команды.

В комплекте поставки tac_plus так же идет замечательная утилита tac_pwd, позволяющая вам зашифровать пароль и использовать его в конфиге в зашифрованном виде. Что безусловно не дает права публиковать «боевые» конфиги в инете, но как минимум делает его не human-readable.

Но вся эта магия начнет работать только при соответствующей настройке клиентского устройства.

Пример конфигурации для cisco ios

Здесь, полагаю, необходимо сделать пояснение синтаксиса: созданы 4 aaa-листа с одинаковым именем admin (имена могут быть произвольными, но из-за принадлежности к одному э-э-э… процессу, я и называю их одинаково), authentication login говорит нашему устройству аутентифицировать пользователя в группе tac-int, а в случае недоступности её серверов локально. Та же самая конструкция используется и для остальных листов, кроме accounting.

В случае если у вас будут пользователи с иными privilege level вам необходимо будет создать соответствующие листы и правила для них.

Источник

3 Атаки на TACACS+ от Cisco

Мне хотелось бы поведать сегодня итоги своего небольшого исследования, связанного с протоколом TACACS+, причём именно с пентестерской точки зрения. Использовать протокол по прямому мне не приходилось, так что каких-то тонкостей могу не упомянуть.

Что такое TACACS+

Terminal Access Controller Access-Control System Plus (TACACS+) — специальный протокол от Cisco для AAA (authentication, authorization, and accounting). То есть это протокол для централизованного управления доступом – чаще всего доступом именно к Cisco, но можно прикрутить что-то еще.

Итак, обычно поднимается один-два сервера с TACACS+ сервисом на 49 порту протокола TCP, а на всех устройствах настраивают его использование. Таким образом, когда пользователь хочет аутентифицироваться на свитче, роутере или другом устройстве, устройство пересылает его аутентификационные данные на TACACS+ сервер, где их проверяют, и принимается решение о разрешении доступа, о чём и сообщается в ответных пакетах

Удобно, централизовано. Можно настроить различные привилегии для различных пользователей на различных устройствах. Есть логирование доступа и действий на серверной стороне. Можно прикрутить поверх другую централизацию доступа, типа AD или LDAP’а. Есть open source реализации сервера (Cisco когда-то официально выложила код).

Атака №1

Первая «атака» больше похожа на некий трюк, чем на полноценную атаку, но может быть полезна в определённых ситуациях.

Итак, представим себе, что в ходе пентеста мы получили конфиг от циски (например, стянув его с TFTP-сервера). Это, конечно, хорошо, но даже если мы успешно набрутим локальную учётку от устройства, то мы не сможем залогиниться, так как устройство будет проверять учётку на TACACS+-сервере.

Но здесь стоит вспомнить типичную конфигурацию при подключении к TACACS+.
Представим себе, что с сервером TACACS+ что-то произошло и он недоступен для Cisco устройства, но админу может быть надо залогиниться на устройство, а он не может этого сделать. Для таких целей Cisco устройства поддерживают различные «виды» аутентификации, которые администратор должен указать при настройке.

Так, классическая конфигурация аутентификации для Cisco c TACACS+ выглядит следующим образом:

Здесь нам важны последние два слова, которые указывают на то, что сначала аутентификация будет проверена с помощью TACACS+, а после – путем поиска в локальной базе юзеров. Причём, если юзер не найден в TACACS+, то он не будет проверяться и локально.

Суть же первой атаки заключается в том, что мы, как атакующие, DoS-им сервер TACACS+, после чего подключаемся к желаемому Cisco устройству используя локальную учётку. Причём DoS имеется в виду в более широком смысле – можно специальный пакет послать (когда-то находили) и большим количеством TCP-соединений…

Интро для атак 2 и 3

Перед тем как перейти к атакам 2 и 3, необходимо узнать ещё кое-что о протоколе TACACS+. Данные в протоколе передаются либо плейн-текстом, либо можно включить шифрование. Организуется оно на основе PSK (Pre-Shared Key), т.е. администратор сам указывает один ключ на TACACS+-сервере и всех подключающихся к нему клиентов (девайсов). Причём шифруются только пользовательские данные, заголовки TACACS+ не шифруется. Само шифрование, насколько мне известно, происходит следующим образом:
Зашифрованные данные (enc_data) представляют собой результат операции XOR с данными (data) и специальной строкой – pseudo_pad.

pseudo_pad является последовательностью MD5 хешей.

MD5-хеши создаются на основе данных из заголовков TACACS+-пакетов, плюс общий ключ (PSK), плюс предыдущий хеш (для первого MD5 его, соответственно, нет). Т.е.:

Где session_id – случайный идентификатор сессии; version – версия протокола; seq_no – инкрементируемый номер пакета; key – PSK.

И вроде как данные зашифрованы…

Атака №2

Итак, давайте конкретизируем задачу и уточним ситуацию. У нас есть устройство Cisco и сервер TACACS+. И мы можем получить зашифрованный TACACS+ трафик между ними (с помощью Man-in-the-Middle, например). Цель же наша – получить PSK, и с помощью него расшифровать трафик и получить валидные учётки.

Теперь давайте посмотрим, что мы можем сделать. Для начала, как мы видим, значение MD5 создаётся от нескольких значений, но только одно них мы точно не знаем – общий ключ, тогда как все остальные можно получить из заголовков TACACS+-пакета. Таким образом, если упросить задачу, то всё сводиться к тому, чтобы перебором (без этого никуда 🙂 подобрать ключ. При этом MD5 можно брутить в оффлайне очень быстро. Но для этого нам нужно получить значение MD5_1.

Далее, мы должны вспомнить, что XOR – это обратимая операция. Т.е. если у нас была операция «data^pseudo_pad=enc_data», то «pseudo_pad=data^enc_data». При этом XOR – это простейшая операция и изменение части строки не влечет изменений в другой части строки. Получаем MD5_1 – это начальная часть pseudo_pad. Если точнее, 128 бит или 16 байт. И, таким образом, чтобы получить MD5_1, нам нужно знать первые 16 байт зашифрованных данных и 16 байт изначальных данных. И если зашифрованные данные мы имеем в любом количестве из трафика, то как нам получить 16 байт изначальных данных?

Важно отметить: формат отличается для запросов и ответов, а также для различных их видов (надо вспомнить, что TACACS+ — это AAA — Authentication, Authorization, Accounting).

Но общая закономерность у них сохраняется — случайные или неизвестные нам значения в первых 16 байтах почти отсутствуют.

Не буду углубляться в подробности и приведу лишь самый удобный пример. Это первый ответ от TACACS+-сервера. Он содержит в себе несколько полей с однозначным значением и строку приветствия от Cisco устройства для пользователя. А так как строку приветствия мы можем получить при подключении, то получается, что мы все значения знаем наверняка.

Таким образом, мы почти точно знаем, какие не зашифрованные данные находятся в пакете, что даёт возможность нам получить MD5_1 и уже локально брутить его. В случае успеха, мы сможем полностью расшифровать трафик.

Для упрощения задачи по парсингу пакета и выделению MD5_1, я набросал тулзеньку: tac2cat.py (как часть проекта TacoTaco, см. далее)

Атака №3

Про эти две атаки я рассказывал на недавней встрече Defcon Russia на CC’2015. И в добрых традициях нашей группы, в ходе дискуссии мне дали пару дельных советов. Один из них от заключался в том, чтобы посмотреть в сторону возможности bit flipping’а

Итак, сценарий последней атаки. У нас есть устройство Cisco и сервер TACACS+. Мы можем проводим активную Man-in-the-Middle атаку (т.е. можем менять трафик). Цель – «поломать всё»

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

Вторая особенность была в формате пакетов. И для пакетов аутентификации, и для авторизации, при запросе разрешения основной ответ передаётся в первом байте ответа. Например, 0x01 – аутентификация успешна, 0x02 – не успешна.

В итоге для реализации этой атаки была написана тулза – tacflip.py (как часть проекта TacoTaco)

Проверена работа её (обход аутентификации и авторизации) с 7200-циской в GNS3 и open source реализацией TACACS+-сервера – tac_plus.
Кусок конфига по TACACS+ выглядит следующим образом.

А вот и небольшое демо-видео входа на устройство, повышения привилегий и выполнения команды.

Ситуация…

В 2000 году Solar Designer сделал интересный ресёрч протокола goo.gl/E2IGnk. Например, было обнаружена возможность replay-атак, или раскрытия длины пароля пользователя (из-за отсутствия padding’а), и кое-что ещё (bit flipping). Но практической реализации их в паблике я не нашел…

Но мой «ресёрч» этого протокола является лишь перечнем случайных взаимодействий с протоколом в течение долгого времени, а не целенаправленным исследованием. Из-за чего я забыл про итоги Solar Designer’а и кое-что заново переоткрыл.

Возможно, главным итогом моих трудов являются рабочие тулзы (пока в стадии беты).
Знакомьтесь — проект TacoTaco github.com/GrrrDog/TacoTaco

Итого:

Можно, наверное, посчитать, что протокол TACACS+ с его реализацией не даёт необходимого уровня защиты от MitM атак.

С другой стороны, данные атаки несколько затруднены, так как часто TACACS+ серверы располагаются в VLAN’ах, доступных только для администраторов и сетевого оборудования (вроде как рекомендации от Сisco). Но это уже другая задачка.

Источник

Другой tacacs+

Я думаю, про tacacs+ его настройку, политики, ACL и прочее сказано, а уж тем более написано более чем достаточно. Но, что меня всегда напрягало в tacas+ — постоянно чего-то не хватает. Некая недоработанность что ли.
Например, нельзя задать баннер на вход группе хостов, можно только по отделенности. Нельзя применить идентичные настройки к группе хостов, можно только по отдельности. И наберется ещё с пяток таких придирок. Возможно, я чего-то не знаю, но пока для меня всё обстоит именно так.
На прошлой работе, видел необычный tacacs+, который в корне отличался от стандартного. И вот, спустя какое-то время, я его нашел. И не просто нашел, а внедрил в небольшую конторку.
Речь пойдёт о проекте: www.pro-bono-publico.de/projects/tac_plus.html. Статья будет несколько в духе «How-to», надеюсь кому-то она окажется полезной.

Исходные данные:
Сервер, с debian wheezy на борту, на котором уже стоит tacacs+ и tftp, установленные мной же из репозиториев.

Приступаем к установке и настройке нового tacacs+ (естественно, удаляем старый tacacs+).
Собирать его мы будем с помощью checkinstall. Нам понадобятся некоторые библиотеки и gcc-multilib. Ставим:
apt-get install flex bison libtool gcc-multilib checkinstall
Подготавливаем к сборке:
./configure
И собираем:
checkinstall

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

tacacs-sourse — каталог, куда мы распаковали исходники.

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

Далее, самая интересная часть — конфигурирование.
На сети, я использовал tacacs+ для cisco, juniper, zelax, qutech.

Но, приступим к конфигурации самого tacacs+:
Для начала, стоит создать каталог, где будет храниться файл конфигурации, у меня это /etc/tacacs+/. Далее, создадим сам файл конфигурации, у меня — tacacs.conf. Выставляем права 600 на папку и файл, чтобы никто посторонний не смог подсмотреть конфиг.

Далее, приведу простенький пример конфигурационного файла с комментариями:

Пользовательские пароли храним зашифрованным в md5 либо DES. Согласно документации это можно сделать так:

Как вы заметили, всем пользователям по умолчанию даются привилегии 15 уровня (cisco). Однако, пользователи группы noob всё равно смогут выполнить только явно разрешенные им команды. Мне кажется это удобным, не надо постоянно вводить пароль на привилегированный режим.

Возможности ACL тут шире, чем в стандартном tacacs+, но и синтаксис здорово отличается. Для более детального изучение стоит покурить man. В рамках этой статьи останавливаться на ACL я не буду.

И так, мы получили вполне рабочий tacas+. Попробуем его запустить:

Правда удобно видеть сколько пользователей в данный момент пользуются системой (особенно, когда хочешь её остановить)?

На сайте www.pro-bono-publico.de. Есть пример init скрипта, я его немного изменил под свои нужды:

Даем скрипту права на исполнение (chmod +x). Обзываем его например tac_plus и кидаем в /etc/init.d. Все. Теперь можно стопарить, запускать, рестартовать tacas+ с помощью service tac_plus start/stop/restart.

Серверная часть готова. Перейдем к настройке активного оборудования. На самом деле, тут все просто, отличился лишь juniper. Для cisco конфиг думаю смысла приводить нет (для zelax и qutech он практически идентичен), а вот для juniper приведу. Кстати, в документации описано, как подружить juniper и tacacs+. В свое время, мне пришлось здорово с этим повозиться.

Конфиг для juniper:

Даже с включенным tacacs+, вы сможете попасть на juniper под учетной записью root. Это делается для того, чтобы вы могли попасть в shell. По учеткам tacacs+ вы попадаете сразу в cli.

Так же, настоятельно рекомендую выделять подсеть управления и навешивать на все устройства ACL, с доступом только с этой подсети.

А сейчас, приведу несколько скриншотов:

З.Ы. К вопросу стабильности. На прошлой работе систему юзало куча администраторов и было несколько тысяч устройств. Все было, в принципе, хорошо.
На текущем месте — это несколько десятков устройств и пяток пользователей, все прекрасно.

Источник