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

UWiki

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

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

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

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

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

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

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

RADIUS (Remote Authentication Dial In User Service)

TACACS+

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

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

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

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

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

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

Источник

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+ содержат всю информацию, которая используется в ходе авторизации, а также другие данные, такие как время начала и окончания (если это необходимо) и данные об использовании ресурсов.

Источник

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+ на Linux с аутентификацией через Active Directory

В сети присутствует множество различных гайдов на эту тему, но поднять сервис на Linux и связать его с Active Directory в течении 30-60 минут не удалось. Предлагаю свой путь решения задачи, с подробными комментариями.

Приступим к установке сервиса. В качестве ОСи используется CentOS.

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

Все операции производим под «root»
(соответственно домашняя директория /root)

Установка Tac Plus

Добавляем директории для файлов аккаунтинга

Добавляем Tac Plus в автозагрузку

Проверка включения в автозагрузку

Правим конфигурационный файл

. После каждого изменения конфига сервис должен быть перезапущен (service tac_plus restart)
Пример рабочего конфигурационного файла (нужно заменить содержимое tac_plus.cfg, предварительно внеся коррективы в прокомментированные поля)

Проверяем правильность конфига (если все ОК, то ничего не выведет)

Создаем группы в AD
В Active Directory необходимо создать 2 группы (исходя из нашего конфига): tacacsadmin и tacacsvoip.
Tac Plus отрезает префикс «tacacs» при соотношении группы, указанной в AD, группе в конфиге и переводит оставшиеся символы в верхний регистр.
Таким образом tacacsadmin соответвствует ADMIN, а tacacsvoip соответствует VOIP (изменить данное поведение можно поигравшись атрибутами: AD_GROUP_PREFIX и REQUIRE_TACACS_GROUP_PREFIX в конфиге).
Группы указаны в конфиге большими буквами не случайно!
Добавляем пользователей в созданные группы.

Запуск и остановка сервиса TACACS

Конфигурация сервиса AAA на оборудовании Cisco

Методика дебага
1. Проверка работы модулей LDAP (должно вернуть пустую строку без ошибок). Ошибки в случае не установленного пакета perl-LDAP.

3. Проверка, что сервис запущен и слушает порт tcp 49

4. Для того, чтобы увидеть обращения к сервису

Источник

Протокол TACACS+

Рубрика: Информационные технологии

Дата публикации: 31.05.2018 2018-05-31

Статья просмотрена: 1468 раз

Библиографическое описание:

Карнаухов, В. В. Протокол TACACS+ / В. В. Карнаухов. — Текст : непосредственный // Молодой ученый. — 2018. — № 22 (208). — С. 44-48. — URL: https://moluch.ru/archive/208/50888/ (дата обращения: 10.12.2021).

Одним из самых сложных заданий, с которыми сталкивается сетевой администратор в сегодняшней среде сетевой безопасности, является ограничение доступа к сетевым службам, с которыми сталкиваются авторизованные пользователи. Потребность в сетевой безопасности создает еще большее ограничение для сетевых администраторов, поскольку сети продолжают расти и становятся более децентрализованными. Идеально необходима центральная точка управления — это называется сервером контроля доступа (ACS). На этом сервере будет размещена центральная пользовательская база данных, и, очевидно, может быть более одного сервера в зависимости от размера и потребности организации. В этой статье основное внимание будет уделено пониманию и внедрению TACACS +, однако одна и та же методология может быть применена к другим протоколам, которые обрабатывают контроль доступа. TACACS + означает сервер контроля доступа к терминалу. Он является производным от приложения TACACS, используемого в сети передачи данных.

Ключевые слова: tacacs+, аутентификация, авторизация, аккаунтинг, cisco

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

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

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

Авторизация

Относится к тому, что пользователю разрешено делать, или к каким услугам у пользователя есть доступ. Например: если пользователи набираются в сети удаленно и проходят аутентификацию, авторизация может определять, какие IP-адреса у пользователя есть и какие приложения на этих устройствах.

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

