AAA, RADIUS, TACACS+ и управление доступом

Так, друзья, у нас сегодня 4 октября, третий день нашего курса CCNA Security INS 30, и мы будем говорить уже о более приземлённых технических вещах. Мы вчера и позавчера разговаривали об основах безопасности, много всего интересного разобрали, и вчера у нас был разговор про эшелонированную защиту. Если кто-то помнит, это про то, что защита должна быть на всех уровнях, не стоит пренебрегать этим правилом, и следуя этому принципу, каждое устройство должно быть защищено. Сегодня мы будем, наверное, целый день разговаривать именно о защите самих устройств — не о защитных функциях, которые будут выполнять маршрутизаторы или firewall, а именно о защите самих наших

железок. Это тоже очень важно, этому уделяется достаточно большое внимание в крупных инсталляциях. Нет, Роман, CPP чуть-чуть попозже, это будет к разговору про control plane. Сейчас мы больше говорим о management plane, об административном доступе к железу. На CCNA Security об этом разговор у вас уже какой-то состоялся, вы уже немножко в курсе, хотя бы что такое парольный enable — все знают. Здесь мы будем развивать эту тему, это я считаю важная тема, она кстати мне тоже очень нравится. Итак, архитектура AAA — ещё иногда называют «triple A». Это термин, под которым понимается аутентификация, авторизация и аккаунтинг. Административный и сетевой

доступ — что такое административный доступ, что такое сетевой доступ? Административный доступ — это доступ для управления самим устройством. Сетевой доступ — это доступ через наше какое-то устройство. Например, доступ по VPN — наше устройство может служить сервером VPN и предоставлять сетевой доступ в нашу сеть. Это тоже надо немножечко различать. Очень часто путают молодые администраторы такие понятия, как аутентификация и авторизация. Если вы плохо в этом ориентируетесь, сейчас я вам это объясню. Даже если вы хорошо в этом ориентируетесь, я всё равно вам это ещё раз напомню. Аутентификация — это идентификация. Аутентификация — это когда мы вводим логин и пароль, когда нас просят представиться. Не обязательно нас — когда

нужно кого-то идентифицировать однозначно — это аутентификация. Авторизация — совершенно другой процесс. Это выдача разрешений, выдача каких-то полномочий субъекту, которого мы перед этим идентифицировали. Аутентификация и авторизация — это разные процессы, они друг с другом могут даже совсем не соотноситься, но, как правило, всегда это всё работает вместе. Аккаунтинг — это третья буковка «A» в нашей аббревиатуре. Она обозначает аудит действий, запись всех действий какого-то субъекта, в нашем случае какого-то администратора железа. Кто-то что-то хочет меня поправить? Иннокентий правильно поправил — иногда один процесс выполняет и аутентификацию, и

авторизацию. SMS в банке с одноразовым кодом — действительно, это процесс, который выполняет и аутентификацию, потому что однозначно можно быть уверенным, что это вы, потому что это ваш номер телефона, и авторизует, потому что пускает вас в банк-клиент, даёт доступ на совершение какой-то операции. Очень хорошее замечание. Запомните по аббревиатуре ИРА. Игорь, если вы немножко расшифруете мне аббревиатуру ИРА... А, всё, я понял, я просто думал, ещё какая-то есть аббревиатура. ИРА — по которой можно запомнить: идентификация, разрешения, аудит. Наверное, можно и так запомнить, хотя я думаю, здесь запоминать-то нечего, просто надо один раз навсегда запомнить различия между аутентификацией и авторизацией, и всё будет очень просто. Когда мы будем говорить

про «triple A», мы будем подразумевать всё сразу. Соответственно, информация об этих действиях, об этих разрешениях — она тоже может где-то храниться. Я не буду сейчас разделять информацию аутентификации или авторизации — всё вместе, вот эта сущность «triple A», мы про неё и говорим. Где мы можем хранить эту информацию? Мы сейчас говорим уже про конкретные сетевые устройства, не как-то обобщённо и размыто, а про конкретные железки. Информацию мы можем хранить в двух местах: во-первых, на самом железе, во-вторых, в каком-то внешнем источнике. И тот, и тот подход имеет свои плюсы и минусы. Плюс того, что хранить на железе — это прежде всего то, что что бы ни случилось с остальной инфраструктурой, наше устройство будет всегда доступно. С другой стороны,

если этих устройств много — десятки, сотни или даже тысячи, — то управлять, например, аутентификацией на этих устройствах становится очень и очень трудно. Получается главная боль — представьте, пароль для пользователя прописать на сотни коммутаторов. В таком случае, конечно, решение с каким-то внешним хранением этих данных оправдано и интересно. С другой стороны, внешнее хранение, как правило, подразумевает централизованное хранение на каком-то одном сервере или кластере серверов — получается тоже своеобразная единая точка отказа, хотя можно всё зарезервировать, никто не запрещает. Вот мы и добрались — я уже забежал вперёд — пара слов о локальной и централизованной базе. Хранилище этих данных называется база. У нас есть локальная база на локальном устройстве —

самый простой способ хранения. Мы уже проговорили, что он не масштабируется, нет поддержки аккаунтинга. Да, действительно, в устройствах Cisco аккаунтинг — запись действий пользователя — возможен только во внешнюю базу. Это имеет смысл, потому что, так же как журналирование — мы с вами тоже про это будем попозже говорить — имеет смысл записывать действия пользователя вместе с остальными системными журналами куда-то во внешний источник для дальнейшего разбора инцидентов, а также чтобы нельзя было затереть следы — тоже очень удобно. Обычно используется в небольших инсталляциях, мы про это тоже немножко поговорили. Централизованная база AAA — учётные данные создаются и изменяются централизованно, управление такими данными является более простым, все политики доступа можно также ими рулить

централизованно — это очень удобно. Опять же, централизованный аудит — классно и понятно. Но может стать единой точкой отказа, да, действительно. Какие есть протоколы? Протоколы AAA — это протоколы, с помощью которых клиент — здесь под клиентом подразумевается не пользователь, который будет подключаться к нашему маршрутизатору, а сам маршрутизатор — с помощью этих протоколов он будет взаимодействовать с внешним сервером, с AAA-сервером. NAS — Network Access Server, есть такое понятие. Но в терминологии Cisco AAA-сервер — это тот же RADIUS. Распространены два протокола. На самом деле их больше, но мы говорим

на нашем курсе — да и вообще в реальном мире — используются два протокола AAA: протокол RADIUS и протокол TACACS+. Протоколы имеют существенные различия и области распространения. От себя могу добавить, что, наверное, RADIUS более распространён, хотя могу ошибаться. Немножко технических подробностей: RADIUS работает по UDP — это важно помнить, и я думаю, вам будет полезно запомнить порты RADIUS, потому что вдруг на экзамене спросят, да и вообще помнить их полезно. Стандартный набор портов — это 1812, который используется для аутентификации и авторизации, и 1813. Смотрите, RADIUS использует разные подключения к разным портам, чтобы передавать сообщения аутентификации и авторизации с помощью

одного подключения, а аккаунтинг — для аккаунтинга используется второе подключение. Старые порты — 1645 и 1646. Мы сейчас будем делать лабораторную работу и посмотрим — долгое время по умолчанию на устройствах Cisco именно они присутствовали. Если вы забиваете конфигурацию RADIUS и не указываете порты 1812 и 1813, то до какой-то версии операционной системы именно эти старые порты 1645 и 1646 подставлялись. Мы сейчас это проверим ещё раз на устройстве. Просто помните, что у Cisco любимые порты были вот эти старые — 1645 и 1646. Поэтому я ещё раз заострю на этом внимание, когда будем конфигурировать, но это помнить надо. TACACS+ работает по TCP, у него один-единственный 49-й порт, и по нему передаются все сообщения: аутентификация,

авторизация, аккаунтинг. Ещё надо сказать, что не стоит путать протокол доступа и способ хранения информации — это тоже очень важная вещь, потому что в каких-то источниках или в разговорах очень часто путают эти понятия и говорят, что «я авторизуюсь на RADIUS-сервере», «RADIUS-сервер хранит мои логин и пароли». Мы с вами всё-таки стараемся называться профессионалами, а профессионал отличается именно чёткой терминологией — мы должны называть вещи правильными именами. RADIUS — это просто протокол доступа, протокол авторизации и аутентификации. С помощью этого протокола мы только можем спросить у сервера какие-то авторизационные данные, например. RADIUS-сервер всего лишь говорит: «можно» — даёт

разрешение, говорит «можно пойти в сеть» или «нельзя пойти в сеть». Хранятся все эти данные — учётные записи — например, совершенно в других местах. Да, Иннокентий, спасибо — это просто обмен сообщениями. Хранилище может быть любое: мы можем хранить где угодно — в LDAP, в Active Directory, в блокноте, в SQL — совершенно неважно, где хранятся эти данные. RADIUS-сервер, в свою очередь, будет уже обращаться к этому хранилищу учётных записей, брать оттуда какие-то данные, либо, в случае аккаунтинга, будет куда-то дальше передавать и записывать сообщения аккаунтинга, но сам он обычно ничего не хранит — это не его задача. Какие есть альтернативы? В настоящее время, честно скажем, альтернатив немного. RADIUS имеет своё логическое продолжение — есть протокол, который начали разрабатывать уже

много-много лет назад, но пока никакого серьёзного распространения не получил — протокол Diameter. Вот такая альтернатива. TACACS+ — я должен уточнить одну вещь: что современный протокол называется TACACS+. Для обмена сообщениями AAA есть ещё протокол TACACS — он старинный, совершенно старый, но в современном мире уже привыкли говорить без слова «плюс» — TACACS, а на самом деле TACACS+ имеется в виду во всех современных реализациях. Различия между RADIUS и TACACS — это тоже надо помнить хотя бы для себя, не обязательно для экзаменов. По поводу сообщений — да, Иннокентий правильно уточнил, что недавно — ну как недавно, сколько

там прошло, год, три — уже давно. Это был Cisco'вский протокол, и на него уже сделали RFC, он сейчас является стандартным, его в принципе уже реализуют многие вендоры, он реализован как сервер на Linux — никаких проблем в этом нет. Дальше давайте немножко про различия. RADIUS совмещает аутентификацию и авторизацию в рамках одного процесса. Мы сейчас с вами будем смотреть RADIUS на лабах просто потому, что я лично считаю RADIUS более распространённым протоколом, и мне везде встречается RADIUS, я сам на нём всё настраивал. Так вот, RADIUS совмещает аутентификацию и авторизацию в рамках одного процесса, соответственно, сообщения тоже будут общие. Но сообщения RADIUS мы не будем глубоко ковырять, смотреть дампы — нам это

на самом деле ни к чему, сами понимаете, что мы на CCNA Security находимся. TACACS+, наоборот, разделяет аутентификацию, авторизацию и аккаунтинг между индивидуальными процессами — там работают три разных процесса и будет разный обмен сообщениями. Например, в TACACS+ очень удобно сделать авторизацию каждой команды, введённой пользователем. RADIUS такого не позволяет. Дальше: RADIUS требует от клиента принятия всех свойств авторизации в момент аутентификации сразу. Когда мы обращаемся к RADIUS-серверу, говорим логин и пароль, RADIUS-сервер говорит нам: «Хорошо, заходите, аутентификация пройдена» — и сразу же вываливает нам какие-то разрешения, отдаёт какие-то атрибуты авторизации. Это очень важно понимать, что здесь сразу же идёт авторизация

