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

Идея написать статью о примере реализации связки 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).

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

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 5

    0
    «Freeradius понравился всем (особенно отзывчивостью устройства при command authorization...»
    Разве RADIUS поддерживает покомандную авторизацию? Я думал, там только уровень привилегий можно выставить пользователю.
    Конфигурацию можно синхронизировать каким-нибудь drbd (если у вас линукс) или как-то так под фрёй.
      +1
      Вы правы, с помощью radius'а только уровень привилегий. Он не поддерживает command authorization. Это моя ошибка, писал по памяти и она подвела, исправлю. Но совершенно точно помнится, что скорость аутентификации под radius'ом была выше.
      За ссылку спасибо.
        0
        С помощью freeradius все таки можно авторизовывать команды Freeradius Command Authorization, но довольно сложным образом.
        Command Authorization

        Cisco claims that there is a complete mapping scheme to translate TACACS+ expressions into Cisco-AVPair Vendor-Specific. This works for example with the priv-lvl attribute:

        cisco-avpair = "shell:priv-lvl=15"

        The two TACACS+ attributes "cmd" and "cmd-arg" would be needed for command authorization.There is a web page for Cisco IOS detailing which TACACS+ commands exist, and it suggests that

        cisco-avpair = "shell:cmd=show"

        would do the trick to authorize the "show" command. EXCEPT that there is a tiny note for the commands "cmd" and "cmd-arg" saying that they cannot be used for encapsulation in the Vendor-Specific space.

        These two are the ONLY ones. Since it's just about parsing the string content of cisco-avpair at the router side, there is absolutely no technical reason why these two wouldn't go through. The only explanation then is that this is a deliberate step by Cisco to make sure that TACACS+ is "superior" to RADIUS by arbitrarily cutting down functionality.
        0
        Позволю себе добавить ссылку на мой идеологически связанный с текущим пост, не набравший в свое время баллов для «выхода в свет»:

        habrahabr.ru/blogs/cisconetworks/53029/
          0
          Именно на ваш пост я давал ссылку, как на упоминание о tacacs на хабре.

        Only users with full accounts can post comments. Log in, please.