TACACS + использует модель клиент-сервер, на которую клиент запрашивает сервер (работающий в UNIX или NT), и сервер в свою очередь возвращает ответ, в котором указывается решение, по которой пользователь прошел или не прошел аутентификацию. Важно отметить, что клиент не является пользователем или машиной пользователя, а скорее устройством, которое пытается определить, следует ли пропускать пользователя через сеть (как правило, маршрутизатор или брандмауэр).

Простейшая схема использования TACACS+ на Рисунке 1:

TACACS + использует подход клиентской модели. Сервер (работает в UNIX или NT) допрашивается клиентом, а сервер, в свою очередь, отвечает, указав, прошел ли пользователь или не прошел аутентификацию. Важно отметить, что клиент не является пользователем или машиной пользователя, а скорее устройством, которое пытается определить, разрешено ли пользователю входить в сеть (обычно это маршрутизатор или брандмауэр). TACACS + использует TCP в качестве транспортного протокола — порт по умолчанию — 49. При необходимости сервер может быть настроен для прослушивания на других портах. TACACS + похож на RADIUS (удаленный доступ к набору номера на пользовательском сервере) с несколькими ключевыми отличиями. RADIUS использует UDP для связи между клиентом и сервером как TACACS +, используемый TCP.

С подключением TCP ориентированный протокол более надежный, это делает более надежным выбором транспортного протокола. И TACACS +, и RADIUS используют общий секретный ключ для обеспечения шифрования для связи между клиентом и сервером. RADIUS шифрует пароль пользователя, когда клиент сделал запрос на сервер. Это шифрование не позволяет кому-то «сниффить» пароль пользователя с помощью анализатора пакетов. Однако можно проанализировать другую информацию, такую ​​как имя пользователя и службы, которые выполняются. TACACS + шифрует не только всю полезную нагрузку при общении, но также шифрует пароль пользователя между клиентом и сервером. Это затрудняет расшифровку информации о связи между клиентом и сервером. TACACS + использует MD5-хэш-функцию в своем алгоритме шифрования и дешифрования. Наконец, в RADIUS проверка аутентификации и авторизации объединяются вместе. Когда клиент запрашивает аутентификацию с сервера; сервер отвечает атрибутами аутентификации, а также атрибутами авторизации. Эти функции не могут выполняться отдельно. В TACACS + все три функции AAA (аутентификация, авторизация и аккаунтинг) могут выполняться отдельно. Это определенно дает администратору большую гибкость при разработке своей политики AAA. Например, для аутентификации можно использовать один метод, такой как kerberos, и для авторизации может использоваться отдельный метод, такой как TACACS. Конфигурирование TACACS + состоит из двух частей: 1) создание профилей пользователей в базе данных сервера, 2) настройка клиентов для связи с сервером. В целях обеспечения дополнительной защиты мы сосредоточимся на различных примерах эффективного использования TACACS + в сетевой среде Cisco. Допустим, что читатель имеет базовые знания о том, как настроить как маршрутизаторы Cisco, так и брандмауэр Cisco PIX. Пример 1: Защита маршрутизаторов / брандмауэров. Маршрутизаторы и брандмауэры являются критическими компонентом любой сети, и поэтому разумно ограничить доступ к этим устройствам. Мы сосредоточимся на маршрутизаторе Cisco, однако те же шаги необходимы для реализации на брандмауэрах Cisco PIX. При доступе к маршрутизатору Cisco интерфейс командной строки (CLI) существует два основных режима: пользовательский режим и режим включения. Пользовательский режим позволяет вам иметь ограниченный доступ, просматривать конфигурацию и статистику маршрутизаторов. Режим Enable дает право на привилегии суперпользователя, что позволяет вам полностью контролировать маршрутизатор. Оба режима обычно защищены отдельным паролем. Применение фильтра для ограничения, из которого IP-адреса маршрутизатор будет принимать telnet-соединения, может дополнительно ограничить доступ. Хотя это хороший старт, есть несколько проблем с этими методами контроля доступа. Во-первых, использование общего пароля, разрешающего доступ к маршрутизатору, увеличивает вероятность того, что пароль может быть просочился. Добавленное ограничение использования списка доступа для фильтрации адреса источника для доступа по telnet означает, что если можно узнать пароль, можно перейти на машину, на которой разрешено соединение с маршрутизатором и telnet. Если что-то пойдет не так, и необходимо исследовать syslogs, чтобы определить, кто был в «контроле» в то время, единственное, что syslog сможет указать, — это IP-адрес от telnet-сервера, но не тот, кто был зарегистрирован в маршрутизаторе. Некоторый сотрудник делает изменения на маршрутизаторе, не пройдя надлежащие каналы управления изменениями (он пытался сэкономить время, это было просто простое изменение), изменение не идет так, как планировалось, и часть сети не работает. Взгляд на syslogs показывает, что кто-то вошел в маршрутизатор с авторизированного IP-адреса, однако несколько отделов имеют доступ к этой конкретной машине — Engineering Implementation и Operations. Нет никакого способа окончательно знать, если это была просто простая ошибка или была запущенная машина, управляемая в попытке получить доступ к маршрутизатору. Используя AAA, мы можем переместить доступ с сетевого уровня на уровень пользователя. Чтобы получить доступ к маршрутизатору, вход пользователя не только должен исходить из правильного IP-адреса, но также требует проверки подлинности сервером TACACS+. Если устройство было преднамеренно поставлено под угрозу, был бы след аудита, показывающий не только исходный IP-адрес, но и учетную запись пользователя, зарегистрированную в устройстве. Еще один шаг — добавление авторизации. Это позволит некоторым пользователям получить больше привилегий, чем другие. Инженеры первого уровня могут получить авторизацию только для выполнения нескольких команд «показать», в то время как избранные несколько старших инженеров допускают право «суперпользователя» На рисунке 2 показана обычная пользовательская конфигурация на сервере Unix Cisco Secure TACACS +, а на рисунке 3 показан пользователь, у которого есть полные права доступа к маршрутизатору. Обратите внимание, что для пользователя только уровень привилегий установлен в 1, то есть число, которое обозначает регулярное пользовательский режим, в то время как пользователь полностью прав, уровень привилегий установлен равным 15, что означает режим разрешения.