одним потоком. TACACS+, наоборот — мы сначала аутентифицировались одним процессом, другой процесс будет отвечать за авторизацию, то есть можно вплоть до того, что каждую команду проверять, спрашивать у TACACS-сервера: можно эту команду выполнить или нельзя? TACACS-сервер будет отвечать: это можно, это нельзя. RADIUS не шифрует никакие данные, которые он передаёт, — только пароли. Для этого используются протоколы аутентификации PAP, CHAP, MS-CHAP, EAP — можно использовать. TACACS+, наоборот, в принципе шифрует всё, то есть в рамках сессии, которая устанавливается, всё будет зашифровано. Последняя оговорка: зачастую RADIUS используется для управления доступом к сети, то есть я в начале сказал — есть административный доступ и сетевой доступ. Когда сетевой доступ — всякие

DSL, всякие пулы PPP, которые ушли в прошлое, VPN, какие-то концентраторы — здесь RADIUS используется намного чаще. TACACS+ используется для административного доступа к устройству. В случае с устройствами Cisco, конечно, TACACS+ здорово, потому что у него возможности больше именно по авторизации на устройстве. Когда сетевой доступ происходит, надо понимать: например, человек подключается по VPN — наш маршрутизатор просто спрашивает у RADIUS-сервера, правильная пара логин-пароль или неправильная, и спрашивает, может быть, ещё какие-то атрибуты, например, какой IP-адрес выдать подключённому клиенту, либо ещё что-то — время сессии, сколько она может жить. Единожды спросил, клиента пустил — всё,

дальше ничего не нужно с этим делать, никакой дополнительной авторизации. А вот с TACACS+ будет уже поинтереснее — там мы запускаем пользователя на устройство, потом можем уже дополнительно его авторизовать. По поводу серверов AAA — несколько слов. Мы сказали — я сказал одно, здесь написано другое — что серверы AAA централизованно хранят базу данных аутентификации. Они обращаются к базам данных аутентификации, управляют политиками доступа и служат средством учёта. На самом деле есть такие продукты, типа Cisco ISE или более старый Cisco ACS, где просто в рамках одного сервера было несколько приложений: и база там хранилась, и всё на свете — там

просто один сервис RADIUS работал, один сервис LDAP, то есть всё хранилось. Можно в принципе это тоже представить как AAA-сервер — такое единое целое. Например, Cisco ISE, хотя он кучу всего другого умеет. Но если рассуждать правильно, то RADIUS-сервер или TACACS+-сервер — это просто процесс, просто программа, и она будет у кого-то ещё запрашивать эти данные. Cisco предлагает два сервера для предприятий: ACS и ISE. Здесь имеется в виду, что они всё хранят. Можно использовать другие продукты: есть Windows Server со службой NPS, есть FreeRADIUS — замечательный сервер в Linux и BSD. Без исключений, сетевые устройства являются AAA- клиентами. NAS — Network Access Server, аббревиатуру которую я забыл. Ещё

раз надо проговорить про терминологию: клиент AAA — это не пользователь, который подключается к устройству, а это именно наше устройство, которое будет потом у сервера что-то запрашивать — какие-то разрешения. Серверы, в свою очередь, будут клиентами для других каких-то систем, например, запрашивать учётные данные в LDAP, в Active Directory или ещё где-то. Некоторые сетевые устройства, включая Cisco ASA, могут взаимодействовать напрямую с Active Directory и LDAP. Да, есть такая штука, Cisco ASA это умеет. Мы с вами это разбирать не будем, такие возможности есть, потому что по ASA есть отдельный жирный курс, в котором это всё уже разбирается. Да и не только Cisco ASA на самом деле умеет — и у других производителей есть. То есть устройства могут сразу обращаться в базу данных за учётными

данными без посредства RADIUS. Продолжаем. Ещё некоторые сравнения серверов AAA — в принципе они всё умеют. Мы здесь сравниваем Cisco ACS с Cisco ISE — это вот два таких продукта. Но сейчас Cisco ISE всё-таки такой флагманский продукт, хотя он и стоит как самолёт. Да, Игорь, я вот про это и говорю, что сейчас он основной продукт. ACS — всё, он уйдёт в историю, и он поддерживается просто потому, что там очень большое количество инсталляций. Он, понятно, не такой навороченный, как ISE, потому что ISE — это флагманский продукт, у которого с каждым годом всё новые и новые возможности

появляются. Но в принципе, если нужно использовать только управление доступом — сетевым и административным — то за глаза хватает других продуктов. Тот же самый NPS в Windows — он бесплатен по факту, это просто одна из ролей Windows Server, или FreeRADIUS, за который тоже никто денег не просит. И эти серверы справляются. Все серверы умеют обращаться к внешнему хранилищу, умеют использовать данные из внешнего хранилища для принятия решений по авторизации. Но Cisco'вские продукты ещё умеют и RADIUS, и TACACS+ прямо всё вместе использовать — и это, и это могут. У ISE есть ещё профилирование, оценка состояния, централизованная веб-аутентификация. Я бы назвал там ещё примерно 1853 фишки, которых больше нигде нет. Ну конечно,

потому что этот продукт — это не просто сервер AAA. Я не специалист по лицензированию продуктов Microsoft и правда вам не скажу, нужна ли клиентская лицензия — как она называется, CAL — клиентская лицензия для NPS. Может быть, Иннокентий скажет. Я честно не знаю. Нет, в лабе вы можете делать вообще всё что угодно, потому что Microsoft'овские продукты, новые, начиная наверное с 2008 Server, — клиентских лицензий не требуют никакой установки. Клиентская лицензия — это просто бумага: когда вы платите деньги партнёру Microsoft, то просто получаете

бумагу, на которой написано, что вы заплатили деньги и вы можете использовать в вашем домене 50 клиентских лицензий или 100 клиентских лицензий. Технически это никак в системе не фигурирует. Вы можете сделать NPS-сервер RADIUS на Windows, в котором будет хоть тысяча, хоть 20 тысяч пользователей — технических ограничений здесь нет. Я просто поэтому честно не знаю: если вы хотите предоставить доступ на тысячу пользователей по VPN с помощью NPS, нужны ли клиентские лицензии или не нужны — правда, не скажу. Вопрос интересный, я думаю, что кому-нибудь его можно задать. Так, обзор — поговорили про это дело. Давайте теперь уже говорить более конкретно про аутентификацию и

авторизацию именно в нашей любимой системе Cisco IOS. Давайте говорить про аутентификацию и авторизацию внутри Cisco IOS. Но для начала — на CCNA Security вы слышали уже этот рассказ, мы его чуть-чуть поподробнее копнём — эту тему про уровни привилегий. Уровни привилегий — это иерархическая политика для авторизации доступа к командам. Уровни привилегий в Cisco IOS — от 0 до 15. Как вы знаете, 15-й уровень — это самый верхний уровень. Когда мы набираем команду enable, нас может спросить пароль, мы попадаем с вами в 15-й уровень по умолчанию. Вот три уровня: 15-й — это привилегированный режим, нулевой уровень — это самые минимальные возможности, в нём есть только

enable, disable, help и logout. Больше в этом уровне нет ничего. По умолчанию, когда вы подключаетесь к маршрутизатору, вам даётся первый уровень привилегий. Остальные уровни — со 2-го по 14-й — они никак не определены, и вы можете на этих уровнях придумать свои какие-то, дать им свои привилегии, свои разрешения и потом уже с этим работать. Каждому уровню можно назначить свой набор команд — это в принципе удобно. Вы можете создать свою иерархическую структуру в своём подразделении, где каждый администратор будет иметь только своё. Надо помнить, что каждый уровень включает в себя команды нижележащих, то есть уровень 7 будет включать в себя команды 1, 2, 3, 4, 5, 6-го уровней тоже.

То есть это именно иерархическая структура. Мы с вами дальше будем говорить немножечко про другую систему, где можно будет назначать привилегии параллельно. Здесь это не параллельно, это иерархия, как такая лесенка. На NX-OS похоже, в принципе механизм схожий, различия есть. Пример распределения привилегий: у нас есть команда, которая работает только на 15-м уровне, например, IP route — она будет работать только на 15-м. Команда, которая будет работать на нулевом-первом уровне, — она будет работать и на уровнях выше, на восьмом. Как это всё конфигурируется? Смотрите, здесь мы сейчас — у нас

консольки ещё недоступны, пока на слайдах разберёмся, как это всё конфигурируется. Мы с вами можем задать для конкретного уровня конкретные команды. На самом деле команды просто глазами смотрите — они очень простые. Команда privilege именно говорит нам о том, какие привилегии задать, в каком уровне какие команды сделать доступными. Задаём уровень 7 и говорим, что clock set, либо ещё какую-то команду. Мы сейчас с вами в лабе всё сделаем. После указания — да, Иннокентий попросил нажать F5 — после задания команд для уровня неплохо бы для этого конкретного уровня придумать свой пароль. Более того, если вы пароль не поставите, то в зависимости от версии он работать вряд ли будет —

скорее всего не будет работать. Чтобы получить доступ к конкретному уровню, просто набрать enable и номер этого уровня — у вас запросит пароль, и попадёте в нужный уровень. Если вы не знаете, на каком уровне привилегий вы находитесь, у нас есть команда show privilege. Про уровни привилегий я кратко рассказал, мы сейчас в лабе тоже всё это пощупаем и посмотрим. Стоит сказать, что уровни привилегий — вот такое конфигурирование — используется сравнительно редко. Есть гораздо более удобный механизм, мы с вами попозже рассмотрим. Но кто-то, наверное, обходится именно разрешениями по уровням. Я скажу, что этот механизм, наверное, можно назвать нежелательным. Теперь поговорим

про локальную аутентификацию. Мы с вами уже проговорили про то, что аутентификация может быть локальная и не локальная. Сейчас именно про локальную говорим. Для того чтобы у нас всё заработало, в Cisco IOS есть такая команда: aaa new-model. Вот эту команду очень важно не забывать, потому что без неё вы никакую нормальную аутентификацию, авторизацию — ничего не настроите. И я каюсь, что иногда сам забываю: я начинаю настраивать какую-то авторизацию или аутентификацию, потом понимаешь, что команды не работают, просто нет нужных команд, и только потом вспоминаешь, что это же до сих пор по умолчанию выключено. Как ни странно, new-model — «новой моделью» это было очень много лет назад, действительно очень давно, но вот так осталось: есть старая модель управления доступом и

вот это новая. Пусть вас это не смущает — этому механизму огромное количество лет, но до сих пор я не знаю, почему компания Cisco не включила её по умолчанию, хотя, наверное, уже пора — уже столько лет прошло. Теперь стоит поговорить про то, какие есть методы аутентификации. Надо понимать, что мы можем аутентифицировать пользователя совершенно по-разному. Давайте я расскажу про эти методы — их, наверное, может быть даже для экзамена кому-то будет полезно запомнить. Смотрите, первый метод — local. Local — это когда операционная система будет смотреть в конфиг, ведь это всё в конфиге хранится — все пользователи. Она будет

смотреть в конфиг, смотреть имя пользователя, смотреть пароль или хэш пароля, если мы правильно всё настроили — мы про это с вами вчера поговорили — и давать добро или не давать добро. Есть метод аутентификации local-case. В local-case будет учитываться регистр. По умолчанию в имени пользователя регистр не учитывается, то есть если набрать пользователя root с большой буквы, в случае local неважно, как вы потом будете представляться — root маленькой буквы или все большими буквами наберёте имя пользователя. Local-case ещё включает именно case sensitivity — чувствительность к регистру. Есть метод аутентификации enable, то есть мы можем сказать, что для того чтобы войти на устройство, нужно набрать тот самый пароль, который вы сконфигурировали командой enable — такой

