ASA. Статья 4. Удаленное управление

Удаленное управление

Понятно, что при нынешнем развитии сетей передачи данных было бы неразумно не внедрять удаленное управление межсетевыми экранами. Поэтому ASA, как и большинство устройств cisco, предоставляет несколько способов удаленного управления.

Самое простое и небезопасное – telnet. Чтобы предоставить доступ на ASA по телнету необходимо явно указать, с каких хостов и сетей и на каком интерфейсе разрешен доступ, а также необходимо задать пароль на телнет командой passwd:

telnet 192.168.1.128 255.255.255.128 inside
telnet 192.168.1.254 255.255.255.255 inside
passwd {пароль}

В целях безопасности работа по телнету на самом небезопасном (с наименьшим уровнем безопасности в рамках данной ASA) интерфейсе заблокирована и обеспечить работу на этом интерфейсе по телнету можно только в том случае, если он приходит через IPSec туннель.

Более безопасный доступ к командной строке обеспечивается протоколом ssh. Однако, для обеспечения доступа по ssh кроме явного указания того, с каких хостов можно заходить для управления, необходимо также задать RSA ключи, необходимые для шифрования данных о пользователе. По умолчанию для подключения по ssh используется пользователь pix и пароль, задаваемый командой passwd (пароль на telnet).

! Задаем имя домена
domain name {имя}
!
! Желательно задать недефолтовое имя хоста
hostname {имя}
!
! После этого можно сгенерировать ключи
crypto key generate rsa
!
! Разрешаем ssh
ssh 192.168.1.128 255.255.255.128 inside
ssh 1.2.3.4 255.255.255.255 outside
passwd {пароль}

Как правило, на ASA начиная с версии 7.2 имя домена уже задано (domain.invalid) и дефолтные ключи сгенерированы, однако как минимум это надо проверить

show crypto key mypubkey rsa

Наличие хотя бы каких то ключей RSA уже позволяет работать по ssh. Но можно дополнительно создать и недефолтовые ключевые пары. Для этого надо указать явно имя ключевой пары

crypto key generate rsa label {имя пары}

Чтобы удалить ключевую пару (или все пары) используется команда

crypto key zeroize rsa [label {имя пары}]

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

copy running-config startup-config
write memory

или короткий вариант последней команды

wr

Также ASA предоставляет крайне популярный метод настройки с использованием веб-броузера. Этот метод называется ASDM (Adaptive Security Device Manager). Для доступа используется безопасный протокол https. Обеспечение доступа настраивается очень похоже на настройку ssh: необходимо выработать или убедиться в наличии дефолтовых RSA ключей и указать, откуда можно подключаться.

domain name {имя}
hostname {имя}
crypto key generate rsa
! Включаем сам https сервер, по умолчанию часто включен. При включении
! генерирует самоподписанный сертификат.
http server enable
! Разрешаем https
http 192.168.1.128 255.255.255.128 inside
http 1.2.3.4 255.255.255.255 outside

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

enable password {пароль}

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

Надо проверить, что во флеше ASA лежит файл ASDM, соответствующий используемой ОС.

dir flash:
show flash

При работе с ASDM используется java и верно следующее: если вы используете ОС версии 7.Х, то ASDM нужен версии 5.Х и java 1.5. Если же используется ОС 8.Х, то ASDM нужен версии 6.Х и java версии 1.6.  К чести разработчиков и радости настройщиков, ASDM версии 6 работает не в пример лучше и быстрее версии 5.Х. Чья тут заслуга: java или cisco или обоих – не знаю.

Возникает резонный вопрос: а если хочется использовать не дефолтовые правила доступа, а явно указывать, откуда брать пользователя? Для этого используются команды

aaa authentication telnet console {имя AAA сервера} [LOCAL]
aaa authentication ssh console {имя AAA сервера} [LOCAL]
aaa authentication http console {имя AAA сервера} [LOCAL]

Если используется только локальная база данных пользователей, то в правиле аутентификации можно указывать только LOCAL (проверьте, что хотя бы один пользователь создан, иначе можно себе заблокировать доступ), а если требуется использовать внешние базы, доступные по протоколам TACACS+, RADIUS или LDAP, то такие сервера надо предварительно настроить

aaa-server {имя AAA сервера} protocol {tacacs|radius|ldap}
aaa-server {имя AAA сервера} ({interface}) host {ip}
key {ключ}
! и другие команды, специфичные для данного типа сервера

Локальная база пользователей задается командой