Следующий шаг — настроить маршрутизатор или пикс для использования сервера TACACS + для выполнения проверки подлинности и авторизации.

В командной строке на маршрутизаторе вводятся следующие команды:

tacacs-server host 192.168.2.1 key secretkey

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

Включает аутентификацию AAA

aaa authentication login default group tacacs+

Указывается, что tacacs + будет методом, используемым для определения уровня exec или команды.

aaa accounting start-stop group tacacs+

Позволяет вести учет и указывает отслеживать начало и конец команд, это позволяет отслеживать, какие команды использовались и когда.

Вывод

Использование TACACS + для обеспечения аутентификации, авторизации и учета дает сетевым инженерам дополнительный уровень защиты в защите сетей. Это позволяет регулировать доступ к сетевым службам на более детальной основе. Удаленные пользователи, подключающиеся к сети, могут быть экранированы с пользовательской базой данных и настраиваемой политикой, которая управляет не только тем, к каким устройствам может обращаться пользователь, но и к каким услугам на конкретном устройстве, к которому пользователь может получить доступ. Если учетная запись пользователя скомпрометирована, эта учетная запись может быть отключена. Аккаунтинг обеспечивает аудиторский след, который может использоваться для отслеживания того, какие услуги у пользователя были доступны. Поскольку все больше рабочих начинают работать удаленно из дома, TACACS +, безусловно, может сделать задачу администрирования учетных записей пользователей и сетевых сервисов более эффективной и безопасной. Сервера TACACS + не должны запускаться никакое другое приложение; это минимизирует вероятность взлома сервера с помощью уязвимостей в одном из других приложений. Связь с серверами TACACS + должна ограничиваться устройствами (клиентами), которые должны взаимодействовать с сервером для выполнения аутентификации. Другими словами, если хакеру нужно было получить доступ к внутреннему устройству, он не должен подключаться к серверу TACACS + с такого устройства. Это должно быть обеспечено за счет наличия соответствующих фильтров (списков контроля доступа) на маршрутизаторах, а также путем применения дополнительных мер безопасности к серверу, таких как обертки TCP.

Источник