метод аутентификации тоже есть, тоже работает. Group RADIUS и group TACACS+ — это в случае, когда у нас используется какой-то внешний сервер. Мы можем использовать не один RADIUS-сервер, мы даже не можем, а неплохо было бы использовать несколько серверов для отказоустойчивости: если вдруг один выйдет из строя, будет другой — 3, 5, 10. Их можно объединять в группы, причём объединять в группы можно хитро: можно несколько групп сделать, в каждой из которых будет несколько серверов. Но, как правило, делается просто одна общая группа RADIUS-серверов, и к ней обращаются. Алгоритм выбора сервера в группе — честно, мне не известен. Если они оба на одинаковом расстоянии, в одной сети, я правда не знаю, как выбирается первый сервер. Вероятно, это будет адрес, который идёт первым, но я не буду

говорить точно. Метод аутентификации line — мы можем задать пароль на линию. Если кто-то помнит с курса CCNA Security — пароль на консоль задавали же, правда? Line console 0, password такой-то — было же дело. Вот, в принципе, мы можем и в качестве аутентификации локально использовать этот самый пароль, который у нас на линии сделан — почему нет. Либо есть none — это тоже метод аутентификации. Мы говорим о том, что аутентифицировать пользователя не нужно, нужно его просто взять и пустить. Это не обозначает запрет, это наоборот обозначает, что не надо аутентифицировать. Вот эти методы — их на самом деле: раз, два, три, четыре, пять, шесть, семь. Если мне не изменяет память, по-моему, мы перечислили здесь все современные. В старых системах может быть что-то ещё было, но нет, по-моему, всё перечислили. Сейчас, секундочку, я проверю на всякий случай.

Да, по-моему, всё перечислили. Смотрите, эти методы можно объединять в списки. Списки — это то, в чём на самом деле запутываются все люди, которые занимаются на курсе CCNA Security и которые начинают разбираться с аутентификацией на Cisco, с авторизацией и аутентификацией. Просто надо запомнить, что есть методы: либо так будем аутентифицировать, либо так. Мы говорим устройству, как нужно действовать. На CCNA Security уже были списки аутентификации. Сейчас, если вы знаете это, — уже хорошо, сейчас ещё раз проговорим. Их можно объединять в списки — просто сказать роутеру: у тебя есть список действий такой-то. Или другой — можно создавать много этих

списков. По умолчанию уже есть список default. И мы говорим: если, например, к нам постучится пользователь в консоль — локальную — у нас аутентификация, вот тебе список из таких-то методов. Сначала попробуешь по локальной базе — или, как правило, лучше наоборот: сначала попробуешь постучаться на RADIUS. Если на RADIUS ничего не ответили, потом попробуешь в локальной базе найти этого пользователя. Если в локальной базе этого пользователя нет, попробуй ещё парольный enable, например. Вот прямо включаем все эти методы в один список. А вот, например, пользователи, которые подключаются с помощью какого-нибудь VPN-соединения или L2TP и тому подобного — без разницы какого — мы создадим другой список. В этом списке напишем: посмотреть в RADIUS и больше нигде не смотреть, потому что у нас только на

На RADIUS-сервере мы только к ним уходим за пользователями, можно создавать списки. Разные списки аутентификации можно применять к разным типам доступа. Мы можем аутентификацию настраивать — мы сейчас будем дальше ещё смотреть это в лабе — именно к разным типам доступа: административный доступ либо сетевой, можем разную аутентификацию для них делать, никто это не запрещает. Это очень удобно, это единственный механизм, который есть у Cisco, но он очень гибкий, и я думаю, что достаточно мощный, не нужно придумывать никаких других дополнительных костылей, и так всё прекрасно работает. Смотрите теперь по команде. Вот эта команда, в которой все путаются. Как у нас настройка локальной аутентификации будет: структура команды такая — aaa authentication, и дальше мы говорим, что мы

аутентифицируем, какая подсистема. Login — это те пользователи, которые на наше устройство подключаются с консоли или по Telnet, вот кого мы пускаем на наше устройство. Либо подсистема может быть PPP — это те пользователи, которые аутентифицируются, подключаются к нам по PPP либо по PPPoE. Мы можем это использовать. Дальше имя списка — я пару примерчиков написал — имя списка либо default, не использовать, почему нет, можно и всё в default написать, и будет работать. И дальше перечисление методов. Смотрите, очень важная штука: если один из методов сказал «нельзя», доступ запрещён, то остальные методы обрабатываться не будут. Это очень важно, на самом деле вопрос такой непростой, он

попадался в таких старших даже экзаменах, серьёзных. Надо ещё раз понимать, что смотрите, например, вот этот пример: мы сначала указали group radius — пусть вас не смущает два слова в команде, это на самом деле один метод, group radius, и group — так называется метод, ну так назвали. Сначала мы пробуем group radius, сначала мы пробуем ломиться на RADIUS-сервер и спросить: можно ли этому пользователю с этим паролем идти? Если RADIUS сказал, что нельзя, доступ запрещён, то следующий метод мы даже пробовать не будем, мы до него не дойдём. Если же RADIUS-сервер у нас просто недоступен, ну выключился или ещё что-то, то в таком случае мы будем использовать уже локальную аутентификацию.

Метод будет работать только если предыдущий не сработал, не если предыдущий ответил отказом, а если он просто не сработал. Вот эта штука, понятно? Запомните. Я не думаю, что у вас там на экзамене будут мучить такими вопросами, но это важно понимать и важно знать. Теперь про авторизацию. С авторизацией тоже всё похоже. Мы можем связать — мы сейчас говорили про уровни привилегий — мы можем с конкретной учётной записью связать конкретный уровень привилегий. Это надо тоже знать, мы можем сказать, что пользователю такому-то мы даём вот именно такую-то привилегию, этому пользователю — другой уровень привилегий. Здесь тоже есть свои методы, их не так много, как в аутентификации. Авторизация у нас

может быть либо локальная — мы прямо в конфиге пишем username Вася, privilege level 8, secret такой-то пароль такой-то — вот прямо в локальной базе, это локальный метод авторизации. Мы можем спросить у RADIUS либо у TACACS-сервера, что делать. В случае с RADIUS, как я уже говорил, мы не будем спрашивать отдельно авторизацию, но просто скажем логин и пароль, RADIUS нам вывалит список атрибутов: вот этому пользователю вот такой уровень привилегий дать, а этому пользователю вот такую привилегию дать, или этому пользователю вот такой IP-адрес выдать в случае с сетевой авторизацией. В случае TACACS мы разделяем эти процессы, как я уже говорил: аутентификация отдельно, потом уже авторизацию спрашиваем, когда нам нужно, мы будем ещё спрашивать какие-то данные.

Авторизации есть такой ещё метод if-authenticated — если пользователь был аутентифицирован, если он был аутентифицирован раньше, то предоставить доступ. Либо метод авторизации none — не нужна никакая авторизация. Так же, как и в случае аутентификации, их тоже можно объединять в списки, точно так же создать список для административного доступа отдельно либо создать отдельный список для сетевого доступа. Можно применять к разным действиям. Авторизация — установка привилегий при входе в систему, как я уже объяснил, как с RADIUS происходит: мы входим в систему, RADIUS нам сразу выдаёт какие-то привилегии, какие-то атрибуты. Он пишет там атрибут такой-то, атрибут такой-то, в этих атрибутах содержится нужная нам информация, мы

даём сразу уровень привилегий, всё, и забываем. Либо авторизация команд: в случае TACACS можно каждую команду проверять, стучаться на TACACS и спрашивать, можно или нельзя этому пользователю. На TACACS будет такой список команд разрешённых. Либо сетевые подключения PPP — те же самые, я уже сказал, что IP-адрес можно выдавать, там можно тоже, атрибутов на самом деле очень-очень много, если разобраться. Те, кто в провайдере работает, который такой обычный домашний провайдер, очень любит использовать PPPoE всякие для аутентификации-авторизации. Там RADIUS у них в почёте, и там RADIUS им отдаёт такие пачки обычно атрибутов, и там всё на свете можно настроить с помощью RADIUS, ну почти всё на свете. Как формировать списки —

списки аутентификации, списки методов. Вы про это говорите, Олег? Да-да. Точно так же, смотрите, они точно так же формируются. Вот как формируется список: мы говорим aaa authentication, у нас про авторизацию всё то же самое. Давайте даже порисуем здесь. Вот у нас список, вот это название списка PPP auth. Сейчас дальше тоже будет, просто здесь очень наглядно нарисовано. И говорим дальше, какие методы мы будем использовать: первый метод, второй метод, там третий, четвёртый и так далее. Я затрудняюсь сказать, сколько можно методов включить в один список, но если подумать логически, то не больше, чем вообще всех методов и есть. На авторизацию всего 5 методов, и больше чем 5 методов

вы не включите. Нельзя сначала попробовать RADIUS, потом локальную базу, потом ещё раз RADIUS, а потом опять локальную базу ещё раз. Я никогда так просто не делал. Ну, групп до группы RADIUS-серверов может быть несколько, всё правильно: сначала к одной группе обратиться, потом к другой группе. Это я не учёл. Ну да, у меня одна группа RADIUS, но в принципе там много особо ты их не напишешь. Сколько у вас есть групп RADIUS-серверов, все остальные там по порядку перечислить — вот вам весь список. Как настраивается локальная авторизация — всё очень похоже, точно так же мы делаем. Но сначала, вот кстати, у нас полная картина здесь, как вообще нормально настраивать. Сначала включаем модель — механизм AAA, настраиваем список для аутентификации, настраиваем список для авторизации. Exec — это имеется в виду авторизация для административного доступа. У нас список default, и у него всего лишь два

метода авторизации: либо локальная, либо не надо авторизовать. Как назначаются уровни привилегий пользователям: мы создаём пользователя какого-то, говорим ему уровень привилегий 1, 7, суперадмина 15, задаём пароль — всё, этого достаточно. При коннекте, когда человек заходит Telnet'ом на наше устройство, то сначала будет отрабатывать аутентификация — спросили логин-пароль, потом авторизация. Процесс авторизации посмотрит, какой там у него уровень привилегий, и даст ему именно этот уровень привилегий. Запомните такую простую штуку: по умолчанию для консольной линии авторизация отключена. Её в принципе можно включить, есть такая команда aaa authorization console. По умолчанию, когда вы заходите на консоль, вам даётся какой уровень привилегий? Кто-нибудь помнит? На консоли

или не помнит? Нет, а login local — это именно включить аутентификацию на консоли. Нет, по умолчанию на консоль полный 15 уровень выдаётся, и всё. Нужно ли делать авторизацию на консоли или не нужно — это тоже вопрос в плане безопасности интересный. Я придерживаюсь того мнения, что не нужно. Есть такое понятие out of band, если вы слышали, мы ещё про out of band будем разговаривать дальше. Это понятие обозначает то, что у вас всегда должен быть какой-то workaround, бэкдор, чтобы на крайний случай вы стопроцентно

получили доступ к железке. Я вам скажу, что у меня в моём хозяйстве есть один роутер, один из роутеров Cisco 1921, у неё железные проблемы, проблемы с памятью, я мало использую, но вот есть такая железка. У неё наблюдалась такая проблема, причём я обновлял IOS — без разницы, просто почему-то процессу AAA не хватает оперативки. У меня оперативки полно свободной, но процессу AAA оперативки не хватает, и он не пускает ни по Telnet, никаким образом. Если ещё и авторизацию на консоль включить, то прикольно конечно, чтобы пользователей-администраторов разграничить, но в случае, если у вас AAA не будет работать, а он может упасть, как я убедился на своём горьком опыте, — но консоль у меня не

