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/