user {пользователь} password {пароль} [privilege #]

Доступ по ASDM возможен только от имени пользователя с уровнем привилегий 15 (максимальный, означает, что пользователю можно все настраивать)

Также локальным пользователям можно задать ряд атрибутов, используя команду

user {пользователь} attributes
! различные атрибуты пользователя

Завершая эту часть приведу кусочек конфига. В нем настроено 2 интерфейса (в данном случае это gigabitethernet 0/0 и 0/1, однако на разных платформах это могут быть и другие физические интерфейсы), inside и outside, дефолтный маршрут, разрешен удаленный доступ по ssh и https ото всюду, при этом аутентификация использует локальную базу данных пользователей.

hostname MyAsa
!
domain name anticisco.ru
!
interface g0/0
nameif outside
security-level 0
ip address 1.1.1.2 255.255.255.252
no shut
!
int g0/1
nameif inside
security-level 100
ip address 10.1.1.1 255.255.255.0
no shut
!
! на ASA запись 0.0.0.0 можно сократить до 0
!
route outside 0 0 1.1.1.1
!
username admin password cisco privilege 15
!
ssh 0 0 inside
ssh 0 0 outside
!
http 0 0 inside
http 0 0 outside
!
aaa authentication ssh console LOCAL
aaa authentication http console LOCAL

Используя такие настройки вы разрешите пакетам ходить из непосредственно присоединенной сети за интерфейсом inside наружу. Снаружи будут приходить только ответы по сессиям, открытым изнутри, т.к. напомню по умолчанию трафик идущий «внутрь» весь запрещен. Как его разрешить поговорим в следующей части.

Источник: anticisco.ru/blogs/2010/02/asa-статья-4-удаленное-управление/

ASA. Статья 3. Маршрутизация

Маршрутизация

Ну куда же без неё! Как у любого маршрутизатора (ASA тоже им является, т.к. использует таблицу маршрутизации для передачи пакетов) сети, настроенные на интерфейсах, автоматически попадают в таблицу маршрутизации с пометкой «Присоединенные» (connected), правда при условии, что сам интерфейс находится в состоянии up. Маршрутизация пакетов между этими сетями производится автоматически.

Те сети, которые ASA сама не знает, надо описать. Это можно сделать вручную, используя команду

route {interface} {network} {mask} {next-hop} [{administrative distance}]

Указывается тот интерфейс, за которым надо искать next-hop, т.к. ASA сама не делает такого поиска (в отличие от обычного маршрутизатора cisco).  Напоминаю, что в таблицу маршрутизации попадает только один маршрут в сеть назначения, в отличие от классическим маршрутизаторов, где может использоваться до 16 параллельных путей через разные интерфейсы.
Если же есть несколько маршрутов в одну ту же сеть через один и тот же интерфейс (максимум — три маршрута), то выбор адреса следующей пересылки происходит путем вычисления хэша адресов источника и назначения пакета.

Примечание: про избыточные маршруты написано на сайте у cisco. Маршруты действительно записываются, но логику выбора next-hop пока определить не удалось. Также не удалось заставить стабильно использовать все избыточные маршруты. Ведется исследование.

Маршрут по умолчанию задается таким же образом

route {interface} 0.0.0.0 0.0.0.0 {next-hop}

Если ASA не имеет записи в таблице маршрутизации о сети назначения пакета, она пакет отбрасывает.

Если возникает задача сделать запасной статический маршрут, который будет работать только при пропадании основного, то это решается указанием так называемой Административной дистанции маршрута. Это такое число от 0 до 255, которое указывает, насколько хорош метод выбора маршрута. Например, статическим маршрутам по умолчанию сопоставлена AD 1, EIGRP – 90, OSPF – 110, RIP – 120. Можно явно указать AD для запасного маршрута больше, чем AD основного. Например:

route outside 0.0.0.0 0.0.0.0 {next-hop} 1
route backup 0.0.0.0 0.0.0.0 {next-hop_backup} 210

Но в  этой ситуации есть один важный вопрос: как заставить «пропасть» основной маршрут? Если физически упал интерфейс все очевидно – само получится, а если интерфейс поднят, а провайдер погиб? Это очень распространенная ситуация, учитывая , что на ASA сплошной ethernet, который физически падает крайне редко.

Для решения этой задачки используется технология SLA. Она весьма развита на классических маршрутизаторах, а на ASA с версии 7.2 внедрили только самый простой механизм: доступность некоторого хоста по протоколу icmp. Для этого создается такая «пинговалка» (sla monitor)

sla monitor {#}
type echo protocol ipIcmpEcho {ip адрес} interface {интерфейс}

Далее, её необходимо запустить, указав время начала (есть возможность запустить «сейчас») и окончания работы (можно задать работу до бесконечности)

sla monitor schedule {#} start now life forever

Но и это ещё не все. Надо создать «переключатель» (track) который будет отслеживать состояние «пинговалки».

track {track #} rtr {sla #} reachability

Не спрашивайте, почему привязка пинговалки производится ключевым словом rtr – это ошметки несогласованности настроек на маршрутизаторах cisco. К слову, на самих маршрутизаторах такое несоответствие уже починили, а вот на ASA ещё нет.

И вот теперь все готово, чтобы применить эту конструкцию к статической маршрутизации

route outside 0 0 {next-hop_outside} track {#}
route backup 0 0 {next-hop_backup} 210

Теперь, пока пингуемый хост доступен, track будет в поднятом (чуть не написал в «приподнятом»  ) состоянии и основной маршрут будет в таблице маршрутизации, но как только связь пропадет, через заданное количество потерянных пакетов (по умолчанию пакеты посылаются раз в 10 секунд и ждем пропадания трех пакетов) track будет переведен в состояние down и основной маршрут пропадет из таблицы маршрутизации, а пакеты будут отправляться по запасному пути.

Приведу пример конфига двух дефолтных маршрутов через разных провайдеров с проверкой доступности основного провайдера:

sla monitor 1
type echo protocol ipIcmpEcho 1.1.1.1 interface outside
!
sla monitor schedule 1 start now life forever
!
track 11 rtr 1 reachability
!
route outside 0 0 1.1.1.1 track 11
route backup 0 0 2.2.2.1 210

Динамическая маршрутизация на ASA возможна по протоколам RIPv1,2, OSPF, EIGRP. Настройка этих протоколов на ASA очень похожа на настройку маршрутизаторов cisco. Пока динамической маршрутизации касаться в этих публикациях не буду.

Источник: anticisco.ru/blogs/2010/02/asa-статья-3-маршрутизация/

ASA. Статья 2. Начальные настройки

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

Настройка интерфейсов

Cisco ASA является аппаратным межсетевым экраном с инспектированием сессий с сохранением состояния (stateful inspection).  ASA умеет работать в двух режимах: routed (режим маршрутизатора, по умолчанию) и transparent (прозрачный межсетевой экран, когда ASA работает как бридж с фильтрацией).  Мы познакомимся с работой в первом режиме и далее везде будем его подразумевать, если явно не указан иной режим.

В режиме routed на каждом интерфейсе ASA настраивается ip адрес, маска, уровень безопасности (security-level), имя интерфейса, а также интерфейс надо принудительно «поднять», так как по умолчанию все интерфейсы находятся в состоянии «выключено администратором». (Исключения бывают: иногда АСАшки приходят уже преднастроенными. Это характерно для модели 5505. В этом случае, как правило, внутренний интерфейс с названием inside уже настроен как самый безопасный и поднят, на нем работает DHCP сервер, задан статический адрес из сети 192.168.1.0/24, внешний интерфейс с названием outside тоже поднят и сам получает адрес по DHCP и настроена трансляция адресов из сети за интерфейсом inside в адрес интерфейса outside. Получается такой plug-n-play  )

int g0/0
ip address {адрес} {маска}
security-level {number}
nameif {имя}
no shutdown

Параметр «уровень безопасности» (security level) – это число от 0 до 100, которое позволяет сравнить 2 интерфейса и определить, кто из них более «безопасен». Параметр используется качественно, а не количественно, т.е. важно только отношение «больше-меньше». По умолчанию трафик, идущий «наружу», т.е. с интерфейса с большим уровнем безопасности на интерфейс с меньшим уровнем безопасности, пропускается, сессия запоминается и обратно пропускаются только ответы по этим сессиям. Трафик же идущий «внутрь» по умолчанию запрещен.

Параметр «имя интерфейса» (nameif) в дальнейшем позволяет использовать в настройках не физическое наименование интерфейса, а его имя, которое можно выбрать «говорящим» (inside, outside, dmz, partner  и т.д.). По идее, как утверждает сама cisco, имя не зависит от регистра, (не case sensitive), однако на практике ряд команд требует соблюдения регистра, что довольно неудобно. Характерный пример: применение crypto map на интерфейс требует точного написания названия интерфейса. Название интерфейса продолжается нажатием кнопки TAB, т.е. можно набрать начало названия и табулятором продолжить его до конца, если набранное начало однозначно идентифицирует интерфейс.

Такая настройка интерфейсов характерна для всех моделей ASA, кроме ASA 5505. В модели 5505 реализован встроенный 8мипортовый L2/L3 коммутатор.   IP адреса в модели 5505 задаются на логических интерфейсах

interface vlan {#}
ip address {адрес} {маска}
security-level {number}
nameif {имя}
no shutdown

Сами же физические интерфейсы L2 сопоставляются VLANам.

interface f0/0
switchport access vlan {#}

Таким образом, межсетевое экранирование возникает между логическими interface vlan.

Как правило, уровень безопасности интерфейсов подбирается таким образом, чтобы максимально соответствовать логической топологии сети. Сама топология представляет из себя зоны безопасности и правила взаимодействия между ними. Классической схемой считается присвоение разным интерфейсам разных уровней безопасности.

Никто не запрещает сделать уровень безопасности на разных интерфейсах одинаковым, однако по умолчанию обмен трафиком между такими интерфейсами запрещен. Такой трафик можно сознательно разрешить, дав команду

same-security-traffic permit inter-interface

Однако надо понимать, что между интерфейсами с одинаковым уровнем безопасности не возникает межсетевого экранирования, а только маршрутизация. Поэтому такой подход применяется для интерфейсов, относящихся к одной и той же логической зоне безопасноcти (например, 2 локальные сети пользователей, объединяемые при помощи ASA)

Источник: anticisco.ru/blogs/2010/02/asa-статья-2-начальные-настройки/

ASA как она есть. Статья 1. Чего она не умеет и чего умеет.

Предисловие: читая курсы о безопасности cisco (вот уже 7 лет, много как то  ) сталкиваюсь с одними и теми же вопросами. Давно уже хочу излить ответы на бумаге ибо повторять одно и то же уже нет сил  Поэтому попробую тезисно, емко рассказать об основных особенностях работы cisco ASA, настройке основных технологий с использованием CLI (настройка через web интерфейс при понимании технологии не сложна) а также некоторых дизайнерских моментах.

Итак, начну, пожалуй, с очень важной и для настройщиков, и для дизайнеров, и для предпродажников темы: чего ASA не умеет.

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

1. Разделение трафика по параллельным путям (путям с одинаковой метрикой) через разные интерфейсы. Не смотря на то, что ASA является устройством 3 уровня, уверенно работает с протоколами RIPv1,2, OSPF, EIGRP, она не поддерживает избыточных маршрутов, т.е. в таблицу маршрутизации всегда попадает один маршрут. Если же маршрутов с одинаковой метрикой более одного (например, OSPF прислал), то выбирается…первый попавшийся  При его пропадании сразу же «найдётся» второй. В частности поэтому невозможно написать 2 дефолтных маршрута (route {int} 0 0 {next-hop}). Исключение составляют маршруты в одну и ту же сеть с одинаковой метрикой через один и тот же исходящий интерфейс. В этом случае может использоваться до трех маршрутов.
2. ASA не поддерживает Policy Based Routing (PBR). Т.е. вы не можете принудительно отправить пакет через определенный интерфейс, основываясь на адресе источника (напомню, что на маршрутизаторах это делается при помощи конструкции route-map, примененной на вход внутреннего интерфейса). Злую шутку со многими настройщиками маршрутизаторов, впервые сталкивающихся с ASA, сыграло то, что на ASA route-map есть! Только используется она исключительно для редистрибуции маршрутов.
3. На ASA нет никаких виртуальных интерфейсов (tunnel, loopback). Поэтому она не поддерживает туннели GRE (очень жаль!), а следовательно и удобную технологию DMVPN.

Это, пожалуй, основные моменты. Есть еще ряд неудобств, но как правило они не критичны в проектах. К ним могу отнести:

1. На ASA нет ни telnet, ни ssh клиента. Т.е. пойти с ASA куда то не получится.
2. У ASA нет «внутренней» маршрутизации, т.е маршрутизации внутри себя. Попасть из зоны inside на интерфейс outside не получится. Правда, с переходом на OS Linux подвижки в этом направлении появились, например, можно «увидеть» адрес внутреннего интерфейса сквозь туннель IPSec, а также позволить управлять ASA сквозь туннель, соединяясь с адресом внутреннего интерфейса (надо дать командуmanagement-interface [int]). В частности поэтому на ASA надо явно указывать интерфейс, через который будет достижим тот или иной адрес, например адрес next-hop при задании статического маршрута

route outside 0 0 192.168.1.1

или при задании сервера аутентификации

aaa-server TAC (inside) host 10.1.1.100

1. На ASA нельзя сразу попасть на 15 уровень привилегий без дополнительного запроса для входа в enable.
2. На ASA нельзя увидеть стартовую конфигурацию как файл в какой-нибудь файловой системе (на маршрутизаторе этот файл лежит в nvram: ). При этом running-config увидеть можно:

more system:/running-config

1. На ASA нельзя просто залить новый файл ОС, чтобы получить новый функционал. Весь функционал уже «зашит» в ОС, а фичи включаются при помощи лицензии (activation key)
2. На ASA нельзя сделать РРТР сервер, равно как и использовать её как РРТР клиента.

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

Теперь поговорим о том, что при помощи ASA сделать можно:

1. Маршрутизация, в том числе динамическая
2. НАТ во всех видах, какие только можно измыслить
3. Динамическое межсетевое экранирование
4. Modular Policy Framework (MPF, конструкция для сортировки пакетов по классам и применения к ним различных действия, например, приоритизация и ограничение полосы)
5. Глубокий анализ «сложных» протоколов (FTP, H.323, SIP,TFTP, IPSec и т.д.)
6. AAA, в том числе перехватывающая аутентификация
7. IPSec Site-to-site, Easy VPN Server (ASA 5505 может быть и hardware client)
8. SSLVPN gate
9. Виртуальные межсетевые экраны (Context)
10. Failover (Active/Standby и Active/Active)
11. «Прозрачное» экранирование (Transparent Firewall)

Поговорим об этих технологиях подробнее в следующих публикациях.

Источник: anticisco.ru/blogs/2010/02/asa-как-она-есть-статья-1-чего-она-не-умеет/

Cisco ASA. Настройка перехватывающей аутентификации через AD и LDAP

Часто возникает задача проверить пользователя до предоставления ему доступа к определенным ресурсам. На Cisco ASA такая проверка называется «перехватывающая аутентификация» (cut-through proxy).

Этот сервис использует инфраструктуру ААА (Authentication, Authorization, Accounting).

Аутентификация.
Отвечает на вопрос «есть ли такой пользователь». Поиск этого пользователя может производиться как в локальной (LOCAL) базе данных, так и во внешних (TACACS+, RADIUS, AD по протоколу LDAP).

Для справки, опишу, как работают эти протоколы:

TACACS+ — протокол cisco. Работает по ТСР/49. Имеет отдельные запросы на аутентификацию, авторизацию и учет. За счет отдельного запроса на авторизацию позволяет учитывать и проверять все вводимые команды. Не расширяемые параметры, слабый «учет». Как правило, используется для административного доступа (доступа на железку для управления)

RADIUS – стандартный протокол (правда, имеет кучу расширений многих производителей). Работает по UDP/1645,1646 или UDP/1812,1813. Один новый, другой старый стандарт. Первый порт используется для аутентификационного запроса и ответа, в котором заодно передаются авторизационные атрибуты пользователя, если есть. Второй – для учета (как правило, при помощи RADIUS учитывают переданные пакеты, считают трафик и некоторые системные параметры)

AD через LDAP – база данных пользователей домена Windows. LDAP работает по ТСР/389. Содержит кучу атрибутов, которые слабо применимы для сетевых нужд. Однако, за счет его широчайшего распространения, cisco научила свои МСЭ лазить в AD напрямую, забирая оттуда все атрибуты пользователя, если ему разрешен доступ. Этим можно (и часто – нужно) воспользоваться, сопоставив атрибуту AD некоторый атрибут, понятный для МСЭ (об этом – ниже)

Научимся же задавать сервера аутентификации.
Для протоколов TACACS+ и RADIUS это делается так:

aaa-server {SERVERNAME} protocol {tacacs|radius}
aaa-server {SERVERNAME} ({interface}) host {IP_SERVER}
 key {ключ}

Ключ общий для Cisco ASA и сервера.

Пример:
aaa-server RAD protocol radius
aaa-server RAD (dmz) host 172.16.1.100
 key MYRADKEY

Настройка сервера LDAP несколько сложнее, т.к. подразумевает указание учетной записи пользователя из AD, с которой Cisco ASA будет входить в LDAP, тип сервера, «корень» поиска и т.д.

aaa-server {SERVERNAME} protocol ldap
aaa-server {SERVERNAME} ({interface}) host {IP_SERVER}
 ldap-base-dn {корневой уровень}
 ldap-scope {subtree|onelevel}
 ldap-naming-attribute {передаваемый атрибут}
 ldap-login-dn {имя пользователя ASA}
 ldap-login-password {пароль на пользователя ASA}
 server-type {Microsoft|Novell|OpenLDAP|sun|auto}

Пример:
aaa-server AD (dmz) host 172.16.1.100
 ldap-base-dn ou=Employers, dc=anticisco, dc=ru
 ldap-scope subtree
 ldap-naming-attribute sAMAccountName
 ldap-login-dn cn=ASA, cn=users, dc=anticisco, dc=ru
 ldap-login-password ASALDAPPASS
 server-type microsoft

Примечание: в конфигурации пароль будет закрыт звездочкой, однако его можно просмотреть командой
more system:/running-config

После того, как настроены сервера, самое время определить, какой трафик нам интересно проверять и не пропускать без аутентификации. На Cisco ASA за это отвечает…конечно список доступа, где строчками permit указывается такой трафик. Сам список доступа для аутентификации применяется командой

aaa authentication match {AUTHACL} {interface} {SERVERNAME}

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

Например, хотим проверить весь трафик из локальной сети 10.1.1.0/24 (за интерфейсом inside), идущий во все сети, кроме 172.16.1.0/24:
access-list AUTH deny ip 10.1.1.0 255.255.255.0 172.16.1.0 255.255.255.0
access-list AUTH permit ip 10.1.1.0 255.255.255.0 any
aaa authentication match AUTH inside RAD

А как же спросить у пользователя его логин/пароль? Ведь не может же какой-нибудь пинг инициировать запрос?
Перехватить сессию и спросить логин и пароль Cisco ASA может по протоколам http/https, ftp, telnet. Если же необходимо аутентифицировать другой трафик, то надо сделать 2 телодвижения: пойти куда-нибудь за Cisco ASA по одному из указанных протоколов, ввести свои логин/пароль либо в броузере либо в telnet либо в ftp окошке. Надо учитывать, что такой трафик обязательно должен быть указан в списке доступа для интересного трафика.
Например, мы хотим, чтобы пользователь мог пойти по telnet или http на хост 1.1.1.1 и его бы спросили логин и пароль. Тогда этот трафик обязательно должен попадать в список доступа. Вот такой не подойдет, т.к. по telnet работать не будет:

access-list AUTH permit tcp any any eq 80
access-list AUTH permit udp any any

Если данные верны, Cisco ASA пропустит ваш трафик. Но только на указанное время. По умолчанию таймауты, скажем так, странные: 5 минут абсолютного времени, таймаут неактивности не отслеживается. Поменять их не только можно, но и нужно:

timeout uauth {HH:MM:SS} {absolute|inactivity}

Пример:
timeout uauth 0:15:0 inactivity
timeout uauth 20:00:00 absolute

Примечание: Эти атрибуты также можно назначать по группам или по пользователям, но только используя сервер RADIUS (атрибуты 027 и 028 в секундах соответственно)

Таким образом, с аутентификацией все просто: если более ничего не указывать, то пользователю, а вернее, ip-адресу его компьютера, будет можно все.

Гораздо более интересный момент – авторизация, то есть ограничение прав пользователя.

По протоколу TACACS можно ограничивать доступ к определенным ресурсам (сетям и протоколам), однако формат такого ограничения весьма странный: на сервере описываются все такие протоколы и сети, и обращение с Cisco ASA на сервер идёт всякий раз, когда появляется ранее не изученный пакетик.
Для этого надо отдельно писать команду для авторизации. Можно использовать тот же список доступа, который был использован для аутентификации, а можно написать новый

aaa authorization match {AUTHORACL} {interface} {SERVERNAME}

Проще использовать протокол RADIUS, у которого предусмотрена возможность в атрибутах пользователя передавать строки списка доступа, который применяется непосредственно к пользователю. Никаких дополнительных команд писать не надо. Правда, такая возможность есть у cisco ACS (Access Control Server). Доподлинно я не знаю, есть ли бесплатные и свободные реализации сервера RADIUS, умеющие также передавать строчки. Впрочем, вручную их точно можно описать.
А в стандартном сервере RADIUS есть атрибут IETF-Radius-Filter-Id, который можно задействовать и при помощи него передавать название списка доступа, который есть на Cisco ASA. Такой список будет применяться на пользователя.

Для авторизации по LDAP нам нужен «костыль» — специальная конструкция, которая сопоставит атрибуту LDAP атрибут RADIUS, который поймет Cisco ASA. Такая конструкция называется

ldap attribute-map {MAPNAME}
 map-name {LDAPATTRIBUTE} {RADUISATTRIBUTE}
 map-value {LDAPATTRIBUTE} {SENDNAME} {TRANSLATENAME}

Пример. Сопоставим атрибуту ipPhone базы AD атрибут IETF-Radius-Filter-Id (список доступа). И опишем, что если в указанном атрибуте мы получим слово «BUHG», то на пользователя применим список доступа BUH, который уже написан на ASA:
ldap attribute-map AD
 map-name ipPhone IETF-Radius-Filter-Id
 map-value ipPhone BUHG BUH

Важно: если в указанном атрибуте мы ничего не получили, мы его игнорируем, а если получили слово, не описанное в значениях для данного атрибута, то доступ будет запрещен. Таким образом, администратор AD может влиять на права доступа. Например, может перекрыть интернет неугодному пользователю, не прикасаясь к Cisco ASA:)

Осталось только применить этот список атрибутов в конкретном сервере LDAP

aaa-server {SERVERNAME} ({interface}) host {IP_SERVER}
 ldap-attribute-map {MAPNAME}

Пример:
aaa-server AD (dmz) host 172.16.1.100
 ldap-attribute-map AD

Посмотреть, какие пользователи сейчас прошли проверку и какие списки доступа в ним прицеплены можно командой

show uauth

Почистить эти записи полностью или по конкретному пользователю можно командой

clear uauth {* | USERNAME}

Учет. Здесь нет ничего сложного, но надо помнить, что Cisco ASA при передаче трафика может подсчитывать только TCP и UDP. Какой трафик мы хотим учитывать, тоже описывается списком доступа.

Пример: посчитаем весь http трафик в сеть 172.16.1.0/24
access-list ACC permit tcp any 172.16.1.0 255.255.25.0 eq 80
aaa accounting match ACC inside RAD

Понятно, что учет нельзя делать на сервер LOCAL (локально), а также на сервер LDAP. На TACACS передается не так много атрибутов, как хотелось бы, а вот RADIUS подходит лучше всего. Причем использовать можно любой. В частности я, когда настраиваю аутентификацию и авторизацию через LDAP для учета использую IAS (это как раз и есть RADIUS, встроенные в сервер Windows)

Источник: blogsvazista.ru/cisco-asa-nastroika-authenticaticon/

Настройка 802.1x на оборудовании cisco (Часть №2)

В прошлом посте мы остановились на том, что закончили общую настройку ACS. Кто случайно попал сразу на вторую часть, то прочитайте сначала первую. А всех остальных, приглашаю под кат...

Теперь вернемся на наш L2_Switch. Настроим его на работу с 802.1x.

L2_Switch#conf t
L2_Switch(config)#aaa new-model - глобально включаем ААА;
L2_Switch(config)#aaa authentication dot1x default group radius -настраиваем свитч использовать Radius для 802.1x аутентификации на всех интерфейсах;
L2_Switch(config)#aaa authorization network default group radius -настраиваем свитч использовать Radius для 802.1x авторизации;
L2_Switch(config)#aaa accounting dot1x default start-stop group radius - настраиваем свитч использовать Radius для 802.1x аккаунтинга;
L2_Switch(config)#ip radius source-interface vlan 2 - в качестве интерфейса, с которого будет отправляться информация на ACS (Radius) используем interface-vlan 2;
L2_Switch(config)#radius-server host 192.168.1.100 auth-port 1645 acct-port 1646 - прописываем IP-адрес и порты нашего Radius-сервера;
L2_Switch(config)#radius-server key сisc0 - указываем секретный ключ, который мы задавали при настройке ACS;
L2_Switch(config)#dot1x system-auth-control - включаем 802.1x на свитче;
L2_Switch(config)#int range fa 1/1 - 2 - заходим сразу на два интерфейса, где у нас будет работать 802.1x;
L2_Switch(config-if-range)#dot1x port-control auto - устанавливаем состояние порта для 802.1x "автоматически", т.е. будет определяться по итогам аутентификации;
L2_Switch(config-if-range)#dot1x timeout reauth-period server -указываем, что период между повторными аутентификациями указан на ACS-сервере;
L2_Switch(config-if-range)#dot1x reauthentication - включаем повторную аутентификацию на портах;
L2_Switch(config-if-range)#dot1x guest-vlan 5 - данная команда используется для определения устройств, на которых нет CTA или не поддерживается 802.1x, в определенный vlan. В нашем случае - это vlan5 (TRASH);
L2_Switch(config-if-range)#exit
L2_Switch(config)#exit
L2_Switch#wr 

Итак, со свитчем закончили. Теперь нам снова предстоит вернуться на ACS и как то связать все предыдущие настройки воедино :). Для этого нам необходимо будет создать и настроить так называемый "Network Access Profile". Он то и свяжет ранее настроенные аутентификацию, "Posture Validation" и авторизацию.
Возвращаемся на ACS и выбираем из правого меню пункт "Network Access Profiles". В нем не будет еще профилей, так что нажимайте на "Add Profile". Откроется следующее окно:

Здесь задаем имя нашему профилю (1) и включаем его (2). Остальные параметры оставляем по умолчанию. Нажимаем "Submit". Вы вернетесь на предыдущее окно, но там уже будет созданный профиль:

Как видите, профиль появился и он активирован. В поле "Policies" представлены политики, с помощью которых нам и предстоит связать ранее сделанные отдельные настройки в "единый организм" :). Так же вверху написано, что для применения настроек необходимо нажать на "Apply and Restart". Так и делаем.
После перезапуска переходим по первой ссылке в поле "Policies", а именно "Protocols". Откроется окно, в котором нас интересует только "EAP-FAST":

Устанавливаем значения параметров, как показано на рисунке выше и нажимаем "Submit". Вы вернетесь на предыдущее окно. Там снова нажимаем "Apply and Restart" и выбираем следующую ссылку "Authentication":

Здесь нас интересует "Credential Validation Database", т.е. к какой базе мы будем обращаться для проверки пользователя. Так как мы используем внутреннюю базу ACS, то выбираем "ACS Internal Database" в левом столбце, нажимаем на стрелку и переносим его в правый столбец. После этого нажимаем на "Submit" и затем, вернувшись на предыдущую страницу, "Apply and Restart". Переходим по следующей ссылке "Posture Validation". Соответственно вы не увидите там правил, так что сразу нажимаем на "Add Rule":

Итак, здесь задаем имя нашему правилу (1). В пункте "Condition" из правого столбца выбираем "Cisco:PA" (так как мы используем только его) и переносим его в левый столбец (2). Далее выбираем ранее созданную внутреннюю политику "Posture Validation" (3). Помните, я говорил про параметр "Posture Token", который соответствовал каждой подгруппе критериев в политике "Posture Validation", так вот здесь, в соответствующих полях, и задается текст, который будет высвечиваться у клиентов с установленным CTA. Соответственно, "Healthy" (4) - при успешной проверке высветится "You was success validated!!!", "Unknown" (5) - при не успешной высветится "Call your administrator!!!". Конечно, помимо просто фразы, можно задавать и другие фишки, но, это уже вам на баловство :). Нажимаем "Submit".
Вы вернетесь на предыдущее окно и должны увидеть вот такую картинку:
  

Нажимаем "Done". Вернувшись на предыдущее окно, снова нажимаем на "Apply and Restart" и переходим по последней ссылке "Authorization". Вы снова увидите отсутствие правил. Нам необходимо создать 3 правила, так что 3 раза нажимаем на "Add Rule". После этого добавятся 3 строчки. Далее начинаем заполнять их, используя выпадающее меню в каждом параметре. По итогу у вас должно получиться вот так:

Итак, что мы имеем. Каждой группе пользователей соответствует свой vlan, в который они будут попадать при успешной авторизации и только после успешной проверки "Posture Validation" (параметр "System Posture Token" ("Healthy")) (1,2,3). Если соответствия не будет найдено или "Posture Validation" завершиться не удачно (не будет установленного CTA или он не будет соответствовать нужной версии), то пользователь будет перемещен в глухой vlan TRASH (4). Прошу обратить внимание, что даже если вы зайдете под пользователем, который входит в группу "Administrators", на компьютер, у которого нет CTA или не та версия, то вы будете перемещены в vlan TRASH (это мы увидим когда будем делать проверки). Использовать настройки групп пользователей и самих пользователей мы не будем, так что снимите отметки с данных параметров (5). Нажимаем "Submit". Вернувшись на предыдущую страницу, снова нажимаем "Apply and Restart".
Основные настройки на сетевом оборудовании и на сервере ACS закончены. Нам осталось настроить DHCP сервер, установить Cisco Trust Agent на Host_1 и, собственно, сделать все проверки работы 802.1x.
Начнем с сервера DHCP. Возвращаемся на Server CA, ACS, DHCP. Переходим в "Start"--"Control Panel"--"Add or Remove Programs"--"Add/Remove Windows Components". Далее находим сервис DHCP:

Нажимаем "OK". Затем нажимаем "Next". Начнется процесс установки. После установки переходим к сервису ("All Programs"--"Administrative Tools"--"DHCP"). В открывшемся окне правой клавишей мыши нажимаем на сервере и выбираем пункт меню "New Scope". Запустится wizard. В первом окне нажимаем "Next". Откроется окно:

Здесь задаем имя (для того, чтобы не запутаться, лучше задавать имя, соответствующее vlan-у, для которого создается пул). Нажимаем "Next":

Здесь указываем начальный (1) и конечный (2) IP-адреса для выдачи клиентам, так же задаем маску сети (3). Нажимаем "Next":

Здесь необходимо указывать диапазон (меня лично удивило, что именно диапазон. Указать конкретно один IP-адрес не получится) IP-адресов, которые выдаваться клиентам не будут. Но так как в диапазон для раздачи клиентам у нас не попадают ни адрес сервера, ни адреса сетевого оборудования, то оставляем поля пустыми и нажимаем "Next":

Здесь задается время, на которое выделяется IP-адрес клиенту. Оставляем по умолчанию и нажимаем "Next". Откроется окно, где предложат настроить дополнительные опции DHCP сервера. Соглашаемся и нажимаем "Next":

Здесь задаем IP-адрес шлюза по умолчанию, который будет спускаться клиентам. Задаем его и нажимаем "Add". Он появится в списке ниже. В следующих окнах нам настраивать ничего не надо, так что смело нажимайте "Next" в этом окне и в следующих. В последнем окне нажимаем "Finish".
Первый пул появится в списке. Таким же образом необходимо создать пулы для остальных vlan-ов. В итоге, у вас должно получиться вот так:

Всё, с сервером DHCP закончили. Переходим на Host_1 и установим Cisco Trust Agent (CTA). Для его установки нам понадобится непосредственно установочный файл (ctasetup-supplicant-win-2.1.103.0.msi) и перенесенные на рабочую станцию (любым доступным способом) сертификаты (корневой сертификат CA и сертификат сервера ACS), которые мы генерировали ранее.
Для успешной инсталляции CTA необходимо, перед началом установки, в папке, где лежит установочный файл, создать папку с названием "certs" и положить туда скопированные сертификаты:

Запускаем файл *.msi. В первом окне нажимаем "Next". Во втором, соглашаемся с лицензией и нажимаем "Next". В следующем окне показан путь, куда будет установлен CTA. Если не требуется его менять, то нажимаем "Next". Откроется окно:

Здесь выбираем пункт "Complete" для установки полного функционала программы. Нажимаем "Next". Появится окно с оповещением, что все готово к установке. Нажимаем "Next". Начнется процесс установки. На конечном этапе у вас должно появиться следующее сообщение:

Оно обозначает, что сертификаты, лежащие в специально созданной папке, успешно импортированы. Нажимаем "OK". В финальном окне нажимаем "Finish". Вам сразу предложат перегрузить компьютер. Пока этого не делайте, так как мы подходим уже к нашим проверкам и необходимо еще немного к ним подготовиться.
Прежде чем перегружать компьютер, создайте на нем точно таких же пользователей, как мы создавали на сервере ACS (admin, guest, work и, желательно, на время дать им права администраторов для отображения сообщений от CTA, так как у простых пользователей может быть запрет на всплывание окон).
Так же пришло время включить порты на свитче L2_Switch, к которым подключены хосты для проверки:

L2_Switch#conf t
L2_Switch(config)#int range fa 1/1 - 2
L2_Switch(config-if-range)#no shutdown
L2_Switch(config-if-range)#exit
L2_Switch(config)#exit
L2_Switch#wr
L2_Switch# 

Все готово к проверкам. Для начала, давайте посмотрим в каком vlan-е на данный момент находятся порты, к которым подключены Host_1 и Host_2:

Как видно из рисунка, на данный момент эти порты находятся в vlan-е TRASH, хотя, если помните, мы не определяли их в определенную сеть, а лишь указали, что guest-vlan для 802.1x является именно vlan TRASH. Это и правильно, так как не известно, что будет подключено в данный порт и как завершится аутентификация.
Теперь, переходим на Host_1 (проверьте, чтобы в настройках сетевой карты стоял пункт динамически получать IP-адрес) и перегружаем его (ну или включаем, если вы его выключали). При загрузке у вас должно появиться, помимо стандартного окна аутентификации windows, куда необходимо ввести учетные данные пользователя, еще и вот такое дополнительное окно Cisco Trust Agent-а:

Здесь вводим данные пользователя, которого заводили на ACS (в данном случае начнем с пользователя "admin"). CTA по умолчанию пытается аутентифицировать и сам компьютер, но так как мы этого не настраивали, то придется подождать некоторое время, пока он не закончит эти попытки. Если вы все ввели правильно, то после загрузки windows вы увидите следующее сообщение:

Если помните, сообщение "You was success validated!!!" мы сами задавали ранее, и обозначает оно, что мы успешно прошли "Posture Validation". Еще одним признаком успешной аутентификации является значок CTA в панели инструментов (зеленый цвет, как показано на рисунке).
Теперь посмотрим, что делается на свитче L2_Switch и проверим сетевую доступность с компьютера Host_1. Переходим на L2_Switch:
  

Как видно, порт перешел из vlan-а TRASH в vlan Administrator. Идем на Host_1:

Как видно из рисунка, мы получили параметры (IP-адрес, маску сети и шлюз) по DHCP из нужного диапазона (1) и получили сетевую доступность, оговоренную в начале поста (успешный ping на ACS (2), на PC_For_Test_1 (3) и на PC_For_Test_2 (4)).
Идем дальше. Теперь сделаем "LogOff" и зайдем под пользователем "work" (Следует отметить, что CTA сохраняет у себя учетные данные, которые вы вводили для каждого нового пользователя и соответственно в следующий раз при входе в систему под этим пользователем, вводить эти данные не придется.). После входа в систему вы должны будете увидеть то же сообщение, что и в предыдущем примере. Проверим что доступно этому пользователю:

Как видно, IP-адрес получен из нужного диапазона (1), доступ в сеть администратора закрыт (2), есть доступ к PC_For_Test_1 (3) и к PC_For_Test_2 (4). Всё, как и оговаривали при постановке задачи.
Посмотрим теперь на L2_Switch:

Порт находится в нужном vlan-е (WORK). Снова делаем "LogOff" и заходим под пользователем "guest":

Как видно, IP-адрес получен из нужного диапазона (1), доступ в сеть администратора закрыта (2), есть доступ к PC_For_Test_1 (3) и нет доступа к PC_For_Test_2 (4). Всё, как и оговаривали при постановке задачи.
Снова посмотрим на L2_Switch, но теперь с помощью команды "show dot1x interface fastEthernet 1/1 details". С помощью нее тоже можно увидеть всю интересующую нас информацию:

где:
• 1 - mac-адрес компьютера;
• 2 - его состояние "аутентифицирован";
• 3 - состояние порта коммутатора "авторизован";
• 4 - период повторной аутентификации 3600 секунд (задавали ранее на ACS);
• 5 - обозначает, что повторная аутентификация включена;
• 6 - время, до повторной аутентификации;
• 7 - метод аутентификации 802.1x;
• 8 - указывает, что процесс Posture Validation прошел успешно;
• 9 - порт авторизован сервером (ACS);
• 10 - порт находится в vlan-е тегом 4 (GUEST).

Все как и должно быть. Осталось проверить, что произойдет, если версия CTA не соответствует заданной и куда попадают компьютеры или другие устройства, у которых вообще нет CTA или не поддерживается 802.1x.
Для проверки версии CTA, изменим условие в политике "Posture Validation Policy". Для этого, переходим на ACS и идем по пути "Posture Validation" -- "Internal Posture Validation Setup". Там выбираем ранее созданную политику ("My_Policy"), в ней выбираем необходимый "Condition" и в нем удаляем старый параметр с Cisco:PA:OS-Version >=2.0.0.0 и добавляем новый Cisco:PA:OS-Version >=6.0.0.0.
В итоге, политика должна выглядеть следующим образом:

Нажимаем на "Done". В следующем окне нажимаем "Apply and Restart". Затем возвращаемся на Host_1 и делаем "LogOff". Зайдем под учетной записью администратора и посмотрим что получится:

Вы увидите вот такое сообщение. Если помните, это сообщение мы настраивали как раз для тех, кто не пройдет "Posture Validation". Теперь посмотрим какой IP-адрес у компьютера и проверим сетевую доступность:

Теперь на свитче L2_Switch:
  

Из рисунков видно, что даже несмотря на то, что мы зашли на компьютер под учетной записью администратора ("admin"), мы попали в изолированный vlan TRASH, получили IP-адрес из соответствующего диапазона и можем лишь ping-овать только шлюз по умолчанию (как и оговаривалось в начале поста).
Ну и последняя проверка. Включим Host_2 и посмотрим куда он попадет:

Как и предполагалось, он попал куда следует :). Рисунок говорит сам за себя.
Проверки успешно пройдены, всё что планировали, работает. Есть небольшой "баг" который я заметил при написании поста и работе в GNS3. При проверках, когда вы сделали "Login" и "Logoff" для пользователей и потом перезагрузили Host_1, то 802.1x не отработает. Чтобы все заработало снова, необходимо остановить ("Stop") и снова запустить ("Start") L2_Switch.
Вот в принципе на сегодня и всё :). Надеюсь, повествование было для вас познавательным и интересным. Хочу поблагодарить вас за внимание!!!

Источник: go-to-easyit.com/2013/11/8021x-cisco-2.html