закрыта, шкаф закрыт, Андрей правильно сказал, — то вы вообще доступ к железке никакой не получите, только перезагружать. А сами понимаете, перезагружать — это не всегда можно, не всегда удобно. Поэтому вот эту штуку лучше не включать, пусть останется бэкдор, лучше физическую защиту применить — закрыть ящик на ключ, и всё, намного лучше. И надо не забывать про enable secret. Enable secret — зачем это написано на слайде? Это тоже из моего личного опыта. В разных версиях IOS 15 уровень работает по-разному. Например, вы можете создать пользователя, задать ему 15 уровень привилегий, потом вы будете подключаться этим пользователем. Смотрите на слайде: пользователь superadmin, задали ему 15 уровень привилегий и задали ему secret.

Потом в какой-то момент, когда вы подключаетесь с консоли, настраиваете железку, всё нормально. Потом взяли железку, запаковали и отдали, чтобы её отвезли в филиал, в другой город. А потом вы подключаетесь с этим пользователем по SSH и не получаете вообще ничего. Нет, вернее, вы получаете первый уровень привилегий. Но когда, если вы забыли поставить пароль на enable, а до этого он работал без пароля на enable, то вам система говорит: пароль не установлен, я вас не пущу на enable. Серьёзно, вот такая штука есть, но это не во всех версиях. На консоли enable можно без пароля делать. Запомните вот такой

момент: на VTY вы зайдёте, вам всё равно даст первый уровень привилегий, и если не установлен enable secret, то всё, до свидания, придётся страдать. Вот так. Давайте продолжать, а продолжать я предлагаю в лабе. Давайте быстро сейчас в лабе пробежимся по уровням привилегий. Hostname R1 — как назвали свой роутер? А чего же роутер-то не назвали? Я вас знаете что прошу сделать: дальше мы будем с RADIUS работать, для RADIUS-а не особо нужно, настройте пожалуйста нормально: R1, R2, не R02, R2 лучше, чтобы так совпадало. Кто знает, где нам ещё это имя роутера понадобится? Оно может понадобиться.

Роман, правильное уточнение сделано. Я думаю, все знают, если кто-то не знает, что если что-то удалённо настраиваешь, то нужно использовать reload. Лучше использовать reload in. Reload — это перезагрузка в конкретное время, а reload in — это перезагрузка через какое-то время. Reload in 10 — перезагрузка через 10 минут, и он в любом случае перезагрузится. Ну да, чтобы не ехать в другой город, очень полезно. Так, мы с вами про уровни привилегий говорили. Чтобы посмотреть уровень привилегий, у нас есть команда — я буду полностью команды сюда набирать. Чтобы посмотреть уровень привилегий, у нас есть команда show privilege, которая показывает уровень привилегий 15. Сейчас у меня 15. Как настраивается уровень привилегий? У нас есть команда privilege, и дальше, если посмотреть,

нажать знак вопроса, то на самом деле уровней привилегий дофига всяких разных есть. Но нас интересует только exec. Exec — это наш командный процессор, это наша консоль, наша оболочка, правильнее будет сказать. Итак, мы здесь говорим privilege exec, какой уровень — давайте сделаем уровень 7, как на слайде будет, и дальше мы просто говорим команды, которые можно: clock set, например. Хватит, этого достаточно. Надо не забывать давать secret на уровень, какой-то пароль на 7 уровень. Вообще, писать лучше полностью. Хватит. Чтобы

перейти в нужный уровень привилегий, мы просто говорим enable, и чтобы перейти на другой уровень привилегий, мы всего лишь навсего можем сказать enable и нужный нам уровень 7. Нас должен спросить пароль. А почему он меня пароль не спросил? Потому что я пароль не для того уровня дал. Хотя у нас стоит enable secret, это если из 15 уровня пойдёт вниз, а вот наверх запросит пароль. Сейчас мы сделаем так. Даже

я ещё параллельно пытаюсь к RADIUS-серверу подключиться. Вниз, когда мы спускаемся из 15 в 7, то там Иннокентий правильно сказал: бесплатно, не нужен пароль. Если наверх — вот у нас сейчас, если посмотреть уровень привилегий, мы на первом уровне. Если мы пойдём наверх, то нас уже спросят пароль. А какой пароль я туда забил, я не помню. Всем secret. Если сейчас мы посмотрим — покажу 7 уровень. Если мы посмотрим, какие есть команды, то по сравнению — команд на самом деле немного, они все есть у нас

в первом уровне, но добавилась команда clock. Мы говорили с вами про то, что уровень привилегий включает все команды из нижележащих уровней. Смотрите, просто в первом уровне команды clock у нас не было, в седьмом уровне мы её добавили. Это такой довольно простой механизм, и я бы не сказал, что он очень мощный. Сейчас мы посмотрим, как сделать немножко поинтереснее. Так, вы успеваете за мной или вас чуть-чуть подождать? Давайте дальше. Дальше мы смотрели вещи по локальной аутентификации. Сейчас я проверю уровень своих привилегий — он у меня 15, я могу делать с железкой всё, что захочу. И

давайте посмотрим на списки аутентификации, с которыми всегда у всех проблемы, и на то, как их настраивать. Ну, поехали. Для начала разберёмся с тем, что никаких команд для настройки аутентификации не должно быть по умолчанию. Просто я до этого настраивал роутер, у меня уже введена команда. Если вы не введёте команду aaa new-model, то у вас вот этого ничего работать не будет. Сейчас, если её убрать, то никаких команд, связанных ни с аутентификацией, ни с авторизацией, вы не получите. Надо сначала включить aaa new-model, которая по умолчанию отключена. Не очень хорошо, но просто не забывайте включить. Итак, давайте с вами придумаем какой-нибудь сценарий. Я, к сожалению, его не придумал заранее, мы придумаем с вами сейчас.

Мы будем настраивать административный доступ. Сетевого доступа у нас пока нет, мы никаких VPN не делаем, никакие PPP нам сейчас не особо нужны. Мы настраиваем административный доступ к устройству. Давайте сделаем таким образом: мы создадим пользователя, пусть будет называться admin. Мы создали до этого какой-то уровень привилегий промежуточный, я создал 7, вы может быть какой-то другой создали. Мы создадим пользователя с этим уровнем привилегий и будем с ним работать. Все помнят, как пользователи создаются, или никто не помнит? Username admin, дальше мы говорим, что уровень привилегий у нас 7, и задаём. Нет, я ему задам password. Помните, чем отличается password от secret? Конечно же вы должны помнить. Я ему задам password — нешифрованный пароль,

хрен бы с ним, но потом ещё с этим делом подружимся немножко. И пароль я ему задам вот такой, очень сложный, который фиг подберёшь. На устройстве Cisco посмотрю, не осталось ли у нас ничего в конфиге от моих предыдущих настроек. Всё, у нас сейчас в конфигурации только один единственный пользователь с 7 уровнем привилегий, мы с ним будем работать. Давайте смотреть, как настраивается аутентификация. Сначала мы пока авторизацию не будем трогать. Начинается всё со слов aaa authentication, а дальше, если нажать вопросик, то у нас будут вот эти самые подсистемы, для которых мы сейчас настраиваем. Мы можем отдельно настроить аутентификацию — смотрите сюда — там

для login, то есть кто заходит на VTY или на консоль, отдельно для PPP, отдельно для dot1x, там для one password и так далее — для всего, что железо поддерживает. Мы настраиваем login, так как мы занимаемся сейчас административным доступом. Подсистему мы определили, а дальше мы должны создать список вот этих самых методов аутентификации, которых дофига, сейчас мы увидим. Ну, как дофига, я вам показывал. Либо создать свой список, либо работать с дефолтным. Я предлагаю создать свой список, почему бы нет, и с ним уже работать. Назовём этот список… Нет, лучше назвать его VTY-login, так

будет, наверно, красивее. И дальше добавляем в этот список просто какие-то методы. Про Kerberos мы там забыли написать в этом слайде, я забыл указать Kerberos. Локальный — давайте сначала по локальной базе работать. Нет, давайте сначала вот так мы сделаем: мы сделаем, что сначала будет система запрашивать RADIUS. Так как RADIUS-сервер у нас ещё не настроен и ещё не работает, то система потом спросит у своей локальной базы. Вот так будет интересно. Мы ему скажем, что group radius — первый метод аутентификации мы ему сказали. Дальше следующий метод аутентификации у нас будет

local. Хватит, наверно, двух. Имя группы не надо здесь, group radius и local. Хватит. У нас будет одна группа, у нас вообще один RADIUS-сервер, достаточно этого. Теперь давайте смотреть, как всё это дело работает. Debug — я думаю, что на CCNA 1 и на CCNA 2 и Иннокентий и все остальные тренеры всегда говорят: никогда не включайте debug, это такая ужасная вещь. Конечно, не включайте debug, но он нам нужен, нам интересно. Посмотрим debug AAA authentication, что же будет происходить. Мы пока на консоли подключены, выходим отсюда и пытаемся зайти. У нас получилось, что мы зашли, но ничего не произошло. У нас AAA

вообще не отработала. Кто скажет, почему? Чего мы забыли? Нет, enable secret здесь ни при чём. Я что-то такое забыл. Не отработало. Мы создали список аутентификации. Нет, команду RADIUS-сервер сейчас вообще не нужно, мы же не обязаны настраивать RADIUS-сервер, правильно? Зачем его настраивать? Олег ответил правильно: повесить аутентификацию на линию. Здесь точно такая же ситуация, как с access-листами, если кто-то помнит. Всё, что рассказывали на предыдущей сессии: сам по себе access-лист по сути — бесполезный кусок конфига, который вообще ничего не делает. Просто написали access-лист, всё, он ничего не делает. Его надо куда-то применить. То же самое и со списком аутентификации —

его надо куда-то применить, чтобы система знала, где его использовать. Мы создали какой-то список, но не сказали, что дальше с ним делать. Давайте его применим. На консоли он на самом деле сейчас вешается вот так. Смотрите, давайте — я что-то просто быстро очень делаю. Мы заходим на консольную линию, line console 0, и говорим login authentication. Помните, на CCNA на консоли какую или на консоли не настраивалась никакая аутентификация,

но здесь внутри только AAA new-model не включалась. Ну давайте. Да, Иннокентий правильно сейчас говорит, потому что лучше на VTY, а не на консоль, чтобы не перезагружать роутер и всё нафиг. Давайте на VTY будем Telnet'ить самих себя — очень хорошее предложение, потому что лучше на line VTY, давайте на линию VTY повесим всё это дело. Login. Олег пишет... Не то. Я вас активно всех читаю. Ну да, Глеб...

Так, смотрите. Список аутентификации login authentication — он на самом деле сейчас работает, если локальный. Вот здесь мы можем указать список, как он у меня назывался — VTY-login. Вот, теперь если посмотреть в конфиг, смотрите: exec — это в авторизации используется, exec — это имеется в виду команды, командный процессор, сама оболочка. Login — это процесс логина. Мы говорим: аутентификация для процесса логина и говорим, какой список. Мы говорим: авторизация для командной строки,

назовём это тогда для оболочки exec, и говорим список аутентификации. Так, давайте тогда это настроим ещё. VTY transport input telnet, всё, потом пойдём сами на себя. Я всё время набираю, почему не работает — Ctrl+Z не с первого раза отрабатывает. Ну всё, поехали проверять. Telnet сами на себя. Он у меня спрашивает, смотрите, он задал вопрос, и вот здесь стоит почитать дебаги. Вот процесс AAA сейчас выбрал — видите, method list, список методов, который называется VTY-login, то, что я задал, определил этот список ранее. Мы сейчас на линии VTY сказали, что аутентифицировать по этому списку. Мы видим, что по этому списку у нас пошла работа.

