Идея написать статью о примере реализации связки cisco + tac_plus возникла спонтанно, когда глядя на конфиг tac_plus'а понял, что уже не помню что, а главное зачем, я там писал несколько лет назад. Объединить накопленный опыт, набитые шишки, бессонные ночи и шаманские пляски в эдаком мини-howto, который можно будет доработать до рабочей инструкции обязательной для прочтения новому сотруднику и может оказаться полезен кому-нибудь ещё (по моему мнению наступать на описанные грабли можно либо из практического интереса, либо находясь в глубокой депрессии/приступе мазохизма). Ну и с целью разнообразить число статей в русскоязычной части интернета. Но самое главное – это понять, что выбранное направление ведет/не ведет в тупик, либо уважаемое сообщество может подсказать другие решения и подкрепить их собственными примерами.
Данный материал не претендует на полноту рассмотрения протокола tacacs+ (в данной статье он вообще не рассматривается, а исключительно эксплуатируется) и на единственно верный способ конфигурирования aaa-new model, рассчитан на людей имеющих опыт настройки и эксплуатации cisco ios устройств.
Когда парк сетевых устройств исчисляется единицами, вести локальную базу администраторов/пользователей/аудиторов с настройкой индивидуальных view-листов и указанием набора команд для каждого privilege-level ещё возможно. Когда их число приближается к нескольким десяткам – утомительно, переваливает за сотню – … мягко говоря неудобно. В csico ios устройствах реализация aaa (authentication, authorization and accounting) возможна либо с использованием локальной базы пользователей, либо с помощью radius или tacacs+ протоколов, что значительно расширяет возможности. Программных реализаций серверов radius-протокола великое множество, так как сам по себе протокол открытый. С tacacs+ ситуация иная – это проприетарная реализация самой cisco протокола tacacs, но (и это исключительный случай!) его исходники доступны официально, о чем упоминалось на хабре. Естественно необходимо отметить и решение от самой cisco – ACS, вот только стоимость этого со всех сторон замечательного, но очень не бесплатного продукта, не позволила убедить начальство его приобрести. В итоге выбирать пришлось из «бесплатных» реализаций radius и tacacs+: freeradius и tac_plus (есть в портах freebsd, есть версия под windows, из исходников можно собрать под требуемую платформу). Freeradius понравился всем (особенно скоростью аутентификации, все таки tcp вносит микросекундные задержки, что становится более заметным на удаленном устройстве, в отличии от udp транспорта или мне так не повезло?) тем более что он уже был и использовался в компании, но категорически не понравился СБ, так как не умел на тот момент (не знаю как сейчас) получать accounting вводимых команд, не поддерживал в полном объёме command authorization (спасибо Rel1cto) и шифровать данные в пакете, а для СБ эти моменты принципиальны. И все мои поползновения сливать accounting просто на syslog-сервер (благо такой функционал cisco без всякого aaa умеет) пресекались начальственным: «Низя!».
В итоге задачи по authentication (определения действительно ли пользователь именно тот за кого он себя выдает), authorization (можно ли этому пользователю выполнить эту команду) и accounting (все значимые действия пользователя записываются) на сетевом оборудовании были возложены на tac_plus.
Далее приведу ряд команд для настройки aaa с комментариями (я ни в коей мере не буду пытаться конкурировать с command reference для вашего релиза, посему в случае расхождения не судите строго, а обратитесь к первоисточнику)
Автор не несет ответственности за последствия действий лиц прочитавших статью. Выполняя изменения конфигурации на работающем оборудовании, соблюдайте меры предосторожности (как вариант используйте отложенный reload).
В примере конфигурации созданы две группы: 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.
Но вся эта магия начнет работать только при соответствующей настройке клиентского устройства.
Здесь, полагаю, необходимо сделать пояснение синтаксиса: созданы 4 aaa-листа с одинаковым именем admin (имена могут быть произвольными, но из-за принадлежности к одному э-э-э… процессу, я и называю их одинаково), authentication login говорит нашему устройству аутентифицировать пользователя в группе tac-int, а в случае недоступности её серверов локально. Та же самая конструкция используется и для остальных листов, кроме accounting.
В случае если у вас будут пользователи с иными privilege level вам необходимо будет создать соответствующие листы и правила для них.
В эксплуатации эта связка работает уже довольно продолжительное время. С точки зрения стабильности работы никаких претензий не вызывала, СБ, я полагаю, вообще тихо млеет от счастья.
tac_plus поднят на двух серверах размещенных в разных датацентрах, единственное неудобство вызывает необходимость синхронизировать конфигурацию сервера вручную. Кстати, какие будут предложения? Условие: файл конфигурации должен храниться локально на каждом из серверов, а синхронизировать только изменения.
Данный материал не претендует на полноту рассмотрения протокола tacacs+ (в данной статье он вообще не рассматривается, а исключительно эксплуатируется) и на единственно верный способ конфигурирования aaa-new model, рассчитан на людей имеющих опыт настройки и эксплуатации cisco ios устройств.
Мысли в слух
Когда парк сетевых устройств исчисляется единицами, вести локальную базу администраторов/пользователей/аудиторов с настройкой индивидуальных view-листов и указанием набора команд для каждого privilege-level ещё возможно. Когда их число приближается к нескольким десяткам – утомительно, переваливает за сотню – … мягко говоря неудобно. В csico ios устройствах реализация aaa (authentication, authorization and accounting) возможна либо с использованием локальной базы пользователей, либо с помощью radius или tacacs+ протоколов, что значительно расширяет возможности. Программных реализаций серверов radius-протокола великое множество, так как сам по себе протокол открытый. С tacacs+ ситуация иная – это проприетарная реализация самой cisco протокола tacacs, но (и это исключительный случай!) его исходники доступны официально, о чем упоминалось на хабре. Естественно необходимо отметить и решение от самой cisco – ACS, вот только стоимость этого со всех сторон замечательного, но очень не бесплатного продукта, не позволила убедить начальство его приобрести. В итоге выбирать пришлось из «бесплатных» реализаций radius и tacacs+: freeradius и tac_plus (есть в портах freebsd, есть версия под windows, из исходников можно собрать под требуемую платформу). Freeradius понравился всем (особенно скоростью аутентификации, все таки tcp вносит микросекундные задержки, что становится более заметным на удаленном устройстве, в отличии от udp транспорта или мне так не повезло?) тем более что он уже был и использовался в компании, но категорически не понравился СБ, так как не умел на тот момент (не знаю как сейчас) получать accounting вводимых команд, не поддерживал в полном объёме command authorization (спасибо Rel1cto) и шифровать данные в пакете, а для СБ эти моменты принципиальны. И все мои поползновения сливать accounting просто на syslog-сервер (благо такой функционал cisco без всякого aaa умеет) пресекались начальственным: «Низя!».
В итоге задачи по authentication (определения действительно ли пользователь именно тот за кого он себя выдает), authorization (можно ли этому пользователю выполнить эту команду) и accounting (все значимые действия пользователя записываются) на сетевом оборудовании были возложены на tac_plus.
Далее приведу ряд команд для настройки aaa с комментариями (я ни в коей мере не буду пытаться конкурировать с command reference для вашего релиза, посему в случае расхождения не судите строго, а обратитесь к первоисточнику)
Автор не несет ответственности за последствия действий лиц прочитавших статью. Выполняя изменения конфигурации на работающем оборудовании, соблюдайте меры предосторожности (как вариант используйте отложенный reload).
Пример конфигурации tac_plus.conf
# ENCYPTION KEY accounting file = /var/log/tac_plus.acct key = VeryLongANDSecureKey # Groups group = admin { default service = permit service = exec { priv-lvl = 15 } } group = service { default service = deny service = exec { priv-lvl = 15 } } # Users user = art0m { member = admin login = des S451H82iNlwqQ } user = auditor { member = admin cmd = configure { deny .* } cmd = enable { deny .* } cmd = clear { deny .* } cmd = reload { deny .* } cmd = write { deny .* } cmd = copy { deny .* } cmd = erase { deny .* } cmd = delete { deny .* } cmd = archive { deny .* } login = cleartext secret } user = event_manager { member = service cmd = clear { permit .* } cmd = tclsh { permit .* } cmd = squeeze { permit .* } cmd = event { permit .* } cmd = more { permit .* } cmd = show { permit version } cmd = delete { permit .* } cmd = "delete /force" { permit .* } cmd = "enable" { permit .* } login = des nUKsTKiXQ7G16 }
В примере конфигурации созданы две группы: admin и service. Основное отличие в политике применяемой по-умолчанию. Permit означает, что пользователю будут разрешены все команды его privilege level если команда явно не запрещена, а deny соответственно наоборот запрещены все команды, если не указано иное. Это позволяет очень гибко настраивать разрешения на использование команд. В данном примере есть пользователь auditor. Несмотря на то, что он имеет privilege level 15 ему запрещено выполнение явно деструктивных команд. На все попытки их ввести, он получит, например:
#delete flash:*.* Command authorization failed.
Другой вариант применения – пользователь event_manager. В ios есть встроенный механизм, позволяющий выполнять некие действия, реагировать на изменения и т.д. Эти действия выполняются от назначаемого имени пользователя (в данном примере event_manager в ios конфигурации (config)#event manager session cli username event_manager) и этот виртуальный пользователь имеет точно такие же права на исполнения своих команд. Одним из вариантов контролировать происходящее поместить этого пользователя в группу (service в данном примере) с запретом по-умолчанию и разрешить только определенные команды.
accounting file = /var/log/tac_plus.acct – файл, в который записываются все введенные команды в виде: Mon Oct 04 15:37:57 2011 172.18.146.2 art0m tty1 172.16.247.25 stop task_id=823 start_time=1319450277 timezone=msk service=shell priv-lvl=15 cmd=traceroute mac 0050.dead.dead 0050.dead.dead
key = VeryLongANDSecurityKey – ключ, которым шифруются данные между сервером и его клиентом.
В комплекте поставки tac_plus так же идет замечательная утилита tac_pwd, позволяющая вам зашифровать пароль и использовать его в конфиге в зашифрованном виде. Что безусловно не дает права публиковать «боевые» конфиги в инете, но как минимум делает его не human-readable.
Но вся эта магия начнет работать только при соответствующей настройке клиентского устройства.
Пример конфигурации для cisco ios
! включение режима aaa aaa new-model ! настройка tacacs (используя такой синтаксис в 15 и выше получите предупреждение will be deprecated soon) ! tacacs-server host 172.16.247.200 key 0 VeryLongANDSecureKey tacacs-server host 172.18.146.43 key 0 VeryLongANDSecureKey tacacs-server timeout 2 tacacs-server directed-request ! так как у нас 2 сервера (для надежности), то их необходимо объеденить в группу aaa group server tacacs+ tac-int server 172.16.247.200 server 172.18.146.43 ! далее создать листы описывающие authentication, authorization and accounting и связать их с группами aaa authentication login admin group tac-int local aaa authorization exec admin group tac-int local aaa authorization commands 15 admin group tac-int local aaa accounting update newinfo aaa accounting commands 15 admin start-stop group tac-int
Здесь, полагаю, необходимо сделать пояснение синтаксиса: созданы 4 aaa-листа с одинаковым именем admin (имена могут быть произвольными, но из-за принадлежности к одному э-э-э… процессу, я и называю их одинаково), authentication login говорит нашему устройству аутентифицировать пользователя в группе tac-int, а в случае недоступности её серверов локально. Та же самая конструкция используется и для остальных листов, кроме accounting.
! после применения к vty-линии след. команд все решения по authentication, authorization and accounting начнет принимать tacacs-сервер line vty 0 4 authorization commands 15 admin authorization exec admin accounting commands 15 admin login authentication admin
В случае если у вас будут пользователи с иными privilege level вам необходимо будет создать соответствующие листы и правила для них.
Итого
В эксплуатации эта связка работает уже довольно продолжительное время. С точки зрения стабильности работы никаких претензий не вызывала, СБ, я полагаю, вообще тихо млеет от счастья.
tac_plus поднят на двух серверах размещенных в разных датацентрах, единственное неудобство вызывает необходимость синхронизировать конфигурацию сервера вручную. Кстати, какие будут предложения? Условие: файл конфигурации должен храниться локально на каждом из серверов, а синхронизировать только изменения.