Timeout, пока я рассуждал. Давайте ещё раз. Я говорю admin и пароль cisco. Как вы помните, мы сначала RADIUS-сервер настроили, вернее мы его не настроили, но у меня в системе остался настроенным. Смотрите, давайте ошибки разберём. Мы сказали, что сначала попробовать group radius, а потом local. Вы точно не забыли потом попробовать local, но он тоже должен пустить. Group radius, local, но не пустил. При этом пароль точно правильный. Можно потрогать, пошутить немножечко. На самом деле, когда не настроен RADIUS, он просто скажет, как у меня, что нет сервера, нет сервера, либо сервер не отвечает, если он там сконфигурирован, и по локальной базе аутентифицирует. Другого быть не может, если аутентифицирует по локальной базе данных. Всё правильно. Так, Роман, я уже это объяснял. Если

мы посмотрим ещё раз — я объяснял — мы создали с вами список аутентификации. Где он есть? Вот он. То же самое, как и со списком доступа, так же как access-листы: он сам по себе бесполезен, пока его не применить никуда. Написали мы его, написали, как access-лист, ну и написали, ну и что. Вот, пока когда мы его включим на линии — вот настройка линии. Так, кто у нас просил настройку? Олег просил про настройку линии, по-быстрому. Мы на линии VTY должны сказать, что аутентифицировать, пожалуйста, по нашему созданному списку. По-другому этот список просто не заработает. Это то же самое, как с access-листами: сам по себе он не работает. Как access-лист написали — пока не применить на интерфейс, не заработает. Ну, или ещё где-то, их можно где угодно применять.

Так, ждём остальных. Смотрите, Telnet'ом зайти смогли. Помните, я вам сказал, что нужен enable secret? Когда мы зашли, давайте разберём сейчас. Мы зашли с вами Telnet'ом, он попробовал RADIUS-сервер, наш маршрутизатор до RADIUS-а не достучался, потому что вообще не сконфигурирован, аутентифицировал нас по локальной базе, выдал нам, кстати, какой уровень привилегий? У пользователя был написан 7 уровень привилегий. Почему первый выдал уровень привилегий? Кто-нибудь может сказать вот так сходу? Мы про это говорили 10 минут назад. Нет, не бардак. Почему не седьмой уровень привилегий дал, а первый дал? Это важный вопрос, это важно понимать. Почему нет привилегий? Мы

создали 7 уровень привилегий, мы пользователю, когда создавали, сказали, что у тебя уровень привилегий 7, но при логине он их не получил. Не надо начинать подсказывать. Давайте ещё раз поговорим. Мы с вами настраивали сейчас что? Мы настраивали аутентификацию. А выдача уровня привилегий — это авторизация, это совершенно другой процесс. Всё правильно. Уровень привилегий нам никто и не даст, потому что у нас не настроена авторизация. И её надо настраивать, не просто так. Так что пока мы до этого ещё не добрались, сейчас мы, конечно же, настроим. Смотрите.

Почему не пускает? В enable был error, я вам про это совсем недавно говорил, потому что в дебаге на самом деле всё сказано: когда мы набираем enable, процесс аутентификации выбирает метод enable — видно, как я выделяю в консоли. Мы же говорили, что есть такой метод аутентификации enable. А дальше процесс аутентификации говорит, что не может найти ни одного пароля, и говорит «до свидания». А потом он говорит: не осталось больше методов, чтобы попробовать ещё что-то. Когда мы набираем просто слово enable, запускается тот же самый процесс аутентификации — вот он запускается и ищет парольный enable. Парольный enable мы не задали. Единственный случай, когда можно работать

без установленного пароля enable — это в консоли, мы же проговаривали это. Сейчас мы по telnet сами на себя зашли, поэтому он нам говорит error. А в дебаге написано, что метод enable, но пароль найти не может. Так что те, кто спрашивал, мы получили ответ на свой вопрос. Всё сходится, всё правильно. В данном случае мы с вами получили первый уровень привилегий, и в enable зайти не можем. С другой стороны, если попробовать зайти на 7 уровень — набрать enable 7, зайти в enable 7 — то нас туда пустят. Но я не помню какой пароль. Поехали ещё раз с самого начала, я всё проговариваю.

Не перебивайте, я быстро, просто чтобы в записи осталось. Итак, первое что надо сделать — включаем triple A new-model, включили. Дальше нам надо создать пользователя. А нет, сначала создадим уровень привилегий — добавим одну командочку, чтобы был какой-то 7 уровень привилегий. Мы скажем privilege exec level 7 и дадим команду clock set — пусть будет добавлена у нас эта командочка. Дальше мы зададим на 7 уровень парольчик: enable level 7 — я буду везде пароли cisco оставлять, чтобы не запутаться. Окей, всё, 7 уровень привилегий мы настроили. Дальше займёмся настройкой локальной — мы пока только локальной

занимаемся — аутентификации. Мы создадим пользователя username, дадим ему имя admin, скажем, что у тебя уровень привилегий 7, и твой пароль — я пока пользуюсь именно словом password — тоже будет cisco. Пользователя создали с этим седьмым уровнем привилегий. И теперь начинаем разбираться с аутентификацией. Мы решили, что для тех пользователей, которые у нас подключаются по telnet, мы будем использовать такой список, в который включим только нужные нам методы аутентификации: сначала RADIUS попробуем, если RADIUS не ответил — что с ним случилось — попробуем локальную базу. Вот этот самый username admin и пароль его. Сейчас только аутентификацию настраиваем и говорим, что аутентификация для login — список у нас будет называться

VTY_LOGIN. И дальше мы перечисляем методы. Если мы вспомним слайд, который мы посмотрели недавно, там этих методов достаточно много, но нас интересует сначала group radius — он называется в два слова, вот это очень многих путает — а потом локальная аутентификация. Мы сначала говорим group radius, а потом говорим local. Всё, список этих методов аутентификации мы с вами создали. Дальше ещё раз повторяю в восьмой раз: мы создали этот список, он на самом деле бесполезен сейчас, потому что его никто не будет применять и никто с ним не работает. Так же как access-лист — создали просто access-лист, он вообще бесполезен. Поэтому теперь нам нужно настроить линию VTY, чтобы при коннекте на эту линию запустилась подсистема аутентификации, чтобы она именно этот список

VTY_LOGIN выбрала для аутентификации, чтобы перебрала методы, которые в этом списке есть. Идём на линию и говорим, что login authentication — и дальше задаём наш список VTY_LOGIN. Всё, вот теперь при подключении на эту линию у нас процесс аутентификации будет обращаться именно к этому списку и перебирать методы, которые мы указали здесь: сначала RADIUS, потом локальная база. Не забудем transport input telnet, а то у нас по telnet никого пускать не будет. Дальше мы уже проговорили несколько раз, что если мы не зададим пароль на enable, то выше первого уровня привилегий мы не поднимемся при подключении по линии. Поэтому ещё на всякий случай

зададим enable secret — я задам enable password, пусть будет пока всё в таком виде, тоже cisco. Всё, в принципе на этом настройка локальной аутентификации закончена, больше здесь ничего не надо. Андрей, сейчас мы про авторизацию поговорим чуть-чуть попозже, нам надо с аутентификацией разобраться. Скажите, пожалуйста, мы вот это для себя уже всё уяснили, проработали методом проб и ошибок. Мы знаем, что теперь — как мы поймём, какой cisco, в смысле какой cisco отработал, почему? А как поймём? У пользователя пароль cisco, а где мы ещё пароль cisco задавали? На enable. Но на enable он тоже будет работать. Можно

посмотреть дебаг. Когда, смотрите, сначала — когда мы будем ломиться на telnet, сначала будет у нас аутентифицироваться пользователь по своему паролю. Если мы вот в этот — смотрите, мы в принципе в этот список можем ещё добавить: сначала RADIUS попробовать, потом local попробовать локальную базу, а потом теоретически можем, если уж и в локальной базе пусто, попробовать login enable — спросить у него, вдруг он его знает. Но это очень маловероятно, что такого пользователя нет, а логин и пароль enable известен. Теоретически можно, и тогда будет: сначала RADIUS, потом локальная база, потом парольный enable. Давайте тогда на этом сейчас аутентификацию завершим, я предлагаю

небольшой перерыв, и будем уже с авторизацией разбираться. С аутентификацией мы разобрались. Напоминаю, у нас есть пользователь admin, у которого 7 уровень. Теперь нам нужно настроить авторизацию, чтобы всё-таки admin, когда заходит по telnet на наш роутер, получал 7 уровень привилегий, а не 1 по умолчанию. Давайте смотреть, как всё это дело настраивается. Мы точно так же создадим список авторизации и перечислим в нём методы, которые будем пробовать. Список авторизации создаётся: aaa authorization, дальше указываем подсистему exec — это наша оболочка, командная строка — и здесь мы создадим список VTY_AUTH, назовём его

таким образом. Перечислим методы. Я предлагаю сначала тоже попробовать у RADIUS спросить, что же делать с этим пользователем. Если RADIUS не ответит, мы в локальной базе уже посмотрим, что у нас для этого пользователя приготовили. Приготовили мы для него 7 уровень привилегий. Говорим group radius — мы потом RADIUS настроим, и RADIUS нам будет отдавать — мы же не просто так всё это настраиваем. Но сейчас RADIUS молчит, и если не получился group radius метод авторизации, мы говорим local. Достаточно. Точно так же, как и со списками аутентификации, этот список сейчас никому не нужен, на него никто не обратит внимания. Поэтому нам точно так же надо сказать, что для авторизации использовать этот список.

Идём на линию и говорим: authorization exec — и говорим имя нашего списка. Всё, этого достаточно. Теперь я завершаю нашу конфигурацию, включаю debug авторизацию, и пробуем коннектиться. Вы за мной успеваете, надеюсь. Я думаю, что успеваете. Давайте я проговорю ещё раз: мы на самом деле просто — у нас уже всё настроено. Мы создали список авторизации с двумя методами: group radius и local, и на линии сказали использовать для авторизации этот список. Всё, коннектимся. Где telnet у меня? Telnet

— и говорим: admin, пароль cisco. В дебаге мы видим, что процесс авторизации у нас выбрал список методов, который называется VTY_AUTH, и обработал по локальной базе, и выдал ему 7 уровень привилегий, и что авторизация завершилась успешно. Теперь если мы посмотрим show privilege — мы находимся на седьмом уровне. Этого достаточно, чтобы пользователь, которому мы назначили уровень привилегий, оказался в своём уровне привилегий. Если посмотреть на команды — команды первого уровня плюс команда clock. У нас уже уровень работает, и я думаю, что он работает неплохо. Вот так у нас работает авторизация. Давайте

теперь за RADIUS попробуем взяться. Конечно, команды с 1 по 6 присутствуют, и те команды, которые мы ещё добавили, тоже присутствуют. Давайте, Кирилл, ваш вопрос. Дебаг я пока выключу, читаю ваши вопросы. Авторизация на exec VTY_AUTH — мы сначала создали список, а потом его на линии применили. Мы же на линии авторизуем, на линии VTY мы всё это используем. Если мы хотим авторизацию для консоли, то надо на консоли именно задать авторизацию. Но мы сейчас не с консоли, потому

что игры с консолью, вы понимаете, могут привести к тому, что у кого-то сейчас заблокируется доступ, придётся роутер перезагружать — это не нужно. Telnet для этого достаточно, чтобы понять вообще, как всё это работает. Со списками разобрались — правильно — авторизации и аутентификации. Теперь мы знаем, как их применять. Мы можем создать списки для административного доступа, точно такие же списки отдельные создать для доступа по PPP, например, почему нет. И даже когда — подождите, на CCNA сейчас настраивают serial-интерфейсы, правильно? Вы же настраивали serial-интерфейсы и аутентификацию по PPP? Было такое? Можно даже эту аутентификацию PPP тоже списком сделать. Могу врать, можно ли сделать списком. На serial-интерфейсах — нет.

На CCNP этого не было. Но раньше было, когда я учился на CCNA, это точно было. Надо Иннокентия спросить. Я современную CCNA, к стыду своему, плохо знаю, программу курса плохо знаю. Для пользователей список команд — это мы сейчас, Игорь, очень хороший вопрос. Как сделать, чтобы — а Иннокентий, сейчас serial-интерфейсы на CCNA есть? Вот хотел спросить. Игорь, сейчас я расскажу, как сделать именно так, потому что здесь в уровнях привилегий мы понимаем, что есть первый уровень привилегий, там и так в принципе команд достаточно. И Иннокентий — serial-

интерфейсы есть на CCNA и сейчас рассматриваются. Надо помнить, что в первом уровне привилегий команд много, и все последующие уровни будут всё равно его наследовать. Но мы сейчас ещё другой механизм рассмотрим. Давайте сначала попробуем RADIUS потыкаем, я почти уверен, что он у нас работает. А стоп, нет — мы сейчас не попробуем RADIUS, прошу прощения. RADIUS будем чуть позже настраивать, мы просто слайды ещё про него не посмотрели. Давайте тогда лабу мы сейчас сворачиваем, я переключаюсь на слайды и буду дальше вам рассказывать. Мы к RADIUS ещё вернёмся обязательно. Следующая наша тема — отвечаю на вопрос Игоря и всех других — как сделать так, чтобы уровни привилегий не наследовались, чтобы сделать не иерархичную

структуру, а параллельные уровни доступа, чтобы они не пересекались. Не как привилегии, которые всё-таки пересекаются. Для этого у нас есть следующий механизм, называется он RBAC — Role-Based Access — доступ к оболочке, основанный на ролях пользователей. Мы будем определять роли пользователей. Есть такая штука как представление — view, ещё называют «вьюха». Представления определяются для каждой роли независимо. Представление — это просто набор команд. Представления не организованы никак в иерархию, они совершенно независимы. Уровни доступа иерархичны, а эти совершенно независимы. Мы понимаем, что view — это когда вы попадаете

в командную оболочку, и представление — это ваш набор команд, ваше окружение. Больше у вас, кроме этого представления, ничего не будет. По умолчанию только одно представление — оно называется root. В нём есть все команды. По умолчанию оно защищено паролем enable, тем самым общим enable. Каждое представление тоже можно защитить своим паролем. Может быть создано максимум 15 разных представлений — это ограничение операционной системы. Я не проверял, больше 15 можно создать или нет. Допускаю, что в каких-то версиях может быть и больше, на какой-то платформе. Но я думаю, что 15 уровней доступа должно хватить даже самой крупной компании, потому что

сколько можно придумать ролей, уровней доступа для администраторов, которые обслуживают одно сетевое устройство. Да, Андрей, можно, конечно, мы этим будем тоже заниматься. Представление можно сопоставить с каждым пользователем либо с группой пользователей, почему нет, тоже не проблема. Но с группами всё-таки нужно в RADIUS работать, на внешнем AAA-сервере, либо в TACACS+, так как там это удобнее намного. Надо помнить, что эти view и RBAC с уровнями привилегий вообще ничего общего не имеют, совершенно ничего общего. Они никак не коррелируют. Забудьте. Иногда можно даже запутаться: бывает такое, что ты заходишь на устройство, тебе дали какое-то представление,

какую-то вьюху, ты там работаешь, потом набираешь enable, хочешь на какой-то другой уровень перебраться, а она говорит, что сейчас работает не в парадигме уровней — извини, мы работаем с представлениями. Я думаю, что мы не запутаемся. Как это всё дело настраивается — давайте проговорим сначала на слайде, а потом сразу попробуем в лабе. Наша задача — создать представление, защищённое паролем, для администратора, и администратору дать несколько команд: в этом случае configure terminal, interface и crypto. Этого достаточно. А потом мы с вами — здесь я не буду проговаривать команды, потому что это всё лучше показать в консоли. Мы создаём представление, потом обязательно нужно задать пароль, и дальше

говорим, какие команды мы включаем в это представление. Включить все команды — all, есть такое ключевое слово. Все команды, которые начинаются со слова show, включить. Команду configure terminal — обратите внимание на эту часть команд: мы говорим commands и в каком режиме эти команды разрешены — в режиме exec либо в режиме конфигурации. Мы говорим, к чему относятся команды, которые мы разрешаем. К сожалению, знак вопросика здесь не будет работать, и придётся их вспоминать по памяти либо по документации как-то составлять эти вьюхи. Их не так просто создавать, как кажется на первый взгляд — там просто помнить все команды, и вопросик не работает. Но сейчас разберёмся, мы такую простенькую создадим вьюху для нашего пользователя admin. Дальше: как

можно получить доступ к этому представлению? Два способа. Либо вручную — так же как мы перепрыгивали на уровень привилегий, можно вручную: enable view — и как мы назвали это представление — и запрыгнуть в это представление и получить те команды, которые мы там задали. Либо вручную, либо с помощью авторизации: мы можем в локальной базе пользователей сказать, что пользователю admin мы назначаем view admin и там пароль его. И потом процесс авторизации, когда будет отрабатывать, он посмотрит, что у этого пользователя такое представление назначено, и даст ему это представление. Давайте в лабу, нечего время тянуть. Давайте теперь под запись, я

чищу консоль. Как мы создаём view? Я ещё раз проговорю для тех, кто не успевает, будет полезно. Итак, командочки у нас: parser view, называем её большими буковками ADMIN, задаём пароль для этого — cisco_admin, я cisco_admin. И начинаем набивать команды, которые мы разрешаем. Сначала в пользовательском режиме: include configure terminal. Разрешим ему все команды show. Что мы ему разрешим конфигурировать? Commands — разрешим ему конфигурировать всё, что касается интерфейсов, и разрешим ему конфигурировать всё, что

касается криптографии. Всё, этого достаточно. Если посмотреть, что мы наконфигурировали, у нас получится вот такая картина. И теперь давайте посмотрим, каким образом мы с вами назначим эту view для пользователя: username admin view ADMIN и secret ему напишем — секретом напишем его пароль. А, у меня там был password — пусть будет password, password cisco. Вот таким образом. Теперь давайте смотреть, как мы можем попасть в эту вьюху, как мы можем её запустить. Мы можем просто сказать enable view ADMIN, нас просят пароль на это

представление, и мы окажемся в этом представлении. Смотрите, чтобы посмотреть, где я нахожусь — задать вопрос, где я нахожусь — есть команда show parser view. Так же как с уровнем привилегий надо спросить show privilege. А кстати, если сейчас спросить, какой у меня уровень привилегий, то нам скажут, что вы вообще находитесь в view, в представлении, и привилегии с этим ничего общего не имеют. У вас сейчас никакого уровня привилегий нет. Как интересно! Мы спросили show privilege — говорят: нет, тут привилегии не работают, это совсем другие вещи. Теперь если мы наберём configure terminal, то здесь нам разрешат всего лишь crypto либо interface. Всё, этот пользователь — эта view ограничена только этими

командами. Но команды show тоже — опять же, если набрать в режиме exec: команды у нас тут либо конфигурировать — мы посмотрели, что мы можем только interface и crypto конфигурировать — либо show. Всё, до свидания. Так что можно только так. Можно сказать enable view root — это верхнее представление, и тогда мы попадём, и тогда у нас будут все команды, и мы станем как бы на пятнадцатом уровне привилегий. Но опять же, мы сейчас не в уровне привилегий 15, а мы в представлении root — верхнем представлении, в котором можно всё. Так что это намного интереснее. А, no нету! Да, кстати, это интересный момент, потому что я про него забыл.

Да, если мы хотим, чтобы ещё что-то — во вьюхах, в представлениях нужно прямо чётко все команды определять, забивать то, что вы разрешаете. По умолчанию root есть, конечно, так же как и 15 уровень привилегий тоже есть. Чтобы отсюда выйти — смотрите, да, вы переключились совершенно в другой контекст, вы во вьюхах работаете. В смысле — что, настраивать? View root? Нет. А пароль на view — смотрите, пароль на представление root является парольный enable. Я же не создавал здесь view, не говорил parser view root и секрет такой-то. На эту вьюху у меня в системе был пароль enable — этого достаточно. Он работает так же, как чтобы перейти на 15

уровень, и работает для того, чтобы перейти в view root — вот в это представление. Здесь мы сейчас находимся именно в парадигме представлений. С привилегиями, с уровнями ничего общего мы не имеем. Если мы хотим обратно вернуться к уровням привилегий — да, он берёт пароль от enable secret. Всё правильно, Олег. Парольный enable, enable secret или enable password, если задан, он и работает. Если мы хотим вернуться к уровню привилегий — сейчас просто enable, enable 15 — то надо просто зайти в какой-то уровень. И теперь сейчас, если мы посмотрим, то мы окажемся в уровне привилегий. Понимаете? Вот сейчас мы работаем в уровне привилегий. Я набрал

enable 15 — самый высокий уровень привилегий, и если я сейчас скажу: покажи-ка мне, в каком я представлении — show parser view — он скажет: извините, у вас не активно никакое представление. Какие вьюхи? Вы сейчас в контексте привилегий находитесь. Здесь мозг сломать довольно несложно, потому что сначала работаешь в одном, потом хочешь enable какой-то набрать, ничего не получается. У Олега тоже путается — но нет, здесь просто надо принять как факт, что либо мы работаем с системой, где есть уровни привилегий, либо мы работаем с системой представлений. Либо так, либо так — они друг с другом не соотносятся. Вот у нас так работает система представлений. Давайте посмотрим одну интересную штуку. Зайдём по telnet — у нас же авторизация настроена, правильно? Авторизация работает.

Зайдём сами на себя. Telnet — я ещё новые адреса не выучил — 10.10.1.1. Admin, cisco. Где мы оказались? Мы оказались — show parser view — оказались в представлении ADMIN. Правильно, мы же для пользователя задали, что этому пользователю нужно предоставить именно вьюху ADMIN. Всё, нам при логине выдали именно это. Мы по telnet на наше устройство зашли и получили эту вьюху. Что интересно — давайте я вам покажу: show running-config username. Смотрите, что интересно: у пользователя admin есть уровень

привилегий 7, и в то же время ему назначена вьюха с названием ADMIN. Когда есть и то, и другое, то будет назначена вьюха. Мы сначала ему уровень привилегий назначили, и при логине он получал 7 уровень привилегий. Потом ему назначили представление ADMIN, и он получил представление ADMIN. Когда мы назначили и то, и другое для пользователя, отработает именно система ролей — ему дадут эту вьюху. Имейте это в виду. Он логинится, процесс авторизации работает и думает: какие права этому человеку дать — либо 7 уровень привилегий, либо вьюху с именем ADMIN? В этом случае процесс авторизации ему даст именно вьюху ADMIN.

Это то, что касается этого механизма. С этим мы разобрались. Я ещё раз напомню, что когда про уровни привилегий говорили, я сразу сказал, что этот механизм уже ушёл в прошлое и он нежелателен. Гораздо эффективнее создавать именно представления для конкретных групп пользователей. У нас есть такие администраторы, есть другие администраторы. Потому что в крупных системах бывают администраторы из техподдержки, которым кроме show посмотреть ничего и нельзя давать, либо люди, которые занимаются только VPN, либо суперадмины, которым всё нужно. Лучше вот таким образом делать — параллельные привилегии, это очень удобно. Но давайте теперь про RADIUS пару слов скажем. Мы

здесь тоже RADIUS глубоко копать не будем, но столько, сколько нужно, и попробуем, как он у нас работает. Смотрите, Кирилл очень правильный вопрос задал: можно ли одному пользователю давать несколько ролей? Нет, конечно, потому что как понять, какую роль ему дать в какой момент? Это же не такая система, которая обладает человеческим интеллектом. Можно хитрее сделать, в принципе, я подозреваю. Но процесс авторизации ломится на RADIUS-сервер или в локальную базу, и там у пользователя несколько ролей написано — что ему давать? Процесс авторизации же не поймёт, что ему сейчас в данный момент приспичило быть — сотрудником техподдержки или администратором. Если одна роль, что — право VPN? Да, можно, но это —

дальше я просто углубляться не хочу — можно эти вьюхи одну в другую вкладывать, вы про это говорите. Здесь надо быть просто осторожным, можно, но обычно делают по одной. Я видел в одной организации в прошлом году — там на вьюхи всё было построено. И там — крупная организация — по всему их четыре штуки было, четыре таких уровня привилегий. Потому что один уровень привилегий был вообще для автоматизированной системы управления конфигурациями. Для неё тоже можно уровень создать — не обязательно для живого

человека эти уровни создавать. У вас есть какой-то скрипт, который бегает по коммутаторам и что-то там прописывает — он же логинится на железо. Ему тоже можно уровень привилегий, чтобы застраховаться от того, что этот скрипт может неправильно что-то — здесь нельзя говорить именно про людей, это может быть и не обязательно человек, который логинится на железку. Всё, продолжаем. Сейчас про RADIUS будем говорить. Про RADIUS мы поговорили как протокол, про внешние AAA-серверы — серверы, лучше говорить. Мы обсудили эти протоколы, пусть поверхностно, но мы понимаем уже, зачем они нужны, что это такое, как это работает — мы тоже понимаем. Здесь нарисована такая большая схема. Я хочу просто проговорить, чтобы у нас в голове прямо вообще отложилось всё —

как работает ещё раз аутентификация с помощью внешнего сервера. Сначала, я буду указочкой водить: клиент — здесь имеется в виду клиент, это удалённый какой-то клиент, который подключается к нашему роутеру, например по VPN. Мы говорили, что доступ может быть сетевой и административный. В этом случае нарисован сетевой доступ. Человек подключается по VPN, его компьютер-клиент устанавливает соединение. Роутер запрашивает у клиента имя и пароль. Клиент ему говорит имя и пароль. Роутер ему говорит: так, подожди, сейчас я пойду и спрошу. Когда он принял пару логин-пароль, вот только тогда он уже пойдёт на внешний RADIUS-сервер и запросит — передаст ему имя пользователя и пароль, вот эту пару. В свою очередь RADIUS-сервер может спросить, например, в Active Directory,

или в любом хранилище — в LDAP, где угодно — может обратиться ещё к внешнему хранилищу и спросить: есть такой Василий с таким-то паролем или Пётр с таким-то паролем? Внешнее хранилище скажет: да, всё окей. И RADIUS-сервер передаст нашему роутеру, что да, всё нормально, этого клиента можно пускать в нашу сеть, давать ему доступ по VPN. И только тогда роутер отдаст ему результаты аутентификации. В случае RADIUS он с этими результатами аутентификации ещё отдаст какие-то атрибуты, неважно какие, которые RADIUS ему сообщил. И собственно всё нормально — либо пустят Василия или Петра, либо не пустят в нашу сеть. Вот так в общих чертах ещё раз проговорили. Как это всё

дело настраивается — мы с вами поговорили о том, что у нас есть такое понятие, как RADIUS-группа. Здесь метод авторизации называется group radius, соответственно, он уже подразумевает, что мы работаем не с одним RADIUS-сервером, а с группой серверов. Эту группу можно объединить в какую-то именованную группу, назначить ей имя, либо просто оставить — серверы и так будут работать. Можно и так сделать, хотя я боюсь ошибиться, но, по-моему, в самых-самых последних версиях, по-моему, надо указывать группу RADIUS. Хотя, может быть, ещё нет — на какой-то платформе где-то это проскакивало. В смысле default — нет, имя default нет. Она просто — создали два RADIUS-сервера, они уже будут в группе RADIUS.

Как настраивается. RADIUS-сервер не принимает от кого попало подключения. И если прийти на RADIUS-сервер и рассказать: вот, RADIUS-сервер, вот у меня есть клиент, он пытается подключиться, вот его имя и пароль — RADIUS-сервер будет молчать как партизан, потому что скажет: ну и что? Не скажу, правильный пароль или нет. Понимаете, с точки зрения безопасности это очень правильно, потому что любой человек может подключиться в нашу сеть и начать брутфорсить наш RADIUS-сервер — спрашивать у него: а этот логин и пароль правильный? А может быть, вот такой попробовать? И так далее. Можно использовать RADIUS-сервер как вектор атаки, просто чтобы выяснить пароль. Это же замечательно, если ломиться, например, просто на компьютер в офисе, который в домене Active Directory, — там после нескольких

попыток он заблокируется или будет увеличивать время между попытками. Как правило, RADIUS-сервер настроен таким образом, что он позволяет больше попыток аутентификации, и RADIUS-сервер можно таким образом попробовать — намного эффективнее будет подбор пароля через RADIUS- сервер. Поэтому RADIUS-сервер не позволяет кому угодно подключаться к себе. Хотя можно и так настроить, но я уже объяснил, почему так делать не нужно. Поэтому на RADIUS-сервере тоже прописывается, что принимать запросы только от роутера номер один, роутера номер два, роутера номер три, и для каждого роутера ещё пароль прописать. Поэтому когда мы настраиваем RADIUS-сервер, нам надо говорить RADIUS-серверу, конечно же, адрес сервера — вот такой IP v4. Неплохо бы после адреса ещё указать порты. Мы с вами про порты говорили: 1812, 1813 — такие

стандартные. Везде — я сейчас попробую его настроить без портов, вы за мной потом повторите. Просто, если честно, я не помню, в нашей текущей версии IOS какие порты подставятся — раньше подставлялись цисковские, старые. И вот этот key — это пароль для RADIUS-сервера. Имеется в виду, на RADIUS-сервере, как правило, клиенты — клиент это сейчас наш роутер — прописываются по IP-адресу. RADIUS-сервер знает, что вот с этого IP с таким паролем пришёл — этого достаточно. Не надо username для RADIUS-сервера, там просто по IP-адресу. А дальше можно в принципе объединить серверы по группам, в именованную группу. Как настраивается RADIUS- аутентификация — мы с вами настраивали аутентификацию, но здесь list, список методов дефолтный. Но мы свой уже

определили. Либо group — просто сказать group radius, либо group с именем группы можно сказать. Можно сначала — понимаете, можно создать одну группу серверов, можно ещё такую. Вдруг у вас там 50 RADIUS-серверов — кто знает, может, у вас такая развесистая топология, что не хватает даже трёх серверов или пяти. Можно их объединить по группам, а потом здесь перебирать: сначала одну группу попробовать подключиться, если там 10 серверов в группе — сразу сдохли, я правда не представляю, что это за сеть — потом к другой группе обратиться и потом попробовать локальную базу, например. Дальше, когда мы всё настроили, есть прекрасная команда, которую нужно знать — просто нужно это знать: RADIUS-сервер можно попробовать протестировать. Обычно чтобы — да, в принципе,

накиньте: правда, что сначала в своём филиале, если тут отказал, потом в центральном филиале попробовать. не в одной сети, а потом куда-то в центр обратиться. Смысл в этом есть, окей, дальше. Тестирование — это штука полезная. Вообще, на самом деле, в операционной системе IOS у вас, к сожалению, не так много тестовых команд, чтобы взять и попробовать, как она работает — сначала безопасно, а потом уже применять. Есть тестовая команда, чтобы проверить: задать логин, задать пароль и потом проверить, как отработает RADIUS-сервер. Так, теперь здесь у нас рассказано про сервер TACACS. У нас

сервера TACACS в топологии нет, на стенде нет, просто давайте я расскажу, и в записи останется, чтобы отложилось в голове. На самом деле отличий от настроек RADIUS не так много. Точно так же настраивается сервер, точно так же настраивается адрес сервера, также настраивается пароль, с которым мы будем подключаться к TACACS+ серверу. Аутентификация настраивается точно так же. Авторизация — давайте её разобьём вот так. Авторизация обычная — вот она, так же как у RADIUS: первоначальный вход в систему и сразу получить какие-то разрешения, какие-то привилегии — она настраивается точно так же, просто не group RADIUS, мы говорим group TACACS. Если не получилось — то local база. А самое вкусное, что есть в TACACS,

почему его используют именно для административного доступа — это авторизация по командам. Мы говорим: авторизация команд 15 уровня — надо сначала обратиться в TACACS. И тогда человек, который вводит команды, у него будет каждая командочка проверяться. Конечно, это тормозит работу в некоторых случаях, но это тоже полезно. Пару слов про аккаунтинг. Аккаунтинг — штука такая, она на нашем курсе очень кратко рассматривается, в двух строчках. На CCNP это просто очень долго разбирается, если хочется прям совсем всё это разобрать — долго приходится вникать, там много всяких приколов. Но по большей части хватает

только того, чтобы сказать, куда отправлять данные аккаунтинга, и система без всякой тонкой настройки просто скажет, что аккаунтинг — вот то, что натворится. Смотрите, так, давайте ещё раз расскажу про аккаунтинг. Смотрите, аккаунтинг — мы можем записывать разные данные. Мы сейчас говорим про административный доступ, не про сетевой пользовательский доступ — там понятно: подключился, отключился пользователь к VPN. А про административный доступ — слово exec, так же как в случае с авторизацией, означает вход в оболочку, запуск командной строки, командного интерпретатора. Это надо не путать. Exec здесь у нас будет — при нашем логине отправляться какая-то информация на TACACS-сервер.

Ключевые слова start-stop — это когда мы в начале и в конце действия какую-то информацию отправляем. То есть начался процесс, закончился процесс. Можно сказать stop-only — это отмечать только конец процесса. И также мы можем отправлять на TACACS-сервер информацию по командам — details введённой команды, и также отправлять всё, что мы вводили, на TACACS-сервер. TACACS-сервер будет у себя всё собирать — как логи, такое журналирование своеобразное. Давайте консольки запускать и попробуем всё дело поднять, настроить. Давайте делаем такую маленькую лабу и пробуем настроить RADIUS-сервер. Для начала неплохо бы проверить, вообще RADIUS-сервер живой у нас в сети или

неживой — хотя бы просто попинговать. Вроде как живой, отзывается. И давайте настраивать. Смотрите, есть два способа настройки. Вы знаете, что операционная система IOS она постоянно развивается, но дело в том, что иногда тянутся старые настройки. Старый способ настройки — в 12 версии настраивалось всё в одну строчку, не так, как я вам на слайде показала, как сейчас будем настраивать. Можно было настроить одну строчку: radius-server, и всю ерунду прописать в одной строке, но читать неудобно и настраивать не очень удобно. Поэтому мы настроим по-новому. Настройка выглядит так: radius server, называем наш сервер srv1, пусть будет, и дальше уже выполняем все остальные настройки. Здесь так намного проще, в одну строку запутаемся обязательно.

Пишем сначала адрес нашего RADIUS-сервера: ipv4 10.101.200. Порты я не буду указывать — вот они: порт аутентификации и порт авторизации. Здесь смотрите: дефолтный порт 1645–1646, как я вам и говорил — это на самом деле цисковские порты. Но современные все продукты — и в том же Windows, и RADIUS, и FreeRADIUS — все они уже используют 1812, 1813. Поэтому здесь будьте внимательны: если просто сказать адрес RADIUS-сервера, то потом мы до него не достучимся, не будет работать. Так что мы здесь пишем порт аутентификации 1812, порт для аккаунтинга 1813. Всё, с адресами разобрались. Теперь по поводу ключа-пароля: я создал на RADIUS-сервере для

каждого из наших роутеров свой пароль. Я надеюсь, что всё это сработает, если RADIUS-сервер живой. Пароль будет выглядеть так: password через ноль и номер комплекта, через собачку и через ноль. Я думаю, что вы разберётесь. Я в чате кину пароль и за ним номер комплекта. У меня будет key password1. Давайте настраивайте. Теперь сразу полезные команды. Одна командочка: у нас есть команда show radius server — сервер-группы — и можно посмотреть, какие у нас сервера сконфигурированы, тип сервера, его адрес, его порты и сколько было попыток аутентификации, авторизации.

Когда у нас будет первое подключение к этому серверу, когда мы к нему первый раз обратимся, там будет больше информации, потом посмотрим. RADIUS-сервер в принципе настроен. Теперь можно его попробовать потестировать: test aaa group radius. Здесь можно указать конкретный какой-то сервер, можно указать уже просто имя пользователя и пароль. На самом деле мы проговорили, что если несколько серверов указано, то будет группа, и он будет тестировать первый попавшийся. К сожалению, алгоритм выбора сервера из группы мне неизвестен, я просто плохо копал, я думаю, что есть какой-то совершенно чёткий алгоритм. Так, теперь смотрите: у нас у каждого будут свои пользователи и свои пароли. Чтобы ещё больше вас

запутать, я сделал именно так. У нас будет пользователь ins и номер комплекта, и соответственно пароль у него будет такой же с номером комплекта. То есть у меня будет пользователь ins1 с паролем password1, у вас будет ins2 с паролем password2, ins3 с паролем password3. Так же, как и пароль именно для RADIUS-сервера — key, ключ — тоже заканчивается номером комплекта. И дальше нам в тестовом задании необходимо указать здесь ещё один атрибут: каким образом мы будем опрашивать наш RADIUS-сервер. Там есть legacy либо new-code. Это просто способ сообщений. Я советую legacy — он просто будет отвечать: аутентификация прошла или не прошла. New-code он ещё

будет атрибуты отдавать. Попробуем legacy. И, наверное, придётся включить дебаг, потому что... О, с первого раза наш RADIUS-сервер ответил! Смотрите, результат тестовой команды: мы пробуем подключиться к группе серверов, и он сказал, что пользователь был успешно аутентифицирован. В принципе классно, то, чего мы добивались — пользователь ins1 успешно аутентифицировался. А если по-новому спросить RADIUS-сервер, то он отдаст ещё некоторые атрибуты. Сейчас давайте с дебагом ещё посмотрим. Я боюсь, что атрибуты сейчас... нет, потому что я всё удалил, я хотел вам в процессе... Почему он не...

Но я там для пользователей задал level 7, всё правильно, user-атрибуты показывает. У меня почему-то RADIUS-сервер не всегда доступен. Недоступен. ins1, password1 — видите, он говорит, что is not responding. Почему-то... Вот, теперь он пропал. Смотрите, если спрашивать по-новому, то он будет говорить, что пользователь аутентифицирован и отдавать атрибуты. Я задал на RADIUS-сервере — на самом деле атрибутов не так много, но самое главное, что мы видим, как они

работают. Я задал для этих пользователей, которых мы сейчас тестируем, чтобы им отдавали уровень привилегий 7. Мы с вами 7 уровень настроили, и теперь, если пользователь зайдёт — вот этот пользователь ins с паролем password1 — давайте попробуем telnet сами на себя и сказать: пользователь ins1 с паролем password1. Он зашёл и получил 7 уровень привилегий. Точно так же через RADIUS можно отдавать не только уровни привилегий, но и можно отдавать view — те же самые, про которые мы говорили. Давайте, чтобы не забыть, я сейчас покажу, какие атрибуты — атрибутов не так много

для RADIUS-сервера, которые можно сразу отдать именно при административном доступе. При доступе сетевом по PPP или VPN каком-нибудь — там можно отдавать довольно много атрибутов. При административном доступе — уровень привилегий и view можно отдать с RADIUS-сервера. У меня, к сожалению, нет подключения к RADIUS-серверу. Иннокентий, ты с нами сейчас? Иннокентий, а у тебя есть доступ к RADIUS? С консоли тоже так себе... Ладно, тогда не будем заморачиваться. Главное — просто посмотрели, что всё это работает, атрибуты отдаются. Если бы был нормальный доступ, мы бы сейчас view отдали. Сейчас одна секунда, я попробую, может он ожил как-нибудь, я ещё раз попробую к нему подключиться. Я сейчас попробую, так, в записи

я продолжу. Давайте дебаг посмотрим. Так, где мы... Всё нормально. У нас есть debug aaa — все дебаги включать не будем, можно и аутентификацию посмотреть, авторизацию и RADIUS. Но сейчас будет 10 экранов дебагов, поэтому посмотрим просто debug radius — debug radius аутентификацию, просто хотя бы на примере. Авторизацию не надо, посмотрим аутентификацию. Всё, ещё раз ломимся. Можно даже в тесте посмотреть — сделать тест и посмотреть, как у нас вообще работает всё это дело. Смотрите, изучать дебаг

всегда полезно и весело. Мы подключились, попробовали запросить у RADIUS-сервера аутентификацию для пользователя ins с его паролем. Так, нам сразу — самое главное. Смотрите, всё, что написано, всё, что называется NAS — это Network Access Server. Как Иннокентий правильно дополнил меня — это наш клиент, он ещё называется NAS. Его IP — 0.0.0.0, потому что мы ему не передаём свой IP, он сам уже знает, с какого IP-адреса пошёл, если я ничего не ошибаюсь. Дальше, что ещё интересного здесь: дальше NAS — это мы. Это вот наш роутер, который клиентом является для RADIUS. Дальше мы

выбираем лучший сервер, с какого адреса к нему обращаться, что мы будем обращаться к серверу с такого-то адреса. И сообщение Access-Request — самое главное — запрос доступа посылаем на адрес такой-то, на 10.1.200, на порт 1812. Мы говорили про порты — вот порт 1812 — это всё по UDP, по UDP и работает. Он используется именно для аутентификации-авторизации. И дальше передаём ему некоторые данные: передаём пароль — понятно, что он зашифрованным поедет — передаём username и потом передаём свой адрес. Всё правильно: адрес мы сначала не знаем, потом выбрали, передаём дальше и отправили RADIUS packet. Пароль не зашифрованный

передаётся! Точно, короче, дело в том, смотрите, на этой штуке обжигались многие. Cisco используют протокол PAP. Вспомним, был протокол PAP и CHAP. На экзамене, правильно, в протоколе PAP пароль не шифруется. Да. Дело в том, что Cisco не умеет ничего, кроме PAP. И очень часто те, кто настраивает RADIUS на том же Windows — Windows по умолчанию PAP отключён — и потом начинается долгий траблшутинг, почему же RADIUS не работает. Вот, Михаил сейчас будет писать свою историю, я точно знаю, что у него такая история тоже была. И у меня в своё время она была. Мы на этом обжигались. Cisco не умеет ничего, кроме PAP. Поэтому вот, NPS, Cisco — да, только через PAP. Это именно виндовый сервер —

только через PAP, в смысле для подсистемы логина. Так, нет, а в LDAP, в Active Directory — ты что проверяешь? У Active Directory можно же спросить просто логин и пароль, не обязательно RADIUS-сервер. В свою очередь, RADIUS-сервер — смотрите, RADIUS-сервер — это же не Active Directory. RADIUS-сервер в свою очередь также посылает запрос на аутентификацию в Active Directory, она ему отвечает, и RADIUS-сервер нигде пароль не хранит. А тогда он едет текстом, всё правильно, просто здесь в дебаге не отображается. Конечно, слайды по 802.1X будут — пару мы так поверхностно коснёмся. Там уже

всё нормально. Но, если честно, с этим RADIUS-сервером, с виндовым, я 802.1X не пробовал. Не было такой задачи у меня — с виндовым сервером 802.1X настраивать. Ладно, дальше дебаг почитаем. Такой RADIUS в бою лучше не настраивать? Но, Олег, смотрите, почему не настраивать — если у вас же не по интернету едет сообщение RADIUS-протокола, если вы это на вашей внутренней сети — ничего в этом страшного нет. Если совсем боитесь, что у вас в пределах одной коммутационной стойки или одной серверной ходят

не зашифрованные данные — возьмите да и в IPsec заверните, и всё. Иннокентий тоже подтверждает — можно. Мы про IPsec ещё дальше с вами поговорим. Почему нет? Можно взять и пошифровать всё это, передавать вообще — весь трафик шифровать, просто тупо шифровать весь трафик от RADIUS-сервера до нашего маршрутизатора, никаких проблем. Так, и дальше собственно процесс аутентификации заканчивается тем, что RADIUS-сервер просто будет рассказывать о том, что сообщение есть Access-Accept. Просто запомните, что есть Access-Request и Access-Accept — это помогает при дальнейшем траблшутинге. Мы получили Access-Accept от нашего сервера с такого-то порта. И дальше передаются атрибуты. Вот,

называется AV pair — это Cisco-атрибуты. Дело в том, что в Windows, когда настраивать RADIUS-сервер, там приходится вот эти атрибуты помнить в голове или где-то откуда-то брать. Там нет никаких галочек, где можно поставить, какие атрибуты передавались — конечно, не очень удобно. В принципе, Windows RADIUS-сервер удобен тем, что не нужно ставить никакие дополнительные решения, если это не какая-то крупная инфраструктура, а если это просто одно предприятие, где есть домен, нормальный Active Directory, где происходит вся аутентификация, авторизация — то можно на контроллере домена просто RADIUS-сервер поднять, и контроллер домена будет

заниматься такой работой. Если страшно, что ходят незашифрованные пароли — это вот, в пределах сети пользователей — можно IPsec потом пошифровать. Всё, конечно, здорово, когда есть выделенный RADIUS-сервер, но в наших условиях недорого получается — он вообще же бесплатный. На контроллере домена просто ещё одну галочку поставил, ещё одну роль поднял и настроил. Он настраивается — я настроил сегодня перед лабой минут за 15, прописал ещё 10 пользователей, прописал ещё 10 роутеров — он очень быстро настраивается. А Cisco ISE — действительно очень дорогое решение. Она классная, но это такой дорогой комбайн — слишком. Если хочется ещё бесплатное решение — есть FreeRADIUS, который на UNIX-системах замечательно прекрасно работает, он бесплатен. Он не так прост в настройке, с другой стороны, если понимать, что делаешь,

то тоже можно разобраться. Между RADIUS-сервером и LDAP — так, Олег, а это уж как — я не могу сказать, всё зависит от реализации RADIUS-сервера и LDAP. В случае Windows там всё, конечно, шифровано — трафик передаётся, там же подсистемы между собой общаются. Если на разных серверах — я подозреваю, что тоже шифрованные пароли передаются. Так что давайте тогда.